经滴滴开源处于上层的跨端解决方案，其简写方式为CML，正式对外发布了1.0版本，它拥有中文名，叫卡梅龙，其具有变色龙之意，所表达的是恰似变色龙那般能够适应不一样环境的企业级跨端整体解决方案特性，具备易用、轻量以及面向未来等基本特点，下文会针对该项目展开详细的研发背景和性能特点介绍。

世界上最快乐的事，莫过于为理想而奋斗。—— 苏格拉底

经历了长达 3 年的研发以及实践历程，经由数十名团队成员全力以赴地付出努力，借助数百名业界参与者共同进行的构建工作，历经数千次的改进与优化举措，最终得以迎来跨端解决方案 CML1.0 的正式版本。

前言

即 CML ，它是一款真正着重于使一套代码能够在多个终端运行的跨端框架，具备业内处于先进水平的工程化设计，拥有丰富的基础库，有着独创的多态协议，提供标准化 MVVM 架构开发模式来统一各类终端。

自打一经开源，CML 立刻备受业界的重点关注，在长期的时段以内一直占领着榜单，并且其开发理念以及框架设计还得到了广泛众多开发者的认同认可。

部分细节因未进行充分思考，所以开源时遭到质疑。针对此状况，我们深入调研业内存有的跨端框架。还积极接纳开源社区所提的建议。历经 6 个月的时间，进行了 180 次开发迭代之后。脚手架 tool 累计发布 70 多个日常版本，产生 5090 次代码修改。运行时框架累计发布 40 多个日常版本，有 900 次代码变动。问题的解决方面，达到 83%的解决比例，而单测覆盖率超过 85%。PR 次数达到 70 多次，CML 的稳定性以及功能实现了质的跨越式提升。所以，我们具备信心去推出那个新颖且稳定的 1.0 版本，而新增加出来的特性主要是涵盖了：

易用性加强

框架优化

端能力扩展

组件扩展

谈到被指责“通用性”致使“丰富性”受损：CML 被反馈频率最高的问题是小程序组件的丰富程度不足，尽管具备跨越所有端的组件以及 API 功能，然而并未封装特定的一些小程序特有的定制化能力，所以，我们很快会发布-ui-以及-api-，仅仅为各类小程序提供服务，全方位支持各类小程序组件与接口，与此同时用户能够依据多态协议的重载实力定制其他端（像是 web 和 weex）的功能达成，期望能够兼顾组件丰富度与统一性。

实际上，CML在滴滴好些业务产品里已历经实践验证，像青桔单车以及滴滴代驾、泊车、滴滴统一登录、收银台、司机端、企业级、国际化这些业务当中均有体现，越来越多的外部团队着手基于CML开启跨端项目建设。比如像百度视频小程序、百度首创新房通、滴滴青桔单车、芒果TV视频、老爸评测商城这类项目，多谢所有应用CML到beta版本的开发者给予的信任。

全新：首个 MVVM+ 跨端标准协议

CML 凭借对跨端工作所进行的积累，规范出了一套跨端标准，将其称作 MVVM+ 协议。

依托 MVVM+ 跨端标准协议，你能够随意去扩展全新的端，迅速地支持任何 MVVM 架构模式的终端，像淘宝小程序，是 React 这般，详细的参考内容为:https://cmljs.org/doc//.html标点符号。

以 CML 为基础进行项目开发，能够使现已存在的项目毫无阻碍地在新的终端上运行，再也无需去学习全新体系的框架了！

凭借不变的那个（项目代码），去应对变化多样的多端，实现从各自按自己的一套行事，转变为真正意义上的全面统一。

是因为多态协议里针对各层代码做了接口的定义，所以 CML 可以达成标准化的扩展新端。

对上图各层定义如下：

全面：支持所有小程序、H5和客户端

CML1.0 对业内所有小程序平台皆予以支持，这些平台涵盖微信、支付宝、百度以及头条 ，同时它还支持 H5 与客户端，并且，快应用官方的研发团队正立足于 MVVM+ 跨端标准协议来扩展快应用程序，其进度已达 100%，此刻处于研发完成后的如今测试阶段。

