android ios 对比 组件_盘点主流移动端跨平台UI技术：实现原理、技术优劣、横向对比等...

当前最热的跨平台UI技术无疑非 Flutter 莫属，Flutter通过自绘 UI 组件，构建高质量跨平台组件库，解决了此类框架难以解决的双端一致性， Bridge 通信效率等问题。并提供丰富的 Widget 组件，渲染性与 Native UI 相媲美，掀起了大家对下一代跨平台技术探索的热情。

同时对国内闲鱼、GCanvas、支付宝、Weex 等都投入了不少研究，通过 Flutter 打造自己的渲染引擎，支持 APP 内业务、小程序等业务。基于 Flutter 引擎有哪些误区？有木有性能媲美 Flutter 的跨平台渲染技术？

本文将通过阐述跨平台 UI 框架的的历史、实现原理、技术优劣，并简单进行横向对比，希望能为你在如今纷乱复杂的跨平台 UI 框架选型上提供一些参考意见。

点评：经常有人在即时通讯网的群里或私信我，说基于Hybrid这种方案的移动端APP里能不能对接即时通讯？该使用什么协议通信？TCP？UDP？还是WebSocket？显然，要正确地认识这些问题，对于即时通讯或相关应用的开发者说，了解当前主流的跨平台移动端UI框架技术原理等，是很有必要的，以免在新产品或项目中的技术选型上走弯路。这也是为什么我要整理与此相关的文章的原因所在。

2、相关文章

《最火移动端跨平台方案盘点：React Native、weex、Flutter》（ 推荐）
《小程序技术始于微信？来看看移动端小程序技术的前世今生！》

3、第一类：WebView 跨平台技术

第一代跨平台技术主要以 Webview 容器，代表有 PhoneGap/Cordova 。优点：功能丰富，标准强，历史悠久，有强大的前端生态支持；是目前最成功的跨平台渲染容器。支付宝及微信更是以此为载体，打造小程序内核。第一代渲染引擎主要缺点在于性能方面及高级组件方面，流畅性始终与 Native 无法媲美。

为何会这样，我们以 Blink 为例从三个方面来看此原因。

3.1WebView 的基础架构及线程模型

盘点主流移动端跨平台UI技术：实现原理、技术优劣、横向对比等_1.png
▲ Blink基础架构示意图

Android 平台 WebView 采用多进程架构，主要分为:

• 1）Browser 进程；
• 2）Render 进程；
• 3）GPU 进程。

Browser 进程负责用户输入， Touch 事件处理、平台相关的对接等功能。 Render 进程 Main Thread 负责 JS 的执行， CSS 解析， Layout Paint ，输出 DisplayList 供 CC 使用。 Work Threads 进行图片的编解码。 Compositor Threads 负责 Layer 的合成，和 Tile 分片；将分片输出成 Bitmap 或者 GL 指令，通过 IPC 输出到 GPU Process 。 GPU Process 的 GPUThread 线程负具体指令的绘制，将绘制指令渲染输出到显示器上。

3.2WebView渲染流程及线程模型

WebView 的渲染一般从载构建成 DOM Tree 开始算起。下图是 Blink 发起一个样式变更，到最终渲染到屏幕上渲染流程。图片来自于 A Pixel Life In Blink 。

盘点主流移动端跨平台UI技术：实现原理、技术优劣、横向对比等_2.png

▲ 一个像素从更新发起到显示的具体流程

下面是 WebView 渲染具体的具体执行的线程模型：

盘点主流移动端跨平台UI技术：实现原理、技术优劣、横向对比等_3.png

WebView 的 JS 执行， DOM 构建， RenderObject 的构建， Layout Paint 都在主线程执行。 Compositor Thread 负责 Layer 合成， Worker Thread 进行图片解码及 GPU 光栅化。 GPU Thread 进行最终的指令合成和渲染显示。

盘点主流移动端跨平台UI技术：实现原理、技术优劣、横向对比等_4.png

上图 Render 进程是与 GPU 进程 GPU Thread 的交互图，WebView 每一帧的更新都需 IPC 调用更新到 GPU Process ，这种 IPC 模型相对线程通信还是比较昂贵的。

3.3HTML5 作为开放的技术标准，历史悠久，包袱多

HTML5 标准在 Android/iOS 引擎实现不统一， Android 平台 Chrome(blink) ， iOS 平台 WKWebview(Webkit) 。

