Пикассо: открывая будущее больших интерфейсов

        “道生一，一生二，二生三，三生万物。” —— 《道德经》

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

Picasso возник благодаря нашему переосмыслению больших интерфейсных практик для достижения высокопроизводительного рендеринга страниц с лаконичной и эффективной архитектурой. На практике переход от технологии Native к технологии Picasso можно использовать даже как метод оптимизации производительности; в то же время Picasso совершила прорыв в работе, охватывающей апплет и сеть, и ожидается, что она будет использоваться в четырех терминалы (Android, iOS, H5, апплет WeChat) на основе унифицированной крупномасштабной интерфейсной практики, для достижения высокопроизводительной крупномасштабной интерфейсной практики, и в то же время с сильной способностью выражения DSL макета Пикассо и Технология генерации кода Пикассо может еще больше повысить производительность.

Клиентская динамизация

В 2007 году был выпущен iPhone первого поколения от Apple, и его появление «переопределило мобильный телефон» и открыло прелюдию к бурному развитию мобильного Интернета. Мобильные технологии, такие как Android и iOS, разрушили ситуацию, когда технология разработки веб-приложений вот-вот доминирует в реках и озерах После этого появилось большое количество приложений. Технология мобильной разработки обеспечивает пользователям лучшее использование мобильного терминала и интерактивный опыт, но ее «статическая» модель разработки ложится тяжелым бременем на интернет-команду, которой необходимо быстро выполнять итерации.

Клиентский «статический» режим разработки

По сравнению с технологией веб-разработки, технология клиентской разработки по своей сути «статична», и мы можем рассматривать ее с двух сторон — пространства и времени.

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

Время компиляции слишком велико.По мере увеличения сложности кода время компиляции интеграции увеличивается. Усилия НИОКР были потрачены на ожидание компиляции, а проверка интеграции стала огромной проблемой.
Пакеты приложений растут слишком быстро.Это соответствует быстрому развитию Интернета, но резко противоречит расширению числа новых пользователей и итеративной эволюции бизнеса.
Связь во время выполнения является серьезной.В теле пакета интегрированного выпуска ненормальное поведение, такое как сбой и утечка памяти, вызванные любым функциональным компонентом, приведут к снижению удобства использования всего приложения, что приведет к большим потерям.
Интеграция затруднена.Повторное использование кода и связь между бизнес-направлениями, бизнес-уровнем, уровнем инфраструктуры и базовым уровнем обслуживания сложны, и необходимо разделить значительный объем кода уровня совместимости, что влияет на общую эффективность разработки.

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

Такая «статическая» модель разработки отрицательно скажется на эффективности НИОКР и качестве работы. Для разработки традиционных приложений для настольных ПК относительно приемлема может быть статическая модель НИОКР. Но для бурно развивающейся индустрии мобильного Интернета противоречие между статичным режимом разработки и гибкими итеративными требованиями к выпускам становится все более заметным.

Тенденция клиентского динамизма

Как решить проблемы, вызванные «статическим» режимом разработки на стороне клиента?

Самый ранний ответ отрасли — использовать веб-технологии

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

Еще одна идея, выдвинутая отраслью, заключается в оптимизации веб-реализации.

Используя гибкость и высокую производительность технологии мобильного клиента, «стандартный веб-браузер» перестраивается так, чтобы «веб-технология» одновременно обладала высокой производительностью, хорошим интерактивным опытом и динамичным характером веб-технологии. На этой волне технологий Facebook снова стал пионером, запустив технологию React Native (сокращенно RN). Тем не менее, дизайн RN немного странный: RN не совместим со стандартной сетью и даже не пытается согласовать двустороннее поведение Android и iOS. Следствием этого является то, что все «крабоеды» компании должны делать вторичную разработку, чтобы в основном согласовать требования обеих сторон. В то же время мы также должны сделать все возможное, чтобы заплатить за проблемы совместимости RN, проблемы со стабильностью и даже проблемы с производительностью.

И наш ответ Пикассо

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

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

Динамический принцип Пикассо

Разработчики приложений Picasso пишут логику макета, используя общий код DSL макета на основе языка программирования. Основываясь на заданной ширине и высоте экрана и бизнес-данных, логика макета вычисляет информацию о макете, информацию о структуре представления, текст, URL-адрес изображения и другую необходимую информацию для бизнес-рендеринга, которая точно адаптируется к экрану и бизнес-данным. PМодель. В качестве промежуточного результата рендеринга макета Picasso PModel соответствует окончательной визуализированной структуре представления один за другим; механизм рендеринга Picasso рекурсивно строит исходное дерево представления в соответствии с информацией PModel и завершает заполнение информации бизнес-рендеринга, тем самым завершая Процесс рендеринга Пикассо. Следует отметить, что механизм рендеринга не выполняет расчеты адаптации и использует DSL макета для выражения требований к макету при выполнении расчетов макета, что является так называемым «выражением является расчетом».

