Автор | Чжо Лин Произведено | Alibaba New Retail Tao Department Технологический отдел

Передняя технология была разработана только более десяти лет с момента ее рождения. Если первые десять лет были эпохой интерфейсов для ПК, то следующие десять лет должны принадлежать эпохе мобильных интерфейсов. В частности, с развитием сетевых стандартов мобильные устройства приобрели беспрецедентную популярность во всем мире.В области клиентских интерфейсов также появился ряд новых мобильных интерфейсных технологий, таких как Hybird Web, React Native, Weex и Flutter. Как грибы после дождя. , сегодня я поделюсь с вами своим пониманием «мобильной фронтенд-разработки и веб-фронтенд-разработки».

Обзор: история фронтенд-разработки

Этап 1: Руби и сжигай

Что касается внешнего интерфейса, то более десяти лет назад разработчики все еще боролись с совместимостью с IE6.jQuery является лидером во фреймворке.Zepto.js можно использовать во внешнем интерфейсе для уменьшения размера веб-страниц. В настоящее время фронтенды в основном ориентированы на ПК, в настоящее время вообще нет понятия мобильного фронтенда, а страницы с трафиком на маленьких экранах мобильных телефонов представляют собой в основном простой текст.

Этап второй: инженерный

В исторический период между 2011 и 2014 годами доминировала идея модульности. В то время для разработки загрузчика ресурсов Assets была сформулирована модульная спецификация протокола. В то время наиболее популярными модульными протоколами были AMD (RequireJS), CMD (представленный Seajs) и KMD (представленный Kissy). На Taobao и Tmall Kissy очень популярен, поэтому KMD доминирует в мире; в Alipay и во внешних сообществах очень популярен Seajs, поэтому CMD доминирует в мире, репутация и престиж Yubo также очень высоки в кругу клиентов; и AMD более популярен за рубежом, но его постепенно ослабляет появившаяся позже спецификация CommonJS.

Фаза 3: Мобильность

С развитием 3G и 4G и растущей популярностью мобильных телефонов iOS и Android на рынке основное поле битвы ПК-бизнеса постепенно переместилось на мобильные терминалы. Режим внешнего интерфейса переместился с ПК на мобильный терминал и соответствует пользовательскому опыту приложения. Поддержка протокола HTML5 на мобильной стороне не идеальна, производственные мощности переднего плана несовершенны, а экран Android фрагментирован, поэтому в то время трудоемкость фронтенд-разработки для адаптации мобильных страниц была намного больше, чем у разработчиков. Эпоха ПК.

Этап четвертый: кадрирование

В сообществе фронтенда фреймворки MV*, такие как Angular, React, Vue, RN (React Native) появлялись один за другим, позволяя фронтенду принять крещение управляемого данными мышления, а также использовали RN для завершения опыт обновления мобильного терминала, включая более поздний Weex, Flutter.

На этом этапе клиентская часть начинает иметь базовую архитектурную группу терминала и начинает понимать производительность загрузки и производительность взаимодействия с пользователем интерфейсной страницы на мобильном терминале. В Alibaba, чтобы решить проблему повторного использования нескольких терминалов, Rax использует VDOM, чтобы открыть оба конца WebView и Weex, и миром правит набор кодов.

Этап 5: Вертикализация

С выпуском оригинального iPhone мобильные телефоны с большим экраном постепенно стали популярными, и спрос на мобильные терминалы начал стремительно расти. На Taobao и Tmall годовой объем мобильных транзакций в двойном размере 11 увеличивается из года в год и постепенно занимает абсолютную лидирующую позицию. Фронтенд-сфера также постепенно подразделяется с этой тенденцией.В зависимости от сцены ее можно просто разделить на мобильную (беспроводную) фронтенд-разработку и мидл и бэк-энд фронтенд разработку.

Разработка мобильного интерфейса нацелена на потребительские веб-сценарии и бизнес-сценарии легких приложений.В этом сценарии, после нескольких лет осадок в маркетинговой деятельности, отдел Tao постепенно сформировал уникальное и легкое решение для мобильного терминала, а также модуль многомерная, ориентированная на операции система построения страниц.

Промежуточный и внутренний интерфейс ориентирован на внутренние бизнес-сценарии, такие как корпоративная ERP, CRM, OA и т. д., такие как бизнес-сервер и другие системы. В этом сценарии с помощью материалов для промежуточной и конечной частей, таких как Feibing и Fusion Design, формируется визуальное строительное решение для средней и задней части, предоставляющее универсальные производственные решения для средней и конечной частей для передней части. -конечная, разработка или роль продукта в бизнесе.

