开源中国专访：Chameleon原理首发，其它跨多端统一框架都是假的？

摘要：中国互联网络信息中心发布的中国互联网络发展状况统计报告显示，截至年月，我国网民规模达亿人，微信月活亿支付宝月活亿百度月活亿另一方面，中国手机占智能手机整体的比例超过，月活约亿。在年末正式发布了面向未来的跨端的。

原创： 嘉宾-张楠

开源中国

以往我们说某一功能跨多端，往往是指在诸如 PC、移动等不同类型的设备之间都能实现；或者更加具体一点，指的是“跨平台”，可能是大到跨操作系统，比如 Windows、macOS、Linux、iOS 与 Android 等，可能是小到跨某个具体技术的不同实现库。

但是今天我们要介绍的是关于跨 MVVM 架构模式各种环境的场景。

Chameleon 是一套开源跨端解决方案，它的目标是让 MVVM 跨端环境大一统，实现任意使用 MVVM 架构设计的终端，都能使用其进行开发并运行。

在这样一个 MVVM 环境中，涉及到了 Weex、React-Native、WebView/浏览器与 Flutter 等各种跨端技术，还有它们实现的具体业务产品，比如微信小程序、快应用、支付宝小程序、百度智能小程序、今日头条小程序与其它各类小程序。

也许你发现了，这里提到了许多种“小程序”，虽然最早微信小程序的概念甚至早期版本出现的时候，有过不少不看好的声音，但是随着它不断发展，目前已经成为了大众生活不可或缺的应用形态。

马化腾透露过，截至 2018 年 11 月有 150 万微信小程序开发者，小程序应用数量超过 100 万，覆盖 200 多个细分行业，日活用户达到 2 亿。这样的成功经验与几乎触及到生活方方面面的巨大流量入口，大家都想入场，于是可以看到后来其它公司纷纷给出了类似的小程序方案。

另一方面，除了小程序百花齐放，2018 年小米、华为、OPPO 等 10 家安卓手机厂商还结成了快应用联盟，并且先后发布了一系列快应用。

Chameleon 目标就是要跨这些端，而随着各家不同实现越来越多，跨端场景也不断变得更加复杂。我们采访了 Chameleon 创始人张楠，请他为读者具体分享了 Chameleon 在这个过程中的成长。

项目地址：https://github.com/didi/chame...

本文是 Chameleon 首次对外公开实现原理！

干货超多，包括：

终端开发未来的开发模式

Chameleon 跨端实现原理

当前各种跨端方案原理对比（各种小程序、快应用等）

与 Taro 的对比

演进过程中遇到的困难与思考

关于这个问题可以从行业背景讲起。

中国互联网络信息中心（CNNIC）发布的《中国互联网络发展状况统计报告》显示，截至 2018 年 6 月，我国网民规模达 8.02 亿人，微信月活 10 亿 、支付宝月活 4 亿、百度月活 3.3 亿；另一方面，2018 Q3 中国 Android 手机占智能手机整体的比例超过 80%，月活约 6 亿。

BAT 与 Android 成为了中国互联网真正的用户入口。但凡流量高的入口级别 APP 都希望做平台，成为一个生态平台和互联网流量入口，大量第三方应用的接入，从业务层让公司 APP 关联上更多企业的利益，并且拥有更强的生命力；从技术层面可以利用“本地能力接口层”收集大量用户数据，从消费互联网到产业互联网需要大量各行各业基础用户数据线索进行驱动和决策。

在这么一种背景下，再结合计算机技术的发展历史，我们知道每一种新技术的出现都会经历“各自为政”的阶段，小程序技术也不例外，所以我们看到了其它各种小程序平台出现。

微信小程序作为首创者，虽然其它小程序都有在技术实现原理、接口设计上刻意模仿，但是作为一线开发者在不同平台发布小程序，往往还是需要重复开发、测试，从前 1 单位的工作量变成了 N 单位的工作量。而这还没算上快应用等其它入口。

这种情况下，滴滴的研发工程师是其中最显著的“受害者”之一，滴滴出行在微信钱包、支付宝、Android 快应用都有相关入口，而且用户流量占比不低。

研发同学在端内既追求 H5 的灵活性，也要追求性能趋近于原生。面对入口扩张，主端、独立端、微信小程序、支付宝小程序、百度小程序、安卓厂商联盟快应用，单一功能在各平台都要重复实现，开发和维护成本成倍增加。

