Если отбросить из описанных мной в статье плюсов те, что можно реализовать в других подходах, то, пожалуй, мой любимый - то, как выглядит и читается всё это на Pull Request'ах. Даже при беглом взгляде считывается структура и значения.
По поводу дефолтных значений для аргументов - в таком походе их тоже можно задать. Просто у нас в проекте их нет, поэтому я как-то забыл про них написать.
В теории подменить один модуль другим во время сборки мне кажется возможным. Например создать новый BuildType в котором будут зависимости на заглушки, использовать его в AndroidStudio. А вот в сборке debug/release уже подставлять реальные модули. В рамках эксперимента, ради интереса, это можно попробовать провернуть.
Но тогда мы от многомодульности возьмём только один аспект - разделение кода. Может сильно упасть скорость сборки, так как при изменении реализации, у нас вынуждены будут собраться все зависимые модули. А стоимость поддержки будет схожа с использованием api/feature.
Если говорить в контексте данного примера, то логика фичи-1 (feature-1-impl) знает только об интерфейсах фичи-2 (feature-2-api), но не о реализации (feature-2-impl). Соответственно реализацию всё ещё надо подключать к app. Так как на неё связей нет.
Если говорить в целом, то обычно фичи при написании подключают к app, а связи между фичами формируются позже в процессе написания дополнительной логики. Чтобы постоянно не отслеживать есть ли транзитивная связь на фичу, связь между app и фичей остаётся. Иначе пришлось бы переодически подключать/отключать фичу от app. Что не удобно. Gradle самостоятельно справляется с таким и делает это на отлично.
"Освоенная технология" не равно "готовый продукт". Надо, чтобы кто-то что-то спроектировал и заказал под 90 нм, потом это произвели, а затем ещё и протестировали. Должно пройти время, чтобы появились продукты.
В том-то и дело, что наследование тут не поможет, так как надо положить базовый Image в еще какой-то модуль. Просто в отдельном модуле будет лежать уже базовый класс Image вместо конкретного класса.
В моем примере property только добавлялись, но они могут и удалятся. В таком случае придется удалять или делать nullable property в базовом классе. В итоге объекты вообще могут разойтись и у них не будет ни одного общего property. И это нормально. Так как это изначально по логике - абсолютно разные объекты, предназначенные для разных фичей. Просто в определенный момент они были одинаковы. В итоге базовый Image может быть вообще удален, а вот связи между модулями останутся и с ними придется разбираться. Поэтому проблема и бъёт, по большей части, по многомодульным проектам.
Посыл статьи как раз был в том, что не стоило пытаться их логически объединять. Неважно, просто используя один и тот же объект или прибегая к наследованию. То, что объекты выглядят одинаково вовсе не значит, что этот один и тоже же объект.
Не до конца понял про "параллельно рисовать в шаренную память". Тут проблема не только и не столько в рисовании, а в том как потом добавить это на карту. Пробовали например вместо 4 объектов с большими Bitmap добавлять на карту 16-32-64 объекта на карту с Bitmap меньшего размера. Но по производительности получалось хуже.
Да, я в заключении предложил получать координаты с сервера как развитие оптимизации. В бинарном виде действительно может быть наилучшим вариантом.
А по поводу рендеринга тайлов на мобиле - мы пробовали и визуально нам это меньше понравилось, поэтому развивали наш текущий подход Вот пример из экспериментов тайлами https://youtu.be/39_qCY_ij9Y
О переносе в NDK думали вскользь. У нас в приложении кроме этих расчетов особо и нечего выносить в NDK, а ради сотни строк перенастраивать сборку, CI парится с объяснениями работы JNI и С++ тоже не очень хочется. Нам проще эти расчеты тогда на бэкенд утащить
Да, на тайлы смотрели. "В качестве альтернативы мы также рассматривали решение с использованием тайлов. Это отдельный слой карты, состоящий из заранее подготовленных растровых картинок, на которых можно рисовать всё что угодно. Для нас это решение не подошло, так как пришлось бы отдельно генерировать изображения для пересечений каждого из 40+ фильтров друг с другом." Поэтому на бэкенде их готовить не очень удобно.
Если говорить про генерацию изображения для тайла уже в приложении, то в итоге качество изображения получалось сильно хуже чем с таким подходом, при одинаковом выделении оперативы под Bitmap'ки. Не знаю получится ли нормально объяснить текстом, но общая суть в том, что может быть виден лишь небольшой уголок тайла, при этом мы должны создать Bitmap под всю его площадь. При этом если попытатся вставить в тайл изображение с высоким разрешением, то при подгрузке тайла случался лаг.
В целом я думаю эти проблемы можно побороть если сильно постараться.
Для нас проблема использования тайлов скорее в том, что при изменении зума они довольно резко и непоследовательно подгружаются самой картой. Выглядит очень похоже как у нас было до оптимизации. Чисто визуально наш подход нам больше понравился.
Рассматривали, но у большинства альтернатив есть проблемы с детализацией в регионах, особенно если город не является областным центром. Тоесть в Москве, Казани, Екатеринбурге все хорошо, а например в Калачинске в Омской области уже могут отсутствовать многие дома, дороги или пятиэтажки отмечены как частные дома. Яндекс.Карты в плане детализации в нашей стране все-таки впереди всех. Поэтому пытались "притереться" именно к ним
Спасибо, очень интересная статья. Можете чуть поподробнее про “Импакт анализ” рассказать? Есть идея определять список изменившихся модулей и передавать его с дополнительным описанием тестировщикам, чтобы сократить время на ручное smoke и регресс тестирование
Если отбросить из описанных мной в статье плюсов те, что можно реализовать в других подходах, то, пожалуй, мой любимый - то, как выглядит и читается всё это на Pull Request'ах. Даже при беглом взгляде считывается структура и значения.
По поводу дефолтных значений для аргументов - в таком походе их тоже можно задать. Просто у нас в проекте их нет, поэтому я как-то забыл про них написать.
В теории подменить один модуль другим во время сборки мне кажется возможным. Например создать новый BuildType в котором будут зависимости на заглушки, использовать его в AndroidStudio. А вот в сборке debug/release уже подставлять реальные модули. В рамках эксперимента, ради интереса, это можно попробовать провернуть.
Но тогда мы от многомодульности возьмём только один аспект - разделение кода. Может сильно упасть скорость сборки, так как при изменении реализации, у нас вынуждены будут собраться все зависимые модули. А стоимость поддержки будет схожа с использованием api/feature.
Но это всё весьма теоритические рассуждения)
Если говорить в контексте данного примера, то логика фичи-1 (feature-1-impl) знает только об интерфейсах фичи-2 (feature-2-api), но не о реализации (feature-2-impl). Соответственно реализацию всё ещё надо подключать к app. Так как на неё связей нет.
Если говорить в целом, то обычно фичи при написании подключают к app, а связи между фичами формируются позже в процессе написания дополнительной логики. Чтобы постоянно не отслеживать есть ли транзитивная связь на фичу, связь между app и фичей остаётся. Иначе пришлось бы переодически подключать/отключать фичу от app. Что не удобно. Gradle самостоятельно справляется с таким и делает это на отлично.
Есть инструменты:
https://github.com/savvasdalkitsis/module-dependency-graph
https://github.com/ivancarras/graphfity
https://github.com/JakeWharton/SdkSearch/blob/master/gradle/projectDependencyGraph.gradle
Но, честно говоря, первые пару раз на их результат посмотреть весело, а вот когда количество модулей переваливает за 50, то уже слишком много информации.
"Освоенная технология" не равно "готовый продукт". Надо, чтобы кто-то что-то спроектировал и заказал под 90 нм, потом это произвели, а затем ещё и протестировали. Должно пройти время, чтобы появились продукты.
Как пример, Samsung заявил, что освоил 5 нм в апреле 2019
https://www.cnews.ru/news/top/2019-04-16_samsung_osvoila_proizvodstvo_5_nm_protsessorov
А первый процессор на 5 нм представили в ноябре 2020
https://en.wikipedia.org/wiki/Exynos#Exynos_1000_series
https://habr.com/ru/company/selectel/blog/528372/
Прошло полтора года.
В случае с Микрон чипы более простые, чем навороченный процессор топового смартфона, но вероятно ещё полгода-год до первого продукта.
В том-то и дело, что наследование тут не поможет, так как надо положить базовый Image в еще какой-то модуль. Просто в отдельном модуле будет лежать уже базовый класс Image вместо конкретного класса.
В моем примере property только добавлялись, но они могут и удалятся. В таком случае придется удалять или делать nullable property в базовом классе. В итоге объекты вообще могут разойтись и у них не будет ни одного общего property. И это нормально. Так как это изначально по логике - абсолютно разные объекты, предназначенные для разных фичей. Просто в определенный момент они были одинаковы. В итоге базовый Image может быть вообще удален, а вот связи между модулями останутся и с ними придется разбираться. Поэтому проблема и бъёт, по большей части, по многомодульным проектам.
Посыл статьи как раз был в том, что не стоило пытаться их логически объединять. Неважно, просто используя один и тот же объект или прибегая к наследованию. То, что объекты выглядят одинаково вовсе не значит, что этот один и тоже же объект.
Добрый день. Это просто допущение.
У Яндекс.Карты есть возможность добавлять свои слои, но там весьма ограниченный набор функций и к сожалению возможности работать с OpenGL напрямую там нет.
https://yandex.ru/dev/maps/mapkit/doc/android-ref/full/com/yandex/mapkit/layers/package-summary.html
В целом бы конечно свой слой с OpenGL по сути решил бы многие проблемы)
Не до конца понял про "параллельно рисовать в шаренную память". Тут проблема не только и не столько в рисовании, а в том как потом добавить это на карту.
Пробовали например вместо 4 объектов с большими Bitmap добавлять на карту 16-32-64 объекта на карту с Bitmap меньшего размера. Но по производительности получалось хуже.
Да, я в заключении предложил получать координаты с сервера как развитие оптимизации. В бинарном виде действительно может быть наилучшим вариантом.
А по поводу рендеринга тайлов на мобиле - мы пробовали и визуально нам это меньше понравилось, поэтому развивали наш текущий подход
Вот пример из экспериментов тайлами
https://youtu.be/39_qCY_ij9Y
Тут на самом деле очень много способов как сделать лучше)
На вебе у нас, насколько мне известно, используется кластеризация, а не "одно объявление - одна точка".
О переносе в NDK думали вскользь. У нас в приложении кроме этих расчетов особо и нечего выносить в NDK, а ради сотни строк перенастраивать сборку, CI парится с объяснениями работы JNI и С++ тоже не очень хочется. Нам проще эти расчеты тогда на бэкенд утащить
Да, на тайлы смотрели.
"В качестве альтернативы мы также рассматривали решение с использованием тайлов. Это отдельный слой карты, состоящий из заранее подготовленных растровых картинок, на которых можно рисовать всё что угодно. Для нас это решение не подошло, так как пришлось бы отдельно генерировать изображения для пересечений каждого из 40+ фильтров друг с другом."
Поэтому на бэкенде их готовить не очень удобно.
Если говорить про генерацию изображения для тайла уже в приложении, то в итоге качество изображения получалось сильно хуже чем с таким подходом, при одинаковом выделении оперативы под Bitmap'ки.
Не знаю получится ли нормально объяснить текстом, но общая суть в том, что может быть виден лишь небольшой уголок тайла, при этом мы должны создать Bitmap под всю его площадь. При этом если попытатся вставить в тайл изображение с высоким разрешением, то при подгрузке тайла случался лаг.
В целом я думаю эти проблемы можно побороть если сильно постараться.
Для нас проблема использования тайлов скорее в том, что при изменении зума они довольно резко и непоследовательно подгружаются самой картой. Выглядит очень похоже как у нас было до оптимизации. Чисто визуально наш подход нам больше понравился.
Рассматривали, но у большинства альтернатив есть проблемы с детализацией в регионах, особенно если город не является областным центром. Тоесть в Москве, Казани, Екатеринбурге все хорошо, а например в Калачинске в Омской области уже могут отсутствовать многие дома, дороги или пятиэтажки отмечены как частные дома.
Яндекс.Карты в плане детализации в нашей стране все-таки впереди всех. Поэтому пытались "притереться" именно к ним
github.com/LiveTyping/u2020-mvp