戲說移動江湖開發歷程

大主線

細說移動開發歷程

大技術

組件化開發

一、組件路由

二、組件配置動態加載

三、組件骨架架構

插件化開發

一、靜態插件化

二、動態插件化

細節雕琢

一、網絡層的優化和架構*

二、動態埋點的實現*

三、技術層架構（MVP，MVVM等模式）

大天地

後續按照大技術塊各個技術點深刻淺出的分享出來，請訂閱關注。

前言

本文閱讀須要8分鐘。

你可能的收穫：

* 理解整個公司移動開發的基線和主線

* 學會移動開發組開發過程碰到問題和解決方案

*  學會移動開發過程各個技術的細枝末葉

*  但願能給讀者開發項目有點啓發和思索

正文

我理解的技術開發人員，除了業務和技術的熱愛，其同時也需具有獨立思考的能力。~~

在這個高速變換的二次元移動開發時代，不少產品和公司應付追趕突飛猛進之變化都是爭分奪秒攻城略地，伴隨而來的移動研發也是進隨着'敲鑼打鼓開天闢地'。

因此咱們有必要分析和思索當下移動開發的週期，就我的理解則把移動開發生命週期分四大週期，這個四個週期同步伴隨着公司發展整個過程。

這個四個生命週期分別命名爲：

1.成長期

2.混沌期

3.統一期

4.分化期

成長期通常在公司的第1~2年；

混沌期通常在公司的第2~3年；

統一和分化期在公司第3年之後；其中統一和分化期有可能屢次迭代進行。

所謂的成長期，也就是傳說中的野蠻發展，此時公司主導方向快速迭代跟進市場，做爲研發里程以及人員數目這塊都是從無到有的過程，其宗旨也是開發追趕產品實現快速上線過程。

此時開發技術選型都是以我的因素爲走向，所以前期項目選型和架構都是我的技術喜好佔主導，本身熟悉的技術和框架纔是最快最有效的，能夠快速追遇上線進度。

譬如喜歡rxjava,喜歡mvp模式很快就會在這個項目就起主導方案和技術架構.甚至有些開發同仁直接從網上所謂架構好的現成項目開幹懟。

此時段公司的惟一宗旨就是首戰市場產出產品，快速迭代佔據每一個開發人員的腦海中，細節等一切能夠忽略，要啥自行車。

接下來，隨着公司業績第一槍打響，同時融資也下來了，開始招兵買馬大幹一場，人員補給上來，開始出現混亂和磨合期，新來人員以爲老代碼就是一坨翔，各類心底鄙視和不爽；

老員工以爲新員工桀驁不馴啥都不懂喜歡裝逼。可是公司補給人員的目的是更加快速迭代項目，公司還動不動搞個什麼敏捷開發鬼模式實現1~2周迭代一個版本（就喜歡搞事）。

需求繼續開展代碼還得迭代而新老開發人員依葫蘆畫瓢編寫代碼，慢慢的（能夠N個），慢慢的過段時間發現代碼充斥各類耦合，不規範代碼，文件包混亂，業務各類穿插，

一句話混亂的一鍋粥，各類線上bug突突的冒出來；線上bug一統計，fuck指標超過5-10%，開始全組上下靜心反思，產生出版本重構迭代統一思想。

項目重構功能改善等統一口號就出現了，此時通常分兩波人馬，一撥人馬繼續業務迭代而另一波人馬進行項目重構；此事的核心就是減小線上bug數的量級，

完成公司要求線上bug不能超過3%的指標，這個時候重構重點基於線上bug進行維度分析，經過問題按多少進行劃分，差很少這個時候的問題以下：

一、Bug的可視化實時監控和統計；

二、引用內存未釋放致使crash的bug；

三、內存泄漏致使crash的bug；

四、進入市場機型問題引發的bug；

五、網絡訪問慢的反饋；

六、奇葩未知的bug；

問題1的思考，引入第三方系統，例如bugly等

問題2的思考，引入Eventbus解決回調地獄問題和回調引發泄漏未釋放問題；

問題3的思考，引進LeakCanary內存泄漏檢測，和prof分析大法根據各個問題進行突破；

問題4的思考，無解，能解決一個是一個，主要公司機型跟不上，能夠經過網上機型提供商進行問題測試，貴不說並且感受沒啥用；

問題5的思考，略；

關於公司指定的線上bug指標，是否完成也是須要多版本迭代現網運行後才能統計；既然是現網bug就有輕重之分，若是重大bug通常當即發佈新版本更新，輕微的bug放到下一個版本迭代修復，那有沒有現網bug熱修復方案，確定有的，成熟的有tinker等第三方庫；

