Как обнаружить неиспользованные методы и #import в Objective C

Xcode позволяет вам (отменить) проверку настроек на наличие определенных предупреждений компилятора, которые могут предупредить вас о некоторых типах неиспользуемого кода. (Выберите проект в списке источников и выберите «Файл»> «Получить информацию», затем выберите вкладку «Сборка»). Вот несколько (которые отображаются для меня в Clang и GCC 4.2), которые могут быть интересны:

• Неиспользуемые функции
• Неиспользуемые параметры
• Неиспользуемые значения

Я не вижу никаких вариантов для обнаружения неиспользуемого импорта, но это немного проще - нетехнологичный подход заключается в том, чтобы просто закомментировать операторы импорта, пока вы не получите ошибку / предупреждение компиляции .

Неиспользуемые методы Objective-C гораздо труднее обнаружить, чем неиспользуемые функции C, потому что сообщения отправляются динамически. Предупреждение или ошибка могут сказать вам, что у вас есть потенциальная проблема, но ее отсутствие не гарантирует, что у вас не будет ошибок времени выполнения.

Редактировать: Еще один хороший способ обнаружить (потенциально) неиспользуемые методы - это изучить покрытие кода от фактических выполнений. Обычно это делается в тандеме с автоматическим модульным тестированием, но это не обязательно.

Это сообщение в блоге представляет собой достойное введение в модульное тестирование и покрытие кода с помощью Xcode. В разделе gcov (который, кстати, работает только с кодом, сгенерированным GCC) объясняется, как заставить Xcode строить инструментированный код, который может записывать, как часто он выполнялся. Если вы протестируете инструментальную сборку своего приложения в симуляторе, а затем запустите на нем gcov, вы увидите, какой код был выполнен с помощью такого инструмента, как CoverStory (довольно упрощенный графический интерфейс) или lcov (скрипты Perl для создания отчетов в формате HTML).

Я использую gcov и lcov для CHDataStructures.framework и автоматически генерирую отчеты о покрытии после каждой фиксации SVN. Опять же, помните, что неразумно рассматривать выполненное покрытие как окончательную меру того, какой код «мертв», но это, безусловно, может помочь определить методы, которые вы можете исследовать дальше.

Наконец, поскольку вы пытаетесь удалить мертвый код, Думаю, вы также найдете этот вопрос SO интересным:

• Профилирование размера двоичного изображения Objective-C

Недавно я изменил большой проект с Carbon на Cocoa. В конце концов, было довольно много потерянных файлов, которые больше не использовались. Я написал сценарий, чтобы найти их, которые, по сути, сделали следующее:

Убедитесь, что исходный код зарегистрирован на подрывную деятельность (т.е. очищен) Убедитесь, что в настоящее время сборка выполняется без ошибок (т.е. xcodebuild возвращает статус 0) Затем для каждого исходного файла в каталоге очистите (т. Е. Удалите содержимое, сократите длину) исходный и заголовочный файл, попробуйте выполнить сборку, в случае сбоя верните файлы, в противном случае оставьте их пустыми.

После запуска вернитесь, а затем удалите все очищенные файлы, скомпилируйте и затем удалите все ошибочные #imports.

Я также должен добавить, вам нужно избегать файлов, на которые есть ссылки из файлов .xib или .sdef, и могут быть другие случаев динамического связывания, но он все равно может дать вам хорошее представление о том, что можно удалить.

Тот же метод можно использовать, чтобы увидеть, какие #imports можно удалить - вместо усечения файла удалите каждый #import в файле по очереди и посмотрите, не завершится ли сборка.