摘要：跨端框架壹個理想主義團隊的開源作品歷經(jīng)近個月打磨，滴滴跨端方案終于開源了真正專注于一套代碼運行多端。這時候我們專門成立了一個人的小項目組，完成一個名為的項目，一期目標是不影響用戶發(fā)揮，不依賴框架方的原則性實現(xiàn)一套代碼運行和微信小程序。

歷經(jīng)近20個月打磨，滴滴跨端方案chameleon終于開源了https://github.com/didi/chameleon,
真正專注于一套代碼運行多端。

微信月活10億月活（超過網(wǎng)民數(shù)量，用戶多個賬號？）、支付寶4億月活、百度3.3億月活；2018 Q3中國Android手機占智能手機市場超過80%；無論BAT還是Android快應用都是中國互聯(lián)網(wǎng)用戶的真正用戶入口，作為小型互聯(lián)網(wǎng)公司都希望能搭上小程序的風口，從而蹭一波流量。

計算機技術歷史發(fā)展告訴我們，每一種新技術出現(xiàn)都會經(jīng)歷"各自為政"的階段，小程序技術也不例外。微信小程序作為首創(chuàng)者，雖然其他小程序都在技術實現(xiàn)原理、接口設計刻意模仿，但是作為一線開發(fā)者面對同樣的應用實現(xiàn)往往需要重復開發(fā)、測試，從前1單位的工作量變成了N單位的工作量。

滴滴的研發(fā)工程師是其中最顯著的"受害者"之一，滴滴出行在微信錢包、支付寶、Android快應用都有相關入口，用戶流量占比不低。

各類小程序已經(jīng)能覆蓋中國所有網(wǎng)民，從Facebook在2013年開源react，這個項目本身越滾越大。從最早的WebUI引擎衍生的ReactNative項目，目標更是宏偉。

Vue.js于2014年左右發(fā)布，逆流而上占據(jù)了大量用戶群體，2016年阿里巴巴也基于vue發(fā)布了weex項目，可以用vue編寫NativeAPP。

Google在2018年末正式發(fā)布了面向未來的跨Andoid、IOS端Flutter1.0.0，作為面向未來的跨端框架，前景一片光明。

雖然不同各端框架環(huán)境千變萬化，無論各類小程序、Weex、React-Native、Flutter、快應用，它們萬變不離其宗的是MVVM架構設計思想。Chameleon希望既能用一套代碼完成所有端需求，將相同的業(yè)務邏輯完成收斂到同一層系統(tǒng)里面，又不會因為項目的抽象一致導致可維護性變差。

讓MVVM跨端環(huán)境大統(tǒng)一：以各個跨端技術(Weex、React-Native、WebView瀏覽器、Flutter)和產品業(yè)務(微信小程序、快應用、支付寶小程序、百度智能小程序、今日頭條小程序、其他各類小程序)的共同技術特點——MVVM架構設計， 以統(tǒng)一MVVM跨端架構平臺為目標的程序語言框架Chameleon(任意使用MVVM架構設計的終端，都能以Chameleon開發(fā)并運行)。

View:

ChameleonSDK包括各類小程序、web端、客戶端(React-Native、Weex、Flutter)，目前支持微信小程序、Web、Weex三類，后續(xù)支持更多MVVM為標準的端。

View Model:

CML(Chameleon MarkupLanguage)是框架設計的一套標簽語言，結合基礎組件、事件系統(tǒng)、數(shù)據(jù)綁定，可以構建出頁面的結構。同時為了降低學習成本支持類VueTemplate。

2017年時微信小程序發(fā)布，滴滴作為白名單用戶首先開始嘗試接入。這時候我們專門成立了一個1、2人的小項目組，完成一個名為MPV的項目，一期目標是“不影響用戶發(fā)揮，不依賴框架方的原則性實現(xiàn)一套代碼運行web和微信小程序”。MPV研發(fā)完成后，在多個項目實踐中，確實完成了超過90%代碼重用，總體上開發(fā)效率和測試效率都有了明顯提升，同時暴露出更多問題，在MPV的實踐積累下，有了一定的底氣和把握，后續(xù)的規(guī)劃更加明確。

可維護性問題，沒有隔離公用代碼和各端差異代碼。

方向選擇錯誤，MPV使用了小程序語法標準(小程序的生命周期、API接口等)，導致用戶使用上無法清晰理解使用規(guī)范。

各端周邊小型差異點太多。

