"Освоенная технология" не равно "готовый продукт". Надо, чтобы кто-то что-то спроектировал и заказал под 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 и регресс тестирование
"Освоенная технология" не равно "готовый продукт". Надо, чтобы кто-то что-то спроектировал и заказал под 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