Chameleon 跨端框架——壹个理想主义团队的开源作品,旧版 android 模拟器
微信月活 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 希望既能用一套代码完成所有端需求,将相同的业务逻辑完成收敛到同一层系统里面,又不会因为项目的抽象一致导致可维护性变差。![image.png](https://upload-images.jianshu.io/upload_images/15233854-c3cfbce8a2cb1f10.png?imageMogr2/auto-ori
ent/strip%7CimageView2/2/w/1240)
让 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 年时微信小程序发布,滴滴作为白名单用户首先开始尝试接入。这时候我们专门成立了一个 1、2 人的小项目组,完成一个名为 MPV 的项目,一期目标是“不影响用户发挥,不依赖框架方的原则性实现一套代码运行 web 和微信小程序”。MPV 研发完成后,在多个项目实践中,确实完成了超过 90%代码重用,总体上开发效率和测试效率都有了明显提升,同时暴露出更多问题,在 MPV 的实践积累下,有了一定的底气和把握,后续的规划更加明确。
可维护性问题,没有隔离公用代码和各端差异代码。
方向选择错误,MPV 使用了小程序语法标准(小程序的生命周期、API 接口等),导致用户使用上无法清晰理解使用规范。
各端周边小型差异点太多。
模板 DSL 语法不规范。
两端界面效果不一致。
多端调试成本高。
工程化建设落后。
不能直接使用各端已有生态组件,即缺乏标准规范接入某个端已有开源组件。
2018 年 4 月我们把跨端项目规模进一步扩大,跨 N 端的解决方案命名为 Chameleon/kmiln/,简写 CML,中文名卡梅龙;中文意思变色龙,意味着就像变 色龙一样能适应不同环境的跨端整体解决方案。
Chameleon 在 MPV 的实践积累下,不仅解决了遇到的各种可维护性问题,后续的规划更加明确,目标真正专注于让一套代码运行多端,提供标准的 MVV M 模式统一各类终端。
经过一年数十位前端开发人员在上百页面中的实践经验积累,在本周正式开源:https://github.com/didi/chameleon。
生产应用举例
易用性好
一套代码运行多端理念,被人挑战最多的如何保证易用性。
开发快,整体开发流程要高效。
简洁性,各端开发定制化空间大,且公用代码不会混杂某端代码。
性能好,不能增加产出文件包大小。
一致性,多端实现效果一致。
多态协议
多端合并后各端差异化实现在所难免,一开始是差异化代码和业务逻辑混杂在一起。这就尴尬了,如果你觉得以上不复杂,假设有 4、5 个端呢,业务逻辑掺杂跨端逻辑,产品逻辑别打断,可读性差,需求变更,牵一发动全身,每个端都要测试,跨端代码效率变得适得其反。
下图各端差异化代码也和逻辑混合在一起
多态协议设计的灵感来自于 Apache Thrift - 可伸缩的跨语言服务开发框架,本质上跨端也属于跨语言。它能让 Chameleon 开发者快速接入各个客户端底层功能或者差异化业务实现,避免可读性差、可维护性差的问题。
多态协议通过定义标准接口(interface),各端模块各自独立实现,编译时和运行时对实现的接口输入输出做检查。
主要 2 个目标:
保障多端可维护性
编译时拆分多端代码
当用户按照标准规范扩展个别产品效果多端不一致或特定底层能力多端不一致的的功能时,多态协议可以有效隔离公用代码和各端差异代码,保证”河水不犯井水“。
评论