X-Plat Development Analysis

1. 1
Thoughts on X-Plat Development

2. X-Plat Dev-Framework Assessment Criteria
2
Domain Category Factors Details
Infrastructure Maturity
Viability License/open source
X-Plat/Device Supported target platforms
Tool/L Development platforms OS, (language)
Ease of Use/M Deploy channel support restriction, publishing, analytics
Ease of Use/M Monetization support free, freemium, paid, in-app purchase, advert
3rd-Pty Support Internationalization localization
Viability Long-term feasibility backing entity, cycle/update, maturity, stability, (community)
3rd-Pty Support Community adoption, popularity-fork/star/commit, examples
Development Support
Tool Language multiple front-end language support, syntax/style, AOT/JIT
Tool Toolchain complier, (CI/CD)
Tool IDE dependencies, hot reload, autocomplete, syntax check, built-in debug/emulator, (CI/CD)
Tool UI design support hot reload, GUI, no-code/low-code
Ease of Use Testing code analysis, testing API, pressure, profiling, logging
Ease of Use CI/CD build, source/package, pkg-sign, deploy, container
Ease of Use Ramp-up curve boilerplate, document, demo, (language/syntax), (community)
Ease of Use Scalability design pattern, modularization
Other/L Development process fit waterfall, extreme, agile
Ease of Use Maintainability hotfix solution, app structure, LOC, readability, design pattern, in-app doc
3rd-Pty Support Extension plug-in, library, components, (native platform access)
X-Plat/Device Configuration/Product support style/theming/branding, (free/paid), (localization)
App Functionality
Characteristic Philosophies main design target/pattern, characteristics, & optimal app/service type
Capability Device specific hw access
Capability Platform specific function
X-Plat/Device X-device programming
Capability Input heterogeneity
Capability Output heterogeneity
Capability App lifecycle mgmt multithreading/background service/live notification
Capability System integration Cloud API/Backend
Quality Security
Quality Robustness
App Usage
X-Plat/Device Look and feel native appearance, x-plat UI consistency
Quality Performance download/app-size, start-up, execution/speed, rendering, UI responsiveness, power, resource-consumption
Other/L Patterns online/offline running

3. What Makes a Good X-Plat Dev-Framework
3
• Optimize x-ecosystem development: iOS, Android, HarmonyOS, Web(KaiOS/H5)/Webview
• Assume desktop is not our priority, though the support of it is feasible
• Optimize development for 1+8+N x-device use cases
• Assume dynamic coupling of devices
• Laptop programming experience with power of device group
Ideal DevFramework
1
Design
Philosophy
Design characteristic aligned with target deliverable
2 Toolchain Familiar, highly efficient, comprehensive Tool support
3 Ease of use Very easy to learn, use, scale
4 Capability Rich capability for wide range of application
5 X-Device Superior x-plat/device programmability
6 Quality Create high quality/performance target deliverable
7 3rdpty Support Extensive community support
8 Viability Worth developer's long-term investment

4. X-Plat App Dev-Framework Landscape
4
Flutter
(Google)
React
(Facebook)
Others
(Xamarin
etc.)
WeeX
(Alibaba*)
Chameleon/
Uniapp
(3rd Pty)
Others
(Taro etc.)
欧美开发社区
中国开发社区
App应用开发 小程序开发
https://insights.stackoverflow.com/survey/2019#technology-_-most-loved-dreaded-and-wanted-other-frameworks-libraries-and-tools
https://www.statista.com/statistics/869224/worldwide-software-developer-working-hours/
http://www.statista.com/download/Statista-Privacy-Policy.pdf

5. • 背景
• 架构解析（设计理念，框架）
• 关键技术/模块设计
• 优劣分析
• 借鉴思考
Flutter/React Native/WeeX/? Teardown
5
业界领先的X-
Platform开发框架

6. WeeX Teardown: 背景
6
• Sponsored by Alibaba and announced in 2016, currently incubated in Apache with ASL2.0 license
• 设计理念:
• 利用前端开发技术（HTML/CSS/JS）开发多端（ Android/iOS/Web/Webview）接近原生体验的跨平台
应用/服务（一套代码，一次开发，多端运行）
• 结合兼顾简洁的前端开发和原生的性能
• 解决频繁版本发布和跨平台研发的痛点
• 关键词：JavaScript, Vue设计模式，原生渲染
WeeX
JS
frmwk JS
frmwk JS
frmwk
Android
App iOS
App Web
App
JS
Bundle
JS Bundle
(Cloud)
Server
(Device)
Client
V8/JSC
Runtime
WXBridge
Native-Render
WXFrmwk
发布转换

7. WeeX Teardown: 架构解析/关键技术
7
JS Bundle
(Cloud)
Server
(Device)
Client
V8/JSC
Runtime
WXBridge
Native-Render
WXFrmwk
Web-
Render
Call JSCall Native
V-DOM
构建
Patch
比较
H5-DOM API
Native-DOM
API
DOM+Bridge
线程
UI
线程
组件 模块 适配
JSCore
WebView/
Native View
逻辑层渲染层

