又到年底了，每到這個時候，我們都會慢慢反思，這一年都做了什么？有什么進步？年初的計劃都實現了嗎？明年年初有跳槽的底氣了嗎？況且今年的互聯網環境太差，需要自己有足夠的知識儲備，才能夠應對這凌冽的寒風。
本文主要是整理了中高級安卓需要會的（或者說面試被頻繁問到的內容），主要作為參考大綱，之后會陸續更新每個詳細部分，供大家參考，互相學習。
- BAT面試合集（Binder，組件化插件化，熱修復，AOP，QQ換膚，虛擬機，https，線程池原理，音視頻原理）
- 算法合集（Hash,KMP 等）
- 中小廠面試合集（內存泄漏，Handler，View，MVC.MVP.MVVM，）
- 大廠相關更新技術（Glide,數據庫，NDK）
- 面試小知識（java小知識）
- 設計模式（設計模式原則和分類）
- 數據結構（數據結構等等）
- 網絡編程（三次握手和四次握手，Volley，OKHttps,Retrofit）
- 源碼解析(屬性動畫實現原理等）
- 多線程解析（線程同步，進程線程）
- 性能優化（Webview,內存泄漏和內存溢出等）
（順手留下GitHub鏈接，需要獲取相關面試或者面試寶典核心筆記PDF等內容的可以自己去找）
https://github.com/xiangjiana/Android-MS
將一個復雜對象的構建與它的表示分離，使得同樣的構建過程可以創建不同的表示。
使用場景比如最常見的 AlertDialog,拿我們開發過程中舉例，比如 Camera 開發過程中，可能需要設置一個初始化的相機配置，設置攝像頭方向，閃光燈開閉，成像質量等等，這種場景下就可以使用建造者模式
裝飾者模式： 動態的給一個對象添加一些額外的職責，就增加功能來說，裝飾模式比生成子類更為靈活。裝飾者模式可以在不改變原有類結構的情況下曾強類的功能，比如 Java 中的 BufferedInputStream 包裝 FileInputStream，舉個開發中的例子，比如在我們現有網絡框架上需要增加新的功能，那么再包裝一層即可，裝飾者模式解決了繼承存在的一些問題，比如多層繼承代碼的臃腫，使代碼邏輯更清晰
觀察者模式，代理模式，門面模式，單例模式，生產者消費者模式
這個通過對比來描述，比如面向對象和面向過程的對比，針對這兩種思想的對比，還可以舉個開發中的例子，比如播放器的實現，面向過程的實現方式就是將播放視頻的這個功能分解成多個過程，比如，加載視頻地址，獲取視頻信息，初始化解碼器，選擇合適的解碼器進行解碼，讀取解碼后的幀進行視頻格式轉換和音頻重采樣，然后讀取幀進行播放，這是一個完整的過程，這個過程中不涉及類的概念，而面向對象最大的特點就是類，封裝繼承和多態是核心，同樣的以播放器為例，一面向對象的方式來實現，將會針對每一個功能封裝出一個對象，吧如說Muxer，獲取視頻信息，Decoder,解碼，格式轉換器，視頻播放器，音頻播放器等，每一個功能對應一個對象，由這個對象來完成對應的功能，并且遵循單一職責原則，一個對象只做它相關的事情
1.繼承 Thread 類實現多線程
2.實現 Runnable 接口
3.實現 Callable 接口
4.通過線程池
線程池的工作原理： 線程池可以減少創建和銷毀線程的次數，從而減少系統資源的消耗，當一個任務提交到線程池時
a. 首先判斷核心線程池中的線程是否已經滿了，如果沒滿，則創建一個核心線程執行任務，否則進入下一步
b. 判斷工作隊列是否已滿，沒有滿則加入工作隊列，否則執行下一步
c. 判斷線程數是否達到了最大值，如果不是，則創建非核心線程執行任務，否則執行飽和策略，默認拋出異常
Handler，Message，looper 和 MessageQueue 構成了安卓的消息機制，handler 創建后可以通過 sendMessage 將消息加入消息隊列，然后 looper不斷的將消息從MessageQueue 中取出來，回調到 Hander 的handleMessage 方法，從而實現線程的通信。
從兩種情況來說，第一在 UI 線程創建 Handler,此時我們不需要手動開啟 looper，因為在應用啟動時，在 ActivityThread 的 main 方法中就創建了一個當前主線程的looper，并開啟了消息隊列，消息隊列是一個無限循環，為什么無限循環不會 ANR?因為可以說，應用的整個生命周期就是運行在這個消息循環中的，安卓是由事件驅動的，Looper.loop 不斷的接收處理事件，每一個點擊觸摸或者 Activity 每一個生命周期都是在 Looper.loop 的控制之下的，looper.loop 一旦結束，應用程序的生命周期也就結束了。我們可以想想什么情況下會發生 ANR，第一，事件沒有得到處理，第二，事件正在處理，但是沒有及時完成，而對事件進行處理的就是looper，所以只能說事件的處理如果阻塞會導致 ANR，而不能說 looper 的無限循環會 ANR
另一種情況就是在子線程創建Handler,此時由于這個線程中沒有默認開啟的消息隊列，所以我們需要手動調用 looper.prepare(),并通過 looper.loop 開啟消息主線程 Looper 從消息隊列讀取消息，當讀完所有消息時，主線程阻塞。子線程往消息隊列發送消息，并且往管道文件寫數據，主線程即被喚醒，從管道文件讀取數據，主線程被喚醒只是為了讀取消息，當消息讀取完畢，再次睡眠。因此 loop的循環并不會對 CPU 性能有過多的消耗。
非靜態內部類會持有外部類的引用，如果非靜態內部類的實例是靜態的，就會長期的維持著外部類的引用，組織被系統回收，解決辦法是使用靜態內部類
匿名內部類同樣會持有外部類的引用，如果在線程中執行耗時操作就有可能發生內存泄漏，導致外部類無法被回收，直到耗時任務結束，解決辦法是在頁面退出時結束線程中的任務
Handler 導致的內存泄漏也可以被歸納為非靜態內部類導致的，Handler 內部
message 是被存儲在 MessageQueue 中的，有些 message 不能馬上被處理，存在的時間會很長，導致 handler 無法被回收，如果 handler 是非靜態的，就會導致它的外部類無法被回收，解決辦法是 1.使用靜態 handler，外部類引用使用弱引用處理 2.在退出頁面時移除消息隊列中的消息
根據場景確定使用Activity的Context還是Application的Context,因為二者生命周期不同，對于不必須使用 Activity 的 Context 的場景（Dialog）,一律采用 Application的 Context,單例模式是最常見的發生此泄漏的場景，比如傳入一個 Activity 的Context 被靜態類引用，導致無法回收
使用靜態 View 可以避免每次啟動 Activity 都去讀取并渲染 View，但是靜態 View會持有 Activity 的引用，導致無法回收，解決辦法是在 Activity 銷毀的時候將靜態View 設置為 null（View 一旦被加載到界面中將會持有一個 Context 對象的引用，在這個例子中，這個 context 對象是我們的 Activity，聲明一個靜態變量引用這個View，也就引用了 activity）
WebView 只要使用一次，內存就不會被釋放，所以 WebView 都存在內存泄漏的問題，通常的解決辦法是為 WebView 單開一個進程，使用 AIDL 進行通信，根據業務需求在合適的時機釋放掉
如 Cursor，File 等，內部往往都使用了緩沖，會造成內存泄漏，一定要確保關閉它并將引用置為 null
集合用于保存對象，如果集合越來越大，不進行合理的清理，尤其是入股集合是靜態的
bitmap 是比較占內存的，所以一定要在不使用的時候及時進行清理，避免靜態變量持有大的 bitmap 對象
很多需要register和unregister的系統服務要在合適的時候進行unregister,手動添加的 listener 也需要及時移除
1.使用更加輕量的數據結構： 如使用 ArrayMap/SparseArray替代HashMap,HashMap 更耗內存，因為它需要額外的實例對象來記錄 Mapping 操作，SparseArray 更加高效，因為它避免了 Key Value 的自動裝箱，和裝箱后的解箱操作
2.便面枚舉的使用，可以用靜態常量或者注解@IntDef 替代
3.Bitmap 優化:
a.尺寸壓縮： 通過 InSampleSize 設置合適的縮放
b.顏色質量： 設置合適的format,ARGB_6666/RBG_545/ARGB_4444/ALPHA_6，存在很大差異
c.inBitmap: 使用inBitmap屬性可以告知 Bitmap 解碼器去嘗試使用已經存在的內存區域，新解碼的Bitmap會嘗試去使用之前那張Bitmap在Heap中所占據的pixeldata內存區域，而不是去問內存重新申請一塊區域來存放 Bitmap。利用這種特性，即使是上千張的圖片，也只會僅僅只需要占用屏幕所能夠顯示的圖片數量的內存大小，但復用存在一些限制，具體體現在：在 Android 4.4 之前只能重用相同大小的 Bitmap 的內存，而 Android 4.4 及以后版本則只要后來的 Bitmap 比之前的小即可。使用inBitmap參數前，每創建一個 Bitmap 對象都會分配一塊內存供其使用，而使用了inBitmap參數后，多個 Bitmap 可以復用一塊內存，這樣可以提高性能
4.StringBuilder 替代 String: 在有些時候，代碼中會需要使用到大量的字符串拼接的操作，這種時候有必要考慮使用 StringBuilder 來替代頻繁的“+”
5.避免在類似 onDraw 這樣的方法中創建對象，因為它會迅速占用大量內存，引起頻繁的 GC 甚至內存抖動
6.減少內存泄漏也是一種避免 OOM 的方法
a: Service 設置成 START_STICKY kill 后會被重啟(等待 5 秒左右)，重傳 Intent，保持與重啟前一樣
b: 通過 startForeground 將進程設置為前臺進程， 做前臺服務，優先級和前臺應用一個級別，除非在系統內存非常缺，否則此進程不會被 kill
c: 雙進程 Service： 讓 2 個進程互相保護對方，其中一個 Service 被清理后，另外沒被清理的進程可以立即重啟進程
d: 用 C 編寫守護進程(即子進程) : Android 系統中當前進程(Process)fork 出來的子進程，被系統認為是兩個不同的進程。當父進程被殺死的時候，子進程仍然可以存活，并不受影響(Android5.0 以上的版本不可行）聯系廠商，加入白名單
e. 鎖屏狀態下，開啟一個一像素 Activity
app 冷啟動： 當應用啟動時，后臺沒有該應用的進程，這時系統會重新創建一個新的進程分配給該應用， 這個啟動方式就叫做冷啟動（后臺不存在該應用進程）。冷啟動因為系統會重新創建一個新的進程分配給它，所以會先創建和初始化 Application 類，再創建和初始化 MainActivity 類（包括一系列的測量、布局、繪制），最后顯示在界面上。
app 熱啟動： 當應用已經被打開， 但是被按下返回鍵、Home 鍵等按鍵時回到桌面或者是其他程序的時候，再重新打開該 app 時， 這個方式叫做熱啟動（后臺已經存在該應用進程）。熱啟動因為會從已有的進程中來啟動，所以熱啟動就不會走 Application 這步了，而是直接走 MainActivity（包括一系列的測量、布局、繪制），所以熱啟動的過程只需要創建和初始化一個 MainActivity 就行了，而不必創建和初始化Application
當點擊 app 的啟動圖標時，安卓系統會從 Zygote 進程中 fork 創建出一個新的進程分配給該應用，之后會依次創建和初始化 Application 類、創建MainActivity 類、加載主題樣式 Theme 中的 windowBackground 等屬性設置給 MainActivity 以及配置 Activity 層級上的一些屬性、再 inflate 布局、當 onCreate/onStart/onResume 方法都走完了后最后才進行 contentView 的 measure/layout/draw 顯示在界面上
Application 構造方法 –> attachBaseContext()–>onCreate –>Activity 構造方法 –>onCreate() –> 配置主體中的背景等操作 –>onStart() –> onResume() –> 測量、布局、繪制顯示
冷啟動的優化主要是視覺上的優化，解決白屏問題，提高用戶體驗，所以通過上面冷啟動的過程。能做的優化如下：
1、減少 onCreate()方法的工作量
2、不要讓 Application 參與業務的操作
3、不要在 Application 進行耗時操作
4、不要以靜態變量的方式在 Application 保存數據
5、減少布局的復雜度和層級
6、減少主線程耗時
原因在于加載主題樣式 Theme 中的 windowBackground 等屬性設置給MainActivity 發生在 inflate 布局當 onCreate/onStart/onResume 方法之前，而windowBackground 背景被設置成了白色或者黑色，所以我們進入 app 的第一個界面的時候會造成先白屏或黑屏一下再進入界面。解決思路如下
1. 給他設置 windowBackground 背景跟啟動頁的背景相同，如果你的啟動頁是張圖片那么可以直接給 windowBackground 這個屬性設置該圖片那么就不會有一閃的效果了
<style name=``"Splash_Theme"`
parent=``"@android:style/Theme.NoTitleBar"``>`
<item
name=``"android:windowBackground"``>@drawable/splash_bg</item>`
<item name=``"android:windowNoTitle"``>``true``</item>`</style> `2. 采用世面的處理方法，設置背景是透明的，給人一種延遲啟動的感覺。,將背景顏色設置為透明色,這樣當用戶點擊桌面 APP 圖片的時候，并不會"立即"進入APP，而且在桌面上停留一會，其實這時候 APP 已經是啟動的了，只是我們心機的把 Theme 里的 windowBackground 的顏色設置成透明的，強行把鍋甩給了手機應用廠商（手機反應太慢了啦）
<style name=``"Splash_Theme"`
parent=``"@android:style/Theme.NoTitleBar"``>`
<item name=``"android:windowIsTranslucent"``>``true``</item>`
<item name=``"android:windowNoTitle"``>``true``</item>`</style> `3. 以上兩種方法是在視覺上顯得更快，但其實只是一種表象，讓應用啟動的更快，有一種思路，將 Application 中的不必要的初始化動作實現懶加載，比如，在SpashActivity 顯示后再發送消息到 Application，去初始化，這樣可以將初始化的動作放在后邊，縮短應用啟動到用戶看到界面的時間
AsyncTask,HandlerThread,IntentServiceAsyncTask 原理： 內部是 Handler 和兩個線程池實現的，Handler 用于將線程切換到主線程，兩個線程池一個用于任務的排隊，一個用于執行任務，當 AsyncTask執行 execute 方法時會封裝出一個 FutureTask 對象，將這個對象加入隊列中，如果此時沒有正在執行的任務，就執行它，執行完成之后繼續執行隊列中下一個任務，執行完成通過 Handler 將事件發送到主線程。AsyncTask 必須在主線程初始化，因為內部的 Handler 是一個靜態對象，在 AsyncTask 類加載的時候他就已經被初始化了。在 Android3.0 開始，execute 方法串行執行任務的，一個一個來，3.0 之前是并行執行的。如果要在 3.0 上執行并行任務，可以調用executeOnExecutor 方法
HandlerThread 原理： 繼承自 Thread，start 開啟線程后，會在其 run 方法中會通過 Looper 創建消息隊列并開啟消息循環，這個消息隊列運行在子線程中，所以可以將 HandlerThread 中的 Looper 實例傳遞給一個 Handler，從而保證這個Handler 的 handleMessage 方法運行在子線程中，Android 中使用 HandlerThread的一個場景就是 IntentService
IntentService 原理： 繼承自 Service，它的內部封裝了 HandlerThread 和 Handler，可以執行耗時任務，同時因為它是一個服務，優先級比普通線程高很多，所以更適合執行一些高優先級的后臺任務，HandlerThread 底層通過 Looper 消息隊列實現的，所以它是順序的執行每一個任務?？梢酝ㄟ^ Intent 的方式開啟IntentService，IntentService 通過 handler 將每一個 intent 加入 HandlerThread 子線程中的消息隊列，通過 looper 按順序一個個的取出并執行，執行完成后自動結束自己，不需要開發者手動關閉
1.耗時的網絡訪問
2.大量的數據讀寫
3.數據庫操作
4.硬件操作（比如 camera)
5.調用 thread 的 join()方法、sleep()方法、wait()方法或者等待線程鎖的時候
6.service binder 的數量達到上限
7.system server 中發生 WatchDog ANR
8.service 忙導致超時無響應
9.其他線程持有鎖，導致主線程等待超時
10.其它線程終止或崩潰導致主線程一直等待
當 Android 端需要獲得數據時比如獲取網絡中的圖片，首先從內存中查（按鍵查找），內存中沒有的再從磁盤文件或 sqlite 中去查找，若磁盤中也沒有才通過網絡獲取
LruCache 中 Lru 算法的實現就是通過 LinkedHashMap 來實現的。LinkedHashMap繼承于HashMap，它使用了一個雙向鏈表來存儲 Map 中的 Entry 順序關系，對于 get、put、remove 等操作，LinkedHashMap 除了要做 HashMap 做的事情，還做些調整 Entry 順序鏈表的工作。
LruCache 中將 LinkedHashMap 的順序設置為 LRU 順序來實現 LRU 緩存，每次調用 get(也就是從內存緩存中取圖片)，則將該對象移到鏈表的尾端。調用 put 插入新的對象也是存儲在鏈表尾端，這樣當內存緩存達到設定的最大值時，將鏈表頭部的對象（近期最少用到的）移除。
JavaVM 是虛擬機在 JNI 層的代表，一個進程只有一個 JavaVM，所有的線程共用一個 JavaVM。
JNIEnv 表示 Java 調用 native 語言的環境，是一個封裝了幾乎全部 JNI 方法的指針。JNIEnv 只在創建它的線程生效，不能跨線程傳遞，不同線程的 JNIEnv 彼此獨立。native 環境中創建的線程，如果需要訪問 JNI，必須要調用 AttachCurrentThread關聯，并使用 DetachCurrentThread 解除鏈接。
方法： 對象繼承 Serializable 類即可實現序列化，就是這么簡單，也是它最吸引我們的地方
Parcelable 方式的實現原理是將一個完整的對象進行分解，用起來比較麻煩
1）在使用內存的時候，Parcelable 比 Serializable 性能高，所以推薦使用 Parcelable。
2）Serializable 在序列化的時候會產生大量的臨時變量，從而引起頻繁的 GC。
3）Parcelable 不能使用在要將數據存儲在磁盤上的情況，因為 Parcelable 不能很好的保證數據的持續性,在外界有變化的情況下。盡管 Serializable 效率低點，但此時還是建議使用 Serializable 。
4）android 上應該盡量采用 Parcelable，效率至上，效率遠高于 Serializable
（順手留下GitHub鏈接，需要獲取相關面試等內容的可以自己去找）
https://github.com/xiangjiana/Android-MS
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
