Открыть список
Как стать автором
Обновить

Комментарии 45

Затем к власти пришёл Трамп (это случилось примерно через три месяца после выпуска нового приложения)
отдельно от контекста звучит как фраза из Пелевина!

Лимит в 200мб. Звучит жутко. Я как то увидел, что приложение по аренде самокатов 47мб, отменил установку, внутренне понимаю, что сейчас это не критично, но как старый дед, до сих по считаю каждый килобайт.

Приложение Uber это карта и пара экранов. Как, ну вот как они умудряются раздуть бинарник до 200 Мб?

Вам же написали в статье 92 библиотеки, большая часть по-любому для организации нормальной функциональной парадигмы. К примеру одна RxSwift вам набросить на вентилятор мегабайта 4. если предположить что каждая библиотека весит 500кб вот вам уже пол приложения.

А почему RxSwift такая тяжёлая? Это связано с особенностями архитектуры iOS приложений или с самой библиотекой? Просто, скажем, RxJS весит 45.6kB (gzip). RxSwift в несколько десятков сложнее? Или это больше сказывается специфика swift?


P.S. я ни в коем случае не троллю, просто пытаюсь понять, откуда такие размеры в бинарных приложениях.

А можно в расчетах потребляемых ресурсов отталкиваться от Permissions для этого приложения.
И заодно посмотреть на кеш, доходящий до 1 ГБ.
Внутри IPA файла можно найти такой список бандлов с локализациями. Похоже Uber приложение состоит из кучи разных модулей (разные способы оплаты, всякие модули для водителей от загрузки документов до верификации по selfi и т.п.) и они вполне могут привести к бинарнику весом в 132М (сейчас он столько весит).

Странно что столкнувшись с описанными в статье проблемами и имея такое модульное приложение они не разделили его на приложения для водителей и пассажиров (причем отдельное приложение для водителей у них есть, но в статье про это не сказано). Ну или как минимум не отключили часть модулей (GenderIdentity-Localizations-Helix.bundle или EatsTutorial-Localizations-Helix.bundle например точно нужны? :) )

Действительно остается загадкой, зачем потенциальным пользователям, мерзнущим на морозе без Wi-Fi сети, ждать загрузки дополнительных 100МБ верификации по селфи для водителей?

Помню 5 лет назад в аппке Фейсбука было 18000 классов: quellish.tumblr.com/post/126712999812/how-on-earth-the-facebook-ios-application-is-so

А потому, что если у тебя тысячи программистов — у тебя не может не быть десятков тысяч классов. Им же всем надо что-то писать.

Это все объясняет, спасибо.

Понятно, спасибо. Т.е. это всё таки не включает в себя функциональность для самих таксистов, их бухгалтеров и прочих связанных людей, как предположили выше. Это только пользовательская функциональность. Просто все возможные случаи для любого региона и все возможные AB-тесты, и все… {подставить что угодно} для {что-угодно} грузят все до единого пользователи системы.


Видимо Apple store (возможно и Google Play тоже) не предоставляет удобных инструментов, организовать всё иначе. А может просто рассчёт на то, что сегодня ты берёшь Uber в Лондоне и платишь одной кредиткой, а завтра в Камбодже, и платишь какой-нибудь местной системой. И всё это без дозагрузки кода.


Всё или ничего. Сразу.

Я так и не понял какие преимущества дал переход на Swift кроме как многомиллионных убытков и головной боли для руководства и разработчиков?
Архитектурную последовательность же. Правда, непонятно, в чем она конкретно выразилась? В костылях с компилятором, линтером и игрой в кошки-мышки с Apple?

Написано же: "Были потрачены миллионы долларов, точную сумму назвать не могу, но больше миллиона долларов", "Начальник сказал мне, что если отменить проект, то ему придётся собирать вещи, и его начальнику тоже, и так вплоть до вице-президента". Люди работали, осваивали бюджеты, в конце получили вечеринку (и наверняка премию).

Какие-то начальники получили повышение. Вот главное преимущество.
Я так понял, внутриполитическая логика была такая: партия / движ переписать приложения с нуля заполучило мощного союзника — отдел iOS — но при условии того, что переписывание для iOS будет на Swift. Сюжетная линия, что Android-приложение тоже переписывалось с нуля, провисла, поскольку автор не в отделе Android работал. Далее, предполагаемая логика отдела iOS: а) рано или позно переходить на Swift надо, почему не воспользоваться моментом; б) Swift — современный модный хайповый язык, приобретаемые навыки перспективны, возможности привлечения молодых программистов лучше.