8. WeeX Teardown: 优劣分析
8
• Pros
• 一次编写，多端运行：通过WeexSDK实现上层的完全三端统一性，再通过VirtualDOM来实现对原生平台
的适配，达到近原生性能
• 更轻量：
• WeexSDK和业务JS分开打包，WeexSDK在端侧提前部署，减少业务JS动态下载代码大小
• 每页动态bundle进一步减小启动时间（但也带来新的问题，见下）
• 学习成本小：
• 使用Vue设计模式
• 提供wap playbround允许开发者轻装上阵不需要AndroidStudio/Xcode就开发功能页面原型
• Cons
• 基础能力不够好（e.g.调试体验分离，稳定性，页面宽高尺寸值固定，网络请求能力，存储能力等）
• 不兼容许多Web标签，使用自定义标签。CSS支持度不够完善。对W3C的Flexbox支持不完善
• 要完成端到端的开发，需要在原生平台上做少量导入/集成（e.g.WXApplication， InitConfig, MainActivity
implements IWXRenderListener() …)。
• 每页动态bundle带来新的问题：重复下载页面共享模块，而且页面间数据共享和跳转不能依靠Vuex/Vue-Router，
需要使用自己封装的navigator等
• 社区支持不足
• 阿里对Weex的支持遭受内部竞争风波，托管给Apache后有所稳定下来
• 文档欠缺，有些错误，有些过于简单。示例欠缺
http://www.shouce.ren/api/view/a/11585
Score
Design
Philosophy
Good
Toolchain Bad
Ease of use Good
Capability OK
X-Device N/A
Quality Bad
3rdpty Support Bad
Viability Bad

9. WeeX Teardown: 借鉴思考
9
• Weex和RN的设计理念非常类似：使用JS前端技术开发，通过核心JS引擎将代码编译成原生组件，
趋近原生性能。Weex开发和原生平台的依赖性更小。
• Write Once， Run Everywhere是终极目标：需要代码随平台没有差异，技术方案上可以使用自有
全栈渲染引擎，或者通过适配层隔离使用原生渲染引擎
• 平台的关联性越低越好：这就要求有完善的功能和基础能力，以及丰富的预定义组件/模块。（鉴
于Weex的当前功能不完善，不合适用于完全的App开发）
• 强大的扩展能力才能支持灵活的应用实现：很多应用都已经有现有版本，完全重写并不现实，需要
完善的定制组件/模块能力来最大化的利用现有实现
• 前端语言/设计模式的简洁易用是非常关键的“第一印象”：Vue简洁易用颇受前端开发者认可，有效
提升Weex的吸引力
• 活跃的社区反哺开发者信心：Weex社区活力的没落造成开发者对其长期性信心动摇

10. WeeX Teardown: 参考
10
Domain Category Factors Details Weex
Infrastructure
Maturity
Viability License/open source 友好/ASL2.0
X-Plat/Device Supported target platforms 有优势：一次编写，三端运行，依赖V8/JSC, 支持Android/iOS/Web
Tool/L Development platforms OS, (language)
web工具基本上是全平台
Pack+CLI+DevTools
Ease of Use/M Deploy channel support restriction, publishing, analytics 没有支持
Ease of Use/M Monetization support free, freemium, paid, in-app purchase, advert 没有支持
3rd-Pty Support Internationalization localization 没有支持
Viability Long-term feasibility backing entity, cycle/update, maturity, stability, (community) 劣势：最近release一年前，最近commit也几个月前，基础功能有待提高
3rd-Pty Support Community adoption, popularity-fork/star/commit, examples 14k star, 2k fork, 550 watch, 三方组件和样例不够丰富，拥护者主要在中国
Development
Support
Tool Language multiple front-end language support, syntax/style, AOT/JIT 有优势：Vue/JS，简洁易上手，依靠runtime
Tool Toolchain complier, (CI/CD) 转换打包JS
Tool IDE
dependencies, hot reload, autocomplete, syntax check, built-in
debug/emulator, (CI/CD) 没有自有IDE，通过插件支持，调试体验分离
Tool UI design support hot reload, GUI, no-code/low-code 有优势：提供wap playground可以快速开发原型
Ease of Use Testing code analysis, testing API, pressure, profiling, logging 没有自有支持
Ease of Use CI/CD build, source/package, pkg-sign, deploy, container 支持分包，文件较小，但没有CI/CD支持
Ease of Use Ramp-up curve boilerplate, document, demo, (language/syntax), (community) 语言易用，但样例不丰富。框架较轻
Ease of Use Scalability design pattern, modularization 组件式设计 + 渐进式开发
Other/L Development process fit waterfall, extreme, agile 适应现代开发模式
Ease of Use Maintainability hotfix solution, app structure, LOC, readability, design pattern, in-app doc
继承了web前端技术的一定热补能力，继承了Vue的设计模式（e.g.MVVM)， UI/业务分层。不
过预定义组件/模块有限，虽然可以定制
3rd-Pty Support Extension plug-in, library, components, (native platform access) 三方组件，库和样例不丰富，支持定制组件/模块对接原生能力
X-Plat/Device Configuration/Product support style/theming/branding, (free/paid), (localization) 没有直接支持
App Functionality
Characteristic Philosophies main design target/pattern, characteristics, & optimal app/service type 一次开发多端运行；web前端技术开发UI，后端原生渲染；
Capability Device specific hw access 通过定制模块实现
Capability Platform specific function 通过定制模块实现
X-Plat/Device X-device programming 没有支持
Capability Input heterogeneity 通过定制模块实现
Capability Output heterogeneity 通过定制模块实现
Capability App lifecycle mgmt multithreading/background service/live notification 通过定制模块实现
Capability System integration Cloud API/Backend 通过定制模块实现
Quality Security 没有自有设计
Quality Robustness 有待提高
App Usage
X-Plat/Device Look and feel native appearance, x-plat UI consistency 原生渲染带来原生体验，跨平台体验难保完全一致
Quality Performance
download/app-size, start-up, execution/speed, rendering, UI
responsiveness, power, resource-consumption 分包可以减少动态下载大小，不过应用大小和其他差异不大，性能近原生但受限JS
Other/L Patterns online/offline running 没有支持