雖然以上問題加班加點的搞完後，可是隨着公司業務的發展和市場的強大推廣，多個業務線如雨後春筍通常立項開幹，看着當前項目架構模式(如圖一)

圖（一）

長嘆一聲，埋在心頭的那個一個極大隱患和不安慢慢露出來，項目中依舊充斥代碼各類耦合和混亂，加上‘混亂代碼加上新代碼依舊仍是混亂代碼’定理一直壓着頭頂上，這項目框架確定沒法跟上公司新業務線的發展和規劃；有壓力就有動力，深思熟慮後不知覺分層分模塊架構慢慢浮現出來，每一個業務線都是一個Module模塊，接下來每來一個業務線就按照這模塊模樣複製粘貼一份接着開懟業務。通常這種狀況須要持續到三個業務線後基本就會出現模塊間混亂調用，資源文件各類重複且代碼處處飛，加上權限控制不到從而每一個人都有權限編寫基礎庫從而使各個業務公共代碼下沉到基礎庫致使龐大臃腫，多模塊混合編譯速度極度慢等不良問題一大堆冒出來，回過頭看看項目現狀，我去，又來了，忙不完的事。看看圖二（偷圖，侵圖刪）若是你把本身當處女座，你確定會發狂，要麼炒老闆魷魚要麼靜下心思考分析。

圖（二）

分析後得出如下幾個急需解決的問題，

1. 模塊間的調用進行解耦合實現模塊熱拔式方案

2. 是時候加上代碼權限管理

3. 模塊打包AAR實現模塊間引入

4. 解決編譯速度慢問題

5. 自動化打包問題

問題1的思考，既然實現解耦合同時實現熱拔式方案，說白點就是當前模塊開關關閉，被其餘引用的模塊沒法感知到這個模塊被關閉，即其餘模塊引用的代碼必須不能硬編碼此模塊的方法和引用類等等，方案就是組件路由，調用方經過字符串path查詢模塊的服務和功能。

問題2的思考，代碼權限管理通常經過git或者svn去實現。

問題3的思考，能夠經過gradle腳本實現模塊打包上傳私服。

問題4的思考，gradle自己問題加上模塊多致使編譯速度慢，根據業務線的獨立性那咱們能夠經過編寫業務模塊時給此模塊實現App模式，減小其餘沒必要要的代碼編譯和運行。實現方案大致以下：

在模塊gradle編譯腳本經過標識符來區分是模塊仍是可獨立運行的App

sourceSets {
 
         main {
 
             jniLibs.srcDirs = ['libs']
 
             if ("true".equals(FINANCE_IS_APPLICATION)) {
 
                 manifest.srcFile 'src/main/diff/appmodule/AndroidManifest.xml'
 
                 java.srcDirs = ['src/main/java', 'src/main/diff/appmodule/java']
 
                 res.srcDirs = ['src/main/res', 'src/main/diff/appmodule/res']
 
                 assets.srcDirs = ['src/main/assets', 'src/main/diff/appmodule/assets']
 
             } else {
 
                 manifest.srcFile 'src/main/diff/libmodule/AndroidManifest.xml'
 
                 java.srcDirs = ['src/main/java', 'src/main/diff/libmodule/java']
 
                 res.srcDirs = ['src/main/res', 'src/main/diff/libmodule/res']
 
                 assets.srcDirs = ['src/main/assets', 'src/main/diff/libmodule/assets']
 
             }
 
         }
  }
複製代碼

這樣咱們須要單獨運行此模塊,在gradle.properies把FINANCE_IS_APPLICATION爲true而後編譯就能夠實現業務代碼編寫和運行。有人問，若是我須要實現主App裏面的新業務，那你能夠關閉其餘無關的模塊實現快速編譯提升開發效率。

問題5的思考，隨着項目的增大和多渠道的打包，此時須要進行考慮項目周邊的業務服務，例如提供給測試人員的打包測試，正式版的發佈等等自動化產出問題。

通常自動化服務能夠經過搭建jenkins服務，或者配合python腳本實現自動化打包功能，其

腳本的功能因公司而異。

#####  圖（三）

因此此時迫切須要一個熟悉gradle，python等腳本的同志（gradle自己是grovvy語言）。保證新業務的開發的狀況下整個過程的重構和完善至少須要半年時間（大公司除外）。

慢慢發現，組件化架構無聲無息的出現了，是否是很神奇。

回過頭髮現組件化架構已經進行了一小部分，信心十足，繼續幹，此時必須祭出毛爺爺的紅本子，大聲的朗讀出來，我愛編程，皮膚好好！！

咱們發現已經作了業務模塊化代碼分離和模塊間路由互調通訊以及gradle組件化腳本；