迫切需要一个只维护一套代码就可以构建多入口的解决方案，于是我们着手去打造了 Chameleon（CML，卡梅龙）这么一个项目，真正专注于让一套代码运行多端。

MVVM 也就是 Model View ViewModel，它本质上是 MVC（ Model View Controller）的进化版本，将 View 的状态和行为抽象化，使得视图 UI 和业务逻辑分开。

它是一种让数据驱动反射视图的模式，发展到现在可能会偏离它的初衷了，更像是一个视图数据间的“通信协议”，让终端开发变得更加单纯，这是一种趋势，面向未来框架都采用这种模式。

Facebook 在 2013 年开源 React，React 这个项目本身是一个 Web UI 引擎，随着不断发展，它衍生出 React Native 项目，用来编写原生移动应用。正是它给跨端方向带来了 MVVM 模式。

Vue.js 于 2014 年左右发布，逆流而上占据了大量用户群体，2016 阿里巴巴也基于它发布了 Weex 项目，使得可以用 Vue 编写 Native App。

Google 在 2018 年末正式发布了面向未来的跨 Android、iOS 端的 Flutter 1.0.0。

我们知道终端开发离不开三大要素——界面表现（结构、外观）层、逻辑处理层与系统接口层（网络、存储与媒体等）。

开发者编写代码时在初始化阶段（生命周期）调用“界面表现层”界面模型的接口绘制界面，当用户触摸界面时，“界面表现层”将事件发送给用户“逻辑处理层”，后者经过条件判断再处理并反馈到用户界面，处理过程可能需要调用“系统接口层”，反馈过程需要调用“界面表现层”的接口。

常规的终端开发架构模式下，无论是 Web 端、Android 端还是 iOS 端的项目开发，都强依赖各端的环境接口，特别是依赖界面相关模型设计。

iOS 系统下绘制界面基于 Objective-C 语言环境下的 UIKit 框架；Android 系统下用户绘制界面基于 Java 语言环境，由 LayoutInflater 处理 XML 结构层次树；Web 端使用 DOM 模型和 CSS 来描述绘制界面。  

MVVM 中的关键是它通过 ViewModel 这一层将界面和逻辑层彻底隔离开来，负责关联界面表现和逻辑处理层的响应事件（update/notify）关系，这一“隔离层”上下通信足够规范、足够纯净单一。  

Model 进行逻辑处理是纯业务响应逻辑，任何一种语言都可以实现，你可以用 Android 的 Java，也可以用 iOS 的 Objective-C，你心情好用“世界第一语言 PHP”也能实现。

之所以普遍选择 JavaScript，很大程度是因为在这个领域内它的优点显著，如学习成本低、天生具备跨端属性、虚拟机（V8、JavaScriptCore）和各方向组件建设较好、生态活跃。

而系统接口层则更简单了，只需穷举统一基础接口+可扩展接口能力即可。

具体来看看各种 MVVM 方案都是怎么样的。

React Native、Weex 与快应用的 MVVM

开发者编写的代码在虚拟机（V8、JavaScriptCore）里面运行，虚拟机容器里面包含扩展的系统基础接口。运行时，将描述界面的数据（主要是 CSS+DSL 所描述内容）通过通信层传递给 Android、iOS 端的渲染引擎，用户触摸界面时，通过通信层传递给虚拟机里面的业务处理代码，业务处理代码可能调用网络、储存与媒体等接口，最后再次反馈到界面。

Flutter 的 MVVM

Flutter 和 RN 的最大区别在于将“JavascriptCore/V8+JS”替换成“C++ 实现的 engine+Dart 实现的 Framework+静态类型 Dart+编译成机器码”。

Flutter 的方案如下图所示：

Service 其实就是本地能力接口层，Widget 树是视图层模型。

Flutter 和 RN 的使用面设计上类似，Flutter 文档中提到“In Flutter, almost everything is a widget.”，widget 的调用从 RN 的 JSX 变成 Flutter 的 widget 调用，UI 的外观描述从 RN 的 CSS（文本样式、布局模型、盒模型）到定制化 Flutter Widget（textStyle 、Layout Widget、Widget）。

本质上 Flutter 也是 MVVM 架构，逻辑层通过 setState 通知视图层更新，一定程度上这也是为什么 Flutter 敢说能转成 Web 框架的原因，核心还是基于这类数据驱动视图架构模式，业务代码不会深度依赖任何一端特有的“视图模型”。

各类小程序的 MVVM

小程序本质上和 Weex、React Native 的设计思路基本一样，最大区别在于前者还是用浏览器 WebView 做渲染引擎，而后者是多带带实现了渲染引擎（所以大量的 CSS 布局模型不支持）。

