大主線

細(xì)說移動(dòng)開發(fā)歷程

大技術(shù)

組件化開發(fā)

• 組件路由
• 組件配置動(dòng)態(tài)加載
• 組件骨架架構(gòu)

插件化開發(fā)

• 靜態(tài)插件化
• 動(dòng)態(tài)插件化

細(xì)節(jié)雕琢

• 網(wǎng)絡(luò)層的優(yōu)化和架構(gòu)
• 動(dòng)態(tài)埋點(diǎn)的實(shí)現(xiàn)
• 技術(shù)層架構(gòu)(MVP，MVVM等模式)

前言

你可能的收獲：

• 理解整個(gè)公司移動(dòng)開發(fā)的基線和主線
• 學(xué)會(huì)移動(dòng)開發(fā)組開發(fā)過程碰到問題和解決方案
• 學(xué)會(huì)移動(dòng)開發(fā)過程各個(gè)技術(shù)的細(xì)枝末葉
• 希望能給讀者開發(fā)項(xiàng)目有點(diǎn)啟發(fā)和思索

正文

我理解的技術(shù)開發(fā)人員，除了業(yè)務(wù)和技術(shù)的熱愛，其同時(shí)也需具備獨(dú)立思考的能力。

在這個(gè)高速變換的二次元移動(dòng)開發(fā)時(shí)代，很多產(chǎn)品和公司應(yīng)付追趕日新月異之變化都是爭分奪秒攻城略地，伴隨而來的移動(dòng)研發(fā)也是進(jìn)隨著'敲鑼打鼓開天辟地'。

所以我們有必要分析和思索當(dāng)下移動(dòng)開發(fā)的周期，就個(gè)人理解則把移動(dòng)開發(fā)生命周期分四大周期，這個(gè)四個(gè)周期同步伴隨著公司發(fā)展整個(gè)過程。

這個(gè)四個(gè)生命周期分別命名為：

• 1.成長期
• 2.混沌期
• 3.統(tǒng)一期
• 4.分化期
• 成長期一般在公司的第1~2年;
• 混沌期一般在公司的第2~3年;

統(tǒng)一和分化期在公司第3年以后;其中統(tǒng)一和分化期有可能多次迭代進(jìn)行。

所謂的成長期，也就是傳說中的野蠻發(fā)展，此時(shí)公司主導(dǎo)方向快速迭代跟進(jìn)市場，作為研發(fā)里程以及人員數(shù)目這塊都是從無到有的過程，其宗旨也是開發(fā)追趕產(chǎn)品實(shí)現(xiàn)快速上線過程。

此時(shí)開發(fā)技術(shù)選型都是以個(gè)人因素為走向，因此前期項(xiàng)目選型和架構(gòu)都是個(gè)人技術(shù)喜愛占主導(dǎo)，自己熟悉的技術(shù)和框架才是最快最有效的，可以快速追趕上線進(jìn)度。

譬如喜歡rxjava,喜歡mvp模式很快就會(huì)在這個(gè)項(xiàng)目就起主導(dǎo)方案和技術(shù)架構(gòu).甚至有些開發(fā)同仁直接從網(wǎng)上所謂架構(gòu)好的現(xiàn)成項(xiàng)目開干懟。

此時(shí)段公司的唯一宗旨就是首戰(zhàn)市場產(chǎn)出產(chǎn)品，快速迭代占據(jù)每個(gè)開發(fā)人員的腦海中，細(xì)節(jié)等一切可以忽略，要啥自行車。

接下來，隨著公司業(yè)績第一槍打響，同時(shí)融資也下來了，開始招兵買馬大干一場，人員補(bǔ)給上來，開始出現(xiàn)混亂和磨合期，新來人員覺得老代碼就是一坨翔，各種心底鄙視和不爽;

