### 回答问题很多人问和业内已有的框架区别，最大区别是其他框架都是小程序增强，即用vue或者react写小程序，这些框架官方给的已接入例子也都是跑微信小程序。其他框架所有的设计都是思考如何用某个框架在微信小程序跑起来，即小程序增强，举个具体栗子： mpvue 讲述如何用echart：http://mpvue.com/qa/#echarts taro 讲述如何用echart：https://github.com/NervJS/taro-sample-weapp cml讲述如何用ecahrt：https://cmljs.org/doc/example/poly.html ### 前身其他框架更加类似cml的前身，考虑如何增强小程序开发， cml的前身叫mpv(mini program view），2017年时微信小程序发布，滴滴作为白名单用户首先开始尝试接入，开始面对重复开发的难题。这时候我们专门成立了一个小项目组，完成一个名为mpv的项目，一期目标是“不影响用户发挥，不依赖框架方的原则性实现一套代码运行web和微信小程序”。看着很美好，用这样的方案实现web端和小程序端，也确实完成了超过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成本高，修改完代码之后2端需要测试 - 2端界面效果不一致，基础内置组件统一性建设不足 - 工程化建设落后，例如不支持liveroload、数据mock、资源定位、proxy、多端统一预览 - 接口设计不完整，生命周期、组件分层、本地API设计等 - 模板DSL语法不规范 ### 复盘总结 CML的出身真正想要一套代码运行多端，总结下来以上要解决几大问题 - 1. 要全面完成端开发的所有细节的统一性 - 2. 要在完成第1条的前提下考虑差异化定制空间 - 2. 持续可维护特别是界面统一性有大量细节要做，大量时间积累。下面表格较宽，可以往右滑动---------> ---------> --------->

节点	项目工程配置	项目结构	路由	组件	布局和外观	界面结构、数据、交互关联	生命周期	交互关联（事件）	数据管理	本地接口	尺寸单位
关键词	chameleon.config.js	app、 components、pages、store	Chameleon URL	CML文件	CMSS	CML语法、类VUE	beforeCreate、created、beforeMount、mounted、beforeDestroy、destroyed	c-bind、 event、事件流（传递顺序）	类vuex	Chameleon-API	cpx
统一性	针对工程化可以自由定制某端差异化	统一结构	在不同环境下能自适应打开不同环境同一页面	组件单文件结构：包含CML、CMSS、逻辑JS、其他配置JSON	定义更精细化、规范化的描述UI的布局、元素尺寸、文本颜色等	定义CML保障可维护性，支持类vue语法降低学习成本	提供6个基础生命周期，各端特定周期事件可以隔离扩展	统一绑定方式、事件对象结构	vuex易用性强，无须过多设置	提供网络、媒体、动画等基础接口	各端单位不统一，提供虚拟单位cpx，自动转成各端尺寸（rpx、rem、px等）
差异化实现空间	各类都可以配置	结构没有差异化需求	H5配置可差异化	组件多态	样式多态	组件多态	方法多态	方法多态	方法多态	方法多态	组件多态
隔离性	纯简单配置		纯简单配置	通过interface定义统一输入、输出保障各端代码和公用代码有效隔离	CSS是纯描述性语言，组件级别隔离	通过interface定义统一输入、输出保障各端代码和公用代码有效隔离	通过interface定义统一输入、输出保障各端代码和公用代码有效隔离	通过interface定义统一输入、输出保障各端代码和公用代码有效隔离	通过interface定义统一输入、输出保障各端代码和公用代码有效隔离	通过interface定义统一输入、输出保障各端代码和公用代码有效隔离	通过interface定义统一输入、输出保障各端代码和公用代码有效隔离

上面表格较宽，可以往右滑动---------> ---------> ---------> ### 业界对比业内其他框架和我们的目标不一样，我们是希望真正一套代码运行多端，而其他框架无非是“某个小程序语法增强”或者“推广某个框架写小程序”，但却是有重合点，这里从整体角度，列举一下功能对比：

	常规功能（模板、数据管理、组件构成）	统一性	差异化	工程化扩展	语法检查	各端组件导入强规范	组件导出	框架设计特点	Native 端配套 SDK
CML	CML/VUE、VUEX、单文	路由、项目、页面、组件、API、尺寸单位等各端使用一致	多态协议隔离差异化	本地调试服务、多类数据Mock线上代理调试	全面检查，提升开发效率	有	有	一套代码运行多端	有
Taro	JSX、redux、单文件	react框架、微信小程序组件、微信小程序API，告知用户差异，用户按端兼容性调用	环境变量判断混合差异化	本地调试服务	无	无	无	推广某个框架写小程序：用react写小程序	无
wepy	VUE、VUEX、单文件	仅支持微信小程序，不存在统一性	仅支持微信小程序，不存在差异性	本地调试服务	无	无	无	小程序语法增强：让小程序支持组件化开发的框架	无（目标不一样）
Mpvue	Vue、Vuex、单文件	仅支持微信小程序，不存在统一性	环境变量判断混合差异化	本地调试服务	无	无	无	某个小程序语法增强：用vue写小程序	无（目标不一样）
weex	VUE、VUEX、单文件	vue框架、weex组件、weex API多端一致（只支持web+native）	环境变量判断混合差异化	本地调试服务	无	无	无	一套代码运行web和native端	有
各类原生小程序	小程序模板、无、多文件	仅支持自身小程序，不存在统一性	仅支持自身小程序，不存在差异性	无	无	无	无	实现自家小程序	无（目标不一样）

chameleon和taro Uni-app mpvue的区别是什么 #12

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions