Анализ технологии гибридных приложений — принципы

внешний интерфейс WeChat JavaScript iOS

введение

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

каждый может прийтиgithubОбсуди со мной!

Второй реальный бой

Существующие гибридные решения

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

  1. на основеWebView UIБазовое решение используется большинством популярных приложений на рынке, таких как WeChat JS-SDK, которое обеспечивает двустороннюю связь между H5 и Native через JSBridge, тем самым предоставляя H5 определенную степень собственных возможностей.

  2. на основеNative UI, такие как React-Native, Weex. На основе предоставления собственных возможностей API H5 дерево виртуальных узлов (Virtual DOM), проанализированное js, далее передается в Native через JSBridge, и используется собственный рендеринг.

  3. Кроме того, есть более популярныеМини программа, также осуществляется через более настраиваемый JSBridge и использует двойной двухпоточный режим WebView для изоляции логики JS и рендеринга пользовательского интерфейса, формирования специального режима разработки, усиления степени смешивания H5 и Native, а также повышения производительности страницы и опыта разработки.

Вышеупомянутые три схемы фактически основаны на коммуникационном уровне, созданном JSBridge.Вторые три схемы фактически можно рассматривать как основу первой схемы, и они продолжают улучшать степень смешивания приложений с помощью различных новых технологий. Таким образом, JSBridge также является наиболее важной частью всего гибридного приложения.Например, JS-SDK, который мы используем при настройке обмена WeChat, объект wx является нашим наиболее распространенным JSBridge:

Выбор схемы

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

  • Требования Веб-технологии Особенности быстрой итерации, гибкая разработка и механизм оперативного оперативного обновления.

  • Основная способность продукта является мощная фотография и основные возможности обработки изображений. Следовательно, чистая технология H5 может делать очень ограниченные вещи и не может удовлетворить потребности. Укрепление H5 через гибридную технологию - это необходимость.

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

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

Принцип гибридной технологии

Суть гибридного приложения заключается в использовании WebView в качестве контейнера для прямого размещения веб-страниц в собственном приложении. Таким образом, ключевым моментом является связь между нативной стороной и стороной H5.уровень двусторонней связи, собственно, здесь тоже можно понять, что нам нужен наборМежъязыковые коммуникационные решения, чтобы завершить взаимодействие между Native(Java/Objective-c/...) и JavaScript. Это решение мы называем JSBridge, а ключом к реализации является WebView как контейнер.Все основано на механизме WebView.

(1) Уведомление JavaScript Собственный

На основе механизма WebView и открытого API существует три общих схемы для реализации этой функции:

  • API-инъекция, принцип на самом деле заключается в том, что Native получает контекст среды JavaScript и напрямую монтирует в нем объекты или методы, так что js можно вызывать напрямую.Android и IOS имеют соответствующие методы монтирования соответственно.

  • Перехват подсказки/консоли/предупреждения в WebView, обычно используйте подсказку, потому что этот метод используется нечасто во фронтенде, и конфликтов не будет;

  • Перехват перехода схемы URL-адреса WebView;

Принципы второго и третьего механизмов аналогичны.Все они достигают связи путем перехвата всплывающей передачи информации WebView.Далее мы в основном начинаем сПринцип - собственный протокол - протокол перехвата - передача параметров - механизм обратного вызоваТретья схема - схема перехвата URL, разработана в 5 аспектах.

1. Принцип реализации

Клиенты могут отслеживать и перехватывать сетевые запросы, сделанные в WebView.

2. Настройка протокола

Нам необходимо разработать комплексURL SchemeПравила, обычно наш запрос начинается с соответствующего протокола, такого как общийxxx.comИли файл://1.jpg, представляющий другое значение. Здесь мы можем настроить запрос типа протокола как:

xxcommand://xxxx?param1=1&param2=2

Вот несколько вещей, на которые стоит обратить внимание:

(1) xxcommand:// — это просто правило, вы можетеАдаптирован к бизнесу, делая его значимым, например, мы определяем xxcommand:// Это общее для всех систем приложений компании, и это общий протокол инструмента:

xxcommand://getProxy?h=1

И определите xxapp:// как отдельный бизнес-протокол для каждого приложения.

xxapp://openCamera?h=2

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

(2) Не используйте location.href для отправки сюда, потому что существует проблема с его собственным механизмом, заключающаяся в том, что несколько одновременных запросов будут объединены в один, что приведет к игнорированию протокола, а параллельный протокол на самом деле является очень распространенной функцией. мы будем использоватьСоздайте iframe для отправки запросаПуть.

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

3. Перехват протокола

Клиенты могут перехватывать запросы WebView через API:

  • В IOS: следуетстартлоадвисрекуест

  • Android: shouldOverrideUrlLoading

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

4. Обратный вызов протокола

Поскольку суть протокола заключается в отправке запроса, а это асинхронный процесс, нам необходимо разобраться с соответствующим механизмом обратного вызова. Используемый здесь метод — это система событий JS, которую мы будем использовать здесь.window.addEventListenerиwindow.dispatchEventЭти два основных API;

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

  • 2. После того, как клиент выполнит соответствующую функцию, он вызывает диспетчерский API Bridge и напрямую передает данные для запуска пользовательского события протокола.

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

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