首先任何一份应用层的高级语言代码块分成几层：语言层（Language）、框架层（Framewrok）与库层（Library）：

Language —— 通俗来说，实现程序所需的基本逻辑命令：逻辑判断(if)、循环(for)与函数调用（foo())等。

Framewrok —— 通俗来说，完成一个 App 应用交互任务所需规范，例如生命周期（onLoad、onShow）、模块化与数据管理等。

Library —— 可以理解就是“方法封装集合”。比如 Web 前端中 Vue 更适合叫框架，而 jQuery 更适合叫库；Android 系统下 activity manager + window Manager  View System 等的集合叫框架，而 SQLite 、libc 更适合叫库。

对应到 Chameleon 就是这样：

具体到实现原理全景架构图如下：

你可以理解 Chameleon 为了实现“让 MVVM 跨端环境大统一”的目标做了以下工作：

定义了标准的 Language(CML DSL)、Framework 与 Library（内置组件和 API）协议层。

在线下编译时将 DSL 转译成各端 DSL，只编译 Language 层面足够基础且稳定的代码。

在各个端运行时分别实现了 Framework 统一，在各个端尽量使用原有框架，方便利用其生态，这样很多组件可以直接用起来。

在各个端运行时分别实现了 Library（内置组件和 API）。

为用户提供多态协议，方便扩展以上几方面的内容，触达底层端特殊属性，同时提升可维护性。

实现思路很简单，所有设计为了 MVVM 标准化，不做多余设计，所以宏观的角度就像 Node.js（libuv）同时运行在 Windows 和 macOS 系统，都提供了一个跨平台抽象层。

从 MVVM 角度来看的话：

View（展现层）

第三方 Render Engine：各类框架已有框架，浏览器的 Vue、Webview 里的小程序引擎、Android、iOS 里面的 React Native/Weex 引擎、甚至 Flutter 里面的 Dart Framework。

Chameleon 内置组件库：多态协议定义统一组件 view、input、text、block 与 cell 等，它是界面组层的原始基类，衍生出多复杂界面功能。

ViewModel（关联层）Chameleon 语法转译

组件调用

循环

条件判断

事件回调关联

父子关系

……

Model（逻辑响应层）

JavaScript 代码

CML Runtime 框架

Chameleon API：多态协议定义统一接口，cml.request、cml.store 等

一句话：基于 Chameleon 开发，效率会越来越高。

各个端的涌现，让原本是 1 的工作量因为多端存在而变成 N 倍，使用 Chameleon，工作量会变回 1.2。这多出来的 0.2 工作量是要处理各端的差异化功能，比如以下场景：

某业务线迁入 Chameleon 时，发现没有“passport登录组件”，在各类小程序里面能免密登录了，在 Web、Native 端是弹出登录框登录，不同业务用户交互形态不一样所以 Chameleon 没有提供组件；开发者需要基于多态协议扩展多带带一个登录组件，无论如何最后返回一个登录后的回调 token 即可，外部无需组件关心里面如何操作。

用户需要分享功能，发现没有“share组件”，在微信 Web 端可以引导右上角分享，在小程序直接分享，不同业务用户交互形态不一样，用户需要基于多态协议扩展多带带一个登录组件。

这种各端差异较大的例子，随着业务的积累，可以变成了一个个业务组件多带带维护，后面也不需要重复开发了，且反推产品体验一致化，组件三层结构“CML框架内置组件->CML扩展组件->业务开发者自己扩展的多态组件”达成 100% 统一。

随着组件积累业务开发工作量越来少，工程师可以专注做更加有意义的事情，这就是 Chameleon 存在的目的。

基于统一的跨端抽象，用户在 Chameleon 项目持续维护过程中，Chameleon 发布新增一个端之后，你的业务代码基本不用改动即可无缝发布成新端。

比如这个 cml-yanxuan 项目开发时支持 3 个端，后面新增了百度、支付宝小程序端，原有代码直接能跑起来运行 5 个端，一端所见即多端所见。

开发时只能跑 3 个端

原有代码无缝支持 5 个端

另外特别强调的是，对于大公司团队，如果有很强的技术能力，希望开发的代码掌控在自己手里，对输出结果有更好控制能力。其实 Chameleon 内置组件和内置 API 是可以替换的，那么所有组件都是业务方自己开发了，哪天不想用了直接导出原生组件即可离开 Chameleon，如下图：