В более широком плане разработчики Picasso используют TypeScript для написания приложений Picasso в VSCode; после отправки кода проверка и упаковка Lint могут быть автоматизированы с помощью системы непрерывной интеграции Picasso, а публикация в оттенках серого выполняется в системе распространения Picasso. он доставляется клиенту в виде пакета JavaScript и интерпретируется и выполняется Picasso SDK для достижения цели динамической бизнес-логики клиента.

В процессе разработки приложений система статических типов TypeScript в сочетании с подключаемыми модулями VSCode и Picasso Debug позволяет получить опыт разработки, сравнимый с традиционными IDE для разработки мобильных клиентов с отладкой intellisense и точками останова. Система Picasso CI взаимодействует с системой типов TypeScript, чтобы избежать низкоуровневых ошибок и облегчить многостороннее и многогрупповое сотрудничество; в то же время она может эффективно решить проблему длинного хвоста поддержки возможностей посредством «совместимых вычислений».

Макет Пикассо DSL

Пикассо провел систематический сравнительный анализ основных механизмов и систем компоновки на мобильном терминале. Эти системы включают:

Обычно используется в развитии AndroidLinearLayout.
Используется внешним интерфейсом и аналогичными динамическими фреймворками Picasso.FlexBox.
Рекламируется AppleAutoLayout.

Среди них AutoLayout, официально запущенный Apple, не имеет простого в использовании DSL, поэтому мы напрямую вносим свой вклад в сообщество мобильных разработчиков.AutoLayout DSLПланы прилагаются для сравнения.

Во-первых, с точки зрения производительности система AutoLayout является худшей: с увеличением сложности требований время «расчёта макета» увеличивается в геометрической прогрессии. По сравнению с AutoLayout, FlexBox и LinearLayout имеют большие преимущества в производительности. Однако LinearLayout и FlexBox заставят разработчиков добавлять ненужные слои представления к концепциям, которые им нужны с точки зрения макета, что приведет к проблемам с производительностью рендеринга.

С точки зрения гибкости макеты LinearLayout и FlexBox имеют серьезные концептуальные ограничения. Один делает упор на линейное расположение, а другой делает упор на такие концепции, как блочный режим и масштабирование.Когда эти модели не соответствуют требованиям к макету и концепциям модели, они должны вмешиваться с языками программирования. А из-за обособленности системы раскладки такое вмешательство сделать непросто, что в определенной степени сказывается на гибкости и выразительности раскладки. С DSL, разработанным на основе общего языка программирования и логики компоновки AutoLayout, теоретически может быть достигнута наибольшая гибкость. Но эти три системы компоновки пытаются решить «проблему выражения логики компоновки декларативным способом», а введение DSL на основе языка программирования делает механизм расчета компоновки излишним.

Ядром макета Picasso DSL является:

Разработан на основе общего языка программирования.
Поддерживает концепцию якорей (на фото выше).

Используя концепцию точки привязки, вы можете просто и четко установить «привязанную» позицию вида двух точек привязки, которые не находятся в одном и том же направлении оси координат. В то же время якоря могут обеспечить семантическую поддержку для описания «относительных» позиционных отношений. На самом деле, более гуманным описанием необходимости макета было бы что-то вроде «B находится справа от A, с интервалом 10, выровнено по верхнему краю», а не «A и B находятся в горизонтальном контейнере макета ...» . Концепция привязки устраняет семантический разрыв между описанием требований и базовой реализацией системы представления посредством минималистской реализации.

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

1 Выравнивание по центру:

    view.centerX = bgView.width / 2
    view.centerY = bgView.height /2

2 Выровнять по правому краю:

    view.right = bgView.width - 10
    view.centerY = bgView.height / 2

3 относительное расположение:

    viewB.top = viewA.top
    viewB.left = viewA.right + 10

4 «Необычных» макета:

    viewB.top = viewA.centerY
    viewB.left = viewA.centerX

Логика компоновки привязки Пикассо имеет наиболее гибкую возможность выражения в теории и может удовлетворить требования к компоновке выражения «что вы хотите, то и получаете». Но иногда мы обнаруживаем, что такая выразительная сила является «чрезмерной» в определенных сценариях. Аналогично требованиям макета на рисунке ниже, 4 элемента представления должны быть расположены горизонтально, с интервалом 10 и выравниванием по верхнему краю; может быть следующий код логики макета привязки:

    v1.top = 10
    v1.left = 10
    v2.top = v1.top
    v3.top = v2.top
    v4.top = v3.top
    v2.left = v1.right + 10
    v3.left = v2.right + 10
    v4.left = v3.right + 10

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

    hlayout([v1, v2, v3, v4],
           { top: 10, left: 10, divideSpace: 10 })

