Да, я понимаю о чем вы. Вы про профилирование кода, но можно профилировать скорость работы сайта. Вещи это разные и обращать нужно на абстракции разного уровня: при профилировании кода на работу функций, загрузку файлов. При профилировании скорости сайта — на время отрисовок, User-Centric метрики, Navigation Timing и так далее, что Lighthouse в принципе и делает. Плюс ещё он подсвечивает узкие места и сам умеет дампать эти 40-50 трейсов и анализировать их на предмет возможных оптимизаций. Профилирование работы сайта можно называть аудитом производительности. Это вопрос терминологии, мне кажется.
Конечно, всех технических подробностей в одной статье не уместить. В этой статье я хотел прежде всего объяснить, зачем нужна культура перформанса в компании, какой профит от неё бизнесу и пользователям. Чуть больше технических деталей, например, про автоматизацию профилирования и поддержание производительности можно узнать из доклада моего коллеги Николая Рябова: youtu.be/u7Ld2AWcB2M
2a. Не могу сказать.
2b. По-видимому, полностью решить можно только отказом от dagger. Практически весь код из корневого модуля вынесен, поэтому компиляция будет быстрой, результат сборки модулей закэширован.
2c. Обо всех фича-модулях.
Выстраивать вертикаль нецелесообразно: команды были организованы как независимые с точки зрения бизнеса, чтобы иметь широкую свободу действий. Фактор ограничения — технологический. Дорого держать бесчисленное число фреймворков в угоду удобству команд. Это влияет на пользователей — рост размера приложения, потенциальная нестабильность различных частей приложения, рост потребления памяти, CPU. Стараемся достигать технических компромиссов как можно раньше на уровне android community по образцу техрадара. Правильным решением видим бюджетирование ресурсов. Для этого нужен широкий мониторинг. Сейчас мы в начале этого пути.
1. Стараемся выделять по принципу микросервисов. Каждый модуль в идеале должен быть самодостаточным: содержать все необходимое в себе и решать некую «бизнес-задачу». К сожалению, этого достичь невозможно, и приходится выносить переиспользуемый код: работа с сетью и базой.
2. Используем единый верхнеуровневый dagger-компонент, в который добавляем субкомпоненты с помощью Subcomponent Builder. Gradle-модули содержат в себе субкомпоненты и модули dagger.
3. Хотим получить большую независимость в поддержке кода. Как правило, gradle-модуль поддерживает небольше число команд (в идеале одна), код более независим.
Ускорение сборки хотим получить за счет кэширования и параллелизации сборки различных модулей. Нагляднее всего это можно посмотреть в отчете от gradle build scan. Мониторим текущее состояние, измеряя время сборки в разных сценариях с gradle-profiler. Проверяем гипотезы в том числе на тестовом проекте, смотрим различные конфигурации модулей.
Вот проблемы, с которыми мы столкнулись.
— Android Studio и gradle требуют больше памяти.
— Sync в IDE идет дольше.
— Ошибки при кэшировании модулей, особенно имеющих annotation processing (kapt).
— Повышение порога входа. Нужно понимать какие модули подключать.
Конечно, всех технических подробностей в одной статье не уместить. В этой статье я хотел прежде всего объяснить, зачем нужна культура перформанса в компании, какой профит от неё бизнесу и пользователям. Чуть больше технических деталей, например, про автоматизацию профилирования и поддержание производительности можно узнать из доклада моего коллеги Николая Рябова: youtu.be/u7Ld2AWcB2M
2b. По-видимому, полностью решить можно только отказом от dagger. Практически весь код из корневого модуля вынесен, поэтому компиляция будет быстрой, результат сборки модулей закэширован.
2c. Обо всех фича-модулях.
2. Используем единый верхнеуровневый dagger-компонент, в который добавляем субкомпоненты с помощью Subcomponent Builder. Gradle-модули содержат в себе субкомпоненты и модули dagger.
3. Хотим получить большую независимость в поддержке кода. Как правило, gradle-модуль поддерживает небольше число команд (в идеале одна), код более независим.
Ускорение сборки хотим получить за счет кэширования и параллелизации сборки различных модулей. Нагляднее всего это можно посмотреть в отчете от gradle build scan. Мониторим текущее состояние, измеряя время сборки в разных сценариях с gradle-profiler. Проверяем гипотезы в том числе на тестовом проекте, смотрим различные конфигурации модулей.
Вот проблемы, с которыми мы столкнулись.
— Android Studio и gradle требуют больше памяти.
— Sync в IDE идет дольше.
— Ошибки при кэшировании модулей, особенно имеющих annotation processing (kapt).
— Повышение порога входа. Нужно понимать какие модули подключать.