我们觉得 Chameleon 与其它解决方案的最大区别在于其它框架都是小程序增强，即用 Vue 或者 React 写小程序，这些框架官方给的已接入例子也都是跑微信小程序。

它们更加类似 Chameleon 的前身 MPV（Mini Program View），即考虑如何增强小程序开发。2017 年微信小程序发布时，滴滴作为白名单用户首先开始尝试接入，开始面对重复开发的难题。

这时候我们专门成立了一个小项目组，完成一个名为 MPV 的项目，一期目标是“不影响用户发挥，不依赖框架方的原则性实现一套代码运行 Web 和微信小程序”。

看着很美好，用这样的方案实现 Web 端和小程序端，也确实完成了超过 90% 代码重用，总体上开发效率和测试效率都有了一定提升，但是却不是真正意义上的跨多端统一。

多带带说到 Chameleon 与 Taro 的区别，总体上看，可以归为这样一个表：

表中每一项都是在做跨端方案时需要考虑到的。我们说除了 Chameleon，其它方案都只是在对小程序进行增强，或者说是模仿微信小程序的 API 和组件的接口设计。

Taro 是通过将 JSX 转成小程序模板，在其它端模拟微信小程序的接口和组件，让其它端更像微信小程序，业务开发时不一致的地方需要环境变量判断差异分别调用，会造成端差异逻辑和产品逻辑混合在一起。

此外，它要跟随小程序更新，业务方会有双重依赖；其它端的和小程序不能保持一致，用户要各种差异化兼容，不利于维护。

那 Chameleon 呢？Chameleon 把这些问题都考虑到了，所以在早期伪跨端 MiniProgram View 成型之后不断演进的过程中，把它发展成为一个真正的跨多端方案。

前边的表格显示了，Chameleon 既考虑统一性，又考虑差异性，且差异性不会影响可维护性；当各端差异确实太大，那就不要用一套代码实现多个端同一页面，而是统一公用组件。

这还只是拿 Chameleon 与 Taro 的重合点进行了对比，但是别忘了 Chameleon 不仅仅是前端框架，它：

还有统一的 Chameleon Native  SDK，Chameleon 不仅仅希望统一各类小程序，还要覆盖自家 APP，会持续通过 Native SDK 扩展 API 和组件，期望有与小程序一样的本地能力。理想情况下，一套代码就能在各类小程序、自家 APP 里面无缝平滑运行。

还有待开源的后台管理系统。

还有待开源的 XEdtior 非研发用编辑器，可以直接编辑跨端页面、直接发布。

另外，未来还将带来以下能力：

后端统一接口（消息推送、分享与支付等）

基于统一的 MVVM 标准，更有基于 Flutter 的原生 APP

当前的各类小程序和 Native 跨端框架，类似当年多个浏览器时，Safari、Chrome、Firefox、IE 6/7/8/9、Android 浏览器等盛行的时代。以这个来类比，那么 Chameleon 的接口组件设计上更像一个 jQuery。

网络请求有的是 XHRHttprequest 有的是 ActiveXObject，jQuery 考虑的是用户需要什么，需要一个网路请求接口，支持 get、post 等，所以 jQuery 写一个既非 ActiveXObject 又非 XHRHttprequest 的名为 $.ajax 接口，提供一个封装网络接口，你不用关心内部在不同端怎么调用的，jQuery 内部会帮你兼容。

Chameleon 也是一样的思路，所有的接口设计都是真正能兼容跨所有的端，没有差异性，而且只保留当前所在端的接口调用代码：IE 里面只保留 ActiveXObject，Chrome 只保留 XHRHttprequest。

Chameleon 的接口设计上比 jQuery 更强的地方在于，使用标准的多态协议，保障可维护性，性能上只保留当前端代码，且将多态协议暴露出来，让用户也能扩展自己想要的 API（类比 $.xxx）。

当然时代已经变了，监听视图不在是 $("#xxx").click(fn)，而是 MVVM 数据驱动视图方式了，所以提供了 Chameleon 双向绑定这样的 VM 层。

前面讲到，2017 年的时候，我们完成一个名为 MPV 的项目，一期目标是不影响用户发挥，不依赖框架方的原则性实现一套代码运行 Web 和微信小程序。

当时缺乏小程序资料是遇到的最大问题（就更别提今天讲到的业内这么多解决方案了），当时唯一一个可以参考的开源项目是 WEPT，WEPT 是一个微信小程序实时开发环境，它的目标是为小程序开发提供高效、稳定、友好、无限制的运行环境。它的设计思路是在 Web 端模仿小程序环境执行。

