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