Мобильный интерфейс: прошлое и настоящее гибридных технологий

Когда-то разработка мобильного клиента и фронтенд-разработка были двумя параллельными линиями, которые не пересекались, но сейчас мы все больше осваиваем совместный продукт двух: гибридную (Hybird) разработку приложений, или концепцию, ставшую популярной в последнее время. -- большая передовая технология.

Думая с точки зрения технологии, по сути, разработка на стороне клиента и разработка интерфейса являются терминальными технологиями, которые характеризуются прямым программированием пользовательского интерфейса, ориентированным на пользователя.

То же самое и с программированием пользовательского интерфейса, с какими болями мы сталкиваемся?

Технические ограничения традиционных интерфейсных веб-технологий

1. Загрузка ресурсов: HTML, JS, CSS, изображения и другие статические ресурсы хранятся на удаленном сервере, что требует динамического асинхронного извлечения, а затем извлекает данные для отображения.Эффективность инициализации намного ниже, чем у Native. 2. Механизм рендеринга: в дизайне браузера выполнение JS, верстка страницы и Paint находятся в одном основном потоке, который нельзя распараллелить.Кроме того, производительность JS не поспевает за язык AOT, а выполнение сложной логики приводит к зависанию.Обычно блокируя пользовательский интерфейс в сочетании с длительным конвейером рендеринга, опыт рендеринга браузера не является доминирующим по сравнению с Native в равных количествах. 3. Переключение страниц. В браузере отсутствует концепция маршрутизации, что приводит к тому, что процесс переключения между страницами полностью зависит от возможностей, предоставляемых оболочкой браузера, которая будет многократно загружаться при переключении страницы. Конечно, концепция одностраничного приложения появилась и в фронтенд-сообществе, но ресурсы нескольких страниц также значительно увеличивают размер JSBundle и усложняют разработку страницы. 4. Возможности API: Механизм безопасности браузера представляет собой механизм песочницы, основанный на политике того же источника. Этот механизм песочницы не позволяет разработчикам внешнего интерфейса использовать собственные возможности системы. Вы можете использовать только функции, определенные стандартом W3C, и учитывая фрагментацию терминала Из-за проблемы преобразования эти интерфейсы часто нельзя использовать напрямую. Это не проблема в сценарии на стороне ПК, но разработчики надеются, что на мобильной стороне будет возможность вызывать системный интерфейс для реализации некоторых более интерактивных сценариев. 5. Интерактивная производительность: интерактивная производительность браузера в режиме реального времени оставляет желать лучшего, а крупномасштабная перестановка в сложных интерактивных сценариях ограничивает частоту кадров пользовательского интерфейса.Это ограничение особенно серьезно для недорогих мобильных устройств. 6. Язык сценариев, динамический анализ и выполнение JS — это JIT-язык, то есть он нуждается в динамическом анализе и выполнении, и его производительность выполнения намного хуже, чем у языков AOT с предварительно скомпилированным машинным кодом.

Ограничения традиционной клиентской технологии?

Динамический: разработка клиента обычно имеет фиксированный план выпуска версии и регулируется правилами проверки Apple App Store. Политики также влияют на неопределенность выпуска версии. В Китае есть много каналов для Android. Неоднократно проверяйте канал, как только найдете онлайн-проблемы должны полагаться на повторный выпуск, стоимость отказоустойчивости очень высока, что также значительно увеличивает ограничения бизнеса.

Стоимость разработки: стоимость разработки клиента высока, но экология не так богата, как в Интернете.Десятки тысяч пакетов с открытым исходным кодом в сообществе npm в сочетании с более активным сообществом разработчиков приводят к более высокой стоимость клиентских исследований и разработок для предприятий, чем веб-разработка.

Межконечная согласованность: для разработки набора сервисов на традиционной стороне клиента необходимо реализовать два набора кода: Android + iOS, а из-за различий в возможностях операционных систем между Android и iOS часто предъявляются одни и те же требования. реализовывались с другим видением и взаимодействием, что также приводило к высоким издержкам бизнеса.

Гибридная фронтенд-разработка

Почему возникает гибридная фронтенд-разработка?