Кстати руководству пункты а) и б) могут быть вполне понятны, они головную боль перетерпят.
Выкинули старый код на обж-с. Это само по себе дорогого стоит. Обычная история: 5 лет назад кто-то принял какое-то сомнительное решение, которое, возможно, тогда выглядело хорошим, поверх легло 20 слоёв кода, прошло время, решение уже не является хорошим, но вытянуть его из-под всех этих слоёв нельзя.

В общем-то, переписывание с нуля на обж-с тоже могло дать такой же эффект, но только если запретить таскать куски из старой кодовой базы. А как же ты это сделаешь?
А на этом можно посмотреть и с другой стороны. Вот ищите вы работу у вас есть на выбор две кампании занимающиеся одним и тем же примерно. Но в одной старый быстрый лапшекод на Objective-C, а в другой причёсанная архитектура на Swift. Как вы думаете что выберет среднестатистический соискатель?
Я думаю что в соискателя не такого большого выбора куда идти.

Вопрос iOS разработчикам: почему речь идёт о таких больших размерах? 150 MiB это же огромный размер для приложения с картой и парой десятков экранов. Условная windows 95 (129MB) целиком помещалась в этот размер. А ведь это целая оконная ОС.


Я явно чего-то не понимаю. В Swift ужасно работает dead code elimination? Или для каждого метода создаётся пара десятков имплементаций и все попадают в бинарник?


Ещё не совсем понятно почему в середине автор пишет, что увеличение размера катастрофически сказалось на доходах, но потом радуется, что Apple подняла лимиты до 200 MiB. Т.е. с тем, что пользователи не всегда могут скачать 150 MiB "здесь и сейчас" просто смирились?


Причём я ещё понимаю, когда с подобными проблемами сталкиваются, при написании действительно больших и сложных приложений. Но Uber скорее относится к приложениям средней сложности. Мне кажется действительно сложные задачи решает их Backend команда.

Там не 10 и не 20 экранов, там тысячи. Убер это приложение, которое работает в огромном количестве стран со своей спецификой, только это стоит огромного количества дополнительного кода, который обычный пользователь никогда не увидит. Не говоря уже от всякой телеметрии и прочее прочее для аналитики.
Не говоря уже от всякой телеметрии и прочее прочее для аналитики.

Бинарник программы управления современного спутника где куча телеметрии для анализа весит ~ 1 Мб

Файл с переводом текстовый — я с трудом представляю что текста в приложении наберется больше, чем на 1 Мб.
Т.е. телеметрия и фишки с переводом с трудом тянет на 2 Мб. Откуда 100 мб?
Вы не поверите, но с программами ещё меньшего размера на луну летали. Но вот не зная всей кухни, мы можем спекулировать сколько угодно, почему и как так много или мало. Из моей практики порой внешне кажущиеся простые сервисы, очень сложные и громоздкие внутри. Где-то по недосмотру, где-то по необходимости, где-то потому, что так быстре и так далее и тому подобное.

Ну и я не сказал, что там только одна телеметрия, я сказал, что там тысячи экранов разных, а телеметрия в довесок.
Там не 10 и не 20 экранов, там тысячи.

Тогда почему они не сделают 2 Uber-а: там где 1000 экранов (вероятно для самих водителей, таксопарков, бухгалтеров и пр.), и там где 30 экранов (для всех остальных)? Эта какая-то очень странная архитектура.

Возможно. Точно не скажу, т.к. надо поэкранно сравнивать, чтобы понять — они просто выпилили лишнее, или ещё и по максимуму урезали нужное. BTW:


This app is incompatible with all of your devices.

Очень странно. У меня там обычно список из 3-4 устройств — и все мимо.

Не знаю почему не сделают, может это выигрыша не даёт большого. Но помимо водителей, есть ещё много всякого другого. Скидки например, или каки-то дополнительные промо акции. Можно много вилами по воде водить, но очевидно одно, всё далеко не так просто. Где-то базовые технологии подводят, где-то не оптимально спроектирована система, где-то просто очень много всего такого, чего мы не знаем.
Потому что эппл считает себя умнее пользователей и если есть лимит на максимальный размер приложения по скачиванию через сотовую сеть, то кнопки «похер качаем» — нет.

Точно не вспомню когда появилась, но в России есть такая кнопка. iPhone предупреждает что файл больше 150МБ и на выбор 2 кнопки: «Всё равно скачать», «Скачать позже по Wi-Fi».

Вроде эта кнопка появилась с iOS 13?

Установил Firefox на трубку. 63 MiB. Едва ли тут дело в том, что Firefox написан не на Swift :)

Насколько я знаю, раньше все браузеры на iOS были лишь оболочками над единственным разрешенным движком — Safari WebKit. Поэтому столь «малый» размер неудивителен. Впрочем, возможно, с того времени что-то изменилось?

Но у меня Android. Так что малый размер — это весь браузер. Не Webkit

