Comments 52
Добрый день! На мой взгляд решение хорошее. Трудности могут возникнуть по следующим моментам:
- Другая модель приложений и экранов и их жизненные циклы
- Многопоточная среда
- Отсутствие декларативного UI как стандарта — Jetpack Compose ещё в разработке, пока доминируют императивные подходы
- Статическая типизация может доставлять неудобства первое время
Начать я бы посоветовал с вступления в следующие Телеграм-каналы, где всегда можно задать вопрос:
- Kotlin Start
- Kotlin Community
- Android Developers
- Android Architecture
- Если надумаете использовать MVICore: https://t.me/joinchat/C0b_YlOkm3y_bIEv-z7--g
Далее я бы рекомендовал разобраться с Java в Android, как с языком, так и с виртуальной машиной. Потом Android SDK, Котлин, архитектурные шаблоны (MVI, MVVM, и т.д.).
Место, за ответ! А чем обоснован такой выбор?
Почему не использование общие подходы к архитектуре? Бизнес не страдает от этого?
Ребята, возможно вопрос достаточно холиварный и сложный, но все же, почему в iOS и Android различаются подходы? arkivanov рассказывал, что у вас получилось Android приложение полностью на новую архитектуру перевести и сейчас осталось буквально немного легаси на чистой архитектуре. Что в это время делала iOS часть команды? Почему не шарили экспертизу? Не удалось убедить? Какие аргументы были не использовать MVI в iOS? Ваш подход к MVI и MVVM не особо противоречат другу. Да, и почему в iOS (ссылку на старую статью прислал wiruzx ) самописная реактивщина?
Вопрос, видимо, к bivy, как к Head of Mobile
Изначально платформы у нас были изолированы, ситуация начала меняться 2-3 года назад. К тому времени на Андроиде было несколько итераций экспериментов и получился зоопарк подходов/архитектур с которым было сложно работать, поэтому был активно запущен процесс поиска решения и унификации.
В iOS ситуация сложилась иначе, зоопарк был меньше и ситуация оставалась контролируемой. Плюс на данный момент iOS команда еще смотрит на SwiftUI и Combine, и не хочет попасть в ситуации когда новые архитектурные паттерны придется менять на корню, после того как эти технологии станут стандартом де-юре и де-факто. Мы в целом подумываем над подобным шагом и на iOS, но как всегда чтобы нужно учитывать cost/benefit/long-term-impact)
Исторически так сложилось, что мы использовали разные подходы к архитектуре в разных частях приложения.
У нас был MVC, MVP и MVVM и только относительно недавно мы договорились использовать MVVM повсеместно.
Почему не использование общие подходы к архитектуре?
Я думаю, основная причина в том, что в iOS команде не было MVI энтузиаста, который бы форсил эту тему.
Бизнес не страдает от этого?
Мне не кажется, что бизнес страдает от разных подходов к архитектуре на разных платформах, по крайней мере до тех пор, пока мы не начали шарить UI код между ними.
Да, и почему в iOS самописная реактивщина?
Мы используем MVVM без RX-extensions, по-этому до сих пор нам хватало маленького самописного Observable :)
C приходом Combine, будем потихоньку перебираться на него.
— часто ли приходится прибегать к NDK и в каких ситуациях это приносило заметный выигрыш?
— используете ли для мониторинга/аналитики in-house или сторонние продукты?
- Мы не используем NDK в нашем клиентском коде, нативный код у нас только от сторонних библиотек, таких как WebRTC для видеозвонков или TensorFlow для фото-верификации. В целом, не думаю, что у нас есть места, где NDK могло бы заметно помочь с производительностью, а минусов со стороны поддержки такого кода больше.
- Для мониторинга и аналитики в основном используем in-house тулы: своя система для аналитических событий, сбора перфоманс метрик, своя краш репортинг система. Иногда прибегаем к сторонним продуктам: например, некоторые метрики из Google Play аналитики нельзя получить своими средствами.
Привет, а для WebRTC используете камеру которая внутри самой гугловой либы? Или что-то внешнее? Если ту которая из коробки нет ли с ней проблем?
Из-за того, что у нас очень много gradle-модулей и UI-тестов в них, и все тесты прогоняются для каждого «пулл-реквеста», мы сделали свой форк раннера Marathon. Оригинальная версия этого раннера решает проблемы стабильности прохождения тестов (при тысячах UI-тестов это отдельная боль), собирает очень удобные репорты и даже сохраняет видео прохождения теста. И наш форк позволяет запускать весь набор тестов из всех модулей полностью параллельно друг другу.
Казалось бы, оригинальный марафон тоже умеет запускать тесты одновременно, зачем нам нужен свой форк? Проблема в том, что марафон не запускает тесты из следующего модуля, пока не закончатся все тесты предыдущего модуля. И такая стратегия запуска может оставить десятки эмуляторов без нагрузки, если в модуле очень мало тестов.
Наши iOS-коллеги не используют марафон, так что мы починили это только для gradle-плагина. API нашего марафона тоже изменился, так что без дополнительной работы запустить его на iOS-проектах не получится.
Вот например, таймлайны трёх запусков тестов на двух агентах (по четыре эмулятора на каждом):
А вот так они проходят с нашим форком:
Пока полный прогон занимает приемлемое время на одной машине, но, поскольку количество тестов у нас удваивается каждые полгода, мы рассматриваем вариант масштабирования раннера сразу на несколько серверов с эмуляторами.
Накинуть ПР в марафон не хотите? Добавить флаг конфигурации с реализацией. Или форк ушел слегка дальше чем это изменение?
Какао пробовали?
Kakao рассматривали при выборе библиотек для UI тестирования, но в итоге остановились на библиотеке от Avito. Одна из причин почему не выбрали Kakao — большая вербозность с вложенным DSL синтаксисом.
1. Как давно вы используете подход с дизайн системой? Как много времени прошло с момента когда вы поняли, что она нужна до момента когда устаканились все процессы работы с дизайнерами с использованием дизайн системы?
2. От кого пошел интент на разработку с помощью дизайн системы? Если от разработки, то как дизайн отреагировал, на то, что сейчас им нужно думать еще и про дизайн систему и как получилось их уговорить.
3. Как устроена ваша дизайн система. Есть ли разделение на core часть (где скажем общая палитра сервиса и шрифты) и на платформенные части. Есть ли разделение внутри платформы на какие-то подчасти, например примитивы (тексты, лоадеры, простейшие вьюшки, кнопки) и на ui-компоненты (например сложные карточки)
4. Как построен процесс разработки нового экрана с использованием дизайн системы. То есть именно что и когда вы делаете, как разработка в этом участвует с момента того например как пришла задача на разработку нового экрана до момента когда команда разработки начинает писать код.
5. Как у вас устроен процесс определения что является компонентом дизайн системы а что нет.
6. Есть ли у вас какие-то критерии по которым вы определяете что вот эти две похожие (визуально) вьюшки это должен быть один компонент а вот эти нет. Это делает только разработка или вместе с дизайном, как построен процесс.
7. Какая тулза используется для хранения дизайна и дизайн системы. В ее использовании применяются ли какие-то возможности тулзы для использования дизайн системы (имею ввиду ссылки на компоненты и т.д.)
8. Действительно ли процесс разработки с дизайн системой приносит выгоду в скорости глобально и в быстром изменении компонентов.
9. Как построен процесс, кто и когда сообщает, что в дизайн системе произошли изменения, например какого-то отступа (например есть отступ padding-normal и вот дизайнеры решили, что он не 16 а скажем 24 становится, кто когда и как уведомляет, что он изменился и как дальше построен процесс разработки и проверки)
10. В дизайне где лежит дизайн система как-то помечается, что компонент еще не реализован на в коде приложения.
11. Есть ли в дизайн системе подробная спецификация для каждого компонента (состояния, зависимые отступы, стили компонента например для темной и светлой темы)
12. Используете ли вы в дизайн системе цветовые токены
13. Есть ли у вас отдельные именованные токены для отступов и соответствующие им размерности
14. Есть ли у вас отдельные именованные токены для стиля написания текста и соответствующие им массивы значений
зы: было бы круто посмотреть небольшой пример как используется у вас дизайн система на примере дизайн+код, то есть очень бы хотелось посмотреть небольшой кусок того как хранится дизайн система, что там оформлено и как и как вы в коде интерпретируете дизайн систему.
4. После того как разработан дизайн, дизайнер создает схему (в виде изображения) с разбиением дизайна на компоненты системы. Затем схему проверяет разработчик, сопоставляя компоненты из дизайн системы с тем, что есть в коде. В случае чего, выделяется дополнительное время на доработку/добавление компонента.
5. Если элемент планируется использовать часто (общаемся с продуктами и дизайнерами), мы обсуждаем возможность включить ее в дизайне систему.
6. Тут нет секретов, все основано на общении и здравом смысле. В каждой команде платформ есть “UI Committee” с 2 — 3 разработчиками, которые помимо своих повседневных задач так же отвечают за связь дизайн системы с кодом платформы. Мы обсуждаем с ними и с дизайнерами. Если происходят споры можно пообщаться и с самим лидом дизайн системы.
7. На данный момент система хранится в виде веб сайта.
8. Глобально для большого и долгосрочного проекта — да. Когда есть стандарты, мы меньше думаем что использовать, как писать код, пушим чтобы дизайнеры использовали элементы из дизайн системы и можем избегать дублирования кода, новые разработчики тратят меньше времени что б разобраться в компонентах, так же это помогает и в тестировании habr.com/ru/company/badoo/blog/479970
9. Все относительно просто. Дизайнер сделал изменение -> рассказал об изменениях “UI Committee” платформ -> создали тикет -> доработали.
10. Не помечается, если приходит дизайн с таким компонентом, выделяем время на разработку этого компонента.
11. Есть, ну и конечно, бывает, что сталкиваемся с новыми кейсами и по ходу дела дорабатываем систему.
12. 13. 14. Токены используем, об этом можно подробнее узнать вот здесь habr.com/ru/company/badoo/blog/491948
Ответить на них нам помогла руководитель продуктовой группы Badoo — Люба Вязникова:
- В продукте мы фокусируемся на инструментах, которые помогают пользователям узнать друг друга лучше, чтобы знакомиться и создавать отношения. Лайв был прекрасной частью продукта, но фокусировался (и работал) больше на развлечение, чем на построении отношений между людьми, будь то дружба или свидания.
- Спасибо за фидбэк! Мы регулярно мониторим отзывы пользователей и смотрим на данные по использованию фичей, чтобы не перегружать продукт и пользователский опыт, а фокусироваться только на самых полезных инструментах. Фильтры — однозначно один из главных фокусов на ближайшее время, следите за обновлениями.
- Такой логики в продукте точно нет. Если вы расскажете подробнее, возможно, станет понятно, в чем проблема.
Дальше в работу вступает специальная команда MAPI, которая разрабатывает протокол общения между клиентом и сервером, описывает, как должен вести себя клиент в той или иной ситуации. Затем это проходит ревью у команд, которые будут все реализовывать. Если нужен дизайн, то дизайнер делает специальный тикет с описанием, где указано, какие компоненты из дизайн-системы нужно использовать, и какие токены для них. Это тоже проходит ревью у разработчиков.
Коммуникация, наверное, как у всех: почта, чат, трекер задач. В былые времена еще можно было подойти и обсудить что-то за чашкой чая :)
Про IT-инфраструктуру: есть разные команды которые отвечают за релиз, внутренние сервисы, тестовое окружение и так далее. Все процессы стараемся автоматизировать.
С инструментами все более-менее стандартно, разве что есть разные сервисы мониторинга, нотификации в чат, автоматизированные релизы мобильных приложений(можно прочитать тут habr.com/ru/company/badoo/blog/509238), remote builds для Android разработчиков.
По моему мнению, в процессе миграции на Kotlin нет ничего сложного. Kotlin и Java могут существовать одновременно в одном проекте, т. е. нет необходимости переписывать весь код, чтобы начать использовать Kotlin. Разве что некоторые вызовы Kotlin кода из Java могут выглядеть некрасиво, и возможно некоторое увеличение времени сборки. Мы просто стали писать новые фичи на Kotlin, оставив старый код на Java. Со временем старый код подвергается рефакторингу и переписывается уже на Kotlin.
Привет, читала про MVICore, насколько я поняла, вся бизнес-логика инкапсулирована в Feature, и они взаимодействуют друг с другом (а так же их может быть несколько на экран). Хотелось бы увидеть более advanced примеры кода, чем sample у вас в репозитории на гитхабе :) ну или хотя бы на пальцах узнать как конкретно взаимодействуют две фичи на абстрактном примере.
В данный момент мы используем компоненты (RIBs), у которых есть чёткий контракт взаимодействия, внутри которых находится фича, которая содержит нужную бизнес логику.
Я распишу на примере такого компонента, где есть коммуникация между рибами.
1. Компонент, который позволяет выбрать элемент из списка и сообщить о выбранном элементе родителю.
2. Компонент, который отображает ввод номера телефона вместе со страной (с возможностью сменить страну на другую)
3. Компонент, который связывает эти 2. Сообщает о том, что 2ой хочет выбрать элемент, возвращает выбранный элемент из 1ого компонента 2ому.
Мы можем заменить рибы на фрагменты и добьёмся того же.
Допустим у вас на экране одновременно отображаются 2 фрагмента, которые позволяют выбрать страну на первом фрагменте, и она отобразится на 2ом фрагменте. В таком случае у нас есть 2 независимые ничего не знающие друг о друге фичи (которые живут внутри фрагментов) и некий родитель, который их связывает между собой.
Есть планы отказаться от нативной разработки и перейти на кросс-платформенные фреймворки типа flutter?
Какие вопросы задаете на собеседованиях мидлам? :)
Для анализа производительности мы сделали opensource-проект Jinba. Если коротко, этот инструмент позволяет размечать в коде начало и конец события, и затем во время выполнения измеряет продолжительность этого события. По этим данным строятся статистические графики, на которых заметно улучшение или ухудшение производительности. Подробнее можно посмотреть в нашем докладе или в этих слайдах.
Планов отказываться от нативной разработки у нас нет. Но мы с интересом исследуем возможность использования Kotlin Multiplatform. Про это у нас уже есть несколько статей (например, Архитектурный шаблон MVI в Kotlin Multiplatform, часть 1).
А по поводу вопросов на собеседовании — лучше один раз увидеть, чем сто раз услышать.
Хей. Мы с коллегами ранее тестировали машинное обучение на вашем приложении. Скажите, те несколько человек, которые посещают аккаунт в момент его создания — они боты или это просто в бизнес-логике зашито? Если мне и коллегам показалось — скажите, мы поймем ;)
У нас нет ботов в продуктах и мы не создаем искусственных пользователей. Совершенно непонятно, зачем это вообще можно было бы делать — в Badoo почти полмиллиарда зарегистрированных пользователей и несколько десятков миллионов активной месячной аудитории. Все люди, с которыми взаимодействуют наши пользователи, — это реальные люди.
Это все в теории или у вас есть опыт в запуске таких приложений/вебсайтов?
Подскажите, а как справляетесь с начальным состоянием в фичах mvicore, чтобы оно не порождало дальше события по цепочке связей?
Т. е. Грузится экран, инициализируются фтчи и начинабтся ненужные инит состояния.
1. Как у вас происходит процесс релиза? Используете какие-то системы или передаёте apk через флешку?)
2. Как быстро происходит внедрение новых инструментов google? Уже используете, например, data binding или navigation components?
- По расписанию создается новая ветка релиза, собирается apk, прогоняются все автоматические тесты. Далее тестировщик делает финальное ручное тестирование. Если блокирующих багов не найдено, то начинается процесс публикации. Публикация происходит постепенно с 1%. Если в дальнейшем будут найдены баги которые необходимо пофиксить в текущем релизе(сломалась целиком часть функционала, увидели большое количество запросов которые спамят сервер), то создаются задачи для их исправления которые будут замержены в текущий релиз, после чего он будет опубликован заново. Процесс публикации автоматизирован и требует минимальных усилий со стороны QA. В качестве CI используется TeamCity, артефакты хранятся удаленно, флешку использовать нет необходимости :) Также есть ежедневная автоматическая публикация beta версий после завершения всех тестов. Про автоматизацию релизов совсем недавно вышла статья.
- Из AndroidX используем не так уж и много: AppCompat, View библиотеки(ConstraintLayout, RecyclerView, и тд), Fragment, Biometric, совсем недавно стали интегрировать Room. Планов по интеграции новых пока нет.
Ask me anything! Задай вопрос Android-команде Badoo