特别需要强调指出的是，致力于CML扩展的头条小程序，其中跟阿里以及芒果TV相关的部分，还有快应用端，也就是快应用官方团队那部分情况呀，它们通通都是由开源社区里非常优秀的开发者们通过贡献力量努力达成实现的呢。

细节：跨端一致性与定制性

CML1.0 实现了一套代码运行多端，并且高度一致。

一致性

长期以来，跨端领域始终存在着一致性与差异化这一棘手难题，CML针对此状况付出了诸多努力，涵盖生命周期的统一、事件系统、尺寸单位、布局外观保持一致、组件化方案以及数据管理等多个方面。尤其需要着重指出的是，组件化以及界面一致性堪称极易被忽略，同时又对开发体验有着极为重大影响的极为关键的要点。

CML的组件化办法，依赖于各端原本具备的组件化本事，最大程度降低因框架致使的性能难题。

以微信小程序和支付宝小程序作为例子，它属于微信小程序底层的那种组件组织框架，被内置在小程序基础库当中，能够为内置组件和自定义组件给出能力方面的支持，它是基于某种特定的模型得以做到实现的，具备高效轻量的特点，性能十分良好。

各个小程序的组件化模型并非一致，比如说，支付宝小程序组件化是基于 React Web 的，在使用过程中存在诸多限制，涵盖组件无样式作用域、数据传递以及事件通信等问题，CML 则是基于支付宝原有的组件化能力，消除与微信之间的各类差异，在确保原有运行性能的情形下，达成多端一致性并提升易用性。

换一个角度来说呢，借助引入了将各方面统一起来的具备一致性的基础样式，把各端出现的呈现效果不一样的状况给解决掉啦。

与此同时，CML1.0 将跨端样式校验规范予以强化，于开发模式之时，会对 CMSS 语法展开严格检查，仅仅准许书写通用的 CMSS 规则（此规则涵盖跨 H5、各类小程序以及客户端）。

定制性

CML具备统一性，还能够定制差异化，它给出了针对级别为工程的、项目、组件、方法、样式等各类别的定制化能力。

CML所独有的那个多态协议标准，能够直接去运用任意一端的第三方组件以及方法库，与此同时还能确保多端业务逻辑得以充分隔离，其维护性是非常高的。

需特别予以强调的是，1.0 版本具备了多态协议重载能力，此能力能够对某一个端的实现进行重载，基于这样的一种能力，我们将会推出面向各类小程序所特有的组件库，以此来解决小程序开发者抱怨最多的小程序组件不够丰富的这一问题。举例来说，借助多态协议重载能力，对组件在 web 端用户的实现予以重载，从而提示用户进行右上角分享。

我开发微信小程序时官方库

组件不够灵活？好说，重载在微信小程序端的实现即可！

性能：极致体验

CML对框架的性能异常重视，于性能优化的方向开展了诸多工作，涵盖包大小、各端加载之速度、执行效率等，给出了极优的性能体验。

包体积优化

下载速度会受到代码包大小的直接影响，进而影响用户首次打开时的体验。CML 一套代码可运行于 N + 端，或许会让人感觉框架规模较大，对性能存在影响。CML 所独创的多态协议，遍及整个框架范围有着包括 、、 等情况，不但具备良好的可维护性，而且在工程构建阶段时仅保留一端代码，以此保障代码产出包足够纯粹且足够微小。

不但如此，于包体积大小的优化层面，还开展了诸多别的工作，其中涵盖：

微信小程序给出分包加载办法，按页面作入口来分包，能够优化小程序初次启动的下载用时，并且在多团队一同开发之际能够更优地实施解耦协作。

CML1.0具备小程序分包加载支持能力，利用极为简便的配置方式，能够于编译阶段精准找寻资源，输出主包以及分包。具体参照内容为：https://cmljs.org/doc//.html?h=%E5%88%86%E5%8C%85。

小程序端性能优化

小程序端的渲染性能也是我们重要优化方向之一。

慢性粒细胞白血病借助接管小程序更新数据的接口，达成了一套数据响应系统，使得开发者能够运用类Vue的数据响应特性，诸如watch等，同时提供更为便捷的数据更新方式，直接进行赋值，而非借助原生接口去更新视图。

