Comments 45
Затем к власти пришёл Трамп (это случилось примерно через три месяца после выпуска нового приложения)отдельно от контекста звучит как фраза из Пелевина!
Лимит в 200мб. Звучит жутко. Я как то увидел, что приложение по аренде самокатов 47мб, отменил установку, внутренне понимаю, что сейчас это не критично, но как старый дед, до сих по считаю каждый килобайт.
Вам же написали в статье 92 библиотеки, большая часть по-любому для организации нормальной функциональной парадигмы. К примеру одна RxSwift вам набросить на вентилятор мегабайта 4. если предположить что каждая библиотека весит 500кб вот вам уже пол приложения.
А почему RxSwift такая тяжёлая? Это связано с особенностями архитектуры iOS приложений или с самой библиотекой? Просто, скажем, RxJS весит 45.6kB (gzip). RxSwift в несколько десятков сложнее? Или это больше сказывается специфика swift?
P.S. я ни в коем случае не троллю, просто пытаюсь понять, откуда такие размеры в бинарных приложениях.
И заодно посмотреть на кеш, доходящий до 1 ГБ.
Странно что столкнувшись с описанными в статье проблемами и имея такое модульное приложение они не разделили его на приложения для водителей и пассажиров (причем отдельное приложение для водителей у них есть, но в статье про это не сказано). Ну или как минимум не отключили часть модулей (GenderIdentity-Localizations-Helix.bundle или EatsTutorial-Localizations-Helix.bundle например точно нужны? :) )
А потому, что если у тебя тысячи программистов — у тебя не может не быть десятков тысяч классов. Им же всем надо что-то писать.
Это все объясняет, спасибо.
Понятно, спасибо. Т.е. это всё таки не включает в себя функциональность для самих таксистов, их бухгалтеров и прочих связанных людей, как предположили выше. Это только пользовательская функциональность. Просто все возможные случаи для любого региона и все возможные AB-тесты, и все… {подставить что угодно} для {что-угодно} грузят все до единого пользователи системы.
Видимо Apple store (возможно и Google Play тоже) не предоставляет удобных инструментов, организовать всё иначе. А может просто рассчёт на то, что сегодня ты берёшь Uber в Лондоне и платишь одной кредиткой, а завтра в Камбодже, и платишь какой-нибудь местной системой. И всё это без дозагрузки кода.
Всё или ничего. Сразу.
Кстати руководству пункты а) и б) могут быть вполне понятны, они головную боль перетерпят.
В общем-то, переписывание с нуля на обж-с тоже могло дать такой же эффект, но только если запретить таскать куски из старой кодовой базы. А как же ты это сделаешь?
Вопрос iOS разработчикам: почему речь идёт о таких больших размерах? 150 MiB это же огромный размер для приложения с картой и парой десятков экранов. Условная windows 95 (129MB) целиком помещалась в этот размер. А ведь это целая оконная ОС.
Я явно чего-то не понимаю. В Swift ужасно работает dead code elimination? Или для каждого метода создаётся пара десятков имплементаций и все попадают в бинарник?
Ещё не совсем понятно почему в середине автор пишет, что увеличение размера катастрофически сказалось на доходах, но потом радуется, что Apple подняла лимиты до 200 MiB. Т.е. с тем, что пользователи не всегда могут скачать 150 MiB "здесь и сейчас" просто смирились?
Причём я ещё понимаю, когда с подобными проблемами сталкиваются, при написании действительно больших и сложных приложений. Но Uber скорее относится к приложениям средней сложности. Мне кажется действительно сложные задачи решает их Backend команда.
Не говоря уже от всякой телеметрии и прочее прочее для аналитики.
Бинарник программы управления современного спутника где куча телеметрии для анализа весит ~ 1 Мб
Файл с переводом текстовый — я с трудом представляю что текста в приложении наберется больше, чем на 1 Мб.
Т.е. телеметрия и фишки с переводом с трудом тянет на 2 Мб. Откуда 100 мб?
Ну и я не сказал, что там только одна телеметрия, я сказал, что там тысячи экранов разных, а телеметрия в довесок.
Там не 10 и не 20 экранов, там тысячи.
Тогда почему они не сделают 2 Uber-а: там где 1000 экранов (вероятно для самих водителей, таксопарков, бухгалтеров и пр.), и там где 30 экранов (для всех остальных)? Эта какая-то очень странная архитектура.
Что-то вроде такого? :>
https://play.google.com/store/apps/details?hl&id=com.ubercab.uberlite
Установил Firefox на трубку. 63 MiB. Едва ли тут дело в том, что Firefox написан не на Swift :)
Но у меня Android. Так что малый размер — это весь браузер. Не Webkit
Для себя я этот парадокс когда-то сформировал так: для многих компаний докупить доп. планки памяти на серверах дешевле, чем оплачивать месяц работы разработчиков, чтобы оптимизировать программу.
Я могу ошибаться, но мне кажется, что в Uber просто не хватает грамотных архитекторов.
Вспоминается история Discord, которые спустя много лет, решили оптимизировать своё React Native приложение. И разразились статьёй — что же именно они изменили, что приложение перестало так нещадно тормозить. Оказалось что они просто включили мозг и открыли документацию. Они не знали и\или игнорировали прописные истины. И просто собрали все грабли, какие могли. Хотя казалось бы большой штат разработчиков, большая аудитория, есть деньги. Но… Nobody cares. Тормозит и тормозит.
Пока мы читаем статьи про то, как "0.1с при загрузке страницы отнимает у вас Х% прибыли", крупные игроки на рынке тащат 6 MiB бандлы (привет gmail), и 150 MiB сборки (привет Uber). Похоже, имея лидерство на рынке, можно диктовать свои условия даже конечным потребителям.
В статье это подано как: это не мы плохие, это Swift кривой. Я хоть и не swift разработчик, но думаю, что Swift тут не причём. Неча на зеркало пенять, коли рожа крива.
Плюс это все дополняется очень слабыми в техническом плане архитекторами, но с отличными soft skill.
Т.е. тут описывается похожая ситуация — у команды была возможность сделать прототип(где как раз надо было бы и продумать все эти моменты). Они его по сути не сделали(это как бы ключевой момент), банально отрапортовав что технология отличная, плюс еще до кучи и остались на своих местах
Не бросайте в меня тухлыми помидорами. Я не являюсь профи в программировании, но кое-что пишу для своих научных нужд довольно часто. Мне иногда кажется, что я со своими убогими навыками могла бы за пару месяцев написать клиентскую часть Убера. Понимаю, что не может такого быть, где я и где та корпорация… Но всё равно не понимаю.
Были разговоры, что Netscape потерял рынок браузеров, когда его было решено переписать в пятой версии (как обычно — мотив для этого был).
Также стоит вспомнить главу «Эффект второй системы» из книги «Мифический человеко-месяц» (с ее публикации в 1975 году ничего не изменилось):
Эта вторая система — самая опасная для человека, который ее проектирует. Когда он трудится над своей третьей и более поздними, все экземпляры из его предшествующего опыта будут подтверждать друг друга относительно общих характеристик таких систем, и их различия будут определять те части его опыта, которые являются частными и необобщаемыми.
Общая тенденция — делать дизайн второй системы с большим за- пасом, используя все идеи и излишества, которые были осторожно отклонены в первой. В результате, как говорил Овидий, получается «большая куча».
Нет, я понимаю, что серверная часть Убера очень и очень непростая. Но в клиенте, что такого сложного? Получить и передать на сервер местоположение, обеспечить скроллинг карты, запрашивая нужные тайлы. Жамкнуть и передать две точки "откуда" и "куда", получить стоимость и отображать статус заказа. Где тут 92 библиотеки и 100 Мбайт кода? Ну ок, можно ещё просматривать и редактировать профиль, регистрироваться, туда-сюда авторизация. Но где тут труд десятков высокооплачиваемых и наверняка неглупых программистов в течение, вашу ж мать, чуть ли не 2 лет (в тексте 90 недель)!
Можно ответить: "Ты не понимаешь, это другое". Да, не понимаю.
Просто из любопытства попробовал прикинуть — что требовалось сделать в клиенте (фактически “с нуля”, но используя готовый опыт), посмотрев ролик о клиенте на ютубе.
Здесь примерный список функциональности, видимой клиенту
— общая
— телефон
— Фейсбук
— Пароль
— Восстановление пароля
Список платежей с деталями
Список поездок с деталями
Free rides (не знаю что это)
Помощь
— иерархическая структура
— Последняя поездка, Квитанция
— Репорт проблем
Настройки
Форма платежей
— настройка и платёж картами
— Настройка и платёж PayPal
— Настройка и использование rewards, promo,gift
Профиль
— персональный
— Бизнес
— Семейный (платить за них и отслеживать поездки)
— Фавориты
Карта и поездка
— доступные машины вокруг (также отрисовка машин, изменение их положения и статуса)
— История остановок недалеко (?)
— Ввод пунктов посадки высадки
— История пунктов
— Известные места (дом, работа)
— Выбор типа машины (эконом, taxi, SUV и т.д.) с деталями
— Выбор «приватный», «бизнес»,«семейный» (немало логики за этим)
— Вызов машины
— Отмена поездки
— Стоимость поездки
— Детали машины, водителя
— Контакт с водителем — звонок, сообщение, выбор своего номера телефона
— Share status (примерное время прибытия в пункт назначения)
— Разделить с другом оплату
— Построение примерного маршрута
— Отслеживание на карте поездки
— Оплата поездки
— Оценка водителя
— Квитанция
Это только для пассажира — без функций водителя.
Нужно помнить также о нефункциональных требованиях,
— изменение внешние — окружение, машина, водитель, поездка
— внутренние — детали профиля, изменение с другого клиента (например клиент на другом телефоне)
— Данные не теряются и синхронизируются при потери сети, кэширование для уменьшения трафика и отзывчивости
— Атрибуты качества. Например — отзывчивость форм в пределах заданного интервала,
— Согласованность дизайна и поведения форм
— Количество сбоев (такое тоже есть) и восстанавливаемость (recovery)
— Юнит-тесты
Все это нужно
— обединять (merge — наработки разных итераций спринтов, разных команд, багфиксы)
— интегрировать — разные компоненты (возможно разных команд) взаимодействуют друг с другом и с сервером
— тестировать (в том числе на различных моделях телефонов и версиях iOS, iPadOS)
— билдить
— деплоить
— исправлять баги
— расширять функциональность
и повторять все циклы снова.
Не забываем о необходимости согласований и коммуникации такого количества команд и разработчиков (а среди них — решение проблемы модели, предложенной братьями Дрейфус). Снова вспомним о книге «Мифический человеко-месяц», и главе «Человеко-месяц» из нее — о том, как количество вовлекаемых в решение задачи человек, влияет на общую производительность в проекте.
Также на все это накладываются ограничения библиотек и их версий (а это хаки и воркэраунды) — просто “не паханная и необъятная целина” (без намека на оценку затрат или даже guesstimates).
Чистка легаси решений — даже в свежем коде: то, что казалось на прошлой неделе хорошим или приемлемым решением — оказывается неудачным (люди учатся, повышают свою квалификацию), архитектор на ревью выявил проблемы дизайна
Поддержание приемлемой производительности компонент и связей.
Примерно так отличается программа от коммерческого продукта.
В общем — я люблю свою работу.
плюсы, которые они получили:
- переход на свифт (который является доминирующим языком под 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
Минусы:
- один аврал из размеров приложения
- починка скорости сборки
- сколько-то людей потеряли из-за выгорания (сколько бы они потеряли в режиме постоянных хотфиксов?)
Мне кажется, всё было сделано верно.
Да, перевод плохой, читайте оригинал.
Как Uber переписал приложение iOS на Swift