содержание:
1. Зачем использовать горячий выпуск;
2. Статус отрасли;
3. Горячий выпуск общего плана дизайна;
4. Он-лайн функция и ситуация с данными;
5. Проблемы, возникающие при использовании;
6. Что нужно сделать потом;
1. Зачем использовать горячий выпуск
1. Ограничения в реальном времени
Как трансграничное приложение для электронной коммерции, Koala с самого начала обречено на ограничения условиями политики, что часто приводит к необходимости внесения некоторых изменений в режиме реального времени. В настоящее время эти потребности в режиме реального времени должны быть решены с помощью прямой версии приложения.Не только цикл выпуска является длительным, но и обзор рынка приложений требует много времени, а скорость обновления пользователей не высока.
2. Новые функции зависят от обновлений
Когда в планировании продукта упоминаются некоторые новые функциональные сценарии, он должен быть разработан в рамках полного итеративного процесса, и, наконец, выпускается новая версия, позволяющая пользователям использовать новые функции, а цикл разработки и тестирования является длительным. В то же время пользователи должны полагаться на обновления, если они хотят использовать новые функции. Невозможно сделать новые функции доступными для пользователей более старых версий.
3. Ошибка не может быть исправлена в горячем режиме
В процессе мобильной разработки часто возникают проблемы с онлайн-логикой или проблемы с зависанием, вызванные непродуманностью.Как правило, они решаются путем переупаковки и выпуска маркета приложений.В настоящее время удобнее решать проблему с помощью патчей. Динамическое решение также может лучше исправлять ошибки за счет тепловой генерации. Просто и эффективно.
4. Высокая стоимость мультитерминальной совместной работы
В настоящее время весь мобильный рынок разделен на android и ios. Когда спрос возрастет, два разработчика android и ios будут одновременно уведомлены о проведении проверки спроса и итерации функций. Всегда будут различные проблемы со связью в процесс коммуникации и реализации спроса.Эффект реализации спроса не является равномерным, и в то же время два разработчика будут тратить рабочую силу. Благодаря динамическому решению обе стороны могут использовать один и тот же набор кодов для решения своей собственной логики, что может сэкономить много рабочей силы.
2. Статус отрасли
Двумя популярными решениями для горячего выпуска являются React Native от Facebook и Weex от Ali.
Сравнение двух схем:
Тот же пункт:
1. Идея обоих одинакова, путем преобразования js в Virtual-dom и последующего сопоставления его с соответствующим компонентом представления Native;
2. Следуйте стандарту W3C, чтобы достичь унифицированного JSEngine и DOM API, и можете разрабатывать собственные страницы и приложения в форме Интернета (HTML + CSS + JS);
3. Все могут выполнять трехтерминальный рендеринг и динамическое распределение функциональных модулей;
разница:
1. Языки DSL верхнего уровня разные.Двумя популярными интерфейсными фреймворками являются React и Vue.React Native использует собственный React, а weex использует vue;
2. RN поддерживает как платформы ios, так и Android, а веб-сторона должна поддерживаться и совместима сама по себе, Weex заявляет о поддержке трех терминалов, но все еще есть много совместимых задач;
3. RN упаковывает базовую часть синтаксического анализа и бизнес-логику вместе при упаковке, поэтому файл js будет относительно большим, в то время как weex упаковывает только бизнес-часть, а конкретный процесс синтаксического анализа находится в SDK, поэтому пакет будет относительно небольшим. ;
Опыт использования: Мы провели исследование обеих схем и выяснили, что RN по-прежнему относительно требователен в процессе написания, не так быстр, как Vue, а RN больше похож на новый язык, он предоставляет разные компоненты для разных терминалов, а Weex предпочитает что эта работа выполняется нативными средствами, и три конца страницы weex используются одинаково; и производительность компонента списка, предоставляемого RN в то время, не очень хороша, а производительность RecyclerView, предоставляемого weex, относительно высока. лучше; Поэтому мы используем решение weex для динамизации мобильного терминала. На самом деле эти две схемы реализуются рендерингом виртуального дома.Нижеследующее кратко представляет принцип схемы weex.
Принцип Weex:
На приведенном выше рисунке схематическая диаграмма weex. Прежде всего, бизнес-функция реализуется с помощью языка DSL верхнего уровня. После завершения реализации он будет упакован с помощью некоторых методов построения. Благодаря упаковке вся бизнес-логика может быть быть упакованным в jsBundle, внутри jsBundle Он содержит реализованные функции и код, который может быть распознан базовой jsFramework.
После того, как у вас есть jsBundle, вы можете поместить его в фоновую систему.Это та функция, которая нам нужна для горячего выпуска.
Следующий уровень - это то, что делает SDK. После того, как SDK получит jsBundle, он будет проанализирован jscore и преобразован в дерево виртуального дома. Разные стороны анализируют дерево виртуального дома в своем соответствующем SDK, а затем самостоятельно преобразуют их в компоненты. стороны для отображения страницы. После понимания функционального принципа weex, давайте представим нашу общую схему применения горячего выпуска.
3. Общий дизайн динамической схемы
Функция общего динамического решения включает в себя внешний, внутренний и мобильный конец, а также реализацию функциональных требований трех концов.Конкретная структурная схема выглядит следующим образом.
1. Интеллект-карта всего процесса
В основном включает три части:
Слой Weex, проект weex отвечает за написание, упаковку и публикацию бизнес-страниц;
На фоновом уровне фон горячего выпуска отвечает за настройку соответствующих страниц функций, предоставляя приложению интерфейс для обнаружения обновлений и возможность отправлять и доставлять пакеты обновлений;
На уровне приложения сторона приложения отвечает за обнаружение обновлений, кэширование пакетов, а также стратегии рендеринга и отображения;
Вот посмотрите на общий процесс горячего выпуска:
В начале мы написали код weex для реализации функциональных требований, а затем упаковали и собрали jsBundle через webpack, и выпустили упакованный и собранный jsBundle на наш собственный сервер.В настоящее время используется платформа ndp и сервер nginx, и правила cdn настроены на платформе ndp, так что каждый файл js будет иметь отдельный статический адрес ресурса. Позже этот статический адрес и информация о маршрутизации страниц будут настроены в нашем фоновом режиме горячей публикации. Пользователи могут получить горячую визуализацию страниц при использовании приложения. Конечно, на стороне приложения есть два способа: во-первых, пользователь активно открывает страницу, чтобы активировать интерфейс обновления для извлечения новых данных, а во-вторых, фон освобождается и отправляется в приложение для фоновых обновлений. Поскольку вся наша стратегия разделена на три части, ниже подробно описывается работа, проделанная каждой частью.
процесс разработки и развертывания страницы a.weex
Поскольку я являюсь клиентским разработчиком, я мало что знаю о процессе разработки внешнего интерфейса, поэтому в процессе разработки я часто отклонялся от курса.
На самом деле фронтенд имеет многолетнюю историю, и многие инструменты разработки совершенны.В настоящее время я также использую вебпак в проекте для упаковки и сборки.
Поскольку DSL верхнего уровня weex выбирает vue, код страницы конкретных требований рекомендуется писать на vue (при возникновении проблем см. официальную документацию vuevuejs.org/index.html, но так как weex рендерится на стороне клиента, некоторые китайские и русские функции vue использовать нельзя.
В центре внимания не написание кода. Основное внимание уделяется настройке упаковки веб-пакета. В настоящее время я настраиваю две схемы упаковки в package.json. Отдельные среды разработки и производства. js можно сжимать и запутывать в производственной среде.
С помощью веб-пакета некоторые общие компоненты могут быть установлены при входе в файл сборки, чтобы уменьшить введение кода vue:
const App = require("${relativePath}")
//全局注册组件
Vue.component('wrapperLayout', require("components/wrapper-layout.vue"))
App.el = '#root'
new Vue(App)
Здесь мы настроили общую структуру страницы, включая панели навигации и эффекты загрузки сетевых запросов.
Установите «weex-loader» во время сборки файла vue:
let weexConfig = getBaseConfig()
weexConfig.output.filename = 'weex/[name].js'
weexConfig.module.loaders[1].loaders.push('weex-loader')
module.exports = [weexConfig]
После завершения сборки будет сгенерирован js-файл соответствующей страницы. В отличие от java, эти файлы js будут включать в себя все импортированные компоненты и методы, поэтому для страницы существует только один файл js, что также делает файл js относительно большим. В настоящее время самые сложные страницы, которые мы разрабатываем, составляют около 2-300 тыс.
После завершения упаковки все файлы js и файлы ресурсов будут развернуты на сервере negix через платформу сборки и связаны с cdn, так что ссылку cdn можно будет использовать непосредственно при настройке страницы.
б. Процесс обработки изображения ресурса
Существует пять способов использования изображений ресурсов: локальный, base64, CDN, iconfont и SVG. В настоящее время мы в основном используем методы base64 и CDN, а метод, используемый для интерфейсных страниц активности, — это iconfont.
2. Фоновый интерфейс и дизайн базы данных
A. Структура таблицы внутренней базы данных
Параметры структуры таблицы для хранения информации о пакетах в фоновой базе данных:
bundleId, minSupportVersion, bundleVersion, bundleModule, fileDownloadUrl, loadType, desc, человек, время
bundleId: уникальный идентификатор текущей страницы;
minSupportVersion: минимальный номер версии приложения, который может поддерживать текущая страница;
bundleVersion: версия текущего пакета;
bundleModule: модуль, которому принадлежит текущий пакет;
fileDownLoadUrl: адрес загрузки пакета;
loadType: метод загрузки, который может использоваться текущей страницей пакета, 1: проверка сети, сначала использовать локальную, а затем загружать последнюю, 2: обновление проверки сети, загружать немедленно, использовать последнюю версию;
desc: Описание текущей ситуации с обновлением пакетов;
лицо: обновитель;
время: время обновления и загрузки;
Структура таблиц в базе данных следующая:
| bundleId | minSupportVersion | bundleVersion | bundleModule | fileDownloadUrl | loadType | desc | person | time |
|---|---|---|---|---|---|---|---|---|
| recommendDetail | 3.9 | 1 | seeding | http://gala/3.9/recommend/recommenddetail.js | 1 | Обновлен ххх, журнал изменений... | Чжан Сан | 2017-10-16 |
** Среди них bundleId и minSupportVersion используются вместе как уникальный идентификатор **; как только один из двух изменится, он будет использоваться как новый фрагмент данных
** Возможны два случая работы базы данных: **
** 1. родной без изменений **
Содержимое обновления не зависит от изменений WeexSdk и Native, поэтому поддерживаются все предыдущие версии, затем фоновый интерфейс напрямую запрашивает текущие данные в базе данных в соответствии с bundleId и appVersion, обновляет bundleVersion (плюс один) и заменяет fileDownloadUrl для нового адреса.
Например: исходная сохраненная база данных:
| bundleId | minSupportVersion | bundleVersion | bundleModule | fileDownloadUrl | loadType | desc | person | time |
|---|---|---|---|---|---|---|---|---|
| recommendDetail | 3.9 | 1 | seeding | http://gala/3.9/recommend/recommenddetail.js | 1 | Обновлен ххх, журнал изменений... | Чжан Сан | 2017-10-16 |
затем обновите до:
| bundleId | minSupportVersion | bundleVersion | bundleModule | fileDownloadUrl | loadType | desc | person | time |
|---|---|---|---|---|---|---|---|---|
| recommendDetail | 3.9 | 2 | seeding | http://gala/3.9/recommend/recommenddetail.js | 1 | Обновлен ххх, журнал изменений... | Чжан Сан | 2017-10-16 |
Изменились только файл и версия, а все остальное осталось без изменений, так что обе версии 3.9 и 4.0 приложения могут использовать новые функции, разработанные на этот раз.
** 2. родной изменился **
В предыдущей версии в базе данных была текущая страница данных. Обновленный контент новой версии можно использовать только в последней версии.Если все предыдущие версии нельзя использовать, в базу данных будет вставлен новый фрагмент данных.
Например: исходная сохраненная база данных:
| bundleId | minSupportVersion | bundleVersion | bundleModule | fileDownloadUrl | loadType | desc | person | time |
|---|---|---|---|---|---|---|---|---|
| recommendDetail | 3.9 | 1 | seeding | http://gala/3.9/recommend/recommenddetail.js | 1 | Обновлен ххх, журнал изменений... | Чжан Сан | 2017-10-15 |
затем обновите до:
| bundleId | minSupportVersion | bundleVersion | bundleModule | fileDownloadUrl | loadType | desc | person | time |
|---|---|---|---|---|---|---|---|---|
| recommendDetail | 3.9 | 1 | seeding | http://gala/3.9/recommend/recommenddetail.js | 1 | Обновлен ххх, журнал изменений... | Чжан Сан | 2017-10-15 |
| recommendDetail | 4.0 | 1 | seeding | http://gala/4.0/recommend/recommenddetail.js | 1 | Обновлен ххх, журнал изменений... | Чжан Сан | 2017-10-16 |
После этого обновления в базе данных будет два фрагмента информации для bundleId из RecommendedDetail: первый — для приложений между версиями 3.9 и 4.0, а второй — для приложений после версии 4.0.
б. Фоновый дизайн интерфейса
Интерфейс обнаружения обновлений в приложении:
requestParams: bundleId, appVersion;
Бэкэнд-интерфейс должен запросить базу данных в соответствии с bundleId и appVersion, чтобы получить самый большой фрагмент данных с minSupportVersion, не превышающим appVersion;
отклик:
{
"bundleId":"recommendDetail",
"minSupportVersion":3.9,
"bundleVersion":1,
"fileDownloadUrl":"http://gala/3.9/recommend/recommendDetail.js",
"loadType":1
}
Например: 1. Если текущая версия приложения 3.9,
Для первого случая выше фон вернет мне последний файл рекомендациюDetail.js с bundleVersoin из 2
Во втором случае фон должен вернуть мне файл рекомендациюDetail.js, доступный в версии 3.9,
2. Если текущая версия приложения 4.0,
Для первого случая выше фон хочет вернуть мне, что minSupportVersion равен 3.9,
Во втором случае серверная часть должна вернуть мне файл рекомендациюDetail.js, доступный в версии 4.0.
c. Система управления фоновой конфигурацией
3. Стратегия отображения обновлений приложения
а. Обновите общую логическую архитектуру
Через фон с горячими волосами мы можем получить информацию о пакете, который необходимо отобразить в соответствии с соответствующим идентификатором пакета, так как же наша собственная страница узнает, какой пакет запрашивать и отображать? Давайте взглянем на нашу стратегию на стороне приложения.Это изображение представляет собой всю нашу архитектуру на стороне приложения, которая разделена на две части: одна — стратегия маршрутизации, а другая — стратегия обнаружения и обновления.
стратегия маршрутизации
Вся страница weex отображается и перескакивает на основе функции маршрутизации. То есть каждая страница weex будет иметь уникальный uri. Например, на странице A в приложении в это время нажимается кнопка для перехода на страницу B, а страница B является страницей weex, затем A передает информацию о маршрутизации B на маршрутизатор, а Маршрутизатор проанализирует маршрут. Информация передаст соответствующий bundleId в weexVersionManager, то есть диспетчеру версий weex, и получит пакет в диспетчере для отображения. Если логика перехода снова появится на странице B, информация о маршрутизации будет прошел через мост между weex и Native. Дайте маршрутизатору следующий прыжок.
показать политику обновления
Вышеупомянутая часть является частью загрузки пакетов и обнаружения обновлений. Конкретный процесс можно увидеть на блок-схеме ниже. Он в основном разделен на две части: одна — стратегия отображения, а другая — стратегия обнаружения и обновления. Давайте сначала взглянем на отображаемый процесс. Согласно предыдущему процессу, маршрут будет передавать bundleId, соответствующий странице, в VersionManager. После получения bundleId, versionManager сначала проверит, есть ли кеш, который можно использовать локально . Если есть кеш, то сначала будет загружен кеш. Если нет локального кеша, он перейдет к фону горячей публикации, чтобы запросить последний пакет. После того, как запрос вернется, будет решено, нужна ли текущая страница для обновления для отображения. Если сеть выйдет из строя, она также выдаст пользователю сообщение об ошибке сети. Эта часть справа представляет собой процесс обнаружения обновлений.Процесс обнаружения обновлений выполняется в фоновом режиме и не влияет на взаимодействие пользователя на переднем плане. Когда начнется обнаружение, он перейдет в фоновый режим, чтобы проверить, доступен ли новый пакет.После получения возвращенных данных он определит, был ли загружен текущий пакет.Если он был загружен, это означает, что локальный последней, и не будет делать ничего другого, это не повлияет на использование пользователем. Если он не был загружен локально, это означает, что предыдущий кеш нужно обновить и перезаписать, тогда jsBundle будет загружен, а jsBUndle будет закеширован после успешной загрузки. Затем различайте в соответствии с loadType, установленным в предыдущих правилах протокола. Как упоминалось ранее, loadType делится на текущую загрузку и вторичную загрузку.Если это текущая загрузка, страница будет обновляться напрямую.Если это вторичная загрузка, последняя будет использоваться при повторном входе пользователя.
4. Онлайн-страницы и данные
В настоящее время в приложении Koala для Android на страницу weex приходится 10% всего приложения Koala. Функции, которые в настоящее время онлайн, - это большинство страниц сообщества по посадке травы и вопрос и ответ о маленькой коале. Как показано ниже:
Производительность: время рендеринга всей страницы может поддерживаться в пределах 1 секунды. Длительность загрузки js: 100-200мс. Обычное время рендеринга страницы составляет около 150-300 мс.
Пять, краткое изложение опыта
1. Об использовании изображений .9: Вы можете использовать изображения .9 в теге img, но установите для атрибута resize значение stretch следующим образом:
<img class="comment-reply-bg" src="local: //res/bg_comment_reply" resize="stretch"/>
2. О переключении стиля класса:
<div class="focus-common" :class="[focusStatus?'focused-container':'focus-container']" >
3. переключение стилей:
:style="{color: focusStatus?'#999999':'#8CAA5E'}"`
4. Родительский компонент вызывает метод и данные дочернего компонента:
Задайте ref или id в дочернем компоненте, в родительском компоненте можно получить соответствующее дочернее представление и вызвать метод дочернего представления через ref:
父vue：
<recommendDetailPage ref="detailPage"></recommendDetailPage>
this.$refs.detailPage.setData(this.$refs.detailPage[0].recommendDetail)
5. Дочерний компонент вызывает родительский компонент:
//子组件通过emit通知父组件，event中传参数
showGoBack(event) {
this.$emit('showgoback',event);
},
//父组件使用子组件时，html中声明这个方法，js中调用方法
<bridgeWebview :loadUrl="url" class="webview_style" @showgoback="showGoBack"></bridgeWebview>
showGoBack(event) {
console.log("event.canGoBack2:"+event.canGoBack);
},
6. проблема с отображением текста
Содержимое в текстовом теге не может переноситься, иначе оно будет перенесено на телефоне; второй в коде ниже будет отображать две строки. Например:
1. <text >hello world</text>
2. <text >hello world
</text>
6. Что делать дальше
1. Совместная конструкция с тремя терминалами для повышения эффективности Наш мобильный терминал koala также проводит дальнейшие исследования и реализацию универсальности с тремя терминалами. Поскольку базовая поддержка на обоих концах ios и android отличается, потребуется некоторое время для совместной разработки базового интерфейса и компонентов, а также для связи. Основная цель после этого — улучшить структуру совместного строительства нижнего уровня, чтобы бизнес верхнего уровня можно было использовать на трех терминалах и повысить эффективность разработки.
2. Горячий релиз компонента weex В настоящее время Weex, который я разрабатываю, находится на уровне страницы, и в будущем я предприму некоторые попытки на уровне компонентов. И извлеките эти общие компоненты и упакуйте их в пакеты npm, которые можно использовать в нескольких проектах.