实际上，它乃是小程序开发期间运用最为频繁的一项接口 ，并且还是最易于引发性能方面问题的接口。

小程序把 用作视图层的渲染载体，将 当作逻辑层的独立运行环境。借助数据Diff 削减两者之间传输的数据量，能够优化性能。

在CML运行时框架当中，会针对每个组件实例去追踪数据，并且收集依赖，当数据出现变更之后，会和上一次所缓存的数据进行数据Diff，进而计算出最小更新数据，然后调用接口去传输最小必要的数据量。

如此一来，你能够针对组件数据进行任意自由的赋值操作，并不需要去操心原生平台接口的调用优化方面之事，框架将会在提高开发体验这件事情的同时，最大限度地确保应用程序的性能。

丰富：生态化建设完善

CML 的生态，不论组件库，还是接口库，又或是编辑器插件、调试工具，均处于疯狂迭代之中，持续进行更新。

需要着重指出的是组件生态圈，在开源 6 个月以来，开发者抱怨最多的是 CML 组件不够丰富这一问题，如今，由 CML 官方团队开发维护的 -ui-、cml-ui、light-ui、-ui- 组件库已然超过 60 + 组件，而且还在持续进行新增迭代，另外，由普惠出行前端团队主导合作共建的 c- 组件库同样包含了 20 + 组件。

c- 组件库

当前存在这样一套多端 UI 组件库，它是依赖基于 框架开发而成的，其以 C- 来命名，此库现阶段已然整合了多列选择器、索引选择器、消息提示此类构件，共计 12 个组件。

特性

进度与计划

当下已然达成了 12 个部件的构筑，拟定于 8 月对已竣工的部件予以优化，精心雕琢。

后续工作：适配需求较多的组件以及自定义主题。

以下是组件库部分组件的简单演示：

light-ui 组件库

Light-ui 的目标在于成为这样一个组件库，它能做到开箱即用，有着多样化配置，并且在多端呈现高度一致的状态。当下，Light-ui 已给出十余个用于跨端的组件，这些组件能够支持开发者迅速达成跨端需求的开发工作。

特性

进度与计划

目前已完成一期共十六个组件的开发。

接下来的工作安排是，原本设定在九月中旬之前要完成二期组件的开发任务，并且时时持续地和设计师进行合作，对细节方面予以精心打磨sublime text 2 js format，将交互体验进行进一步完善，把组件的易用性提升上去。

以下是组件库部分组件的简单演示：

-ui- 组件库

- -ui- 给出具备自由能力且丰富的、专门属于小程序端的特有组件以及 api 库。用户能够直接去运用各类小程序的统一版本的登录组件库，并且是在基于多态组件的重载能力扩展而达成的情况下，如此一来，既能够在各类小程序当中运用统一登录，又能够实现定制化的 web 端等登录能力。

特性

进度与计划

目前已初步完成既定组件的开发。

后续工作：完成组件文档更新，进一步优化及测试组件。

以下是组件库部分组件的简单演示：

生态规划

将 CML 社区用户群体具象分为以下等级开发者：

开放“一级开发”的组件导出能力，独立开放“二级开发”各端框架入口，并且为CML“贡献者”开放新端扩展标准入口，基于某种特定的激励机制，共同构建CML生态，持续进行转化输出。

工程化：全方位能力加持

CML 有着先进的工程化理念，这得益于团队于工程化设计方面所进行的尝试与实践，其整体开发、打包构建等流程极为高效 ，它解决了本地开发之际的各类痛点，诸如具备提供 dev 服务、mock 数据、热更新、自动刷新、调试窗口、线上资源代理等能力，这极大地提升了本地开发效率 ，你能够自由引入各类 npm 依赖包，开展组件化开发，进行模块化复用，运用 ES6 特性以及 CSS 样式预处理等等。

与此同时，CML 对框架的稳定性极为看重，它从代码质量方面着手，从测试可靠度方面考量，从语法检查方面审视，从生产环境方面出发，进而提供稳定靠谱的跨端解决办法。

现代化"链接"管理

