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的改進(jìn)版。
各種模型的
主要目的都是是分離視圖（View）和模型（Model）绢记，即將UI界面顯示和業(yè)務(wù)邏輯進(jìn)行分離角骤。
1.1 架構(gòu)設(shè)計模式-MVC
(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是從經(jīng)典的MVC模式演變而來，它們的基本思想有相通的地方:Controller/Presenter負(fù)責(zé)邏輯的處理檬果，Model提供數(shù)據(jù)瓮孙，View負(fù)責(zé)顯示。在Android開發(fā)中选脊，MVP的具體實現(xiàn)流程是當(dāng)Presenter接收到View的請求杭抠，便從Model層獲取數(shù)據(jù)，將數(shù)據(jù)進(jìn)行處理知牌。處理好的數(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）層：負(fù)責(zé)
View的繪制以及與用戶交互邢疙。在Android開發(fā)中棍弄，它一般對應(yīng)著xml布局文件和Activity/Fragment。 - P（Presenter）層：負(fù)責(zé)完成Model層和View層間的數(shù)據(jù)
交互和業(yè)務(wù)邏輯疟游。
(2) 實例
(3) MVC和MVP的區(qū)別
MVP中的View并不直接使用Model呼畸，它們之間的通信是通過Presenter來進(jìn)行的，所有的交互都發(fā)生在Presenter內(nèi)部颁虐，而在MVC中View會直接從Model中讀取數(shù)據(jù)而不通過Controller
- MVC和MVP的最大區(qū)別：MVC的Model層和View層
能夠直接交互蛮原；MVP的Model層和View層不能直接交互，需通過Presenter層來進(jìn)行交互另绩。 - 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容劳，里面沒有很多的實際東西喘沿，主要負(fù)責(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
(1) 定義
- M（Model）層：仍然是
實體模型（但是不同于之前定義的Model層）纸淮，主要負(fù)責(zé)數(shù)據(jù)獲取、存儲和變化亚享，提供數(shù)據(jù)接口供 ViewModel 層調(diào)用咽块。 - V（View）層：對應(yīng)
Activity/Feagment和xml布局文件 ，負(fù)責(zé)View的繪制以及與用戶交互
說明：View層僅能操作UI（數(shù)據(jù)綁定來實現(xiàn) UI 更新）欺税；不能做任何和業(yè)務(wù)邏輯有關(guān)的數(shù)據(jù)操作 - VM（ViewModel）層：負(fù)責(zé)完成Model層和View層間的數(shù)據(jù)
交互和業(yè)務(wù)邏輯
說明：ViewModel層僅能做和業(yè)務(wù)邏輯有關(guān)的數(shù)據(jù)操作侈沪；不能做UI相關(guān)的操作
2. android插件化
插件化來由：隨著業(yè)務(wù)的增多，業(yè)務(wù)邏輯代碼越來越多晚凿，apk包也逐漸增大亭罪，不利于維護(hù)和升級。通過插件化開發(fā)可將功能模塊解耦歼秽，不同的維護(hù)團(tuán)隊僅維護(hù)某模塊的業(yè)務(wù)皆撩，同時當(dāng)app升級時可僅對某功能模塊進(jìn)行升級而不需整體升級。
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)部的信息機(jī)制亚脆，最重要的是我們可以在運行時實例化這個對象調(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，主要通過反射去獲得它的屬性和方法柑营，從而進(jìn)行apk的調(diào)用屈雄。
實現(xiàn)原理：類加載器（加載類）+反射（獲取屬性和方法）+動態(tài)代理（執(zhí)行）
如：
2.2 插件化要解決的問題—如何加載資源
通過android中ServiceManager類的隱藏方法來加載資源。
2.3 插件化要解決的問題—如何加載代碼
使用java中的類加載機(jī)制官套，但是android和java也有一點不一樣酒奶，android比java多了組件和生命周期，所以并不是類加載進(jìn)來就能使用(不能管理生命周期)奶赔。
3. Android熱更新(在線熱修復(fù)技術(shù))
(1) 熱更新流程
- 檢測到線上嚴(yán)重的crash（參考：app檢測crash并發(fā)送日志到服務(wù)器的實現(xiàn)）
- 線上版本拉出bugfix分支并在分支上修復(fù)問題
- jenkins構(gòu)建及生成補(bǔ)丁
- app在合適時機(jī)通過推送或主動拉取補(bǔ)丁文件
- 將bugfix代碼合并到master上
(2) 熱更新主流框架
- Dexposed
- AndFix
- NuWa
(3) 熱更新原理
- Android類加載機(jī)制（類加載器）
PathClassLoader類：用來加載系統(tǒng)類
DexClassLoader：用來加載dex文件惋嚎、jar文件包和apk包等
- 熱修復(fù)機(jī)制（原理）
原理：在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ù)過程。
4. Android進(jìn)程苯衢活
(1) 進(jìn)程敝斜矗活概念
進(jìn)程保活：讓進(jìn)程在
內(nèi)存中永遠(yuǎn)存在且無法殺死臼朗，就算被殺死也能绷谑伲活。
進(jìn)程被殺死的原因：人為地調(diào)用kill视哑；被第三方安全軟件殺死绣否。
進(jìn)程保活并非是一種流氓手段挡毅，在很多場景下我們需要一個常駐進(jìn)程來為用戶提供服務(wù)蒜撮，如：
- 接收屏幕開關(guān)的系統(tǒng)廣播：因為廣播接收者不支持靜態(tài)注冊，必須在進(jìn)程中動態(tài)注冊廣播接收者來接收跪呈，如果沒有常駐進(jìn)程段磨，那么鎖屏應(yīng)用無法為用戶正常提供服務(wù)。
- 定位服務(wù)：需要在后臺維護(hù)一個長連接耗绿，以便及時地將信息（推送的信息/定位信息等）傳達(dá)給用戶苹支。
缺點：進(jìn)程保活在內(nèi)存误阻，不管如何優(yōu)化债蜜，或多或少都會增加性能的開銷。所以需在
進(jìn)程本糠矗活和內(nèi)存消耗之間尋找平衡點來為用戶進(jìn)程毖岸ǎ活。
(2) android進(jìn)程優(yōu)先級和回收策略
- android進(jìn)程優(yōu)先級：前臺進(jìn)程 > 可見進(jìn)程 > 服務(wù)進(jìn)程 > 后臺進(jìn)程 > 空進(jìn)程
- android進(jìn)程的回收策略：主要依靠LMK ( Low Memory Killer )機(jī)制來完成精耐。LMK機(jī)制通過 oom_adj 這個閥值來判斷進(jìn)程的優(yōu)先級狼速，oom_adj 的值越高，優(yōu)先級越低黍氮，越容易被殺死唐含。
拓展：LMK ( Low Memory Killer ) 機(jī)制基于Linux的OOM（Out Of Memery）機(jī)制，通過一些比較復(fù)雜的評分機(jī)制沫浆，對進(jìn)程進(jìn)行打分捷枯，將分?jǐn)?shù)高的進(jìn)程判定為bad進(jìn)程，殺死并釋放內(nèi)存专执。LMS機(jī)制和OOM機(jī)制的不同之處在于：OOM只有當(dāng)系統(tǒng)內(nèi)存不足時才會啟動檢查淮捆，而LMS機(jī)制是定時進(jìn)行檢查。
- 利用系統(tǒng)廣播拉活
在發(fā)生系統(tǒng)事件時攀痊，系統(tǒng)會發(fā)出相對響應(yīng)的廣播(常用的廣播事件如：開機(jī)桐腌、網(wǎng)絡(luò)狀態(tài)變化、文件或sd卡的卸載等)苟径，我們可以在mainfest.xml文件中靜態(tài)注冊廣播監(jiān)聽器
缺點（無法拉活的情形）：廣播接收者被管理軟件或系統(tǒng)軟件通過自啟動管理等功能禁用的場景下是無法接受廣播的案站，從而無法自啟動進(jìn)行系統(tǒng)拉活；系統(tǒng)廣播事件是不可控制的棘街，只有在發(fā)生事件時才能進(jìn)行拉活蟆盐，無法保證進(jìn)程被殺死后立即被拉活。
- 利用系統(tǒng)Service機(jī)制拉活
將Service中的onStartCommand()回調(diào)方法的返回值設(shè)為
START_STICKY遭殉，就可以利用系統(tǒng)機(jī)制在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)就會不驚醒拉活蚁飒；進(jìn)程被取得root權(quán)限的管理工具或系統(tǒng)工具通過強(qiáng)制stop時疾瓮，通過Service機(jī)制無法重啟進(jìn)程。
- 利用Native進(jìn)程拉活
思想：利用Linux中的fork機(jī)制創(chuàng)建一個Native進(jìn)程飒箭，在Native進(jìn)程可以監(jiān)控主進(jìn)程的存活，當(dāng)主進(jìn)程掛掉之后蜒灰，Native進(jìn)程可以立即對主進(jìn)程進(jìn)行拉活弦蹂。
在Native進(jìn)程中如何監(jiān)聽主進(jìn)程被殺死：可在Native進(jìn)程中通過死循環(huán)或定時器，輪詢地判斷主進(jìn)程被殺死强窖，但是此方案會耗時耗資源凸椿；在主線程中創(chuàng)建一個監(jiān)控文件，并且在主進(jìn)程中持有文件鎖翅溺，在拉活進(jìn)程啟動后申請文件鎖將會被阻塞脑漫，一旦成功獲取到鎖說明主進(jìn)程掛掉了。
如何在Native進(jìn)程中拉活主進(jìn)程：主要通過一個am命令即可拉活咙崎。
說明：android5.0后系統(tǒng)對Native進(jìn)程加強(qiáng)了管理优幸，利用Native進(jìn)程拉活的方式已失效。
- 利用JobScheduler機(jī)制拉活
說明：android在5.0后提供了JobScheduler接口褪猛，這個接口能夠監(jiān)聽主進(jìn)程的存活网杆，然后拉活進(jìn)程。
- 利用賬號同步機(jī)制拉活（已失效）
說明：android系統(tǒng)的賬號同步機(jī)制會定期同步賬號信息，這個方案主要是利用賬號同步機(jī)制進(jìn)行進(jìn)程拉活碳却。不過最新的android版本對賬號同步機(jī)制做了改動队秩，該方法可能不再生效。