标准的实现难度非常高：

• 1）每个引擎代码行数都在 500-1000 万行；
• 2）庞大的代码规模导致入门和改动成本比较高，引擎定制成本非常复杂。

目前从国内来看， UC /阿里云有能力做内核级别的高级定制开发，其它团队难以进行大规模内核级别的高级定制。无线端 Native 平台成熟的 List Scroller Cell 等高性能组件，无法在 WebView 内核级别做有效的支持。以小程序内嵌 NativeView 所需的同层渲染技术为例，在两个平台要做不同的技术实现。 HTML 规范从提出到落地时间非常长，一般 3-5 年后才能普及，业务难以等待。

3.4WebView 渲染引擎设计的上的缺陷

• 1）JS Execute，Layout， Paint 都在MainThread ，无法并行化。
• 2）JS 的性能赶不上 Native Tookit 的 Java Dart Object-C 等编译型语言，执行复杂逻辑时会卡顿。
• 3）渲染流水线非常长，导致浏览器对合成器动画和非合成器动画区分对待，非合成器动画性能不佳。
• 4）OpenGL 设计上是推荐单线程模型，一个 Context 同时只能运行一个线程使用。 GPU Thread 运行在单独 GPU 进程， Render 进程无法访问 GPU 进程的 OpenGL Context ，两个进程无法 Texture 共享资源。 Render 进程只能输出 Bitmap/Command Buffer 通过 IPC 传递给 GPU 进程，无法直接在 GPU 进程的 Open GL Context 做直接光栅化，难以充分发挥现代 GPU 的性能。
• 5）光栅化是异步进行的，进行惯性滚动时，会出现白屏，这个是 Webview 始终无法避免的问题。
• 6）设备平台众多，需要兼容CPU渲染，无法进行 All In GPU 的设计。

4、第二类：Weex/React-Native 跨平台技术

第二类跨平台框架主要以 Weex/React-Native/ 鸟巢等为代表，这种技术最大化的复用前端的生态和 Native 的生态体系，把 Native View 的高性能组件积累输出给前端的技术体系。此方案和浏览器的最大区别在于 Script 的执行和 Native View 渲染体系。

4.1Weex 的基础架构

盘点主流移动端跨平台UI技术：实现原理、技术优劣、横向对比等_5.png

Weex 对外通过 Rax 和 Vue 前端框架进行功能输出，前端框架下有一层 JS Framework 来实现 dom 的功能。 WeexCore 负责基础的 Flex Layout ，然后通过 Component 分别对接到 Android/iOS 的 Platform Native View 体系。

4.2Weex 基础架构 JS 执行上相对 WebView 的优势

盘点主流移动端跨平台UI技术：实现原理、技术优劣、横向对比等_6.png

▲ Weex 和 WebView 在 JS Execute Layout Paint 线程模型区别

Weex 体系中， JS 的执行在 JS Thread，Layout 执行在独立的 Layout Thread ，渲染执行在系统的 MainThread ，三个线程相互独立，并行执行。在 WebView 的体系中 JS 的执行、 Layout 、 Paint 都在 MainThread ，相互影响，在进行复杂任务时会导致界面卡顿。

4.3Weex 体系渲染流水线及 OpenGL 设计上和 WebView 区别

Android Native 线程模型和 WebView 线程模型对比如下图：

盘点主流移动端跨平台UI技术：实现原理、技术优劣、横向对比等_7.png

盘点主流移动端跨平台UI技术：实现原理、技术优劣、横向对比等_8.png

两图对比可以看出：

• 1）Android Native 采用更轻量级的渲染流水线，能更快更高效的的响应事件；
• 2）RenderThread 直接操作 OpenGLContext ，进行 Direct GPU Raster ，充分发挥现代 GPU 的特性，提供高性能渲染和流畅的体验；
• 3）部分耗时操作，如 Bitmap 上传 Texture ， TextureThread 上传到 Share Open GL Context 中， Texture 完成后通知主线程进行绘制，通过 Share Open GL Context 与主线程共享 Texture 等资源。 WebView 只能在 Render Process 内部进行 Texture 的共享， RenderProcess 无法与 GPU Process 共享 Texture 等资源；
• 4）Android Native 有 RecycleView ViewPager 等高级组件，每个高级组件都做了性能的最佳实践；浏览器上的高级组件只能通过 JS 模拟实现，优化定制效率低；
• 5）浏览器流水线设计复杂，需要考虑到 PC 、手机、嵌入式设备等多种复杂的环境，不少设备上木有 GPU ，只能进行 CPU 渲染。无法像 Android Native 体系一样进行 All In GPU 的体系设计，全面发挥现代 GPU 的性能。

