戲說移動江湖開發(fā)歷程
大主線
細說移動開發(fā)歷程
大技術(shù)
組件化開發(fā)
- 組件路由
- 組件配置動態(tài)加載
- 組件骨架架構(gòu)
插件化開發(fā)
- 靜態(tài)插件化
- 動態(tài)插件化
細節(jié)雕琢
- 網(wǎng)絡(luò)層的優(yōu)化和架構(gòu)
- 動態(tài)埋點的實現(xiàn)
- 技術(shù)層架構(gòu)(MVP，MVVM等模式)
前言
你可能的收獲：
- 理解整個公司移動開發(fā)的基線和主線
- 學(xué)會移動開發(fā)組開發(fā)過程碰到問題和解決方案
- 學(xué)會移動開發(fā)過程各個技術(shù)的細枝末葉
- 希望能給讀者開發(fā)項目有點啟發(fā)和思索
正文
我理解的技術(shù)開發(fā)人員，除了業(yè)務(wù)和技術(shù)的熱愛，其同時也需具備獨立思考的能力。
在這個高速變換的二次元移動開發(fā)時代，很多產(chǎn)品和公司應(yīng)付追趕日新月異之變化都是爭分奪秒攻城略地，伴隨而來的移動研發(fā)也是進隨著'敲鑼打鼓開天辟地'。
所以我們有必要分析和思索當(dāng)下移動開發(fā)的周期，就個人理解則把移動開發(fā)生命周期分四大周期，這個四個周期同步伴隨著公司發(fā)展整個過程。
這個四個生命周期分別命名為：
- 1.成長期
- 2.混沌期
- 3.統(tǒng)一期
- 4.分化期
- 成長期一般在公司的第1~2年;
- 混沌期一般在公司的第2~3年;
統(tǒng)一和分化期在公司第3年以后;其中統(tǒng)一和分化期有可能多次迭代進行。
所謂的成長期，也就是傳說中的野蠻發(fā)展，此時公司主導(dǎo)方向快速迭代跟進市場，作為研發(fā)里程以及人員數(shù)目這塊都是從無到有的過程，其宗旨也是開發(fā)追趕產(chǎn)品實現(xiàn)快速上線過程。
此時開發(fā)技術(shù)選型都是以個人因素為走向，因此前期項目選型和架構(gòu)都是個人技術(shù)喜愛占主導(dǎo)，自己熟悉的技術(shù)和框架才是最快最有效的，可以快速追趕上線進度。
譬如喜歡rxjava,喜歡mvp模式很快就會在這個項目就起主導(dǎo)方案和技術(shù)架構(gòu).甚至有些開發(fā)同仁直接從網(wǎng)上所謂架構(gòu)好的現(xiàn)成項目開干懟。
此時段公司的唯一宗旨就是首戰(zhàn)市場產(chǎn)出產(chǎn)品，快速迭代占據(jù)每個開發(fā)人員的腦海中，細節(jié)等一切可以忽略，要啥自行車。
接下來，隨著公司業(yè)績第一槍打響，同時融資也下來了，開始招兵買馬大干一場，人員補給上來，開始出現(xiàn)混亂和磨合期，新來人員覺得老代碼就是一坨翔，各種心底鄙視和不爽;
老員工覺得新員工桀驁不馴啥都不懂喜歡裝逼。但是公司補給人員的目的是更加快速迭代項目，公司還動不動搞個什么敏捷開發(fā)鬼模式實現(xiàn)1~2周迭代一個版本(就喜歡搞事)。
需求繼續(xù)開展代碼還得迭代而新老開發(fā)人員依葫蘆畫瓢編寫代碼，慢慢的(可以N個)，慢慢的過段時間發(fā)現(xiàn)代碼充斥各種耦合，不規(guī)范代碼，文件包混亂，業(yè)務(wù)各種穿插，
一句話混亂的一鍋粥，各種線上bug突突的冒出來;線上bug一統(tǒng)計，fuck指標(biāo)超過5-10%，開始全組上下靜心反思，產(chǎn)生出版本重構(gòu)迭代統(tǒng)一思想。
項目重構(gòu)功能改善等統(tǒng)一口號就出現(xiàn)了，此時一般分兩波人馬，一撥人馬繼續(xù)業(yè)務(wù)迭代而另外一波人馬進行項目重構(gòu);此事的核心就是減少線上bug數(shù)的量級，
完成公司要求線上bug不能超過3%的指標(biāo)，這個時候重構(gòu)重點基于線上bug進行維度分析，通過問題按多少進行劃分，差不多這個時候的問題如下：
- Bug的可視化實時監(jiān)控和統(tǒng)計;
- 引用內(nèi)存未釋放導(dǎo)致crash的bug;
- 內(nèi)存泄漏導(dǎo)致crash的bug;
- 進入市場機型問題引起的bug;
- 網(wǎng)絡(luò)訪問慢的反饋;
- 奇葩未知的bug;
- 。。。
- 問題1的思考，引入第三方系統(tǒng)，例如bugly等
- 問題2的思考，引入Eventbus解決回調(diào)地獄問題和回調(diào)引起泄漏未釋放問題;
- 問題3的思考，引進LeakCanary內(nèi)存泄漏檢測，和prof分析大法根據(jù)各個問題進行突破;
- 問題4的思考，無解，能解決一個是一個，主要公司機型跟不上，可以通過網(wǎng)上機型提供商進行問題測試，貴不說而且感覺沒啥用;
- 問題5的思考，略;
關(guān)于公司指定的線上bug指標(biāo)，是否完成也是需要多版本迭代現(xiàn)網(wǎng)運行后才能統(tǒng)計;既然是現(xiàn)網(wǎng)bug就有輕重之分，如果重大bug一般立即發(fā)布新版本更新，輕微的bug放到下一個版本迭代修復(fù)，那有沒有現(xiàn)網(wǎng)bug熱修復(fù)方案，肯定有的，成熟的有tinker等第三方庫;
雖然以上問題加班加點的搞完后，但是隨著公司業(yè)務(wù)的發(fā)展和市場的強大推廣，多個業(yè)務(wù)線如雨后春筍一般立項開干，看著當(dāng)前項目架構(gòu)模式(如圖一)
長嘆一聲，埋在心頭的那個一個極大隱患和不安慢慢露出來，項目中依舊充斥代碼各種耦合和混亂，加上‘混亂代碼加上新代碼依舊還是混亂代碼’定理一直壓著頭頂上，這項目框架肯定無法跟上公司新業(yè)務(wù)線的發(fā)展和規(guī)劃;有壓力就有動力，深思熟慮后不知覺分層分模塊架構(gòu)慢慢浮現(xiàn)出來，每個業(yè)務(wù)線都是一個Module模塊，接下來每來一個業(yè)務(wù)線就按照這模塊模樣復(fù)制粘貼一份接著開懟業(yè)務(wù)。一般這種情況需要持續(xù)到三個業(yè)務(wù)線后基本就會出現(xiàn)模塊間混亂調(diào)用，資源文件各種重復(fù)且代碼到處飛，加上權(quán)限控制不到從而每個人都有權(quán)限編寫基礎(chǔ)庫從而使各個業(yè)務(wù)公共代碼下沉到基礎(chǔ)庫導(dǎo)致龐大臃腫，多模塊混合編譯速度極度慢等不良問題一大堆冒出來，回過頭看看項目現(xiàn)狀，我去，又來了，忙不完的事?？纯磮D二如果你把自己當(dāng)處女座，你肯定會發(fā)狂，要么炒老板魷魚要么靜下心思考分析。
分析后得出以下幾個急需解決的問題，
- 模塊間的調(diào)用進行解耦合實現(xiàn)模塊熱拔式方案
- 是時候加上代碼權(quán)限管理
- 模塊打包AAR實現(xiàn)模塊間引入
- 解決編譯速度慢問題
- 自動化打包問題
- 。。。。
問題1的思考，既然實現(xiàn)解耦合同時實現(xiàn)熱拔式方案，說白點就是當(dāng)前模塊開關(guān)關(guān)閉，被其他引用的模塊無法感知到這個模塊被關(guān)閉，即其他模塊引用的代碼必須不能硬編碼此模塊的方法和引用類等等，方案就是組件路由，調(diào)用方通過字符串path查詢模塊的服務(wù)和功能。
問題2的思考，代碼權(quán)限管理一般通過git或者svn去實現(xiàn)。
問題3的思考，可以通過gradle腳本實現(xiàn)模塊打包上傳私服。
問題4的思考，gradle本身問題加上模塊多導(dǎo)致編譯速度慢，根據(jù)業(yè)務(wù)線的獨立性那我們可以通過編寫業(yè)務(wù)模塊時給此模塊實現(xiàn)App模式，減少其他不必要的代碼編譯和運行。實現(xiàn)方案大體如下：
在模塊gradle編譯腳本通過標(biāo)識符來區(qū)分是模塊還是可獨立運行的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然后編譯就可以實現(xiàn)業(yè)務(wù)代碼編寫和運行。有人問，如果我需要實現(xiàn)主App里面的新業(yè)務(wù)，那你可以關(guān)閉其他無關(guān)的模塊實現(xiàn)快速編譯提高開發(fā)效率。
問題5的思考，隨著項目的增大和多渠道的打包，此時需要進行考慮項目周邊的業(yè)務(wù)服務(wù)，例如提供給測試人員的打包測試，正式版的發(fā)布等等自動化產(chǎn)出問題。
一般自動化服務(wù)可以通過搭建jenkins服務(wù)，或者配合python腳本實現(xiàn)自動化打包功能，其
腳本的功能因公司而異。
所以此時迫切需要一個熟悉gradle，python等腳本的同志(gradle本身是grovvy語言)。保證新業(yè)務(wù)的開發(fā)的情況下整個過程的重構(gòu)和完善至少需要半年時間(大公司除外)。
慢慢發(fā)現(xiàn)，組件化架構(gòu)無聲無息的出現(xiàn)了，是不是很神奇。
回過頭發(fā)現(xiàn)組件化架構(gòu)已經(jīng)進行了一小部分，信心十足，繼續(xù)干，此時必須祭出毛爺爺?shù)募t本子，大聲的朗讀出來，我愛編程，皮膚好好!!
我們發(fā)現(xiàn)已經(jīng)做了業(yè)務(wù)模塊化代碼分離和模塊間路由互調(diào)通信以及gradle組件化腳本;
你的成長是建立在公司的成長上，隨著公司業(yè)務(wù)發(fā)展龐大，種種緣由業(yè)務(wù)伴隨著也會出現(xiàn)分支獨立，需要某些子業(yè)務(wù)線獨立出App提供專業(yè)的服務(wù)和體驗;需要撒播種子開花結(jié)果，原先的子模塊可能變成獨立App，所以發(fā)現(xiàn)目前的架構(gòu)是沒法實現(xiàn)，對，走過來，請在菩提樹下思考;其根本緣由就是組件化不完全導(dǎo)致的。其中最大問題就是主項目模塊涉及到大量的以前最早的業(yè)務(wù)代碼和功能，現(xiàn)在最迫切問題是需要把主項目的業(yè)務(wù)剝離變成一個業(yè)務(wù)子模塊加一個純粹的項目骨架，其中項目骨架必須上升一級變成新的主項目模塊，此主項目模塊包含項目公共業(yè)務(wù)。說白點，把項目骨架套在其他子模塊就是一個獨立的App可以運行;
作為對比，圖四為原架構(gòu)圖，圖五為主項目模塊上升一級為項目骨架的架構(gòu)圖
其中主項目骨架必須包含的功能有：
- 項目升級降級功能;
- 第三方庫的引用和初始化工作;
- 實現(xiàn)子模塊加載和引入以及初始化工作;
- 周邊服務(wù)或插件的引入和初始化工作;例如Tinker和bugly等
- 。。。
這個時候組件化大體已經(jīng)完整成型，現(xiàn)在唯一需要做的就是通過gradle腳本去做粘合器，腳本配合jenkins動態(tài)實現(xiàn)模塊間和主項目骨架的組合;
上面說的組件化成型是主體骨架完整了，但是需要根據(jù)自己的公司業(yè)務(wù)繼續(xù)進一步解耦和分離，一般如：
- 全局配置文件的分離，實現(xiàn)配置文件根據(jù)子模塊業(yè)務(wù)走，例如網(wǎng)絡(luò)地址的配置和網(wǎng)絡(luò)請求地址的分離;
- 業(yè)務(wù)配置文件的分離，配合服務(wù)端一起實現(xiàn)模塊化分離;
- 各個子模塊的公共業(yè)務(wù)動態(tài)加載塊;
- 耦合代碼的分離和重構(gòu);
- 。。。
此過程應(yīng)該做到了項目模塊以及代碼的各種解耦和分離，看起來非常清爽和干凈。不知覺又開始唱起了：我愛編程，皮膚好好!!
突然有一天你聽到有人說插件化，你心里暗暗一笑，我們項目早就實現(xiàn)了熱拔式插件化;
一討論發(fā)現(xiàn)原來不是你想的插件化，他們說的插件化是把業(yè)務(wù)模塊動態(tài)存放到網(wǎng)上，需要的時候加載進來;
哇咔咔，原來插件化分兩種，一直靜態(tài)插件化和動態(tài)插件化;
不知覺的發(fā)現(xiàn)我們已經(jīng)實現(xiàn)了靜態(tài)插件化功能，細水長流說的就是這個，哦，應(yīng)該是水到渠成;
動態(tài)插件化的前提必須是項目已經(jīng)具備成型的組件化后才能實現(xiàn)動態(tài)插件化功能。
目前已經(jīng)可以獨立出各個子模塊打包成AAR、JAR、APK;接下來就是需要在主項目骨架上添加一項動態(tài)插件化功能;完美
現(xiàn)在動態(tài)插件化市面上有很多成熟的方案，因為這個不像組件化過程，組件化其實本身和業(yè)務(wù)和項目有很大關(guān)聯(lián)，需要根據(jù)自己的業(yè)務(wù)以及已有的業(yè)務(wù)框架進行加工和架構(gòu)實現(xiàn);而
動態(tài)插件化實現(xiàn)機制和業(yè)務(wù)體系和自身架構(gòu)無關(guān)系，可以大膽的引入第三方成熟的插件;例如美團公司，阿里公司的動態(tài)插件化。
其實，回味下整個過程，發(fā)現(xiàn)這些都是一步步的走下去的，不可能一步到位，這才人生;
有人問是不是接下來高枕無憂，哈哈，too x too native， 這才是萬里長征前幾步而已，接下來需要細節(jié)上和技術(shù)上進一步雕琢，周邊服務(wù)的完善和安全等配套實施都需要等你去實現(xiàn);路遙茫茫。。。
細節(jié)上雕琢隨便列舉幾個：
- 例如上面提到的bug中出現(xiàn)網(wǎng)絡(luò)性能慢，這個就可以深入挖掘各個實現(xiàn)，例如騰訊就這個小點實現(xiàn)了Mars開源框架;
- 業(yè)務(wù)UI框架的封裝(減少重復(fù)開發(fā)以及性能問題);
- 性能監(jiān)控;
- 配置管理中心;
- 動態(tài)埋點;
- 各個業(yè)務(wù)核心點的優(yōu)化;
- 編寫的組件化的重構(gòu)和優(yōu)化;
- 技術(shù)層架構(gòu)(MVP，MVVM等模式)
- 分布式架構(gòu);
- 。。。。
最終你會發(fā)現(xiàn)，很多功能只有在你組件化結(jié)束后或者插件化結(jié)束后再去實施會達到事半功倍效果，實現(xiàn)集中優(yōu)化改動分布最小化，極大減少改動的風(fēng)險和bug風(fēng)險;
以上過程其實是一個分久必合合久必分的過程。當(dāng)項目走向做到極致的時候還是沒法應(yīng)付龐大用戶群和業(yè)務(wù)群，請轉(zhuǎn)行養(yǎng)豬。。。
插件化路由實現(xiàn)，源碼詳見，覺得好請點擊star：
https://github.com/wenzhonghu/MyRouter
