Мм, почему хуже? А самое главное - как иначе? Подгружать динамически код нельзя (только через 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 Да, можно пойти разгребать. Я понимаю, что статья не про это - поэтому и написал комментарий, чтобы мнение было у рассматривающих более целостное, а не только на основе того, что в статье.
1 Нет, не у любого. Под санкциями подавляющее меньшинство компаний.
2 и 3 - если iOS разработчику плевать на пользовательский опыт приложения, которое он будет разрабатывать, то вряд ли он хороший и ответственный разработчик. Если таких и ищут, чтобы работал и не задавал вопросы (и сам тоже не пользовался), то вопросов нет.
Идеальных решений не бывает, и в статье хотелось бы услышать и про минусы частых релизов. Озвучу те, что вижу сам:
Release notes, как правило, не будут обновлять каждую неделю и переводить на десятки языков. Это требует усилий как редакторов/маркетологов, так и переводчиков. В итоге release notes превращаются во всеми ненавистные "bug fixes and performance improvements". Проверил - у inDriver в английском сторе примерно так и есть)
Частые релизы подталкивают разработчиков к атомарным мелким PRам и фича-флагам для включения фич. В итоге при ревью контекст кода всей задачи в голове имеет только тот, кто ее реализует, а полного ревью от начала до конца одними и теми же людьми не проводится (как минимум это не энфорсится). В результате в главную ветку может попасть что угодно, если разделить это на достаточно малые части). А обилие фича-флагов мешает пониманию, что в какой сборке приложения есть и в каком качестве - в итоге release notes даже если и будут, то будут бесполезны (фичи могут быть под a/b тестами, выключены/включены у части аудитории, перманентно выключены, но быть в коде и т.п.).
Следствие предыдущего - рост бинарника. Когда PR мелкие и ничего не меняют в боевом приложении (из-за фиче-флагов) их психологически легко принять, и код начинает резко расти. У Убера был кейс, когда приложение росло мегабайтами в неделю. Так же из-за этого сложно вычистить что-то из приложения - сложно понять, не используется ли это, не дописано ли ещё, или уже выпилено выключенным фиче-флагом.
Быстрые релизы не позволяют вносить фундаментальные ломающие изменения в процесс сборки без остановки релиз-поезда хотя бы на время. Когда до релиза три недели, можно сломать весь CI/CD и делать с ним что угодно пару недель. С еженедельными релизами сломать его так не получится. Далеко не всегда можно держать две системы параллельно, и недельные релизы проигрывают при важных изменениях (смена сервиса для переводов, смена провайдера удаленных машин, смена самой платформы, например, на self-hosted или обратно)
Да нет, все считают так. В мире приложений почти все ходовые приложения - нативные. Уже даже стартапы сразу пишут нативные приложения, потому что их потом при росте не нужно будет переписывать на нативные (а пользователи и разработчики обязательно попросят). Самые известные примеры - AirBnb (выкинули React Native) и Slack (переписали с Electron целиком).
В мире игр вообще кроссплатформенности почти нет. На моем маке могу запустить только 10% библиотеки Steam. Если "все считают", что кроссплатформенность нужна, то где версия под мак? Или под линукс без Proton?
Безлимитный отпуск - стандартная американская практика. Очень удобная для работодателя - можно не платить неотгуляный отпуск, разрешается 0 отпуска (раз он безлимитный и снизу тоже, то если никто не сходит, штрафа не будет), ну и peer pressure вынуждает сотрудников реже брать и в итоге не ходить (есть исследования на эту тему недавние почитайте).
Почему же, создаёте main.swift и пишете там что угодно, а потом зовёте UIApplicationMain. Делать так, конечно, не надо, но это же вполне возможно без load/initialize, конструкторов динамических либ и прочей изотерики. При этом создаваемый контейнер может быть и не синглтоном, а инициализировать свои поля может и лениво. А сделать контейнер, не являющийся god object, ещё надо постараться - это для подавляющего числа приложений (даже сложных) просто непрактично.
Мм, почему хуже? А самое главное - как иначе? Подгружать динамически код нельзя (только через 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 Да, можно пойти разгребать. Я понимаю, что статья не про это - поэтому и написал комментарий, чтобы мнение было у рассматривающих более целостное, а не только на основе того, что в статье.
1 Нет, не у любого. Под санкциями подавляющее меньшинство компаний.
2 и 3 - если iOS разработчику плевать на пользовательский опыт приложения, которое он будет разрабатывать, то вряд ли он хороший и ответственный разработчик. Если таких и ищут, чтобы работал и не задавал вопросы (и сам тоже не пользовался), то вопросов нет.
Идеальных решений не бывает, и в статье хотелось бы услышать и про минусы частых релизов. Озвучу те, что вижу сам:
Release notes, как правило, не будут обновлять каждую неделю и переводить на десятки языков. Это требует усилий как редакторов/маркетологов, так и переводчиков. В итоге release notes превращаются во всеми ненавистные "bug fixes and performance improvements". Проверил - у inDriver в английском сторе примерно так и есть)
Частые релизы подталкивают разработчиков к атомарным мелким PRам и фича-флагам для включения фич. В итоге при ревью контекст кода всей задачи в голове имеет только тот, кто ее реализует, а полного ревью от начала до конца одними и теми же людьми не проводится (как минимум это не энфорсится). В результате в главную ветку может попасть что угодно, если разделить это на достаточно малые части). А обилие фича-флагов мешает пониманию, что в какой сборке приложения есть и в каком качестве - в итоге release notes даже если и будут, то будут бесполезны (фичи могут быть под a/b тестами, выключены/включены у части аудитории, перманентно выключены, но быть в коде и т.п.).
Следствие предыдущего - рост бинарника. Когда PR мелкие и ничего не меняют в боевом приложении (из-за фиче-флагов) их психологически легко принять, и код начинает резко расти. У Убера был кейс, когда приложение росло мегабайтами в неделю. Так же из-за этого сложно вычистить что-то из приложения - сложно понять, не используется ли это, не дописано ли ещё, или уже выпилено выключенным фиче-флагом.
Быстрые релизы не позволяют вносить фундаментальные ломающие изменения в процесс сборки без остановки релиз-поезда хотя бы на время. Когда до релиза три недели, можно сломать весь CI/CD и делать с ним что угодно пару недель. С еженедельными релизами сломать его так не получится. Далеко не всегда можно держать две системы параллельно, и недельные релизы проигрывают при важных изменениях (смена сервиса для переводов, смена провайдера удаленных машин, смена самой платформы, например, на self-hosted или обратно)
Да нет, все считают так. В мире приложений почти все ходовые приложения - нативные. Уже даже стартапы сразу пишут нативные приложения, потому что их потом при росте не нужно будет переписывать на нативные (а пользователи и разработчики обязательно попросят). Самые известные примеры - AirBnb (выкинули React Native) и Slack (переписали с Electron целиком).
В мире игр вообще кроссплатформенности почти нет. На моем маке могу запустить только 10% библиотеки Steam. Если "все считают", что кроссплатформенность нужна, то где версия под мак? Или под линукс без Proton?
Безлимитный отпуск - стандартная американская практика. Очень удобная для работодателя - можно не платить неотгуляный отпуск, разрешается 0 отпуска (раз он безлимитный и снизу тоже, то если никто не сходит, штрафа не будет), ну и peer pressure вынуждает сотрудников реже брать и в итоге не ходить (есть исследования на эту тему недавние почитайте).
Почему же, создаёте main.swift и пишете там что угодно, а потом зовёте UIApplicationMain. Делать так, конечно, не надо, но это же вполне возможно без load/initialize, конструкторов динамических либ и прочей изотерики. При этом создаваемый контейнер может быть и не синглтоном, а инициализировать свои поля может и лениво. А сделать контейнер, не являющийся god object, ещё надо постараться - это для подавляющего числа приложений (даже сложных) просто непрактично.