Тема перформанса на мобиле очень обширная и за час, конечно, всего не расскажешь, поэтому если у вас возникли вопросы при просмотре подкаста, можете задать их в комментариях к выпуску. Я постараюсь ответить на все!
@@AlexeiKorshun спасибо за вопрос! Я предполагаю, что под джобой перфоманс тестов на МРах вы имеете ввиду сам процесс билда бинарника приложения + билд тестов ну и сам запуск? Тут есть несколько опций. Если мы рассматриваем этап билда и на пайплайне гоняются еще UI тесты, то можно попробовать переиспользовать билд приложения, чтобы не билдить его два раза. Кроме этого есть дополнительная оптимизация, если приложение строится долго, можно внедрить концепцию sample-app'ов (их еще называют example app), которая позволит билдить не все приложение, а только его часть, что значительно ускорит процесс сборки. В таком случае тесты писать придется не на основное приложение, а на вот такие небольшие модули. Они даже будут проходить сильно быстрее тестов из основного модуля приложения. Если мы говорим не про билд, а про сам прогон тестов, то здесь не так много опций. Может помочь уменьшение количества итераций в рамках теста, но она неизбежно увеличит дисперсию и уменьшит стат. значимость распределения значения наблюдаемых метрик на выходе. Для того, чтобы избавиться от этого сайдэффекта нужно увеличивать количество эмуляторов (или девайсов), на которых параллельно запускаются тесты. А вот уже то на сколько увеличивать количество таких эмуляторов целиком и полностью зависит от возможностей инфраструктуры, в которой они размещены. Плюс, нужно учитывать также, что МРов может быть много и в какой-то момент времени только на одни performance-тесты будут зарезервированы все ресурсы инфраструктуры. Есть еще одна киллер-фича - это impact анализ, который позволяет не запускать тесты в случае, если код, через который они проходят не был затронут, но не у всех этот инструмент работает стабильно, поэтому тут могут возникнуть свои сложности. Надеюсь, ответил на ваш вопрос, Алексей.
![ИИ-ассистенты для разработчиков: Николай Пермяков, Nestor [Т-Банк] - Как это работает](http://i.ytimg.com/vi/1XdCOICqjvs/mqdefault.jpg)
![ИИ-ассистенты для разработчиков: Николай Пермяков, Nestor [Т-Банк] — Как это работает](/img/tr.png)
Спасибо за выпуск 😊
Тема перформанса на мобиле очень обширная и за час, конечно, всего не расскажешь, поэтому если у вас возникли вопросы при просмотре подкаста, можете задать их в комментариях к выпуску. Я постараюсь ответить на все!
Даниил, спасибо за подкаст, скажите, как ускорить джобы перфоманс тестов на мрах? спасибо :)
@@AlexeiKorshun спасибо за вопрос!
Я предполагаю, что под джобой перфоманс тестов на МРах вы имеете ввиду сам процесс билда бинарника приложения + билд тестов ну и сам запуск? Тут есть несколько опций.
Если мы рассматриваем этап билда и на пайплайне гоняются еще UI тесты, то можно попробовать переиспользовать билд приложения, чтобы не билдить его два раза. Кроме этого есть дополнительная оптимизация, если приложение строится долго, можно внедрить концепцию sample-app'ов (их еще называют example app), которая позволит билдить не все приложение, а только его часть, что значительно ускорит процесс сборки. В таком случае тесты писать придется не на основное приложение, а на вот такие небольшие модули. Они даже будут проходить сильно быстрее тестов из основного модуля приложения.
Если мы говорим не про билд, а про сам прогон тестов, то здесь не так много опций. Может помочь уменьшение количества итераций в рамках теста, но она неизбежно увеличит дисперсию и уменьшит стат. значимость распределения значения наблюдаемых метрик на выходе. Для того, чтобы избавиться от этого сайдэффекта нужно увеличивать количество эмуляторов (или девайсов), на которых параллельно запускаются тесты. А вот уже то на сколько увеличивать количество таких эмуляторов целиком и полностью зависит от возможностей инфраструктуры, в которой они размещены. Плюс, нужно учитывать также, что МРов может быть много и в какой-то момент времени только на одни performance-тесты будут зарезервированы все ресурсы инфраструктуры.
Есть еще одна киллер-фича - это impact анализ, который позволяет не запускать тесты в случае, если код, через который они проходят не был затронут, но не у всех этот инструмент работает стабильно, поэтому тут могут возникнуть свои сложности.
Надеюсь, ответил на ваш вопрос, Алексей.