一.Activity面試詳解

1.activity生命周期

4種狀態
running/paused/stopped/killed
activity生命周期
android進程優先級： 前臺/可見/服務/后臺/空

2.Android任務棧

3.activity啟動模式

onNewIntent何時調用：在singleTop和singleTask模式下，某個acitivity已經啟動。當再次調用的時候，才會調用

4.scheme跳轉協議

二. Fragment面試詳解

1.Fragment為什么被稱為第五大組件

為什么會成為第五大組件
使用頻率，有自己聲明周期，動態靈活加載到activity，更節省內存
加載到Activity的兩種方式
FragmentPagerAdpter和FragmentStatePagerAdapter的區別
前者使用于頁面較少的，后者適用于頁面較多的情況。

2.Fragment的聲明周期

3.Fragment之間的通信

fragment調用activity中方法 getActivity

4.FragmentManager

三. Service面試詳解

1.service應用場景，與Thread的區別

service基礎 是什么？區別？

2.啟動的兩種方式

startService
使用：
生命周期
onCreate->onStartCommand->onDestroy
多次調用startService,會多次調用onStartCommand函數，但不會調用onCreate
特點：與開始服務的組件沒有關系，開啟服務的組件銷毀，服務仍舊會繼續運行。
bindService
使用：
生命周期
onCreate->onBind->onUnBind->onDestroy
特點：與綁定服務的組件強綁定，綁定服務的組件如果銷毀，該服務也會銷毀。

四. Broadcast Receiver面試詳解

1.廣播

定義
場景 同一app的多個進程 不同app之間的組件之間的通信
種類 普通廣播，有序廣播，本地廣播

2.實現廣播 receiver

3.廣播實現機制

4.LocalBroadcastManager詳解

五. Binder機制

1.Linux內核基礎知識

進程隔離/虛擬地址空間
系統調用：內核空間，用戶空間

2.Binder通信機制介紹

為什么使用binder
binder通信模型
通信的兩個用戶進程：手機
binder驅動：基站
serviceManager:通訊錄
binder通信原理

3.AIDL

使用步驟

六.Android多線程

1.Handler面試詳解

1.1 什么是Handler

1.2 使用方法

1.3 機制原理

1.4 handler引起的內存泄露和解決方法

原因

靜態內部類持有外部類的應用，導致外部類activity無法被釋放

解決方法

handler內部持有外部acitvity的弱引用，并把handler改為靜態內部類，在activity的ondestroy中加入mHandler.removeCallback()

2.asynctask面試詳解

2.1.什么是asynctask 封裝了線程池和handler的異步框架

2.2.使用方法

2.3.內部原理

2.4.AsyncTask的注意事項

AsyncTask的對象必須在主線程中創建
execute方法必須在UI線程中加載
一個AsyncTask對象只能執行一次，即只能調用一次execute方法，否則會報一場
不適合做長時間耗時的操作，如果要執行長時間操作，最好使用線程池Excutor
避免內存泄露，解決內存泄露的方法跟handler一樣。

3.handlerThread面試詳解

3.1.是什么

產生的背景：為了解決 多次創建和銷毀線程是很消耗系統資源的。

3.2.源碼解析

4.intentService面試詳解

4.1.是什么

一個封裝了HandlerThread和handler的異步框架。每次任務完成會自動關閉service。普通service是運行在主線程的，無法處理耗時操作，intentService提供了這種機制。

4.2.使用方法

繼承intentService，覆寫onhandleIntent方法，在里面處理耗時操作。

4.3.源碼解析

可以啟動多個intentService，會將任務存儲在隊列中依次執行。
內部是利用handlerThread實現的。

七.view

1.繪制問題面試

1.1.view樹的繪制流程

1.2.measure

