Weex工具鏈的奧祕

導讀	在2017年1月12日 Weex Conf 2017上，來自阿里的卜道依據Weex開發中的痛點介紹了Weex的打包和插件機制，一樣來自阿里的歸影介紹了Weex的調試工具Devtools，共同揭祕了Weex的工具鏈。本文是卜道和歸影關於Weex工具鏈實踐的分享整理。

Weexpack與插件機制

Weex開發中的痛點

Weex提供了一個高效的引擎，可是開發者僅有這個SDK是不夠的，咱們還須要更完善的類庫和強大的調試工具，遇到問題能夠用工具來解決，複雜的場景須要用工具來消解其複雜度，把複雜問題簡單化。

Weex工具鏈

Pack一鍵打包，適合純前端的開發者創建Weex應用，不須要關心native的具體作法。Devtools主要解決Weex代碼的調試問題。插件機制可以讓開發者從Weex市場安裝插件到本地的工程中, 以搭積木的方式開發app。IDE還在持續建設中。

Weex SDK支持的擴展方式

Module是一些非UI的特定功能，sendHttp、openURL等能夠做爲module來擴展。Component是一些UI控件，RichText、DatePicker等能夠做爲component來擴展。Adapter/Handler是SDK內置的一些適配器接口，沒有指定具體的實現，能夠根據本身APP的狀況選擇合適的實現來做爲功能的擴展，例如圖片加載器等。

插件機制

示意圖最上方是市場，市場中會有開發者發佈的不少的可複用的插件。中間是咱們的應用，與OS進行通訊的是SDK，基於SDK有一個APP Framework（應用容器，包括了一些頁面控制邏輯，解析插件的配置文件），Plugin Framework插件容器是插件安裝的target，插件既能夠從市場下載安裝，也能夠從本地或者github安裝。插件是上述SDK的三種擴展方式的封裝，能夠調動native的接口，具備和native通訊的能力，極大地擴展了應用的能力，擴展了Weex應用的邊界。

插件到插件容器的映射

左側是插件結構的示意圖，配置文件爲Plugin.xml，裏面配置了插件的組成和相應平臺須要安裝的資源、源碼及依賴，安裝到了Plugin Framework中後，映射爲了右側的相應文件，分別對應到android平臺和IOS平臺。

打包及插件相關命令

左圖是打包命令，Weexpack create建立一個新工程，包括必要的目錄和一些配置文件，Weexpack platform add/remove用來安裝或者移除應用模版，它的參數是相應平臺的應用模板， Weexpack plugin add/remove用來安裝和移除插件，參數爲插件名，它是打包流程的一個可選項。右圖是插件開發者的一些命令，經過Weexpack plugin create建立插件，配置好相關命令，經過publish發佈。

插件的安裝使用

打包及插件機制應用示例

 

上圖案例中的插件是一個複雜插件，咱們設置了其對其它插件的依賴關係，Weex-gcanvas插件提供基礎的繪圖能力，Weex-chart基於其所依賴的Weex-gcanvas進一步提供圖表的能力。具體的步驟如上圖所示。

 

Weex-gcanvas安裝怎麼完成的？首先，插件在plugin.xml定義了其依賴關係以及須要暴露的接口；而後，咱們的工具會根據plugin.xml的配置去維護幾個文件——config.xml和build.gradle, 若是涉及權限或者其餘資源相應的也會去修改AndroidManifest， 源碼和資源會被複制到插件容器對應的目錄中。

插件機制的優勢

• 按需打包，插件能夠按需靈活配置打包，app徹底自主；
• 獨立升級，插件可獨立升級，支持細粒度的版本控制；
• 支持二次開發，插件能夠二進制庫或者源碼形式發佈，方便二次開發；
• 流程自動化，提供完善的命令行工具，自動合併代碼、資源及編譯腳本；
• 面向定製，可按需定製本身的插件倉庫和平臺模板；
• 集成一鍵打包，插件工具和打包工具完全打通，下降開發app的門檻。

展望——插件化的Weex APP

 

若是插件市場已經有了不少插件，功能很豐富，前端的開發者只須要寫最熟悉的業務邏輯就能生成應用；而native開發者也能參與開發發佈Plugin和Framework中來。

調試工具Devtools

Weex的調試需求

做爲前端的開發者，須要哪些功能？在邏輯方面，最重要的，咱們須要斷點調試js，最好能直接在we文件裏打斷點；在渲染方面，須要能夠查看dom層級結構(前端)/native view層級結構(native端)的工具；在優化方面，能不能看到native的各類網絡加載信息，如加載bundle的信息和時間，或者JS運行時的堆快照(heap snapshot)等等。

Weex Devtool主要功能

上圖是Weex Devtool提供的主要功能。Debugger能夠遠程調試Weex源碼，可呈現原始的we代碼結構並打斷點。Inspector展現渲染節點的層級結構，可隨時切換dom tree和native view tree，能夠高亮某一個節點。

遠程調試

 

在解決問題以前須要抽象問題，一個客觀事實是若是想在Chrome裏面調試JS，那這個JS必須運行在Chrome的運行時裏面。Weex現有的流程歸納爲用戶寫的業務代碼運行在native的運行時（android是V8，IOS是JSCore）裏面，由這些運行時和JS的worker負責與native渲染引擎的通訊。那麼，問題抽象爲若是要實現遠程的運行時——Chrome，並實現運行時和native渲染引擎的通訊。運行時環境哪家強？顯然是worker，基於worker的前端是瀏覽器解決多線程的一種技術手段。今天用到的是其靈活和隔離性，一個worker能夠很方便的建立和銷燬，並且它又有比較好的獨立性，因此是一個比較好的運行時環境。通訊方面，利用一種計算RPC的方式，制定本身的協議，並經過這個協議與native的渲染引擎進行通訊。優化方面，Weex加載Bundle的方式是直接加載Bundle的運行源碼，調試時沒辦法打斷點，因此調試工具作了一箇中間層，將Bundle包裝成一個函數並將其放在一個JS文件裏面，利用Chrome的運行時去加載這個文件。還原成源碼中打斷點，即提供一個Sourcemap。

Inspector原理

 

Inspector是模仿Chrome的Inspector製做的。Chrome的調試工具是一個Web APP，是純前端技術寫出來的APP。其數據是Chrome經過remote debug protocol協議發送給Devtool工具，這些數據一部分來自渲染引擎，另一部分來自V8引擎。對於前端來講，不管是渲染引擎仍是V8都在一個Chrome裏面，可是對於Weex的場景並非這樣的。Weex的JS是運行在Chrome的運行時裏面，渲染是在手機native端，調試這些調試信息須要經過Chrome的V8來獲取，並且只能給到原生的Devtool。而咱們的層級信息須要手機的native端給到，因此只能本身作了一個extension頁面去承載和表現這部分的數據。

總體架構

 

分三層：最上層是Devtool的前端；中間是Node Server，主要負責RPC消息轉發、維持session多實例管理的功能；最下層是Native Inspector。這些RPC是須要在native端安插內應的，即android和IOS的Native Inspector模塊，它會截獲自己Weex的SDK應該發給native runtime的全部信息，而後將這些信息轉發給遠程的Weex調試工具。

困境和展望

最大的困境是調試體驗太分離，由於分爲兩個界面，而且一部分的功能須要extension提供。可是，Weex Devtool 1.0.0已經正在開發，逐步完善解決這些問題。

原文來自：https://yq.aliyun.com/articles/68947?spm=5176.100239.bloglist.131.pn6omB

本文地址： http://www.linuxprobe.com/weex-tools.html