模板DSL語法不規(guī)范。

兩端界面效果不一致。

多端調試成本高。

工程化建設落后。

不能直接使用各端已有生態(tài)組件，即缺乏標準規(guī)范接入某個端已有開源組件。

2018年4月我們把跨端項目規(guī)模進一步擴大，跨N端的解決方案命名為Chameleon/kmiln/，簡寫CML，中文名卡梅龍;中文意思多帶帶飛，意味著就像變 色龍一樣能適應不同環(huán)境的跨端整體解決方案。

Chameleon在MPV的實踐積累下，不僅解決了遇到的各種可維護性問題，后續(xù)的規(guī)劃更加明確，目標真正專注于讓一套代碼運行多端，提供標準的MVV M模式統(tǒng)一各類終端。

經(jīng)過一年數(shù)十位前端開發(fā)人員在上百頁面中的實踐經(jīng)驗積累，在本周正式開源:https://github.com/didi/chameleon。

一套代碼運行多端理念，被人挑戰(zhàn)最多的如何保證易用性。

開發(fā)快，整體開發(fā)流程要高效。

簡潔性，各端開發(fā)定制化空間大，且公用代碼不會混雜某端代碼。

性能好，不能增加產出文件包大小。

一致性，多端實現(xiàn)效果一致。

多端合并后各端差異化實現(xiàn)在所難免，一開始是差異化代碼和業(yè)務邏輯混雜在一起。這就尷尬了，如果你覺得以上不復雜，假設有4、5個端呢，業(yè)務邏輯摻雜跨端邏輯，產品邏輯別打斷，可讀性差，需求變更，牽一發(fā)動全身，每個端都要測試，跨端代碼效率變得適得其反。

下圖各端差異化代碼也和邏輯混合在一起
-7b1535c36a260b577f497853d62268cb.png)

多態(tài)協(xié)議設計的靈感來自于Apache Thrift - 可伸縮的跨語言服務開發(fā)框架，本質上跨端也屬于跨語言。
它能讓Chameleon開發(fā)者快速接入各個客戶端底層功能或者差異化業(yè)務實現(xiàn)，避免可讀性差、可維護性差的問題。

多態(tài)協(xié)議通過定義標準接口(interface)，各端模塊各自獨立實現(xiàn)，編譯時和運行時對實現(xiàn)的接口輸入輸出做檢查。

主要2個目標:

保障多端可維護性

編譯時拆分多端代碼

當用戶按照標準規(guī)范擴展個別產品效果多端不一致或特定底層能力多端不一致的的功能時，多態(tài)協(xié)議可以有效隔離公用代碼和各端差異代碼，保證”河水不犯井水“。

1. 在項目中分別按照web版本 npm install echarts 和微信版本下載相關文件

2. 然后定義一個多態(tài)組件 charts

3. 在 charts/charts.interface 定義該組件的輸入和輸出

4. 分別在 charts/charts.wx.cml 和 charts/charts.web.cml 里面調用微信版本(可使用微信小程序組件文件夾)和web版本(可調用.vue后綴文件)

5. 最后就能在項目中使用該組件

產出包里面只包含該組件其中一端的代碼;因輸入輸出的限制，該組件調用上完全一致，不用根據(jù)某端做特殊邏輯處理。你可以將該echart多態(tài)組件多帶帶放置在一個倉庫里面多帶帶維護并發(fā)布;其他人無需關系內部細節(jié)，直接npm install echart即可使用。

VM層的CML語法是關聯(lián)視圖層和邏輯層的抽象DSL，其有學習成本問題是被熱心很多幫助我們的同學提的最多建議，本身其CML學習成本已經(jīng)非常低，無非是數(shù)據(jù)雙向綁定、事件綁定、組件樹、條件語句、循環(huán)遍歷等等。一開始我們是拒絕的，后來綜合考慮之下，還是妥協(xié)支持了類vue語法，讓開發(fā)者更快上手CML。

很多人已經(jīng)開發(fā)小程序了，又不愿意大多闊斧重新改造，也希望使用CML？當然可以,兩種方式使用CML:

業(yè)內其他框架和我們的目標不一樣，我們是希望真正一套代碼運行多端，而其他框架無非是“某個小程序語法增強”或者“推廣某個框架寫小程序 ”，但卻是有重合點，列舉一下功能對比:

快速開始：https://cmljs.org/doc/quick_start/quick_start.html

常見問題: https://cmljs.org/doc/framework/faq.html