11. React Native Teardown: 背景
11
• React Native (RN): 使用React/JavaScript来开发跨平台原生移动应用的平台
• Initial release @ 2015年3月 by Facebook Inc., 90.8k stars in GitHub @10/2020
• License: BSD + Patent(2018年3月以前) => MIT license (2018年3月以后)
• 对开发者和大公司的商业开发更友好，弱化了Facebook通过已有专利对开源社区的控制力
• 生态系统目前由三层控制：以Facebook为核心，包括微软等企业伙伴和社区贡献者为主
• RN 支持下面平台:
• iOS, android 和 Web (官方支持)
• Windows 和 UWP (微软支持), 目前支持windows 10系列设备
• macOS, Android TV, tvOS, Linux等 (社区支持)
• React (RN基于React): a JavaScript for building user interfaces
• Introduced @ 2013年5月, 由Facebook和社区共同支持. 158k stars in GitHub @10/2020.
• License: BSD + Patent(2018年3月以前) => MIT license (2018年3月以后)
• RN-React都基于JavaScript编程语言：最流行的前端OOP编程语言，非常易于学习和使用

12. 2.React Native Teardown: RN背后的框架
12
• RN-React 设计理念很大来源于MVC – (Web时代前端设
计最成功的框架）
• React的”component design”为基于RN的 JS开发人
员基于不同偏爱和需求来开发第三方框架和应用提
供了灵活性。
• RN-React实现了“抽屉式”的组件设计可以根据
不同需求来无缝实现。
• React/Flux天然的支持MVVM/MVC设计理念并
可以支持不同种类的Client MVC和Server
MVC应用。
• RN 通过提供桥接架构来连接React和原生系统而实
现快速简洁的跨平台方案：
• 集成的JSC可提供接近原生的性能
• React Native针对不同应用也提供不同性能的
rendering实现。

13. 2.React Native Teardown: RN-React架构实现
13
• RN + React的最新架构兼顾了抽屉式”component design”
实现和性能优化。
• 继承自React的抽屉式组件设计，可以通过更改MVC
框架内各部分的不同开源组件来实现不同用途：
• 例如采用 Flux + Node.js 来实现client/server
结构的应用，而采用Redux支持“Hot-
reloading”应用。
• RN Bridge + JSC Runtime 提供跨平台功能。
• 在iOS中使用集成JSC；而在Android中既可使
用集成的V8，也可使用其他优化Runtime，如
Hermes，以在非iOS的平台上提供更高的性能
和更小的应用程序大小。
• 针对不同应用也提供三种不同性能的rendering
实现 (React原生，RN原生和后引入的Yoga
Layout引擎 -Yoga/Flex渲染全部用C实现，
Android 性能提高33％)。
• 新一代RN bridge设计(下一页)

14. Model层
加快数据交流
2.React Native Teardown: RN Bridge新一代架构解析
14
• RN 在2019年3月更新最新一代的bridge架构
(React>=16.6, RN >=0.59)，关键改进：
• 支持最新的React / JS功能：如静态类型（来自
TypeScript）和并发。
• 重新设计桥来添加了并发、暂挂来加快桥间数据交
流，和减少桥跳，从而优化性能。
Old bridge
design
Optimization:
New bridge
design
Fabric：
单进程到多线程渲染实现
Turbo Module：
支持原生模块自主加载
CodeGen：
转换静态JS到原生类型
JSI：直接映射JS->C
消除桥接中的JSON和
原生之间转换
View层减少了
“桥跳”次数
BRIDGE
SHADOW TREE
JSON (ASYNC)
NATIVE MODULES
Any JS
REACT++
JavaScript
CODEGEN
JSI
FABIC
TURBO
MODULES
NATIVE(s)
STATIC TYPE

15. React Native Teardown: 优劣讨论
15
• Pros
• 支持单个代码开发，跨平台多端运行：
• 针对主流三端，React框架来统一不同平台的API来支持跨平台的开发统一性，并以不同RN Bridge的原生实
现来桥接上层API和原生平台的适配，从而达到接近原生性能的跨平台开发
• Learn once, write anywhere： RN设计上承认不同平台的不同，来最大限度保持本身的统一性，从而大大降
低跨平台开发的难度；做到只学习一个平台，就能开发大部分的跨平台应用
• 第三方社区和企业支持：
• 第三方支持全平台IDE和web工具丰富：如VS code, ReactIDE(web),Atom(Web),WebStorm和 reactstudio
等工具可视化快速开发原型
• 社区活跃，大量开发人员在网上提供大量问题解答，相对节约开发时间，如在stackoverflow数据库中，RN
长期排第一
• 抽屉式的组件架构设计：
• 组件式架构，能满足不同的开发者的开发需求，例如采用 Flux + Node.js 来实现client/server结构的应用，
而采用Redux支持“Hot- reloading”应用
• 同时框架结构也吸引了大量的第三方开发者和大公司如微软来支持整个软件平台的良性发展
• Cons
• 开放需要原生系统知识基础
• 不能做到完全屏蔽 iOS 端或 Android 的细节，前端开发者必须对原生平台有所了解， 加重了学习成本。(例
如 ActionSheetiOS只支持iOS, DrawerLayoutAndroid, ToastAndroid只支持Android)
• 存在一致性问题，针对不同平台之间的不同特性，由代码一致性问题
• 安全缺陷
• 组件式设计，架构本身没有考虑安全问题，只能依赖第三方组件（如oAuth2)和JSC来提供安全性，
• 不提供内部安全存储， 不能阻止如“deep-link”的非授权信息泄露缺陷
Score
Design
Philosophy
Good
Toolchain Bad
Ease of use Good
Capability OK
X-Device N/A
Quality Good
3rdpty Support Good
Viability OK

16. React Native Teardown: 借鉴思考
16
• 分层和组件式的理念需要继承，可以支持灵活的应用设计模式，并帮助解耦逻辑，大大增加代码的
可维护性
• 社区的活跃度是生态的关键，可以有效弥补官方支持的不足
• 开发框架本身必须是开放的：一方面开放接受现有的各种流行组件，另一方面，框架本身的组件结构也需
要可替换或者可叠加，来支持大多数当前和将来的应用场景
• 针对社区和第三方开发的也是开放的：需要吸引三方企业和社区开发者来共同构建一个不仅是开放平台还
是开放的生态系统
• 未来的跨平台开发框架必须是对开发者友好型的易学易用的平台
• 跨平台开发框架本身需要基于一种（或多种）流行且易于使用的语言，一种可能的选择是Java或
JavaScript
• 面向开发人员的丰富而易于使用的工具链对于未来的跨平台开发框架是必不可少，比如跨平台的统一的
IDE开发环境等
• JSBridge优化思路可以参考，主要聚焦减少桥跳次数和数据的交换

17. React Native Teardown: 参考
17
Domain Category Factors Details React Native
Infrastructure
Maturity
Viability License/open source 友好/MIT
X-Plat/Device Supported target platforms
有优势：一次编写，三端运行，自带或依赖V8/JSC/hermes, 官方支持Android/iOS/Web, 微软支
持Win, macOS, Android TV, tvOS, Linux.
Tool/L Development platforms OS, (language)
官方支持CLI，, 第三方支持全平台IDE和web工具
CLI+DevTools+IDE
Ease of Use/M Deploy channel support restriction, publishing, analytics 通过第三方组件支持
Ease of Use/M Monetization support free, freemium, paid, in-app purchase, advert 通过第三方组件支持
3rd-Pty Support Internationalization localization 官方支持
Viability Long-term feasibility backing entity, cycle/update, maturity, stability, (community) 优势，最近官方版本更新9月2020年
3rd-Pty Support Community adoption, popularity-fork/star/commit, examples
158k star 31.3k folk 6.8k watch(React) 90.9k20.1k3.7k(RN) 最活跃的社区和第三方开发者支
持，微软,Facebook支持
Development
Support
Tool Language multiple front-end language support, syntax/style, AOT/JIT 有优势：React/JS流行语言，简洁易上手，依靠runtime
Tool Toolchain complier, (CI/CD) 提供babel编译器及转换打包工具
Tool IDE
dependencies, hot reload, autocomplete, syntax check, built-in
debug/emulator, (CI/CD) 第三方支持全平台IDE和web工具: VS code, ReactIDE(web),Atom(Web),WebStorm,VIM
Tool UI design support hot reload, GUI, no-code/low-code 有优势：提供reactstudio 等工具可视化快速开发原型
Ease of Use Testing code analysis, testing API, pressure, profiling, logging 自带支持，包括静态测试到单元测试到端端测试等。
Ease of Use CI/CD build, source/package, pkg-sign, deploy, container 支持打包，文件包括JSC.so比较大，第三方工具链支持CI/CD支持
Ease of Use Ramp-up curve boilerplate, document, demo, (language/syntax), (community) 语言易用，样例丰富。框架可轻（去掉JSC),或重(加上JSC)
Ease of Use Scalability design pattern, modularization 抽屉式组件设计 + 渐进式开发
Other/L Development process fit waterfall, extreme, agile 适应所有适合MVC的现代开发模式（包括MVC/MVVM等）
Ease of Use Maintainability hotfix solution, app structure, LOC, readability, design pattern, in-app doc 三方组件提供”Hot reloading” ,支持主流MVC/MVVM等设计模式， 支持UI/数据/业务分层。
3rd-Pty Support Extension plug-in, library, components, (native platform access) 大量三方组件，通过不同组件/模块支持对接JSC系统接口或原生Layout引擎
X-Plat/Device Configuration/Product support style/theming/branding, (free/paid), (localization) 有第三方社区开源或商业工具支持
App Functionality
Characteristic Philosophies main design target/pattern, characteristics, & optimal app/service type 一次学习多端应用；web前端技术开发UI，后端原生渲染，支持不同类型的app应用；
Capability Device specific hw access 通过不同平台的RN bridge 模块实现
Capability Platform specific function 通过不同平台的RN bridge模块实现
X-Plat/Device X-device programming 不支持
Capability Input heterogeneity 通过第三方组件实现
Capability Output heterogeneity 通过第三方组件实现
Capability App lifecycle mgmt multithreading/background service/live notification 通过第三方组件实现
Capability System integration Cloud API/Backend 通过第三方组件实现，如嵌入node.js等
Quality Security 提供oAuth2等组件，但是由于组件式设计，本身无安全检查需要，存在”deep link”威胁。
Quality Robustness 有大量商业例证
App Usage
X-Plat/Device Look and feel
native appearance, x-plat UI consistency
针对不同平台提供原生渲染，获得原生APP类似体验，大部分共性跨平台体验一致，平台特性
体验无法保证完全一致
Quality Performance
download/app-size, start-up, execution/speed, rendering, UI
responsiveness, power, resource-consumption 相对原生APP较大，和其他跨平台方案差异不大，性能近原生但受限JSC性能
Other/L Patterns online/offline running 不支持

18. ▪ Flutter, X-platform open-source dev framework, initiated by Google.
▪ 1st release in 2018, and 105k stars (the most & way more than others) at GitHub in Oct.
2020.
▪ BSD 3-clause license - almost no constraint, as long as other company’s names are not used.
▪ Release cadence and versions are fully controlled by Google: TSC Google employees
▪ Fastest growing programming language and framework in 2019.
▪ Support below platforms, with “true” single codebase and the same UI (if preferred):
▪ Android
▪ IOS
▪ Windows
▪ macOS
▪ Linux
▪ Web
Flutter 背景
18