CML从工程化的角度，将项目里用于外部通信的所有“链接”实行统一管理，这些“链接”涵盖数据请求链接（)、静态文件请求链接 ()、页面路由链接 ( )、跨端统一链接 ( URL)，它不但能够对“链接”数据进行统一化管理，还能够高效运用数据模拟（mock）、线上数据代理（proxy）、CDN跨端重用与更新、跨端页面统一下发等功能。

端的优化策略

针对端性能，从加载速度与执行速度这不同个特定维度着手进行优化，刚开始的时候要预先加载资源以此提升首次加载的速度，运用缓存的方式来提高二次加载达到的速度，并且与此同时对资源采取增量更新的策略。

将下载动作提前完成的预加载，是在需要用到的时候能直接从本地读取并渲染。于实际项目使用里，可于 app 启动时提前从服务端获取需要预加载的 url 地址列表，借助 SDK 提供的预加载能力提前把它们下载下来。

将SDK缓存此内容于下载完成之后，下次进行渲染之际的时候，如果此并未更新，那么便不会下载新的，以此达成节省时间以及流量提升速度于渲染方面的目的。

详尽的参照指向：https://cmljs.org/doc//.html。

另一方面，计划 CML 底层支持 ，敬请期待。

MVVM+ 协议：

编辑器插件

以便减少针对“开发一次调试多端”状况的指责言说出现的频率，促使相关问题在“编辑的这个时候”就能够被前瞻性地揭示出来，CML推出了好多款编辑器拓展程序玩意儿，当中涵盖了Code、Atom等等这一些。在扩展应用商店之内搜寻“cml”进行安装操作就可以达成相应诉求。给出编辑器插件对应的链接是：https://cmljs.org/doc//edit-.html。

目前该插件支持了以下能力：

正在开发对更多功能的支持，后续还会支持text插件，敬请期待。

强大的语法检查

CML 实现了全面的语法检查功能，且在持续加强。

跨端呈现出美好的状态，然而其最大的风险在于可维护性方面存在问题。多态协议构成了 CML 业务层代码与各端底层组件以及接口的分界之处 ，CML 会对输入输出值的类型和结构进行严格的“管制” ，与此同时 ，会对业务层 JS 代码展开严格的检查 ，以求避免直接运用某端所特有的接口 ，不允许在公共代码的位置使用某个端特定的方法 ，哪怕这段代码并不会被执行 ，比如说禁止使用 、wx、my、swan、weex 等方法。

分为：

CML for DoKit

CML DoKit专项工具，是CML团队，跟优秀的端研发工具，展开合作之后，所产出的CML定制版Dokit，它能够提供端SDK多种调试功能，目前涵盖的内容有：

如下图所示：

友好：渐进式接入

为了把原来已经有的项目，往CML框架那边进行迁移的时候，能够降低成本，在CML1.0这个版本里，向大家提供了下面这两种渐进式接入的方案，这两种方案呈现出优雅并且具有简洁性这样的特质。

CML 组件导入与导出

CML1.0具备把CML组件导出为各端组件的能力sublime text 2 js format，从而使你能够更自由地运用CML。

亦即是说，你能够于任意一端的原有项目里，运用经由CML开发而成的组件，网址为：https://cmljs.org/doc//io.html。

拿 web 和小程序来说，处于正常开发模式时，你得维护 4 套代码，分别是 web、wx、baidu 这三套。借助渐进式方案接入 CML 框架，去开发 cml 通用组件，之后导出各端供原有项目使用，如此仅需维护一套组件代码，充分运用了 CML 的跨端优势，极大地降低了代码开发维护成本。

与此同时，CML1.0 通过多态协议规范来导入各端的第三方组件库，在此情况下，你能够进行自由定制。

原有项目集成 CML 跨端方案

CML发布了一款名为“easy-”的产品，它能够直接在原本有的项目之中进行集成操作，这个操作符合CML相关要求。

接入的方式极为简便，你仅在easy-后添加上，依据指引进行轻度配置，便能够运用借助CML所具备的强烈语法运用能力、编译能力展开操作，以及运用CML组件、开展CML组件开发。具体接入文档参照为:https://cmljs.org/doc//.html。

如有侵权请联系删除！