于是我们在开发 MPV 时考虑了两种实现策略：

1、在 Web 端像 WEPT 一样 mock 小程序环境；就像微信开发者工具里面也模拟了小程序执行环境，WAServie、WAWebview 提供的两套环境源码做底层，在页面中开启三个独立运行环境运行并用 iframe 通讯模拟微信小程序的 3 个 Webview 之间的联通关系。

2、逐个转译代码支持小程序，缺点是可能会有 edge case 需要处理以及潜在的 bug 会比较多。

最终在看完 WEPT 源码和微信开发者工具的情况下，我们明确放弃了第 1 条实现策略，选择了逐个转译代码支持小程序的路线，主要原因是于 Web 端兼容微信所有的功能，尺寸过于庞大。

经过三个月紧锣密鼓的开发终于实现了第一版本 MPV：  

经过实现几个 demo 之后，开始执行迁移计划：

MPV 在 Webapp 上实践最终实现效果如下：

最终实现效果挺美好，也确实完成了超过 90% 的代码重用，总体上开发效率和测试效率都有了明显提升。

但是在后续实践过程中，发现存在大量的问题，并且项目越大问题越凸显出来，总结如下：

可维护性问题，没有隔离公用代码和各端差异代码。项目中不止有业务逻辑，还混杂着 Web 端和小程序端产品功能差异化逻辑。比如前边举过的例子，分享功能 Web 端无法实现（引导分享），小程序可以实现，意味着各种环境判断各种差异化逻辑，牵一发动全身，还要来回测试。

方向选择错误，MPV 使用了小程序语法标准（小程序的生命周期、API 接口等），导致用户使用上无法清晰理解。

不能直接使用各端已有生态组件，即缺乏标准规范接入某个端已有开源组件。比如 Web 端 pick.js 组件缺乏快速接入规范，用户要么重新开发，或者在模板和 js 代码中使用环境判断的方式针对引入。最终导致同一功能不同端的调用方式、输入与输出不一致。

业务项目依赖 MPV 框架。框架依赖微信小程序接口（模板、生命周期与接口），扩展了统一接口。例如微信小程序更新了 wx.request 时，业务项目方无法立刻使用，需要等框架更新。

文件夹结构混乱，混杂着多个端代码文件，且识别成本高。

不支持 vuex、redux 等高效数据管理方式

尺寸单位不统一，px 和 rpx 不一致

周边小型差异点太多：

协议不一致，例如 Web 端可以用 //:www.didiglobal.com/passenger/create ，小程序只能用 https://:www.didiglobal.com/passenger/create

打开一个新页面时链接不统一，例如打开发单页时，Web 端是 //:www.didiglobal.com/passenger/create，小程序是 /page/create

页面之间跳转时，传参不统一

debug 成本高，修改完代码之后两端需要测试

两端界面效果不一致，基础内置组件统一性建设不足

工程化建设落后，例如不支持 liveroload、数据 mock、资源定位、proxy、多端统一预览

接口设计不完整，生命周期、组件分层、本地 API 设计等

模板 DSL 语法不规范

在 MPV 的实践积累下，有了一定的底气和把握，后续的规划更加明确。2018 年 4 月我们把跨端项目规模进一步扩大，想要做一个真正跨 N 端的解决方案，目标是提供标准的 MVVM 架构开发模式统一各类终端。这就是 Chameleon 的出现契机。

Chameleon 真正想要一套代码运行多端，总结下来要解决几大问题：

要全面完成端开发的所有细节的统一性，特别是界面统一性有大量细节要做

要在完成上一条的前提下考虑差异化定制空间

持续可维护

目标理想业务形态是这样的：

图中上半部分是传统开发方式，下半部分 Chameleon 的模式抽象出了 UI 渲染层和本地接口能力层，业务代码一部分简单页面由 XEditor（h5Editor 的前身）编辑工具产出，另一部分工程师使用 Chameleon 开发，不止解决跨端问题，还弥补改进了工程开发过程中的效率、质量、性能与稳定性问题，让工程师专注有意义的业务，成长更快。

首个 Native 渲染引擎选择——小程序架构、RN/Weex 架构

从 MPV 到 Chameleon，外界看来最明显的变化是从跨 2 端（Web、小程序）升级到跨多端（Web、小程序、Android、iOS)，最开始纠结于首个端上版本的渲染引擎使用小程序架构还是 RN/Weex 架构。