19. ▪ Everything is built-in widget.
▪ “True” single codebase + identical UI across
platforms.
▪ Fully independent from target platforms.
▪ Layered/nested pixel-level control, with the best
performance than others
▪ 自帶渲染引擎: Skia
▪ Only needs canvas for rendering from target
platforms.
▪ Support both AOT (Ahead-of-Time) and JIT:
▪ Able to compile app code into any target
platform’s binary/bytecode, without additional
bridge in the middle (like JavaScript) to sacrifice
the performance
Flutter 架构解析
19Flutter-related diagrams come from https://flutter.dev/tos with terms included.

20. Flutter Engine – How to Access Native Platform Resources
▪ Platform Channels:
▪ Able to access "all" known target
platform's resources like
GPS/camera, with NO limitations.
▪ When needed (for new native
features that Flutter doesn’t
support yet), Dart can do
embedding/integrating/interacting
with native code.
20Flutter-related diagrams come from https://flutter.dev/tos with terms included.

21. Flutter Web Support
21
▪ Flutter supports the “generation” of web content
using standards-based web technologies: HTML,
CSS, DOM and JavaScript.
▪ Flutter implements core drawing layer on top of
standard browser APIs.
▪ Developers can compile existing Flutter code of
Dart into client experience that can be
embedded in browser and deployed to any web
server.
▪ “NO” need of browser plug-in, with the
compilation/conversion generating minified
JavaScript source files (.js).
▪ PWA (progressive web application) is supported as
target package.
▪ Support Embedded interactive content.
▪ Not every HTML scenario is suited for Flutter.
▪ For example, Flutter may not help “blog” much,
which isn’t app-centric and doesn’t focus on
interactive experience much.
Flutter-related diagrams come from https://flutter.dev/tos with terms included.

22. ▪ Both native executables & plug-in are
supported.
▪ Flutter does the work of compilation
& conversion for target platforms.
▪ For now, require building “exactly on”
target platform for desktop support.
▪ On Windows, need “Visual Studio 2019” for
now to generate executable/DLL.
▪ On macOS, need Xcode for now to
generate executable (.app).
Require CocoaPods for generating macOS
plug-in.
▪ On Linux, “snapd” will install all
dependencies for Flutter support, in order
to generate Linux executable.
Flutter Desktop Support
22Flutter-related diagrams come from https://flutter.dev/tos with terms included.

23. ▪ Comprehensive family of official tools/plug-ins (all open source):
▪ Support command line and major IDEs like Android Studio, VS Code, IntelliJ, etc.
▪ Dart DevTool : debugging tool with runtime inspection etc.
▪ Widget Inspector: widget tree hierarchy visualization and exploration.
▪ Timeline View: app monitor at a frame-by-frame level - rendering and computational work can be identified
by this tool.
▪ Source-level Debugger: step through code, set breakpoints and investigate call stack, etc.
▪ Logging View: display events from Dart runtime, application frameworks and app.
▪ Internationalized libraries: localization
▪ Support unit test, automated testing, and continuous integration like Jenkins.
▪ No magic in Flutter tool family. Everything including 3rd-parties is open source.
▪ Built-in rendering engine provide better UI consistency and performance
▪ Decouple with native components to maximize code sharing
▪ Minimize the bridge between app code and native, greatly push the performance closer to native
Flutter Developer Support
23

24. ▪ Code size: significantly bigger output code size due to built-in widgets.
▪ Currently, the smallest app can weigh no less than 4MB for Android, and 10MB for iOS.
▪ To support a new target platform, Flutter need to develop a new set of built-in widgets
corresponding to that target platform
▪ Learning curve: new OOP language - Dart (vs. popular JavaScript)
▪ Flutter project though is open source, TSC is fully controlled by Google, rather than
community (same goes to React Native/Facebook & Xamarin/Microsoft).
▪ No support for 3D yet. Google is having explicit plans exposing 3D APIs.
▪ Surprisingly, Flutter could be difficult to build apps for old 32bit iOS devices like iPhone 5.
Flutter 劣势
24

25. ▪ 105k stars (the most & way more than others) at GitHub in Oct. 2020.
▪ Support the most target platforms, way more than others.
▪ Built-in rendering engine, Skia:
▪ The best display performance at 60fps, way better than other framework. (Sometimes even better than
native apps.)
▪ Support 120fps, while others cannot.
▪ AOT + JIT:
▪ Able to generate platform-specific/independent output with the best performance.
▪ No need of additional translation/bridge, like React Native’s JavaScript.
▪ Built-in widgets for UI:
▪ “True” single codebase with identical UI across target platforms, with pixel-level control.
▪ Comprehensive developer/community support: complete official toolchains, rich
documentations, etc.
▪ Flutter even has/supports dedicated Chinese community support.
Flutter 优势
25

26. ▪ Be “TRUE X-platform” dev framework, and support as many platforms as possible:
▪ Mobiles, Web & Desktops
▪ Mini-apps
▪ Be fully independent from target platforms, in order to achieve great/better performance:
▪ Build an optimal/great compiler engine (with AOT) for better app/speed performance.
▪ Does NOT matter whether choose brand new, or popular programming language.
▪ Great compiler engine can support wide range of target platforms.
▪ Have built-in UI components & rendering engine.
▪ Not only able to provide “true” single codebase and consistent UI.
▪ But also can have better UI/display-related performance.
▪ “MUST” have comprehensive developer experience journey (or just think about “Weex”):
▪ Complete and official toolchain support (like IDE, debugger etc.)
▪ Transparent open source ecosystem to attract developers/3rd-parties, including roadmap, etc.
▪ Active community support (like demos, forums, conference, rich documentations, etc.)
Flutter 借鉴思考
26
Score
Design
Philosophy
Good
Toolchain Good
Ease of use OK
Capability Good
X-Device Limited
Quality Good
3rdpty Support OK
Viability Good

