華爲架構師深刻講解Android開發！Android技術功底不夠如何去面試，面試必問

前言

最近有很多人問我這樣一個問題：「我剛接觸編程，準備學習下Android開發，可是擔憂如今市場飽和了，Android開發的前景怎麼樣？」

想着可能有不少人都有這樣的擔憂，因而就趕忙寫篇文章，來跟大家談下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的調用。

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

學習分享

在當下這個信息共享的時代，不少資源均可以在網絡上找到，只取決於你願不肯意找或是找的方法對不對了

不少朋友不是沒有資料，大多都是有幾十上百個G，可是雜亂無章，不知道怎麼看從哪看起，甚至是看後就忘

若是你們以爲本身在網上找的資料很是雜亂、不成體系的話，我也分享一套給你們，比較系統，我日常本身也會常常研讀。

2020最新上萬頁的大廠面試真題

七大模塊學習資料：如NDK模塊開發、Android框架體系架構...

只有系統，有方向的學習，才能在段時間內迅速提升本身的技術。

這份體系學習筆記，適應人羣： 第一，學習知識比較碎片化，沒有合理的學習路線與進階方向。 第二，開發幾年，不知道如何進階更進一步，比較迷茫。 第三，到了合適的年紀，後續不知道該如何發展，轉型管理，仍是增強技術研究。若是你有須要，我這裏剛好有爲何，不來領取！說不定能改變你如今的狀態呢！ 因爲文章內容比較多，篇幅不容許，部分未展現內容以截圖方式展現 。 若有須要獲取完整的資料文檔的朋友點擊個人GitHub免費獲取。