Это да. Но как уже здесь заметили, раньше в 100 MB могли всунуть довольно большую операционную систему. Это только говорит о том, что в наше время удобство разработки и использование сторонних библиотек более выгодно, чем если делать все «с чистого листа».
Для себя я этот парадокс когда-то сформировал так: для многих компаний докупить доп. планки памяти на серверах дешевле, чем оплачивать месяц работы разработчиков, чтобы оптимизировать программу.

Я могу ошибаться, но мне кажется, что в Uber просто не хватает грамотных архитекторов.


Вспоминается история Discord, которые спустя много лет, решили оптимизировать своё React Native приложение. И разразились статьёй — что же именно они изменили, что приложение перестало так нещадно тормозить. Оказалось что они просто включили мозг и открыли документацию. Они не знали и\или игнорировали прописные истины. И просто собрали все грабли, какие могли. Хотя казалось бы большой штат разработчиков, большая аудитория, есть деньги. Но… Nobody cares. Тормозит и тормозит.


Пока мы читаем статьи про то, как "0.1с при загрузке страницы отнимает у вас Х% прибыли", крупные игроки на рынке тащат 6 MiB бандлы (привет gmail), и 150 MiB сборки (привет Uber). Похоже, имея лидерство на рынке, можно диктовать свои условия даже конечным потребителям.


В статье это подано как: это не мы плохие, это Swift кривой. Я хоть и не swift разработчик, но думаю, что Swift тут не причём. Неча на зеркало пенять, коли рожа крива.

Некоторое время назад работал на похожем проекте. Т.е. задачу которую вполне по силам сделать 10 людьми делают 100. При чем в этих 100 есть довольно много грамотных людей, но из-за кол-во возникает множество замечательных эффектов, когда принимается какое-нибудь неоптимальное решение, все остальные вместо того чтобы его исправить на корню, исправляют последствия.
Плюс это все дополняется очень слабыми в техническом плане архитекторами, но с отличными soft skill.
Т.е. тут описывается похожая ситуация — у команды была возможность сделать прототип(где как раз надо было бы и продумать все эти моменты). Они его по сути не сделали(это как бы ключевой момент), банально отрапортовав что технология отличная, плюс еще до кучи и остались на своих местах

Не бросайте в меня тухлыми помидорами. Я не являюсь профи в программировании, но кое-что пишу для своих научных нужд довольно часто. Мне иногда кажется, что я со своими убогими навыками могла бы за пару месяцев написать клиентскую часть Убера. Понимаю, что не может такого быть, где я и где та корпорация… Но всё равно не понимаю.

Вполне обычные ощущения, возникающие у большинства разработчиков, пришедших в новый проект (пока не узнает деталей). Иногда эти ощущения даже верные. Это как посмотреть на прохождение квеста — «все же просто», вместо того, чтобы пройти его. Отсюда и появляется такое популярное в кругу разработчиков желание «переписать с нуля». Я такое много раз видел.
Были разговоры, что Netscape потерял рынок браузеров, когда его было решено переписать в пятой версии (как обычно — мотив для этого был).
Также стоит вспомнить главу «Эффект второй системы» из книги «Мифический человеко-месяц» (с ее публикации в 1975 году ничего не изменилось):
Эта вторая система — самая опасная для человека, который ее проектирует. Когда он трудится над своей третьей и более поздними, все экземпляры из его предшествующего опыта будут подтверждать друг друга относительно общих характеристик таких систем, и их различия будут определять те части его опыта, которые являются частными и необобщаемыми.
Общая тенденция — делать дизайн второй системы с большим за- пасом, используя все идеи и излишества, которые были осторожно отклонены в первой. В результате, как говорил Овидий, получается «большая куча».

Нет, я понимаю, что серверная часть Убера очень и очень непростая. Но в клиенте, что такого сложного? Получить и передать на сервер местоположение, обеспечить скроллинг карты, запрашивая нужные тайлы. Жамкнуть и передать две точки "откуда" и "куда", получить стоимость и отображать статус заказа. Где тут 92 библиотеки и 100 Мбайт кода? Ну ок, можно ещё просматривать и редактировать профиль, регистрироваться, туда-сюда авторизация. Но где тут труд десятков высокооплачиваемых и наверняка неглупых программистов в течение, вашу ж мать, чуть ли не 2 лет (в тексте 90 недель)!


Можно ответить: "Ты не понимаешь, это другое". Да, не понимаю.

