戲說移動江湖開發歷程
大主線
細說移動開發歷程
大技術
組件化開發
- 組件路由
- 組件配置動態加載
- 組件骨架架構
插件化開發
- 靜態插件化
- 動態插件化
細節雕琢
- 網絡層的優化和架構
- 動態埋點的實現
- 技術層架構(MVP，MVVM等模式)
前言
你可能的收獲：
- 理解整個公司移動開發的基線和主線
- 學會移動開發組開發過程碰到問題和解決方案
- 學會移動開發過程各個技術的細枝末葉
- 希望能給讀者開發項目有點啟發和思索
正文
我理解的技術開發人員，除了業務和技術的熱愛，其同時也需具備獨立思考的能力。
在這個高速變換的二次元移動開發時代，很多產品和公司應付追趕日新月異之變化都是爭分奪秒攻城略地，伴隨而來的移動研發也是進隨著'敲鑼打鼓開天辟地'。
所以我們有必要分析和思索當下移動開發的周期，就個人理解則把移動開發生命周期分四大周期，這個四個周期同步伴隨著公司發展整個過程。
這個四個生命周期分別命名為：
- 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模塊，接下來每來一個業務線就按照這模塊模樣復制粘貼一份接著開懟業務。一般這種情況需要持續到三個業務線后基本就會出現模塊間混亂調用，資源文件各種重復且代碼到處飛，加上權限控制不到從而每個人都有權限編寫基礎庫從而使各個業務公共代碼下沉到基礎庫導致龐大臃腫，多模塊混合編譯速度極度慢等不良問題一大堆冒出來，回過頭看看項目現狀，我去，又來了，忙不完的事。看看圖二如果你把自己當處女座，你肯定會發狂，要么炒老板魷魚要么靜下心思考分析。
分析后得出以下幾個急需解決的問題，
- 模塊間的調用進行解耦合實現模塊熱拔式方案
- 是時候加上代碼權限管理
- 模塊打包AAR實現模塊間引入
- 解決編譯速度慢問題
- 自動化打包問題
- 。。。。
問題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動態實現模塊間和主項目骨架的組合;
上面說的組件化成型是主體骨架完整了，但是需要根據自己的公司業務繼續進一步解耦和分離，一般如：
- 全局配置文件的分離，實現配置文件根據子模塊業務走，例如網絡地址的配置和網絡請求地址的分離;
- 業務配置文件的分離，配合服務端一起實現模塊化分離;
- 各個子模塊的公共業務動態加載塊;
- 耦合代碼的分離和重構;
- 。。。
此過程應該做到了項目模塊以及代碼的各種解耦和分離，看起來非常清爽和干凈。不知覺又開始唱起了：我愛編程，皮膚好好!!
突然有一天你聽到有人說插件化，你心里暗暗一笑，我們項目早就實現了熱拔式插件化;
一討論發現原來不是你想的插件化，他們說的插件化是把業務模塊動態存放到網上，需要的時候加載進來;
哇咔咔，原來插件化分兩種，一直靜態插件化和動態插件化;
不知覺的發現我們已經實現了靜態插件化功能，細水長流說的就是這個，哦，應該是水到渠成;
動態插件化的前提必須是項目已經具備成型的組件化后才能實現動態插件化功能。
目前已經可以獨立出各個子模塊打包成AAR、JAR、APK;接下來就是需要在主項目骨架上添加一項動態插件化功能;完美
現在動態插件化市面上有很多成熟的方案，因為這個不像組件化過程，組件化其實本身和業務和項目有很大關聯，需要根據自己的業務以及已有的業務框架進行加工和架構實現;而
動態插件化實現機制和業務體系和自身架構無關系，可以大膽的引入第三方成熟的插件;例如美團公司，阿里公司的動態插件化。
其實，回味下整個過程，發現這些都是一步步的走下去的，不可能一步到位，這才人生;
有人問是不是接下來高枕無憂，哈哈，too x too native， 這才是萬里長征前幾步而已，接下來需要細節上和技術上進一步雕琢，周邊服務的完善和安全等配套實施都需要等你去實現;路遙茫茫。。。
細節上雕琢隨便列舉幾個：
- 例如上面提到的bug中出現網絡性能慢，這個就可以深入挖掘各個實現，例如騰訊就這個小點實現了Mars開源框架;
- 業務UI框架的封裝(減少重復開發以及性能問題);
- 性能監控;
- 配置管理中心;
- 動態埋點;
- 各個業務核心點的優化;
- 編寫的組件化的重構和優化;
- 技術層架構(MVP，MVVM等模式)
- 分布式架構;
- 。。。。
最終你會發現，很多功能只有在你組件化結束后或者插件化結束后再去實施會達到事半功倍效果，實現集中優化改動分布最小化，極大減少改動的風險和bug風險;
以上過程其實是一個分久必合合久必分的過程。當項目走向做到極致的時候還是沒法應付龐大用戶群和業務群，請轉行養豬。。。
插件化路由實現，源碼詳見，覺得好請點擊star：
https://github.com/wenzhonghu/MyRouter
