Chameleon跨端框架——壹個理想主義團隊的開源做品

文章較長，信息量很大，請耐心閱讀，必然有收穫。下面正文開始~

• 背景
• 解決方案
• 原理
• 久經考驗
• 生產應用舉例
• 易用性好
• 多態協議
• 學習成本低
• 漸進式接入
• 業內對比
• 後期規劃
• 理想主義

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

背景

微信月活10億月活、支付寶4億月活、百度3.3億月活；2018 Q3中國Android手機佔智能手機市場超過80%；不管BAT仍是Android快應用都是中國互聯網用戶的真正用戶入口，做爲小型互聯網公司都但願能搭上小程序的風口，從而蹭一波流量。

計算機技術歷史發展告訴咱們，每一種新技術出現都會經歷"各自爲政"的階段，小程序技術也不例外。微信小程序做爲獨創者，雖然其餘小程序都在技術實現原理、接口設計刻意模仿，可是做爲一線開發者面對一樣的應用實現每每須要重複開發、測試，從前1單位的工做量變成了N單位的工做量。

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

各種原生跨端框架並駕齊驅：

1. 從Facebook在2013年開源react，這個項目自己越滾越大。從最先的WebUI引擎衍生的ReactNative項目，目標更是宏偉。
2. Vue.js於2014年左右發佈，逆流而上佔據了大量用戶羣體，2016年阿里巴巴也基於vue發佈了weex項目，能夠用vue編寫Native APP。
3. Google在2018年底正式發佈了面向將來的跨Andoid、IOS端Flutter1.0.0，做爲面向將來的跨端框架，前景一片光明。

解決方案

雖然不一樣各端框架環境變幻無窮，不管各種小程序、Weex、React-Native、Flutter、快應用，它們萬變不離其宗的是MVVM架構設計思想。Chameleon但願既能用一套代碼完成全部端需求，將相同的業務邏輯完成收斂到同一層系統裏面，又不會由於項目的抽象一致致使可維護性變差。

讓MVVM跨端環境大統一：以各個跨端技術(Wee x、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的實踐積累下，不只解決了遇到的各類問題，後續的規劃更加明確，目標真正專一於讓一套代碼運行多端，提供標準的MVVM模式統一各種終端。

通過一年數十位前端開發人員在上百頁面中的實踐經驗積累，於近日正式開源:https://github.com/didi/chameleon。

生產應用舉例

易用性好

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

• 開發快，總體開發流程要高效。
• 簡潔性，各端開發定製化空間大，且公用代碼不會混雜某端代碼。
• 性能好，不能增長產出文件包大小。
• 一致性，多端實現效果一致。

多態協議

多端合併後各端差別化實如今所不免，一開始是差別化代碼和業務邏輯混雜在一塊兒。這就尷尬了，若是你以爲以上不復雜，假設有四、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？固然能夠,兩種方式使用CML:

業內對比

業內其餘框架和咱們的目標不同，咱們是但願真正一套代碼運行多端，而其餘框架無非是「某個小程序語法加強」或者「推廣某個框架寫小程序 」，但倒是有重合點，列舉一下功能對比:

後期規劃

理想主義

1. 咱們忍受不了本身的時間浪費在重複勞動上。
2. 要麼不作要作就到極致，一套代碼運行多端原本就是理想主義，這條路很艱苦，咱們卻偏執的堅信必定要盡最大努力作出來，做爲一個不那麼自 信的人，不作到好用是不敢發佈出來的。
3. CML框架各個細節都要作到極致，咱們不能容忍有設計上的缺陷，因此經常CML週會上團隊成員討論6個小時直到深夜。

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

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

歡迎加入貢獻代碼：didi/chameleon