深刻Weex系列（十一）使用Weex構建一個完整App的思考

一、前言

通過前面十篇文章，咱們學習了Weex的使用、源碼及架構分析，對Weex的優缺點和核心能力也有了認識。

爲了將大前端進行完全，咱們來思考一個問題： 如何使用Weex構建一個完整的App？ 也就是說App是個殼子，骨架則是Weex。

二、優點

咱們先來想下一個完整Weex構建的App有哪些好處，固然在必定程度上能夠換句話說是平時Native開發的缺點：

• 動態更新的能力，模塊修改或者熱修復；
• 更簡單的支持A/BTest；
• Apk包小，業務模塊可按需下載；
• 下降崩潰率；

試想，平時咱們是否是在Native開發中會花費大力氣在熱修復、A/BTest以及Dex較多時的拆包方案上，同時在發佈市場的時候須要等待審覈及用戶升級率不高的長時間焦灼。

三、實踐

通常對於比較難或者大的問題咱們會首先進行任務拆解，拆解成若干小問題逐個突破。

咱們看下拆解以後的各類小問題：

• 項目鏈路；
• 協做方式；
• 其它優化；

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的源碼很是熟悉，必要的時候加以修改（這點我以爲免不了）。**如下列出幾點：

• 基礎能力須要本身作；
• 測試環節的增強，穩定性、性能的保障；
• 界面顯示速度的優化；

務必注意：吃透源碼，不知足的時候才能盡情修改。

四、總結

本文總結Weex開發的鏈路，關於Weex的使用、源碼分析、架構設計、優劣等能夠參考以前的系列文章。

歡迎關注微信公衆號：按期分享Java、Android乾貨！