Для технической аналитики мы используем своё внутреннее кроссплатформенное решение Gelato. Сделать своё мы решили из-за того, что у всех существующих систем присутсвуют те или иные ограничения (например, AppCenter не принимает более 60 сообщений об ошибке в минуту, а Crashlytics сохраняет не более восьми отчётов за сессию). Также это позволяет нам реализовывать любые хотелки, от фильтрации по специфичным полям, до улучшенных алгоритмов группировки отчётов.
Для анализа производительности мы сделали opensource-проект Jinba. Если коротко, этот инструмент позволяет размечать в коде начало и конец события, и затем во время выполнения измеряет продолжительность этого события. По этим данным строятся статистические графики, на которых заметно улучшение или ухудшение производительности. Подробнее можно посмотреть в нашем докладе или в этих слайдах.
Планов отказываться от нативной разработки у нас нет. Но мы с интересом исследуем возможность использования Kotlin Multiplatform. Про это у нас уже есть несколько статей (например, Архитектурный шаблон MVI в Kotlin Multiplatform, часть 1).
А по поводу вопросов на собеседовании — лучше один раз увидеть, чем сто раз услышать.
Из-за того, что у нас очень много gradle-модулей и UI-тестов в них, и все тесты прогоняются для каждого «пулл-реквеста», мы сделали свой форк раннера Marathon. Оригинальная версия этого раннера решает проблемы стабильности прохождения тестов (при тысячах UI-тестов это отдельная боль), собирает очень удобные репорты и даже сохраняет видео прохождения теста. И наш форк позволяет запускать весь набор тестов из всех модулей полностью параллельно друг другу.
Казалось бы, оригинальный марафон тоже умеет запускать тесты одновременно, зачем нам нужен свой форк? Проблема в том, что марафон не запускает тесты из следующего модуля, пока не закончатся все тесты предыдущего модуля. И такая стратегия запуска может оставить десятки эмуляторов без нагрузки, если в модуле очень мало тестов.
Наши iOS-коллеги не используют марафон, так что мы починили это только для gradle-плагина. API нашего марафона тоже изменился, так что без дополнительной работы запустить его на iOS-проектах не получится.
Вот например, таймлайны трёх запусков тестов на двух агентах (по четыре эмулятора на каждом):
А вот так они проходят с нашим форком:
Пока полный прогон занимает приемлемое время на одной машине, но, поскольку количество тестов у нас удваивается каждые полгода, мы рассматриваем вариант масштабирования раннера сразу на несколько серверов с эмуляторами.
Для анализа производительности мы сделали opensource-проект Jinba. Если коротко, этот инструмент позволяет размечать в коде начало и конец события, и затем во время выполнения измеряет продолжительность этого события. По этим данным строятся статистические графики, на которых заметно улучшение или ухудшение производительности. Подробнее можно посмотреть в нашем докладе или в этих слайдах.
Планов отказываться от нативной разработки у нас нет. Но мы с интересом исследуем возможность использования Kotlin Multiplatform. Про это у нас уже есть несколько статей (например, Архитектурный шаблон MVI в Kotlin Multiplatform, часть 1).
А по поводу вопросов на собеседовании — лучше один раз увидеть, чем сто раз услышать.
Из-за того, что у нас очень много gradle-модулей и UI-тестов в них, и все тесты прогоняются для каждого «пулл-реквеста», мы сделали свой форк раннера Marathon. Оригинальная версия этого раннера решает проблемы стабильности прохождения тестов (при тысячах UI-тестов это отдельная боль), собирает очень удобные репорты и даже сохраняет видео прохождения теста. И наш форк позволяет запускать весь набор тестов из всех модулей полностью параллельно друг другу.
Казалось бы, оригинальный марафон тоже умеет запускать тесты одновременно, зачем нам нужен свой форк? Проблема в том, что марафон не запускает тесты из следующего модуля, пока не закончатся все тесты предыдущего модуля. И такая стратегия запуска может оставить десятки эмуляторов без нагрузки, если в модуле очень мало тестов.
Наши iOS-коллеги не используют марафон, так что мы починили это только для gradle-плагина. API нашего марафона тоже изменился, так что без дополнительной работы запустить его на iOS-проектах не получится.
Вот например, таймлайны трёх запусков тестов на двух агентах (по четыре эмулятора на каждом):
А вот так они проходят с нашим форком:
Пока полный прогон занимает приемлемое время на одной машине, но, поскольку количество тестов у нас удваивается каждые полгода, мы рассматриваем вариант масштабирования раннера сразу на несколько серверов с эмуляторами.