分享幾個重要的Android面試題

說一下JAVA多態的理解，以及接繼承，和接口的理解

於哥在這裏只講多態，其餘本身上網體會

對於多態的定義

不一樣類的對象對統一函數作出不一樣對的響應或者動做。

做用

主要是消除類之間的耦合性，靈活性比較強，利於代碼的編寫和修改。尤爲在處理大量的運算和操做時，能夠靈活地簡化，替換或者是修改代碼！

三個必要條件

一、一個凳子（繼承extends）

二、重寫

三、父類引用指向子類對象

for example

測試結果：

測試結果

OKHTTP的 原理

1.同步和異步：

• 1.異步使用了Dispatcher來將存儲在 Deque 中的請求分派給線程池中各個線程執行。
• 2.當任務執行完成後，不管是否有異常，finally代碼段總會被執行，也就是會調用Dispatcher的finished函數，它將正在運行的任務Call從隊列runningAsyncCalls中移除後，主動的把緩存隊列向前走了一步。

2.鏈接池：

• 1.一個Connection封裝了一個socket，ConnectionPool中儲存s着全部的Connection，StreamAllocation是引用計數的一個單位
• 2.當一個請求獲取一個Connection的時候要傳入一個StreamAllocation，Connection中存着一個弱引用的StreamAllocation列表，每當上層應用引用一次Connection，StreamAllocation就會加一個。反之若是上層應用不使用了，就會刪除一個。
• 3.ConnectionPool中會有一個後臺任務定時清理StreamAllocation列表爲空的Connection。5分鐘時間，維持5個socket

3.選擇路線與創建鏈接

• 1.選擇路線有兩種方式：
  • 1.無代理，那麼在本地使用DNS查找到ip，注意結果是數組，即一個域名有多個IP，這就是自動重連的來源
  • 2.有代理HTTP：設置socket的ip爲代理地址的ip，設置socket的端口爲代理地址的端口
  • 3.代理好處：HTTP代理會幫你在遠程服務器進行DNS查詢，能夠減小DNS劫持。
• 2.創建鏈接
  • 1.鏈接池中已經存在鏈接，就從中取出(get)RealConnection，若是沒有命中就進入下一步
  • 2.根據選擇的路線(Route)，調用Platform.get().connectSocket選擇當前平臺Runtime下最好的socket庫進行握手
  • 3.將創建成功的RealConnection放入(put)鏈接池緩存
  • 4.若是存在TLS，就根據SSL版本與證書進行安全握手
  • 5.構造HttpStream並維護剛剛的socket鏈接，管道創建完成

4.職責鏈模式：緩存、重試、創建鏈接等功能存在於攔截器中網絡請求相關，主要是網絡請求優化。網絡請求的時候遇到的問題

線程同步的問題，經常使用的線程同步

1.sycn：保證了原子性、可見性、有序性

2.鎖：保證了原子性、可見性、有序性

• 1.自旋鎖:可使線程在沒有取得鎖的時候，不被掛起，而轉去執行一個空循環。
  • 1.優勢:線程被掛起的概率減小，線程執行的連貫性增強。用於對於鎖競爭不是很激烈，鎖佔用時間很短的併發線程。
  • 2.缺點:過多浪費CPU時間，有一個線程連續兩次試圖得到自旋鎖引發死鎖
• 2.阻塞鎖:沒獲得鎖的線程等待或者掛起，Sycn、Lock
• 3.可重入鎖:一個線程可屢次獲取該鎖，Sycn、Lock
• 4.悲觀鎖:每次去拿數據的時候都認爲別人會修改，因此會阻塞所有其餘線程 Sycn、Lock
• 5.樂觀鎖:每次去拿數據的時候都認爲別人不會修改，因此不會上鎖，可是在更新的時候會判斷一下在此期間別人有沒有去更新這個數據，可使用版本號等機制。cas
• 6.顯示鎖和內置鎖:顯示鎖用Lock來定義、內置鎖用synchronized。
• 7.讀-寫鎖:爲了提升性能，Java提供了讀

3.volatile

• 1.只能保證可見性，不能保證原子性
• 2.自增操做有三步，此時多線程寫會出現問題

4.cas

• 1.操做:內存值V、舊的預期值A、要修改的值B，當且僅當預期值A和內存值V相同時，將內存值修改成B並返回true，不然什麼都不作並返回false。
• 2.解釋:本地副本爲A，共享內存爲V，線程A要把V修改爲B。某個時刻線程A要把V修改爲B，若是A和V不一樣那麼就表示有其餘線程在修改V，此時就表示修改失敗，不然表示沒有其餘線程修改，那麼把V改爲B。
• 3.侷限:若是V被修改爲V1而後又被改爲V，此時cas識別不出變化，仍是認爲沒有其餘線程在修改V，此時就會有問題
• 4.侷限解決:將V帶上版本。

5.線程不安全究竟是怎麼回事：

• 1.一個線程寫，多個線程讀的時候，會形成寫了一半就去讀
• 2.多線程寫，會形成髒數據