Внимательные люди могут обнаружить, что это то же самое, что и классический LinearLayout на платформе Android. В соответствии с функцией hlayout существует также vlayout, представляющая собой пару родственных функций, которые почти полностью реализуют семантику Android LinearLayout.Логика реализации составляет менее 300 строк.Упор здесь делается не на две функции макета, а о неограниченных возможностях абстрактного выражения макета Пикассо DSL. Если бизнес-сценарий требует концептуальной модели, подобной Flexbox или другой, бизнес-приложения могут быстро реализовать ее по мере необходимости.

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

Видно, что DSL компоновки Picasso превосходит вышеперечисленные системы компоновки с точки зрения потенциала производительности и выразительности. Дизайн макета DSL Пикассо является краеугольным камнем способности Пикассо построить высокопроизводительную динамическую структуру с четырьмя терминалами.

В то же время, благодаря выразительным и расширяемым возможностям DSL макета Picasso, Picasso также обладает уникальными преимуществами в области автоматического создания кода макета, а сгенерированный код более удобен в сопровождении и расширяем. С популярностью Пикассо процесс «визуальной реставрации» в нынешних фронтенд-исследованиях и разработках станет историей, а опыт фронтенд-разработчиков также освободится от повторяющейся работы по «копированию» визуальных набросков.

Высокопроизводительный рендеринг Picasso

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

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

Расположение якоря Пикассо позволяетВыражение макета и расчет макета происходят одновременно. Избегаются избыточные и повторяющиеся процессы расчета макета.
Философия компоновки Пикассо делаетИерархия плоского представления. Все представления независимы, без избыточных иерархий для представления логики макета.
Дизайн Пикассо поддерживаетпроцесс предварительных вычислений. Часть процесса, который изначально должен быть рассчитан в основном потоке, может выполняться в фоновом потоке.

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

Применение Пикассо в Meituan

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

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

В дополнение к постоянному обслуживанию Picasso SDK, системы непрерывной интеграции Picasso, включая отладку точек останова на основе VSCode, Liveload и других основных цепочек инструментов разработки, команда Picasso также предоставляет единую систему распространения для группы, закладывая прочную основу для большого передняя команда в группе для выполнения динамической практики Пикассо прочный фундамент.

В настоящее время ведущий BG в приложении Picasso в группе добился динамической технологии Picasso, охватывающую более 80% развития бизнеса. Техническая команда достигла быстрого развития.

Перечислите некоторые случаи применения Пикассо в Meituan:

Пикассо открывает большое фронтенд-будущее

Пикассо добился успеха в практике динамики на стороне клиента, решая различные болевые точки, вызванные традиционной «статичной» моделью исследований и разработок на стороне клиента. Обобщить:

Если хочешьГибкий релиз, используя Пикассо.
Если хочешьвысокое качество доставки, используя Пикассо.
Если хочешьОтличный пользовательский опыт, используя Пикассо.
Если хочешьвысокая производительность, используя Пикассо.
Если хочешьАвтоматически генерировать код макета, используя Пикассо.
Если хочешьвысокая производительность, используя Пикассо.

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

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

Picasso еще не является открытым исходным кодом. Если вы заинтересованы в Picasso, добро пожаловать в большую семью Dianping.

об авторе

Xiaoyan Picasso, руководитель основной группы SDK, восьмилетний опыт разработки мобильных приложений, присоединился к Dianping в 2012 году. Команда разработчиков ядра Picasso SDK стремится исследовать лучшие динамические решения на стороне клиента, вносить и поддерживать SDK Picasso с высокой производительностью и надежностью, а также продвигать руководство и разработку приложения и экосистемы Picasso.

Руководитель проекта Давэй Пикассо, директор по мобильным технологиям платформы Dianping, платформа Dianping продолжает поставлять продукты платформы Dianping, постоянно выпуская фреймворки и решения для поддержки мобильных технологий группы; Команда мобильных технологий платформы Dianping также представляет собой обширную команду Пикассо, комплексную. Цепочка инструментов Picasso, система непрерывной интеграции Picasso, система дистрибуции Picasso, основные компоненты пользовательского интерфейса Picasso и платформа комментариев будут продолжать способствовать динамичному развитию мобильного бизнеса группы.