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

1. Wormholy

Исходный код - здесь. Фреймворк для дебага трафика мобильного приложения.

Возможности:

• импортируется без написания кода;

• записывается весь трафик приложения, который использует NSURLSession;

• не нужны SSL сертификаты для анализа трафика HTTPS;

• взаимодействует с внешними библиотеками для работы с сетью, такими как Alamofire и AFNetworking;

Установка фреймворка очень проста - через добавление в Podfile следующей строчки:

pod ‘Wormholy’, :configurations => [‘Debug’]

После этого в терминале в директории с проектом необходимо установить поды из Podfile командой pod install.

Затем запустить ваш проект. Для того чтобы открыть анализатор трафика, нужно потрясти телефон (в симуляторе это делается или сочетанием клавиш control-command-z, или выбором вкладки Device -> Shake). После этого открывается окно со списком запросов, которые ваше приложение успело сделать с момента запуска.

В качестве тестируемого проекта мы используем простое новостное приложение. Приложение взаимодействует с NewsAPI для получения новостей и с Firebase (логин и чтение/запись в БД).

Можно посмотреть детальное описание запроса и ответа от сервера.

Отдельно можно посмотреть тело запроса и ответа в удобочитаемом виде. Есть поиск по JSON.

В целом достаточно удобный инструмент для анализа трафика мобильного приложения.

Из преимуществ здесь простая интеграция в приложение без написания кода, описание запроса и удобное отображение JSON.

Из недостатков - не отображаются запросы через библиотеку KingFisher для загрузки изображений. Вероятно есть проблемы с отображением запросов и других сторонних библиотек, хотя авторы уверяют, что Alamofire и AFNetworking поддерживаются.

2. Netfox

Установить можно несколькими способами: через Swift Package Manager, через Cocoapods, через Carthage или вручную. Все способы подробно описаны в readme. Мы выбрали установку через Cocoapods. Для этого в свой Podfile добавляем строку:

 pod ‘netfox’, :configuration => [‘Debug’]

и установливаем поды через терминал.

Далее необходимо импортировать в проект. Делается это следующим образом. В файле AppDelegate импортируем netfox:

import netfox

и в функцию application с параметром didFinishLaunchingWithOptions вставляем следующий код:

#if DEBUG

NFX.sharedInstance().start()

#endif

На этом импортирование библиотеки завершено и можно запускать приложение. Открытие анализатора запросов происходит аналогично предыдущему фреймворку, а именно через встряхивание смартфона или комбинацией клавиш Control-Command-z в случае работы на симуляторе. Хотя есть возможность кастомизировать по своему усмотрению, и в документации описано как это сделать. После встряхивания открывается список запросов.

Кликнув по запросу, мы получаем подробную информацию, его статус, ответ от сервера.

Также здесь есть возможность отображать тело запроса и ответа в различных форматах (JSON, HTML, XML), или просмотреть изображение, если оно запрашивалось.

Доступна настройка анализатора, просмотр статистики по запросам, объему трафика и т.д.

Подводя итог, можно сказать, что Netfox достаточно мощный и удобный инструмент для анализа трафика. К преимуществам можно отнести более детальное описание запросов, возможность предпросмотра изображений, поддержка разных форматов и сторонних библиотек. К недостаткам, в сравнении с Wormhole, можно отнести необходимость внедрения в код проекта.

3. Dotzu

Ссылка на репозиторий - здесь.

Не рекомендуется к использованию, так как проект не развивается. Поддерживает 9 версию iOS. После ручной адаптации кода под современные версии iOS получилось запустить приложение, однако работало оно на симуляторе с 12 версией iOS. Более поздние версии не поддерживаются. Но даже после запуска по какой-то причине список запросов не отображался, так что можно сделать вывод о невозможности применения этой библиотеки в современной разработке. К тому же в репозитории указано, что владелец заархивировал его, что говорит о том, что проект, к сожалению, мертв.

