基于前端领域移动端跨平台方案的研究

岳奎

(四川理工学院，四川自贡643000)

最早的跨端跨平台解决方案要追溯到PhoneGap 的时代，也叫作Hybird 时代，代表作Cordova，同时期后来也有了基于AngularJS 和Cordova 的增强版Ionic，这些方案都是混合开发方案。接着迎来了借助原生渲染的方案，先后出现的有React Na‐tive、Weex、uni-app等。之后出现了放弃原生渲染，自建渲染方案的自渲染技术Flutter。本文主要研究跨端方案的演进过程以及各种跨端方案的各自特性。

1 混合开发时代

混合(hybird)开发时代的代表作有Apache Cordova[1]，其前身就是PhoneGap。它允许开发者用标准的Web 技术也就是HTTML5、CSS3和JavaScript来做跨平台开发。应用在每个平台的具体执行细节都被封装了，并借助封装过原生标准的API去访问每个设备的功能，比如相机拍照、地理位置定位、传感器等。

1.1 混合开发Apache Cordova实现原理以及特点

1.1.1 实现原理

因为是基于Web技术，所以必然依赖于WebView才能进行页面渲染展示。那么对于Android 来讲就是利用WebView 技术，对于iOS 来说就是利用的UIWebView 或者WKWebView。所以Web 和客户端Native 的通信方式是依赖于WebView 提供的相关接口实现的，对于Android 来讲一般常用的相互通信方式是WebView 实例加载Web 的URL 以及Native 注入全局变量(使用addJavascriptInterface[2])到WebView 中，这样HTML5 就可以全局可见地调用该方法。对于iOS 来说是利用WKWebview里的evaluateJavaScript 方法直接执行即可，那么H5 调用Native的能力是依靠NA 自身的JavaScriptCore 提供接口出去供H5 来调用。本质上两端通信还有一个共同的方式就是NA拦截Web的URL(也叫作标准协议规范schema)做对应的处理，这是一个比较常用，而且容易自定义的协议规范，实现也相对简单灵活。

1.1.2 混合开发特性

开发效率方面，对前端开发者友好，前端众多生态都可以拿来使用，比传统的Android 和iOS 开发效率快很多，但涉及Native 的部分，依然需要去熟悉掌握原理。其次是能力受限于桥接层，扩展性低。调试和错误日志不友好。热更能力方面，因为使用JS，所以是支持热更。多端一致性方面，因完全依赖于Native的webview层的内核渲染，无法媲美原生体验，涉及宿主问题必然需要开发者自己处理。性能方面，因渲染依赖于WebView，所以性能不如Native 直接渲染，特别对于长列表渲染[4]，性能很差。

综上所述其实Hybird 方案是一个矛盾结合体，既要快，又要性能还要完善的生态。当然开发者们都看到了此缺陷所以才有了后来大家耳熟能详的React-Native。

2 原生Native渲染时代

常见的通过Native 渲染的技术目前有React Native、Weex、uni-app，接下来逐个分析相关方案的原理和特性。

2.1 React Native

架构理念是Learn once，write anywhere也就是说掌握了Re‐act 开发，可以同时掌握Web 和App 两种开发技能。React Na‐tive[3]用了react 的设计模式，但UI 渲染、动画效果、网络请求等功能均由原生实现。开发者编写的js 代码，通过React Native的中间层转化为原生控件来渲染和响应事件，相比ionic等跨平台应用，极大地提高了用户体验。

2.1.1 React Native的框架组成、渲染原理、平台通信

首先React Native 框架内部已提供了很多内置组件，如View、Text 等基础布局组件，一些功能组件如Button、Picker 等，用于列表展示的List 组件和对应Android 平台和iOS 平台特有的组件、API 等。同时也提供了编写与原生平台交互的接口。渲染这块主要还是把React写好的JSX代码通过ReactElements转换，然后经历React的部分生命周期再由AppRegistry.register‐Component[3]进行注册，接着通过遍历dom进行diff算法，但这里是要经过消息队列异步传递的，最终把增量的变化传递到Na‐tive 侧，然后进行渲染真正的Native 组件。平台通信这块主要是通过Bridge 来进行通信，所有JS 代码都是要经过JavaScript‐Core编译，然后给到由C/C++编写的Bridge桥，当作中间人进行交换通信，再分发给对应的Android或者iOS宿主。所以这个过程中最消耗性能的其实就是渲染时的消息队列通信相关的增量变化。大致的架构图如图1所示。

图1 架构图

2.1.2 React Native特点总结

