跨平台解决方案的技术分析
责任编辑:app设计发表时间:2021-08-10 22:09:06作者:ELab团队



近 20 年是中国互联网蓬勃发展的时代,以 2010 年为界限,前 10 年是 PC 互联网时代,PC 互联网时代培养了国民上网冲浪的用户习惯,为后 10 多年的以智能手机为终端的移动互联网时代带来丰厚的人口红利,而在移动互联网时代,以智能手机为依托的软硬件也就成为各大互联网公司争夺流量的焦点战场。


移动互联网发展早期,或是依托母公司的强大技术实力支撑,或是抓住时代发展机遇,或是努力创新求变,一批又一批现象级的移动应用成为广大用户的生活工作等方面难以分割的一部分,类似微信之于社交通讯、支付宝之于支付理财、头条之于资讯创作、美团之于生活服务等等不一而足。移动互联网发展至今,早已是一片红海市场,早期发展起来的 APP 要么成为国民级别的超级 APP,要么在垂直领域深耕难以撼动。


那么,行业龙头型 APP 如何持续拓展服务边界,快速响应市场需求变化以保持竞争优势,后进的 APP 如何通过产品、商业模式创新,迅速切入市场,提高研发的灵活机动性同时不降低产品的用户体验。


针对当前移动互联网的发展现状,跨平台开发的概念和解决方案应运而生。跨平台开发的诞生使命就是围绕着研发效能和用户体验两个主题去打造的,但是就如同一个符合特定场景和高效算法在时间和空间上的 trade-off,跨平台解决方案的不同实现在研发效能和用户体验上同样面临权衡取舍。


本文旨在介绍不同跨平台解决方案的技术架构和特点,分析各个解决方案的优势和不足之处,以便对业界当前的跨平台技术方案建立起整体的认知和对团队的技术选型提供一定的参考作用。注意的是,这里的跨平台特指的是针对 iOS 和安卓进行的跨平台开发

跨平台解决方案

根据采用的渲染技术不同,跨平台解决方案可分为以下三类:

  • Web 渲染方案
  • 原生渲染方案
  • 自建渲染引擎渲染方案

Web 渲染方案

Web 渲染方案主要是使用原生 WebView 控件渲染 HTML 页面,并在原生应用中定义可供 H5 页面访问原生部分能力的接口 JSBridge,从而实现 H5 和 Native 双向通信,也使得 H5 的能力向端侧进一步扩展。



Web 渲染方案本质上是依托原生应用的内嵌浏览器控件 WebView 去渲染 H5 页面,因此 h5 App 的渲染流水线和 Web 页面渲染相一致,能力也局限在 WebView 这一沙箱。下图描述从 WebView 初始化到 H5 页面最终渲染的全过程。


Web 渲染方案的性能瓶颈和 Web 页面开发中遇到的类似,即首屏渲染优化问题,同时多出了一个 WebView 初始化的特有问题。


对于 WebView 初始化所带来的性能开销,不少公司针对自身的 APP 进行内核的定制化改造,诸如腾讯的 X5 内核以及阿里 UC 技术团队的 UCWebView 等。


针对资源加载所带来的白屏问题,业界又提出了离线包的优化方案。所谓离线包机制,大体思路就是将原有从线上加载 H5 应用,提前下发到本地,通过 FileIO 或是内存等方式直接进行页面渲染,达到接近原生的用户体验。


上面所描述的是最为原始的 Web 渲染方案,在这基础上业内又提出 h5 容器的技术解决方案,h5 容器提供丰富的内置 JSAPI,增强版的 WebView 控件以及插件机制等能力,对原始版本的方案做了进一步功能高内聚和模块低耦合。


下面以 Cordova 为例,概述一下 H5 容器的大致架构,Cordova 是 Apache 一个开源的移动开发框架,这一框架的核心实现原理就是基于 Web 渲染技术。


Cordova 应用程序由几部分组成:

应用程序代码的实现地方,采用的是 Web 技术,应用运行在原生控件 WebView 中

  • HTML Rendering Engine

