1、前言
經過前面十篇文章，我們學習了Weex的使用、原始碼及架構分析，對Weex的優缺點和核心能力也有了認識。
為了將大前端進行徹底，我們來思考一個問題： 如何使用Weex構建一個完整的App？ 也就是說App是個殼子，骨架則是Weex。
2、優勢
我們先來想下一個完整Weex構建的App有哪些好處，當然在一定程度上可以換句話說是平時Native開發的缺點：
- 動態更新的能力，模組修改或者熱修復；
- 更簡單的支援A/BTest；
- Apk包小，業務模組可按需下載；
- 降低崩潰率；
試想，平時我們是不是在Native開發中會花費大力氣在熱修復、A/BTest以及Dex較多時的拆包方案上，同時在釋出市場的時候需要等待稽核及使用者升級率不高的長時間焦灼。
3、實踐
一般對於比較難或者大的問題我們會首先進行任務拆解，拆解成若干小問題逐個突破。
我們看下拆解之後的各種小問題：
- 專案鏈路；
- 協作方式；
- 其它優化；
3.1 專案鏈路
專案鏈路就是整個專案開發、測試、打包、灰度、釋出等的流程，和傳統的Native開發區別並不是很大，有一些需要注意的點。
對開發的版本控制倉庫我們需要兩個，一個是Android的程式碼倉庫，另一個是Weex的開發倉庫；
- Android程式碼倉庫用來做Native元件提供、Weex模組的程式碼內建及殼App的打包；
- Weex程式碼倉庫就是Vue程式碼的版本控制；
備註：
- Weex使用Vue程式碼需要經過編譯，最好做一個指令碼工具簡化步驟；
- 對灰度來說，依賴於釋出平臺，最好能有一個視覺化的操作介面；
3.2 協作方式
協作方式就是一個完整的Weex App需要哪些人，如何分工能使人效最大化？
首先對於簡單的Weex使用，Native RD可以自己上手寫Weex程式碼。但是整個App都是Weex構建為了更好的工程化，那麼最好分工明確：
- Native同學只負責基礎架構，提供各種元件供前端同學來呼叫；
- 業務部分由前端同學來做；
這種分工的好處是Native和前端同學各自負責自己擅長的工作內容，有利於業務的快速開展。
3.3 其它優化
**對於一個完整的Weex App，這塊必不可少。畢竟對於純粹的原生開發，大量開發人員經驗豐富，解Bug、調優的套路都有明確的路子。但是一旦完全採用了Weex技術棧，單純的使用Weex就不夠了，需要對Weex的原始碼非常熟悉，必要的時候加以修改（這點我覺得免不了）。**以下列出幾點：
- 基礎能力需要自己做；
- 測試環節的加強，穩定性、效能的保障；
- 介面顯示速度的優化；
務必注意：吃透原始碼，不滿足的時候才能盡情修改。
4、總結
本文總結Weex開發的鏈路，關於Weex的使用、原始碼分析、架構設計、優劣等可以參考之前的系列文章。
歡迎關注微信公眾號：定期分享Java、Android乾貨！