开发效率方面，在Web基础上引进了React能力，符合前端大趋势，但涉及与Native 交互的地方就需要开发者自己处理，这点还是需要对NA比较熟悉，因本地支持热加载，也有对应配套的调试dom节点元素的工具提供，开发体验是友好的。动态化方面，因为用的是react，故可以做线上热更操作，不过需要结合三方npm 包或者自研NA 相关的JS Bundle 文件下载、上传、替换等功能。多端一致性方面，因为是渲染的NA组件，所以可以保证和Native 拥有一样的用户体验，但三方组件依赖性较强，比如版本更新不及时，社区活跃度不高。性能方面，稍差于Native，但远好于Hybird，但因为渲染时需要JavaScript 和原生之间不停地进行数据通信，在有些场景如拖动可能会因为通信频繁导致卡顿。其次是因为JavaScript 为脚本语言，执行时需要JIT，执行效率相比AOT代码[5]仍有一定的差距。

2.2 Weex

Weex 也是借助NA 来做渲染的一个移动端跨平台方案。它和React Native 很多方面都很相似，但还是有不同点，比如它使用的是Vuejs 和Rax 这两个任意一个框架来编写代码，同时Weex 的渲染引擎和DSL 语法层是分开的，这点和React Native理念完全不同。因为很多都和React Native 相似，所以这里就简单阐述。

2.2.1 Weex整体工作流程

首先会把用vue 写的项目打包成一份JS Bundle，然后部署到服务器，客户端打开某一个网页，先下载服务端的JS Bundle，然后在客户端本地执行该JS Bundle。一般会用到JavaScript‐Core 或者V8 引擎去执行JS Bundle，JS 执行引擎和浏览器执行过程类似，JS Bundle 的代码被执行，生成VNode 树进行patch，找到最小DOM 节点的操作变化，把DOM 节点的操作转变为Native DOM API 的操作，然后调用WXBridge[6]进行通信，WX‐Bridge 将渲染指令分发到Native 渲染引擎，由Native 渲染引擎完成最终的页面渲染。

2.2.2 Weex的特性

开发效率方面，和React Native 几乎没啥差别，不过本地开发调试方面没有React Native 体验好。动态化方面，天然支持动态化而且还支持拆bundle，React Native当然也支持拆包但需要改造。

2.3 总结

尽管借助NA 渲染方式相比混合开发性能高很多，而且方案也很完美，但还有很多不足的地方比如框架自身维护成本高，主要是因为提供的组件大多依赖原生控件，那么这些An‐droid 和iOS 控件也不是一成不变的，系统厂商也会做一些迭代，那么就必然要适配，适配成本很高。所以就会存在天然抹不平双端的差异，所以才有了后来的自渲染技术。

3 自渲染技术

含义是通过框架自身的自绘引擎，来实现布局和绘制到终端，可以认为是从另一个角度的创新，为人们打开的新的方向和思考，自渲染的代表作就是Flutter，接下来我们就一起了解下Flutter的核心架构思想以及特性。

3.1 Flutter架构组成

Flutter 是以Dart 语言编写[6]，基于Dart 编写提供了很多组件也叫Widget，有两套风格的Widget，分别Material 和cuperti‐no。两套风格有很多widget，比如Text、Input等，也提供了动画、手势等通用的Widget。因为没有采用WebView，也就没有JS和Native 的通信了，而是自行实现一套UI 框架，在引擎底层通过Skia[6]渲染到屏幕。对于UI之外所需要使用的移动设备自身提供的服务，比如相机拍照、定位等，则采用Platform Channels[6]接口跟原生系统通信的方式来实现。

3.2 Flutter的特点

效率方面，因为采用dart 语言编写，需要先熟悉dart 语言，但熟练后效率有明显提升，同样也支持热Hot Reload 能够很好地在本地进行快速的开发和调试。动态化方面，目前iOS是不允许进行热更的，因为苹果官方禁止JS Path，当然Android是可以热更，但大环境目前是不太友好的。平台一致性方面，可以做到像素级UI控制，能做到最大限度的还原，保证最大限度在不同平台的体验一致性，目前还支持PC、嵌入式等。性能方面，这块优于以上介绍的所有跨平台框架方案，也是最能媲美原生性能的跨平台技术方案，因为Dart代码执行效率比JS高很多，而且是通过AOT 编译成平台原生代码[7]，渲染采用Skia 方案，既不需要JS Bridge也不涉及虚拟机[8]。

4 总结

通过从最早的Apache Cordova 混合开发技术的背景开始，分析了当时混合开发时代的优劣势，当时的开发者为此做了很多努力和改进，让我们知道当时的技术方案是可以降本增效的，但有诸多弊端，于是就迎来了原生渲染技术的时代，这个时代放大了前端生态的繁荣，很多方案都是借助前端技术栈作为入口，撬动了整个跨端方案，无论是从体验、性能、一致性上都完胜混合开发，但还是有诸多不完美，比如依赖三方组件，依赖厂商适配，同步迭代更新成本高等问题。最后出现了自渲染技术，这对于整个跨平台方案来说立意高，创新强，一出来就在用户体验层面和平台一致性上完胜依赖原生Native渲染方案，但不支持热更，有一定的学习成本。所以综上所述，目前性能最佳、一致性最好的方案是自渲染。但如果想支持热更最佳选择就是React Native。