測量是從viewgroup從上到下依次遞歸測量的。viewgroup是抽象類，里面沒有重寫onMeasure，如果要自定義viewgroup類的時候必須重寫onMeasure，里面定義如何通過遍歷子類最后計算出viewgroup的大小。
onMeasure中有兩個參數，分別是widthMeasureSpec, heightMeasureSpec，每個measurespec包含兩個值，一個是specmode，一個是specsize。每個view的measurespec是由父控件的measurespec和當前view的layoutparam共同決定的。
如果為EXACTLY，說明view的layoutparam是具體的size，或者match_parent，此時specsize就是最后的size。
如果是AT_MOST，說明view的layoutparam是wrap_content，此時specsize需要子view根據自己的情況獲取最后的size。
也就是說當我們自定義view的時候，如果在布局文件中只需要設置具體size或者match_parent兩種屬性，那么就不需要重寫onMeasure。如果需要設置wrap_content，就需要重寫onMeasure，計算這種情況下的 控件的大小。
參考：http://www.lxweimin.com/p/d07f633c37e7

1.3 layout

onLayout()都是由ViewGroup的子類實現的，他的作用就是確定容器中每個子控件的位置，由于不同的容器有不容的布局策略，所以每個容器對onLayout()方法的實現都不同，onLayout()方法會遍歷容器中所有的子控件，然后計算他們左上右下的坐標值，最后調用child.layout()方法為子控件設置坐標

首先我們要明確布局的本質是什么，布局就是為 View 設置四個坐標值，這四個坐標值保存在View的成員變量 mLeft、mTop、mRight、mBottom 中，方便 View 在繪制（onDraw）的時候知道應該在那個區域內繪制控件。
自定義viewgroup必須實現onLayout，對子控件進行擺放。
參考：http://www.lxweimin.com/p/0b444c4c5cf6

1.4 draw

1.5 getWidth和getMeasureWidth區別

getMeasureWidth是在onMeasure執行完成后獲得的，而getWidth是在onLayout執行完成后獲得的

getMeasureWidth是onMeasure最后通過setMeasuredDimension設置大小后獲取的寬度。getWidth是onLayout后，mRight-mLeft獲得的。也就是說在onMeasure后可以通過onLayout改變控件的顯示寬度。

2.view的事件分發機制面試

2.1.為什么會有事件分發機制

由于view是樹形結構，點擊屏幕可能引起多個響應，為了確定哪個view進行響應，引入了事件分發機制。

2.2.三個重要的方法

dispatchTouchEvent，onInterceptTouchEvent，onTouchEvent
三者之間的偽代碼如下

    @Override
    public boolean dispatchTouchEvent(MotionEvent ev) {
    boolean consume = false;
    if(onInterceptTouchEvent(ev)){
        consume = onTouchEvent(ev);
    }else {
        consume = child.dispatchTouchEvent(ev);
    }
    return consume;
}

viewgroup接收到TouchEvent后會將事件通過dispatchTouchEvent分發。如果onInterceptTouchEvent返回true，則事件交由viewgroup的onTouchEvent來處理；如果返回false，則會交給子View的dispatchTouchEvent來處理。
默認情況下，viewgroup的onterinceptTouchEvent返回false，及不攔截事件。view沒有onterinceptTouchEvent，所以view只要已接收到事件，就會傳遞給自身的onTouchEvent。

滑動沖突解決

八.優化

1.內存溢出oom

當前占用的內存加上我們申請的內存資源超過了Davik虛擬機的最大內存限制就會拋出out of memory異常。
主要原因就是bitmap

1.1 有關bitmap

（1）圖片的存儲優化

圖片占用內存計算：圖片寬度 x 圖片高度 x 一個像素占用的內存大小

尺寸壓縮

（1）設置inJustDecodeBound=true,，使圖片能夠沒加載進內存就能夠獲取圖片的狂傲。
（2）設置imSampleSize，只要大于2，就能夠壓縮圖片占用內存。
（3）單純改變ImageView不會對圖片占用內存有任何的改變，必須針對bitmap本身的優化才起作用。

質量壓縮

（1）常見的PNG,JPG,WEBP等格式的圖片在設置到UI上之前需要經過解碼過程；
使用tinyPNG網站壓縮PNG
使用Webp
（2）使用RGB_565替代ARGB_8888可以降低圖片占用內存；
RGB_565一個像素占用兩個字節，而ARGB_8888一個像素占用四個字節

內存重用

使用inBitmap屬性，對內存進行重用。
4.cache
使用lru算法。
內部利用linkedHashMap實現，提供了get,put操作，緩存滿了之后提供trimToSize方法，移除較早的緩存對象，添加最新的對象