5. Метод передачи параметров

Поскольку WebView имеет ограничение на длину URL-адреса, у обычного метода передачи параметра поиска есть проблема, какЕсли передаваемый параметр слишком длинный, он может быть усечен., например, при передаче base64 или при передаче больших объемов данных.

Поэтому нам необходимо сформулировать новые правила передачи параметров, и мы используем метод вызова функции. Принцип здесь в основном основан на:

Native может напрямую вызывать методы JS и напрямую получать возвращаемое значение функции.

Нам нужно только пометить каждый протокол уникальным идентификатором и сохранить параметры в пуле параметров, а затем клиент может получить соответствующие параметры из пула параметров через уникальный идентификатор.

(2) Собственный Javascript для уведомлений

Поскольку Native можно считать хостом H5, он имеет больший авторитет, о чем также упоминалось выше.Native может напрямую выполнять код Js через WebView API.. Это разрешение также делает общение в этом направлении очень удобным.

  • IOS: stringByEvaluatingJavaScriptFromString
// Swift
webview.stringByEvaluatingJavaScriptFromString("alert('NativeCall')")
  • Android: loadUrl (4.4-)
// 调用js中的JSBridge.trigger方法
// 该方法的弊端是无法获取函数返回值；
webView.loadUrl("javascript:JSBridge.trigger('NativeCall')")

Tips:Когда система ниже 4.4, оценитьJavascript нельзя использовать, поэтому возвращаемое значение JS нельзя получить просто с помощью loadUrl.В настоящее время нам нужно использовать метод приглашения, упомянутый выше для совместимости, и позволить концу H5 отправлять данные через Терминал перехватывает и получает данные.

  • Android: evaluateJavascript (4.4+)
// 4.4+后使用该方法便可调用并获取函数返回值；
mWebView.evaluateJavascript（"javascript:JSBridge.trigger('NativeCall')", 	 new ValueCallback<String>() {
    @Override
    public void onReceiveValue(String value) {
        //此处为 js 返回的结果
    }
});

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

(3) Доступ к JSBridge

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

  • JS-часть (мост): внедрить код реализации моста в среду JS, включая некоторые базовые функции, такие как сборка протокола/отправка/пул параметров/пул обратного вызова.

  • Нативная часть (SDK): код сопоставления функций моста в клиенте реализует такие функции, как перехват URL-адресов и синтаксический анализ/вставка информации об окружении/общее сопоставление функций.

Здесь мы объединяем эти две части в одну.Native SDK, который равномерно вводится клиентом. Когда клиент инициализирует WebView для открытия страницы, если адрес страницы находится в белом списке, онВставьте соответствующий bridge.js непосредственно в заголовок HTML.. Этот подход имеет следующие преимущества:

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

  • Доступ к приложению очень удобен, вам нужно только получить доступ к последней версии SDK в соответствии с документом, и вы можете напрямую запустить все гибридное решение, что удобно для быстрой реализации в нескольких приложениях;

  • Нет необходимости обращать внимание на сторону H5, которая способствует открытию моста на сторонние страницы.

Здесь следует отметить, чтоВызов протокола должен быть гарантированно выполнен после успешного внедрения bridge.js.. Поскольку инъекционное поведение клиента является дополнительным асинхронным поведением, трудно зафиксировать точное время завершения со стороны H5, поэтому необходимо отслеживать завершение страницы через клиента и уведомлять сторону H5 на основе вышеупомянутый механизм обратного вызова события, и страница может пройтиwindow.addEventListener('bridgeReady', e => {})для инициализации.

(4) Доступ к H5 в приложении

Обычно есть два способа подключить H5 к приложению:

(1) Онлайн H5, что является наиболее распространенным способом. Нам нужно только развернуть код H5 на сервере, если соответствующий URL-адрес предоставляется клиенту, а URL-адрес открывается с помощью WebView и может быть встроен. Преимущества этого подхода:

  • Сильная независимость, с очень независимыми возможностями разработки/отладки/обновления/онлайн;
  • Ресурсы размещаются на сервере и никак не повлияют на объем пакета клиента;
  • Стоимость доступа очень низкая, и полный механизм горячего обновления.

Однако этот метод имеет и соответствующие недостатки:

  • Полная сетевая зависимость, страницу нельзя открыть в офлайне;
  • Скорость загрузки первого экрана зависит от сети, при медленной сети загрузка первого экрана тоже медленнее;

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

(2) Встроенный пакет H5, который является методом локализованного встраивания. Нам нужно упаковать код и отправить его клиенту, а клиент будет напрямую распаковывать его в локальное хранилище. Обычно мы используем его на некоторых более крупных и важных модулях. Его преимущества:

  • Благодаря локализации скорость загрузки первого экрана высокая, а пользовательский опыт ближе к оригиналу;
  • Он может работать в автономном режиме, не полагаясь на сеть;

Но в то же время его недостатки также весьма очевидны:

  • Механизм процесса разработки/обновления сложен и требует взаимодействия клиента и даже сервера;
  • Размер пакета приложения будет соответственно увеличен;

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

Суммировать

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

  • JavaScript уведомляет Native
  • Собственный Javascript для уведомлений
  • Доступ к JSBridge
  • Доступ к H5

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

Категории