Гораздо интереснее было бы рассмотреть, чем он хуже GCD, так как про лучшесть и так из каждой трубы слышно.
Приоритет тасок теперь важен, так как исполняются они не в FIFO, как в GCD. Это может сбить с толку кучу народу, кто всю жизнь писал под GCD/Combine и не трогал треды. Apple на этой важнейшей детали вообще не заострил внимание
Акторы обманчиво похожи на обычный джавный монитор на самом объекте (или, если вы из мира ios, на serial queue по заходу в метод), но на самом деле критическая секция длится лишь до suspend'а. На деле это значит, то любые isolated-методы у акторов надо делать с пониманием, что зайти в метод может много клиентов сразу, но исполняется только один за раз. Это, опять же, контринтуитивно и упоминается Apple лишь вскользь
Таски захватывают свой контекст сильно до конца исполнения, даже если написать [weak self]. В интернете об этом знают полторы статьи - в итоге память течет нещадно (но, к счастью, утечки чаще всего временные). Опять же, контринтуитивно и в разрез с устоявшимся синтаксисом остального языка
Чтобы таски тестировать в юнит тестах, их приходится открывать как private(set), так как свои Executor эппл писать не разрешила. В итоге из каждого объекта торчит лишняя переменная, а тесты ходят по другим потокам даже для возвращения мок-данных, так как нельзя заставить все идти серийно, синхронно на один тред (как с GCD делалось через собственную абстракцию над DispatchQueue).
Короче понял вас - винда старая умеет больше, а весит меньше современного приложения. Согласен с этим. Но из этого не следует, что эти 200мб можно и нужно сделать меньше.
Делают разное, но количество делаемого и сложность описания — можно посравнивать.
Ну если для вас картографический движок это "нарисовать картинку", то сложность доказывать бесполезно.
То что справа налево или иероглифы требовали отдельных модулей?
Например да. Да просто чтобы ОС была на русском, надо было покупать специальную версию. Или то, что в Юникод винда 95 почти не умела. Если играть в дум, это конечно, незаметно - хотя что сложного, "нарисовать буковки"
легаси ведет к росту кодовой базы
Легаси - это как раз винда старая, под капотом оказывающаяся досом. В 2гисе же назовите хоть одну вещь, которая легаси и которую надо переписать, чтобы код уменьшился?
Хуже потому, что мы добавляем к 2гису еще Х мегабайт нативного кода
Кроссплатформенный UI (на Qt) тестировали около 2014 года. Не взлетело по многим причинам, нативные UI получаются сильно качественнее (даже если не брать в расчет состояние Qt под какой-нибудь iOS, которое плачевное). Какой-то код с UI все равно придется добавить - и тут добавлять Qt не получилось лучше, чем добавлять UIKit, скажем.
а от 170 мегабайт 95 винды убираем дум и дальше нужно как-то объяснить, как карты описать оказывается во столько раз сложнее, чем операционную систему.
Сравнение ОС с приложением некорректное, сравнивать их бессмысленно, они делают разное
Там надо то — СЛУ решить и векторную картинку нарисовать. Причем скорее всего средствами ОС.Против толпы драйверов, рендеренга тех самых картинок как растровых, так и векторных, шрифтов тех же и тд и тп.
"Толпы драйверов"? Да в те времена с каждым девайсом шел драйвер на диске/дискете в комплекте. Ни одна видеокарта бы не завелась без ручной установки драйверов, как пример.
Ещё ОС шла одноязычной - какие там шрифты сложные? В том же 2гисе поставляется ICU, который по функционалу куда сильнее того, что предоставляла одноязычная ОС 90х.
А про СЛУ и "картинку нарисовать" вообще смешно. Так можно любой софт тривиализировать до одного предложения, это неконструктивно.
Меня вообще не удивляет, что там кода больше винды, хоть по логике, хоть по размеру. Кого-то это может не устраивать, но технические решения, которые привели к текущему состоянию, мне неверными не кажутся. 2гис уже 24 года в разработке сотнями людей, а винду 98 написали меньше ста человек за несколько лет (и для пары допрелизов).
Представлять не надо - я выше примерно написал, что там. Если думаете, что код, генерируемый сишными компиляторами в 90х аналогичен по размеру генерируемому из современного С++ по размеру - у меня плохие новости, современный код куда больше по размеру. Не учитывая разницы архитектур даже
Мм, почему хуже? А самое главное - как иначе? Подгружать динамически код нельзя (только через webview, но тогда у вас не приложение, а браузер), а большая часть приложения - код. Предлагаете уменьшать функционал?
2гис не кроссплатформенный - кроссплатформенный только один его кусок, поставляемый с нативными приложениями, чтобы не реализовывать на всех платформах одинаковую логику.
Про винду согласен, ОС действительно выглядят раздутыми, но и ожидания от них выше, чем тогда (как и средний уровень подготовленности пользователя)
там миллиарды строк кода?
Насколько помню, не миллиарды, но миллионы. Напоминаю, что в кроссплатформенной части не только роутинг, а например поиск (думаете в поиске мало кода и всяких индексов/грамматик? Зайдите в утекший Яндекс.поиск, удивитесь). Ещё кроме поиска - 3D-движок, рисующий карту, текст, иконки, объекты, анимации, перелеты на видеокарте (по сути сравнимый с игровым графический движок). Кроме движка - вся общая логика, которую можно вынести (например, работа с избранным, базами, навигатором). Всё это запросто занимает 200 мб, и я даже удивлен, что не больше.
секрет дутости приложений в бездумном импорте либ налево и направо
Помнится, либ в этой части немного и все нужны. Зайдите в либу через IDA Pro, если не верите - кажется самым большим был ICU, но без него никак не нарисовать текст на карте на куче языков Ещё была кажется штука для работы с SVG - предлагаете свою писать? Или LZMA с zlib?
это всё от гугла повелось, который рекомендует в зависимости compat либы цеплять которые весят так что телефоны старые помирают от одних только цифр их размера
В C++ кроссплатформенной части compat-либ и нет, они же для нативного андроида. А андроид 2гис почти весь на QT, так что и там я думаю их немного. К обратной совместимости 2гис не прикопаешься, до недавнего времени выходили базы для WinPhone (который перестали обновлять годы назад), а для десктопной версии, или, например, для iOS 8, они до сих пор выходят. Для такой обратной совместимости и нужно много хорошего кода для работы с базами - возможно, винда поэтому и толстая такая (чтобы бодро запускать ПО ещё с Windows 3.11)
Хотите сказать, в фотошопе и думе логика сложнее современного кроссплатформенного картографического приложения?
Рендеринг карт (OpenGL ES + Metal), текстовый поиск на нескольких языках, алгоритмы построения маршрутов между странами на автомобиле и внутри городов пешком, на велосипеде и автомобиле с эвристиками и оптимизациями, пошаговая навигация с голосовыми подсказками, эффективная работа с базами (огромными, а не wadами или картинками на несколько мегабайт) и возможность обновлять все эти вещи по частям с сохранением совместимости версий, и ещё все это офлайн и онлайн. Думы и фотошопы девяностых такого не умели. Откройте 2гис 1.0 под винду 99 года - он тоже весил очень мало, но и не умел ничего из перечисленного выше.
Вопрос — сколько лишнего места суммарно заняла эта пара приложений на телефонах населения?
Отвечу - скорее всего не очень много. Или вы считаете, что если это библиотеки, то они не нужны? Каждой компании писать свои карты?
Согласен с тем, что оптимизации уделено недостаточно внимания (смотрим размер СБОЛ и сравниваем с ВТБ). Но иногда размер кода приложения действительно велик, так как оно сложнее, чем кажется. Если интересно, почитайте статью о том, как Uber пытались ужать в 150 Мб, хотя приложение, казалось бы, простое.
То, что кроссплатформенная часть 2ГИС влезает в 200 мб - достижение, потому что оффлайновой логики там экстремально много (источник: я там работал).
Теперь мы знаем, что для сборки iOS-приложения в алиэкспресс.россия, требуется:
Java
Ruby
Python
Kotlin
Причём приложение в основном нативное, не какая-то дикая кроссплатформа. Кажется, что если убрать лишнее (оставить, скажем Ruby для скриптов), то и команда Mobile Speed будет не нужна.
Как - объяснили, например, комментарием выше, или почитайте соседние ветки, механизмов очень много, самый простой - проверить размер MTU.
Зачем - например, чтобы не попасть на нарушение законодательства или контрактов с зарубежными правообладателями. Так или иначе ограничивают контент по региону все стриминги.
Смотреть в оригинале можно и на Кинопоиске если что, еще и дешевле раз в 10, чем в аналогичных зарубежных сервисах. А если российский контент есть желание посмотреть - то тут вообще вариантов немного и зарубежные сервисы особо не помогут.
Причём тут "первая необходимость" не понял, в треде вроде бы обсуждали для чего хватит VPN безотносительно необходимости.
Вы статью-то читали? Так же и сделали, добавили одно поле. Просто за счёт того, что 2гис работает и в офлайне, и в онлайне, мало просто поменять бэк, фронт и мобильные клиенты, нужны ещё исправления в формате данных и паковщике пакетов данных, с учетом обратной совместимости и зоопарка версий приложения, платформ и данных. А потом как-то уметь протестировать эти компоненты вместе. А потом ещё нужно проследить, что релизы всех этих вещей (которые все в разное время) ничего не сломали, ни на новых клиентах, ни на старых, ни в офлайне, ни в онлайне, и чтобы не менять серьезно версию пакетов, с возможным заделом на прямую совместимость в будущем (иначе придётся раздавать кучу версий тяжелых пакетов, несовместимых между собой и потратить состояние на серверы)
Я правильно понял, что у вас разные модули iOS-приложения лежат в разных git-репозиториях?
Если да, то плюсов у этого решения не то что бы много, зато неудобств столько, что борьба с ними занимает полстатьи. В монорепозитории как минимум можно было бы не думать о версионировании, а Cocoapods бы завёлся с первой попытки.
Однако, тут возникают свои проблемы - Cocoapods (как и SPM и даже Carthage) плохо умеет в кэширование модулей между машинами разработчиков, поэтому начиная с определенного размера приложения и команды они перестают скейлится (из-за времени чистой сборки). Я видел, что в такой ситуации обычно переходят на более высокоуровневые сборочные системы (Buck, Bazel, Tuist). Не рассматривали такие?
1 Согласен, но разве аккаунт Apple для разработчиков оплачивается в евро? Но вообще да, могут отрубить и вообще все.
2 и 3 Да, можно пойти разгребать. Я понимаю, что статья не про это - поэтому и написал комментарий, чтобы мнение было у рассматривающих более целостное, а не только на основе того, что в статье.
Гораздо интереснее было бы рассмотреть, чем он хуже GCD, так как про лучшесть и так из каждой трубы слышно.
Приоритет тасок теперь важен, так как исполняются они не в FIFO, как в GCD. Это может сбить с толку кучу народу, кто всю жизнь писал под GCD/Combine и не трогал треды. Apple на этой важнейшей детали вообще не заострил внимание
Акторы обманчиво похожи на обычный джавный монитор на самом объекте (или, если вы из мира ios, на serial queue по заходу в метод), но на самом деле критическая секция длится лишь до suspend'а. На деле это значит, то любые isolated-методы у акторов надо делать с пониманием, что зайти в метод может много клиентов сразу, но исполняется только один за раз. Это, опять же, контринтуитивно и упоминается Apple лишь вскользь
Таски захватывают свой контекст сильно до конца исполнения, даже если написать [weak self]. В интернете об этом знают полторы статьи - в итоге память течет нещадно (но, к счастью, утечки чаще всего временные). Опять же, контринтуитивно и в разрез с устоявшимся синтаксисом остального языка
Чтобы таски тестировать в юнит тестах, их приходится открывать как private(set), так как свои Executor эппл писать не разрешила. В итоге из каждого объекта торчит лишняя переменная, а тесты ходят по другим потокам даже для возвращения мок-данных, так как нельзя заставить все идти серийно, синхронно на один тред (как с GCD делалось через собственную абстракцию над DispatchQueue).
Короче понял вас - винда старая умеет больше, а весит меньше современного приложения. Согласен с этим. Но из этого не следует, что эти 200мб можно и нужно сделать меньше.
Ну если для вас картографический движок это "нарисовать картинку", то сложность доказывать бесполезно.
Например да. Да просто чтобы ОС была на русском, надо было покупать специальную версию. Или то, что в Юникод винда 95 почти не умела. Если играть в дум, это конечно, незаметно - хотя что сложного, "нарисовать буковки"
Легаси - это как раз винда старая, под капотом оказывающаяся досом. В 2гисе же назовите хоть одну вещь, которая легаси и которую надо переписать, чтобы код уменьшился?
Кроссплатформенный UI (на Qt) тестировали около 2014 года. Не взлетело по многим причинам, нативные UI получаются сильно качественнее (даже если не брать в расчет состояние Qt под какой-нибудь iOS, которое плачевное). Какой-то код с UI все равно придется добавить - и тут добавлять Qt не получилось лучше, чем добавлять UIKit, скажем.
Сравнение ОС с приложением некорректное, сравнивать их бессмысленно, они делают разное
"Толпы драйверов"? Да в те времена с каждым девайсом шел драйвер на диске/дискете в комплекте. Ни одна видеокарта бы не завелась без ручной установки драйверов, как пример.
Ещё ОС шла одноязычной - какие там шрифты сложные? В том же 2гисе поставляется ICU, который по функционалу куда сильнее того, что предоставляла одноязычная ОС 90х.
А про СЛУ и "картинку нарисовать" вообще смешно. Так можно любой софт тривиализировать до одного предложения, это неконструктивно.
Меня вообще не удивляет, что там кода больше винды, хоть по логике, хоть по размеру. Кого-то это может не устраивать, но технические решения, которые привели к текущему состоянию, мне неверными не кажутся. 2гис уже 24 года в разработке сотнями людей, а винду 98 написали меньше ста человек за несколько лет (и для пары допрелизов).
Представлять не надо - я выше примерно написал, что там. Если думаете, что код, генерируемый сишными компиляторами в 90х аналогичен по размеру генерируемому из современного С++ по размеру - у меня плохие новости, современный код куда больше по размеру. Не учитывая разницы архитектур даже
Мм, почему хуже? А самое главное - как иначе? Подгружать динамически код нельзя (только через webview, но тогда у вас не приложение, а браузер), а большая часть приложения - код. Предлагаете уменьшать функционал?
Не очень понял, о чем вы.
2гис не кроссплатформенный - кроссплатформенный только один его кусок, поставляемый с нативными приложениями, чтобы не реализовывать на всех платформах одинаковую логику.
Про винду согласен, ОС действительно выглядят раздутыми, но и ожидания от них выше, чем тогда (как и средний уровень подготовленности пользователя)
Насколько помню, не миллиарды, но миллионы. Напоминаю, что в кроссплатформенной части не только роутинг, а например поиск (думаете в поиске мало кода и всяких индексов/грамматик? Зайдите в утекший Яндекс.поиск, удивитесь). Ещё кроме поиска - 3D-движок, рисующий карту, текст, иконки, объекты, анимации, перелеты на видеокарте (по сути сравнимый с игровым графический движок). Кроме движка - вся общая логика, которую можно вынести (например, работа с избранным, базами, навигатором). Всё это запросто занимает 200 мб, и я даже удивлен, что не больше.
Помнится, либ в этой части немного и все нужны. Зайдите в либу через IDA Pro, если не верите - кажется самым большим был ICU, но без него никак не нарисовать текст на карте на куче языков Ещё была кажется штука для работы с SVG - предлагаете свою писать? Или LZMA с zlib?
В C++ кроссплатформенной части compat-либ и нет, они же для нативного андроида. А андроид 2гис почти весь на QT, так что и там я думаю их немного. К обратной совместимости 2гис не прикопаешься, до недавнего времени выходили базы для WinPhone (который перестали обновлять годы назад), а для десктопной версии, или, например, для iOS 8, они до сих пор выходят. Для такой обратной совместимости и нужно много хорошего кода для работы с базами - возможно, винда поэтому и толстая такая (чтобы бодро запускать ПО ещё с Windows 3.11)
Хотите сказать, в фотошопе и думе логика сложнее современного кроссплатформенного картографического приложения?
Рендеринг карт (OpenGL ES + Metal), текстовый поиск на нескольких языках, алгоритмы построения маршрутов между странами на автомобиле и внутри городов пешком, на велосипеде и автомобиле с эвристиками и оптимизациями, пошаговая навигация с голосовыми подсказками, эффективная работа с базами (огромными, а не wadами или картинками на несколько мегабайт) и возможность обновлять все эти вещи по частям с сохранением совместимости версий, и ещё все это офлайн и онлайн. Думы и фотошопы девяностых такого не умели. Откройте 2гис 1.0 под винду 99 года - он тоже весил очень мало, но и не умел ничего из перечисленного выше.
Отвечу - скорее всего не очень много. Или вы считаете, что если это библиотеки, то они не нужны? Каждой компании писать свои карты?
Согласен с тем, что оптимизации уделено недостаточно внимания (смотрим размер СБОЛ и сравниваем с ВТБ). Но иногда размер кода приложения действительно велик, так как оно сложнее, чем кажется. Если интересно, почитайте статью о том, как Uber пытались ужать в 150 Мб, хотя приложение, казалось бы, простое.
То, что кроссплатформенная часть 2ГИС влезает в 200 мб - достижение, потому что оффлайновой логики там экстремально много (источник: я там работал).
Теперь мы знаем, что для сборки iOS-приложения в алиэкспресс.россия, требуется:
Java
Ruby
Python
Kotlin
Причём приложение в основном нативное, не какая-то дикая кроссплатформа. Кажется, что если убрать лишнее (оставить, скажем Ruby для скриптов), то и команда Mobile Speed будет не нужна.
И как "неотчуждаемо" хранить Kerbal Space Program? Предлагаете пиратки качать?
Не закрыли - смотреть часть контента кинопоиска из-за границы можно, например, советское кино
Как - объяснили, например, комментарием выше, или почитайте соседние ветки, механизмов очень много, самый простой - проверить размер MTU.
Зачем - например, чтобы не попасть на нарушение законодательства или контрактов с зарубежными правообладателями. Так или иначе ограничивают контент по региону все стриминги.
Смотреть в оригинале можно и на Кинопоиске если что, еще и дешевле раз в 10, чем в аналогичных зарубежных сервисах. А если российский контент есть желание посмотреть - то тут вообще вариантов немного и зарубежные сервисы особо не помогут.
Причём тут "первая необходимость" не понял, в треде вроде бы обсуждали для чего хватит VPN безотносительно необходимости.
Недостаточно. Все очевидные (и даже не очень очевидные) попытки посмотреть Кинопоиск через VPN распознаются и блокируются уже несколько месяцев как.
Новосибирск тоже стоит на гранитной плите, но метро построили, просто совсем неглубокое.
Вы статью-то читали? Так же и сделали, добавили одно поле. Просто за счёт того, что 2гис работает и в офлайне, и в онлайне, мало просто поменять бэк, фронт и мобильные клиенты, нужны ещё исправления в формате данных и паковщике пакетов данных, с учетом обратной совместимости и зоопарка версий приложения, платформ и данных. А потом как-то уметь протестировать эти компоненты вместе. А потом ещё нужно проследить, что релизы всех этих вещей (которые все в разное время) ничего не сломали, ни на новых клиентах, ни на старых, ни в офлайне, ни в онлайне, и чтобы не менять серьезно версию пакетов, с возможным заделом на прямую совместимость в будущем (иначе придётся раздавать кучу версий тяжелых пакетов, несовместимых между собой и потратить состояние на серверы)
Вот об этом статья.
Я правильно понял, что у вас разные модули iOS-приложения лежат в разных git-репозиториях?
Если да, то плюсов у этого решения не то что бы много, зато неудобств столько, что борьба с ними занимает полстатьи. В монорепозитории как минимум можно было бы не думать о версионировании, а Cocoapods бы завёлся с первой попытки.
Однако, тут возникают свои проблемы - Cocoapods (как и SPM и даже Carthage) плохо умеет в кэширование модулей между машинами разработчиков, поэтому начиная с определенного размера приложения и команды они перестают скейлится (из-за времени чистой сборки). Я видел, что в такой ситуации обычно переходят на более высокоуровневые сборочные системы (Buck, Bazel, Tuist). Не рассматривали такие?
1 Согласен, но разве аккаунт Apple для разработчиков оплачивается в евро? Но вообще да, могут отрубить и вообще все.
2 и 3 Да, можно пойти разгребать. Я понимаю, что статья не про это - поэтому и написал комментарий, чтобы мнение было у рассматривающих более целостное, а не только на основе того, что в статье.