应用的渲染引擎,即 WebView,该渲染引擎是页面和 Native 实现双向通信的桥梁

  • Cordova 插件

提供了 Cordova 和原生组件相互通信的接口并绑定到了标准的设备API上。这使你能够通过JavaScript 调用原生代码,这些核心插件包括的应用程序访问设备功能,比如:电源,相机,联系人等。

  • Mobile OS

原生系统层,提供系统能力


小程序

小程序是微信在 2017 年提出一项创新性的轻应用,不需要下载安装即可使用。记得 Brendan Eich 曾对 JavaScript 的评价它的原创之处并不优秀,它的优秀之处并非原创。我想微信小程序也是这样,因为小程序采用的技术手段仍脱离不了 Web 渲染方案,即采用 WebView 作为渲染引擎、JSBridge 的封装和离线包机制等,但是其最大创新之处在于将渲染层和逻辑层进行了分离,提供一个干净纯粹的 JavaScript 运行时,多 WebView 的架构使得用户体验进一步逼近原生体验。


具体来看,小程序的渲染层和逻辑层分别由两个线程管理,渲染层采用 WebView 进行页面渲染(iOS 使用 UIWebView/WKWebView,Android 使用 WebView),小程序的多页面也由多 WebView 接管。逻辑层从 WebView 分离,使用 JavaScript 引擎(iOS 使用 JavaScriptCore,Android 使用 V8)单独开启一个 Worker 线程去执行 JavaScript 代码。逻辑层和渲染层之间的通信经由 Native 层中转,网络 IO 也通过 Native 层进行转发。


小程序采用多 WebView + 双线程模型的架构。由多 WebView 构成的视图层为页面性能赋予更加接近原生的用户体验,单个 WebView 承载更加轻量的页面渲染任务,JavaScript 脚本单独抽离在 Worker 线程限制了开发者直接操作页面的能力,进一步约束在微信小程序的规范下,这也是小程序无法直接操作 DOM 的缘由。


这里多提一点的是,小程序的组件分为原生组件和非原生组件,对于原生组件而言,这就脱离的 Web 渲染方案的范畴,属于原生渲染方案的一部分,所以从这点上看,小程序也可以算得上是 Web 渲染和原生渲染的融合解决方案。综上来看,Web 渲染跨平台方案经历了三个阶段性的发展,从原始时期的 h5 + JSBridge + WebView,到 h5 容器的抽象提升,再到目前如火如荼的小程序。不难看出,Web 渲染方案的有如下特点:



  • 开发效率高

采用 Web 技术,技术门槛相对较低,技术人员积累丰厚,社区资源丰富,对前端友好,一次开发,多端运行

  • 动态化好

Web 技术的天然动态特性支持,无需发版

  • 表现一致性佳

Web 页面除了个别元素和属性的差异、多屏适配外,其双端表现相对一致

  • 性能较差

页面采用 WebView 渲染,页面加载耗时长,功能受限于沙箱,能力有限,难以承接复杂交互或是需要高性能的任务,整体用户体验差


原生渲染方案

Web 渲染方案的致命弱点在于无法出色地完成高性能和体验的目标,但是其良好的社区生态、跨平台一致性和高研发效率都是其无法忽视的优势,那么如何做到二者的平衡,答案就是原生渲染方案。


原生渲染方案的基本思路是在 UI 层采用前端框架,然后通过 JavaScript 引擎解析 JS 代码,JS 代码通过 Bridge 层调用原生组件和能力,代表的框架是 React Native 和 Weex。


从原生渲染方案的实现思路不难看出,顶层采用类 Web 框架用于降低开发成本和统一技术栈,UI 的渲染通过 JSBridge 由原生控件直接接管,从而获得性能和体验的提升。



236

让我们来倾听您的需求
为您定制商业创新

甄科技微信账号

备案号:京ICP备2021016757号-1   版权所有: 北京拥有甄科技有限公司

在线咨询

13240987098

甄科技微信账号
提供一站式服务

免费在线咨询

首页

电话

在线咨询

二维码

甄科技微信账号