Говоря об эволюции гибридных приложений

Внешний интерфейс хочет написать приложение

Начало главы должно начинаться таким образом: с самого начала приложения и до настоящего времени учащиеся переднего плана всегда хотели написать приложение, и различные технологии также должны заставить учащихся переднего плана написать приложение. ПРИЛОЖЕНИЕ.

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

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

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

web APP

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

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

Клиент предоставляет среду хостинга, подобную браузеру, а внешний интерфейс запускает собственный HTML/CSS/JS для просмотра страницы. Но со стороны ПК страницы, которые мы видели на мобильном телефоне, не подходили для отображения и взаимодействия. Причина, по которой мы называем это приложение h5, заключается в том, что нам нужно использовать новые функции HTML5/CSS3 на мобильном терминале, и с помощью этих функций мы можем адаптировать страницу отображения в браузере клиента.

Адаптивная верстка, новые метатеги, медиа-запросы и другие функции позволяют отображать страницы интерфейса, которые ранее отображались на ПК, на мобильном телефоне. вместе сPWAПоявление мобильного телефона постепенно поддерживает Service Worker (Safari все еще колеблется), а веб-приложение снова омолаживается.

преимущество:

• Кроссплатформенность на основе WebView, простая отладка (консольная отладка)
• Скорость разработки быстрая, пока есть браузер, его можно открыть, подходит для проб и ошибок небольших версий
• Без установки, без памяти, можно обновить в любое время, низкая стоимость обслуживания

недостаток:

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

Репрезентативные продукты:

• Все веб-страницы, которые можно открыть в мобильных браузерах (будут проблемы, если нет совместимого дисплея)
• Чистые статьи в публичном аккаунте WeChat

гибридное приложение

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

Реализация взаимодействия front-end webView не может напрямую взаимодействовать с API камеры.Такие функции являются возможностями клиента.Если webView хочет выполнить такую ​​функцию, если она не может быть выполнена напрямую,можно ли это сделать через звонит клиент, но фронтенд А клиент это два разных языка и реализации, как общаться?

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

js bridge

js вызывает родной:

• запрос на перехват
• Блокировка всплывающих окон
• внедрить js-метод

собственный вызов js:

• Выполнять код js напрямую

запрос на перехват

Запрос, отправленный webView, будет проходить через модуль отправки запросов клиента. Клиент может перехватить запрос перед его отправкой. Все согласны с протоколом реализации URI. Если запрос соответствует протоколу реализации, он будет перехвачен, и соглашение будет проанализировано.Отправлено как настоящий запрос.

Сначала договоритесь о простом соглашении

eros://bmImage/camera?params={"imageNum":2,"allowCrop":true,"callbackId":"bmImage.camera1527235458519"}

eros            // 作为协议存在，用于做拦截的方式
bmImage/camera  // 用于约定是调用客户端的方法名，可以是想要调用相机上传两种图片的接口
params          // query 表示参数，其中有一个参数名叫 params 的参数是一个 json，是调用客户端的方法所需要的三个参数

Независимо от того, как инкапсулирован js, необходимо отправить запрос, лучше всего, чтобы фронтенд мог сделать унифицированную инкапсуляцию через iframe или отправить запрос напрямую через ajax.

Как клиент перехватывает

способ перехвата андроидаshouldOverrideUrlLoading

@Override
public boolean shouldOverrideUrlLoading(WebView view, String url) {
    // 根据协议判断是否需要拦截
    if (true){
      // 解析协议路径得知调用方法
      // 解析 query 得到参数
      // 通过反射的方式去调用对应的原生方法
      return true;
    }
    return super.shouldOverrideUrlLoading(view, url);
}

Метод перехвата iOS (UIWebView)webView:shouldStartLoadWithRequest:navigationType:

- (BOOL)webView:(UIWebView *)webView shouldStartLoadWithRequest:(NSURLRequest *)request navigationType:(UIWebViewNavigationType)navigationType
{
    // 根据协议判断是否需要拦截
    if (true){
        // 解析协议路径得知调用方法
        // 解析 query 得到参数
        // 通过 AOP 的方式去调用去调用对应的原生方法
        return NO;
    }
    return YES;
}

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

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

Блокировка всплывающих окон

Когда js вызывает всплывающее окно, обычно существует три типа всплывающих окон: предупреждение/подтверждение/подсказка Эти три типа всплывающих окон будут иметь методы для реализации, соответствующие клиенту, которые могут быть перехвачены напрямую.

var actionInfo = {
    type: 'eros',
    action: 'bmImage/camera',
    params:{
        "imageNum":2,
        "allowCrop":true,
        "callbackId":"bmImage.camera1527235458519"
    }
}

prompt(JSON.stringify([actionInfo]))

