Chameleon跨端框架——壹个理想主义团队的开源做品

文章较长，信息量很大，请耐心阅读，必然有收获。下面正文开始~

• 背景
• 解决方案
• 原理
• 久经考验
• 生产应用举例
• 易用性好
• 多态协议
• 学习成本低
• 渐进式接入
• 业内对比
• 后期规划
• 理想主义

历经近20个月打磨，滴滴跨端方案chameleon终于开源了github.com/didi/chamel…, 真正专一于一套代码运行多端。

背景

微信月活10亿月活（超过网民数量，用户多个帐号？）、支付宝4亿月活、百度3.3亿月活；2018 Q3中国Android手机占智能手机市场超过80%；不管BAT仍是Android快应用都是中国互联网用户的真正用户入口，做为小型互联网公司都但愿能搭上小程序的风口，从而蹭一波流量。

计算机技术历史发展告诉咱们，每一种新技术出现都会经历"各自为政"的阶段，小程序技术也不例外。微信小程序做为独创者，虽然其余小程序都在技术实现原理、接口设计刻意模仿，可是做为一线开发者面对一样的应用实现每每须要重复开发、测试，从前1单位的工做量变成了N单位的工做量。

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

各种小程序已经能覆盖中国全部网民，从Facebook在2013年开源react，这个项目自己越滚越大。从最先的WebUI引擎衍生的ReactNative项目，目标更是宏伟。

Vue.js于2014年左右发布，逆流而上占据了大量用户群体，2016年阿里巴巴也基于vue发布了weex项目，能够用vue编写NativeAPP。

Google在2018年底正式发布了面向将来的跨Andoid、IOS端Flutter1.0.0，做为面向将来的跨端框架，前景一片光明。

解决方案

虽然不一样各端框架环境变幻无穷，不管各种小程序、Weex、React-Native、Flutter、快应用，它们万变不离其宗的是MVVM架构设计思想。Chameleon但愿既能用一套代码完成全部端需求，将相同的业务逻辑完成收敛到同一层系统里面，又不会由于项目的抽象一致致使可维护性变差。

让MVVM跨端环境大统一：以各个跨端技术(Weex、React-Native、WebView浏览器、Flutter)和产品业务(微信小程序、快应用、支付宝小程序、百度智能小程序、今日头条小程序、其余各种小程序)的共同技术特色——MVVM架构设计， 以统一MVVM跨端架构平台为目标的程序语言框架Chameleon(任意使用MVVM架构设计的终端，都能以Chameleon开发并运行)。

View:

ChameleonSDK包括各种小程序、web端、客户端(React-Native、Weex、Flutter)，目前支持微信小程序、Web、Weex三类，后续支持更多MVVM为标准的端。

View Model:

CML(Chameleon MarkupLanguage)是框架设计的一套标签语言，结合基础组件、事件系统、数据绑定，能够构建出页面的结构。同时为了下降学习成本支持类VueTemplate。

原理

久经考验

2017年时微信小程序发布，滴滴做为白名单用户首先开始尝试接入。这时候咱们专门成立了一个一、2人的小项目组，完成一个名为MPV的项目，一期目标是“不影响用户发挥，不依赖框架方的原则性实现一套代码运行web和微信小程序”。MPV研发完成后，在多个项目实践中，确实完成了超过90%代码重用，整体上开发效率和测试效率都有了明显提高，同时暴露出更多问题：

• 可维护性问题，没有隔离公用代码和各端差别代码。
• 方向选择错误，MPV使用了小程序语法标准(小程序的生命周期、API接口等)，致使用户使用上没法清晰理解使用规范。
• 各端周边小型差别点太多。
• 模板DSL语法不规范。
• 两端界面效果不一致。
• 多端调试成本高。
• 工程化建设落后。
• 不能直接使用各端已有生态组件，即缺少标准规范接入某个端已有开源组件。

2018年4月咱们把跨端项目规模进一步扩大，跨N端的解决方案命名为Chameleon/kmiln/，简写CML，中文名卡梅龙;中文意思变色龙，意味着就像变 色龙同样能适应不一样环境的跨端总体解决方案。

Chameleon在MPV的实践积累下，不只解决了遇到的各类可维护性问题，后续的规划更加明确，目标真正专一于让一套代码运行多端，提供标准的MVV M模式统一各种终端。

通过一年数十位前端开发人员在上百页面中的实践经验积累，在本周正式开源:github.com/didi/chamel…。。

生产应用举例

易用性好

一套代码运行多端理念，被人挑战最多的如何保证易用性。

• 开发快，总体开发流程要高效。
• 简洁性，各端开发定制化空间大，且公用代码不会混杂某端代码。
• 性能好，不能增长产出文件包大小。
• 一致性，多端实现效果一致。

	开发快
关键词	工程化开发	项目级统一	组件级统一
描述	收集最优秀的工程化功能: 多种数据Mock、资源定位、代理调试、LivereLoad等， CML不用仅仅是跨端，更能帮助开发者高效开发单个端。	当多个端整个业务高度一致时，能用一套项目代码运行多端	已经用原生小程序开发代码，已经用vue开发的web页面，2者有重复开发组件如登陆 导出成小程序原生代码/vue组件，放在各个项目里面使用 安装webpack插件，在普通项目中直接安装该Chameleon组件并使用

	简洁性（各端开发定制化空间大）	性能好	一致性