老員工覺得新員工桀驁不馴啥都不懂喜歡裝逼。但是公司補(bǔ)給人員的目的是更加快速迭代項(xiàng)目，公司還動(dòng)不動(dòng)搞個(gè)什么敏捷開發(fā)鬼模式實(shí)現(xiàn)1~2周迭代一個(gè)版本(就喜歡搞事)。

需求繼續(xù)開展代碼還得迭代而新老開發(fā)人員依葫蘆畫瓢編寫代碼，慢慢的(可以N個(gè))，慢慢的過段時(shí)間發(fā)現(xiàn)代碼充斥各種耦合，不規(guī)范代碼，文件包混亂，業(yè)務(wù)各種穿插，

一句話混亂的一鍋粥，各種線上bug突突的冒出來;線上bug一統(tǒng)計(jì)，fuck指標(biāo)超過5-10%，開始全組上下靜心反思，產(chǎn)生出版本重構(gòu)迭代統(tǒng)一思想。

項(xiàng)目重構(gòu)功能改善等統(tǒng)一口號(hào)就出現(xiàn)了，此時(shí)一般分兩波人馬，一撥人馬繼續(xù)業(yè)務(wù)迭代而另外一波人馬進(jìn)行項(xiàng)目重構(gòu);此事的核心就是減少線上bug數(shù)的量級(jí)，

完成公司要求線上bug不能超過3%的指標(biāo)，這個(gè)時(shí)候重構(gòu)重點(diǎn)基于線上bug進(jìn)行維度分析，通過問題按多少進(jìn)行劃分，差不多這個(gè)時(shí)候的問題如下：

1. Bug的可視化實(shí)時(shí)監(jiān)控和統(tǒng)計(jì);
2. 引用內(nèi)存未釋放導(dǎo)致crash的bug;
3. 內(nèi)存泄漏導(dǎo)致crash的bug;
4. 進(jìn)入市場機(jī)型問題引起的bug;
5. 網(wǎng)絡(luò)訪問慢的反饋;
6. 奇葩未知的bug;
7. 。。。

• 問題1的思考，引入第三方系統(tǒng)，例如bugly等
• 問題2的思考，引入Eventbus解決回調(diào)地獄問題和回調(diào)引起泄漏未釋放問題;
• 問題3的思考，引進(jìn)LeakCanary內(nèi)存泄漏檢測，和prof分析大法根據(jù)各個(gè)問題進(jìn)行突破;
• 問題4的思考，無解，能解決一個(gè)是一個(gè)，主要公司機(jī)型跟不上，可以通過網(wǎng)上機(jī)型提供商進(jìn)行問題測試，貴不說而且感覺沒啥用;
• 問題5的思考，略;

關(guān)于公司指定的線上bug指標(biāo)，是否完成也是需要多版本迭代現(xiàn)網(wǎng)運(yùn)行后才能統(tǒng)計(jì);既然是現(xiàn)網(wǎng)bug就有輕重之分，如果重大bug一般立即發(fā)布新版本更新，輕微的bug放到下一個(gè)版本迭代修復(fù)，那有沒有現(xiàn)網(wǎng)bug熱修復(fù)方案，肯定有的，成熟的有tinker等第三方庫;

雖然以上問題加班加點(diǎn)的搞完后，但是隨著公司業(yè)務(wù)的發(fā)展和市場的強(qiáng)大推廣，多個(gè)業(yè)務(wù)線如雨后春筍一般立項(xiàng)開干，看著當(dāng)前項(xiàng)目架構(gòu)模式(如圖一) 

