前言

以前是只要你會Android四大組件的都是個香餑餑，那樣的時代已經(jīng)過去了，隨著人機(jī)交互的體驗要求，App的用戶體驗的要求、流暢度等等，已經(jīng)不可同日而語。

在這樣的大環(huán)境下，那么對我們的Android開發(fā)工程師也是同樣的改變。中、高級的工程師還是很受歡迎的，所以我認(rèn)為正確的職業(yè)規(guī)劃應(yīng)該是金字塔形，核心競爭力一定要扎實！

對于現(xiàn)在的Android及移動互聯(lián)網(wǎng)來說，我們需要掌握的技術(shù)，我做了一個清單，掌握了這些過好2020年不是問題了(#^ o ^#)：

泛型原理丶反射原理丶Java虛擬機(jī)原理丶線程池原理丶
注解原理丶注解原理丶序列化
Activity知識體系（Activity的生命周期丶Activity的任務(wù)棧丶Activity的啟動模式丶View源碼丶Fragment內(nèi)核相關(guān)丶service原理等）
代碼框架結(jié)構(gòu)優(yōu)化（數(shù)據(jù)結(jié)構(gòu)丶排序算法丶設(shè)計模式）
APP性能優(yōu)化（用戶體驗優(yōu)化丶適配丶代碼調(diào)優(yōu)）
熱修復(fù)丶熱升級丶Hook技術(shù)丶IOC架構(gòu)設(shè)計
NDK（c編程丶C++丶JNI丶LINUX）
如何提高開發(fā)效率？
MVC丶MVP丶MVVM
微信小程序
Hybrid
Flutter

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ū)別?？梢哉fAndroid從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)程?；?/h1>

(1) 進(jìn)程?；罡拍?/strong>

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

進(jìn)程?；畈⒎鞘且环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)程?；?/code>和內(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)行檢查。

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

• 利用系統(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ī)制做了改動，該方法可能不再生效。

總結(jié)

【Android 詳細(xì)知識點思維腦圖（技能樹）】

其實Android開發(fā)的知識點就那么多，面試問來問去還是那么點東西。所以面試沒有其他的訣竅，只看你對這些知識點準(zhǔn)備的充分程度。so，出去面試時先看看自己復(fù)習(xí)到了哪個階段就好。

雖然 Android 沒有前幾年火熱了，已經(jīng)過去了會四大組件就能找到高薪職位的時代了。這只能說明 Android 中級以下的崗位飽和了，現(xiàn)在高級工程師還是比較缺少的，很多高級職位給的薪資真的特別高（錢多也不一定能找到合適的），所以努力讓自己成為高級工程師才是最重要的。

這里附上上述的面試題相關(guān)的幾十套字節(jié)跳動，京東，小米，騰訊、頭條、阿里、美團(tuán)等公司19年的面試題。把技術(shù)點整理成了視頻和PDF（實際上比預(yù)期多花了不少精力），包含知識脈絡(luò) + 諸多細(xì)節(jié)。

由于篇幅有限，這里以圖片的形式給大家展示一小部分。

詳細(xì)整理在石墨文檔可以見；

Android架構(gòu)視頻+BAT面試專題PDF+學(xué)習(xí)筆記?

網(wǎng)上學(xué)習(xí) Android的資料一大堆，但如果學(xué)到的知識不成體系，遇到問題時只是淺嘗輒止，不再深入研究，那么很難做到真正的技術(shù)提升。希望這份系統(tǒng)化的技術(shù)體系對大家有一個方向參考。