27. Flutter Capabilities: 参考
27
Domain Category Factors Details Flutter
Infrastructure
Maturity
Viability License/open source 友好/BSD 3-clause (Yet, GitHub is fully controlled by Google.)
X-Plat/Device Supported target platforms Support the most target platforms: Android/iOS, Web, Windows/macOS/Linux.
Tool/L Development platforms OS, (language) 全平台 Pack + CLI + DevTools
Ease of Use/M Deploy channel support restriction, publishing, analytics 官方支持 (for Android/iOS)
Ease of Use/M Monetization support free, freemium, paid, in-app purchase, advert 官方支持 (for Google/Apple Pay)
3rd-Pty Support Internationalization localization 官方支持
Viability Long-term feasibility backing entity, cycle/update, maturity, stability, (community) 有优势：Google has been putting huge amount of resources on it, with prompt support.
3rd-Pty Support Community adoption, popularity-fork/star/commit, examples 105k stars, 14.6k forks, 3.2k watches (Oct. 2020) - other frameworks are doing the same way like Flutter.
Development
Support
Tool Language multiple front-end language support, syntax/style, AOT/JIT Need to learn new programming language – Dart
Tool Toolchain complier, (CI/CD) Optimal compiler with AOT, which makes Flutter able to support multiple target platforms easily and well.
Tool IDE
dependencies, hot reload, autocomplete, syntax check, built-in
debug/emulator, (CI/CD) Support all major IDEs including Android Studio, VS Code, IntelliJ, etc.
Tool UI design support hot reload, GUI, no-code/low-code 有优势：Built-in widget to support stateful hot reloading better, and exactly identical UI across platforms.
Ease of Use Testing code analysis, testing API, pressure, profiling, logging 官方支持
Ease of Use CI/CD build, source/package, pkg-sign, deploy, container 官方支持 with bigger code size because of built-in widgets
Ease of Use Ramp-up curve boilerplate, document, demo, (language/syntax), (community) 官方支持 with rich documentations and high-quality demos
Ease of Use Scalability design pattern, modularization 组件式设计 + 渐进式开发
Other/L Development process fit waterfall, extreme, agile 适应现代开发模式
Ease of Use Maintainability hotfix solution, app structure, LOC, readability, design pattern, in-app doc Have the advantages of OOP language like C++, which supports design pattern model etc.
3rd-Pty Support Extension plug-in, library, components, (native platform access) Rich 3rd-party support/community. Can access full native platform resources fully, without limitations.
X-Plat/Device Configuration/Product support style/theming/branding, (free/paid), (localization) 官方支持
App Functionality
Characteristic Philosophies main design target/pattern, characteristics, & optimal app/service type 一次开发多端运行；自帶 UI & 渲染；
Capability Device specific hw access Full access without limitations, via platform channels.
Capability Platform specific function Full access without limitations, via platform channels.
X-Plat/Device X-device programming X-platform/device resource access and computation 官方支持 (Limited support for Android/iOS)
Capability Input heterogeneity True single codebase across all platforms including desktops.
Capability Output heterogeneity Able to generate target platform’s native outputs/executables.
Capability App lifecycle mgmt multithreading/background service/live notification 官方支持
Capability System integration Cloud API/Backend 官方支持
Quality Security 官方支持
Quality Robustness Good reputation, thus more and more frameworks are building on top of, or learning from Flutter.
App Usage
X-Plat/Device Look and feel native appearance, x-plat UI consistency 自帶 UI & 渲染，使跨平台体验保證完全一致
Quality Performance
download/app-size, start-up, execution/speed, rendering, UI
responsiveness, power, resource-consumption The best performance in terms of speed/display, with bigger code size due to built-in widgets.
Other/L Patterns online/offline running 官方支持

28. X-Plat Mini-App Dev-Framework Landscape
28
▪ 目前在国内大概有7个较流行的小程序开发框架。
▪ 但其中只有Chameleon、Uni-app、Taro支持H5/小程序/本地原生应用。
▪ 根据具体实验，我们发现事实上只有Chameleon与uni-app这两个开发框架对小程序，特别是在
本地原生应用上完成度较高。
▪ 虽然Chameleon 与 mpv 都来自滴滴团队，但是由于mpv框架在多个项目实践中暴露的缺陷以及
他主要针对小程序，mpv已经很久没有更新，滴滴对Chameleon的支持度明显要比mpv要高。

29. Chameleon Overview
29
• Apache License 2.0
• MPV的扩大版
• 像变色龙一样能适应不同环境的跨端整体解决方案。
• MVVM 架构
• 多端统一（路由、项目、页面、组件、API、尺寸单位）
• CML + CMSS + JS，采用与 Vue 一致的组件化方案、单文件组织方式、生命周期，同时数据响应能力对齐 Vue，
数据管理能力对齐 Vuex，非常方便开发者上手、维护。

