Po długim czasie pracy w aplikacji na iPhone'a, zdałem sobie sprawę, że mój kod jest dość brudny, zawierający kilka #importów i metod, które nie są w ogóle wywoływane lub przydatne.Jak wykrywać nieużywane metody i #import w Objective-C
Chciałbym wiedzieć, czy istnieje dyrektywa kompilatora lub sposób wykrywania tych niepotrzebnych linii kodu. Czy Xcode ma jakieś narzędzie do wykrycia tego?
Xcode umożliwia (nie) sprawdzanie ustawień określonych ostrzeżeń kompilatora, które mogą ostrzegać o niektórych rodzajach nieużywanego kodu. (Zaznacz projekt na liście źródeł i Plik> Informacje, a następnie wybierz kartę budować.) Oto kilka z nich (który pojawi się na Clang i GCC 4.2 dla mnie), które mogą stanowić przedmiot zainteresowania:
nie widzę żadnych możliwości wykrywania nieużywane importu, ale to nieco prostsze - podejście low-tech jest po prostu skomentuj instrukcje importu aż do ciebie uzyskać błąd kompilacji/ostrzeżenie.
Niewykorzystane metody Objective-C są dużo trudniejsze do wykrycia niż nieużywane funkcje C, ponieważ komunikaty są wysyłane dynamicznie. Ostrzeżenie lub błąd może informować o potencjalnym problemie, ale jego brak nie gwarantuje, że nie wystąpią błędy środowiska wykonawczego.
Edit: Innym dobrym sposobem na wykrycie (potencjalnie) niewykorzystane metody jest analiza pokrycia kodu od rzeczywistych egzekucji. Zwykle odbywa się to w parze z automatycznymi testami jednostkowymi, ale nie musi tak być.
This blog post to przyzwoite wprowadzenie do testów jednostkowych i pokrycia kodu za pomocą Xcode. Sekcja o gcov (która nawiasem przypomina kod wygenerowany przez GCC, nawiasem mówiąc) wyjaśnia, jak zmusić Xcode do zbudowania oprzyrządowanego kodu, który może rejestrować, jak często został wykonany. Jeśli weźmiesz symulację na oprzyrządowaną kompilację swojej aplikacji, a następnie uruchom gcov, zobaczysz, jaki kod został wykonany za pomocą narzędzia takiego jak CoverStory (dość uproszczony GUI) lub lcov (skrypty Perla do tworzenia raportów HTML).
Używam gcov i lcov dla CHDataStructures.framework i automatycznie generuję coverage reports po każdym zatwierdzeniu SVN. Ponownie, pamiętaj, że nierozsądne jest traktowanie wykonanego zasięgu jako definitywnej miary tego, co kod jest "martwy", ale z pewnością pomoże to w zidentyfikowaniu metod, które możesz dalej zbadać.
Wreszcie, ponieważ starasz się usunąć martwy kod, myślę, że znajdziesz to tak interesujące, jak również pytanie:
Niedawno zmieniłem dużego projektu z Węgiel do kakao. Pod koniec tego było sporo osieroconych plików, które nie były już używane.Napisałem skrypt, aby je znaleźć, że w istocie to zrobił:
Zapewnienie źródła wszystko jest sprawdzane w celu dywersji (czyli czysty) upewnić się, że obecnie buduje bez błędu (tj xcodebuild zwraca 0 statusu) Następnie dla każdego źródła plik w katalogu, pusty (tj. usuń zawartość, skróć długość) źródło i plik nagłówkowy, spróbuj zbudować, jeśli się nie powiedzie, przywróć pliki, w przeciwnym razie pozostaw je puste.
Po uruchomieniu tego, przywróć, a następnie usuń wszystkie opróżnione pliki, skompiluj, a następnie usuń wszystkie błędy #imports.
Powinienem również dodać, że należy unikać plików, do których odwołują się pliki .xib lub .sdef, i mogą istnieć inne dynamiczne przypadki łączenia, ale nadal mogą one dostarczyć wskazówek co do tego, co można usunąć.
Ta sama technika może być użyta do sprawdzenia, które #import można usunąć - zamiast skracać plik, usuń po kolei #import w pliku i sprawdź, czy kompilacja nie powiedzie się.
Niedawno napisałem skrypt znaleźć niewykorzystane (lub duplikat) #import oświadczenia: https://gist.github.com/Orangenhain/7691314
Skrypt pobiera plik .m objc i zaczyna zakomentowanie każdą linię kolei #import i zobaczyć, czy projekt nadal kompiluje. Będziesz musiał zmienić BUILD_DIR & BUILD_CMD.
Jeśli używasz polecenia find niech skrypt przejechać wiele plików, upewnij się, aby użyć BUILD_CMD że faktycznie używa wszystkie te pliki (lub pojawi się plik z dużą ilością niewykorzystanych sprawozdania importu).
Napisałem to nie wiedząc, że AppCode ma podobną funkcję, jednak kiedy testowałem AppCode, nie było tak dokładne jak ten skrypt (ale o wiele szybciej [dla całego projektu]).
Działa tylko w duplikatach, nieużywany import nie jest usuwany. – Rahul
Używamy jakąś uczelnię kodu Ruby, teraz ekstrakcji do gem nazwie fui: https://github.com/dblock/fui
nie działa z Xcode 6.4 i 10.10.5 –
fui znajduje nieużywane klasy nie importowane. Nazwa jest bardzo myląca .. – Fengson
Jak paddydub powiedział AppCode to zrobić bardzo dobrze. Próbowałem, i zajęło mi tylko 10 minut:
Idź do Code > Optimize Imports... lub ^ + ⌥ + O
Oto film opisujący, jak to zrobić: Detection of unused import and methods in AppCode
Można użyć Xcode Analyzer do stwierdzenia, że i inne problemy.
http://help.apple.com/xcode/mac/8.0/#/devb7babe820
Ponadto można przejść do kompilacji projektu oraz docelowej i dodawać ostrzeżenia zmiany preferencji w ustawieniach kompilacji. Zobacz ten przewodnik:
http://oleb.net/blog/2013/04/compiler-warnings-for-objective-c-developers/
http://clang-analyzer.llvm.org/ – slf
Nie jestem pewien, co jest punkt ...Analizator statyczny może znaleźć wiele problemów, ale jeśli wyślesz wiadomość do zmiennej wpisanej jako ** id "** lub utworzysz selektor do wywoływania w czasie wykonywania, analizator statyczny nie może zagwarantować, że kod jest naprawdę nie używany. Jeśli kod, który jest nadal potrzebny, zostanie usunięty, w tym miejscu pojawią się błędy środowiska wykonawczego. Czy czegoś brakuje? –
Co więcej, selektory tworzone na podstawie ciągów w czasie wykonywania są dość powszechne. – dreamlax