Не рекомендуется к использованию, так как проект не развивается. Поддерживает 9 версию iOS. После ручной адаптации кода под современные версии iOS получилось запустить приложение, однако работало оно на симуляторе с 12 версией iOS. Более поздние версии не поддерживаются. Но даже после запуска по какой-то причине список запросов не отображался, так что можно сделать вывод о невозможности применения этой библиотеки в современной разработке. К тому же в репозитории указано, что владелец заархивировал его, что говорит о том, что проект, к сожалению, мертв.

4. FLEX

Ссылка на репозиторий - здесь. Очень мощный инструмент для дебаггинга приложения в реалтайме. Описание всех возможностей этой библиотеки - материал для отдельной статьи, поэтому здесь коснемся только вопросов связанных с анализом трафика. Установка подробно описана в документации, мы воспользовались привычным способом - через CocoaPods. Добавляем строку в Podfile:

pod ‘FLEX’, :configuration => [‘Debug’]

и устанавливаем поды. В файл AppDelegate импортируем FLEX и в функцию application() с параметром didFinishLaunchingWithOptions вставляем следующий код:

#if DEBUG

FLEXManager.shared.showExplorer()

#endif

После запуска приложения в симуляторе необходимо нажать f, чтобы вызвать панель инструментов FLEX.

Нажав menu -> Network History мы попадаем в анализатор трафика. Здесь все похоже на предыдущие фреймворки: список запросов, возможность посмотреть детальное описание запроса, отформатированный JSON или изображение.

Функционал, способ импортирования и запуска практически полностью идентичен Netfox. Поэтому если не нужен остальной функционал FLEX, наверное более обоснованно использовать Netfox, поскольку у него функционал четко ограничен сетевым взаимодействием. Однако если для дебаггинга приложения нужен дополнительный функционал, то FLEX - идеальный выбор для этого.

5. PonyDebugger

Ссылка на репозиторий.

Суть работы этого фреймворка несколько отличается от предыдущих. В локальной сети, к которой подключено устройство или на хосте запускается сервер. У сервера есть веб-страница, которая собственно отображает все запросы устройства. Однако нормально запустить сервер на MacOS Big Sur не получилось - способ установки, описанный в документации не работает. Несколько дополнительных способов описаны в Issues к проекту. С их помощью удалось поднять сервер, но не получается зайти на веб страницу. С подобной проблемой сталкиваются многие пользователи, но решения, которое бы «лечило» все проблемы пока не нашлось.Сам фреймворк достаточно давно не обновлялся, возможно проблема связана именно с адаптацией под новые версии MacOS, так как внутри используется Python 2.7, который уже несколько лет официально не поддерживается. Поэтому при попытке использовать данный фреймворк надо иметь ввиду, что из коробки его использовать не получится.

Выводы

Из рассмотренных выше фреймворков сложно выбрать однозначного лидера. Несмотря на весьма похожий функционал, у каждого из них есть свои преимущества и недостатки. Например, Wormehole крайне прост в установке и использовании и не требует непосредственной интеграции в код, однако в сравнении с другими не отображает все запросы и описание самих запросов не такое подробное. В то же время FLEX и Netfox обладают схожими возможностями, но если сфера применения Netfox - это только анализ трафика приложения, то FLEX - это мощный инструмент для дебага всего приложения с возможностью даже менять View приложения в реальном времени. Поэтому стоит выбирать тот или иной фреймворк исходя из потребностей.

Фреймворки с интеграцией в код удобно использовать на этапе разработки приложения для тестирования работы с сетью. В отличии от прокси, для отслеживания трафика нет необходимости устанавливать SSL сертификаты. Но очевидным недостатком является то, что их нельзя использовать для анализа трафика в релизных версиях приложения, поскольку все эти фреймворки работают только в дебаг схемах. Поэтому для прода следует рассматривать инструменты, использующие прокси, которые были описаны в первой части.