1. Android架構設計模式

• MVC架構設計模式：MVC全名是Model View Controller，是模型(model)-視圖(view)-控制器(controller)的縮寫。
• MVP架構設計模式：MVC全名是Model View Persenter，MVP由MVC演變而來，是現在主流的開發模式。
• MVVM架構設計模式：MVVM全名是Model-View-ViewModel，它本質上就是MVC的改進版。

各種模型的**主要目的**都是是分離視圖（View）和模型（Model），即將UI界面顯示和業務邏輯進行分離。

1.1 架構設計模式-MVC

(1) 定義：

在android開發過程中，比較流行的開發框架曾經采用的是MVC框架模式。

• M（Model）層：實體模型，處理業務邏輯。如：數據庫操作，網絡操作，I/O操作，復雜操作和耗時任務等。
• V（View）層：處理數據顯示。在Android開發中，它一般對應著xml布局文件。
• C（Controller）層：處理用戶交互。在Android開發中，它一般對應著Activity/Feagment。android中主要通過activity處理用戶交互和業務邏輯，接受用戶的輸入并調用Model和View去完成用戶的需求。

(2) 特點

• 低耦合
• 可重用易拓展
• 模塊職責劃分明確

(3) 實例

android本身的設計結構符合 MVC 模式。

(4) MVC優缺點

• MVC的優點：MVC模式通過Controller來掌控全局，同時將View展示和Model的變化分離開
• MVC也有局限性：

View層對應xml布局文件能做的事情非常有限，所以需要把大部分View相關的操作移到Controller層的activity中。導致activity相當于充當了2個角色(View層和Controller層)，不僅要處理業務邏輯，還要操作UI。一旦一個頁面的業務繁多復雜的話，activity的代碼就會越來越臃腫和復雜。

1.2 架構設計模式-MVP

MVP是從經典的MVC模式演變而來，它們的基本思想有相通的地方:Controller/Presenter負責邏輯的處理，Model提供數據，View負責顯示。在Android開發中，MVP的具體實現流程是當Presenter接收到View的請求，便從Model層獲取數據，將數據進行處理。處理好的數據再通過View層的接口回調給Activity或Fragment。這樣MVP能夠讓Activity或Fragment成為真正的View，只做與UI相關的事而不處理其他業務流程。

(1) 定義

• M（Model）層：實體模型，處理業務邏輯。如：數據庫操作，網絡操作，I/O操作，復雜操作和耗時任務等。
• V（View）層：負責View的繪制以及與用戶交互。在Android開發中，它一般對應著xml布局文件和Activity/Fragment。
• P（Presenter）層：負責完成Model層和View層間的數據交互和業務邏輯。

(2) 實例

(3) MVC和MVP的區別

MVP中的View并不直接使用Model，它們之間的通信是通過Presenter來進行的，所有的交互都發生在Presenter內部，而在MVC中View會直接從Model中讀取數據而不通過Controller

• MVC和MVP的最大區別：MVC的Model層和View層能夠直接交互；MVP的Model層和View層不能直接交互，需通過Presenter層來進行交互。
• Activity職責不同：Activity在MVC中屬于Controller層，在MVP中屬于View層，這是MVC和MVP很主要的一個區別。可以說Android從MVC轉向MVP開發也主要是優化Activity的代碼，避免Activity的代碼臃腫龐大。
• View層不同：MVC的View層指的是XML布局文件（或用Java自定義的View）；MVP的View層是Activity（或Fragment）
• 控制層不同：MVC的控制層是Activity（或Fragment）；MVP的控制層是Presenter，里面沒有很多的實際東西，主要負責Model層和View層的交互。

(4) MVP優缺點

• MVP的優點如下:

模型與視圖完全分離，我們可以修改視圖而不影響模型；項目代碼結構清晰，一看就知道什么類干什么事情；我們可以將一個Presenter用于多個視圖，而不需要改變Presenter的邏輯，這個特性非常的有用，因為視圖的變化總是比模型的變化更頻繁 ；協同工作(例如在設計師沒出圖之前可以先寫一些業務邏輯代碼)

• MVP也有不足之處:

接口過多，一定程度影響了編碼效率。一定程度上導致Presenter的代碼量過大。
為了降低Presenter中業務繁多的問題，Google又推出了MVVM，試圖通過數據驅動來減少Presenter的代碼量。

1.3 架構設計模式-MVVM

(1) 定義

• M（Model）層：仍然是實體模型（但是不同于之前定義的Model層），主要負責數據獲取、存儲和變化，提供數據接口供 ViewModel 層調用。
• V（View）層：對應Activity/Feagment 和xml布局文件 ，負責View的繪制以及與用戶交互
  說明：View層僅能操作UI（數據綁定來實現 UI 更新）；不能做任何和業務邏輯有關的數據操作
• VM（ViewModel）層：負責完成Model層和View層間的數據交互和業務邏輯
  說明：ViewModel層僅能做和業務邏輯有關的數據操作；不能做UI相關的操作

2. android插件化

插件化來由：隨著業務的增多，業務邏輯代碼越來越多，apk包也逐漸增大，不利于維護和升級。通過插件化開發可將功能模塊解耦，不同的維護團隊僅維護某模塊的業務，同時當app升級時可僅對某功能模塊進行升級而不需整體升級。

2.1 插件化要解決的問題—如何動態加載a

《安卓學習筆記總結+最新移動架構視頻+大廠安卓面試真題+項目實戰源碼講義》瀏覽器打開

完整開源項目：docs.qq.com/doc/DSkNLaERkbnFoS0ZF

pk

(1) android類加載器及區別

類加載器作用：java字節碼通過類加載器加載到java虛擬器。

• PathClassLoader：僅能加載文件目錄下的apk。
• DexClassLoader：可以加載apk文件中的字節碼(從dex實體jar文件中加載java字節碼)。主要用于動態加載和代碼熱更新等。

(2)反射： java中的反射使我們在運行時獲得這個類的屬性、方法和class內部的信息機制，最重要的是我們可以在運行時實例化這個對象調用方法，這也是java反射的最大優點。
(3) 實現動態加載apk

什么是動態加載apk：android中有一個速度程序會主動到指定的sd卡中去加載apk，并通過代理activity去執行。

實現：需要一個代理activity去執行apk中的activity，主要通過反射去獲得它的屬性和方法，從而進行apk的調用。
實現原理：類加載器（加載類）+反射（獲取屬性和方法）+動態代理（執行）

最后

在這里我和身邊一些朋友特意整理了一份快速進階為Android高級工程師的系統且全面的學習資料。涵蓋了Android初級——Android高級架構師進階必備的一些學習技能。

附上：我們之前因為秋招收集的二十套一二線互聯網公司Android面試真題（含BAT、小米、華為、美團、滴滴）和我自己整理Android復習筆記（包含Android基礎知識點、Android擴展知識點、Android源碼解析、設計模式匯總、Gradle知識點、常見算法題匯總。）

ndroid復習筆記（包含Android基礎知識點、Android擴展知識點、Android源碼解析、設計模式匯總、Gradle知識點、常見算法題匯總。）

[外鏈圖片轉存中…(img-8NIBoU1B-1709290070311)]

本文已被CODING開源項目：《Android學習筆記總結+移動架構視頻+大廠面試真題+項目實戰源碼》收錄