Автор: Fan Huaiyu (соучредитель и технический директор Qingmang)
Спасибо за приглашение Nuggets, у меня есть возможность поделиться с вами некоторыми конкретными практиками создания небольших программ в Qingman.В сочетании с нашим техническим выбором в процессе создания журнала Qingman, я сосредоточусь на том, чтобы рассказать о некотором опыте интерактивной реализации. журнала Цинман.
Глядя на техническое развитие всего клиента, можно обнаружить, что с точки зрения «конечной» технологии он становится все тоньше и тоньше. Оказывается, при разработке Windows вы можете столкнуться с большим количеством компакт-дисков, очень толстыми документами MSDN и огромными API-интерфейсами Windows32. Что касается апплета, то он становился все тоньше и тоньше, а деталей для понимания стало меньше. Это связано с тем, что фреймворк на платформе будет становиться все толще и толще, и нашим разработчикам будет все проще запускать платформу. Сегодняшняя тенденция развития «конца» заключается в том, что где пользователь, там и «конец».
Компания Qingmang запустила продукты, связанные с мини-программой, в первый же день ее выпуска, в том числе журнал Qingmang, который рекомендует пользователям высококачественный контент. код.
Помимо представления и рендеринга контента, также очень важно обрабатывать все взаимодействия с пользователями, на это, собственно, и приходится большой объем фронтенд-разработки, поэтому кому-то фронтенд-разработка может надоесть, а кому-то может чувствовать себя очень привлекательным. Для интерактивности на самом деле нет серебряной пули. В разработке программного обеспечения всегда нужна «серебряная пуля», то есть «когда я знаю секрет, я могу сделать это очень легко, и все может быть очень шикарно», но ее не существует. Там много практики, смешанной с деталями, включая многое из того, чем я делюсь с вами сегодня, это не звучит так волшебно или даже говорит, что некоторые из них вообще не работают, но это настоящая практика. Вы действительно должны сделать что-то хорошо, и многое из этого заключается в деталях.
Прежде всего, позвольте мне представить особенности платформы мини-программ, потому что вся фронтенд-разработка выполняется на одной платформе, и вы должны быть хорошо знакомы с этой платформой, так же, как и на сцене, вам нужно знать, где сцена есть, где свет, где звук и т.д. Вам необходимо понимать характеристики этой платформы, чтобы в дальнейшем чувствовать себя более комфортно.
Конструктивные особенности слоя взаимодействия мини-программы
По сравнению с другими платформами, с которыми я сталкивался, во-первых, я думаю, что Mini Program — это клиентская платформа, полностью управляемая данными. Например, теперь перейдите к веб-разработке или разработке для Android, если вам нужно нажать кнопку в интерфейсе, чтобы скрыть место, или нажать кнопку, чтобы расширить место, что бы вы сделали? Согласно модели MVC прямо сейчас, вы не можете пройти через Контроллер к Модели, затем изменить Модель и вернуться, вы не пойдете по этому пути. Вы обязательно будете использовать какие-то простые скрипты или трюки на интерфейсе, чтобы скрыть эту штуку и снова развернуть ее, это не повлияет на основную модель данных, и это очень удобно.
Но во всем апплете такого нет, вы не можете оперировать ни одним DOM-узлом, а значит, что бы вы ни делали, в том числе меняли какое-нибудь маленькое состояние интерфейса, вам нужно передать его на уровень логики через элемент управления Слой и используйте js для его передачи.Некоторые вычисления, а затем вызов функции setData для запуска сравнения изменений данных и повторного рендеринга интерфейса.Это вся управляемая ядром модель апплета. Откровенно говоря, многие части этой модели очень тяжелые, что ограничит вас в особенно гибких реализациях, но для наших разработчиков, только поняв эту модель, мы узнаем, какие аспекты требуют особого внимания при разработке.
Есть еще один момент, с которым все очень хорошо знакомы.Небольшая программа — это традиционный веб-компонент, смешанный с некоторыми нативными компонентами, то есть локальный компонент, реализованный на локальном языке, например, Objective C для iOS или Java для Android. разные. Технический маршрут, принятый апплетом, — это так называемый многоуровневый рендеринг.Нижний — это веб-слой, а верхний — собственный слой.Когда я перемещаю веб-слой, собственный слой получает некоторые события и пытается связь с веб-слоем, но они на самом деле есть задержка в середине.Эта задержка принесет много неприятностей, тем более, что этот слой является родным слоем, который всегда живет на веб-слое, что также принесет некоторые неприятности для дизайн взаимодействия и практика взаимодействия.
Еще одна особенность — одно окно.Конечно, другие платформы в эпоху мобильных устройств тоже такие же.На интерактивной странице мы будем иметь дело только с одним окном. Особенность апплета в том, что он полностью отменяет концепцию окна, и мы можем не ощущать существования окна. Если вы работали с Android, то знаете, что Android можно использовать как плавающее окно.Из-за ограничений механизма платформы апплета интерактивная форма плавающего окна не может быть реализована.
Вышеизложенное является важными особенностями дизайна взаимодействия платформы Mini Program, которые я обобщил.Это также очень важная отправная точка для нас, чтобы разработать дизайн взаимодействия и практику взаимодействия на платформе Mini Program.
Интерактивный практический пример Qingmang 1: реализация списков
Давайте поделимся некоторыми случаями джентльменов, сначала взяв много людей, использующих наиболее: список. Почему список важен? Логика списка — очень важное звено для понимания инженерами бизнеса и дизайна для инженеров. В традиционной сборке общего интерфейса список является самым сложным модулем, в котором будет много данных, его взаимодействие, передача данных и распределение событий будет сопряжено со многими проблемами, именно поэтому мы должны хорошенько подумать, как это сделать. И во многих сценариях производительность длинных списков является источником многих узких мест производительности, которым также необходимо уделить особое внимание.
Что такое список? Например, левая часть рисунка ниже — это очень очевидный список, который можно бесконечно загружать и постоянно прокручивать Мы думаем, что каждая карточка — это элемент списка. Картинка справа выглядит как страница сведений о содержании.На практике мы тоже делаем ее списком.Мы абстрагируем каждый ее абзац и отрисовываем в соответствии со списком.
Самая большая особенность апплета заключается в том, что он не имеет встроенного компонента списка. Мы только что говорили о MVC, и ядро MVC — это дизайн модели, то есть то, как выглядит модель данных во всем продукте, что реально влияет на время разработки. Если модель хорошо спроектирована, это как посадить дерево с растущими на нем ветвями.Если очень красиво абстрагировать все модели данных, то ветви на дереве, то есть View и Controller, реализовать будет очень легко. Если ваша модель вообще не абстрагирована, а вы просто подчищаете и начинаете интерактивную разработку, то даже если вы выберете множество красивых трансформаций в интерфейсном слое и будете использовать множество навороченных фреймворков, вам будет сложно уменьшить сложность кода.Степень повторного использования не высокая, поэтому и говорю, что если брать проект, то лучше начинать со списка, потому что модель данных списка обычно самая сложная, и список понятен , и весь продукт ясен.
В Qingmang, например, поток водопада только что, мы абстрагируем его в объект события.Конечно, мы не делаем этого при разработке всех небольших программ, потому что в других небольших программах бизнес отличается, и абстрактная модель может Также будет отличаться.Наша реализация вспомогательного списка также будет отличаться. В журнале Qingmang, поскольку существуют очень сложные типы карточек или различные типы стилей взаимодействия, мы абстрагируем различные типы данных в объект события, каждое событие будет иметь тип, а затем мы разработаем элемент управления списком вокруг события. Для конкретной реализации мы использовали шаблон WeChat для абстракции и инкапсуляции, потому что мы сделали этот проект слишком рано, когда у нас не было проектов с открытым исходным кодом, и мы могли только инкапсулировать все это сами.
Самое главное здесь — это на самом деле абстракция объекта события, которая является базовой моделью данных в продукте.Если вы разберетесь с этим, вы обнаружите, что позже все станет очень просто. В этом коде рендеринг каждой карты может иметь две разные реализации.Некоторые карты реализованы с помощью шаблонов, таких как single-card-*.В реализации мы будем напрямую использовать single-card для добавления конкретных типов для реализации элементов списка, например, статья с одной карточкой, изображение с одной карточкой, видео с одной карточкой и так далее. После того, как в WeChat появились пользовательские компоненты, мы поместили некоторые новые карты, которые были позже реализованы в пользовательских компонентах, например карту вселенной здесь, и мы использовали новый способ создания новых карт.
В первые дни, поскольку мы использовали Template для инкапсуляции элементов интерфейса, эта инкапсуляция включала реализацию любого взаимодействия. Поскольку в ранние дни WeChat не предоставлял никакого механизма инкапсуляции, теперь вы можете сделать это через различные фреймворки с открытым исходным кодом.Единственный способ в первые дни — это абстрагировать некоторые функции, связанные с взаимодействием интерфейса, в некоторые модули Mixin, а затем напрямую интегрируйте их в конфигурацию страницы, чтобы улучшить возможность повторного использования. Мы все еще используем эту схему, и она также является одной из наиболее часто используемых практических схем в небольших программах.
С другой стороны, инкапсуляция списка также предназначена для унификации связанных компонентов интерфейса, таких как унифицированный стиль загрузки, унифицированный стиль пустой страницы, логика перелистывания страниц и многоуровневая вложенность и т. д. Например, когда все данные загружены, в списке определяется способ перелистывания страниц, который определяет способ взаимодействия между клиентом и сервером продукта. В Qingmang при перелистывании всех страниц на стороне сервера будет использоваться режим «Следующий URL», сервер сообщит клиенту, есть ли следующая страница, и если клиент прокрутит страницу до конца, будет загружена следующая страница. Это говорит нам о том, что если сервер имеет унифицированный шаблон API, разработка клиента станет проще, а абстракция и повторное использование могут быть выполнены более полно. Конечно, это обратное также ограничивает серверную сторону, которая требует, чтобы серверная сторона предоставляла унифицированный или интегрированный API, чтобы его можно было внедрить во все команды компании, что может повысить общую производительность. Для фронтенда только такое решение может сильно упростить разработку.
В реализации списка также есть пункт и небольшая характеристика программы, как встроить нативный компонент в список, типа хочу жить в списке, хочу встроить карту в список, встроить поле ввода , поле ввода Как это сделать? Если вы используете механизм рендеринга нативных компонентов WeChat, если вы встраиваете видео в поток контента, оно может охватывать множество диалогов, которые вы хотите воспроизвести; возможно, вы хотите реализовать быструю прокрутку страницы, видео будет иметь очень медленное перетаскивание, это влияет на впечатление от продукта.
В реализации списка все еще есть некоторые проблемы, связанные с обработкой данных и состояния. Каждый элемент списка будет содержать множество элементов.Например, в элементе списка будет основная информация о статье.При этом в правом нижнем углу есть интерактивная кнопка.После нажатия пользователем, состояние кнопки Для Qingmang это «Mark», и ничто из этого не является собственными данными и будет меняться при взаимодействии с пользователем, отсюда и название состояния. На ранних этапах разработки небольших программ вы, возможно, не сможете различить состояние и данные и поместить данные и состояние в одну и ту же модель данных, потому что логика реализации очень сложна, и в чистых данных будет много проблем. управляемый режим.
Практический опыт Qingmang заключается в разделении данных и состояний. Например, после получения данных мы разделим данные на две части: одна часть — собственные данные, которые не изменятся при взаимодействии с пользователем и хранятся в виде списка, а другая — состояние, которое изменится при взаимодействии с пользователем. , здесь мы будем использовать словарь для хранения. В коде, показанном на рисунке, и ui-switch, и подписанные объекты хранят информацию о состоянии.Когда пользователь оперирует определенным элементом, ему нужно только изменить определенное значение идентификатора, соответствующего переключателю на уровне управления, и интерфейс можно быстро обновить.. Это может показаться очень небольшой оптимизацией, но если вы сможете контролировать ее во всех взаимодействиях с интерфейсом, преимущества могут быть огромными. Еще одна его особенность — централизация. Например, для воспроизведения видео, которое мы только что видели, мы разрешаем одновременное воспроизведение только одного видео. После того, как пользователь нажмет на видео, другие видео перестанут воспроизводиться. В это время вам нужно только очистить все состояние в слой управления и сброс состояния интерактивного объекта.Ну, это все вещи, которые звучат относительно подробно, но очень важны на практике.
Последний вопрос — оптимизация производительности длинных списков, это не столько обмен опытом, сколько обмен уроками. В журнале Qingmang мы используем множество длинных списков, водопады с бесконечной прокруткой, очень длинные статьи и так далее. Все это приведет к тому, что список станет длиннее и вызовет заикание. Почему? Что касается механизма рендеринга апплета, от установки данных до рендеринга интерфейса, то есть от вызова функции setData до возврата функции setData, есть две вещи, которые могут отнимать много времени. Какие данные обновляются и какие элементы интерфейса связаны с этими данными. Другое дело — обновить интерфейс: чтобы представить обновленные данные, сначала отрендерить их на виртуальной ноде, а потом выложить на фронтенд для презентации. Самая большая проблема с небольшими программами заключается в том, что эти две ссылки слишком «черные ящики», и они сообщают разработчикам очень мало информации, поэтому их труднее оптимизировать. Мы знаем, что рендеринг журнала Qingmang Magazine полностью тратится здесь, поэтому будут задержки, но мы не можем знать, на что уходит время.
Таким образом, план оптимизации производительности, который мы составили, состоит в том, чтобы попытаться продолжать выполнять два пункта, делать меньше логики и смотреть, улучшится ли производительность. Сначала мы ставим точку производительности на тот факт, что setData не может быть добавлен. Хотя setData может изменять элементы в списке, как только ему нужно добавить или удалить элементы, его необходимо заменить. Это основная проблема всей управляемой данными WeChat. модель. Здесь мы пытаемся использовать фиксированное количество элементов списка. Во-первых, мы виртуализируем сто элементов списка, а данные могут быть только в десяти. Если необходимо добавить новые элементы, нам нужно только изменить их, а не заменить их все. Окончательный вывод - эффект есть, но небольшой, а стоимость разработки сильно возросла. Позже мы добавили больше проблем с производительностью при рендеринге и обнаружили, что эффективным решением является упрощение дизайна интерфейса с меньшим количеством элементов для рендеринга, и производительность будет намного выше. Таким образом, в длинном списке большим узким местом по-прежнему является рендеринг DOM. Апплет не предоставляет механизма повторного использования элементов для списка, что заставляет его полностью отображать весь список. Ему все равно, должен ли элемент списка находиться в списке. Интерфейс или нет.Представление, необходимость или не показ его пользователю может вызвать много проблем с производительностью.
Здесь у нас также нет полного опыта, это скорее урок. Для всех, если вы можете предвидеть, что ваш продукт будет иметь длинный список, вы можете заранее подумать, хотите ли вы уменьшить сложность дизайна элемента списка, контролировать количество узлов DOM для каждого элемента списка и уменьшить количество Узлы DOM на некоторых узлах DOM Связывание данных и событий и т. д., что может повысить производительность продукта. Конечно, рендеринг апплета в целом остается черным ящиком, и мы можем использовать меньше методов оптимизации. Подводя итог, я больше всего хочу с вами поговорить о том, что интерактивная разработка и бизнес неразделимы, и нам нужно совершенствоваться вместе с дизайном, серверной частью и продуктами, а также понимать больше потребностей в техническом дизайне.
Интерактивная практика Qingmang 2: Реализация глобального окна
Мы знаем, что апплет WeChat — это интерактивная платформа с одним окном, так что же такое глобальное окно? Например, карта обмена слева вверху, ее нужно вызвать на любой странице журнала Qingmang, чтобы поделиться страницей. Справа наш собственный тост. Во многих случаях нужный нам тост отличается от официального апплета WeChat. В этом случае его нужно реализовать на основе глобального окна. Но поскольку в апплете нет механизма глобального окна, единственный способ для нас — имитировать глобальное окно, помещая компонент на каждую страницу и вызывая его в любое время.Мы называем это глобальным компонентом. В этой части я сосредоточусь на инкапсуляции компонентов и на том, что является лучшим компонентным решением в апплете.
Вы только что слышали много сторонних фреймворков, в Qingmang мы в основном реализуем их на основе нативных механизмов. Существует два распространенных нативных метода: на основе шаблона и на основе пользовательских компонентов.Мы очень часто используем эти два метода инкапсуляции. Как видно из этого кода, некоторые из наших карт упакованы с пользовательскими компонентами, а некоторые индикаторы загрузки могут быть упакованы с шаблонами. Но если я сделаю его глобальным компонентом и позволю включать его на каждую страницу, оба метода потребуют от меня копирования большого количества повторяющегося кода на каждой странице, возможно, сотен строк.Как только мне нужно изменить его, мне нужно изменить весь небольшой код одновременно десятки страниц в программе. Мы использовали эту схему в первые дни, но обнаружили, что эффект был не очень хорошим, и ее было слишком сложно поддерживать. Итак, мы перепроектировали его и обнаружили, что в апплете есть несколько более простых решений инкапсуляции, которые более подходят, то есть решение включения, которое вы можете редко использовать сегодня, что эквивалентно непосредственному введению еще одного блока кода. Это очень традиционное решение. Сейчас мы делаем упор на компоненты и инкапсуляцию. Нам нужно красиво инкапсулировать и делать границы компонентов четкими. Но на самом деле в таком сценарии мы нарушаем ограничения некоторых простых компонентов. Полегче.
Мы напишем глобальный файл окна с именем global.wxml и поместим сюда данные и реализацию всех глобальных компонентов, которые будут использоваться в апплете.Код на картинке наложен, но расширение все равно относительно длинное.Потому что другие Шаблоны больше нельзя использовать для инкапсуляции в include. Соответственно, также предоставляется некоторый код js.Мы инкапсулируем файл action.js, который будет включать в себя управление различными глобальными компонентами, такими как модальные диалоги, диалоги ввода, тосты, общие карточки и так далее. В конечном итоге на каждую страницу нужно добавить только две строки: одну include global и одну Mixin, action.js, что решает проблему.
Этот пример очень маленький, и то, о чем я хочу рассказать, — это идея инкапсуляции компонентов. При техническом проектировании вы всегда должны учитывать, как инкапсулировать компоненты и как их повторно использовать, потому что это важно для всей фронтенд-разработки и разработки на стороне сервера.Если вы не используете повторно или не пытаетесь сделать некоторые абстракции, код в долгосрочной перспективе станет очень рассеянным. , трудно поддерживать, трудно читать. Но как делать инкапсуляцию, как заниматься практикой? Помимо очень красивого абстрагирования компонентов, вы также можете попробовать некоторые решения инкапсуляции с более размытыми границами, которые могут значительно сократить код и упростить его изменение и поддержку. Например, в предыдущем примере, если я хочу изменить стиль глобального компонента, мне нужно изменить только global.xml, а место, где вызывается файл, менять не нужно. -закрытый принцип, это реализация, удовлетворяющая принципу открытого-закрытого.Стратегия.
Интерактивный практический пример Цинмана 3: Марк
Мы попали во множество ловушек.Когда пользователь перемещает палец, чтобы изменить выбранную область, если мы используем условное суждение WeChat wx:если изменить цвет фона или тому подобное, это, вероятно, изменит структуру всего дерева управления и все взаимодействие. Интерфейс придет в ужасное состояние и полностью перестанет отвечать. Мы предполагаем, что это ошибка, которая вызвала нижний уровень WeChat. Так что в таком взаимодействии лучше всего менять только CSS, а структуру элементов интерфейса стараться не менять.
Вот деталь.После срабатывания области выбора метки настройки, когда мы перетаскиваем палец, весь интерфейс не прокручивается, и весь интерфейс не может снова начать прокрутку, пока мы не отпустим палец. В это время используется процесс обработки только что упомянутого механизма распространения событий.В апплете, пока вы устанавливаете функцию захвата, вы должны захватывать событие.В отличие от других платформ, вы можете контролировать, нужно ли вам использовать возвращает значение функции захвата Capture, и если вы его не захватите, вы не сможете потом прервать прокрутку всей страницы. Что делать тогда? Позже мы использовали еще несколько методов Hack, мы перешли к динамическому изменению имени связанной функции захвата. Когда вам нужно захватить, установите требуемую функцию, а когда вы остановите захват, установите функцию захвата в пустую строку, которая может обойти его механизм захвата. В это время вы можете контролировать, когда интерфейс может прокручивать страницу и когда можно настраивать только выбранную область.
Мы много раз пересматривали это взаимодействие с метками.В первые дни его было очень сложно реализовать, потому что не было механизма для запроса каких-либо элементов DOM. Теперь WeChat предоставляет API для запроса узлов DOM. Я могу примерно знать, где находятся узлы DOM. Теперь мы будем многократно использовать функцию запроса, чтобы понять состояние интерфейса и настроить взаимодействия, которые могут быть выполнены. В течение всего процесса внедрения Марка между инженерами и дизайнерами было много дискуссий, дизайнеры переосмысливали некоторые интерактивные решения в соответствии с техническими ограничениями и постоянно пытались внедрить какие-то Hack-подобные средства для реализации этих решений. Если вы хотите сделать взаимодействие более продвинутым, вам, несомненно, потребуется спроектировать и реализовать его таким образом, и вы также наступите на ямы некоторых платформ.Этот опыт также можно использовать для ознакомления.
Три описанных выше случая не все чисто технические, но есть много нетехнических моментов. Взаимодействие кажется чисто фронтенд-реализацией, но на самом деле его реализация — дело всей команды, включая разработку продукта, дизайна и внутренних API. Это также интерактивная интеграция возможностей платформы и дизайна продукта.
Кроме того, на платформе Mini Program нам необходимо уделить особое внимание дизайну модели данных.Мы должны сделать так, чтобы вся модель данных хорошо понимала бизнес и четко проектировала всю модель данных.Что такое данные, что такое состояние, которое должно быть изолировано, а которое должно быть помещено в «Вместе», различение этих вещей может значительно упростить всю разработку внешнего интерфейса. Кроме того, мы должны быть очень осторожны при работе с нативными компонентами, и нам нужно избегать некоторых дизайнерских решений, иначе это принесет ряд ошибок.
Это то, чем я делюсь с вами сегодня. Это беззаботная практика. Я считаю, что она не будет полностью соответствовать вашим конкретным бизнес-потребностям и целям. Но я также надеюсь, что сегодняшний обмен может вдохновить вас.Если вы сможете использовать некоторые из них, нам этого будет достаточно.
Спасибо вам всем.