長嘆一聲，埋在心頭的那個(gè)一個(gè)極大隱患和不安慢慢露出來，項(xiàng)目中依舊充斥代碼各種耦合和混亂，加上‘混亂代碼加上新代碼依舊還是混亂代碼’定理一直壓著頭頂上，這項(xiàng)目框架肯定無法跟上公司新業(yè)務(wù)線的發(fā)展和規(guī)劃;有壓力就有動(dòng)力，深思熟慮后不知覺分層分模塊架構(gòu)慢慢浮現(xiàn)出來，每個(gè)業(yè)務(wù)線都是一個(gè)Module模塊，接下來每來一個(gè)業(yè)務(wù)線就按照這模塊模樣復(fù)制粘貼一份接著開懟業(yè)務(wù)。一般這種情況需要持續(xù)到三個(gè)業(yè)務(wù)線后基本就會(huì)出現(xiàn)模塊間混亂調(diào)用，資源文件各種重復(fù)且代碼到處飛，加上權(quán)限控制不到從而每個(gè)人都有權(quán)限編寫基礎(chǔ)庫從而使各個(gè)業(yè)務(wù)公共代碼下沉到基礎(chǔ)庫導(dǎo)致龐大臃腫，多模塊混合編譯速度極度慢等不良問題一大堆冒出來，回過頭看看項(xiàng)目現(xiàn)狀，我去，又來了，忙不完的事?？纯磮D二如果你把自己當(dāng)處女座，你肯定會(huì)發(fā)狂，要么炒老板魷魚要么靜下心思考分析。

分析后得出以下幾個(gè)急需解決的問題，

• 模塊間的調(diào)用進(jìn)行解耦合實(shí)現(xiàn)模塊熱拔式方案
• 是時(shí)候加上代碼權(quán)限管理
• 模塊打包AAR實(shí)現(xiàn)模塊間引入
• 解決編譯速度慢問題
• 自動(dòng)化打包問題
• 。。。。

問題1的思考，既然實(shí)現(xiàn)解耦合同時(shí)實(shí)現(xiàn)熱拔式方案，說白點(diǎn)就是當(dāng)前模塊開關(guān)關(guān)閉，被其他引用的模塊無法感知到這個(gè)模塊被關(guān)閉，即其他模塊引用的代碼必須不能硬編碼此模塊的方法和引用類等等，方案就是組件路由，調(diào)用方通過字符串path查詢模塊的服務(wù)和功能。

問題2的思考，代碼權(quán)限管理一般通過git或者svn去實(shí)現(xiàn)。

問題3的思考，可以通過gradle腳本實(shí)現(xiàn)模塊打包上傳私服。

問題4的思考，gradle本身問題加上模塊多導(dǎo)致編譯速度慢，根據(jù)業(yè)務(wù)線的獨(dú)立性那我們可以通過編寫業(yè)務(wù)模塊時(shí)給此模塊實(shí)現(xiàn)App模式，減少其他不必要的代碼編譯和運(yùn)行。實(shí)現(xiàn)方案大體如下：

在模塊gradle編譯腳本通過標(biāo)識(shí)符來區(qū)分是模塊還是可獨(dú)立運(yùn)行的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']  
            }  
        } } 

這樣我們需要單獨(dú)運(yùn)行此模塊,在gradle.properies把FINANCE_IS_APPLICATION為true然后編譯就可以實(shí)現(xiàn)業(yè)務(wù)代碼編寫和運(yùn)行。有人問，如果我需要實(shí)現(xiàn)主App里面的新業(yè)務(wù)，那你可以關(guān)閉其他無關(guān)的模塊實(shí)現(xiàn)快速編譯提高開發(fā)效率。

問題5的思考，隨著項(xiàng)目的增大和多渠道的打包，此時(shí)需要進(jìn)行考慮項(xiàng)目周邊的業(yè)務(wù)服務(wù)，例如提供給測試人員的打包測試，正式版的發(fā)布等等自動(dòng)化產(chǎn)出問題。

一般自動(dòng)化服務(wù)可以通過搭建jenkins服務(wù)，或者配合python腳本實(shí)現(xiàn)自動(dòng)化打包功能，其

腳本的功能因公司而異。 

所以此時(shí)迫切需要一個(gè)熟悉gradle，python等腳本的同志(gradle本身是grovvy語言)。保證新業(yè)務(wù)的開發(fā)的情況下整個(gè)過程的重構(gòu)和完善至少需要半年時(shí)間(大公司除外)。

