一、Android MVC、MVP以及MVVM框架模式

MVC開發(fā)框架

• View：對應(yīng)于布局文件和自定義View,負責將用戶的請求通知Controller，并根據(jù)model更新界面；
• Controller：對應(yīng)于Activity、Fragement,負責處理業(yè)務(wù)邏輯接收用戶請求并更新model；（而事實上我們的Activity同時承擔著MVC3種角色，代碼動不動就上千行！）
• Model：數(shù)據(jù)模型，負責數(shù)據(jù)處理相關(guān)的邏輯，封裝應(yīng)用程序狀態(tài)，響應(yīng)狀態(tài)查詢，通知View改變。

MVP開發(fā)框架

• View 對應(yīng)于Activity，負責View的繪制以及與用戶交互
• Model 依然是數(shù)據(jù)模型，負責數(shù)據(jù)處理相關(guān)的邏輯和實體模型
• Presenter 負責完成View于Model間的交互，處理業(yè)務(wù)邏輯

MVP框架的優(yōu)點： ①Model層和View層充分解耦。 ②復(fù)雜的任務(wù)被分成細小的任務(wù)，并且很容易解決。越小的東西，bug越少，越容易debug，更好測試。 ③在MVP模式下的View層將會變得簡單，簡單直觀。 ④后臺任務(wù)不再和Activity聯(lián)系在一起，這既不會導致內(nèi)存泄露(OOM)，也不依賴于Activity的重建。 ⑤Persnter層負責處理業(yè)務(wù)邏輯，這樣業(yè)務(wù)邏輯就被剝離了出來，不在擔心需求的不停變更，可以使開發(fā)者更專注解決問題。 ⑥可以直接單元測試Persenter層，以致于無需實現(xiàn)和View層和Model層。 MVP框架的缺點： 需要寫很多類，原本一個類可以完成的事，現(xiàn)在需要寫6個！

MVVM開發(fā)框架

• MVVM可以算是MVP的升級版，將 Presenter 改名為 ViewModel。關(guān)鍵在于ViewModel和Model的雙向綁定，當View有用戶輸入后，ViewModel通知Model更新數(shù)據(jù)，同理Model數(shù)據(jù)更新后，ViewModel通知View更新。
• MVVM的出現(xiàn)還是為了解決View層和Model層之間的解耦，實現(xiàn)了充分解耦。
• MVVM相比MVP，很大程度上解決了MVP的缺點
• Android Google在2015年提出的DataBinding Library技術(shù)，使得ViewModel和Model之間的雙向綁定更加容易。IOS上如果要實現(xiàn)類似功能，使用KVO也可實現(xiàn)。

MVVM框架的優(yōu)點 ①繼承了MVP框架的所有優(yōu)點 ②書寫更加方便，不必創(chuàng)建很多個類。使得視圖層，業(yè)務(wù)邏輯層，數(shù)據(jù)模型層，層次結(jié)構(gòu)更加清晰。 ③再Model層和View層充分解耦的同時，還實現(xiàn)了數(shù)據(jù)和視圖的雙向綁定，數(shù)據(jù)變化時，視圖自動更新。這個特性很有用，對于一些實時性較高的應(yīng)用來說無疑是最佳的解決方案。例如炒股的一些APP。 MVVM框架在Android工程上的實現(xiàn)的基本要求 ①開發(fā)工具目前只支持Android Stduio，很顯然eclipse已經(jīng)被Google淘汰。 ②Android Studio需要1.3版本以上 ③Gradle版本需要2.2以上版本 ④Android plugin for gradle 1.3.0及以上版本

二、Android組件化開發(fā)和插件化開發(fā)技術(shù)

Android組件化開發(fā)

1、什么是組件化開發(fā)？ 所謂組件化開發(fā)就單獨的業(yè)務(wù)模塊抽取出來。每一個模塊是一個module，正常一個App中可以有多個module，但是一般只會有一個module是設(shè)置為application的，其他均設(shè)置為library，組件化開發(fā)就是要每個module都可以運行起來，因此在開發(fā)期間每個module均設(shè)置為application，發(fā)布時再進行合并。 2、為什么要使用組件化開發(fā)？ ① Android項目中代碼量達到一定程度，編譯將是一件非常痛苦的事情，短則一兩分鐘，長則達到五六分鐘。組件化開發(fā)可以有效降低代碼模塊的耦合度，使代碼架構(gòu)更加清晰，同時模塊化的編譯可以有效減少編譯時間，當然總的編譯時間是不會減少的，只是App模塊化之后開發(fā)某個模塊時，只需要編譯特定模塊，可以快速編譯調(diào)試。 ②組件化實現(xiàn)了業(yè)務(wù)的解耦和重用。

組件化開發(fā)模式的演變

（1） 單工程開發(fā)模式

該種開發(fā)模型已經(jīng)有了明確的模塊劃分,并且通過邏輯上的分層呈現(xiàn)出較好結(jié)構(gòu),該模型最為我們所熟悉,通常用于早期產(chǎn)品的快速開發(fā),團隊規(guī)模較小的情況下，隨著產(chǎn)品的迭代,業(yè)務(wù)越來越復(fù)雜,隨之帶來的是項目結(jié)構(gòu)復(fù)雜度的極度增加,此時我們面臨著幾個問題:

• 實際業(yè)務(wù)變化非常快但是工程之前的業(yè)務(wù)模塊耦合度太高,牽一發(fā)而動全身.
• 對工程所做的任何修改都必須要編譯整個工程
• 功能測試和系統(tǒng)測試每次都要進行.
• 團隊協(xié)同開發(fā)存在較多的沖突.不得不花費更多的時間去溝通和協(xié)調(diào),并且在開發(fā)過程中,任何一位成員沒辦法專注于自己的功能點,影響開發(fā)效率.
• 不能靈活的對工程進行配置和組裝.比如今天產(chǎn)品經(jīng)理說加上這個功能,明天又說去掉,后天在加上.

