了解更多
输入“/”快速插入内容
了解更多
了解更多
原理
为什么 MPFlutter 可以运行在微信小程序上？MPFlutter 在背后做了什么工作？
在回答这个问题前，我们先看看 Flutter 官方是如何在 Web 上运行 Flutter 应用的：
画板
这里有几个要点：
•
Dart 代码是无法直接运行在浏览器的，必须编译成 JavaScript，Dart 提供了 dart2js 编译器。
•
浏览器是没有 Skia API 提供的，因此需要找到合适的 Renderer 用于最终渲染，存在两种 Renderer。
◦
HTML Renderer，它直接将 RenderTree 翻译成普通的 DOM 对象，添加到 body 上，由浏览器自行合成界面。
◦
CanvasKit Renderer，它借助 WebAssembly 技术，使得 Skia 可以运行在浏览器上，并结合 WebGL 渲染界面。
不同的渲染方案各有优点：
•
HTML Renderer 兼容性更好，也不需要关注字体加载问题，但是在移动端性能表现堪忧。
•
CanvasKit Renderer 性能最优，兼容性在现阶段已不是问题，但需要关注字体加载、包体积等问题。
从 Flutter 的渲染一致性角度来看，CanvasKit Renderer 是更贴近 Flutter 的理念的。
MPFlutter 2.0 选择了 CanvasKit Renderer 方案：
MPFlutter 2.0 完全复用 Flutter For Web 的基建，我们提供了以下适配策略：
•
裁剪并编译一个符合微信小程序包大小要求的 Skia WebAssembly 库；
•
适当地调整 Skia CanvasKit 加载脚本，使它能运行在微信小程序上；
•
添加智能分包策略，使 main.dart.js 以及资源文件可以在构建阶段智能地分配到不同分包中；
•
在微信小程序中，补全 Flutter For Web 所需要的 Web API；
•
在微信小程序中，补充必要的触摸、键盘事件回传。
方案优点
MPFlutter 在帧率表现上优于传统的小程序开发模式。
传统的小程序开发模式其数据交换可见下图：
画板
MPFlutter 数据交换可见下图：
画板
可见 MPFlutter 方案仅在页面创建时，使用 WXML 一性次地获取 WebGL 上下文，后续的界面更新都闭环在 JS Context 中。
而传统方案则需要不断使用 setData 传输数据至 WebView 层，通过 DOM 刷新的方式更新界面。
在强交互、需要持续使用 Data 刷新界面的场景下，MPFlutter 的表现明显是更优秀的。
方案缺点
当然，MPFlutter 也存在以下缺点：
•
包体积大，相比传统方案，MPFlutter 的初始包体积是 5M。
◦
Skia 2M
◦
main.dart.js 1.8M
◦
内置字体 1.2M
•
运行内存占用更高
◦
WebAssembly 的初始化需要提前申请更多内存
◦
Skia 对于图片编解码也需要额外申请内存
•
字体需要另行加载（原因： 字体使用 ）
•
微信小程序提供的视图组件需要使用 Platform View 方式实现
小结
MPFlutter 2.0 方案是一种全新的开发模式，它大大的提高了微信小程序的性能上限，并使得 Flutter 技术可无缝迁移到微信小程序。