ASYNCTASK和線程池，GC相關（怎麼判斷哪些內存該GC，GC算法）

1.Asynctask：異步任務類，單線程線程池+Handler

2.線程池：

• 1.ThreadPoolExecutor：經過Executors能夠構造單線程池、固定數目線程池、不固定數目線程池。

• 2.ScheduledThreadPoolExecutor：能夠延時調用線程或者延時重複調度線程。

  3.GC相關：重要

• 1.搜索算法：

  1.引用計數

  2.圖搜索，可達性分析

• 2.回收算法：

  1.標記清除複製：用於青年代

  2.標記整理：用於老年代

• 3.堆分區：

  1.青年區eden 80%、survivor1 10%、survivor2 10%

  2.老年區

• 4.虛擬機棧分區：

  1.局部變量表

  2.操做數棧

  3.動態連接

  4.方法返回地址

• 5.GC Roots:

  1.虛擬機棧(棧楨中的本地變量表)中的引用的對象

  2.方法區中的類靜態屬性引用的對象

  3.方法區中的常量引用的對象

  4.本地方法棧中JNI的引用的對象

JAVA類加載過程：

• 1.加載時機：建立實例、訪問靜態變量或方法、反射、加載子類以前
• 2.驗證：驗證文件格式、元數據、字節碼、符號引用的正確性
• 3.加載：根據全類名獲取文件字節流、將字節流轉化爲靜態儲存結構放入方法區、生成class對象
• 4.準備：在堆上爲靜態變量劃份內存
• 5.解析：將常量池中的符號引用轉換爲直接引用
• 6.初始化：初始化靜態變量

MVC、MVP、MVVM：

• 1.mvc:數據、View、Activity，View將操做反饋給Activity，Activitiy去獲取數據，數據經過觀察者模式刷新給View。循環依賴
  • 1.Activity重，很難單元測試
  • 2.View和Model耦合嚴重
• 2.mvp:數據、View、Presenter，View將操做給Presenter，Presenter去獲取數據，數據獲取好了返回給Presenter，Presenter去刷新View。PV，PM雙向依賴
  • 1.接口爆炸
  • 2.Presenter很重
• 3.mvvm:數據、View、ViewModel，View將操做給ViewModel，ViewModel去獲取數據，數據和界面綁定了，數據更新界面更新。
  • 1.viewModel的業務邏輯能夠單獨拿來測試
  • 2.一個view 對應一個 viewModel 業務邏輯能夠分離，不會出現全能類
  • 3.數據和界面綁定了，不用寫垃圾代碼，可是複用起來不舒服

APK瘦身:

1.classes.dex：經過代碼混淆，刪掉沒必要要的jar包和代碼實現該文件的優化

2.資源文件：經過Lint工具掃描代碼中沒有使用到的靜態資源

3.圖片資源：使用tinypng和webP，下面詳細介紹圖片資源優化的方案,矢量圖

4.SO文件將不用的去掉，目前主流app通常只放一個arm的so包

ANR的造成，各個組件上出現ARN的時間限制是多少

1.只要是主線程耗時的操做就會ARN 如io

2.broadcast超時時間爲10秒 按鍵無響應的超時時間爲5秒 前臺service無響應的超時時間爲20秒，後臺service爲200秒

SERIALIZABLE和PARCELABLE 的區別

1.P 消耗內存小

2.網絡傳輸用S 程序內使用P

3.S將數據持久化方便

4.S使用了反射 容易觸發垃圾回收 比較慢

SHAREDPREFERENCES源碼簡述

1.儲存於硬盤上的xml鍵值對，數據多了會有性能問題

2.ContextImpl記錄着SharedPreferences的重要數據，文件路徑和實例的鍵值對

3.在xml文件所有內加載到內存中以前，讀取操做是阻塞的，在xml文件所有內加載到內存中以後，是直接讀取內存中的數據

4.apply由於是異步的沒有返回值, commit是同步的有返回值能知道修改是否提交成功

5.多併發的提交commit時，需等待正在處理的commit數據更新到磁盤文件後纔會繼續往下執行，從而下降效率; 而apply只是原子更新到內存，後調用apply函數會直接覆蓋前面內存數據，從必定程度上提升不少效率。 3.edit()每次都是建立新的EditorImpl對象.

ANR的造成，各個組件上出現ARN的時間限制是多少

1.只要是主線程耗時的操做就會ARN 如io

2.broadcast超時時間爲10秒 按鍵無響應的超時時間爲5秒 前臺service無響應的超時時間爲20秒，後臺service爲200秒

APK瘦身:

1.classes.dex：經過代碼混淆，刪掉沒必要要的jar包和代碼實現該文件的優化

2.資源文件：經過Lint工具掃描代碼中沒有使用到的靜態資源

3.圖片資源：使用tinypng和webP，下面詳細介紹圖片資源優化的方案,矢量圖

4.SO文件將不用的去掉，目前主流app通常只放一個arm的so包