подсказка перехвата андроида

@Override
public boolean onJsPrompt(WebView view, String url, String message, String defaultValue, JsPromptResult result) {
    // 解析传过来的字符串判断 type 类型是不是解析的方式
    if (true){
        // 解析协议路径得知调用方法
        // 解析 query 得到参数
        // 通过 AOP 的方式去调用去调用对应的原生方法
        // 如果是异步返回
        return true;
        // 如果是同步，待上面的程序执行完毕之后返回结果
        // return res
    }
    return super.onJsPrompt(view, url, message, defaultValue, result);
}

iOS перехватывает приглашение (используя WKWebView)

- (void)webView:(WKWebView *)webView runJavaScriptTextInputPanelWithPrompt:(NSString *)prompt defaultText:(nullable NSString *)defaultText initiatedByFrame:(WKFrameInfo *)frame completionHandler:(void (^)(NSString * _Nullable result))completionHandler{
    // 解析传过来的字符串判断 type 类型是不是解析的方式
    if (true){
        // 解析协议路径得知调用方法
        // 解析 query 得到参数
        // 通过 AOP 的方式去调用去调用对应的原生方法
        // 如果是异步返回
        NSInvocation *invocation = [执行方法]
        [invocation invoke];
        return invocation;
        // 如果是同步，待上面的程序执行完毕之后返回结果
        return nil
    }else{
        执行对应的弹窗
    }
}

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

контекст внедрения js

Вышеупомянутый метод использования все еще довольно мучителен.Он разработал JavaScriptCore, который является ядром большинства гибридных прикладных решений.JavaScriptCore не имеет объекта BOM или объекта DOM и даже не имеет некоторых методов браузера, но это js и нативный доступ. общественные места. После открытия webView внедрите методы в контекст js для вызова js.

iOS JavaScriptCore Injection (UIWebView)

// 获取 WebView 中 JS上下文
JSContext *context = [webview valueForKeyPath:@"documentView.webView.mainFrame.javaScriptContext"];
//注入 callNative 函数方法
context[@"callNative"] = ^( JSValue * params )
{
    // 解析参数找到对应的方法进行处理
    // 同步回调
    NSInvocation *invocation = [执行方法]
    [invocation invoke];
    return invocation;
    // 异步回调
    return nil
}

js-метод вызова

callNative({
    action: 'bmImage/camera',
    params:{
        "imageNum":2,
        "allowCrop":true,
        "callbackId":"bmImage.camera1527235458519"
    }
});

Android-инъекция WebView

// 通过 addJavascriptInterface 将对象映射到 JS 对象
// android 对象
// js 的对象名
mWebView.addJavascriptInterface(new JavaScriptBridge(), "callNative");

js-метод вызова

callNative.bmImage.camera({
    "imageNum":2,
    "allowCrop":true,
    "callbackId":"bmImage.camera1527235458519"
})

Этот метод ближе к способу написания кода, будь то способ вызова, способ передачи параметров или способ синхронных и асинхронных обратных вызовов. Но и у этого метода есть некоторые моменты, на которые стоит обратить внимание, в первую очередь нужно обратить внимание на время внедрения клиента, внедрение до loadUrl недействительно, но после внедрения FinishLoad webView мог вызвать метод, а метод не будет вызываться в это время, поэтому для гарантии этой проблемы также требуются другие механизмы. Например, интерфейс wx.config официальной учетной записи WeChat.

родной вызов js

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

Во-первых, js предоставит метод ожидания вызова клиента.

