二、Android面試題
Android面試題包括Android基礎(chǔ)，還有一些源碼級(jí)別的、原理這些等。所以想去大公司面試，一定要多看看源碼和實(shí)現(xiàn)方式，常用框架可以試試自己能不能手寫實(shí)現(xiàn)一下，鍛煉一下自己。
（一）Android基礎(chǔ)知識(shí)點(diǎn)
1、四大組件是什么
Activity、Service、Content Provider、BroadCast Receiver
2、四大組件的生命周期和簡(jiǎn)單用法
Activity:
Service:
用法：
步驟1：創(chuàng)建子類繼承Service類。
需要重寫父類的onCreate()、onStartCommond()、onDestroy()和onBind()方法。
步驟2：構(gòu)建用于啟動(dòng)Service的Intent對(duì)象。
步驟3：調(diào)用startService()啟動(dòng)Service，調(diào)用stopService()停止服務(wù)。
步驟4：在AndroidManifest.xml里邊注冊(cè)Service。
Content Provider:
ContentProvider并沒有Activity那樣復(fù)雜的生命周期，只有簡(jiǎn)單的onCreate過程。ContentProvider是一個(gè)抽象類，當(dāng)實(shí)現(xiàn)自己的ContentProvider類，只需要繼承ContentProvider，并實(shí)現(xiàn)以下六個(gè)抽象方法。
onCreate()：執(zhí)行初始化工作。
insert(Uri,ContentValues)：插入新數(shù)據(jù)。
delete(Uri,String,String[])：刪除已有數(shù)據(jù)。
update(Uri,ContentValues,String,String[])：更新數(shù)據(jù)。
query(Uri,String[],String,String[],String)：查詢數(shù)據(jù)。
getType(Uri)：獲取數(shù)據(jù)的MIME類型。
BroadCast Receiver:
動(dòng)態(tài)注冊(cè)的廣播，生命周期僅限于當(dāng)前注冊(cè)的Activity，離開Activity時(shí)，一定要取消注冊(cè)，否則會(huì)拋出異常，但是該異常不會(huì)造成APP崩潰，但會(huì)造成內(nèi)存泄漏。離開Activity后，即使沒有取消注冊(cè)，該廣播也不會(huì)再接收消息。
靜態(tài)注冊(cè)廣播，相比較動(dòng)態(tài)注冊(cè)，即使退出app，廣播依然可用，通過<receiver>標(biāo)簽進(jìn)行靜態(tài)注冊(cè)廣播，會(huì)在執(zhí)行完onReceive方法后任意時(shí)間段內(nèi)銷毀，所以，我們不需要手動(dòng)進(jìn)行取消注冊(cè)。
3、Activity之間的通信方式
Intent傳值。
借助類的靜態(tài)變量。
借助全局變量/Application。
借助外部工具（SharePreference，SQLLite，F(xiàn)ile，Android剪切板）。
借助Service。
4、Activity各種情況下的生命周期
（1）、Activity第一次啟動(dòng)生命周期：onCreate-->onStart-->onResume
（2）、當(dāng)用戶打開新的Activity或切換到桌面時(shí)：回調(diào)onPause-->onStop。這里有一個(gè)特殊情況，就是當(dāng)打開的Activity是一個(gè)透明的Activity時(shí)，當(dāng)前Activity只會(huì)執(zhí)行onPause，不會(huì)執(zhí)行onStop。
（3）、當(dāng)用戶再次回到原Activity時(shí)，回調(diào)：onRestart-->onStart-->onResume。
（4）、當(dāng)用戶按下Back鍵時(shí)，回調(diào)：onPause-->onStop-->onDestroy。
（5）、當(dāng)Activity被系統(tǒng)回收，再次打開聲明周期與（1）相同，只是生命周期相同，并不是代表所有過程都一樣。
（6）、從這個(gè)生命周期來說，onCreate與onDestroy是配對(duì)的，分別標(biāo)識(shí)著Activity的創(chuàng)建和銷毀，并且只可能調(diào)用一次。
5、橫豎屏切換的時(shí)候，Activity 各種情況下的生命周期
（1）、不設(shè)置Activity的Android:configChanges時(shí)，切屏?xí)匦抡{(diào)用生命周期，切橫屏?xí){(diào)用一次，切豎屏?xí){(diào)用兩次。
（2）、設(shè)置Activity的Android:configChanges="orientation"時(shí)，切屏還是會(huì)重新調(diào)用生命周期，切橫豎屏都只調(diào)用一次生命周期。
（3）、設(shè)置Activity的Android:configChanges="orientation|keyboardHidden|screenSize"時(shí)，切屏不會(huì)重新調(diào)用各個(gè)生命周期，只會(huì)調(diào)用onConfigurationChanged方法。
6、Activity與Fragment之間生命周期比較
Fragment生命周期：
onAttach()
onCreate()
onCreateView()
onActivityCreate()? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ---以上相當(dāng)于Activity的onCreate方法。
onStart()? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ---相當(dāng)于Activity的onStart方法
onResume() ---相當(dāng)于Activity的onResume方法
onPause() ---相當(dāng)于Activity的onPause方法
onStop() ---相當(dāng)于Activity的onStop方法
onDestroyView()
onDestroy()
onDetach() ---相當(dāng)于Activity的onDestroy方法。
7、Activity上有Dialog的時(shí)候按Home鍵時(shí)的生命周期
無論頁(yè)面上是否有Dialog，按下Home鍵時(shí)都會(huì)回調(diào)：onPause-->onStop
8、兩個(gè)Activity 之間跳轉(zhuǎn)時(shí)必然會(huì)執(zhí)行的是哪幾個(gè)方法？
當(dāng)從ActivityA跳轉(zhuǎn)到ActivityB時(shí)，A會(huì)調(diào)用onPause()，然后B調(diào)用onCreate()，onStart()，onResume()，然后B此時(shí)覆蓋在A只是，A調(diào)用onStop()方法。
如果B是透明窗口，或?qū)υ捒驑邮剑筒粫?huì)調(diào)用A的onStop()方法。
如果B已經(jīng)存在在Activity棧中，B就不會(huì)調(diào)用onCreate()方法。
9、前臺(tái)切換到后臺(tái)，然后再回到前臺(tái)，Activity生命周期回調(diào)方法。彈出Dialog，生命值周期回調(diào)方法。
前臺(tái)切換到后臺(tái)，回調(diào)：onPause-->onStop
再回到前臺(tái)，回調(diào)：onRestart-->onStart-->onResume
彈出Dialog，回調(diào)：onPause
10、Activity的四種啟動(dòng)模式對(duì)比
Activity四種啟動(dòng)模式：standard、singleTop、singleTask、singleInstance
standard：標(biāo)準(zhǔn)模式，這也是系統(tǒng)默認(rèn)模式。每次啟動(dòng)Activity都會(huì)創(chuàng)建一個(gè)實(shí)例，不管這個(gè)實(shí)例是否已存在。
singleTop：棧頂復(fù)用模式。在這種模式下，如果新的Activity已經(jīng)存在于任務(wù)棧的棧頂，那么此Activity的實(shí)例不會(huì)被重新創(chuàng)建，同時(shí)它的onNewIntent方法會(huì)被回調(diào)。注意：這個(gè)Activity的onCreate、onStart方法并不會(huì)被系統(tǒng)調(diào)用，因?yàn)樗鼪]有發(fā)生改變；如果新的Activity的實(shí)例已存在，但并不在棧頂，那么會(huì)重新創(chuàng)建新的Activity實(shí)例。
singleTask：棧內(nèi)復(fù)用模式。這是一種單實(shí)例模式，如果任務(wù)棧內(nèi)存在該Activity的實(shí)例，那么就將這個(gè)實(shí)例之上的所有Activity出棧，將這個(gè)新的Activity實(shí)例置于棧頂。
singleInstance：?jiǎn)螌?shí)例模式。這是一種加強(qiáng)版的singleTask，此模式的Activity只能單獨(dú)運(yùn)行在一個(gè)任務(wù)棧中。
11、Activity狀態(tài)保存于恢復(fù)
（1）、onSaveInstanceState()方法用來在Activity被強(qiáng)制銷毀之前保存數(shù)據(jù)，onSaveInstanceState()方法攜帶一個(gè)Bundle類型的參數(shù)，Bundle提供了一系列方法用于保存數(shù)據(jù)。
（2）、onRestoreInstanceState()方法用來取的之前再onSaveInstanceState()方法中保存的值。
12、fragment各種情況下的生命周期
（1）、Fragment在Activity中replace
新替換的Fragment：onAttach-->onCreate-->onCreateView-->onViewCreated-->onActivityCreated-->onStart-->onResume
被替換的Fragment：onPause-->onStop-->onDestroyView-->onDestroy-->onDestach
（2）、Fragment在Activity中replace并addToBackStack
新替換的Fragment（沒有在BackStack中）：onAttach-->onCreate-->onCreateView-->onViewCreated-->onActivityCreated-->onStart-->onResume
新替換的Fragment（在BackStack中）：onCreateView-->onViewCreated-->onActivityCreated-->onStart-->onResume
被替換的Fragment：onPause-->onStop-->onDestroyView
（3）、Fragment在上述情況下進(jìn)入onResume后，則進(jìn)入了運(yùn)行狀態(tài)，以下四個(gè)生命周期將跟隨所屬的Activity一起調(diào)用：
onPause > onStop > onStart > onResume
13、Fragment狀態(tài)保存startActivityForResult是哪個(gè)類的方法，在什么情況下使用？
Fragment調(diào)用startActivityForResult--->HostCallbacks.onStartActivityFromFragment--->Fragment.startActivityFromFragment。
14、如何實(shí)現(xiàn)Fragment的滑動(dòng)？
ViewPager嵌套Fragment即可實(shí)現(xiàn)滑動(dòng)。
15、fragment之間傳遞數(shù)據(jù)的方式？
（1）、在創(chuàng)建的Fragment添加tag，使用bundle傳值。
（2）、使用接口回調(diào)傳值。
（3）、使用開源的EventBus傳值。
16、Activity 怎么和Service 綁定？
實(shí)現(xiàn)Service的onBind()方法以返回Service的實(shí)例給Activity。
17、怎么在Activity 中啟動(dòng)自己對(duì)應(yīng)的Service？
Activity通過bindService()跟Service綁定。
綁定成功后，Service會(huì)將代理對(duì)象通過回調(diào)的形式傳遞給MyServiceConnection，這樣我們就獲得了Service提供的代理對(duì)象。
18、service和activity怎么進(jìn)行數(shù)據(jù)交互？
（1）、binder+回調(diào)（listener）
主要思路：Activity將實(shí)例傳入Service，同時(shí)利用回調(diào)更新UI。
（2）、binder+Handler
主要思路：Service持有Activity的Handler對(duì)象，Service通過往該Handler send message的方式，達(dá)到通信的目的。
（3）、廣播（推薦LocalBroadCastManager）
主要思路：利用系統(tǒng)的LocalBroadCastManager、Service send message，Activity receive message;
（4）、開源組件（EventBus，otto）
（5）、AIDL
19、Service的開啟方式
（1）、采用start啟動(dòng)方式
步驟：定義一個(gè)類繼承Service
? 在Manifest.xml中配置Service
? 使用Context的startService(Intent)方法啟動(dòng)Service
? 不再使用時(shí)，使用stopService(Intent)方法停止Service
特點(diǎn)：
一旦服務(wù)開啟跟調(diào)用者（開啟者）就沒有關(guān)系了。
開啟者退出，開啟者掛了，服務(wù)還在后臺(tái)長(zhǎng)期的運(yùn)行。
開啟者不能調(diào)用服務(wù)里的方法。
（2）、使用bind啟動(dòng)方式
步驟：定義一個(gè)類繼承Service
? ? 在Manifest.xml中配置Service
? ? 使用Context的bindService(Intent,ServiceConnection,int)方法啟動(dòng)該Service
? ? 不再使用時(shí)，調(diào)用unbindService(ServiceConnection)方法停止服務(wù)。
20、請(qǐng)描述一下Service 的生命周期
21、談?wù)勀銓?duì)ContentProvider的理解
ContentProvider一般為存儲(chǔ)和獲取數(shù)據(jù)提供統(tǒng)一的接口，可以再不同的應(yīng)用程序之間共享數(shù)據(jù)。
之所以使用ContentProvider的原因：
（1）、ContentProvider提供了對(duì)底層數(shù)據(jù)存儲(chǔ)方式的抽象。比如下圖，底層使用SQLite數(shù)據(jù)庫(kù)，在用了ContentProvider封裝后，即使把數(shù)據(jù)庫(kù)換成MongoDB，也不會(huì)對(duì)上層數(shù)據(jù)使用層代碼產(chǎn)生影響。
（2）、Android框架中的一些類需要ContentProvider類型的數(shù)據(jù)。
（3）、ContentProvider為應(yīng)用間提供了一個(gè)安全的環(huán)境。它準(zhǔn)許你把自己的應(yīng)用的數(shù)據(jù)根據(jù)需求開放給其他應(yīng)用進(jìn)行增、刪、改、查，而不用擔(dān)心直接開放數(shù)據(jù)庫(kù)權(quán)限而帶來的安全問題。
22、說說ContentProvider、ContentResolver、ContentObserver 之間的關(guān)系
ContentProvider的作用是實(shí)現(xiàn)各個(gè)應(yīng)用程序之間的（跨應(yīng)用）數(shù)據(jù)共享。
一個(gè)應(yīng)用實(shí)現(xiàn)ContentProvider來提供內(nèi)容給別的應(yīng)用來操作，通過ContentResolver來操作別的應(yīng)用的數(shù)據(jù)，當(dāng)然在自己的應(yīng)用中也是可以的。
ContentObserver-----內(nèi)容觀察者，目的是觀察特定Uri引起的數(shù)據(jù)庫(kù)的變化，繼而做一些相應(yīng)的處理，它類似于數(shù)據(jù)庫(kù)技術(shù)中的觸發(fā)器，當(dāng)ContentObserver所觀察的Uri發(fā)生變化時(shí)，便會(huì)觸發(fā)它。
23、請(qǐng)描述一下廣播BroadcastReceiver的理解
廣播即一個(gè)全局的監(jiān)聽器，屬于Android四大組件。
Android廣播分為兩個(gè)角色：廣播發(fā)送者，廣播接收者。
應(yīng)用場(chǎng)景：
Android不同組件間的通信（含：應(yīng)用內(nèi)/不同應(yīng)用之間的）。
多線程通信。
與Android系統(tǒng)在特定情況下的通信。（如電話呼入時(shí)，網(wǎng)絡(luò)可用時(shí)）
采用的模型：
Android中的廣播采用了設(shè)計(jì)模式中的觀察者模式：基于消息的發(fā)布/訂閱事件模型。
模型中的角色：
消息訂閱者（廣播接收者）
消息發(fā)布者（廣播發(fā)送者）
消息中心（AMS，即Activity Manager Service）
24、廣播的分類
普通廣播
系統(tǒng)廣播
有序廣播
粘性廣播
App應(yīng)用內(nèi)廣播
25、廣播使用的方式和場(chǎng)景
（1）、靜態(tài)注冊(cè)
步驟：定義一個(gè)廣播接收器（繼承BroadcastReceiver）
? ? 在清單文件中注冊(cè)該廣播接收器? ?
? ? ?在java程序中使用廣播
（2）、動(dòng)態(tài)注冊(cè)
步驟：定義一個(gè)廣播接收器（繼承BroadcastReceiver）
? ? 動(dòng)態(tài)注冊(cè)廣播及使用
解除廣播
在清單文件中注冊(cè)該廣播。
26、在manifest 和代碼中如何注冊(cè)和使用BroadcastReceiver?
同上。
27、本地廣播和全局廣播有什么差別？
全局廣播：BroadcastReceiver是針對(duì)應(yīng)用間、應(yīng)用與系統(tǒng)間、應(yīng)用內(nèi)部進(jìn)行通信的一種方式
本地廣播：LocalBroadcaseReceiver僅在自身應(yīng)用內(nèi)發(fā)送接收廣播，也就是只有自己的應(yīng)用能收到，數(shù)據(jù)更加安全，廣播只在這個(gè)程序里，而且效率更高
28、BroadcastReceiver，LocalBroadcastReceiver 區(qū)別
同上。
29、AlertDialog,popupWindow,Activity區(qū)別
AlertDialog：用來提示用戶一些信息，用起來也比較簡(jiǎn)單，設(shè)置標(biāo)題內(nèi)容和按鈕即可。
popupWindow：就是一個(gè)懸浮在Activity上的窗口，可以用來展示任意布局。
activity：Activity是Android四大組件之一，可以用于顯示View。Activity是一個(gè)與用戶交互的模塊。
AlertDialog是非阻塞式對(duì)話框，AlertDialog彈出時(shí)，后臺(tái)還可以做事情；popupWindow是阻塞式對(duì)話框，popupWindow彈出時(shí)，程序會(huì)等待，在popupWindow退出前，程序一致處于等待，只有當(dāng)我們調(diào)用了dismiss方法后，popupWindow退出，程序才會(huì)向下執(zhí)行。
30、Application 和 Activity 的 Context 對(duì)象的區(qū)別
凡是跟UI相關(guān)的，都應(yīng)該使用Activity作為Context來處理；其他的一些操作，Service，Activity，Application等實(shí)例都可以。
31、Android屬性動(dòng)畫特性
（1）、作用對(duì)象進(jìn)行了擴(kuò)展：不只是View對(duì)象，甚至沒有對(duì)象也可以。
（2）、動(dòng)畫效果：不只是4種基本變換，還有其他動(dòng)畫效果。
（3）、作用領(lǐng)域：API11之后引入的。
32、如何導(dǎo)入外部數(shù)據(jù)庫(kù)?
（1）、將格式為.db的數(shù)據(jù)庫(kù)文件放到android項(xiàng)目assets目錄中；
（2）、在程序必要的時(shí)候，將其“拷貝”（文件讀?。┑紸ndroid程序的默認(rèn)的數(shù)據(jù)庫(kù)存儲(chǔ)目錄中，一般路徑為“data/data/項(xiàng)目包名/databases/”；
（3）、自定義SQLiteOpenHelp類，創(chuàng)建一個(gè)名字和步驟（1）中一樣的數(shù)據(jù)庫(kù)；
（4）、按照平常的邏輯，對(duì)數(shù)據(jù)庫(kù)進(jìn)行增刪改查。
33、LinearLayout、RelativeLayout、FrameLayout的特性及對(duì)比，并介紹使用場(chǎng)景。
（1）、RelativeLayout會(huì)讓子View調(diào)用兩次onMeasure，LinearLayout在有weight時(shí)，也會(huì)調(diào)用子View兩次onMeasure。
（2）、RelativeLayout的子View如果高度和RelativeLayout不同，則會(huì)引發(fā)效率問題，當(dāng)子View很復(fù)雜的時(shí)候，這個(gè)問題會(huì)更加嚴(yán)重。如果可以盡量使用padding代替margin。
（3）、在不影響層級(jí)深度的情況下，使用LinearLayout和FrameLayout而不是RelativeLayout。
（4）、能用兩層LinearLayout，盡量用一個(gè)RelativeLayout，在時(shí)間上此時(shí)RelativeLayout消耗更小。
34、談?wù)剬?duì)接口與回調(diào)的理解
接口回調(diào)：可以把使用實(shí)現(xiàn)了某一接口的類創(chuàng)建的對(duì)象的引用，賦給該接口聲明的接口變量，那么該接口變量就可以調(diào)用被類實(shí)現(xiàn)的接口方法。實(shí)際上，當(dāng)接口變量調(diào)用被類實(shí)現(xiàn)的接口方法時(shí)，就是通知響應(yīng)的對(duì)象調(diào)用接口的方法，這一過程稱為對(duì)象功能的接口回調(diào)。
35、回調(diào)的原理
（1）、定義回調(diào)接口，定義回調(diào)方法；
（2）、定義要設(shè)置回調(diào)機(jī)制的類，并是此類持有回調(diào)接口的指針；
（3）、在該類中初始化回調(diào)接口指針，并使用指針調(diào)用回調(diào)方法；
（4）、在該類中設(shè)置觸發(fā)時(shí)機(jī)及執(zhí)行的觸發(fā)事件函數(shù)。
36、寫一個(gè)回調(diào)demo
37、介紹下SurfView
SurfaceView指一個(gè)在表層的View對(duì)象。其他View是繪制在表層的上面，而SurfaceView充當(dāng)表層本身。
38、RecycleView的使用
https://blog.csdn.net/weixin_42190712/article/details/80404757
39、序列化的作用，以及Android兩種序列化的區(qū)別
序列化：將對(duì)象轉(zhuǎn)換為字節(jié)流
（1）、在使用內(nèi)存的時(shí)候，Parcelable比Serializable性能高，所以推薦使用Parcelable。
（2）、Serializable在序列化的時(shí)候會(huì)產(chǎn)生大量的臨時(shí)變量，從而引起頻繁的GC。
（3）、Parcelable不能使用在要將數(shù)據(jù)存儲(chǔ)在磁盤上的情況，因?yàn)镻arcelable不能很好的保證數(shù)據(jù)的持續(xù)性，在外界有變化的情況下。盡管Serializable效率有點(diǎn)低，但是還是推薦使用Serializable。
（4）、Serializable實(shí)現(xiàn)，只需要implements Serializable即可，這是給對(duì)象打一個(gè)標(biāo)記，系統(tǒng)會(huì)自動(dòng)將其序列化。
（5）、Parcelable實(shí)現(xiàn)，不僅需要implements Parcelable，還需要在類中添加一個(gè)靜態(tài)成員變量CREATOR，這個(gè)變量要實(shí)現(xiàn)Parcelable.Ccreator接口。
（6）、Parcelable性能比Serializable好，在內(nèi)存開銷方面比較小，所以在內(nèi)存間數(shù)據(jù)傳輸時(shí)，推薦使用Parcelable，如：Activity之間傳值；而Serializable在數(shù)據(jù)持久化方面方便保存，在網(wǎng)絡(luò)中傳輸時(shí)，使用Serializable，因?yàn)閍ndroid不同版本的Parcelable可能不同，所以不推薦使用Parcelable做數(shù)據(jù)持久化。
40、差值器
Interpolator負(fù)責(zé)控制動(dòng)畫變化的速率，使得基本動(dòng)畫能夠以勻速、加速、減速、拋物線速率等各種速率變化。
41、估值器
TypeEvaluator設(shè)置屬性值，從初始值過度到結(jié)束值的變化具體數(shù)值。
42、Android中數(shù)據(jù)存儲(chǔ)方式
（1）、使用SharePreference存儲(chǔ)
（2）、使用文件存儲(chǔ)
（3）、SQLite數(shù)據(jù)庫(kù)存儲(chǔ)
（4）、使用ContentProvider存儲(chǔ)數(shù)據(jù)
（5）、使用網(wǎng)絡(luò)存儲(chǔ)。
（二）Android源碼相關(guān)分析
1、Android動(dòng)畫框架實(shí)現(xiàn)原理
實(shí)現(xiàn)原理：每次繪制View時(shí)，ViewGroup中的drawChild函數(shù)獲取該View的Animation的Transformation值，然后調(diào)用canvas.concat(transformToApply.getMatrix())，通過矩陣運(yùn)算完成幀動(dòng)畫，如果動(dòng)畫沒有完成，就繼續(xù)調(diào)用invalidate()函數(shù)，啟動(dòng)下次繪制來驅(qū)動(dòng)動(dòng)畫，從而完成整個(gè)動(dòng)畫的繪制。
當(dāng)一個(gè)ChildView要重畫時(shí)，它會(huì)調(diào)用其他成員函數(shù)invalidate()函數(shù)將通知其ParentView這個(gè)ChildView要重畫。
這個(gè)過程一直遍歷到ViewRoot，當(dāng)ViewRoot收到這個(gè)通知后就會(huì)調(diào)用上面提到的ViewRoot中的draw函數(shù)從而完成繪制。
Android動(dòng)畫就是通過ParentView來不斷調(diào)整ChildView的畫布坐標(biāo)系來實(shí)現(xiàn)的。
https://blog.csdn.net/qq_32816979/article/details/79746150
2、Android各個(gè)版本API的區(qū)別
https://blog.csdn.net/qq_21399461/article/details/80277472
3、Requestlayout，onlayout，onDraw，DrawChild區(qū)別與聯(lián)系
requestLayout會(huì)導(dǎo)致調(diào)用measure()過程和layout()過程。說明：只是對(duì)View樹重新布局layout過程包括measure()過程和layout()過程，不會(huì)調(diào)用draw()過程，但不會(huì)重新繪制任何視圖包括該調(diào)用者本身。
onLayout()方法（如果該View是ViewGroup對(duì)象，需要實(shí)現(xiàn)該方法，對(duì)每個(gè)子視圖進(jìn)行布局。）
調(diào)用onDraw()方法繪制視圖本身（每個(gè)視圖都需要重載該方法，ViewGroup不需要實(shí)現(xiàn)該方法。）
drawChild()主要是draw viewGroup中的某個(gè)View
4、invalidate和postInvalidate的區(qū)別及使用
Android中實(shí)現(xiàn)View的更新有兩組方法，一組是invalidate，另外一組是postInvalidate，其中前者是在UI線程自身中使用，而后者是在非UI線程中使用。
invalidate是在handler中使用，postInvalidate可以直接在子線程中調(diào)用更新View。
5、Activity-Window-View三者的差別
Activity是Android四大組件之一，負(fù)責(zé)界面展示、用戶交互和邏輯處理。
Window就是負(fù)責(zé)界面展示以及交互的只能部門，就相當(dāng)于Activity的下屬，Activity的生命周期方法負(fù)責(zé)業(yè)務(wù)的處理。
View就是放在Window容器的元素，Window是View的載體，View是Window的具體展示。
6、談?wù)剬?duì)Volley的理解
Volley是Google推出的輕量級(jí)Android異步網(wǎng)絡(luò)請(qǐng)求框架和圖片加載框架。其適用于數(shù)據(jù)量小，通信頻繁的網(wǎng)絡(luò)操作。
主要特點(diǎn)：
（1）、擴(kuò)展性強(qiáng)。Volley大多數(shù)是基于接口的設(shè)計(jì)，可配置性強(qiáng)。
（2）、一定程度符合Http規(guī)范，包括返回ResponseCode(2xx,3xx,4xx,5xx)的處理，請(qǐng)求頭的處理，緩存機(jī)制的支持等。并支持重試及優(yōu)先級(jí)定義。
（3）、默認(rèn)Android2.3及以上基于HttpURLConnection，2.3以下基于HttpClient實(shí)現(xiàn)。
（4）、提供簡(jiǎn)便的圖片加載工具。
7、如何優(yōu)化自定義View
（1）、硬件加速就是使用GPU來代替CPU完成繪制的計(jì)算工作，它從工作分?jǐn)?，和繪制機(jī)制優(yōu)化來提升繪制速度。
（2）、如果我們?cè)谧远xView的時(shí)候，繪制操作不支持硬件加速，那么我們可以在自定義View中手動(dòng)關(guān)閉硬件加速。
8、低版本SDK如何實(shí)現(xiàn)高版本api？
Android提供了兩種注解方式避免編譯時(shí)報(bào)錯(cuò)。
@SuppressLint
@TargetApi
SuppressLint很顯然的意思是忽略Lint檢查，對(duì)于我們使用高版本的API來說，可以使用@SuppressLint("NewApi")的方式讓Lint在編譯時(shí)忽略所調(diào)用的API對(duì)版本的要求。而@TargetApi是忽略特定版本的API調(diào)用報(bào)錯(cuò)。
9、描述一次網(wǎng)絡(luò)請(qǐng)求的流程
（1）、通過URL找到IP
（2）、對(duì)IP結(jié)果建立TCP連接
（3）、向服務(wù)器發(fā)送數(shù)據(jù)
（4）、服務(wù)器解析，并返回
（5）、瀏覽器解析HTML
10、HttpUrlConnection 和 okhttp關(guān)系
HttpUrlConnection是一種多用途、輕量級(jí)的HTTP客戶端，使用它來進(jìn)行HTTP操作可以適用于大多數(shù)應(yīng)用程序。雖然HttpUrlConnection的API提供的比較簡(jiǎn)單，但是，同時(shí)使得我們可以更加容易地使用和擴(kuò)展它。從Android4.4開始HttpUrlConnection的底層采用的就是okHttp。
okhttp是高性能的http庫(kù)，支持同步、異步，而且實(shí)現(xiàn)了spdy，http2，websocket協(xié)議，api很簡(jiǎn)潔易用，和volley一樣實(shí)現(xiàn)了http協(xié)議的緩存。picasso就是利用okhttp的緩存機(jī)制實(shí)現(xiàn)其文件緩存的，實(shí)現(xiàn)的很優(yōu)雅，很正確；反例就是UIL(universal image loader)，自己做的文件緩存，而且不遵守http緩存機(jī)制。
11、Bitmap對(duì)象的理解
Bitmap的構(gòu)造方法不是共有的，因此外部不能通過new的方式來創(chuàng)建，不過可以Bitmap的createBitmap方法和BitmapFactory。
12、looper架構(gòu)
有消息循環(huán)的線程一般都會(huì)有一個(gè)looper。
Looper.myLooper()；獲取當(dāng)前的Looper。
Looper.getMainLooper()；獲取UI線程的Looper。
如果一個(gè)線程調(diào)用Looper.prepare()，那么系統(tǒng)就會(huì)自動(dòng)為該線程建立一個(gè)消息隊(duì)列，然后調(diào)用Looper.loop()；之后就進(jìn)入了消息循環(huán)，這個(gè)之后就可以發(fā)消息、取消息、和處理消息。這個(gè)如何發(fā)送消息和如何處理消息可以再其他線程中通過Handle來做。
13、ActivityThread，AMS，WMS的工作原理
AMS：統(tǒng)一調(diào)度所有應(yīng)用程序的Activity。
WMS：控制所有的Window的顯示與隱藏以及要顯示的位置。
ActivityThread：Android應(yīng)用主線程（UI線程）。
工作原理：
ActivityThread創(chuàng)建完新的進(jìn)程后，main函數(shù)被加載，然后執(zhí)行一個(gè)loop循環(huán)使當(dāng)前線程進(jìn)入消息循環(huán)，并作為主線程。接下來還會(huì)初始化很多必要的屬性。
AMS：AMS從系統(tǒng)運(yùn)行的角度來看，AMS可以分為Client端和Server端；
Client端運(yùn)行在各個(gè)app進(jìn)程，app進(jìn)程實(shí)現(xiàn)了具體的Activity，Service等，告訴系統(tǒng)有哪些Activity、Service等，并且調(diào)用系統(tǒng)接口來完成顯示。
Server端運(yùn)行在SystemServer進(jìn)程，是系統(tǒng)級(jí)別的ActivityManagerService的具體實(shí)現(xiàn)，其相應(yīng)Client端的系統(tǒng)調(diào)用請(qǐng)求，并且管理Client端各個(gè)App進(jìn)程的生命周期。
WMS：為窗口分配Surface。
? ? 管理Surface的顯示順序、尺寸和位置
? ? 管理窗口動(dòng)畫
? ? 輸入系統(tǒng)相關(guān)
14、自定義View如何考慮機(jī)型適配
（1）、盡量使用warp_parent、match_parent。
（2）、盡可能的使用RelativeLayout。
（3）、針對(duì)不同的機(jī)型，使用不同的布局文件放在對(duì)應(yīng)的目錄下，android會(huì)自動(dòng)匹配。
（4）、盡量使用點(diǎn)9的圖片。
（5）、使用與密度無關(guān)的像素單位dp、sp。
（6）、引入android的百分比布局。
（7）、切圖的時(shí)候切大分辨率的圖，應(yīng)用到布局中，在小分辨率的手機(jī)上也會(huì)有很好的顯示。
15、自定義View的事件
以點(diǎn)擊事件為例
（1）、一個(gè)監(jiān)聽內(nèi)部的接口，OnItemSelectListener。
（2）、接口內(nèi)部有一個(gè)onItemSelect方法，Activity中使用時(shí)，通過重寫該方法來實(shí)現(xiàn)事件的監(jiān)聽。
（3）、在控件中定義一個(gè)OnItemSelectListener接口的對(duì)象，并設(shè)置set方法。
16、AstncTask+HttpClient 與 AsyncHttpClient有什么區(qū)別？
AsyncHttpClient來自android-async-http庫(kù)是在Apach的HttpClient庫(kù)的基礎(chǔ)上開發(fā)構(gòu)建而成的，這里的異步，是指它所有的網(wǎng)絡(luò)請(qǐng)求都是在app的UI線程之外的獨(dú)立工作線程中執(zhí)行。而開發(fā)者通過利用Android的消息處理機(jī)制，把我們所編寫的回調(diào)函數(shù)放在這個(gè)回調(diào)函數(shù)的創(chuàng)建線程中執(zhí)行（一般是UI線程），所以使用起來非常方便，除了能用在開發(fā)普通App以外，還可以用來開發(fā)Service或后臺(tái)線程，android-async-http庫(kù)可以自己分辨是被用在哪種應(yīng)用下，不需要額外設(shè)置。
17、LaunchMode應(yīng)用場(chǎng)景
standard模式：默認(rèn)啟動(dòng)模式，每次啟動(dòng)Activity都會(huì)創(chuàng)建Activity的實(shí)例，并放入任務(wù)棧。
singleTop模式：棧頂模式，每次啟動(dòng)Activity如果Activity的實(shí)例正好處于棧頂，則重用該實(shí)例，否則，創(chuàng)建新的Activity實(shí)例，并放入任務(wù)棧。
singleTask模式：棧內(nèi)模式，啟動(dòng)Activity，如果Activity的實(shí)例存在于棧內(nèi)，則將該實(shí)例上部的所有Activity出棧，該實(shí)例處于棧頂，如果不存在，則創(chuàng)建新的實(shí)例，并放入任務(wù)棧。
singleInstance模式：棧內(nèi)單例模式，每次啟動(dòng)Activity，都會(huì)重新創(chuàng)建一個(gè)新的任務(wù)棧，并創(chuàng)建實(shí)例放入該任務(wù)棧。
https://blog.csdn.net/android_freshman/article/details/52948124
18、AsyncTask 如何使用?
（1）、新建內(nèi)部類繼承AsyncTask。
（2）、定義AsyncTask的三種泛型參數(shù)。
（3）、重寫doInBackground抽象方法。
（4）、重寫onPreExecute抽象方法。
（5）、重寫onProgressUpdate方法。
（6）、重寫onPostExecute方法。
（7）、在需要啟動(dòng)的地方調(diào)用execute()方法。
19、SpareArray原理
SpareArray采用兩個(gè)數(shù)組，用來存放key以及value值，核心思想就是通過折半查找來找到key對(duì)應(yīng)的位置，然后取出值，或者插入值。
20、請(qǐng)介紹下ContentProvider 是如何實(shí)現(xiàn)數(shù)據(jù)共享的？
（1）、定義自己的ContentProvider類，該類需要繼承android系統(tǒng)自帶的ContentProvider類。
（2）、在Manifest.xml中注冊(cè)ContentProvider。
（3）、其他程序使用ContentResolver來操作。
21、Android Service與Activity之間通信的幾種方式
（1）、Activity調(diào)用bindService(Intent service,ServiceConnection conn,int flags)方法，得到Service對(duì)象的一個(gè)引用，這樣Activity可以直接調(diào)用到Service中的方法，如果要主動(dòng)通知Activity，我們可以利用回調(diào)的方法。
（2）、Service向Activity發(fā)送消息，可以使用廣播，當(dāng)然Activity要注冊(cè)相應(yīng)的廣播接收器。比如，Service向多個(gè)Activity發(fā)送消息的時(shí)候，用這種方法更好。
22、IntentService原理及作用是什么？
IntentService是繼承于Service并處理異步請(qǐng)求的一個(gè)類，在IntentService中有一個(gè)工作線程來處理耗時(shí)操作，啟動(dòng)IntentService的方式和啟動(dòng)傳統(tǒng)Service一樣，同時(shí)，當(dāng)任務(wù)完成后，IntentService會(huì)自動(dòng)停止，而不需要我們?nèi)ナ謩?dòng)控制。另外，可以啟動(dòng)IntentService多次，而每一個(gè)耗時(shí)操作會(huì)以工作隊(duì)列的方式在IntentService的onHandleIntent回調(diào)方法中執(zhí)行，并且，每次只會(huì)執(zhí)行一個(gè)工作線程，執(zhí)行完第一個(gè)，再執(zhí)行第二個(gè)，以此類推。
作用：
（1）、省去了在Service中手動(dòng)開啟線程的麻煩；
（2）、當(dāng)操作完成時(shí)，不需要手動(dòng)停止Service；
（3）、方便使用。
23、說說Activity、Intent、Service 是什么關(guān)系
（1）、一個(gè)Activity通常是一個(gè)單獨(dú)的屏幕，每一個(gè)Activity都被實(shí)現(xiàn)為一個(gè)單獨(dú)的類，這些類都是從Activity基類中繼承而來。Activity類會(huì)顯示由視圖控件組成的用戶接口，并對(duì)視圖控件的事件作出響應(yīng)。
（2）、Intent的調(diào)用是用于屏幕間的切換。Intent描述應(yīng)用想要做什么。Intent數(shù)據(jù)結(jié)構(gòu)中兩個(gè)最重要的部分是動(dòng)作和動(dòng)作對(duì)應(yīng)的數(shù)據(jù)。
（3）、Service是運(yùn)行在后臺(tái)的組件，不于用戶進(jìn)行交互，可以運(yùn)行在自己的進(jìn)程中，也可以運(yùn)行在其他程序的上下文中。需要一個(gè)Context對(duì)象調(diào)用。
（4）、Activity與Service都是四大組件之一，存在相同的基類，他們之間互相調(diào)用需要通過Intent攜帶信息，即Intent相當(dāng)于一個(gè)消息傳送者。
24、ApplicationContext和ActivityContext的區(qū)別
首先Activity.this和getApplicationContext()返回的不是同一個(gè)對(duì)象，一個(gè)是當(dāng)前Activity的實(shí)例，一個(gè)是項(xiàng)目的Application的實(shí)例，它們各自的使用場(chǎng)景不同，this.getApplicationContext()取的是這個(gè)應(yīng)用程序的Context，它的生命周期伴隨著應(yīng)用程序的存在而存在；而Activity.this取的是當(dāng)前Activity的實(shí)例，它的生命周期只存活于當(dāng)前Activity，這兩者的生命周期是不同的。getApplicationContext()生命周期是整個(gè)應(yīng)用，當(dāng)應(yīng)用程序銷毀時(shí)，它才銷毀；Activity.this的生命周期是這個(gè)Activity，當(dāng)Activity銷毀時(shí)，它也銷毀。
25、SP是進(jìn)程同步的嗎?有什么方法做到同步？
一個(gè)進(jìn)程時(shí)，可以用SP存儲(chǔ)，但不支持多進(jìn)程，因?yàn)樗腔趩蝹€(gè)文件的，且app對(duì)SP做了緩存，不好同步。
考慮用ContentProvider讓SharePreference實(shí)現(xiàn)進(jìn)程同步。
（1）、ContentProvider每次操作都會(huì)getSP()，保證SP的一致性。
（2）、ContentProvider基于Binder，不存在進(jìn)程互斥，對(duì)同步也做了很好的封裝，不需要開發(fā)者額外實(shí)現(xiàn)。
26、談?wù)劧嗑€程在Android中的使用
在項(xiàng)目中比較常用的多線程操作：
（1）、Handler
（2）、AsyncTask
（3）、IntentService
27、進(jìn)程和 Application 的生命周期
進(jìn)程的生命周期，優(yōu)先級(jí)從高到底
（1）、前臺(tái)進(jìn)程，比如Activity的Resume狀態(tài)。
（2）、可見進(jìn)程，比如主Activity上彈出一個(gè)對(duì)話框，該Activity的進(jìn)程狀態(tài)就為可見進(jìn)程。
（3）、服務(wù)進(jìn)程，比如正在運(yùn)行的Service的狀態(tài)。
（4）、后臺(tái)進(jìn)程，比如Activity，按Home鍵之后的狀態(tài)。
（5）、空進(jìn)程，該進(jìn)程狀態(tài)主要用來緩存進(jìn)程，保存一些進(jìn)程的數(shù)據(jù)，方便下次啟動(dòng)的時(shí)候，直接從緩存讀取數(shù)據(jù)。
Application的生命周期：
（1）、onCreate在創(chuàng)建應(yīng)用程序時(shí)調(diào)用?？梢灾貙戇@個(gè)方法來實(shí)現(xiàn)實(shí)例化應(yīng)用程序單態(tài)，以及創(chuàng)建和實(shí)例化任何程序狀態(tài)變量和共享資源。
（2）、onLowMemory當(dāng)系統(tǒng)處于資源匱乏的時(shí)候，具有良好行為的應(yīng)用程序可以釋放額外的內(nèi)存。這個(gè)方法一般只會(huì)在后臺(tái)進(jìn)程已經(jīng)終止，但是前臺(tái)應(yīng)用程序仍然缺少內(nèi)存時(shí)調(diào)用?？梢灾貙戇@個(gè)處理程序來清空緩存或釋放不必要的資源。
（3）、onTrimMemory作為onLowMemory的一個(gè)特定于應(yīng)用程序的替代選擇，在Android4.0時(shí)引入。當(dāng)運(yùn)行時(shí)決定當(dāng)前應(yīng)用程序應(yīng)該嘗試減少其內(nèi)存開銷時(shí)調(diào)用，它包含一個(gè)level參數(shù)，用于提供請(qǐng)求的上下文。
（4）、onConfigurationChanged與Activity不同，在配置改變時(shí)，應(yīng)用程序?qū)ο蟛粫?huì)被終止和重啟。如果應(yīng)用程序使用的值依賴于特定的配置，則重寫這個(gè)方法來重新加載這些值，或在應(yīng)用程序級(jí)別處理配置改變。
28、封裝View的時(shí)候怎么知道view的大小
getMeasuredHeight()：獲取控件的實(shí)際高度，包括顯示的部分和超出屏幕的部分，它的值與屏幕無關(guān)。
getHeight()：獲取控件在屏幕中顯示的高度。
getMeasuredWidth()：與getMeasuredHeight()類似。
getWidth()：與getHeigth()類似。
29、RecycleView原理
RecycleView將onMeasure()，onLayout()交給了LayoutManager去處理，因此，RecyclerView設(shè)置不同的LayoutManager就可以達(dá)到不同的顯示效果，因?yàn)閛nMeasure()和onLayout()不一樣。
ItemDecoration是為了顯示每個(gè)item之間分隔樣式的。它本質(zhì)上就是一個(gè)Drawable。當(dāng)RecyclerView執(zhí)行到onDraw()，這時(shí)，如果重寫了該方法，就相當(dāng)于在RecyclerView上畫了一個(gè)Drawable表現(xiàn)的東西。而最后，在它的內(nèi)部還有一個(gè)叫g(shù)etItemOffsets()的方法，從字面來理解，它是用來偏移每個(gè)item視圖的，當(dāng)我們?cè)诿總€(gè)item之間強(qiáng)行插入繪畫一段Drawable，那么如果再用原來的邏輯去繪制item視圖，就會(huì)覆蓋掉Decoration，所以需要這個(gè)方法將每個(gè)item向后偏移，以免覆蓋分隔樣式。
ItemAnimation每個(gè)item在特定的情況下都會(huì)執(zhí)行的動(dòng)畫。說是特定情況，其實(shí)就是視圖在發(fā)生改變的時(shí)候，我們手動(dòng)調(diào)用notifyXXX()方法的時(shí)候。通常這個(gè)時(shí)候，我們要傳一個(gè)下標(biāo)，那么從這個(gè)下標(biāo)一直到最后，所有的item都要執(zhí)行這個(gè)動(dòng)畫。
Adapter首先是適配器，適配器的作用都是類似的，用于提供每個(gè)item視圖，并返回給RecyclerView作為其子布局添加到內(nèi)部。但是，與ListView不同的是，ListView的適配器是直接返回一個(gè)View，將這個(gè)View添加到ListView的內(nèi)部。而RecyclerView是返回一個(gè)ViewHolder并且不是直接將這個(gè)holder添加到視圖內(nèi)部，而是添加到一個(gè)緩沖區(qū)，在視圖需要的時(shí)候去緩沖區(qū)找到這個(gè)holder，再間接找到holder包裹的View。
每個(gè)ViewHolder內(nèi)部都包裹著一個(gè)View，并且ViewHolder必須繼承自RecyclerView.ViewHolder類。這主要是因?yàn)镽ecyclerView內(nèi)部的緩存結(jié)構(gòu)并不像ListView那樣緩存一個(gè)View，而是直接緩存一個(gè)ViewHolder，在ViewHolder內(nèi)部又持有一個(gè)View。既然緩存的是ViewHolder，那么當(dāng)然就所有的ViewHolder必須都繼承同一個(gè)類。
https://www.cnblogs.com/jiangbeixiaoqiao/p/5672766.html
30、AndroidManifest的作用與理解
作用：
（1）、描述app的包名：Android設(shè)備據(jù)此區(qū)分不同的app，如果每個(gè)app是一個(gè)人的話，那么包名就是這個(gè)人的名字（為了防止惡意軟件仿冒其他app，只有新的app包名和簽名均與就的app相同，才能升級(jí)）。
（2）、描述app使用的Android版本信息。
（3）、描述app本身的版本信息，這樣對(duì)于app兩個(gè)版本，系統(tǒng)可以區(qū)分哪個(gè)是新版本，哪個(gè)是舊版本。
（4）、描述應(yīng)用對(duì)外暴露的組件（或者叫接口）。
（5）、其他各種需要用文本直接告知系統(tǒng)的信息：包括權(quán)限，應(yīng)用主題等。
https://blog.csdn.net/wyzzgo/article/details/73556414
（三）常見的一些原理性問題
1、Handler機(jī)制和底層實(shí)現(xiàn)
Handler包括四個(gè)角色：
Handler：負(fù)責(zé)發(fā)送消息處理消息。
Message：消息實(shí)體對(duì)象，handler通過sendMessage將實(shí)體放入消息隊(duì)列中。
MessageQueue：存放消息的隊(duì)列。
Looper：消息輪詢器，不停地從消息隊(duì)列中取出消息交給handler處理。
在主線程創(chuàng)建Handler，在需要發(fā)送消息的地方創(chuàng)建Message，通過handler發(fā)送。這個(gè)消息回到MessageQueue中，然后Looper將這個(gè)消息取出交給handler處理。
Handler可以有多個(gè)，但是在同一線程中Looper和MessageQueue只有一個(gè)。
2、Handler、Thread和HandlerThread的差別
Thread：普通的異步線程。
Handler：異步更新UI的，更詳細(xì)的來說是用來做線程通信的，更新UI時(shí)是子線程與UI主線程之間的通信。
HandlerThread：子線程與子線程之間的通信。它內(nèi)部創(chuàng)建一個(gè)帶有Looper的線程，looper對(duì)象可以用于創(chuàng)建Handler類來進(jìn)行調(diào)度。
3、handler發(fā)消息給子線程，looper怎么啟動(dòng)？
Looper.prepare()啟動(dòng)Looper。
Looper.loop()停止Looper循環(huán)。
4、關(guān)于Handler，在任何地方new Handler 都是什么線程下?
默認(rèn)情況下，Android創(chuàng)建的線程沒有開啟消息循環(huán)Looper，主線程除外。
系統(tǒng)自動(dòng)為主線程創(chuàng)建Looper對(duì)象，開啟消息循環(huán)；
所以主線程中可以直接new Handler，但在子線程中不能直接new，子線程中需要：
5、ThreadLocal原理，實(shí)現(xiàn)及如何保證Local屬性？
當(dāng)需要多線程時(shí)，有個(gè)變量恰巧不需要共享，此時(shí)就不必使用Synchronized這么麻煩的關(guān)鍵字來鎖住，每個(gè)線程都相當(dāng)于在堆內(nèi)開辟一個(gè)空間，線程中帶有對(duì)共享變量的緩沖區(qū)，通過緩沖區(qū)將內(nèi)存中的共享變量進(jìn)行讀取和操作，ThreadLocal相當(dāng)于線程中的內(nèi)存，一個(gè)局部變量。每次可以對(duì)線程自身的數(shù)據(jù)讀取和操作，并不需要通過緩沖區(qū)與主內(nèi)存中的變量進(jìn)行交互。并不會(huì)像synchronized那樣修改主內(nèi)存中的數(shù)據(jù)，再將主內(nèi)存中的數(shù)據(jù)復(fù)制到線程內(nèi)的工作內(nèi)存。ThreadLocal可以讓線程獨(dú)占資源，存儲(chǔ)于線程內(nèi)部，避免線程阻塞造成CPU吞吐下降。
6、請(qǐng)解釋下在單線程模型中Message、Handler、Message Queue、Looper之間的關(guān)系
Handler獲取當(dāng)前線程中的looper對(duì)象，looper用來從存放Message的MessageQueue中取出Message，再由Handler進(jìn)行消息的分發(fā)和處理。
7、請(qǐng)描述一下View事件傳遞分發(fā)機(jī)制
事件分發(fā)需要View的三個(gè)重要方法共同完成：
（1）、dispatchTouchEvent(MotionEvent event)
返回值表示是否消費(fèi)了當(dāng)前事件。可能View本身的onTouchEvent方法消費(fèi)，也可能是子View的dispatchTouchEvent方法中消費(fèi)。返回true表示事件被消費(fèi)，本次事件終止。返回false表示View以及子View都沒有消費(fèi)事件，將調(diào)用父View的onTouchEvent方法。
（2）、onInterceptTouchEvent(MotionEvent event)
事件攔截，當(dāng)一個(gè)ViewGroup在接到MotionEvent事件序列的時(shí)候，首先會(huì)調(diào)用此方法判斷是否需要攔截。特別注意，這是ViewGroup特有的方法，View并沒有攔截方法。
返回值表示是否攔截事件傳遞，返回true表示攔截了事件，那么事件將不再向下分發(fā)，而是調(diào)用View本身的onTouchEvent方法。返回false表示不進(jìn)行攔截，事件向下分發(fā)到子View的dispatchTouchEvent方法。
（3）、onTouchEvent(MotionEvent event)
真正對(duì)MotionEvent進(jìn)行處理或消費(fèi)的方法。在dispatchTouchEvent中調(diào)用。
返回值返回true表示事件被消費(fèi)，本次的事件終止；返回false表示事件并沒有被消費(fèi)，將調(diào)用父View的onTouchEvent方法。
8、Touch事件傳遞流程
android的touch事件自上而下傳遞：經(jīng)過Activity->PhoneWindow->DectorView->ContentView->ViewGroup->ChildView
其中最主要的是Activity、ViewGroup和View的處理
9、事件分發(fā)中的onTouch 和onTouchEvent 有什么區(qū)別，又該如何使用？
onTouch方法優(yōu)先級(jí)高于onTouchEvent，會(huì)先觸發(fā)。假如onTouch方法返回false，會(huì)接著觸發(fā)onTouchEvent方法，反之，onTouchEvent方法并不會(huì)被調(diào)用。內(nèi)置諸如click事件的實(shí)現(xiàn)等都基于onTouchEvent方法，假如onTouch方法返回true，這些事件將不會(huì)被觸發(fā)。
https://blog.csdn.net/qq_26358311/article/details/79620964
10、View和ViewGroup分別有哪些事件分發(fā)相關(guān)的回調(diào)方法
11、View刷新機(jī)制
View更新一共有兩個(gè)方法：invalidate和postInvalidate，其中前者是在UI線程中使用，而后者是在非UI線程中使用。
12、View繪制流程
View的measure過程
ViewGroup的measure過程
View的layout過程
ViewGroup的layout過程
View的draw過程
ViewGroup的draw過程
13、自定義控件原理
View繪制的基本上是由measure()，layout()，draw()三個(gè)方法完成的。
https://blog.csdn.net/u012426327/article/details/77836069
14、自定義View如何提供獲取View屬性的接口？
（1）、在自定義View中定義一個(gè)接口。
（2）、類成員變量里聲明一個(gè)這個(gè)接口的引用。
（3）、寫一個(gè)方法并持有Activity實(shí)現(xiàn)的接口的實(shí)例。
（4）、在Activity里實(shí)現(xiàn)這個(gè)接口。
（5）、Activity里綁定XML中的自定義View屬性，并向XML創(chuàng)建的自定義View對(duì)象傳遞Activity實(shí)現(xiàn)的接口對(duì)象。
https://blog.csdn.net/hystudio_lzu/article/details/79135105
15、Android代碼中實(shí)現(xiàn)WAP方式聯(lián)網(wǎng)
https://blog.csdn.net/asce1885/article/details/7844159
16、AsyncTask機(jī)制
AsyncTask是android提供的一種異步消息處理機(jī)制，可以直接繼承AsyncTask，在類中繼承抽象方法執(zhí)行耗時(shí)任務(wù)，并且AsyncTask提供接口反饋當(dāng)前異步操作的進(jìn)度，可以通過接口實(shí)現(xiàn)UI更新。最終返回后臺(tái)執(zhí)行的結(jié)果給UI主線程，從而實(shí)現(xiàn)消息的異步處理。
17、AsyncTask原理及不足
AsyncTask原理：
AsyncTask內(nèi)部是通過線程池+Handler實(shí)現(xiàn)，構(gòu)造方法里邊new了兩個(gè)對(duì)象，在new WorkRunnable對(duì)象時(shí)通過result = doInBackground(mParams)給result賦值。然后調(diào)用postResult(result)方法，并把WorkRunnable對(duì)象當(dāng)做參數(shù)傳遞給FutureTask。由于那是Runnable對(duì)象開啟線程跑任務(wù)，跑完回調(diào)FutureTask的done()方法，這個(gè)方法又調(diào)用了postResultIfNotInvoked(get())方法。
不足：
（1）、線程池中已有128個(gè)線程，緩沖隊(duì)列已滿，假設(shè)此時(shí)向線程提交任務(wù)，將會(huì)拋出異常。
（2）、AsyncTask不會(huì)隨著Activity的銷毀而銷毀，直到doInBackground()方法運(yùn)行完成，假設(shè)我們的Activity銷毀之前沒有取消AsyncTask，這有可能造成AsyncTask崩潰，因?yàn)橛锌赡芩幚淼腣iew已經(jīng)被銷毀。
（3）、假設(shè)AsyncTask被聲明為Activity的非靜態(tài)內(nèi)部類，那么AsyncTask會(huì)保留一個(gè)對(duì)創(chuàng)建了AsyncTask的Activity的引用。
（4）、屏幕旋轉(zhuǎn)或Activity在后臺(tái)被系統(tǒng)殺掉等情況會(huì)造成Activity再一次創(chuàng)建，之前運(yùn)行的AsyncTask會(huì)持有銷毀之前的Activity的引用，這個(gè)引用已經(jīng)無效，這時(shí)調(diào)用onPostExecute()再去更新界面將不再生效。
https://www.cnblogs.com/lytwajue/p/7270299.html
18、如何取消AsyncTask？
我們可以隨時(shí)調(diào)用cancel(boolean)去取消這個(gè)加載任務(wù)，調(diào)這個(gè)方法會(huì)間接調(diào)用iscancelled并且返回true，調(diào)用cancel()后，在doInBackground()return后，我們將會(huì)調(diào)用onCancelled(Object)不再調(diào)用onPostExeecute(Object)方法，為了保證任務(wù)能夠更快的取消掉，應(yīng)該在doInBackground()方法中周期性的檢查isCancelled去判斷。
19、為什么不能在子線程更新UI？
Android的UI訪問是沒有加鎖的，多線程可以同時(shí)訪問更新操作同一個(gè)UI控件。也就是說訪問UI的時(shí)候，android系統(tǒng)中的控件都不是線程安全的，這將導(dǎo)致在多線程模式下，當(dāng)多個(gè)線程共同訪問更新操作同一個(gè)控件時(shí)容易發(fā)生不可控的錯(cuò)誤，而這是致命的。所以Android中規(guī)定只能在UI線程中更新UI，這相當(dāng)于從另一個(gè)角度給Android的UI訪問加了鎖，偽鎖。
20、ANR產(chǎn)生的原因是什么？
（1）、主線程執(zhí)行了耗時(shí)操作，比如數(shù)據(jù)操作或網(wǎng)絡(luò)請(qǐng)求。
（2）、其他進(jìn)程占用CPU導(dǎo)致本進(jìn)程得不到CPU時(shí)間片，比如其他進(jìn)程的頻繁讀寫操作可能會(huì)導(dǎo)致這個(gè)問題。
21、ANR定位和修正
可以查看data/anr/traces.txt查看ANR信息。
根本原因就是主線程被卡，導(dǎo)致應(yīng)用在5秒內(nèi)未響應(yīng)用戶的輸入事件。
修正：
將耗時(shí)操作改到子線程中執(zhí)行。
22、oom是什么？
oom指的是Out Of Memory，內(nèi)存溢出。
23、什么情況導(dǎo)致oom？
OOM可能的原因：
（1）、數(shù)據(jù)庫(kù)的cursor沒有及時(shí)關(guān)閉
（2）、構(gòu)造Adapter沒有使用緩存convertView
（3）、RegisterReceiver()和unRegisterReceiver()沒有成對(duì)出現(xiàn)
（4）、未關(guān)閉InputStream、OutputStream
（5）、Bitmap使用后未調(diào)用recycle()
（6）、static等關(guān)鍵字
（7）、非靜態(tài)內(nèi)部類持有外部類的引用，context泄漏
24、有什么解決方法可以避免OOM？
（1）、針對(duì)數(shù)據(jù)庫(kù)cursor沒有關(guān)閉的情況，如果查詢數(shù)據(jù)量少是不會(huì)造成內(nèi)存溢出的，但是數(shù)據(jù)量太大容易造成OOM，所以用完Cursor后應(yīng)該手動(dòng)調(diào)用close方法關(guān)閉cursor。
（2）、針對(duì)adapter沒有復(fù)用convertView的情況，除了要在getView方法里邊對(duì)convertView進(jìn)行判斷后復(fù)用，還應(yīng)該使用ViewHolder類來保存通過findViewById獲取的子控件地址值。
（3）、在Activity中注冊(cè)了廣播，但在Activity退出時(shí)沒有取消注冊(cè)的話可能會(huì)造成內(nèi)存溢出，需要手動(dòng)在相應(yīng)的位置進(jìn)行反注冊(cè)。
（4）、不關(guān)閉輸入輸出流的話就相當(dāng)于在內(nèi)存和硬盤一直存在著連接占用著資源，當(dāng)其他操作需要資源時(shí)，就會(huì)造成內(nèi)存溢出。
（5）、位圖在Android中占用的內(nèi)存是很大的，使用后如不及時(shí)回收的話會(huì)占用大量空間，所以針對(duì)位圖一般有以下幾種處理：
及時(shí)的調(diào)用recycle方法來手動(dòng)回收；
設(shè)置采樣率，有時(shí)候我們不需要把圖片完全顯示出來，這時(shí)候就要按照比例來進(jìn)行縮放，在我們得到采樣率后就可以將圖片縮小后再進(jìn)行加載，節(jié)省大量?jī)?nèi)存；
使用軟引用
（6）、應(yīng)該盡量避免static成員變量引用資源耗費(fèi)過多實(shí)例，比如Context
Context盡量使用Application Context，因?yàn)锳pplication Context生命周期比較長(zhǎng)，引用它不會(huì)出現(xiàn)內(nèi)存泄漏的問題
使用WeakReference代替強(qiáng)引用。
（7）、非靜態(tài)內(nèi)部類，上下文泄漏。
25、Oom 是否可以try catch？為什么？
一般不適合這樣處理。
java內(nèi)存中除了顯式地catch OOM之外還有更多有效的方式，比如SoftReference，WeakReference，硬盤緩存等。
如果OOM的原因不是在try中的代碼，那么catch依然會(huì)拋出OOM的異常。
26、內(nèi)存泄漏是什么？
內(nèi)存泄漏是指當(dāng)前程序不再使用到的內(nèi)存時(shí)，釋放內(nèi)存失敗而產(chǎn)生了無用的內(nèi)存消耗。內(nèi)存泄漏并不是指物理上的內(nèi)存消失，這里的內(nèi)存泄漏是指由程序分配的內(nèi)存但是由于程序邏輯的錯(cuò)誤而導(dǎo)致程序?qū)υ搩?nèi)存失去控制，使得內(nèi)存浪費(fèi)。
27、什么情況導(dǎo)致內(nèi)存泄漏？
（1）、資源對(duì)象沒有關(guān)閉導(dǎo)致內(nèi)存泄漏，如查詢數(shù)據(jù)庫(kù)沒有關(guān)閉cursor。
（2）、構(gòu)造adapter時(shí)，沒有使用convertView復(fù)用。
（3）、Bitmap對(duì)象不再使用時(shí)，未調(diào)用recycle()釋放內(nèi)存。
（4）、對(duì)象被生命周期長(zhǎng)的對(duì)象引用，如Activity被靜態(tài)集合引用導(dǎo)致Activity不能釋放。
28、如何防止線程的內(nèi)存泄漏？
將AsyncTask或Runnable類獨(dú)立出來或使用靜態(tài)內(nèi)部類，這樣可以避免內(nèi)存泄漏。
29、內(nèi)存泄露場(chǎng)的解決方法
（1）、在涉及使用Context時(shí)，優(yōu)先考慮Application Context。
（2）、對(duì)于需要在靜態(tài)內(nèi)部類中使用非靜態(tài)外部成員變量（如：Context、View），可以在靜態(tài)內(nèi)部類中使用弱引用來引用外部類的變量來避免內(nèi)存泄漏。
（3）、對(duì)于不再需要使用的對(duì)象，顯示的將其賦值為null，比如使用完Bitmap后先調(diào)用recycle()，再賦值為null.
（4）、保持對(duì)對(duì)象生命周期的敏感，特別注意單例、靜態(tài)對(duì)象、全局性集合等的生命周期。
（5）、對(duì)于生命周期比Activity長(zhǎng)的內(nèi)部類對(duì)象，并且內(nèi)部類中使用了外部類的成員變量，可以這樣做避免內(nèi)存泄漏：將內(nèi)部類改為靜態(tài)內(nèi)部類；靜態(tài)內(nèi)部類中使用弱引用來引用外部類的成員變量。
30、內(nèi)存泄漏和內(nèi)存溢出區(qū)別？
內(nèi)存泄漏的堆積就會(huì)導(dǎo)致內(nèi)存溢出。
內(nèi)存泄漏是指申請(qǐng)內(nèi)存后無法釋放已申請(qǐng)的內(nèi)存空間，內(nèi)存溢出是沒有足夠的內(nèi)存供申請(qǐng)者使用。
31、LruCache默認(rèn)緩存大小
手機(jī)內(nèi)存的1/8
32、ContentProvider的權(quán)限管理(解答：讀寫分離，權(quán)限控制-精確到表級(jí)，URL控制)
33、如何通過廣播攔截和abort一條短信？
https://blog.csdn.net/ljw124213/article/details/50492449
34、廣播是否可以請(qǐng)求網(wǎng)絡(luò)？
子線程可以，主線程超過10s引起anr
35、廣播引起anr的時(shí)間限制是多少？
10s
36、計(jì)算一個(gè)view的嵌套層級(jí)
view.getParent()遞歸就可以就算嵌套層級(jí)。
37、Activity棧
Activity棧記錄Activity的打開順序，先進(jìn)后出。
38、Android線程有沒有上限？
其實(shí)這個(gè)是沒有上限的，因?yàn)橘Y源都是限制在這個(gè)進(jìn)程中，無論開多少線程都是這么多的資源。至于開多少，完全取決于自己，合理開線程，不卡就行。
39、線程池有沒有上限？
有，跟內(nèi)存掛鉤。
40、ListView重用的是什么？
ListView重用的是View
41、Android為什么引入Parcelable？
在內(nèi)存使用上Parcelable比Serializable性能高。
42、有沒有嘗試簡(jiǎn)化Parcelable的使用？
as插件簡(jiǎn)化Parcelable使用。
（四）開發(fā)中常見的一些問題
1、ListView 中圖片錯(cuò)位的問題是如何產(chǎn)生的?
如果只是簡(jiǎn)單的展示list中的數(shù)據(jù)，而沒用convertView的復(fù)用機(jī)制和異步操作，就不會(huì)產(chǎn)生圖片錯(cuò)位的問題；重用但沒有異步，也不會(huì)出現(xiàn)這個(gè)問題，但程序會(huì)很卡。
圖片錯(cuò)位就是因?yàn)閏onvertView復(fù)用，同時(shí)異步加載圖片造成的。
2、混合開發(fā)有了解嗎？
混合開發(fā)的APP就是在app內(nèi)部?jī)?nèi)嵌一個(gè)輕量級(jí)的瀏覽器，一部分原生的功能改為HTML5開發(fā)，這部分功能不僅能夠在app不升級(jí)的情況下動(dòng)態(tài)更新，且可以在Android和IOS上運(yùn)行，讓用戶體驗(yàn)更好又可以節(jié)省開發(fā)的資源。
3、知道哪些混合開發(fā)的方式？說出它們的優(yōu)缺點(diǎn)和各自使用場(chǎng)景？（解答：比如:RN，weex，H5，小程序，WPA等。做Android的了解一些前端js等還是很有好處的)；
4、屏幕適配的處理技巧都有哪些?
布局盡量使用相對(duì)布局與線性布局
根據(jù)不同的分辨率的手機(jī)，提供不同的資源
限制橫豎屏切換。
5、服務(wù)器只提供數(shù)據(jù)接收接口，在多線程或多進(jìn)程條件下，如何保證數(shù)據(jù)的有序到達(dá)？
（1）、有序，多線程需要使用同步，多線程要使用進(jìn)程通信保障數(shù)據(jù)傳輸?shù)捻樞颉?/p>
（2）、到達(dá)，使用TCP可靠傳輸，服務(wù)器返回傳輸成功后才能傳輸下一個(gè)。
（3）、要在傳輸包中加入順序標(biāo)識(shí)。
6、動(dòng)態(tài)布局的理解
動(dòng)態(tài)加載布局有三種方式
第一種方式內(nèi)部調(diào)用的是第二種方式，第二種方式內(nèi)部調(diào)用的是第三種方式。
第三種方式分析：
參數(shù)一：要加載的布局文件。
參數(shù)二：父布局容器。
參數(shù)三：false表示不把布局文件添加到容器中，true表示把布局文件添加到容器中。
如果參數(shù)三設(shè)置了false，但添加了下面的代碼，表示和true一樣，都可以把布局添加到容器中。
7、怎么去除重復(fù)代碼？
（1）、對(duì)于Activity或者Fragment，抽取基類BaseActivity，BaseFragment，在基類中抽取一些所有子類都需要的方法，比如：initView、initListener、initData、initStatusBarColors、startActivity、showToast、checkNetConnected等方法。
（2）、對(duì)于xml布局文件，在多個(gè)頁(yè)面中同時(shí)出現(xiàn)的、可以重復(fù)利用的，就單獨(dú)抽出來，用include引入，比如：標(biāo)題欄，下一步按鈕，等等一些可以抽取出來的公共部分。
（3）、對(duì)于資源文件的引用，比如文字的text、文字大小textSize、文字顏色textColor，全部采用引用，不要全部寫死到布局中，對(duì)于文字text一律寫到string中、對(duì)于文字大小，一律寫入dimens中，對(duì)于文字顏色，一律寫入到color中，然后統(tǒng)一引入xml布局文件中。
8、畫出 Android 的大體架構(gòu)圖
9、Recycleview和ListView的區(qū)別
（1）、ViewHolder是用來保存視圖引用的類，無論是ListView還是RecyclerView。
在ListView中，ViewHolder需要自定義，使用ViewHolder的時(shí)候，每次getView時(shí)，都會(huì)調(diào)用findViewById，所以會(huì)造成卡頓。
RecyclerView使用RecyclerView.ViewHolder，解決了ListView的卡頓問題
（2）、ListView只能在垂直方向滑動(dòng)
RecyclerView可以水平和豎直方向滑動(dòng)
可以布局交叉網(wǎng)格風(fēng)格的列表，如瀑布流
支持網(wǎng)格風(fēng)格的列表。
（3）、RecyclerView增加了View動(dòng)畫
（4）、ListView通過AdapterView.OnItemClickListener接口來探測(cè)點(diǎn)擊事件。
RecyclerView則通過RecyclerView.OnItemTouchListener接口來探測(cè)觸摸事件。
https://blog.csdn.net/kimi985566/article/details/79839692
10、ListView圖片加載錯(cuò)亂的原理和解決方案
ListView圖片加載錯(cuò)亂是因?yàn)楫惒秸?qǐng)求和convertView復(fù)用造成的。
解決方案：
對(duì)imageView設(shè)置tag，并預(yù)設(shè)一張圖片。
11、動(dòng)態(tài)權(quán)限適配方案，權(quán)限組的概念
對(duì)于低于M版本的Android系統(tǒng)，沒有動(dòng)態(tài)權(quán)限的申請(qǐng)問題，動(dòng)態(tài)權(quán)限的申請(qǐng)流程對(duì)于低于M版本的android系統(tǒng)也不再適用。所以適配方案，首先要考慮低于M版本的Android系統(tǒng)，因此對(duì)于低于M版本的Android系統(tǒng)，在檢查權(quán)限時(shí)，直接返回true；對(duì)于高于M版本的系統(tǒng)，可以將動(dòng)態(tài)權(quán)限申請(qǐng)進(jìn)行一次封裝。
12、Android系統(tǒng)為什么會(huì)設(shè)計(jì)ContentProvider？
Android設(shè)計(jì)ContentProvider主要是為了實(shí)現(xiàn)跨進(jìn)程通信。
為了應(yīng)用程序之間交換數(shù)據(jù)，Android提供了ContentProvider，ContentProvider是不同應(yīng)用程序之間進(jìn)行數(shù)據(jù)交換的標(biāo)準(zhǔn)API，當(dāng)一個(gè)應(yīng)用程序需要把自己的數(shù)據(jù)暴露給其他應(yīng)用程序使用時(shí)，該應(yīng)用程序就可以通過提供ContentProvider來實(shí)現(xiàn)，其他應(yīng)用程序就可以通過ContentProvider來操作ContentProvider暴露出來的數(shù)據(jù)。
13、下拉狀態(tài)欄是不是影響activity的生命周期
不會(huì)影響Activity的生命周期。
14、如果在onStop的時(shí)候做了網(wǎng)絡(luò)請(qǐng)求，onResume的時(shí)候怎么恢復(fù)？
stop的時(shí)候被暫停，onStart的時(shí)候重新檢測(cè)恢復(fù)請(qǐng)求即可。
如果是恢復(fù)頁(yè)面請(qǐng)求后的頁(yè)面數(shù)據(jù)，分兩種，一、Activity已經(jīng)銷毀，那么使用saveInstanceState存儲(chǔ)數(shù)據(jù)，onRestoreInstanceState()恢復(fù)數(shù)據(jù)；二，Activity沒有銷毀，那就不需要恢復(fù)。
15、Bitmap 使用時(shí)候注意什么？
（1）、要使用合適的圖片規(guī)格（bitmap類型）
（2）、降低采樣率
（3）、復(fù)用內(nèi)存。
（4）、及時(shí)回收
（5）、壓縮圖片
（6）、盡量不要使用setImageBitmap或setImageResource或BitmapFactory.decodeResource來設(shè)置一張大圖，因?yàn)檫@些函數(shù)在完成decode后，最終都會(huì)通過java層調(diào)用createBitmap來完成，需要消耗更多的內(nèi)存，可以通過BitmapFactory.decodeStream方法，創(chuàng)建出一個(gè)Bitmap，再將其設(shè)置成ImageView的source。
http://www.itdecent.cn/p/fbf5a310788c
16、Bitmap的recycler()
Android有自己的垃圾回收機(jī)制，如果只使用了少量的圖片，回收與否關(guān)系不大?？墒侨粲写罅康腷itmap需要垃圾回收，那么垃圾回收的次數(shù)過于頻繁，會(huì)造成系統(tǒng)資源負(fù)荷。所以還是自己recycler()比較好。
一定要注意ImageView的圖片來源，然后進(jìn)行相應(yīng)的recycler
17、Android中開啟攝像頭的主要步驟
一共有兩種方式可以使用Android中的攝像頭
（1）、調(diào)用Android系統(tǒng)現(xiàn)有的攝像頭程序。
（2）、直接使用Android系統(tǒng)提供的攝像頭API。
啟動(dòng)安裝在手機(jī)上的攝像頭應(yīng)用程序。
使用靜態(tài)方法通過Camera.open()方法初始化相機(jī)對(duì)象。
18、ViewPager使用細(xì)節(jié)，如何設(shè)置成每次只初始化當(dāng)前的Fragment，其他的不初始化？
每次只初始化一個(gè)頁(yè)面的時(shí)候，就要注意了，需要采用懶加載的方式，因?yàn)樵陧?yè)面進(jìn)入前臺(tái)的時(shí)候，是會(huì)調(diào)用setUserVisiableHint()這個(gè)方法的，通過這個(gè)方法，我們可以獲得當(dāng)前頁(yè)面是否對(duì)用戶可見，并在對(duì)用戶可見的時(shí)候進(jìn)行初始化，這時(shí)還需要注意一點(diǎn)，setUserVisiableHint()這個(gè)方法的調(diào)用并不保證View等需要的東西是否已經(jīng)初始化成功，所以還需要再判斷一下。
19、點(diǎn)擊事件被攔截，但是想傳到下面的View，如何操作？
在父控件中加入請(qǐng)求父控件不攔截子控件的觸摸事件，自定義重寫子控件的dispatchTouchView();
就可以阻止父控件對(duì)子控件點(diǎn)擊事件的攔截，可以為子控件單獨(dú)設(shè)置點(diǎn)擊事件的響應(yīng)。
20、微信主頁(yè)面的實(shí)現(xiàn)方式
fragment嵌套。
21、微信上消息小紅點(diǎn)的原理
可以是UI設(shè)計(jì)是切出的帶有小紅點(diǎn)的圖，也可以自定義RadioButton繪制小紅點(diǎn)。
22、CAS介紹（這是阿里巴巴的面試題，我不是很了解，可以參考博客: CAS簡(jiǎn)介）
（1）、訪問服務(wù)：SSO客戶端發(fā)送請(qǐng)求訪問應(yīng)用系統(tǒng)提供的服務(wù)資源。
（2）、重定向認(rèn)證：SSO客戶端會(huì)重定向用戶請(qǐng)求到SSO服務(wù)器
（3）、用戶驗(yàn)證：驗(yàn)證用戶身份
（4）、生成票據(jù)：SSO服務(wù)器會(huì)產(chǎn)生一個(gè)隨機(jī)的Service Ticket
（5）、驗(yàn)證票據(jù)：SSO服務(wù)器驗(yàn)證票據(jù)Service Ticket的合法性，驗(yàn)證通過后，允許客戶端訪問服務(wù)。
（6）、傳輸用戶信息：SSO服務(wù)器驗(yàn)證票據(jù)通過后，傳輸用戶認(rèn)證結(jié)果信息給客戶端。
附；AndroidAPP開發(fā)框架技術(shù)體系大綱；