（2）主工程多組件開發(fā)模型 在"單工程"模型的基礎(chǔ)上,將業(yè)務(wù)層中的各業(yè)務(wù)抽取出來,封裝成相應(yīng)的業(yè)務(wù)組件,將基礎(chǔ)庫中各部分抽取出來,封裝成基礎(chǔ)組件,而主工程是一個可運行的app,作為各組件的入口(主工程也被稱之為殼程序).這些組件或以jar的形式呈現(xiàn),或以aar的形式呈現(xiàn).主工程通過依賴的方式使用組件所提供的功能.

優(yōu)點： ①每個成員可以專注自己所負責的業(yè)務(wù),并不影響其他業(yè)務(wù),同時借助穩(wěn)定的基礎(chǔ)組件,可以極大減少代碼缺陷,因而整個團隊可以以并行開發(fā)的方式高效的推進開發(fā)進度. ②原有的業(yè)務(wù)不需要再次進行功能測試,可以專注于發(fā)生變化的業(yè)務(wù)的測試,以及最終的集成測試即可. 缺點： 到現(xiàn)在為止,我們已經(jīng)有效解決了"單工程開發(fā)模型"中一些問題,對于大部分團隊來說這種已經(jīng)可以了,但是該模型仍然存在一些可以改進的點:每次修改依賴包,就需要重新編譯生成lib或者aar.比如說小顏同學接手了一個項目有40多個組件,在最后集成所有組件的時候,小顏同學發(fā)現(xiàn)其中某組件存在問題,為了定位和修改該組件中的問題,小顏同學不斷這調(diào)試該組件.由于在該模型下,組件不能脫離主工程,那么意味著,每次修改后,小顏同學都要在漫長的編譯過程中等待.更糟糕的是,現(xiàn)在離上線只有5小時了,每次編譯10分鐘,為改這個bug,編譯了20次,恩....什么也不用干了,可以提交離職報告了

（3）主工程多子工程開發(fā)模型 不難發(fā)現(xiàn),該種開發(fā)模型在結(jié)構(gòu)上和"主工程多組件"并無不同,唯一的區(qū)別在于:所有業(yè)務(wù)組件不再是mouble而是作為一個子工程,基礎(chǔ)組件可以使moudle,也可以是子工程,該子工程和主工程不同:Debug模式下下作為app,可以單獨的開發(fā),運行,調(diào)試;Release模式下作為Library,被主工程所依賴,向主工程提供服務(wù).

優(yōu)點： ①在該種模型下,當小顏同學發(fā)現(xiàn)某個業(yè)務(wù)組件存在缺陷,會如何做呢?比如是基礎(chǔ)組件2出現(xiàn)問題,由于在Debug模式下,基礎(chǔ)組件2作為app可以獨立運行的,因此可以很容易地對該模塊進行單獨修改,調(diào)試.最后修改完后只需要重新編譯一次整個項目即可。 ②不難發(fā)現(xiàn)該種開發(fā)模型有效的減少了全編譯的次數(shù),減少編譯耗時的同時,方便開發(fā)者進行開發(fā)調(diào)試。 ③對測試同學來說,功能測試可以提前,并且能夠及時的參與到開發(fā)環(huán)節(jié)中,將風險降到最低。

Android插件化開發(fā)

插件化和組件化開發(fā)略有不用，插件化開發(fā)時將整個app拆分成很多模塊，這些模塊包括一個宿主和多個插件，每個模塊都是一個apk或者Dex包（組件化的每個模塊是個lib，盡管調(diào)試時是一個應(yīng)用，打包時還是作為lib處理），最終打包的時候?qū)⑺拗鱝pk和插件apk分開或者聯(lián)合打包。

1、為什么會產(chǎn)生插件化開發(fā)模式？ 我們知道一個APK包只有一個classes.dex文件，但dex文件最大的方法數(shù)為65535。 如果一個應(yīng)用的業(yè)務(wù)邏輯十分龐大，例如淘寶、京東。很顯然如果只有一個APK文件是遠遠不夠的。那么有什么解決方法，有如下幾個：

• 用 H5、React Native、Flutter 代替部分邏輯
• 刪無用代碼
• 買付費版的 Proguard
• 另外還有一個就是插件化模式。

2、插件化的優(yōu)點

• 模塊解耦
• 應(yīng)用可以實現(xiàn)動態(tài)升級（熱更新，差異包更新）
• 可以動態(tài)修復(fù)線上應(yīng)用Bug，而無需重新構(gòu)建版本，再次升級。
• 高效并行開發(fā)
• 按需加載相應(yīng)模塊，內(nèi)存占用率更低
• 節(jié)省流量升級

3、Android插件化基礎(chǔ)知識

• Android進程間通信（IPC）binder機制
• APP打包流程
• APP安裝流程
• APP啟動流程
• 資源加載機制
• Gradle腳本

4、Android插件化實現(xiàn)目前的技術(shù)流派

• 動態(tài)替換
• 靜態(tài)代理
• Dex合并（Dex合并就是Android熱修復(fù)的思想）

5、目前比較流行的第三方插件化框架

• 360的插件化框架：github.com/Qihoo360/Dr…
• 阿里的插件化框架：github.com/alibaba/atl…
• 百度任玉剛：github.com/singwhatiwa…
• Google親兒子：Android App Bundles

總結(jié)

以上是生活随笔為你收集整理的Android开发人员应该知道的一些技术的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。