4.4Weex 体系在跨平台及性能上的不足

Weex 体系充分将 Native 的 View 体系输出到前端体系中，在进行 Android/iOS Native View 的封装过程中，存在不少难以逾越的障碍。

如：难以磨平的双端一致性问题、复杂样式能力难以实现、 Layout 动画需要执行两次（WeexCore Layout 和 Android Native 本身的 Layout ）。组件的封装成本随着复杂度增加也越来越高，难以逾越 Native View 限制提供更细致的 W3C 标准能力。

5、第三类：Flutter 跨平台技术

2018 年 Flutter 横空出世，通过 Dart 语言构建一套跨平台的开发组件，所有组件基于 Skia 引擎自绘，在性能上和 Native 平台的 View 相媲美。引起大家广泛关注，充分验证了通过绘制构建组件做到 Native View 媲美的 UI 渲染引擎的可行性。

5.1Flutter 的基础架构

盘点主流移动端跨平台UI技术：实现原理、技术优劣、横向对比等_9.png

▲ Flutter基础架构

Flutter 基础架构主要分为三个部分：

• 1）Framework 层：包含 Animation Painting Gestures RenderIng Widgets 等模块；提供基础的 UI 组件；
• 2）Engine 层包括： Dart VM Manager ， Frame Pipeline Rendering , TextLayout 等模块，主要负责 Skia 的渲染调度以及 Layer Tree 等合成；
• 3）Embedber 层分别对接 Android/iOS 平台层，进行事件对接， Surface 对接，以及 Native 平台接口调用的插件机制。

5.2Flutter 的渲染流水线和 Android Native 对比

a. Flutter 的渲染流水线：

盘点主流移动端跨平台UI技术：实现原理、技术优劣、横向对比等_10.png

▲ Flutter 渲染流水线

Embedber 层收到 VSync 信号，把此信号传递给 Dart VM 中运行 Flutter Framework 。 Dart UI FrameWork 首先处理 Animation 差值，然后更新 Widget Tree ，接着更新 Element Tree ，最后更新 RenderObject Tree ，发起 Paint 流程。再由 SceneBuilder 输出 Layer Tree ，提交到 GPU 线程进行这一帧的阻塞式合成，合成完成后开始下一帧。

b. Android Native 渲染流水线：

盘点主流移动端跨平台UI技术：实现原理、技术优劣、横向对比等_11.jpg

▲ Android Native 渲染流水线

Android 系统 Native View Framework 收到 VSync 信号后，首先进行 Touch、Input 等事件处理，再进行 Animation 的更新处理，之后 View Tree 发起 Measure和 Layout 完成布局过程。通过 Draw 把本次更新的脏节点更新的 DispayList 绘制指令同步到 RenderThread 。 RenderThread 通过 DisplayList 对 RenderNode 更新合成，把指令转换成 OpenGL 绘制指令输出到 GPU ， 整个流程和Flutter基本相同。

5.3Flutter 和 Android 在渲染方面相似点和不同点

a）Flutter 和Android 共同点：

• 1）采用精简的渲染流水线，从事件到 GPU 更新整体渲染流程很相似；
• 2）在 GPU 层面进行直接光栅化，充分利用现代 GPU 的高性能渲染性能；
• 3）都采用 OpenGL Share Context 进行设计，异步进行图片 Texture 上传，共享图片等 Texture 资源；
• 4）最新版本 Android Native 和 Flutter 底层共同采用 Skia 引擎进行合成绘制。

b）Flutter 和 Android 不同点：

• 1）Android Native 采用 Java 构建 UIFramework ， Flutter 采用 Dart ；
• 2）Android Native 支持局部更新，在 Open GL 层面做了非常多的深层次的优化， Flutter 这块工作目前不足；
• 3）Android HW UI 是系统应用，可根据手机机型及 GPU 进行参数调优，深度定制；这是 Flutter 框架做不到的；
• 4）目前 Android 生态 UI 库比较全面，模块之间融合成本低。 Flutter 自成体系，和 Native View 融合上存在一定成本。

