Android開發(fā)熱門前沿知識

1. Android架構(gòu)設(shè)計模式

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

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

1.1 架構(gòu)設(shè)計模式-MVC

MVC模式.png

(1) 定義：在android開發(fā)過程中，比較流行的開發(fā)框架曾經(jīng)采用的是MVC框架模式。

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

(2) 特點

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

(3) 實例

android本身的設(shè)計結(jié)構(gòu)符合 MVC 模式。

(4) MVC優(yōu)缺點

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

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

1.2 架構(gòu)設(shè)計模式-MVP

MVP模式.png

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

(1) 定義

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

(2) 實例

(3) MVC和MVP的區(qū)別

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

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

(4) MVP優(yōu)缺點

  • MVP的優(yōu)點如下:

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

  • MVP也有不足之處:

接口過多，一定程度影響了編碼效率。一定程度上導(dǎo)致Presenter的代碼量過大。
為了降低Presenter中業(yè)務(wù)繁多的問題，Google又推出了MVVM，試圖通過數(shù)據(jù)驅(qū)動來減少Presenter的代碼量。

1.3 架構(gòu)設(shè)計模式-MVVM

MVVM模式.png

(1) 定義

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

2. android插件化

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

2.1 插件化要解決的問題—如何動態(tài)加載apk

(1) android類加載器及區(qū)別

類加載器作用：java字節(jié)碼通過類加載器加載到j(luò)ava虛擬器。

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

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

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

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

動態(tài)加載apk.png

如：


ProxyActivity.png

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

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

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

使用java中的類加載機制，但是android和java也有一點不一樣，android比java多了組件和生命周期，所以并不是類加載進來就能使用(不能管理生命周期)。

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

(1) 熱更新流程

熱更新流程.png

(2) 熱更新主流框架

  • Dexposed
  • AndFix
  • NuWa

(3) 熱更新原理

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

PathClassLoader類：用來加載系統(tǒng)類
DexClassLoader：用來加載dex文件、jar文件包和apk包等

  • 熱修復(fù)機制（原理）

原理：在ClassLoader中創(chuàng)建一個dexElements數(shù)組，根據(jù)線上的crash定位找到對應(yīng)的類文件，然后把這個類文件修復(fù)完成后打包成一個dex文件并放到dexElements數(shù)組的最前方。那么當(dāng)ClassLoader遍歷dexElements數(shù)組（加載數(shù)組中的dex文件）時，因為ClassLoader會優(yōu)先加載最前方的dex文件，所以不會加載線上有crash的dex文件，只會加載修復(fù)完的dex文件，從而完成熱修復(fù)過程。

熱修復(fù)機制原理.png

4. Android進程?；?/h1>

(1) 進程保活概念

進程?；睿鹤屵M程在內(nèi)存中永遠存在且無法殺死，就算被殺死也能保活。
進程被殺死的原因：人為地調(diào)用kill；被第三方安全軟件殺死。

進程?；畈⒎鞘且环N流氓手段，在很多場景下我們需要一個常駐進程來為用戶提供服務(wù)，如：

  • 接收屏幕開關(guān)的系統(tǒng)廣播：因為廣播接收者不支持靜態(tài)注冊，必須在進程中動態(tài)注冊廣播接收者來接收，如果沒有常駐進程，那么鎖屏應(yīng)用無法為用戶正常提供服務(wù)。
  • 定位服務(wù)：需要在后臺維護一個長連接，以便及時地將信息（推送的信息/定位信息等）傳達給用戶。

