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

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

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

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

背景

微信月活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但願既能用一套代碼完成全部端需求，將相同的業務邏輯完成收斂到同一層系統裏面，又不會由於項目的抽象一致致使可維護性變差。

讓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年時微信小程序發佈，滴滴做爲白名單用戶首先開始嘗試接入。這時候咱們專門成立了一個一、2人的小項目組，完成一個名爲MPV的項目，一期目標是「不影響用戶發揮，不依賴框架方的原則性實現一套代碼運行web和微信小程序」。MPV研發完成後，在多個項目實踐中，確實完成了超過90%代碼重用，整體上開發效率和測試效率都有了明顯提高，同時暴露出更多問題：

• 可維護性問題，沒有隔離公用代碼和各端差別代碼。
• 方向選擇錯誤，MPV使用了小程序語法標準(小程序的生命週期、API接口等)，致使用戶使用上沒法清晰理解使用規範。
• 各端周邊小型差別點太多。
• 模板DSL語法不規範。
• 兩端界面效果不一致。
• 多端調試成本高。
• 工程化建設落後。
• 不能直接使用各端已有生態組件，即缺少標準規範接入某個端已有開源組件。

2018年4月咱們把跨端項目規模進一步擴大，跨N端的解決方案命名爲Chameleon/kmiln/，簡寫CML，中文名卡梅龍;中文意思變色龍，意味着就像變 色龍同樣能適應不一樣環境的跨端總體解決方案。

Chameleon在MPV的實踐積累下，不只解決了遇到的各類可維護性問題，後續的規劃更加明確，目標真正專一於讓一套代碼運行多端，提供標準的MVV M模式統一各種終端。

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

生產應用舉例

易用性好

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

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

	開發快
關鍵詞	工程化開發	項目級統一	組件級統一
描述	收集最優秀的工程化功能: 多種數據Mock、資源定位、代理調試、LivereLoad等， CML不用僅僅是跨端，更能幫助開發者高效開發單個端。	當多個端整個業務高度一致時，能用一套項目代碼運行多端	已經用原生小程序開發代碼，已經用vue開發的web頁面，2者有重複開發組件如登陸 導出成小程序原生代碼/vue組件，放在各個項目裏面使用 安裝webpack插件，在普通項目中直接安裝該Chameleon組件並使用

	簡潔性（各端開發定製化空間大）	性能好	一致性
關鍵詞	多態協議	產出資源包大小，只保留單端代碼	語法檢查	多端一致性還原
描述	多態協議可用於多級，用戶自由切換，由上至下：方法級、組件級、頁面級、應用級	編譯階段將會只保留要導出的部分代碼，內置組件和API按需打包	爲了保障各個端實現效果一致，不用挨個調試各端，保存時作語法檢查，暴露潛在問題。	在編譯、runtime層大量工做保障實現效果一致

多態協議

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

說明/類型	整個項目使用CML	公用組件使用CML
關係圖
說明	業務層需求在各端環境高度相似, 本來須要針對不一樣端重複開發、重複測試， 那麼使用Chameleon將整個項目」從上至下「都用一套代碼運行。	本來公用組件須要重複開發、重複測試， 使用一套代碼開發公用組件， 各個端能夠直接使用公用組件
舉例	首頁、詳情頁、訂單	分享組件、支付組件、地圖組件、picker組件

業內對比

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

後期規劃

方向	子方向	執行項目
易用性增強	語法檢查 速度 前端工程化	A、檢查能力增強:潛在錯誤阻斷在編輯時 B、編輯器插件語法檢查:Sublime text、Visual Studio Code、Webstorm C、Chameleon playground:Debug工具增強 D、編輯器插件:代碼提示 E、圖形化界面建立和管理項目
框架優化	包大小 運行性能 web前端模塊服務化	A、包大小:優化各包大小到70%(uglily後當前weex 136k wx 99.3k web 143k) B、多端界面一致性增強:組件建立Web Component化 C、統一內置能力增強:Canvas、地圖、音頻等 D、靜態資源關係依賴:服務端按依賴自動加載資源包
端品類擴展	各種小程序 React-Native Flutter	A、支付寶小程序:能力支持(測試中) B、百度小程序:能力支持(測試中) C、快應用:能力支持 D、端擴展協議標準化:用戶自由擴展新端
組件擴展	c-design 內置組件增強	A、c-design:「開箱即食」的組件庫 c-design ，任意端用戶直接安裝可用 B、垂直類組件庫:金融、電商類型組件庫
端能力擴展	Native能力 內置組件增強	A、Native API:Chameleon Native SDK能力向小程序靠齊
流程優化	XEditor ChameleonShow	A、ChameleonShow:開源Chameleon後臺管理平臺，解決移動端頁面碎片化問題 B、XEditor:讓非研發直接發佈任意終端的簡單頁面，無需重複開發
服務擴展	多端服務能力統一	A、統一雲服務:統一後端服務接口能力，如分享、支付、消息推送

理想主義

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

快速開始：cmljs.org/doc/quick_s…

常見問題: cmljs.org/doc/framewo…

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