5.4Flutter 相对 Weex Native 的优势与不足

Flutter 引擎基于 Skia 构建跨平台组件，解决了 Weex 难以解决的双端一致性等问题。

但是：

• 1）上层采用 Dart 语言，没有利用到前端最强大的 JavaScript 生态；
• 2）和 NativeView 的融合上也存在一些问题，难以复用 Native 多年来积累的强大组件。

这些是它相对于 Weex 的不足。

在性能方面， Flutter 和 Weex 解决方案，本质上基本相同，实际页面性能取决于最佳实践，目前实际情况看 Weex 的 NativeView 性能优势更强一些。

5.5在 Flutter 渲染引擎上的探索与实践

Weex 团队、GCanvas 团队、UC 团队、支付宝团队都在研究 Flutter Engine 。

目前主要由 C++ 流和 JavaScript 流两种做法。这两种做法的共同点核心仍采用 Flutter Engine 的渲染流水线，去除 Dart VM ，引入 JavaScript 生态，把 Flutter 标准转换成 W3C 标准对外输出。

下面简单介绍一下这两种做法：

盘点主流移动端跨平台UI技术：实现原理、技术优劣、横向对比等_12.jpg

▲ Flutter体系向前端输出尝试探索

方案一：通过把 Flutter Widget 整个体系采用 TypeScript 重写，来实现 Flutter 的 JavaScript 的化，上层再基于 JavaScript 的 Widget 封装框架。

方案二：通过把 Flutter的 Framework 采用 C++ 重写，在 Widget 上层封装一层 Component 层，完成 Widget 到 W3C 标准层的转换，然后通过 JavaScript Binding 把 HTML 标准讲功能对外输出。

两种方案都难以把 Flutter 整个体系迁移过来，只能挑选核心的组件进行重写，都是非常不错的尝试。

5.6Flutter 引擎走 HTML 子集输出的缺陷

Widget 标准对于前端不友好，因此不少团队开始尝试把 Widget 体系转换成前端标准子集进行功能输出。在完善的 Flutter Widget 的前提下，Flutter Widget 通过 Component 封装转换成前端 HTML5 标准进行输出。

此方式相对 Weex 封装 Android/iOS 平台 Native View 做法，具有解决 Weex 面临的双端一致性的问题优势。

但Weex 从 Native View 到 W3C 的标准转换很难去完美适配，Flutter 的 Widget 实际到 HTML5 标准转换过程中一样会存在。在深层次标准适配时，会出现难以解决的样式和布局能力扩展的问题。由于引擎本身绘制能力可扩展性，这些方面的缺陷相对 Weex 会弱一些。

整体来看：

• 1）Widget 的标准转换到 HTML5 标准只能做部分实现，难以完美适配；
• 2）进行复杂样式组合时会碰到和标准不一致的现象，难以像下一代定制内核的UI渲染引擎一样高效。

6、横向对比以上三类跨平台技术

上面整体介绍了三类主流的跨平台渲染引擎，下面从特点和技术方面来总结上面的跨平台渲染引擎。

6.1跨平台渲染引擎的特点上对比

盘点主流移动端跨平台UI技术：实现原理、技术优劣、横向对比等_13.jpg

备注： WebView性能目前随着手机性能的提升而逐步提升，在某些高端机上简单页面的性能已经非常流畅，但在复杂页面尤其是有交互的页面和Weex还是有一定的性能差距。

6.2跨平台渲染引擎的技术上进行对比

盘点主流移动端跨平台UI技术：实现原理、技术优劣、横向对比等_14.jpg

此表格概括了目前主流的三代跨平台渲染引擎的技术特点。

7、最后总结

目前各种渲染引擎并不是一成不变的，都在蓬勃发展。如 Blink 的 Slimming Paint 项目采用和 Native View 相同的策略， Render Layer 只输出 Display List ，由 CC 根据策略是采用 Layer Compositor 还是 Direct GPU Raster 思路？ Firefox 的 WebRender 渲染引擎，尝试把 JS 的执行， Layout、Paint 的执行并行化，并采用更高级的 GPU 绘制元素的方式。

相信未来一定会涌出不少优秀的跨平台 UI 渲染引擎。
原文作者：JackJiang
原文链接：http://www.52im.net/forum.php?mod=viewthread&tid=2641&ctid=16
来源:即时通讯网