慢慢發(fā)現(xiàn)，組件化架構(gòu)無聲無息的出現(xiàn)了，是不是很神奇。

回過頭發(fā)現(xiàn)組件化架構(gòu)已經(jīng)進(jìn)行了一小部分，信心十足，繼續(xù)干，此時(shí)必須祭出毛爺爺?shù)募t本子，大聲的朗讀出來，我愛編程，皮膚好好!!

我們發(fā)現(xiàn)已經(jīng)做了業(yè)務(wù)模塊化代碼分離和模塊間路由互調(diào)通信以及gradle組件化腳本;

你的成長是建立在公司的成長上，隨著公司業(yè)務(wù)發(fā)展龐大，種種緣由業(yè)務(wù)伴隨著也會(huì)出現(xiàn)分支獨(dú)立，需要某些子業(yè)務(wù)線獨(dú)立出App提供專業(yè)的服務(wù)和體驗(yàn);需要撒播種子開花結(jié)果，原先的子模塊可能變成獨(dú)立App，所以發(fā)現(xiàn)目前的架構(gòu)是沒法實(shí)現(xiàn)，對(duì)，走過來，請(qǐng)?jiān)谄刑針湎滤伎?其根本緣由就是組件化不完全導(dǎo)致的。其中最大問題就是主項(xiàng)目模塊涉及到大量的以前最早的業(yè)務(wù)代碼和功能，現(xiàn)在最迫切問題是需要把主項(xiàng)目的業(yè)務(wù)剝離變成一個(gè)業(yè)務(wù)子模塊加一個(gè)純粹的項(xiàng)目骨架，其中項(xiàng)目骨架必須上升一級(jí)變成新的主項(xiàng)目模塊，此主項(xiàng)目模塊包含項(xiàng)目公共業(yè)務(wù)。說白點(diǎn)，把項(xiàng)目骨架套在其他子模塊就是一個(gè)獨(dú)立的App可以運(yùn)行;

作為對(duì)比，圖四為原架構(gòu)圖，圖五為主項(xiàng)目模塊上升一級(jí)為項(xiàng)目骨架的架構(gòu)圖

其中主項(xiàng)目骨架必須包含的功能有：

1. 項(xiàng)目升級(jí)降級(jí)功能;
2. 第三方庫的引用和初始化工作;
3. 實(shí)現(xiàn)子模塊加載和引入以及初始化工作;
4. 周邊服務(wù)或插件的引入和初始化工作;例如Tinker和bugly等
5. 。。。 

這個(gè)時(shí)候組件化大體已經(jīng)完整成型，現(xiàn)在唯一需要做的就是通過gradle腳本去做粘合器，腳本配合jenkins動(dòng)態(tài)實(shí)現(xiàn)模塊間和主項(xiàng)目骨架的組合;

上面說的組件化成型是主體骨架完整了，但是需要根據(jù)自己的公司業(yè)務(wù)繼續(xù)進(jìn)一步解耦和分離，一般如：

1. 全局配置文件的分離，實(shí)現(xiàn)配置文件根據(jù)子模塊業(yè)務(wù)走，例如網(wǎng)絡(luò)地址的配置和網(wǎng)絡(luò)請(qǐng)求地址的分離;
2. 業(yè)務(wù)配置文件的分離，配合服務(wù)端一起實(shí)現(xiàn)模塊化分離;
3. 各個(gè)子模塊的公共業(yè)務(wù)動(dòng)態(tài)加載塊;
4. 耦合代碼的分離和重構(gòu);
5. 。。。

此過程應(yīng)該做到了項(xiàng)目模塊以及代碼的各種解耦和分離，看起來非常清爽和干凈。不知覺又開始唱起了：我愛編程，皮膚好好!!

突然有一天你聽到有人說插件化，你心里暗暗一笑，我們項(xiàng)目早就實(shí)現(xiàn)了熱拔式插件化;