关键词	多态协议	产出资源包大小，只保留单端代码	语法检查	多端一致性还原
描述	多态协议可用于多级，用户自由切换，由上至下：方法级、组件级、页面级、应用级	编译阶段将会只保留要导出的部分代码，内置组件和API按需打包	为了保障各个端实现效果一致，不用挨个调试各端，保存时作语法检查，暴露潜在问题。	在编译、runtime层大量工做保障实现效果一致

多态协议

多端合并后各端差别化实如今所不免，一开始是差别化代码和业务逻辑混杂在一块儿。这就尴尬了，若是你以为以上不复杂，假设有四、5个端呢，业务逻辑掺杂跨端逻辑，产品逻辑别打断，可读性差，需求变动，牵一发动全身，每一个端都要测试，跨端代码效率变得拔苗助长。

下图各端差别化代码也和逻辑混合在一块儿

多态协议设计的灵感来自于Apache Thrift - 可伸缩的跨语言服务开发框架，本质上跨端也属于跨语言。 它能让Chameleon开发者快速接入各个客户端底层功能或者差别化业务实现，避免可读性差、可维护性差的问题。

多态协议经过定义标准接口(interface)，各端模块各自独立实现，编译时和运行时对实现的接口输入输出作检查。

主要2个目标:

• 保障多端可维护性
• 编译时拆分多端代码

当用户按照标准规范扩展个别产品效果多端不一致或特定底层能力多端不一致的的功能时，多态协议能够有效隔离公用代码和各端差别代码，保证”河水不犯井水“。

举例:当你像开发一个图表功能组件时，可能用到 echarts :

1. 在项目中分别按照web版本 npm install echarts 和微信版本下载相关文件
2. 而后定义一个多态组件 charts
3. 在 charts/charts.interface 定义该组件的输入和输出
4. 分别在 charts/charts.wx.cml 和 charts/charts.web.cml 里面调用微信版本(可以使用微信小程序组件文件夹)和web版本(可调用.vue后缀文件)
5. 最后就能在项目中使用该组件

产出包里面只包含该组件其中一端的代码;因输入输出的限制，该组件调用上彻底一致，不用根据某端作特殊逻辑处理。你能够将该echart多态组件单独放置在一个仓库里面单独维护并发布;其余人无需关系内部细节，直接npm install echart便可使用。

学习成本低

VM层的CML语法是关联视图层和逻辑层的抽象DSL，其有学习成本问题是被热心不少帮助咱们的同窗提的最多建议，自己其CML学习成本已经很是低，无非是数据双向绑定、事件绑定、组件树、条件语句、循环遍历等等。一开始咱们是拒绝的，后来综合考虑之下，仍是妥协支持了类vue语法，让开发者更快上手CML。

渐进式接入

不少人已经开发小程序了，又不肯意大多阔斧从新改造，也但愿使用CML?固然能够，2种方式使用CML:

说明/类型	整个项目使用CML	公用组件使用CML
关系图
说明	业务层需求在各端环境高度相似, 本来须要针对不一样端重复开发、重复测试， 那么使用Chameleon将整个项目”从上至下“都用一套代码运行。	本来公用组件须要重复开发、重复测试， 使用一套代码开发公用组件， 各个端能够直接使用公用组件
举例	首页、详情页、订单	分享组件、支付组件、地图组件、picker组件

业内对比

业内其余框架和咱们的目标不同，咱们是但愿真正一套代码运行多端，而其余框架无非是“某个小程序语法加强”或者“推广某个框架写小程序 ”，但倒是有重合点，列举一下功能对比:

后期规划

方向	子方向	执行项目
易用性增强	语法检查 速度 前端工程化	A、检查能力增强:潜在错误阻断在编辑时 B、编辑器插件语法检查:Sublime text、Visual Studio Code、Webstorm C、Chameleon playground:Debug工具增强 D、编辑器插件:代码提示 E、图形化界面建立和管理项目
框架优化	包大小 运行性能 web前端模块服务化	A、包大小:优化各包大小到70%(uglily后当前weex 136k wx 99.3k web 143k) B、多端界面一致性增强:组件建立Web Component化 C、统一内置能力增强:Canvas、地图、音频等 D、静态资源关系依赖:服务端按依赖自动加载资源包
端品类扩展	各种小程序 React-Native Flutter	A、支付宝小程序:能力支持(测试中) B、百度小程序:能力支持(测试中) C、快应用:能力支持 D、端扩展协议标准化:用户自由扩展新端
组件扩展	c-design 内置组件增强	A、c-design:“开箱即食”的组件库 c-design ，任意端用户直接安装可用 B、垂直类组件库:金融、电商类型组件库
端能力扩展	Native能力 内置组件增强	A、Native API:Chameleon Native SDK能力向小程序靠齐
流程优化	XEditor ChameleonShow	A、ChameleonShow:开源Chameleon后台管理平台，解决移动端页面碎片化问题 B、XEditor:让非研发直接发布任意终端的简单页面，无需重复开发
服务扩展	多端服务能力统一	A、统一云服务:统一后端服务接口能力，如分享、支付、消息推送

理想主义

1. 咱们忍受不了本身的时间浪费在重复劳动上。
2. 要么不作要作就到极致，一套代码运行多端原本就是理想主义，这条路很艰苦，咱们却偏执的坚信必定要尽最大努力作出来，做为一个不那么自信的人，不作到好用是不敢发布出来的。
3. CML框架各个细节都要作到极致，咱们不能容忍有设计上的缺陷，因此经常CML周会上团队成员讨论6个小时直到深夜。

快速开始：cmljs.org/doc/quick_s…

常见问题: cmljs.org/doc/framewo…

欢迎加入贡献代码: didi/chameleon