30. Architecture
30
Chameleon设计理念：定义统一的语
言框架 + 统一多态协议 (适配层）
• 定义了标准的前端语言CMSS样式语言
+CML页面结构描述语言
• 提供多态协议，其本质为adapter，为
上层应用定义一个统一的标准接口，各
端下层模块各自独立实现，编译时和运
行时对实现的接口输入输出做检查。
• 定义了统一的前端 Language(CML DSL)、Framework 与 Library（内置组件和 API）协议
层（多态协议）
• 在编译时将 DSL 转译成各端 DSL，只编译 Language 层面足够基础且稳定的代码
• 在各个端运行时分别实现了 Framework 统一，在各个端尽量使用原有框架，方便利用其生
态，这样很多组件可以直接用起来
• 在各个端运行时分别实现了该端的 Library（内置组件和 API）。
• 为用户提供多态协议，方便扩展以上几方面的内容，触达底层端特殊属性，同时提升可维
护性

31. ▪ 多态协议分为：
▪ 多态接口（接口适配）：适用于因为端的不同而进行不同接口的调用或者不同业务逻辑处理的场景
▪ 多态组件（组件适配）：产品在需求上导致某一个组件在各端的结构表现不同，适用于当某个功能组件需要调用各端
的原生组件，各端原生组件的属性不一致，或者一端有原生组件，其他端需要组合实现等
Critical Design：多态协议
31
Chameleon-related diagrams come fromhttps://github.com/didi/chameleon
Apache 2.0
▪ 前端
▪ 提供规范化的项目结构
▪ 利用多态提供了统一的
组件、API
▪ (使用模式)渐进式跨端
▪ 可以只是公用组件
使用CML
▪ 也可以整个项目都
使用CML
▪ 后端
▪ 接入不同端的具体实现
▪ 对于原生Android/iOS
应用，提供sdk(复用了
weex对Android/iOS
的sdk)

32. Chameleon Capabilities: 参考
32

33. ▪ Dcloud团队出品
▪ Apache License 2.0
▪ uni-app 是一个使用 Vue.js 开发跨平台应用的前端框架，提供了完整的 Vue.js 开发体验
▪ 支持多端：iOS、Android、Web（响应式）、以及各种小程序（微信/支付宝/百度/头条/QQ/钉
钉/淘宝）、快应用等多个平台
▪ 开发者容易上手，掌握vue即可
▪ 提供可视化IDE: HBuilder，提供发布、运行app功能
Uni-app Overview
33

34. Uni-app Architecture
34
▪ Uni内置组件丰富，有关教程、文档丰富
▪ Uni-app在App端内置了一个基于 weex 改进的原生渲染引
擎，提供了原生渲染能力。
▪ 如果使用vue页面，则使用webview渲染；
▪ 如果使用nvue页面(native vue的缩写)，则使用原生渲染。
▪ weex偏重于渲染，没有足够的API能力（比如各种push sdk
集成、蓝牙等能力调用），引入native.js将mobile native 原
生能力映射为JS对象，从而在JS环境中调用手机原生能力
▪ 采用条件编译来维护多端差异性

35. Uni-app Optimization
35
▪ Uni-app开发的小程序性能基本能保证与原生小程序性能差不多，
甚至还要高
▪ 性能优化1： 小程序：利用小程序已有的性能优化技术，如微信
的wxs技术（一种能直接运行在渲染层的脚本）
▪ 性能优化2：app/H5：采用类似wxs的技术RenderJS
▪ 性能优化3：利用Vue特性，自动合并差量数据，减少调用
setData次数
▪ 性能优化4：修改Vue
▪ compile：optimize 过程可取消，因为该环节是为了标注静态文本节点，
而 Vue 只负责数据，不需要关注 DOM 节点；
▪ render function：不生成 vnode；
▪ patch：不比对 vnode，因为 setData 仅能传递数据，所以我们只比对
data。
▪ 性能优化5：借鉴 westore JSON Diff 库，实现数据差量更新
▪ 性能优化6：组件差量更新，仅在当前组件内计算数据差量
优化技术
微信小程序 WXS/关键帧动画
支付宝小程序 SJS
百度小程序 Filter/Lottie
头条小程序 无
Source: https://vuejs.org/v2/guide/reactivity.html
MIT license

36. Uni-app Capabilities: 参考
36

37. Pros
▪ Chameleon 与uni-app都提供了跨多端的能力（小程序、mobile app、H5）， 为mobile 原生开发分别提供了sdk
▪ 7个小程序开发框架中，唯独Uni-app提供了可视化IDE，让开发者以非常简便可视的方式发布、运行app， 而且uni-app提供了开源的ui框架，以
便开发者自由切换APP风格
▪ DSL 为 类vue或是vue，对于前端开发人员友好
▪ Chameleon设计理念核心思想就是一个标准响应式数据驱动视图更新的 MVVM 框架，理论上任意使用MVVM架构设计的终端，都能以
Chameleon开发并运行
▪ Chameleon独创多态协议标准，充分隔离各端差异化实现，多端统一
▪ Uni-app充分利用了小程序已有的性能优化技术与vue中的性能优化
Cons
▪ Chameleon 使用了他自己的DSL ： CML，虽然号称简答易学，但最后还是做了妥协，为开发者提供了类Vue语法
▪ 跨平台小程序开发框架成熟度普遍不高，小程序开发框架最支持微信小程序的编译运行，但在其他如头条、百度中可能编译无法通过，bug较多，
需要开发者逐个去解决，另外真机调试会出现IDE中没有的bug
▪ 对于native app的支持，Chameleon提供的sdk本质上利用的是weex扩展到android/IOS的能力，因此他对android/iOS资源的访问限制受限于
weex
Pros and Cons(Chameleon & Uni-app)
37

38. ▪ 总体指导思想：write once , run everywhere( h5,mobile app, mini-app)
▪ 吸引开发者 :
▪ 避免让开发者去重新学习一门新的语言（Chameleon最后做了妥协）
▪ 让开发者能利用可视化的IDE去编写、编译、运行、部署、签名（HBuilderX IDE是Uni-app的亮点之一，
其他小程序开发框架都没有提供可视化IDE）
▪ 为开发者提供足够多的教案与第三方组件，避免开发者走弯路
▪ 保证社区的活跃度，让开发者的问题能及时得到回应
▪ 框架设计理念：借鉴Chameleon的多态协议， 为开发者提供统一的接口，减少开发者对多端的
维护成本。弊端是对小程序及时更新要求较高。
▪ 性能优化： 借鉴Uni-app对各种性能技术的利用。
Reflection from X-Dev Mini-app Framework
38

39. One Sentence Summary
39
框架 精华 局限
Flutter
提供最好的效能，灵活的UI和完善工具支持，支持最多的平台
(Built-in Widget/Rendering, AOT/Optimal Compiler) Built-in vs. Size Overhead, Learning New Language
React/Native
开放的架构和丰富的社区
（Component Design & Layer Structure) Bridge/JSC Overhead
Weex
采用极简洁又灵活的前端技术，从而最小化门槛
（Vue? DSL? Multi-Frontend?) Web-first vs Native first
Chameleon
多态协议 ，从而实现MVVM跨端环境大统一
(统一接口/组件） 需要学习新语言，需及时更新API实现
UniApp
组件丰富，性能体验好，前端上手容易
（可视IDE/Vue?） 条件编译，需要开发者较多维护工作
Application Native-Platform
native
code
Widgets/
Rendering
Canvas/
Events
System Services
(Location, Sensor, Media)
Application Native-Platform
JScode
Widgets/
Rendering
Canvas/
Events
System Services
(Location, Sensor, Media)
Application Native-Platform
Dartcode
Widgets/
Rendering
Canvas/
Events
System Services
(Location, Sensor, Media)JSbridge
Platform
Channel
原生App应用 React/Weex应用 Flutter应用

40. X-Plat Dev-Framework Risk & Opportunity
40
▪ Risk
▪ Say NO to support X-platform?
▪ X-platform dev framework may not be able to provide an optimal experience to rival native framework
▪ React Native and Flutter has a lead time of 4~5 years, with good performance and community support.
▪ InstantApp/AppClip in western market are different from Mini-App in eastern market
▪ Opportunity
▪ Mini-App ecosystem is more mature in China, posing opportunity to lead western market
▪ Enablement of x-platform computing is not considered in any of current framework – could be a competitive
differentiator
▪ Integrated security model is missing from any of current framework – could be another competitive
differentiator
▪ Enable Flutter (and/or React Native) to support NewOS to help apps migrate
▪ Onboard quality 3rd-party partners to enrich official platform offerings

41. An Ideal X-Plat Dev-Framework Design for NewOS
41
系统管理
是否熟悉？
是否容易上手？
是否简单易用？
是否开发高效？
是否工具丰富？
是否组件丰富？
框架层
原生层
自有DSL语言
（Dart vs ???）
高效JS语言
（Vue/JS+TypeScript）
前端层
是否和原生体验一致？
是否跨平台体验一致？
是否高性能媲美原生？
组件/模块/适配器
Runtime管理
（Optional）
渲染处理（布局，
数据/事件，视图）
原生接口
自有渲染引擎
（e.g.Skia）
VirtualDOM适配
原生渲染引擎
原生适配
Write Once， Run Everywhere
Fast Development & Fast Performance
是否UI性能有保证？
是否UI灵活有保证？
是否容易对接原生功能？
是否扩展能力丰富？
1
2
3
4

42. Design Discussions
42
▪ To-be or Not-to-be: does x-plat dev-framework bring sufficient value? (Yes!)
▪ Advantages: code reusability; UI consistency; cloud integration; time2market; maintenance cost;
▪ Challenges: limited tool/feature; consumer experience (e.g. Back control); Performance
▪ Answer: 双生态的现实 + 新生态的需要 => 跨平台开发框架可以更好吸引开发者
▪ Choice of front-end Language: Web-first and/or Native-first approach
▪ Web-first helpful to attract front-end developer and usually smoother learning curve
▪ Answer: 采用Vue降低门槛 + 高功效的定制语言 => 多前端支持
https://insights.stackoverflow.com/survey/2019#technology-_-most-loved-dreaded-and-wanted-other-frameworks-libraries-and-tools

43. Design Discussions
43
▪ Built-in Runtime (AOT + JIT) or not
▪ Runtime is key to support hot-reload feature, though potential size impact
▪ Answer: Runtime解释 + 原生机编译的混合模式，旁路JS桥的优化是关键
▪ Built-in Widget/Render or not
▪ Key to achieve UX consistency, yet size impact
▪ Answer: 双路方案，Built-in给原生应用，DOM层对接给即时应用
▪ 腾讯为微信小程序做过reverse尝试 - 前端用微信小程序组件，后端接到Flutter渲染引擎做渲染，但只是内部尝试，没有商用
▪ Mini-App support
▪ Mostly JS/web-view based, could translate at Component level or Virtual DOM level
▪ Answer: 在Virtual DOM层适配有利于前端代码一致性，代码大小和性能要进一步分析
▪ Native platform service access
▪ Need to provide 100% native access support
▪ Answer: 官方模块需要有足够原生能力支撑，避免应用需要耦合原生平台逻辑
▪ Missing pieces
▪ 安全支持和跨平台计算的使能是目前所有平台的欠缺，也是差异化机会

44. X-Plat Dev-Framework Implement Strategy Proposal
44
▪ Grow on top of Flutter??? (For performance and build-in widget/render)
▪ Front-end adopt Vue and/or React (For ease of use) => later add other language when mature
▪ Back-end enable dual mode: built-in rendering for native app, and DOM-level integration for
Web/Mini Program (For UI flexibility and code size optimization)
▪ AOT/JIT hybrid mode (get rid of JSBridge overhead) for high performance & flexibility
▪ Enable seamless X-platform UX & computing, with small footprint for IoT/device.
▪ Ray, an-source distributed computing platform, can potentially be investigated/leveraged. Yet Ray's
latest stable release is possibly too big for resource limited devices.
▪ Currently minimum memory requirement of Ray is 512MB. In addition, Python interpreter is needed with ~50KB
flash and ~8KB RAM depending on target platform and toolchain used.
▪ Customization effort will involve decoupling AI/cloud-related components, adding ad-hoc network support, as
well as distributed heterogeneous resource access (like camera/microphone) among heterogeneous device
group (mobile, IOT etc.)
▪ (Needless to say) UI & BLo decouple => MVC/MVP/MVVM
▪ (Needless to say) Toolchain & Community