Поскольку iOS + Android установили господство среди мобильных операционных систем, фронтенд-разработчики также ищут модели для использования возможностей, предоставляемых операционной системой, для развития бизнеса. Метод веб-разработки намного удобнее и эффективнее, чем в iOS и Android, а бесконечное разнообразие библиотек и фреймворков в Интернете гораздо удобнее, чем в Android и iOS. Мы можем легко использовать различные интерфейсные фреймворки в Интернете для предварительного просмотра эффекта во времени (подумайте о времени компиляции большого проекта Android/iOS).

С точки зрения Alibaba, по мере того, как концепция Zhongtaiization постепенно принимается: бизнес должен стремиться к быстрому развитию, пользовательский интерфейс и требования к стойке регистрации будут быстро повторяться вместе с бизнес-решениями, а различные позиции внешнего интерфейса и На стороне клиента также сформировалась модель разделения труда.

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

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

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

Фаза 1: JSBridge

На этом этапе в основном используется WebView, а JSBridge обеспечивает канал связи между Naive и JS. На основе этой коммуникационной основы Native может предоставлять некоторые стандартные API-интерфейсы службы для вызовов JS. Тот же JS также может использовать Это инкапсулирует некоторые базовые API-интерфейсы для Native звонки. Разработчики внешнего интерфейса используют традиционные JS + HTML + CSS для разработки страниц и вызывают JSBridge API для расширения возможностей на стороне клиента. На данном этапе Apache Cordova является лидером в отрасли, и большинство интернет-компаний также имеют свои собственные реализации фреймворка JSBridge.Можно сказать, что JSBridge впервые дал разработчикам переднего плана возможность вызывать Native.

Однако основным недостатком решения JSBridge является отсутствие производительности и расширенных возможностей расширения компонентов, а беглость никогда не была сравнима с Native.

Фаза 2: собственный пользовательский интерфейс

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

1. Как открытый технический стандарт, W3C имеет долгую историю и множество обременений, что значительно замедляет работу браузеров. 2. Недостатки в конструкции механизма рендеринга WebView, конвейер рендеринга очень длинный, из-за чего браузер по-разному обрабатывает анимацию синтезатора и анимацию без синтезатора, а производительность анимации без синтезатора не очень хорошая. 3. Однопоточная модель не может в полной мере использовать многоядерную производительность современных аппаратных архитектур, особенно архитектур ARM. 4. Дизайн асинхронной растеризации, при прокрутке длинного списка неизбежно появится явление белого экрана.

Есть ли способ получить лучшее из обоих миров? Возникновение реагирования родного / WEEX принесла свет на передние разработчики.

React Native/Weex использует движок JS для вызова компонентов на стороне Native для выполнения соответствующих функций. И React Native, и Weex позволяют внешним разработчикам использовать JS для разработки бизнес-логики, использовать VDOM для описания структуры документа и взаимодействовать с подмножествами CSS для настройки стилей, стилей и разделения шаблонов.

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

В системе WebView выполнение JS, Layout и Paint все находится в MainThread, и они влияют друг на друга, что приведет к зависанию интерфейса при выполнении сложных задач.

Преимущество этого решения заключается в максимальном повторном использовании интерфейсной экосистемы и собственной экосистемы.

В Alibaba крупномасштабное приложение Weex даже удвоило трафик на уровне 1,1 миллиарда.

▐ Этап 3: Самовытяжной двигатель

Что такое самозавлеченный двигатель?

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

На последнем этапе фронтенд-разработчики уже могут использовать движок JS для управления собственным пользовательским интерфейсом, зачем вам движок для самостоятельного рисования?

React Native/Weex полностью экспортирует систему Native View во внешнюю систему.В процессе упаковки Android/iOS Native View возникает множество непреодолимых препятствий. Например: проблемы согласованности с двумя концами, которые трудно сгладить, сложные возможности стилей, которые трудно реализовать, и анимацию макета необходимо выполнять дважды (макет Weex Core и собственный макет Android Native). Стоимость упаковки компонентов становится все выше и выше по мере увеличения сложности, и трудно превысить ограничения Native View, чтобы предоставить более подробные стандартные возможности W3C.

Flutter родился в 2018. Он создает набор компонентов для кроссплатформенной разработки с помощью языка Dart. Все компоненты нарисованы самостоятельно на основе движка Skia. Производительность сравнима с View of the Native. Он привлек всеобщее внимание и полностью подтвердил возможность создания механизма рендеринга пользовательского интерфейса, сравнимого с Native View, путем рисования и создания компонентов.

