Chameleon是一個專業的跨多端開發的統一解決方案，之所以取名為變色龍，就是因為其高度的適應期，它可以像變色龍一樣適應不同的環境。多端高度一致，無需關注各端文檔。基于多態協議，不影響各端的差異化與靈活性。現在許多編程的小伙伴在面對入口擴張、各種小程序和快應用時，單一功能要想覆蓋到各大平臺，需要花費較多的心血和時間，開發和維護成本成倍增加。使用CML就可以幫助你實現一套代碼運行多端，一端所見即多端所見。

軟件特色

多端高度一致

深入到編程語言維度保障一致性，包括框架、生命周期、內置組件、事件通信、路由、界面布局、界面單位、組件作用域、組件通信等高度統一。

豐富的組件

在用 CML 寫頁面時，chameleon 提供了豐富的組件供開發者使用，內置的有button switch radio checkbox等組件，擴展的有c-picker c-dialog c-loading等等,覆蓋了開發工作中常用的組件。

豐富的 API

為了方便開發者的高效開發，chameleon 提供了豐富的 API 庫,發布為 npm 包chameleon-api，里面包括了網絡請求、數據存儲、地理位置、系統信息、動畫等方法。

自由定制 API 和組件

基于強大的多態協議，可自由擴展任意 API 和組件，不強依賴框架的更新。各端原始項目中已積累大量組件，也能直接引入到跨端項目中使用。

基于強大的多態協議，充分隔離各端差異化實現，輕松維護一套代碼實現跨多端。

智能規范校驗

代碼規范校驗，當出現不符合規范要求的代碼時，編輯器會展示智能提示，不用挨個調試各端代碼，同時命令行啟動窗口也會提示代碼的錯誤位置。

漸進式跨端

既想一套代碼運行多端，又不用大刀闊斧的重構項目？不僅可以用 cml 開發頁面，也可以將多端重用組件用 cml 開發，直接在原有項目里面調用。

先進前端開發體驗

Chameleon 不僅僅是跨端解決方案。基于優秀的前端打包工具 Webpack，吸收了業內多年來積累的最有用的工程化設計，提供了前端基礎開發腳手架命令工具，幫助端開發者從開發、聯調、測試、上線等全流程高效的完成業務開發。

業務線收集

使用CML業務線收集。

項目上線指南

#是否添加 polyfill

CML 框架中 js 代碼都是經過了 babel 編譯，但是 babel 默認只轉換語法，而不處理新的 API，例如Object.assign,Object.entries。如果項目中使用了一些不經過 babel 的 API，并且線上產品需要兼容低版本系統的手機，CML 提供了在各端添加 polyfill 的配置 參見 babelPolyfill。

#靜態資源發布路徑

靜態資源發布路徑 是配合項目靜態資源最終線上地址,設置方法參見資源發布路徑。 例如： 項目中引用了一個本地圖片：

該圖片執行 cml web build 打包到本地 web/static/img/chameleon_83ee00e.png;

如果預計將該靜態資源上線到https://static.cml.js/vender下

例如圖片線上地址https://static.cml.js/vender/web/static/img/chameleon_83ee00e.png。

則應該將 publicPath 設置為https://static.cml.com/vender后執行cml web build。

這樣代碼中的圖片地址線上就能夠正確訪問。 同理適用于 Web 端 html 頁面中注入的link和script標簽。

#小程序中的靜態資源上線

由于小程序有包大小的限制，所有建議打包出的靜態資源單獨上線，不放在小程序包中，chameleon-tool@0.3.1 版本在 dev 模式也默認將圖片的地址改成本地 web 服務器訪問的地址，解決 css 中 background-image 不能使用本地圖片的問題。

如果不將靜態資源單獨上線，注意要將 publicPath 設置為/，例如：

cml.config.merge({ wx: { build: { publicPath: "/" } } });

注：百度小程序中必須將靜態資源單獨上線, 因為不支持靜態資源的。

常見問題

♦怎么理解框架的實現原理？

實現原理圖

♦我想使用 CML，是否需要大刀闊斧的重構項目？

不需要，可以使用 CML 開發公用組件，導出到各端原有項目中使用。

♦用 CML 標準編寫代碼，是否增加調試成本？

我們實現了全面的語法檢查功能，且在持續加強。理論上框架是降低調試成本，就像從原生 js 開發到 vuejs、reactjs 是否認為也增加了調試成本，見仁見智。

♦如何定位并解決 CML 開發中遇到的問題？

首先，當我們遇到一些問題的時候，第一步要定位問題，定位問題的基本思路如下

初始化一個項目，以最基礎、最簡單的demo復現出現問題的基本場景

通過在代碼中插入debugger進行基本的斷點調試

github-issues搜索是否有類似問題

♦各端包括小程序的接口更新頻繁，如何保證框架編譯的抽象度和穩定性？

1、自建輸入語法標準 cml，編譯輸出結果自定的格式語法。 2、框架的 runtime 層實現匹配接收的編譯輸出代碼，runtime 跟隨小程序更新。 3、框架整體方向一致：mvvm 底層設計模式為標準設計接口。 基于以上三條，你可以理解為：我們設計了一個框架統一標準協議，再在各個端 runtime 分別實現這個框架，宏觀的角度就像 nodejs 同時運行在 window 和 macOS 系統，就像 flutter 運行在 Android 和 iOS 一個道理。各端小程序接口更新除非遇到不向下兼容情況，否則不影響框架，如果真遇到不向下兼容更新，這種情況下是否用框架都需要改。

♦一套代碼運行多端，如何保證各個端充分的定制化空間？

基于多態協議，充分保證各端發揮，且保證最終一致性。

♦各端包括小程序的接口更新后，是否一定依賴框架更新？

同上一個問題，基于多態協議，可自己直接調用新的底層接口。

更新內容

支持chameleon-api-miniapp按需加載

支持組件動態加載

支持路由懶加載

支持終端構建進度 processBar 可配置，默認關閉

修復config.json生成的weex端信息缺失

支持壓縮模式下console信息可配置是否刪除

chameleon-linter修復useingComponents中引入動態組件校驗