一討論發(fā)現(xiàn)原來不是你想的插件化，他們說的插件化是把業(yè)務(wù)模塊動(dòng)態(tài)存放到網(wǎng)上，需要的時(shí)候加載進(jìn)來;

哇咔咔，原來插件化分兩種，一直靜態(tài)插件化和動(dòng)態(tài)插件化;

不知覺的發(fā)現(xiàn)我們已經(jīng)實(shí)現(xiàn)了靜態(tài)插件化功能，細(xì)水長流說的就是這個(gè)，哦，應(yīng)該是水到渠成;

動(dòng)態(tài)插件化的前提必須是項(xiàng)目已經(jīng)具備成型的組件化后才能實(shí)現(xiàn)動(dòng)態(tài)插件化功能。

目前已經(jīng)可以獨(dú)立出各個(gè)子模塊打包成AAR、JAR、APK;接下來就是需要在主項(xiàng)目骨架上添加一項(xiàng)動(dòng)態(tài)插件化功能;完美

現(xiàn)在動(dòng)態(tài)插件化市面上有很多成熟的方案，因?yàn)檫@個(gè)不像組件化過程，組件化其實(shí)本身和業(yè)務(wù)和項(xiàng)目有很大關(guān)聯(lián)，需要根據(jù)自己的業(yè)務(wù)以及已有的業(yè)務(wù)框架進(jìn)行加工和架構(gòu)實(shí)現(xiàn);而

動(dòng)態(tài)插件化實(shí)現(xiàn)機(jī)制和業(yè)務(wù)體系和自身架構(gòu)無關(guān)系，可以大膽的引入第三方成熟的插件;例如美團(tuán)公司，阿里公司的動(dòng)態(tài)插件化。

其實(shí)，回味下整個(gè)過程，發(fā)現(xiàn)這些都是一步步的走下去的，不可能一步到位，這才人生;

有人問是不是接下來高枕無憂，哈哈，too x too native， 這才是萬里長征前幾步而已，接下來需要細(xì)節(jié)上和技術(shù)上進(jìn)一步雕琢，周邊服務(wù)的完善和安全等配套實(shí)施都需要等你去實(shí)現(xiàn);路遙茫茫。。。

細(xì)節(jié)上雕琢隨便列舉幾個(gè)：

1. 例如上面提到的bug中出現(xiàn)網(wǎng)絡(luò)性能慢，這個(gè)就可以深入挖掘各個(gè)實(shí)現(xiàn)，例如騰訊就這個(gè)小點(diǎn)實(shí)現(xiàn)了Mars開源框架;
2. 業(yè)務(wù)UI框架的封裝(減少重復(fù)開發(fā)以及性能問題);
3. 性能監(jiān)控;
4. 配置管理中心;
5. 動(dòng)態(tài)埋點(diǎn);
6. 各個(gè)業(yè)務(wù)核心點(diǎn)的優(yōu)化;
7. 編寫的組件化的重構(gòu)和優(yōu)化;
8. 技術(shù)層架構(gòu)(MVP，MVVM等模式)
9. 分布式架構(gòu);
10. 。。。。

最終你會(huì)發(fā)現(xiàn)，很多功能只有在你組件化結(jié)束后或者插件化結(jié)束后再去實(shí)施會(huì)達(dá)到事半功倍效果，實(shí)現(xiàn)集中優(yōu)化改動(dòng)分布最小化，極大減少改動(dòng)的風(fēng)險(xiǎn)和bug風(fēng)險(xiǎn);

以上過程其實(shí)是一個(gè)分久必合合久必分的過程。當(dāng)項(xiàng)目走向做到極致的時(shí)候還是沒法應(yīng)付龐大用戶群和業(yè)務(wù)群，請(qǐng)轉(zhuǎn)行養(yǎng)豬。。。

插件化路由實(shí)現(xiàn)，源碼詳見，覺得好請(qǐng)點(diǎn)擊star：

https://github.com/wenzhonghu/MyRouter