listview convertview/lru

1.2 避免在onDraw方法里面執行對象的創建

容易造成內存抖動，內存抖動積累到一定程度也會造成oom。因為頻繁內存抖動會將內存碎片化，從而當需要分配內存的時候,雖然總體上還有內存分配,但是由于這些內存不是連 續的,導致無法分配,系統就直接返回OOM了

1.3 使用多進程，需非常謹慎

2.內存抖動

短時間內創建大量對象，內存達到閾值后，觸發gc。內存抖動積累到一定程度也會造成oom。因為
頻繁內存抖動會將內存碎片化，從而當需要分配內存的時候,雖然總體上還有內存分配,但是由于這些內存不是連續的,導致無法分配,系統就直接返回OOM了

3.內存泄露：

3.1 java內存泄露基礎知識

指的是無用對象持續占有內存或無用對象的內存得不到及時釋放，造成的內存空間的浪費稱為內存泄露。

1.java內存分配策略

靜態存儲區（方法區）

存儲靜態變量，全局變量。編譯的時候已經分配好了，并且該區域存儲的變量在整個程序運行的過程中都存在。

棧區

方法中的局部變量，一些基本類型的變量，對象的引用變量。方法結束后自動釋放。

堆區

動態內存分配。存儲new出來的對象和數組，由java的垃圾回收器來管理

2.java如何管理內存

3.java中的內存泄露

3.2 android內存泄露

1.單例.

因為靜態變量存在與app的整個生命周期。如果靜態變量持有了某個activity的context，就會造成activity無法釋放。

2.非靜態內部類：

包括成員內部類，局部內部類和匿名內部類。因為非靜態內部類會持有外部類的引用

3.handler

4.避免使用static

5.資源未關閉造成的內存泄漏

6.AsyncTask造成的內存泄漏

android內存管理
    內存管理機制概述
    分配機制：為每個進程分配機制
    回收機制：
android內存管理機制
    分配機制：
    回收機制：根據進程優先級回收進程
內存管理機制的特點
    更少的占用內存
    在合適的時候，合理的釋放系統資源（不是說對象不需要了就立刻回收掉就是最好的內存管理，頻繁的釋放內存

會造成內存抖動，這樣會造成anr，oom，卡頓）
在系統內存緊張的時候，盡可能的釋放掉一些非重要資源

內存優化方法
    service完成任務后，盡量停止它
    在UI不可見的時候，盡可能的釋放掉一些非重要資源
    在系統內存緊張的時候，盡可能多的釋放掉一些非重要資源 onTrimMerory
    避免濫用Bitmap導致的內存浪費
    使用針對內存優化過的數據容器，避免使用枚舉
    避免使用依賴注入的框架
    使用zip對齊的apk
    使用多進程 例如開啟一個進程 定位，webview，推送    
內存溢出vs內存泄露
    內存溢出oom：
    內存泄漏：

4.UI卡頓

4.1 UI卡頓原理

60fps->16ms
Android系統每隔16ms觸發對android進行渲染，如果每次都能渲染成功，就能夠達到流暢的畫面，也就是每秒60幀畫面。

4.2 UI卡頓原因分析

1. 人為在UI線程中做輕微耗時操作，導致UI線程卡頓

2. 布局Layout過于復雜，或者過度繪制，無法在16ms內完成渲染。

3. 同一時間動畫執行的次數過多，導致CPU或GPU負載過重。

4. View頻繁的觸發measure、layout，導致measure、layout累計耗時過多及整個View頻繁的重新渲染。

5. 內存頻繁觸發GC過多，導致暫時阻塞渲染操作。gc過程會暫停所有線程的工作。

4.3 UI卡頓總結

(1)布局優化

消除冗余嵌套和過復雜的布局

Gong替換invisible

盡量使用weight代替長寬

如果存在非常復雜的嵌套，可以考慮使用自定義的view。減少measure和layout的次數

(2) 列表及adpter優化

在滑動過程中，只加載缺省圖片，停止的時候才加載圖片和數據

(3) 背景和圖片等內存分配優化

