Согласно опубликованному отчету об анализе индустрии мобильного интернета за 2018 год, ежемесячное количество активных пользователей Alipay превзошло QQ и стало вторым по величине приложением в Китае.
В начале Alipay был просто приложением типа инструмента для одного приложения, которое позволяло пользователям выполнять бизнес-запросы и операции, связанные с Alipay, на своих мобильных телефонах. После 2013 года Alipay постепенно трансформировалась в платформенное приложение, обладающее характеристиками обслуживания, модульности и компонентности инструментов. В настоящее время бизнес Alipay заключается не только в оплате, но и в предоставлении клиентам многих жизненных услуг, таких как Yu'ebao, оплата счетов за электроэнергию и т. д. После 2015 года Alipay превратился в суперприложение.В это время Alipay необходимо поддерживать большое количество сложных бизнесов, и в то же время открывать собственные бизнес-возможности и использовать собственный трафик для помощи партнерам.Поэтому все приложение сталкивается проблемы открытости, динамичности и высокой доступности Эти проблемы мы суммируем в следующих трех пунктах:
- Как справиться со сложным деловым сотрудничеством?
- Как удовлетворить потребности быстрой бизнес-итерации?
- Как построить ориентированную на будущее открытую экосистему?
1. Используйте архитектуру гибридного приложения для решения сложных задач совместной работы.
Бизнес приложения становится все более сложным, не только внутренним бизнесом, но и включает в себя большое количество внешних партнеров. Трудно справляться со все более сложными бизнес-сценариями, если используется традиционный метод разработки приложений.
1.1 Выбор гибридного технического решения
При выборе гибридных технических решений мы прошли «Стоимость разработки, взаимодействие с пользователем, динамизм, комплексные возможности поддержки бизнеса, сложность НИОКР«Всесторонне рассматриваются пять аспектов. Мы отобрали HTML5, ReactNative/Weex и Flutter в качестве альтернатив и использовали нативную разработку в качестве основы для завершения сравнения. (Учитывая, что популярность Flutter в последнее время продолжает расти, мы включили Flutter для анализ.)
Сначала мы начнем с бизнесаЗатраты на разработкуПерспектива:
- Натив, как самый базовый режим разработки, необходимо развивать с обеих сторон, и стоимость, несомненно, самая высокая;
- Второй - ReactNative/Weex. Даже если он разрабатывается один раз и работает на обоих концах одновременно, поскольку JS преобразуется в рендеринг Native компонентов, в реальной работе все равно есть некоторые различия. В результате, когда разработчики пишут бизнес-интерфейсы , некоторые различия должны пройти через нативную сторону.Разработка на заказ для решения. В целом ReactNative/Weex помогли бизнес-партнерам значительно сократить затраты на разработку;
- Следующим является Flutter, с точки зрения развития бизнеса, Flutter действительно сложно сделать с двойным концом. В большинстве сцен Android-концы можно без проблем запустить на стороне iOS, конечно, это связано с самим движком. Однако Flutter необходимо разрабатывать на основе языка DART, поэтому разработчики должны учитывать некоторые старые бизнес-трансплантации;
- Наконец, HTML5, со зрелым языком, зрелой моделью разработки и почти такими же проявлениями дуплекса, HTML5 по-прежнему является самой низкой стоимостью затрат на разработку.
Далее мы обсудимПользовательский опыт:
- Во-первых, родной опыт, несомненно, лучший;
- Второй — Flutter с собственным движком рендеринга.Будь то производительность или форма отображения элементов управления, можно сказать, что это не меньше, чем нативный опыт;
- Следующим шагом является решение ReactNative/Weex, в котором интерфейсный код преобразуется в собственные элементы управления Natvie. В более ранних версиях приложение зависало из-за неправильной оптимизации некоторых элементов управления, поэтому производительность взаимодействия с пользователем была недостаточной;
- Последним является HTML5, который полностью обрабатывается ядром браузера. С помощью предустановленных ресурсов, оптимизации ядра и других технологий HTML5 может достичь почти родного опыта, но общая производительность все же отличается.
с последующимдинамизмслужба поддержки:
Во второй главе этой статьи «Автономный пакетный механизм + платформа публикации» мы подробно проанализируем важность динамизма в поддержке бизнес-сценариев с высокой степенью параллелизма с точки зрения быстрой итерации.
- Во-первых, лучшая динамика — это решение HTML5: вы можете получить доступ к онлайн-страницам, сервер вступит в силу немедленно, и вы можете динамически обновляться, распределяя ресурсы;
- Второе — это решение ReactNative/Weex.При определенной настройке разработчики могут развертывать и обновлять интерфейсные пакеты в горячем режиме. Однако по сравнению с динамикой HTML5 «онлайн + офлайн» в этом решении все же есть определенный пробел;
- Далее нативное.И Android и iOS можно динамически обновлять через какие-то черные технологические средства.Однако из-за запрета политики iOS нативные решения пока не рекомендуются с точки зрения динамики;
- Наконец, есть Flutter, хотя он имеет мощный механизм горячей перезагрузки, из-за ограничений Google онлайн-версия iOS не может обновляться в горячем режиме, поэтому Flutter занимает последнее место в динамической оценке.
Наконец, поговорим о реализации каждой схемы.Трудность НИОКР:
- Здесь мы временно ставим HTML5 на первое место, потому что решение HTML5 Hybrid неотделимо от оптимизации ядра, а оптимизация ядра требует определенных возможностей исследования и разработки ядра, поэтому с точки зрения разработчиков исследования и разработки HTML5 являются наиболее сложными. Если это просто контейнер HTML5, сложность разработки значительно уменьшится;
- Второй - Flutter. В настоящее время, с точки зрения реальных бизнес-приложений, только команда Xianyu указала Flutter для крупномасштабных приложений в Китае. В то же время все еще существует большое количество открытых вопросов. ожидает решения на GitHub Flutter. В процессе фактической разработки и применения разработчики должны обратить внимание на управление жизненным циклом Flutter, управление стеком представлений, собственное переключение страниц и другие вопросы в процессе раннего выбора;
- Далее идет ReactNative/Weex.Поскольку эти два решения имеют открытый исходный код и поддерживаются большим количеством зрелых технических сообществ, сложность разработки решения невелика для разработчиков, а открытый исходный код легко модифицировать и проще использовать;
- Последним является собственное решение. Если вы не рассматриваете горячее восстановление, собственное решение можно использовать напрямую без внесения каких-либо изменений. использоваться напрямую.
Подводя итог, после рассмотрения преимуществ и недостатков всех сторон, мы решили принять подход «контейнер HTML5 + оптимизация ядра» для решения сложных задач. Далее мы представим архитектуру контейнера.
1.2 Контейнерная архитектура
Верхний уровень — это собственный код HTML5, который является общей средой веб-разработки, включая HTML, CSS, JavaScript и т. д. Следующий уровень — автономное управление пакетами, о котором мы подробно расскажем во второй главе. Ниже находится уровень контейнера HTML5.Контейнер HTML5 служит средним уровнем, который органично объединяет браузер и базовую структуру Alipay, а также предоставляет различные механизмы жизненного цикла, механизмы событий и подключаемые модули расширения.
В контейнере HTML5 есть очень важная концепция: JSBridge. Через JSBridge контейнер HTML5 соединяет различные возможности, предоставляемые нижним уровнем платформы Alipay и уровнем промежуточного программного обеспечения, с интерфейсным кодом HTML5, включая RPC (удаленный вызов процедуры, используемый для связи между приложением и сервером), оплату , сканирование и т.д.
Внизу находится базовая структура Alipay, которая предоставляет такие концепции, как микроприложения и микросервисы. Приложение HTML5 также моделируется платформой как микроприложение, которое отделяется через идентификатор приложения.
1.2.1 Введение в JSBridge
JSBridge является краеугольным камнем контейнера HTML5. Он соединяет среду JS и среду Native и реализует двустороннюю связь между кодом Native и средой браузера. Код Native может запускать JS, вызывая интерфейс, предоставляемый браузером, поэтому что касается вызова функций JS и передачи параметров в среду JS и т. д., а связь из браузера в среду JS достигается за счет собственного перехвата запроса браузера, который может быть сетевым запросом или вызовом некоторых внутренних функций.
1.2.2 Расширение настройки контейнера H5
Контейнеры HTML5 предоставляют 2 расширения:
- JSAPI
Метод JSAPI добавляет интерфейс вызова собственных функций на страницу HTML5. Путем реализации метода Handler в пользовательском классе JSAPI определенные функции могут быть реализованы в форме Native, например вызов функции шифрования Native.
- мероприятие
Контейнер HTML5 будет отправлять события при изменении состояния. Отслеживая определенные события контейнера HTML5, можно обрабатывать жизненный цикл контейнера HTML5, например изменять цвет индикатора выполнения загрузки, изменять панель навигации по странице и т. д. . События обеспечивают более надежную настройку и могут полностью соответствовать различным требованиям к настройке для контейнеров HTML5.
1.3 Стабильность контейнера
В вышеприведенной проблеме исследования и разработки мы упомянули, что метод HTML5 является наиболее сложным для разработки, поскольку для оптимизации производительности и стабильности требуется специальное ядро. В настоящее время Alipay использует ядро UC, разработанное Ali Group, и провела глубокую оптимизацию и настройку контейнера Alipay HTML5. Как показано на рисунке, эффект сравнения данных зависшей скорости ядра UC и ядра системы очень значителен, и мы можем интуитивно увидеть улучшение стабильности Webview.
2. Механизм автономных пакетов + платформа публикации, обновление в режиме реального времени, чтобы соответствовать быстрой итерации бизнеса
Еще одна особенность бизнеса Alipay заключается в том, что он требует быстрой итерации.Изменения в политике и чрезвычайные ситуации требуют от нас быстрого удовлетворения новых потребностей бизнеса для пользователей. Но для разработчиков приложений есть проблема, которую нельзя игнорировать, а именно обзор магазина приложений. В связи с наличием аудитов будет единый график для бизнеса, разработанного в приложении, например, в конце месяца будет новая версия, поэтому весь бизнес-процесс должен учитывать график приложения.
2.1 Механизм офлайн-пакетов
Чтобы добиться хорошего пользовательского опыта, мы внедрили в контейнер механизм офлайн-пакетов. С помощью механизма автономного пакета мы заранее доставим исходное приложение HTML5, загруженное из сети, в локальную среду, и отобразим страницу, считывая ввод-вывод или память, чтобы добиться почти естественного взаимодействия с пользователем.
С помощью платформы публикации мы можем распространять различные офлайн-пакеты HTML5 в виде отдельных приложений в разных измерениях, так что исходное все в режиме публикации Native может быть изменено на собственный индивидуальный план публикации и стандарты публикации каждой бизнес-линии. форма релиза, отвечающая быстрой итерации бизнеса.
2.1.1 Механизм заряжания
Предварительно загружая память, регулярно обновляя и запуская предварительную загрузку памяти, мы загружаем ресурсы, необходимые бизнес-пакету, в память, чтобы процесс запуска был максимально нечувствительным, а страница открывалась за считанные секунды без пустого экрана. В то же время у нас также есть резервный метод, чтобы гарантировать, что, когда пакет поврежден или не загружен, можно гарантировать 100% доступность бизнеса в виде онлайн-страницы.
2.1.2 Механизм пакета общедоступных ресурсов
Так называемый общедоступный пакет ресурсов представляет собой набор общих ресурсов, которые могут использовать все автономные пакеты HTML5. Общий пакет ресурсов решает проблему избыточности, вызванную использованием одного и того же ресурса несколькими приложениями HTML5. Например, приложение React, использующее код фреймворка ReactJS. Вы можете поместить общие ресурсы в глобальный пакет ресурсов, чтобы уменьшить размер вашего приложения HTML5.
Благодаря механизму пакета общедоступных ресурсов размер пакета каждого приложения HTML5 можно эффективно уменьшить, тем самым увеличив скорость обновления и ускорив открытие страницы.
2.2 Издательская платформа
Чтобы удовлетворить потребности быстрой итерации, необходима мощная платформа выпуска. Основным показателем платформы публикации является публикация контента на указанном устройстве, для достижения этой цели мы предприняли следующие усилия.
2.2.1 Управление размером пакета в автономном режиме и механизм дифференциального пакета
Автономный пакет контейнера HTML5 предоставляет механизм обновления с одним автономным пакетом в качестве измерения обновления. Поскольку бизнес с одним автономным пакетом очень прост, размер автономного пакета можно контролировать, обычно он не превышает 500 КБ. Благодаря большой практике мы пришли к выводу, что значение «500 КБ» может не только удовлетворить контент одного бизнеса, но и более эффективно публиковать его на устройстве. 500 КБ, в эпоху 4G пользователи могут обновляться почти незаметно, даже 2G/3G может гарантировать высокую скорость поступления.
Выше указан размер приложения HTML5. Фактически, пакет, который мы обновляем, будет меньше, и платформа публикации рассчитает пакет различий между двумя разными версиями одного и того же приложения HTML5 с помощью алгоритма сравнения. Пакет различий обычно колеблется от нескольких КБ до десятков КБ. более высокая скорость успешной загрузки, скорость успешной загрузки в определенной степени означает фактическую скорость прибытия.
2.2.2 Резервный механизм
В некоторых экстремальных сетевых сценариях обновление нового пакета ресурсов службы завершается сбоем, и мы ожидаем, что пользователи будут использовать последнюю версию службы.В это время вступает в действие механизм доступа Fallback. Каждый ресурс автономного пакета будет храниться на платформе сервера выпуска.В только что упомянутом крайнем сценарии пользователь получит доступ к резервному адресу сервера, чтобы получить ресурс для обеспечения доступности страницы.
2.2.3 Многомерная публикация
Кроме того, для недавно разработанного приложения мы можем выпустить его через выпуск в оттенках серого платформы выпуска и проверить бизнес-показатели в виде внешних оттенков серого.После достижения стандарта мы можем официально выпустить его откат.
3. Лучшее гибридное решение: дифференциальный анализ HTML5 и мини-программ
Одной из важнейших особенностей суперприложения является открытость. Открытие заключается в том, чтобы разделить трафик приложения, чтобы бизнес внешних партнеров мог достигать пользователей через Alipay, который сталкивается с проблемой контроля качества. Alipay необходимо обеспечить, чтобы эти предприятия были законными и соответствовали требованиям, а также обеспечить безопасность имущества пользователей.
3.1 Автономный пакет против апплета
Если вы развиваете односторонний бизнес, офлайн-пакет, безусловно, очень хороший выбор. Однако, если сторонние партнеры могут создать экосистему, чистые HTML5-страницы имеют некоторые недостатки.
На приведенном выше рисунке показано подробное сравнение автономного пакета HTML5 и апплета. Подводя итог, можно сказать, что для экосистемы, открытой для третьих лиц, с точки зрения работы приложения апплет более унифицирован и качество гарантировано; с точки зрения безопасности приложения апплет обращается к нашему серверу публикации, а не напрямую к третьему. сторонние ссылки, безопасные и контролируемые, с точки зрения порога исследований и разработок, апплет представляет собой более простой метод разработки интерфейса, а также предоставляет очень богатый набор компонентов.
3.2 Анализ мини-программы
Апплет на самом деле похож на автономный пакет по сути, оба являются гибридными приложениями, но апплет основан на настраиваемом языке DSL, а не на стандарте внешнего интерфейса, но похож. Предприятия разрабатывают небольшие программы в соответствии с правилами DSL и не поддерживают прямое манипулирование DOM.Эта свобода в соответствии с правилами DSL может эффективно контролировать качество.
Как приложение, апплет имеет полный жизненный цикл. От разработки до закрытия разработчики это чувствуют, чего в HTML5 тоже нет. Кроме того, каждый апплет полностью изолирован от времени выполнения и сохранения, а апплет работает в определенном процессе, поэтому он также изолирован от Alipay.
Что касается производительности рендеринга, апплет работает в двухпоточном режиме, чтобы рендеринг страницы и бизнес-логика размещались в двух отдельных потоках: модуль рендеринга работает в WebView и отвечает за рендеринг интерфейса, а бизнес-логика апплета выполняется в отдельном рабочем потоке. и отвечает за события, обработку, вызовы API и управление жизненным циклом. Обмен данными между двумя потоками осуществляется через postMessage и onMessage.Данные могут быть переданы из рабочего потока в средство визуализации для повторного рендеринга интерфейса, и средство визуализации также может передавать события соответствующему рабочему процессу для обработки. Рабочий процесс может соответствовать нескольким средствам визуализации для облегчения обмена данными и взаимодействия между страницами.
Что касается загрузки ресурсов, апплет загружается в автономном режиме, то есть при открытии апплета его офлайн-пакет должен быть загружен на локальный сервер.Поскольку каждая версия загружается только один раз, с одной стороны, Накладные расходы на ресурсы каждого запроса сохраняются.С другой стороны, скорость запуска значительно повышается. При наличии новой версии платформа публикации автоматически сравнивает локально установленную версию с последней версией для создания и доставки дифференциального пакета.Клиент может обновить апплет до последней версии, не загружая весь пакет.
3.3 Построение экосистемы
Внедряя ту же архитектуру мини-программ, мини-программы можно использовать в качестве экосистемы для многосторонних взаимных инвестиций. Апплет, запущенный в Alipay, может работать в приложении, основанном на той же архитектуре апплета, только за счет адаптации некоторых открытых интерфейсов. В будущем разработчики или сторонние сервисы будут в большей степени ориентированы на небольшие программы, а приложения будут предоставлять единую архитектуру, по-настоящему открывать экологию и исчезать после использования.
О контейнерном решении HTML5 собственной разработки Alipay
Автономный пакет mPaaS является производным от собственного решения Alipay и прошел серьезные бизнес-тесты.Он позволяет напрямую использовать тот же набор кода уровня инфраструктуры с Alipay, имеет унифицированный контейнер и ядро, а также обеспечивает более низкую частоту сбоев и уровень ANR, чем ядро системы.Адаптация Он очень гибкий и имеет хорошие и гибкие возможности расширения, а JSAPI можно настроить в соответствии с конкретными потребностями бизнеса. Это может помочь уменьшить белый экран приложения, решить проблему межплатформенной совместимости и адаптации гибридного приложения, повысить производительность приложения и значительно оптимизировать размер пакета при собственной разработке.
В настоящее время исходный код демо-версии автономного пакета mPaaS обновлен на GitHub, добро пожаловать в Star:GitHub.com/Alibaba/MPAA…
Добро пожаловать, чтобы подать заявку на пробную версию, дать больше предложений по оптимизации и использовать отзывы:mpaas2019.mikecrm.com/otOU1k1
Присоединяйтесь к нашей коммуникационной группе и с нетерпением ждем возможности общаться вместе и предлагать лучшие решения для гибридной разработки:
Читать в прошлом
«Начало | Обзор системы основных компонентов сервера mPaaS компании Ant Financial»
«Основные компоненты сервера mPaaS: анализ архитектуры службы мобильного анализа MAS»
«Проект системы компонентов Ant Financial для 100 миллионов одновременных сценариев»
«Эволюция автоматизированного сбора и анализа журналов в приложении Alipay»
Подпишитесь на нашу официальную учетную запись, чтобы ознакомиться с технологией mPaaS из первых рук.
Группа Dingding: номер группы поиска «23124039» через Dingding
С нетерпением жду вашего присоединения~