源 / 頂級程序員        文/ 

---

在開發(fā)世界里，永遠是技術(shù)至上，一門新技術(shù)的盛行總是有原因的，要么比老框架性能提升不少，要不更加易用等等。作為一個追求上進的開發(fā)者，就是要不斷學(xué)習(xí)，嘗試各種新技術(shù)。

APP自身在飛速發(fā)展，發(fā)展有兩個方向：

1）死亡，我們的團隊被優(yōu)化；

2）版本不斷迭代，新功能不斷增加，業(yè)務(wù)模塊數(shù)量不斷增加，業(yè)務(wù)上的處理邏輯越變越復(fù)雜，同時每個模塊代碼也變得越來越多。對于app的不斷壯大，這將引發(fā)一個問題，所維護的代碼成本越來越高，稍微一改動可能就牽一發(fā)而動全身，改個小的功能點就需要回歸整個APP測試，這就對開發(fā)和維護帶來很大的挑戰(zhàn)，更有甚者：一個app里面同質(zhì)的SDK大量集成，最典型的就是網(wǎng)絡(luò)SDK，一個App里面同時包含了Volley，Okhttp，Retrofit，其實，我們不想這樣啊，我們是沒辦法才這樣做的，因為，我們的app架構(gòu)太混亂了，不敢動哦，有木有？

明明只改了一行代碼啊…

事實上以下才是根本問題：

1. 代碼量膨脹，不利于維護，不利于新功能的開發(fā)。項目工程構(gòu)建速度慢，在一些電腦上寫兩句代碼，重新編譯整個項目，測試的話編譯速度起碼5~10分鐘，有的甚至更長，Gradle老是和我們過不去。

2. 不同模塊之間代碼耦合嚴重，有時候修改一處代碼而牽動許多模塊，更不用說切換SDK了。每個模塊之間都有引用第三方庫，但有些第三方庫版本不一致，導(dǎo)致打包APP時候代碼冗余，容易引起版本沖突。

3. 現(xiàn)有項目基于他人項目基礎(chǔ)上開發(fā)，經(jīng)手的人次過多，存在著不同的代碼風(fēng)格，項目中代碼規(guī)范亂，類似的功能寫法卻不一樣，導(dǎo)致不統(tǒng)一，然后我卻不敢動手推翻重來。

app重構(gòu)后，系統(tǒng)更穩(wěn)健了

如果之前app的架構(gòu)無法滿足現(xiàn)有的業(yè)務(wù)需求，我們該如何優(yōu)雅地重構(gòu)App呢？

從工作到現(xiàn)在，經(jīng)歷過了MVC、MVP、MVVM等，每個App由于項目特點和需求的不同，都會出現(xiàn)一套基于開發(fā)者所設(shè)計的架構(gòu)模式，分層、組件化、模塊化，每一種設(shè)計都是基于項目所在場景的，很難適合所有項目場景。

App 業(yè)務(wù)規(guī)模擴大，隨之而來的是團隊規(guī)模擴大，那就涉及到多人協(xié)作問題，每個移動端軟件開發(fā)人員勢必要熟悉如此之多代碼，如果不按照一定的模塊組件機制去劃分，將很難進行多人協(xié)作開發(fā)；隨著單一項目變大，而且Andorid項目在編譯代碼方面就會變得非常緩慢，在單一工程代碼耦合嚴重，每修改一處代碼后都需要重新編譯打包測試，非常耗時。

模塊化、層次化、控件化、組件化怎么應(yīng)用到實踐當(dāng)中？Artifactory對模塊化和組件化大有幫助；Jetpack可以有效減少OOM和No Pointer Exception；Mvvm則可以滿足需求的變化。也許單個的技術(shù)點你了解過，我們又該怎樣將Artifactory、最新的Jetpack和Mvvm結(jié)合呢？另外，如何在搭建app架構(gòu)的同時，進行App啟動速度的性能優(yōu)化呢？

---

— 完 —

一鍵三連「分享」、「點贊」和「在看」

技術(shù)干貨與你天天見~