去掉不必要的背景
圖片要進行壓縮

(4) 避免ANR

5. 冷啟動優化

5.1什么是冷啟動

（1）冷啟動的定義

第一次啟動應用或者被進程殺死后重新啟動。
啟動之前，系統中沒有該應用的任何進程信息。

（2）冷啟動熱啟動的區別

a.啟動之前有沒有該應用的進程

b．要不要啟動Application的類

（3）冷啟動的時間的計算

這個時間值從應用啟動（創建進程開始計算），到完成視圖的第一次繪制（即Activity內容對用戶可見）為止。

5.2 冷啟動流程

Zygote進程匯總fock創建出一個新的進程
創建和初始化Application類，創建MainActivity類。
Inflate布局、當onCreate、onStart、onResume方法都走完
contentView的measure、layout、draw顯示在界面上

Application的構造器方法?attachBaseContext?onCreate()?Activity的構造方法?onCreate()?配置主題中背景等屬性?onStart?onResume?測量布局繪制顯示在界面上

5.3 啟動優化

(1) 減少onCreate方法的工作量

(2) 不要讓Application參與業務操作

(3) 不要在Application進行耗時操作

如果耗時操作過多，應用冷啟動后會出現白屏現象。
解決方法：http://www.lxweimin.com/p/436b91175826

(4) 不要以靜態變量的方式在application中保存數據

(5) 布局/mainThread

6 其他優化

6.1 android中不要用靜態變量存儲數據

App轉入后臺，由于內存過低，系統可能會將app進程殺死。但是系統為了用戶體驗，會將最后的Activity恢復，而此時app的進程使重新開啟的，靜態變量會重新初始化。該Activity如果應用了靜態變量，會造成nullpointer的錯誤

6.2 有關Sharepreference的問題

（1）不能跨進程同步

每個進程都有sharepreference的副本，只有在進程結束的時候才會同步。

（2）Sharepreference的文件過大的問題

如果文件過大，在獲取Sharepreference值的時候，會阻塞主線程，造成卡頓
如果文件過大，在解析Sharepreference的時候，會產生大量的臨時對象，造成頻繁GC，造成內存抖動，也會造成界面卡頓，甚至會發生oom

（3）內存對象序列化

序列化

將對象的狀態信息轉換為可以存儲活傳輸的形式的過程

Serializeble

產生大量臨時變量，引起頻繁gc，造成內存抖動，頁面卡頓，嚴重的會產生oom

Parcelable

android獨有的序列化方式。不能適用將數據存儲在磁盤的情況。適用的場合使進程間通信。使用內存的時候Parcelable性能更高。

java的垃圾回收機制

Java的一個重要有點就是通過垃圾收集器GC自動管理內存回收，程序員不需要通過調用函數釋放內存。但是并不是說java就不存在內存泄露。雖然簡化了程序員的工作，但同時也加重了jvm的工作，這也是Java程序運行速度較慢的原因之一。因為，gc為了能夠正確釋放對象，gc必須監控每一個對象的運行狀態，包括對象的申請、被引用、引用、賦值等，gc都需要進行監控。
從幾個方面來說：

1.什么時候回收？

a.在cpu空閑的時候

b.在堆內存滿了的時候

c.system.gc（）調用的時候嘗試回收

2.怎么判斷對象可以被回收

java和c#都是使用根搜索算法（GC Roots Tracing）判斷的。這個算法的基本思路就是通過一系列名為“GC Roots”的對象作為起點，從這些幾點開始向下搜索，搜索所走過的路徑成為引用鏈，當一個對象到GC Roots沒有任何引用鏈相連時，則證明此對象是不可用的。

九. Activity的窗口機制

每個activity含有一個phoneWindow對象，phonewindow中含有DecorView。phoneWindow是Activity和DecorView的橋梁。DecorView只有一個LinerLayout的子view。包含通知欄，標題欄，內容欄。setContentView就是將xml的view添加到內容欄位置。

事件分發：Activity接到事件后，會傳到Window對象中，window再將事件傳遞給DeocrView，Decorview傳給它唯一的子View，一個ViewGroup，然后遞歸傳遞下去。