RN/Weex 网上有大量资料可查，但是小程序方面则不然。千辛万苦搜索之后，根据一位知道内情的朋友的描述分享，才有了一定的了解。

这里分享几个印象深刻的要点：

小程序展现层使用 Webview，里面内置了一套 JS 框架用来和 Native 通信，真正业务代码执行在多带带 JS 虚拟机容器实例中

JS 虚拟机容器使用情况，iOS 系统是 JavaScriptCore，Android 系统使用 QQ 浏览器的 X5 内核

小程序的各个 TAG 组件使用的数据驱动用的是 Web Components

显而易见，部分性能要求较高的使用原生控件（视频、键盘等等）插入到 Webview 里面。

原生控件的具体位置 Native 怎么获取？答案是由嵌入到 Webview 的一套小程序框架通知给原生层

原生控件怎么保证在内部可滚动的元素（Scroll-view）里面正常滚动？答案是 CSS 设置 -webkit-over-scroll:touch 时，iOS 的实现是原生的 UIScrollView，Native 可以通过一些黑科技找到视图层级中的 UIScrollView，然后对原生控件进行插入和处理；而 Android 直接绘制没办法做到这点。现在（截至 4 月）仅仅是直接覆盖到 Webview 最外层的 scrollview 上，由内置到 Webview 的一套 JS 框架控制原生控件位置

最终多方面分析如下：

虽然小程序方案看起来很简单，但其实很多细节点需要大量打磨，从确认方案到真正可以跑起来可以线上发布，仅仅花费在终端上的研发人力为 20P*6 个月，微信小程序团队的目标和我们跨端目标不一样，他们投入这么多成本是值得的，我们为了跨端没必要投入这么高成本。

所以我们选择放弃小程序渲染方案，而使用已开源的 RN/Weex 方案。

第一个版本最终使用 Weex，包括团队同学去看了 Weex 源码实现。

在整体设计上仅仅使用 Weex 渲染功能，外层包装接口，保障后续能有更高扩展性。

Chameleon Native SDK

针对 Native SDK 我们主要从原生能力扩展、性能与稳定等三个方面做了工作。 

原生能力扩展：无论是 Webview 还是 React Native、Weex 甚至 Flutter 都只提供渲染能力（以及一些最基础本地接口），更多完成业务功能所需本地环境的能力（例如分享到微信）需要 Android 和 iOS 的 Native 往容器去扩展。本地能力包含 2 种，涉及 UI 界面的统一叫组件（UI 组件如登录、支付），涉及到纯能力调用的统一叫 API（网络、存储等）

性能：界面展现和交互耗时关键取决于 2 块，资源加载耗时（非打包到安装包部分代码）、执行耗时

稳定：主要关注灰度发布（风险可控）和线上止损，主要工作是按用户灰度发布、可以快速降级到 H5

以下是性能方向中的首屏加载时间的优化数据，原有 H5 使用 SSR（Server Side Render)已经算是最快的 Web 首屏技术方案了（不考虑优化后端多模块耗时的 BIGPIPE），它保持在 1.5 秒以下，在优化后降到 0.5 秒左右。  

性能优化中我们有一个关于执行速度的 TODO 计划。同样是跨端，Flutter 之所以比 Weex 和 RN 执行速度快，主要原因是前者是编译型，客户端机器运行前已经是 CPU 可识别的机器码；后者是解释型，到客户端运行前是字符串，边编译边执行，虽然做了 JIT 尽量优化，差距还是较大。其实在这中间还有一个抹平了不同 CPU 架构下机器码差异的中间码；当然前提是开发语言改成静态类型，这里不作展开。

原本分 5 次开发的 Web 端、支付宝小程序、快应用、微信小程序、Native 端变成了 1.2 次左右开发了。最重要的是随着业务级别各端差异化的多态组件和跨端组件积累，后续 1.2 工作量也会变成 0.8，0.4 的优化主要来自两个方面：

0.2 是普通跨端组件的积累，复用度变高

0.2 是各类业务级别的差异化多态组件，例如登录功能，在 Web端、Native 端和小程序端实现和交互是不一致的，这时候业务形态不一样，设计的 组件也不一样，只能各业务线去封装。

我们的最终目标是提供标准的 MVVM 架构开发模式统一各类终端。

接下来的具体 roadmap 如下表所示：

欢迎有共同愿景的同学加入我们一起共建，往仓库贡献自己的代码。

项目地址：https://github.com/didi/chame...

QQ 群：

公众号：

张楠，Chameleon 创始人，技术团队负责人，前百度资深工程师，终身学习者。