Android開發熱門前沿知識，這幾點常常被忽略，你敢說你都知道？

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 插件化要解決的問題—如何動態加載apk

(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的調用。

實現原理：類加載器（加載類）+反射（獲取屬性和方法）+動態代理（執行）

如：

ProxyActivity.png

2.2 插件化要解決的問題—如何加載資源

經過android中ServiceManager類的隱藏方法來加載資源。

2.3 插件化要解決的問題—如何加載代碼

使用java中的類加載機制，可是android和java也有一點不同，android比java多了組件和生命週期，因此並非類加載進來就能使用(不能管理生命週期)。

3. Android熱更新(在線熱修復技術)

(1) 熱更新流程

• 檢測到線上嚴重的crash（參考：app檢測crash併發送日誌到服務器的實現）
• 線上版本拉出bugfix分支並在分支上修復問題
• jenkins構建及生成補丁
• app在合適時機經過推送或主動拉取補丁文件
• 將bugfix代碼合併到master上

熱更新流程.png

(2) 熱更新主流框架

• Dexposed
• AndFix
• NuWa

(3) 熱更新原理

• Android類加載機制（類加載器）

PathClassLoader類：用來加載系統類DexClassLoader：用來加載dex文件、jar文件包和apk包等

• 熱修復機制（原理）

原理：在ClassLoader中建立一個dexElements數組，根據線上的crash定位找到對應的類文件，而後把這個類文件修復完成後打包成一個dex文件並放到dexElements數組的最前方。那麼當ClassLoader遍歷dexElements數組（加載數組中的dex文件）時，由於ClassLoader會優先加載最前方的dex文件，因此不會加載線上有crash的dex文件，只會加載修復完的dex文件，從而完成熱修復過程。

熱修復機制原理.png

4. Android進程保活

(1) 進程保活概念

進程保活：讓進程在內存中永遠存在且沒法殺死，就算被殺死也能保活。進程被殺死的緣由：人爲地調用kill；被第三方安全軟件殺死。

進程保活並不是是一種流氓手段，在不少場景下咱們須要一個常駐進程來爲用戶提供服務，如：

• 接收屏幕開關的系統廣播：由於廣播接收者不支持靜態註冊，必須在進程中動態註冊廣播接收者來接收，若是沒有常駐進程，那麼鎖屏應用沒法爲用戶正常提供服務。
• 定位服務：須要在後臺維護一個長鏈接，以便及時地將信息（推送的信息/定位信息等）傳達給用戶。

缺點：進程保活在內存，無論如何優化，或多或少都會增長性能的開銷。因此需在進程保活和內存消耗之間尋找平衡點來爲用戶進程保活。

(2) android進程優先級和回收策略

android進程優先級：前臺進程 > 可見進程 > 服務進程 > 後臺進程 > 空進程

android進程的回收策略：主要依靠LMK ( Low Memory Killer )機制來完成。LMK機制經過 oom_adj 這個閥值來判斷進程的優先級，oom_adj 的值越高，優先級越低，越容易被殺死。

拓展：LMK ( Low Memory Killer ) 機制基於Linux的OOM（Out Of Memery）機制，經過一些比較複雜的評分機制，對進程進行打分，將分數高的進程斷定爲bad進程，殺死並釋放內存。LMS機制和OOM機制的不一樣之處在於：OOM只有當系統內存不足時纔會啓動檢查，而LMS機制是定時進行檢查。

(3) android進程保活方案

• 利用系統廣播拉活 在發生系統事件時，系統會發出相對響應的廣播(經常使用的廣播事件如：開機、網絡狀態變化、文件或sd卡的卸載等)，咱們能夠在mainfest.xml文件中靜態註冊廣播監聽器

缺點（沒法拉活的情形）：廣播接收者被管理軟件或系統軟件經過自啓動管理等功能禁用的場景下是沒法接受廣播的，從而沒法自啓動進行系統拉活；系統廣播事件是不可控制的，只有在發生事件時才能進行拉活，沒法保證進程被殺死後當即被拉活。

• 利用系統Service機制拉活 將Service中的onStartCommand()回調方法的返回值設爲START_STICKY，就能夠利用系統機制在Service掛掉後自動拉活。

拓展：onStartCommand()的返回值代表當Service因爲系統內存不足而被系統殺掉以後，在將來的某個時間段內當系統內存足夠的狀況下，系統會嘗試建立這個Service，一旦建立成功就又會回調onStartCommand()方法。

缺點（沒法拉活的情形）：Service第一次被異常殺死後會在5s內重啓，第二次會在10s內重啓，第三次會在20s內重啓，若Service在短期內被殺死的次數超過3次以上系統就會不驚醒拉活；進程被取得root權限的管理工具或系統工具經過強制stop時，經過Service機制沒法重啓進程。

• 利用Native進程拉活 思想：利用Linux中的fork機制建立一個Native進程，在Native進程能夠監控主進程的存活，當主進程掛掉以後，Native進程能夠當即對主進程進行拉活。

在Native進程中如何監聽主進程被殺死：可在Native進程中經過死循環或定時器，輪詢地判斷主進程被殺死，可是此方案會耗時耗資源；在主線程中建立一個監控文件，而且在主進程中持有文件鎖，在拉活進程啓動後申請文件鎖將會被阻塞，一旦成功獲取到鎖說明主進程掛掉了。

如何在Native進程中拉活主進程：主要經過一個am命令便可拉活。說明：android5.0後系統對Native進程增強了管理，利用Native進程拉活的方式已失效。

• 利用JobScheduler機制拉活

說明：android在5.0後提供了JobScheduler接口，這個接口可以監聽主進程的存活，而後拉活進程。

• 利用帳號同步機制拉活（已失效）

說明：android系統的帳號同步機制會按期同步帳號信息，這個方案主要是利用帳號同步機制進行進程拉活。不過最新的android版本對帳號同步機制作了改動，該方法可能再也不生效。

文章不易，若是你們喜歡這篇文章，或者對你有幫助但願你們多多，點贊，轉發，關注 哦。文章會持續更新的。絕對乾貨！！！