window.nativeCallbackMap = {};
const callJs = (data) => {
    var data = JSON.parse(data);
    var callback = window.nativeCallbackMap[data['callbackId']
    if(callback){
        callback.call(null, data['resData'])
    }
    delete window.nativeCallbackMap[data['callbackId']
}

iOS вызывает js

NSString *resDataString = [self _serializeMessageData:data];
NSString* javascriptCommand = [NSString stringWithFormat:@"callJs('%@');", resDataString];
if ([[NSThread currentThread] isMainThread]) {
    [self.webView evaluateJavaScript:javascriptCommand completionHandler:nil];
} else {
    __strong typeof(self)strongSelf = self;
    dispatch_sync(dispatch_get_main_queue(), ^{
        [strongSelf.webView evaluateJavaScript:javascriptCommand completionHandler:nil];
    });
}

андроид вызывает js

final int version = Build.VERSION.SDK_INT;
// 因为该方法在 Android 4.4 版本才可使用，所以使用时需进行版本判断
if (version < 18) {
    mWebView.loadUrl("javascript:callJs()");
} else {
    mWebView.evaluateJavascript（"javascript:callJs()", new ValueCallback<String>() {
        @Override
        public void onReceiveValue(String value) {
            // js 的同步返回
        }
    });
}

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

Если вам нужно общаться с нативной страницей, вы должны договориться о схеме, которую также можно понимать как реализацию URI, вызывая клиента через интерфейс js bridge (в это время вы также можете передать клиенту callback , когда клиент завершает определенную операцию После возврата на страницу для выполнения обратного вызова, например выбора даты), клиент анализирует протокол, открывает соответствующую собственную страницу и завершает соответствующую операцию. Схема также является протоколом, распознаваемым мобильными браузерами.Если есть соответствующее приложение, вы можете напрямую вызвать приложение, но когда вы открываете страницу клиента со слишком большим количеством параметров, ваша схема становится слишком длинной, и браузер усекает URL-адрес. , на этот раз также требуется простое преобразование сервиса с короткой цепью

преимущество:

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

недостаток

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

Репрезентативные продукты:

• Официальный аккаунт использует функции WeChat sdk
• Гибридные фреймворки, такие как AppCan, PhoneGap, Cordova и т. д.

Апплеты

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

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

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

APP View

Слой представления и код логики, которые мы написали, разделены.WXML и WXSS структурируют код слоя представления.WXML преобразуется в VDOM с помощью инструмента wcc, а WXSS преобразуется в тег стиля с помощью wxsc. Нижний уровень обеспечивает инкапсуляцию нижнего уровня с помощью WAWebview.js. Каждое представление будет иметь веб-представление для рендеринга, что также повышает производительность рендеринга страницы. При наличии нескольких страниц представления будет несколько процессов веб-представления. Уровень страницы ограничен, а память ограничено. Слой просмотра в основном включает в себя следующее:

• Пакет WeixinJSBridge такой же, как и вышеупомянутый гибридный jsBridge.
• Регистрация компонентов, предоставляемая апплетом, некоторые API, которые могут манипулировать DOM.
• Реализация рендеринга: VDOM, diff, render UI (по знанию знатоков я понимаю, что суть рендеринга все-таки в webview, на нативной стороне поддерживается только flex layout, но в апплете поддерживается и web layout. Это видно что тут должен быть рендеринг из webView, а не нативный)
• Управление жизненным циклом страницы

APP Service

Весь код обработки логики загружается в службу приложения процесса.В отличие от просмотра webView, вся логика кода будет загружаться в этот процесс одновременно, потому что основным узким местом по-прежнему является производительность рендеринга, и загружается весь код логики. В процессе гарантируется поток переключения представлений, а с ограничением размера апплета в 2 МБ загрузка будет лучше в текущем сетевом окружении. Служба APP включает в себя следующее:

• Пакет WeixinJSBridge такой же, как и вышеупомянутый гибридный jsBridge.
• Внедрение метода API обеспечивается всеми апплетами, внедрение глобального метода
• Модульная реализация AMD

Среда разработки небольших программ

Апплет работает в среде разработки, а онлайн-среда отличается.Онлайн-среда iOS и Android обеспечивают реальную среду webView.В процессе разработки апплет предоставляет IDE.IDE реализована на основе nwjs и клиента DingTalk Он также основан на этой реализации. На самом деле, это должно предоставить как можно больше собственных возможностей в клиентской среде на стороне ПК, и если это мобильный терминал, дифференцированные возможности будут скрыты. Разница между двумя средами также отражается в службе APP.Служба APP в основном вызывает нижний уровень клиента, поэтому разница в нижнем уровне также влияет на инкапсуляцию этого уровня.

APP View взаимодействует со службой APP

Когда мы понимаем принцип связи предыдущего гибрида, связь здесь становится легче понять. Принцип реализации моста апплета такой же, как и у гибрида. Не говоря уже об iOS и Android. Клиент на основе nwjs реализован через window.postMessage с использованием интерфейса расширения Chrome для внедрения contentScript.js, который инкапсулирует метод postMessage.

// 发送消息通过 
window.postMessage(data, ‘*’);
// 接受消息通过
window.addEventListener(‘message’, messageHandler);

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

преимущество:

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

недостаток

• Его можно использовать только на платформе WeChat.Если есть потребности нескольких пользователей, стоимость разработки увеличится.
• Компонентов по-прежнему мало, многие способы работы с DOM будут ограничены, а требования к завершению ограничены.
• Для повышения производительности размер пакета ограничен, а уровень открытия страниц ограничен.

Репрезентативные продукты:

• Мини программы для разных клиентов

Быстрое приложение

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

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

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

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

Достоинства и недостатки не детализированы, все понятно с первого взгляда

Flutter

Расширение ReactNative еще больше укрепило доминирование React.React также превратился из фреймворка в интерфейсное многотерминальное решение на основе React и экологическое решение для стека технологий. Как Google мог отказаться от своих позиций в области технологий, даже если это связано с технологией фронтенда, поэтому для завершения APP было использовано техническое решение Flutter.

Воспользовавшись преимуществами платформы Android и Chrome, он готов запустить ОС Fuchsia и построить собственную низкоуровневую систему, не основанную на Linux, а назначенным набором инструментов пользовательского интерфейса Fuchsia OS является Flutter. Самым большим улучшением Flutter является переделка механизма рендеринга для рендеринга страниц, что поднимает производительность рендеринга гибридных приложений на новый уровень.

Самая большая разница между Flutter и RN заключается в рендеринге.Он отделен от рекурсивной передачи компонентов JSFramework и пошагового расчета и рисования.Это больше похоже на рисование на холсте, а пользовательский интерфейс рисуется напрямую.Flutter перестраивает дерево виджетов, когда изменения состояния. Механизм рендеринга Flutter преобразует дерево виджетов в визуализированное дерево рендеринга и, наконец, передает его операционной системе для вызова графического процессора для рендеринга. Flutter написан программой Dart. Между Dart и нативным интерфейсом все еще существует интерфейс. , который может кодировать и декодировать данные, что может быть лучше, чем мосты JavaScript, на порядки быстрее.

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

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

Если вы заинтересованы, вы можете перейти к:

• Введение в принципы флаттера
• Что такое флаттер-революция
• Как оценить Fuchsia, Android, iOS кроссплатформенный фреймворк приложений Flutter от Google?

Weex и ReactNative

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

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

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

Я думаю, Weex начал с KPI.В конце концов, это очень хороший способ для крупных производителей построить колеса для модернизации, но в будущем это стало решением для двух лагерей для улучшения экологии.Теперь полный комплект передних Решения, основанные на React, покрывают ПК, Web и Native стали стандартными процедурами для интерфейсных решений крупных компаний.Восходящая звезда Vue начала захватывать пользователей хорошим опытом разработки и методом входа с низким порогом.Разное Школы обучения фронтенду делают некоторые фронтенды не понимающими основ js, а Vue буксует летать. Но Vue не сформировал охват Native, что также может быть причиной того, что Weex и Vue нашли общий язык.

Давайте поговорим по теме, на фоне постепенной интеграции большого фронтенда, как команда, строящая технологический стек с Vue, мы начинаем искать решения на стороне клиента, и мы начинаем рассматривать бизнес-достижения, командное обучение стоимость, эффективность разработки, производительность и другие вопросы при выборе технологии. Мы также сравнивали Weex и RN в начале. Предыдущая компания использовала RN, но текущая команда строит стек технологий на основе Vue. Учитывая второй фактор, смещен в сторону Weex, мы обнаружили, что в Weex действительно много ям во время фактического исследовательского процесса, но, к счастью, уже есть решения многих проблем.Конечно, независимо от того, хотите ли вы использовать два вышеуказанных решения, вам необходимо иметь определенные собственные возможности . В самом процессе разработки было обнаружено, что по мере того, как понимание Weex становилось все больше и больше, эффективность разработки становилась все быстрее и быстрее.После входа в яму я обнаружил третье, четвертое и даже пятое и шестое преимущества.

Что касается самого большого преимущества Weex, то он совместим с тремя терминалами.У каждого есть свое мнение о преимуществах веб-стороны.Мы пытались быть совместимыми с веб-сайтом, но обнаружили, что эффективность разработки была принесена в жертву, и было время для совместимость. Также был разработан отдельный набор, и, что более важно, из-за несоответствия привычек пользователей, веб и натив ориентированы на разные группы пользователей. В этой среде, где трафик - это золото, мы не собираемся жертвовать пользовательским опытом и развитием. эффективность для совместимости с Интернетом.

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

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

При выборе двух решений должны быть некоторые желаемые места для выбора.Дух инженера заключается в том, чтобы пойти в яму, найти правильное направление, а затем двигаться вперед.У обоих решений есть отличные продукты, которые были запущены, что указывает на то, что это дорога, по крайней мере, это можно сделать.Конечно, мы также обобщили наши решения в процессе, надеясь помочь коллегам, которые борются на дороге Weex.Независимо от того, какое решение вы выберете, вы можете сделать это хорошо, если вы выберете.Ткните пожалуйста адрес проекта Эрос (не скупитесь на свою звезду).Адрес документа Эрос, пожалуйста, отметьте. Наша компания уже запустила через Eros три проекта, через Eros выпущены десятки приложений.

Конечно, есть много отличных решений, которые не перечислить по одному, например: kotlin, WebAssembly, каждое решение аккумулировало накопление многих фронтенд-инженеров, и предоставляет различные решения, которые можно реализовать. mui, appcan, apicloud и т. д.

В следующей статье будет подробно описаноПринцип Weex