Однако в самом Flutter отсутствует функция динамического обновления. В сообществе также есть несколько проектов, изучающих динамические функции Flutter. Наша команда также внедряет ориентированный на интерфейс динамический движок Flutter: Kraken. В отличие от других решений, Kraken не основан Встроенная структура виджетов расширена, но стандартный API W3C расширен с нижнего уровня, что делает его более похожим на браузер и значительно снижает порог для использования Flutter веб-разработчиками.

Будущее: вернуться к истокам

Общая тенденция мира, если он будет разделен на долгое время, он будет объединен, а если он будет объединен на долгое время, он будет разделен. Мобильная фронтенд-разработка по сути является формой терминальной разработки, как бы ни менялись контейнеры, фреймворки и языки, среди фронтенд-разработчиков никогда не изменится только стандарт W3C. Автор считает, что с развитием Интернета технология браузера станет более общим стандартом программирования пользовательского интерфейса после решения ряда проблем с производительностью и опытом.

PWA

В первые годы Google усердно работал в этой области и запустил концепцию PWA (Progress Web Application).

Предоставляя стандартизированную структуру в мобильных браузерах, PWA обеспечивает взаимодействие с пользователем, аналогичное нативному приложению в веб-приложении. Его функции на самом деле представляют собой набор стандартов W3C и частных стандартов.Проще говоря, PWA поддерживает:

1. Автономная загрузка: с помощью механизма кэширования, предоставляемого Service Worker и т. д., пользователи могут напрямую читать автономные ресурсы, когда сеть отключена или слаба.

2. Фоновый резидентный процесс: В нормальных условиях после закрытия страницы браузера завершается весь его жизненный цикл, а также освобождается память. Service Workers позволяют страницам продолжать работать, даже если они закрыты, что гарантирует такие вещи, как автономное кэширование, упреждающую отправку и т. д.

3. Уведомление о сообщении: позволяет веб-разработчикам реализовать активный механизм push-уведомлений, подобный приложению.

4. Функциональные особенности других мобильных приложений, такие как сохранение значков непосредственно на рабочем столе, позволяют пользователям открывать приложения PWA так же, как они обычно используют приложение; элементы браузера по умолчанию в пользовательском интерфейсе могут быть скрыты, а веб-контент может быть скрыт. отображается в полноэкранном режиме, визуально делая веб-приложение более похожим на нативное приложение, иногда вы не можете сказать, веб-приложение это или нативное приложение.

PHA

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

Так родилась концепция PHA (Progress Hybird Application), которая представляет собой прогрессивную стратегию улучшения гибридных приложений, предоставляющую дополнительные возможности для конечного тестирования и повышающую производительность рендеринга и удобство использования WebView. Вообще говоря, популярные небольшие программы и быстрые приложения — все это реализации PHA.

Внутри отдела Amoy мы также внедряем легкое решение PHA, и мы добились хороших результатов в большом продвижении.Я хочу написать отдельную статью о PHA, чтобы объяснить это позже.

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

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

Основываясь на недавних горячих возможностях WebAssembly, браузеры могут преодолевать ограничения JavaScript и иметь больше возможностей для воображения.

Найм на работу!

Мы являемся основателями популярных проектов с открытым исходным кодом, таких как Rax, Feibing (ICE), GCanvas и т. д. Мы являемся запутанностью любви и ненависти, которой вы не можете избежать, когда пишете интерфейс на Али. Вы хотите заложить прочный фундамент фасадной конструкции группы, чтобы сделать 100-метровую высотку более прочной? Вы хотите, чтобы ваш код приносил пользу сообществу и вызывал восхищение? Хотите подсмотреть красоту движка рендеринга следующего поколения (Kraken) и контейнера приложений Taobao нового поколения (PHA)? Что ж, то, что вы видите сейчас, является единственным правильным ответом.

Скучный код один и тот же, а интересные работы - одна на тысячу. Будущее терминальной архитектуры такое широкое, и всем нужна ваша помощь. Добро пожаловать в команду фронтенд-архитектуры отдела Али Тао!

Мы являемся техническим отделом отдела Alibaba Tao — большой команды по технической архитектуре.Мы искренне приглашаем всех видов мелких партнеров присоединиться к нам и вместе делать великие дела!

Резюме можно отправить по почте zhuoling.lcl@alibaba-inc.com, с нетерпением жду вашего контакта.