Согласен, выглядит очень затратно. Я не оправдываю этого, сам участвовал в проектах, неоправданно раздутых и затянутых. Но бывают и оправданно большие и ресурсоемкие проекты.
Просто из любопытства попробовал прикинуть — что требовалось сделать в клиенте (фактически “с нуля”, но используя готовый опыт), посмотрев ролик о клиенте на ютубе.
Здесь примерный список функциональности, видимой клиенту
(формы и опции)
Регистрация
— общая
— телефон
— Фейсбук
— Пароль
— Восстановление пароля
Список платежей с деталями
Список поездок с деталями
Free rides (не знаю что это)
Помощь
— иерархическая структура
— Последняя поездка, Квитанция
— Репорт проблем
Настройки
Форма платежей
— настройка и платёж картами
— Настройка и платёж PayPal
— Настройка и использование rewards, promo,gift
Профиль
— персональный
— Бизнес
— Семейный (платить за них и отслеживать поездки)
— Фавориты
Карта и поездка
— доступные машины вокруг (также отрисовка машин, изменение их положения и статуса)
— История остановок недалеко (?)
— Ввод пунктов посадки высадки
— История пунктов
— Известные места (дом, работа)
— Выбор типа машины (эконом, taxi, SUV и т.д.) с деталями
— Выбор «приватный», «бизнес»,«семейный» (немало логики за этим)
— Вызов машины
— Отмена поездки
— Стоимость поездки
— Детали машины, водителя
— Контакт с водителем — звонок, сообщение, выбор своего номера телефона
— Share status (примерное время прибытия в пункт назначения)
— Разделить с другом оплату
— Построение примерного маршрута
— Отслеживание на карте поездки
— Оплата поездки
— Оценка водителя
— Квитанция

Это только для пассажира — без функций водителя.

Нужно помнить также о нефункциональных требованиях,
например
— Многие эти формы должны работать асинхронно, также информация в них синхронизируется
— изменение внешние — окружение, машина, водитель, поездка
— внутренние — детали профиля, изменение с другого клиента (например клиент на другом телефоне)
— Данные не теряются и синхронизируются при потери сети, кэширование для уменьшения трафика и отзывчивости
— Атрибуты качества. Например — отзывчивость форм в пределах заданного интервала,
— Согласованность дизайна и поведения форм
— Количество сбоев (такое тоже есть) и восстанавливаемость (recovery)
— Юнит-тесты

Все это нужно
— обединять (merge — наработки разных итераций спринтов, разных команд, багфиксы)
— интегрировать — разные компоненты (возможно разных команд) взаимодействуют друг с другом и с сервером
— тестировать (в том числе на различных моделях телефонов и версиях iOS, iPadOS)
— билдить
— деплоить
— исправлять баги
— расширять функциональность
и повторять все циклы снова.

Не забываем о необходимости согласований и коммуникации такого количества команд и разработчиков (а среди них — решение проблемы модели, предложенной братьями Дрейфус). Снова вспомним о книге «Мифический человеко-месяц», и главе «Человеко-месяц» из нее — о том, как количество вовлекаемых в решение задачи человек, влияет на общую производительность в проекте.

Также на все это накладываются ограничения библиотек и их версий (а это хаки и воркэраунды) — просто “не паханная и необъятная целина” (без намека на оценку затрат или даже guesstimates).
Чистка легаси решений — даже в свежем коде: то, что казалось на прошлой неделе хорошим или приемлемым решением — оказывается неудачным (люди учатся, повышают свою квалификацию), архитектор на ревью выявил проблемы дизайна
Поддержание приемлемой производительности компонент и связей.

Примерно так отличается программа от коммерческого продукта.

В общем — я люблю свою работу.
Такое ощущение что это были не разработчики, а сборище клоунов которые не удосужились посмотреть, а как дела у других в индустрии со свифстом.

И жаль таки что все это сборище фанатиков в итоге с треском не уволили, и не внесли в черные списки по всей индустрии навсегда, надо отвечать за свои технические решения.

миллионы и миллионы долларов (не могу назвать реальную цифру, но гораздо больше одного).

Хороший сеньоре в США стоит 300-400к годовых, с учетом их масштабов и времени это условно даже 100 человек на 2 года(90 недель округлим с отпусками) итого 80М долларов только на ЗП и бонусы.
больше чем это на 17% если включить налоги, сраховки…

плюсы, которые они получили:


  • переход на свифт (который является доминирующим языком под iOS сейчас),
  • переход на функциональную парадигму (Rx), которая является доминирующей сейчас,
  • перевод приложения на архитектуру, в которой каждая фича отделена от остальных
  • куда-то пропали пожары, которые они в 2016м тушили: Uber at the time was extremely heavy on client side logic so the app would break a lot. We were constantly doing hot fixes, burning releases, etc. The design was also scaling badly

Минусы:


  • один аврал из размеров приложения
  • починка скорости сборки
  • сколько-то людей потеряли из-за выгорания (сколько бы они потеряли в режиме постоянных хотфиксов?)

Мне кажется, всё было сделано верно.


Да, перевод плохой, читайте оригинал.

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.