你的成長是創建在公司的成長上，隨着公司業務發展龐大，種種原因業務伴隨着也會出現分支獨立，須要某些子業務線獨立出App提供專業的服務和體驗；須要撒播種子開花結果，原先的子模塊可能變成獨立App，因此發現目前的架構是無法實現，對，走過來，請在菩提樹下思考；其根本原因就是組件化不徹底致使的。其中最大問題就是主項目模塊涉及到大量的之前最先的業務代碼和功能，如今最迫切問題是須要把主項目的業務剝離變成一個業務子模塊加一個純粹的項目骨架，其中項目骨架必須上升一級變成新的主項目模塊，此主項目模塊包含項目公共業務。說白點，把項目骨架套在其餘子模塊就是一個獨立的App能夠運行；

做爲對比，圖四爲原架構圖，圖五爲主項目模塊上升一級爲項目骨架的架構圖

其中主項目骨架必須包含的功能有：

一、項目升級降級功能；

二、第三方庫的引用和初始化工做；

三、實現子模塊加載和引入以及初始化工做；

四、周邊服務或插件的引入和初始化工做；例如Tinker和bugly等

圖（四）

圖（五）

這個時候組件化大致已經完整成型，如今惟一須要作的就是經過gradle腳本去作粘合器，腳本配合jenkins動態實現模塊間和主項目骨架的組合；

上面說的組件化成型是主體骨架完整了，可是須要根據本身的公司業務繼續進一步解耦和分離，通常如：

1. 全局配置文件的分離，實現配置文件根據子模塊業務走，例如網絡地址的配置和網絡請求地址的分離；

2. 業務配置文件的分離，配合服務端一塊兒實現模塊化分離；

3. 各個子模塊的公共業務動態加載塊；

4. 耦合代碼的分離和重構；

此過程應該作到了項目模塊以及代碼的各類解耦和分離，看起來很是清爽和乾淨。不知覺又開始唱起了：我愛編程，皮膚好好！！

忽然有一天你聽到有人說插件化，你內心暗暗一笑，咱們項目早就實現了熱拔式插件化；

一討論發現原來不是你想的插件化，他們說的插件化是把業務模塊動態存放到網上，須要的時候加載進來；

哇咔咔，原來插件化分兩種，一直靜態插件化和動態插件化；

不知覺的發現咱們已經實現了靜態插件化功能，細水長流說的就是這個，哦，應該是水到渠成；

動態插件化的前提必須是項目已經具有成型的組件化後才能實現動態插件化功能。

目前已經能夠獨立出各個子模塊打包成AAR、JAR、APK；接下來就是須要在主項目骨架上添加一項動態插件化功能；完美

如今動態插件化市面上有不少成熟的方案，由於這個不像組件化過程，組件化其實自己和業務和項目有很大關聯，須要根據本身的業務以及已有的業務框架進行加工和架構實現；而

動態插件化實現機制和業務體系和自身架構無關係，能夠大膽的引入第三方成熟的插件；例如美團公司，阿里公司的動態插件化。

其實，回味下整個過程，發現這些都是一步步的走下去的，不可能一步到位，這才人生；

有人問是否是接下來高枕無憂，哈哈，too x too native， 這纔是萬里長征前幾步而已，接下來須要細節上和技術上進一步雕琢，周邊服務的完善和安全等配套實施都須要等你去實現；路遙茫茫。。。

細節上雕琢隨便列舉幾個：

一、例如上面提到的bug中出現網絡性能慢，這個就能夠深刻挖掘各個實現，例如騰訊就這個小點實現了Mars開源框架；

二、業務UI框架的封裝（減小重複開發以及性能問題）；

三、性能監控；

四、配置管理中心；

五、動態埋點；

六、各個業務核心點的優化；

七、編寫的組件化的重構和優化；

八、技術層架構（MVP，MVVM等模式）

九、分佈式架構；

最終你會發現，不少功能只有在你組件化結束後或者插件化結束後再去實施會達到事半功倍效果，實現集中優化改動分佈最小化，極大減小改動的風險和bug風險；

以上過程實際上是一個分久必合合久必分的過程。當項目走向作到極致的時候仍是無法應付龐大用戶羣和業務羣，請轉行養豬。。。

插件化路由實現，源碼詳見，以爲好請點擊star：個人路由

連接：https://www.jianshu.com/p/df2a6717009d,轉載請註明來源

閱讀更多

react-native技術的優劣

學習React Native必看的幾個開源項目

開發了幾個小程序後，說說我對小程序的見解

NDK項目實戰—高仿360手機助手之卸載監聽

（Android）面試題級答案（精選版）

若是有什麼 問題，歡迎和我交流 微信公衆號：終端研發部