一、Android MVC、MVP以及MVVM框架模式
MVC開發框架
- View：對應於佈局檔案和自定義View,負責將使用者的請求通知Controller，並根據model更新介面；
- Controller：對應於Activity、Fragement,負責處理業務邏輯接收使用者請求並更新model；（而事實上我們的Activity同時承擔著MVC3種角色，程式碼動不動就上千行！）
- Model：資料模型，負責資料處理相關的邏輯，封裝應用程式狀態，響應狀態查詢，通知View改變。
MVP開發框架
- View 對應於Activity，負責View的繪製以及與使用者互動
- Model 依然是資料模型，負責資料處理相關的邏輯和實體模型
- Presenter 負責完成View於Model間的互動，處理業務邏輯
MVP框架的優點： ①Model層和View層充分解耦。 ②複雜的任務被分成細小的任務，並且很容易解決。越小的東西，bug越少，越容易debug，更好測試。 ③在MVP模式下的View層將會變得簡單，簡單直觀。 ④後臺任務不再和Activity聯絡在一起，這既不會導致記憶體洩露(OOM)，也不依賴於Activity的重建。 ⑤Persnter層負責處理業務邏輯，這樣業務邏輯就被剝離了出來，不在擔心需求的不停變更，可以使開發者更專注解決問題。 ⑥可以直接單元測試Persenter層，以致於無需實現和View層和Model層。 MVP框架的缺點： 需要寫很多類，原本一個類可以完成的事，現在需要寫6個！
MVVM開發框架
- MVVM可以算是MVP的升級版，將 Presenter 改名為 ViewModel。關鍵在於ViewModel和Model的雙向繫結，當View有使用者輸入後，ViewModel通知Model更新資料，同理Model資料更新後，ViewModel通知View更新。
- MVVM的出現還是為了解決View層和Model層之間的解耦，實現了充分解耦。
- MVVM相比MVP，很大程度上解決了MVP的缺點
- Android Google在2015年提出的DataBinding Library技術，使得ViewModel和Model之間的雙向繫結更加容易。IOS上如果要實現類似功能，使用KVO也可實現。
MVVM框架的優點 ①繼承了MVP框架的所有優點 ②書寫更加方便，不必建立很多個類。使得檢視層，業務邏輯層，資料模型層，層次結構更加清晰。 ③再Model層和View層充分解耦的同時，還實現了資料和檢視的雙向繫結，資料變化時，檢視自動更新。這個特性很有用，對於一些實時性較高的應用來說無疑是最佳的解決方案。例如炒股的一些APP。 MVVM框架在Android工程上的實現的基本要求 ①開發工具目前只支援Android Stduio，很顯然eclipse已經被Google淘汰。 ②Android Studio需要1.3版本以上 ③Gradle版本需要2.2以上版本 ④Android plugin for gradle 1.3.0及以上版本
二、Android元件化開發和外掛化開發技術
Android元件化開發
1、什麼是元件化開發？ 所謂元件化開發就單獨的業務模組抽取出來。每一個模組是一個module，正常一個App中可以有多個module，但是一般只會有一個module是設定為application的，其他均設定為library，元件化開發就是要每個module都可以執行起來，因此在開發期間每個module均設定為application，釋出時再進行合併。 2、為什麼要使用元件化開發？ ① Android專案中程式碼量達到一定程度，編譯將是一件非常痛苦的事情，短則一兩分鐘，長則達到五六分鐘。元件化開發可以有效降低程式碼模組的耦合度，使程式碼架構更加清晰，同時模組化的編譯可以有效減少編譯時間，當然總的編譯時間是不會減少的，只是App模組化之後開發某個模組時，只需要編譯特定模組，可以快速編譯除錯。 ②元件化實現了業務的解耦和重用。
元件化開發模式的演變
（1） 單工程開發模式
該種開發模型已經有了明確的模組劃分,並且通過邏輯上的分層呈現出較好結構,該模型最為我們所熟悉,通常用於早期產品的快速開發,團隊規模較小的情況下，隨著產品的迭代,業務越來越複雜,隨之帶來的是專案結構複雜度的極度增加,此時我們面臨著幾個問題:
- 實際業務變化非常快但是工程之前的業務模組耦合度太高,牽一髮而動全身.
- 對工程所做的任何修改都必須要編譯整個工程
- 功能測試和系統測試每次都要進行.
- 團隊協同開發存在較多的衝突.不得不花費更多的時間去溝通和協調,並且在開發過程中,任何一位成員沒辦法專注於自己的功能點,影響開發效率.
- 不能靈活的對工程進行配置和組裝.比如今天產品經理說加上這個功能,明天又說去掉,後天在加上.
（2）主工程多元件開發模型 在"單工程"模型的基礎上,將業務層中的各業務抽取出來,封裝成相應的業務元件,將基礎庫中各部分抽取出來,封裝成基礎元件,而主工程是一個可執行的app,作為各元件的入口(主工程也被稱之為殼程式).這些元件或以jar的形式呈現,或以aar的形式呈現.主工程通過依賴的方式使用元件所提供的功能.
優點： ①每個成員可以專注自己所負責的業務,並不影響其他業務,同時藉助穩定的基礎元件,可以極大減少程式碼缺陷,因而整個團隊可以以並行開發的方式高效的推進開發進度. ②原有的業務不需要再次進行功能測試,可以專注於發生變化的業務的測試,以及最終的整合測試即可. 缺點： 到現在為止,我們已經有效解決了"單工程開發模型"中一些問題,對於大部分團隊來說這種已經可以了,但是該模型仍然存在一些可以改進的點:每次修改依賴包,就需要重新編譯生成lib或者aar.比如說小顏同學接手了一個專案有40多個元件,在最後整合所有元件的時候,小顏同學發現其中某元件存在問題,為了定位和修改該元件中的問題,小顏同學不斷這除錯該元件.由於在該模型下,元件不能脫離主工程,那麼意味著,每次修改後,小顏同學都要在漫長的編譯過程中等待.更糟糕的是,現在離上線只有5小時了,每次編譯10分鐘,為改這個bug,編譯了20次,恩....什麼也不用幹了,可以提交離職報告了
（3）主工程多子工程開發模型 不難發現,該種開發模型在結構上和"主工程多元件"並無不同,唯一的區別在於:所有業務元件不再是mouble而是作為一個子工程,基礎元件可以使moudle,也可以是子工程,該子工程和主工程不同:Debug模式下下作為app,可以單獨的開發,執行,除錯;Release模式下作為Library,被主工程所依賴,向主工程提供服務.
優點： ①在該種模型下,當小顏同學發現某個業務元件存在缺陷,會如何做呢?比如是基礎元件2出現問題,由於在Debug模式下,基礎元件2作為app可以獨立執行的,因此可以很容易地對該模組進行單獨修改,除錯.最後修改完後只需要重新編譯一次整個專案即可。 ②不難發現該種開發模型有效的減少了全編譯的次數,減少編譯耗時的同時,方便開發者進行開發除錯。 ③對測試同學來說,功能測試可以提前,並且能夠及時的參與到開發環節中,將風險降到最低。
Android外掛化開發
外掛化和元件化開發略有不用，外掛化開發時將整個app拆分成很多模組，這些模組包括一個宿主和多個外掛，每個模組都是一個apk或者Dex包（元件化的每個模組是個lib，儘管除錯時是一個應用，打包時還是作為lib處理），最終打包的時候將宿主apk和外掛apk分開或者聯合打包。
1、為什麼會產生外掛化開發模式？ 我們知道一個APK包只有一個classes.dex檔案，但dex檔案最大的方法數為65535。 如果一個應用的業務邏輯十分龐大，例如淘寶、京東。很顯然如果只有一個APK檔案是遠遠不夠的。那麼有什麼解決方法，有如下幾個：
- 用 H5、React Native、Flutter 代替部分邏輯
- 刪無用程式碼
- 買付費版的 Proguard
- 另外還有一個就是外掛化模式。
2、外掛化的優點
- 模組解耦
- 應用可以實現動態升級（熱更新，差異包更新）
- 可以動態修復線上應用Bug，而無需重新構建版本，再次升級。
- 高效並行開發
- 按需載入相應模組，記憶體佔用率更低
- 節省流量升級
3、Android外掛化基礎知識
- Android程式間通訊（IPC）binder機制
- APP打包流程
- APP安裝流程
- APP啟動流程
- 資源載入機制
- Gradle指令碼
4、Android外掛化實現目前的技術流派
- 動態替換
- 靜態代理
- Dex合併（Dex合併就是Android熱修復的思想）
5、目前比較流行的第三方外掛化框架
- 360的外掛化框架：github.com/Qihoo360/Dr…
- 阿里的外掛化框架：github.com/alibaba/atl…
- 百度任玉剛：github.com/singwhatiwa…
- Google親兒子：Android App Bundles