IM即时通讯移动端开发跨平台UI技术

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

第一类：WebView 跨平台技术

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

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 线程负具体指令的绘制，将绘制指令渲染输出到显示器上。

 

WebView渲染流程及线程模型

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

WebView 的 JS 执行， DOM 构建， RenderObject 的构建， Layout Paint 都在主线程执行。

Compositor Thread 负责 Layer 合成， Worker Thread 进行图片解码及 GPU 光栅化。 GPU Thread

进行最终的指令合成和渲染显示。

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

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

标准的实现难度非常高：

1）每个引擎代码行数都在 500-1000 万行；

2）庞大的代码规模导致入门和改动成本比较高，引擎定制成本非常复杂。

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

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

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 始终无法避免的问题。即时通讯聊天软件app开发可以加蔚可云的v：weikeyun24咨询

 

6）设备平台众多，需要兼容CPU渲染，无法进行 All In GPU 的设计。

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

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

Weex 对外通过 Rax 和 Vue 前端框架进行功能输出，前端框架下有一层 JS Framework 来实现 dom 的功能。

WeexCore 负责基础的 Flex Layout ，然后通过 Component 分别对接到 Android/iOS 的 Platform

Native View 体系。

Weex 体系中， JS 的执行在 JS Thread，Layout 执行在独立的 Layout Thread ，渲染执行在系统的

MainThread ，三个线程相互独立，并行执行。在 WebView 的体系中 JS 的执行、 Layout 、 Paint 都在

MainThread ，相互影响，在进行复杂任务时会导致界面卡顿。

对比可以看出：

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 的性能。

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

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

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

第三类：Flutter 跨平台技术

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

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 平台接口调用的插件机制。

Embedber 层收到 VSync 信号，把此信号传递给 Dart VM 中运行 Flutter Framework 。 Dart UI

FrameWork 首先处理 Animation 差值，然后更新 Widget Tree ，接着更新 Element Tree ，最后更新

RenderObject Tree ，发起 Paint 流程。再由 SceneBuilder 输出 Layer Tree ，提交到 GPU

线程进行这一帧的阻塞式合成，合成完成后开始下一帧。

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

Flutter 和 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 融合上存在一定成本。

Flutter 相对 Weex Native 的优势与不足

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

但是：

1）上层采用 Dart 语言，没有利用到前端最强大的 JavaScript 生态；

2）和 NativeView 的融合上也存在一些问题，难以复用 Native 多年来积累的强大组件。

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

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

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

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

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