缺點：進程保活在內(nèi)存，不管如何優(yōu)化，或多或少都會增加性能的開銷。所以需在進程?；?/code>和內(nèi)存消耗之間尋找平衡點來為用戶進程?；睢?/p>

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

  • android進程優(yōu)先級：前臺進程 > 可見進程 > 服務(wù)進程 > 后臺進程 > 空進程
  • android進程的回收策略：主要依靠LMK ( Low Memory Killer )機制來完成。LMK機制通過 oom_adj 這個閥值來判斷進程的優(yōu)先級，oom_adj 的值越高，優(yōu)先級越低，越容易被殺死。
    拓展：LMK ( Low Memory Killer ) 機制基于Linux的OOM（Out Of Memery）機制，通過一些比較復(fù)雜的評分機制，對進程進行打分，將分數(shù)高的進程判定為bad進程，殺死并釋放內(nèi)存。LMS機制和OOM機制的不同之處在于：OOM只有當(dāng)系統(tǒng)內(nèi)存不足時才會啟動檢查，而LMS機制是定時進行檢查。

(3) android進程?；罘桨?/a>

  • 利用系統(tǒng)廣播拉活

在發(fā)生系統(tǒng)事件時，系統(tǒng)會發(fā)出相對響應(yīng)的廣播(常用的廣播事件如：開機、網(wǎng)絡(luò)狀態(tài)變化、文件或sd卡的卸載等)，我們可以在mainfest.xml文件中靜態(tài)注冊廣播監(jiān)聽器
缺點（無法拉活的情形）：廣播接收者被管理軟件或系統(tǒng)軟件通過自啟動管理等功能禁用的場景下是無法接受廣播的，從而無法自啟動進行系統(tǒng)拉活；系統(tǒng)廣播事件是不可控制的，只有在發(fā)生事件時才能進行拉活，無法保證進程被殺死后立即被拉活。

  • 利用系統(tǒng)Service機制拉活

將Service中的onStartCommand()回調(diào)方法的返回值設(shè)為START_STICKY，就可以利用系統(tǒng)機制在Service掛掉后自動拉活。
拓展：onStartCommand()的返回值表明當(dāng)Service由于系統(tǒng)內(nèi)存不足而被系統(tǒng)殺掉之后，在未來的某個時間段內(nèi)當(dāng)系統(tǒng)內(nèi)存足夠的情況下，系統(tǒng)會嘗試創(chuàng)建這個Service，一旦創(chuàng)建成功就又會回調(diào)onStartCommand()方法。
缺點（無法拉活的情形）：Service第一次被異常殺死后會在5s內(nèi)重啟，第二次會在10s內(nèi)重啟，第三次會在20s內(nèi)重啟，若Service在短時間內(nèi)被殺死的次數(shù)超過3次以上系統(tǒng)就會不驚醒拉活；進程被取得root權(quán)限的管理工具或系統(tǒng)工具通過強制stop時，通過Service機制無法重啟進程。

  • 利用Native進程拉活

思想：利用Linux中的fork機制創(chuàng)建一個Native進程，在Native進程可以監(jiān)控主進程的存活，當(dāng)主進程掛掉之后，Native進程可以立即對主進程進行拉活。
在Native進程中如何監(jiān)聽主進程被殺死：可在Native進程中通過死循環(huán)或定時器，輪詢地判斷主進程被殺死，但是此方案會耗時耗資源；在主線程中創(chuàng)建一個監(jiān)控文件，并且在主進程中持有文件鎖，在拉活進程啟動后申請文件鎖將會被阻塞，一旦成功獲取到鎖說明主進程掛掉了。
如何在Native進程中拉活主進程：主要通過一個am命令即可拉活。
說明：android5.0后系統(tǒng)對Native進程加強了管理，利用Native進程拉活的方式已失效。

  • 利用JobScheduler機制拉活

說明：android在5.0后提供了JobScheduler接口，這個接口能夠監(jiān)聽主進程的存活，然后拉活進程。

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

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

?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
【社區(qū)內(nèi)容提示】社區(qū)部分內(nèi)容疑似由AI輔助生成，瀏覽時請結(jié)合常識與多方信息審慎甄別。
平臺聲明：文章內(nèi)容（如有圖片或視頻亦包括在內(nèi)）由作者上傳并發(fā)布，文章內(nèi)容僅代表作者本人觀點，簡書系信息發(fā)布平臺，僅提供信息存儲服務(wù)。

相關(guān)閱讀更多精彩內(nèi)容

友情鏈接更多精彩內(nèi)容