1.屏幕適配：
為了讓我們開發(fā)的程序能夠比較美觀的顯示在不同尺寸沃呢、分辨率、像素密度的設(shè)備上流纹。
1.使用約束布局或者相對(duì)布局
就可以根據(jù)各組件之間的特殊關(guān)系指定布局
2.適配不同尺寸避免寫死的尺寸值糜烹；wrap_content，match_parent漱凝，weight,利用dpi換算dp和px的值疮蹦。
3.圖片考慮使用可以拉伸的，xml自定義shape圖片碉哑，矢量圖，自動(dòng)拉伸.9圖
4.限定符亮蒋；最小寬度限定符扣典，屏幕方向限定符，布局別名慎玖。（要注意限定符的優(yōu)先級(jí)）
2.內(nèi)存溢出和內(nèi)存泄漏的區(qū)別贮尖，產(chǎn)生原因以及解決方案
概念與區(qū)別
內(nèi)存溢出：沒有足夠的內(nèi)存空間可以使用， 那就是內(nèi)存溢出趁怔。
內(nèi)存泄露：內(nèi)存泄漏時(shí)一個(gè)對(duì)象已經(jīng)不需要再使用了湿硝，但是其他的對(duì)象還持有該對(duì)象的引用，導(dǎo)致內(nèi)存不能被垃圾回收器回收润努。比如在內(nèi)部類持有外部類的引用時(shí)关斜。靜態(tài)變量，非靜態(tài)內(nèi)部類：持有外部類引用(handler)铺浇。內(nèi)存泄漏會(huì)導(dǎo)致OOM.
內(nèi)存泄露的解決方案：
1.不要在匿名內(nèi)部類中進(jìn)行異步操作
2.使用Context時(shí)痢畜，盡量使用Application 的 Context
3.盡量避免使用static 成員變量。
將Handler聲明為靜態(tài)類鳍侣。靜態(tài)類不持有外部類的對(duì)象丁稀，所以你的Activity可以隨意被回收。需要在Handler中增加一個(gè)對(duì)Activity的弱引用（WeakReference）倚聚。因?yàn)閔andler不在持有外部對(duì)象的引用
內(nèi)存溢出
1.內(nèi)存中加載的數(shù)據(jù)量過于龐大
2.集合類中有對(duì)對(duì)象的引用线衫，使用完后未清空，使得JVM不能回收惑折；
3.代碼中存在死循環(huán)或循環(huán)產(chǎn)生過多重復(fù)的對(duì)象實(shí)體授账；
內(nèi)存溢出的解決方案：
動(dòng)態(tài)回收內(nèi)存
優(yōu)化Dalvik虛擬機(jī)的堆內(nèi)存分配
在內(nèi)存引用上做處理，比如軟引用惨驶、弱引用等
3.事件分發(fā)
事件分發(fā)矗积，如果有多層嵌套的時(shí)候，讓那個(gè)控件消費(fèi)這個(gè)點(diǎn)擊事件
事件分發(fā)三個(gè)主要的方法分別是：dispatchTouchEvent（分發(fā)） onTouchEvent（消費(fèi)）
onInterceptTouchEvent（攔截）敞咧，只有容器才有onInterceptTouchEvent（攔截方法）
從Activity開始棘捣，進(jìn)入事件分發(fā)，Activity無論返回true或false都自己消費(fèi)，因?yàn)樗约壕褪琼攲诱Э郑幌到y(tǒng)消費(fèi)评疗，返回super向下分發(fā)，交給子viewgroup茵烈，如果viewgroup的dispatchTouchEvent（分發(fā)）返回true就消費(fèi)百匆，返回false交給上一層消費(fèi)，返回super交給 自身攔截事件呜投，攔截事件返回true的話自己消費(fèi)加匈，其他則繼續(xù)想下分發(fā)，子view的分發(fā)事件為true自己消費(fèi),返回false交給上一層
4.Handler機(jī)制
Handler 的主要作用是線程間通信仑荐，實(shí)現(xiàn)子線程與主線程的切換雕拼，通過 Handler 來異步更新UI，避免線程操作不安全的問題
總體流程：Handler向MessageQueue發(fā)送一條Message粘招，MessageQueue通過next方法把消息傳給Looper啥寇，Looper收到消息后開始處理，然后最終交給Handler自己去處理洒扎。
Message Queue(消息隊(duì)列)：負(fù)責(zé)存儲(chǔ)消息對(duì)象辑甜，按照先進(jìn)先出原則執(zhí)行，是由Message組成的一個(gè)隊(duì)列袍冷；
Message：消息類磷醋，包含了消息處理對(duì)象以及處理的數(shù)據(jù)等。
Looper：負(fù)責(zé)消息隊(duì)列的創(chuàng)建胡诗，從消息隊(duì)列中獲取消息執(zhí)行子檀，一個(gè)MessageQueue需要一個(gè)Looper；
Handler ：是Message的主要處理者乃戈，負(fù)責(zé)管理消息的發(fā)送和收到消息后的邏輯處理
在子線程創(chuàng)建handler:（因?yàn)閔andler必須要調(diào)用looper. Prepare()方法,所以必須要在子線程中獲取looper對(duì)象褂痰。）
方法一：在run方法創(chuàng)建一個(gè)handler對(duì)象，獲取主線程的looper來實(shí)現(xiàn)症虑。
方法二：在run方法通過looper.prepare()獲取looper對(duì)象缩歪，在發(fā)送消息完調(diào)用Looper.loop方法，不斷遍歷MessageQueue方法
主線程的Looper.loop為什么不可以造成死循環(huán)
android所有的UI處理都是通過handler消息機(jī)制處理的谍憔，每次處理都發(fā)送到消息隊(duì)列匪蝙，從消息隊(duì)列取出來才進(jìn)行執(zhí)行，如果消息隊(duì)列沒有就不執(zhí)行习贫，所以不會(huì)造成死循環(huán)逛球。
5.性能優(yōu)化：
卡頓優(yōu)化
1、布局優(yōu)化
一個(gè)頁(yè)面的顯示測(cè)量和繪制過程都是通過遞歸來完成的苫昌，如果層級(jí)太深颤绕，每增加一層則會(huì)增加更多的頁(yè)面顯示時(shí)間，所以布局的合理性就顯得很重要。
1.減少層級(jí)奥务。合理使用 RelativeLayout 和 LinerLayout,ConstraintLayout
2.Merge合并物独，減少層級(jí)，從而減少繪制時(shí)間氯葬。
3.使用 ViewStub來提高顯示速度挡篓。是看不見，占用資源非常小的視圖對(duì)象帚称，僅在需要時(shí)才加載布局官研，
4.布局復(fù)用〈扯茫可以通過include標(biāo)簽來提高復(fù)用戏羽。
5.盡可能少用wrap_content。在已知寬高為固定值時(shí)瞻坝，不用wrap_content 蛛壳。wrap_content會(huì)增加布局計(jì)算成本
2杏瞻、避免過度繪制
過度繪制是指在屏幕上的同一塊地方在一時(shí)間被繪制了多次所刀。從而浪費(fèi)了多余的 CPU 以及 GPU 資源。解決：移除 XML 中非必須的背景捞挥，移除 Window 默認(rèn)的背景浮创、按需要顯示占位背景圖片
3、合理的刷新機(jī)制
在應(yīng)用開發(fā)過程中砌函，因?yàn)閿?shù)據(jù)的變化斩披，需要刷新頁(yè)面來展示新的數(shù)據(jù)，但頻繁刷新會(huì)增加資源開銷讹俊，并且可能導(dǎo)致卡頓發(fā)生垦沉，因此，需要一個(gè)合理的刷新機(jī)制來提高整體的 UI 流暢度仍劈。合理的刷新需要注意以下幾點(diǎn)：
1.盡量減少刷新次數(shù)厕倍。
2.盡量避免后臺(tái)有高的 CPU 線程運(yùn)行。
3.縮小刷新區(qū)域贩疙。
內(nèi)存優(yōu)化
1讹弯、優(yōu)化內(nèi)存空間
Android 系統(tǒng)對(duì)每個(gè)應(yīng)用進(jìn)程也都分配了有限的內(nèi)存， GC 能更高效地回收不再需要使用的對(duì)象这溅，讓應(yīng)用存保持充足的可用內(nèi)存组民，使應(yīng)用更穩(wěn)定高效地運(yùn)行。常見做法如下：
1.對(duì)象引用悲靴。強(qiáng)引用臭胜、軟引用、弱引用、虛引用四種引用類型
2.減少不必要的內(nèi)存開銷庇楞。注意自動(dòng)裝箱榜配，增加內(nèi)存復(fù)用，比如有效利用系統(tǒng)自帶的資源吕晌、視圖復(fù)用蛋褥、對(duì)象池、Bitmap對(duì)象的復(fù)用睛驳。
3.使用最優(yōu)的數(shù)據(jù)類型烙心。比如針對(duì)數(shù)據(jù)類容器結(jié)構(gòu)，可以使用ArrayMap數(shù)據(jù)結(jié)構(gòu)乏沸，避免使用枚舉類型淫茵，使用緩存Lrucache等等。
4.圖片內(nèi)存優(yōu)化蹬跃〉海可以設(shè)置位圖規(guī)格，根據(jù)采樣因子做壓縮翁都，用一些圖片緩存方式對(duì)圖片進(jìn)行管理等等坐搔。
2、穩(wěn)定性優(yōu)化
Android 應(yīng)用的穩(wěn)定性定義很寬泛介汹，影響穩(wěn)定性的原因很多却嗡，比如內(nèi)存使用不合理、代碼異常場(chǎng)景考慮不周全嘹承、代碼邏輯不合理等窗价，都會(huì)對(duì)應(yīng)用的穩(wěn)定性造成影響。其中最常見的兩個(gè)場(chǎng)景是：Crash 和 ANR叹卷，這兩個(gè)錯(cuò)誤將會(huì)使得程序無法使用撼港，比較常用的解決方式如下：
1.提高代碼質(zhì)量。比如開發(fā)期間的代碼審核骤竹，看些代碼設(shè)計(jì)邏輯帝牡，業(yè)務(wù)合理性等。
3瘤载、耗電優(yōu)化
5.0 之后專門引入了一個(gè)獲取設(shè)備上電量消耗信息的 API:Battery Historian否灾。Battery Historian 是一款由 Google 提供的 Android 系統(tǒng)電量分析工具卖擅，和Systrace 一樣鸣奔，是一款圖形化數(shù)據(jù)分析工具，直觀地展示出手機(jī)的電量消耗過程惩阶，通過輸入電量分析文件挎狸，顯示消耗情況，最后提供一些可供參考電量?jī)?yōu)化的方法断楷。除此之外锨匆，還有一些常用方案可提供：
1.計(jì)算優(yōu)化，避開浮點(diǎn)運(yùn)算等冬筒。
2.避免 WaleLock 使用不當(dāng)恐锣。
3.使用 Job Scheduler。
4舞痰、安裝包大小優(yōu)化
減少安裝包大小的常用方案
1.代碼混淆土榴。使用proGuard 代碼混淆器工具，它包括壓縮响牛、優(yōu)化玷禽、混淆等功能赫段。
2.資源優(yōu)化。比如使用 Android Lint 刪除剩余資源矢赁，資源文件最少化等。
3.圖片優(yōu)化。比如利用 AAPT 工具對(duì) PNG 格式的圖片做壓縮處理志珍，降低圖片色彩位數(shù)等鬼佣。
4.避免重復(fù)功能的庫(kù)，使用 WebP圖片格式等额获。
5.插件化稠炬。比如功能模塊放在服務(wù)器上，按需下載咪啡，可以減少安裝包大小首启。
6.OKhttp使用、有哪些操作撤摸，原理和源碼詳解
網(wǎng)絡(luò)請(qǐng)求的框架用于代替HttpurlConnection和httpclient毅桃。可以用來文件上傳准夷，下載钥飞，加載圖片，網(wǎng)絡(luò)請(qǐng)求衫嵌，是根據(jù)build模式（將一個(gè)復(fù)雜對(duì)象的構(gòu)建與它的表示分離）读宙，鏈?zhǔn)秸{(diào)用，每一個(gè)方法的返回值類型都是當(dāng)前類的對(duì)象
優(yōu)點(diǎn)是：
1.支持同步楔绞、異步结闸。
2.緩存響應(yīng)數(shù)據(jù)（減少了重復(fù)的網(wǎng)絡(luò)請(qǐng)求）
3.自動(dòng)重連（底層是Socket，有自動(dòng)維護(hù)的socket連接池酒朵，減少了握手次數(shù)）
使用：
先用一個(gè)構(gòu)造好的OkHttpClient和Request獲取到一個(gè)Call桦锄，然后執(zhí)行call的異步或者同步方法取得Response或者處理異常。
五大攔截器：
一蔫耽、RetryAndFollowUpInterceptor （重定向攔截器）
1.創(chuàng)建 StreamAllocation對(duì)socket進(jìn)行管理结耀，比如連接復(fù)用，選擇連接自動(dòng)重連等
2.根據(jù)響應(yīng)碼做重定向和重試匙铡，重定向時(shí)如果地址不一致會(huì)釋放連接图甜，多重定向?yàn)?0次，超出拋異常
二鳖眼、BridgeInterceptor (橋接攔截器)
用來連接用戶請(qǐng)求信息 和 HTTP 請(qǐng)求
BridgeInterceptor 在請(qǐng)求階段黑毅，補(bǔ)全http header,
在響應(yīng)階段保存
Cookie
三、CacheInterceptor （緩存攔截器）
在緩存可用的情況下具帮，讀取本地的緩存的數(shù)據(jù)博肋，如果沒有直接去服務(wù)器讀取數(shù)據(jù)低斋，如果有，首先先判斷是否有緩存策略匪凡，然后判斷是否過期膊畴，如果沒有過期，直接從緩存中讀病游，如果過期了唇跨，你需要添加一些之前的頭部信息
注意事項(xiàng)：
只支持GET方式，并且需要服務(wù)器配合衬衬，通過header相關(guān)的頭來控制緩存
創(chuàng)建OkhttpClient時(shí)候需要配置Cache
四买猖、ConnectInterceptor (連接攔截器)
主要作用是打開了與服務(wù)器的鏈接，正式開啟了網(wǎng)絡(luò)請(qǐng)求滋尉。對(duì)socket封裝玉控，判斷連接是否可以重用，除了比較連接當(dāng)前的host狮惜，也可以比較路由信息高诺。最多空閑連接為5，最長(zhǎng)空閑時(shí)間為五分鐘
五碾篡、CallServerInterceptor(讀寫攔截器)
給服務(wù)器寫數(shù)據(jù)和讀取數(shù)據(jù)虱而；
寫頭部信息，寫body表單信息等等开泽；
它負(fù)責(zé)實(shí)現(xiàn)網(wǎng)絡(luò) IO牡拇，所有攔截器都要依賴它才能拿到響應(yīng)數(shù)據(jù)。
7.Retrofit使用穆律，常用注解惠呼、動(dòng)態(tài)代理以及原理
什么是Retrofit?
Retrofit 是一個(gè)Square開發(fā)的安卓客戶端請(qǐng)求庫(kù)。其中內(nèi)部封裝了okhttp庫(kù)众旗。Retrofit使用注解,能夠極大的簡(jiǎn)化網(wǎng)絡(luò)請(qǐng)求數(shù)據(jù)的代碼罢杉。
Retrofit常用注解：
@Query趟畏，@QueryMap贡歧，@Field，@FieldMap赋秀， @FormUrlEncoded利朵，@Path，@Url
@Query猎莲，@QueryMap
@Query主要用于Get請(qǐng)求數(shù)據(jù)绍弟，用于拼接在Url路徑后面的查詢參數(shù)，多個(gè)參數(shù)中間用著洼，隔開樟遣。
@QueryMap：主要的效果等同于多個(gè)@Query參數(shù)拼接而叼，主要也用于Get請(qǐng)求網(wǎng)絡(luò)數(shù)據(jù)。
@Field豹悬，@FieldMap
@Field的用法類似于@Query葵陵，主要不同的是@Field主要用于Post請(qǐng)求數(shù)據(jù)。@FieldMap的用法類似于@QueryMap瞻佛。
兩者主要區(qū)別是：如果請(qǐng)求為post實(shí)現(xiàn)脱篙，那么最好傳遞參數(shù)時(shí)使用@Field、@FieldMap和@FormUrlEncoded伤柄。因?yàn)锧Query和或QueryMap都是將參數(shù)拼接在url后面的绊困，而@Field或@FieldMap傳遞的參數(shù)時(shí)放在請(qǐng)求體的。
@FormUrlEncoded
如果是Post請(qǐng)求的話适刀，必須加@FromUrlEncoded注解秤朗。
@Path
@Path主要用于Get請(qǐng)求，用于替換Url路徑中的變量字符
@Url
@Url是動(dòng)態(tài)的Url請(qǐng)求數(shù)據(jù)的注解笔喉。
retrofit有幾個(gè)關(guān)鍵的地方.（原理）
1.用戶自定義的接口和接口方法.由動(dòng)態(tài)代理創(chuàng)建對(duì)象.
2.converter轉(zhuǎn)換器.把response轉(zhuǎn)換為一個(gè)具體的對(duì)象
3.注解的使用.
Retrofit中的動(dòng)態(tài)代理 ：
也就是一個(gè)網(wǎng)絡(luò)調(diào)用川梅，你只需要在你創(chuàng)建的接口里面通過注解進(jìn)行設(shè)置，然后通過retrofit創(chuàng)建一個(gè)api然后調(diào)用然遏，就可以自動(dòng)完成一個(gè)Okhttp的Call的創(chuàng)建贫途。
8.RxJava使用，可以實(shí)現(xiàn)哪些操作以及常用操作符
RxJava將鏈?zhǔn)骄幊毯彤惒浇Y(jié)合在一起,采用觀察者模式,和響應(yīng)式編程來實(shí)現(xiàn)待侵。RxJava 的異步可以隨著程序邏輯變得越來越復(fù)雜丢早，它依然能夠保持簡(jiǎn)潔。
RxJava 有四個(gè)基本概念：Observable (被觀察者)秧倾、 Observer (觀察者)怨酝、 subscribe (訂閱)、事件那先。
Observable 和 Observer 通過 subscribe() 方法實(shí)現(xiàn)訂閱關(guān)系农猬，從而 Observable 可以在需要的時(shí)候發(fā)出事件來通知 Observer。RxJava 的事件回調(diào)方法除了普通事件 onNext() 之外售淡，還定義了兩個(gè)特殊的事件：onCompleted() 和 onError()斤葱。
總結(jié)：
- 只有當(dāng)Observable被訂閱了subscriber)方法才會(huì)被執(zhí)行
- onCompleted方法里會(huì)把Subscription取消訂閱（unsubscribe）
- 如果調(diào)用了void onError(Throwable e)方法，那么onNext和onCompleted都不會(huì)執(zhí)行揖闸。會(huì)在onError調(diào)用之前揍堕，把Subscription取消注冊(cè)。
- 整個(gè)事件流不管是正常結(jié)束（onComplete）還是出現(xiàn)了異常（onError）汤纸，Subscription都會(huì)被取消注冊(cè)（unsubscribe）衩茸。
但是，由于我們可能執(zhí)行一些耗時(shí)操作贮泞，界面又被關(guān)閉了楞慈，所以還需要把subscription取消注冊(cè)
創(chuàng)建操作
用于創(chuàng)建Observable（被觀察者）的操作符
?Create（創(chuàng)建） — 通過調(diào)用觀察者（observer）的方法從頭開始創(chuàng)建一個(gè)Observable
?Just（僅僅） — 將一個(gè)對(duì)象或者一組對(duì)象轉(zhuǎn)換為一個(gè)會(huì)發(fā)出該對(duì)象或那些對(duì)象的Observable
?Start（開始） — 創(chuàng)建一個(gè)發(fā)出函數(shù)的返回值的Observable
?Timer（定時(shí)器） — 創(chuàng)建在一個(gè)指定的延遲之后發(fā)出單個(gè)數(shù)據(jù)項(xiàng)的Observable
變換操作
用于對(duì)Observable發(fā)出的數(shù)據(jù)進(jìn)行變換的操作符
?FlatMap（扁平映射） — 將Observable發(fā)出的數(shù)據(jù)變換為Observables集合幔烛，然后將這些 Observable發(fā)出的數(shù)據(jù)平坦化的放進(jìn)一個(gè)單獨(dú)的Observable，可以認(rèn)為是一個(gè)將嵌套的數(shù)據(jù)結(jié)構(gòu)展開的過程
?Map（映射） — 通過對(duì)序列的每一項(xiàng)都應(yīng)用一個(gè)函數(shù)變換Observable發(fā)出的數(shù)據(jù)囊蓝，實(shí)質(zhì)是對(duì)序列中的每一項(xiàng)執(zhí)行一個(gè)函數(shù)说贝，函數(shù)的參數(shù)就是這個(gè)數(shù)據(jù)項(xiàng)
過濾操作
用于從Observable發(fā)射的數(shù)據(jù)中選擇性的過濾一些數(shù)據(jù)的操作符
?Distinct（去重） — 抑制Observable發(fā)出的重復(fù)數(shù)據(jù)
?First（首選） — 只從Observable發(fā)出第一個(gè)數(shù)據(jù)項(xiàng)滿足條件的第一個(gè)數(shù)據(jù)項(xiàng)
?Last（末項(xiàng)） — 只發(fā)出Observable發(fā)出最后一條數(shù)據(jù)
組合操作
用于將多個(gè)Observable組合成一個(gè)單一的Observable的操作符
?Join - 當(dāng)在根據(jù)由另一Observable發(fā)射的項(xiàng)目定義的時(shí)間窗期間發(fā)出來自一個(gè)Observable的項(xiàng)目時(shí)，就將兩個(gè)Observable發(fā)射的數(shù)據(jù)組合成一個(gè)并發(fā)射
?Merge（合并） - 將多個(gè)Observable發(fā)射的數(shù)據(jù)組合并成一個(gè)
?Zip - 通過指定的函數(shù)將多個(gè)Observable的發(fā)射組合在一起慎颗，并根據(jù)此函數(shù)的結(jié)果為每個(gè)組合發(fā)出單個(gè)數(shù)據(jù)項(xiàng)
錯(cuò)誤處理操作
有助于從Observable的錯(cuò)誤通知中恢復(fù)的操作符
?Catch（捕獲） — 繼續(xù)序列操作乡恕，將錯(cuò)誤替換為正常的數(shù)據(jù)，從onError通知中恢復(fù)
?Retry（重試） — 如果Observable發(fā)射了一個(gè)onError通知俯萎，重新訂閱它傲宜，希望它將完成并沒有錯(cuò)誤
輔助操作
用于處理Observable的操作符
?Delay — 延遲一段時(shí)間發(fā)射結(jié)果數(shù)據(jù)
?ObserveOn（觀察在） — 指定Observer觀察Observable的調(diào)度器（Scheduler）（工作線程）
?Serialize（序列化） — 強(qiáng)制Observable按次序發(fā)射數(shù)據(jù)并且功能是有效的
?Subscribe（訂閱） — 收到Observable發(fā)射的數(shù)據(jù)和通知后執(zhí)行的操作
?SubscribeOn（訂閱在） — 指定Observable應(yīng)該在哪個(gè)調(diào)度器上執(zhí)行
?Timeout（超時(shí)） — 如果過了指定的一段時(shí)間沒有發(fā)射數(shù)據(jù)，則發(fā)射錯(cuò)誤通知
背壓操作
?backpressure operators - 為了應(yīng)對(duì)觀察者消費(fèi)事件比被觀察者生產(chǎn)事件更快夫啊，所以需要背壓
31函卒、自定義View
通常自定義view分為
1.繼承現(xiàn)有控件，對(duì)其控件的功能進(jìn)行拓展撇眯。
2.將現(xiàn)有控件進(jìn)行組合报嵌，實(shí)現(xiàn)功能更加強(qiáng)大控件。
3.重寫View實(shí)現(xiàn)全新的控件
一般當(dāng)我們遇到了原生控件無法滿足我們現(xiàn)有的需求的時(shí)候熊榛，我們就可以創(chuàng)建一個(gè)全新的View來實(shí)現(xiàn)我們所需要的功能锚国。創(chuàng)建一個(gè)全新View實(shí)現(xiàn)自定義控件，無非分成這么幾步：
1.在OnMeasure（）方法中玄坦，測(cè)量自定義控件的大小血筑，使自定義控件能夠自適應(yīng)布局各種各樣的需求。
將 MeasureSpec 經(jīng)過自身處理后, 分發(fā)到下層子 View
View 測(cè)量流程是父 View 先測(cè)量子 View煎楣，等子 View 測(cè)量完了豺总，再來測(cè)量自己。在ViewGroup 測(cè)量子 View 的入口就是 measureChildWithMargins
子 View 確定了大小之后, 再回到父容器中
父容器結(jié)合子 View 大小和 自身布局特性 來確定自己的大小, 一直回到頂層
2.draw過程
3.1择懂，背景繪制
4.2喻喳，對(duì)View的內(nèi)容進(jìn)行繪制
5.3，對(duì)當(dāng)前View的所有子View進(jìn)行繪制
6.4困曙，對(duì)View的滾動(dòng)條進(jìn)行繪制
7.在OnDraw（）方法中表伦，利用Canvas（畫布）與Paint（畫筆）來繪制要顯示的內(nèi)容。
8.在OnLayout（）方法中來確定控件顯示位置赂弓。
measure（） 方法中我們已經(jīng)測(cè)量出View的大小绑榴，根據(jù)這些大小，我們接下來就需要確定 View 在父 View 的位置進(jìn)行排版布局盈魁，這就是layout 作用。
對(duì) View 進(jìn)行排版布局窃诉，還是要看父 View杨耙，也就是 ViewGroup赤套。
10.在OnTouchEvent（）方法處理控件的觸摸事件。
進(jìn)程間通信：
一珊膜、使用 Intent
1.Activity容握，Service，Receiver 都支持在 Intent 中傳遞 Bundle 數(shù)據(jù)车柠，而 Bundle 實(shí)現(xiàn)了 Parcelable 接口剔氏，可以在不同的進(jìn)程間進(jìn)行傳輸。
2.在一個(gè)進(jìn)程中啟動(dòng)了另一個(gè)進(jìn)程的 Activity竹祷，Service 和 Receiver 谈跛，可以在 Bundle 中附加要傳遞的數(shù)據(jù)通過 Intent 發(fā)送出去。
二塑陵、使用文件共享
1.Windows 上感憾，一個(gè)文件如果被加了排斥鎖會(huì)導(dǎo)致其他線程無法對(duì)其進(jìn)行訪問，包括讀和寫令花；而 Android 系統(tǒng)基于 Linux 阻桅，使得其并發(fā)讀取文件沒有限制地進(jìn)行，甚至允許兩個(gè)線程同時(shí)對(duì)一個(gè)文件進(jìn)行讀寫操作兼都，盡管這樣可能會(huì)出問題嫂沉。
2.可以在一個(gè)進(jìn)程中序列化一個(gè)對(duì)象到文件系統(tǒng)中，在另一個(gè)進(jìn)程中反序列化恢復(fù)這個(gè)對(duì)象（注意：并不是同一個(gè)對(duì)象扮碧，只是內(nèi)容相同输瓜。）。
3.SharedPreferences 是個(gè)特例芬萍，系統(tǒng)對(duì)它的讀 / 寫有一定的緩存策略尤揣，即內(nèi)存中會(huì)有一份 ShardPreferences 文件的緩存，系統(tǒng)對(duì)他的讀 / 寫就變得不可靠柬祠，當(dāng)面對(duì)高并發(fā)的讀寫訪問北戏，SharedPreferences 有很多大的幾率丟失數(shù)據(jù)。因此漫蛔，IPC 不建議采用 SharedPreferences嗜愈。
三、使用 Messenger
Messenger 是一種輕量級(jí)的 IPC 方案莽龟，它的底層實(shí)現(xiàn)是 AIDL 蠕嫁，可以在不同進(jìn)程中傳遞 Message 對(duì)象，它一次只處理一個(gè)請(qǐng)求毯盈，在服務(wù)端不需要考慮線程同步的問題剃毒，服務(wù)端不存在并發(fā)執(zhí)行的情形
?服務(wù)端進(jìn)程：服務(wù)端創(chuàng)建一個(gè) Service 來處理客戶端請(qǐng)求，同時(shí)通過一個(gè) Handler 對(duì)象來實(shí)例化一個(gè) Messenger 對(duì)象，然后在 Service 的 onBind 中返回這個(gè) Messenger 對(duì)象底層的 Binder 即可赘阀。
?客戶端進(jìn)程：首先綁定服務(wù)端 Service 益缠，綁定成功之后用服務(wù)端的 IBinder 對(duì)象創(chuàng)建一個(gè) Messenger ，通過這個(gè) Messenger 就可以向服務(wù)端發(fā)送消息了基公，消息類型是 Message 幅慌。如果需要服務(wù)端響應(yīng)，則需要?jiǎng)?chuàng)建一個(gè) Handler 并通過它來創(chuàng)建一個(gè) Messenger（和服務(wù)端一樣）轰豆，并通過 Message 的 replyTo 參數(shù)傳遞給服務(wù)端胰伍。服務(wù)端通過 Message 的 replyTo 參數(shù)就可以回應(yīng)客戶端了。
四酸休、使用 AIDL
Messenger 是以串行的方式處理客戶端發(fā)來的消息骂租，如果大量消息同時(shí)發(fā)送到服務(wù)端，服務(wù)端只能一個(gè)一個(gè)處理雨席，所以大量并發(fā)請(qǐng)求就不適合用 Messenger 菩咨，而且 Messenger 只適合傳遞消息，不能跨進(jìn)程調(diào)用服務(wù)端的方法陡厘。AIDL 可以解決并發(fā)和跨進(jìn)程調(diào)用方法的問題抽米，要知道 Messenger 本質(zhì)上也是 AIDL ，只不過系統(tǒng)做了封裝方便上層的調(diào)用而已糙置。
五云茸、使用 ContentProvider
用于不同應(yīng)用間數(shù)據(jù)共享，和 Messenger 底層實(shí)現(xiàn)同樣是 Binder 和 AIDL谤饭，系統(tǒng)做了封裝标捺，使用簡(jiǎn)單。 系統(tǒng)預(yù)置了許多 ContentProvider 揉抵，如通訊錄亡容、日程表，需要跨進(jìn)程訪問冤今。 使用方法：繼承 ContentProvider 類實(shí)現(xiàn) 6 個(gè)抽象方法闺兢，這六個(gè)方法均運(yùn)行在 ContentProvider 進(jìn)程中，除 onCreate 運(yùn)行在主線程里戏罢，其他五個(gè)方法均由外界回調(diào)運(yùn)行在 Binder 線程池中屋谭。
ContentProvider 的底層數(shù)據(jù)，可以是 SQLite 數(shù)據(jù)庫(kù)龟糕，可以是文件桐磁，也可以是內(nèi)存中的數(shù)據(jù)。
六讲岁、使用 Socket
Socket起源于 Unix我擂，而 Unix 基本哲學(xué)之一就是“一切皆文件”衬以，都可以用“打開 open –讀寫 write/read –關(guān)閉 close ”模式來操作。Socket 就是該模式的一個(gè)實(shí)現(xiàn)扶踊，網(wǎng)絡(luò)的 Socket 數(shù)據(jù)傳輸是一種特殊的 I/O泄鹏，Socket 也是一種文件描述符郎任。Socket 也具有一個(gè)類似于打開文件的函數(shù)調(diào)用： Socket()秧耗，該函數(shù)返回一個(gè)整型的Socket 描述符，隨后的連接建立舶治、數(shù)據(jù)傳輸?shù)炔僮鞫际峭ㄟ^該 Socket 實(shí)現(xiàn)的分井。
常用的 Socket 類型有兩種：流式 Socket（SOCK_STREAM）和數(shù)據(jù)報(bào)式 Socket（SOCK_DGRAM）。流式是一種面向連接的 Socket霉猛，針對(duì)于面向連接的 TCP 服務(wù)應(yīng)用尺锚；數(shù)據(jù)報(bào)式 Socket 是一種無連接的 Socket ，對(duì)應(yīng)于無連接的 UDP 服務(wù)應(yīng)用惜浅。
Srvice:
Service是四大組件之一瘫辩，它可以在后臺(tái)執(zhí)行長(zhǎng)時(shí)間運(yùn)行操作而沒有用戶界面的應(yīng)用組件
兩種啟動(dòng)方式和特點(diǎn)：
startService特點(diǎn)：
1.使用這種start方式啟動(dòng)的Service的生命周期如下：onCreate()--->onStartCommand()---> onDestroy()
2.如果服務(wù)已經(jīng)開啟，不會(huì)重復(fù)的執(zhí)行onCreate()坛悉， 而是會(huì)調(diào)用onStart()和onStartCommand()
3.一旦服務(wù)開啟跟調(diào)用者(開啟者)就沒有任何關(guān)系了伐厌。
4.開啟者退出了，開啟者掛了裸影，服務(wù)還在后臺(tái)長(zhǎng)期的運(yùn)行挣轨。
5.開啟者不能調(diào)用服務(wù)里面的方法。
bindService特點(diǎn)：
1.使用這種start方式啟動(dòng)的Service的生命周期如下：onCreate() --->onBind()--->onUnbind()--->onDestroy()
2.綁定服務(wù)不會(huì)調(diào)用onStart()或者onStartCommand()方法
3.bind的方式開啟服務(wù)轩猩，綁定服務(wù)卷扮。調(diào)用者調(diào)用unbindService解除綁定，服務(wù)也會(huì)跟著銷毀均践。
4.綁定者可以調(diào)用服務(wù)里面的方法
IntentService是什么晤锹。。通常用來離線下載
?重點(diǎn)（本質(zhì)上也是為了節(jié)省資源）
?IntentService是繼承自Service并處理異步請(qǐng)求的一個(gè)類彤委，其內(nèi)部采用HandlerThread和Handler實(shí)現(xiàn)的鞭铆，在IntentService內(nèi)有一個(gè)工作線程來處理耗時(shí)操作，其優(yōu)先級(jí)比普通Service高
?當(dāng)任務(wù)完成后葫慎，IntentService會(huì)自動(dòng)停止衔彻，而不需要手動(dòng)調(diào)用stopSelf()
?可以多次啟動(dòng)IntentService，每個(gè)耗時(shí)操作都會(huì)以工作隊(duì)列的方式在IntentService中onHandlerIntent()回調(diào)方法中執(zhí)行偷办，并且每次只會(huì)執(zhí)行一個(gè)工作線程
- IntentService使用方法
1.創(chuàng)建Service繼承自IntentService
2.覆寫構(gòu)造方法和onHandlerIntent()方法
3.在onHandlerIntent()中執(zhí)行耗時(shí)操作
3.IntentService工作原理
1.IntentService繼承自Service艰额，內(nèi)部有一個(gè)HandlerThread對(duì)象
2.在onCreate的時(shí)候會(huì)創(chuàng)建一個(gè)HandlerThread對(duì)象，并啟動(dòng)線程
3.緊接著創(chuàng)建ServiceHandler對(duì)象椒涯，ServiceHandler繼承自Handler柄沮，用來處理消息。ServiceHandler將獲取HandlerThread的Looper就可以開始正常工作了
Service保活
1 onStartCommand方法祖搓，返回START_STICKY
在運(yùn)行onStartCommand后service進(jìn)程被殺死后狱意，那將保留在開始狀態(tài)，但不會(huì)保留那些傳入的intent拯欧。不久后service就會(huì)再次嘗試重新創(chuàng)建详囤，因?yàn)楸Ａ粼陂_始狀態(tài)，在創(chuàng)建 service后將保證調(diào)用onstartCommand镐作。如果沒有傳遞任何開始命令給service藏姐，那獲取到的Intent為null。手動(dòng)返回START_STICKY该贾，親測(cè)當(dāng)service因內(nèi)存不足被kill羔杨，當(dāng)內(nèi)存又有的時(shí)候，service又被重新創(chuàng)建杨蛋，但是不能保證任何情況下都被重建兜材，比如進(jìn)程被干掉了….
2 提升Service優(yōu)先級(jí)
在AndroidManifest.xml文件中對(duì)于intent-filter可以通過android:priority = “1000”這個(gè)屬性設(shè)置最高優(yōu)先級(jí)，1000是最高值逞力，如果數(shù)字越小則優(yōu)先級(jí)越低曙寡，同時(shí)適用于廣播。
3 提升Service進(jìn)程優(yōu)先級(jí)
Android中將進(jìn)程分成6個(gè)等級(jí)掏击，由高到低分別是：前臺(tái)進(jìn)程卵皂、可視進(jìn)程、次要服務(wù)進(jìn)程砚亭、后臺(tái)進(jìn)程灯变、內(nèi)容供應(yīng)節(jié)點(diǎn)以及空進(jìn)程。當(dāng)系統(tǒng)進(jìn)程空間緊張時(shí)捅膘，會(huì)按照優(yōu)先級(jí)自動(dòng)進(jìn)行進(jìn)程回收添祸。可以使用startForeground()將服務(wù)設(shè)置為前臺(tái)進(jìn)程
4 在onDestory中重啟Service
直接在onDestroy()里startService或service +broadcast 方式寻仗，就是當(dāng)service走ondestory的時(shí)候刃泌，發(fā)送一個(gè)自定義的廣播，當(dāng)收到廣播的時(shí)候署尤，重新啟動(dòng)service耙替。
5 監(jiān)聽系統(tǒng)廣播判斷Service狀態(tài)
通過系統(tǒng)的一些廣播，比如：手機(jī)重啟曹体、界面喚醒俗扇、應(yīng)用狀態(tài)改變等等監(jiān)聽并捕獲到，然后判斷我們的Service是否還存活箕别，但要記得加權(quán)限铜幽。
9.Glide
glide默認(rèn)使用httpurlcolltion加載圖片滞谢，還可以修改為okhttp3或Volley來進(jìn)行加載圖片
1、glide怎么獲取圖片寬高除抛，獲取屏幕寬高的幾種方案:
1.可以直接獲取到尺寸狮杨，當(dāng)xml文件里寫固定值，可以直接獲取到忽。還有就是布局已經(jīng)繪制完成橄教，通過view可以獲取，如果是wrap_content就通過 override() 指定其他固定尺寸绘趋，并使用屏幕尺寸為該請(qǐng)求尺寸
2.布局沒有繪制完成颤陶，通過調(diào)用onPreDrawListener監(jiān)聽實(shí)現(xiàn)獲取寬高
2.綁定生命周期分為五種類型1颗管、content2陷遮、Activity3、FragmentActivity4垦江、Fragment5帽馋、View
原理：通過獲取 Activity 的FragmentManager，綁定一個(gè)空RequestManagerFragment比吭，用來綁定空的Fragment然后在RequestManagerFragment 中初始化RequestManager绽族，并注冊(cè)至LifecycleListener
當(dāng)Activity 觸發(fā)生命周期時(shí)，回調(diào) Fragment衩藤，并傳至LifecycleListener,LifecycleListener會(huì)回調(diào)所有向其注冊(cè)過的RequestManager
Glide和Picasso比較：
1.Picasso和Glide的withi后面的參數(shù)不同
Picasso.with(這里只能傳入上下文) .
Glide.with,后面可以傳入上下文,activity實(shí)例,FragmentActivity實(shí)例,Fragement.傳入的對(duì)象要比前者多.
2.加載后圖片質(zhì)量不同
Picasso采用的ARGB-8888,
Glide采用的是RGB-565 相對(duì)而言,
Picasso加載的是全圖,圖片質(zhì)量和清晰對(duì)要比Glide的要高
但是,因?yàn)榧虞d的采樣率過高,導(dǎo)致,出現(xiàn)OOM異常的概率要比Glide要大很多.
3.加載Gif圖片(備注:Gif圖片消耗太對(duì)內(nèi)存,盡量謹(jǐn)慎使用):
Picasso不能加載git圖片
Glide可以加載緩存圖片
4.緩存策略和加載速度.
Picasso緩存的是全尺寸
Glide的緩存的跟ImageView的尺寸相同.
講ImageView調(diào)整為不同的大小,不管大小如何設(shè)置,
Glide則不同,他會(huì)為每種大小不一致的ImageView都緩存一次.Glide的這個(gè)特點(diǎn),讓加載顯得特別的快,
Picasso只緩存一個(gè)全尺寸的,Picasso則因?yàn)樾枰陲@示之前重新調(diào)整大小而導(dǎo)致一些延遲,(即便是添加了noFade)
5.總結(jié):
Glide比Picasso加載速度要快,其實(shí)他是在Picasso的基礎(chǔ)上進(jìn)行了第二次封裝,
Glide比Picasso需要更多的空間來緩存;
Glide加載圖像以及磁盤緩存的方式,都優(yōu)于Picasso,且Glide更有利于減少OutOfMemoryError的發(fā)生;
Gif動(dòng)畫,是Glide的殺手锏.
3.Glide線程池
1.磁盤緩存線程池
2.核心處理線程池
3.動(dòng)畫線程池
10吧慢、MVC,MVP，MVVM 的區(qū)別
MVC：
moduel對(duì)數(shù)據(jù)進(jìn)行處理赏表，將數(shù)據(jù)給view展示
View用戶界面检诗，給controller傳送要顯示的頁(yè)面
Controller:控制器,對(duì)邏輯做處理，讓moduel改變狀態(tài)
特點(diǎn)：因?yàn)関iew可以訪問moduel瓢剿，所以要做一些邏輯逢慌，導(dǎo)致更改view比較困難，
Controller代碼過多臃腫间狂，職責(zé)不清晰攻泼，測(cè)試不方便（必須手動(dòng)點(diǎn)擊，使用自動(dòng)化的測(cè)試工具）所有的通信都是單向的
MVP:
View ：是指顯示數(shù)據(jù)并且和用戶交互的層鉴象。
Model ：是數(shù)據(jù)源層忙菠。用來保存數(shù)據(jù)，以及請(qǐng)求數(shù)據(jù)等纺弊。
Presenter：是從Model中獲取數(shù)據(jù)并提供給View的層牛欢，Presenter還負(fù)責(zé)處理所有的邏輯
優(yōu)點(diǎn)：測(cè)試方便，m與v完全脫離俭尖，各部分通信都是雙向的氢惋，降低了耦合性洞翩，
缺點(diǎn)，接口過于頻繁,維護(hù)不方便
MVVM:
對(duì)MVP的改進(jìn)
1將Presenter改名為ViewModuel
并通過雙向的數(shù)據(jù)綁定來實(shí)現(xiàn)視圖和數(shù)據(jù)的交互焰望。也就是說只需要將數(shù)據(jù)和視圖綁定一次之后骚亿，那么之后當(dāng)數(shù)據(jù)發(fā)生改變時(shí)就會(huì)自動(dòng)的在UI上刷新而不需要我們自己進(jìn)行手動(dòng)刷新。在MVVM中熊赖，他盡可能的會(huì)簡(jiǎn)化數(shù)據(jù)流的走向来屠，使其變得更加簡(jiǎn)潔明了。
優(yōu)點(diǎn)：可以使得數(shù)據(jù)流的走向更加的清晰明了震鹉，同時(shí)也簡(jiǎn)化了開發(fā)俱笛，數(shù)據(jù)和視圖只需要進(jìn)行一次綁定即可。
11传趾、AsyncTask
基本概念及原理：
異步任務(wù)迎膜，它本質(zhì)上就是一個(gè)封裝了線程池和Handler的異步框架〗迹可以實(shí)現(xiàn)UI線程和后臺(tái)線程進(jìn)行通訊,后臺(tái)線程執(zhí)行異步任務(wù),并把結(jié)果返回給UI線程磕仅。
利用AsyncTask，可以方便的實(shí)現(xiàn)異步任務(wù)處理簸呈，可以在子線程更新UI,封裝簡(jiǎn)化了異步操作榕订，使用線程，線程池處理異步任務(wù)蜕便，AsyncTask執(zhí)行任務(wù)時(shí)劫恒，內(nèi)部會(huì)創(chuàng)建一個(gè)進(jìn)程作用域的線程池來管理要運(yùn)行的任務(wù)，也就是說當(dāng)你調(diào)用了AsyncTa sk.execute()后轿腺，AsyncTask會(huì)把任務(wù)交給線程池两嘴，由線程池來管理創(chuàng)建Thread和運(yùn)行Thread。
為什么要做異步任務(wù)：
因?yàn)閍ndroid中只有主線程才可以對(duì)ui進(jìn)行操作吃溅，但是不可以做耗時(shí)操作溶诞，如果主線程做耗時(shí)操作，可能就會(huì)導(dǎo)致ANR,將耗時(shí)操作放到子線程去做决侈，此時(shí)就可以用AsyncTask螺垢，既避免了Android中單線程，又避免了ANR.
使用方法：
構(gòu)建AsyncTask子類的泛型參數(shù)：
Params:啟動(dòng)任務(wù)時(shí)輸入的參數(shù)類型.
Progress:后臺(tái)任務(wù)執(zhí)行中返回進(jìn)度值的類型.
Result:后臺(tái)任務(wù)執(zhí)行完成后返回結(jié)果的類型.
構(gòu)建AsyncTask子類的回調(diào)方法：
doInBackground:必須重寫,異步執(zhí)行后臺(tái)線程要完成的任務(wù),耗時(shí)操作將在此方法中完成.
onPreExecute:執(zhí)行后臺(tái)耗時(shí)操作前被調(diào)用,通常用于進(jìn)行初始化操作.
onPostExecute:當(dāng)doInBackground方法完成后,系統(tǒng)將自動(dòng)調(diào)用此方法,并將doInBackground方法返回的值傳入此方法.通過此方法進(jìn)行UI的更新.
onProgressUpdate:當(dāng)在doInBackground方法中調(diào)用publishProgress方法更新任務(wù)執(zhí)行進(jìn)度后,將調(diào)用此方法.通過此方法我們可以知曉任務(wù)的完成進(jìn)度.
使用AsyncTask的注意事項(xiàng)
① 必須在UI線程中創(chuàng)建AsyncTask的實(shí)例.
② 只能在UI線程中調(diào)用AsyncTask的execute方法.
③ AsyncTask被重寫的四個(gè)方法是系統(tǒng)自動(dòng)調(diào)用的,不應(yīng)手動(dòng)調(diào)用.
④ 每個(gè)AsyncTask只能被執(zhí)行(execute方法)一次,多次執(zhí)行將會(huì)引發(fā)異常.
⑤ AsyncTask的四個(gè)方法,只有doInBackground方法是運(yùn)行在其他線程中,其他三個(gè)方法都運(yùn)行在UI線程中,也就說其他三個(gè)方法都可以進(jìn)行UI的更新操作.
12赖歌、Android 6.0枉圃、7.0、8.0庐冯、9.0各個(gè)版本的版本特性主要講解關(guān)于開發(fā)方面
6.0
運(yùn)行時(shí)權(quán)限孽亲，首次使用要申請(qǐng)獲得權(quán)限
低電耗模式和應(yīng)用待機(jī)模式，一段時(shí)間不用展父，會(huì)處于休眠狀態(tài)或待機(jī)模式
取消支持http客戶端的支持返劲，用HttpURLConnection,減少透明壓縮和響應(yīng)緩存等
文本操作玲昧，選中之后可以對(duì)其操作
WLAN和網(wǎng)絡(luò)連接變更
對(duì)相機(jī)的服務(wù)有些改變
USB連接，僅充電模式篮绿，要做其他操作孵延，要獲取權(quán)限
7.0
多窗口支持，分屏功能
增強(qiáng)通知功能亲配，模板更新尘应，消息傳遞樣式自定義，捆綁通知吼虎，快速通知等犬钢，
配置文件指導(dǎo)的JIT/AOT編譯，對(duì)代碼進(jìn)行分析思灰，讓它可以在應(yīng)用運(yùn)行時(shí)持續(xù)提升 Android 應(yīng)用的性能玷犹，提高應(yīng)用安裝和系統(tǒng)更新的速度，
低電耗模式官辈，即設(shè)備處于空閑狀態(tài)時(shí)箱舞，通過推遲應(yīng)用的 CPU 和網(wǎng)絡(luò)活動(dòng)以實(shí)現(xiàn)省電目的的系統(tǒng)模式
流量節(jié)省模式，
夜間模式
多語言區(qū)域支持拳亿，更多語言
秘鑰認(rèn)證
VR支持，可以讓用戶打造高質(zhì)量移動(dòng)VR體驗(yàn)
新增FrameMetricsListener API 允許應(yīng)用檢測(cè)他的UI渲染性能
8.0
自動(dòng)填充框架
Android 8.0 通過引入自動(dòng)填充框架愿伴，簡(jiǎn)化了登錄和信用卡表單之類表單的填寫工作肺魁。在用戶選擇接受自動(dòng)填充之后，新老應(yīng)用都可使用自動(dòng)填充框架。
畫中畫模式
Android 8.0 允許以畫中畫 (PIP) 模式啟動(dòng)操作組件。PIP 是一種特殊的多窗口模式的畴，最常用于視頻播放妓美。而 Android 8.0 則讓該功能可進(jìn)一步用于其他 Android 設(shè)備。
字體
1提供從程序應(yīng)用請(qǐng)求字體爆安，不不需要讓Apk去下載字體，減少APK大小
2 XML 中的字體，允許您使用字體作為資源蹦误。
自動(dòng)調(diào)整Textview的大小
根據(jù) TextView 的大小自動(dòng)設(shè)置文本展開或收縮的大小。更容易屏幕適配
可以自適應(yīng)應(yīng)用圖標(biāo)
提高WebView API增強(qiáng)應(yīng)用穩(wěn)定性和安全性
統(tǒng)一的布局外邊距和內(nèi)邊距
指針捕獲肉津，例如游戲强胰，遠(yuǎn)程桌面都收益與指針控制
新的 StrictMode 檢測(cè)程序，幫助識(shí)別應(yīng)用可能出現(xiàn)的錯(cuò)誤
自定義數(shù)據(jù)存儲(chǔ)
WLAN 感知
在具有相應(yīng) WLAN 感知硬件的設(shè)備上妹沙，應(yīng)用和附近設(shè)備可以通過 WLAN 進(jìn)行搜索和通信偶洋，無需依賴互聯(lián)網(wǎng)接入點(diǎn)
無障礙功能
支持開發(fā)者使用以下無障礙功能創(chuàng)建自己的無障礙服務(wù)。
新增與電話相關(guān)的權(quán)限
9.0：
1.所有應(yīng)用都使用HTTPS距糖，對(duì)所有應(yīng)用信息安全
2.多攝像頭支持玄窝，您可以通過兩個(gè)或更多物理攝像頭來同時(shí)訪問多個(gè)視頻流牵寺。
3.顯示屏缺口支持
Android 9 支持最新的全面屏，其中包含為攝像頭和揚(yáng)聲器預(yù)留空間的屏幕缺口恩脂。 通過 DisplayCutout 類可確定非功能區(qū)域的位置和形狀缸剪，這些區(qū)域不應(yīng)顯示內(nèi)容。 要確定這些屏幕缺口區(qū)域是否存在及其位置东亦，請(qǐng)使用 getDisplayCutout() 函數(shù)杏节。
4.動(dòng)畫，用來繪制GIF和WebP動(dòng)畫圖像
5.HDR VP9視頻典阵，HEIF圖像壓縮和MediaApi
6.對(duì)流量費(fèi)用敏感奋渔，如果網(wǎng)絡(luò)阻塞時(shí)，會(huì)延遲較大的網(wǎng)絡(luò)請(qǐng)求
13壮啊、EventBus
EventBus簡(jiǎn)化了Android組件間的通信嫉鲸。有效的分離事件發(fā)送方和接收方(也就是解耦的意思)，能避免復(fù)雜和容易出錯(cuò)的依賴性和生命周期問題 歹啼。
三要素：
Event 事件玄渗。它可以是任意類型
Subscriber 事件訂閱者。3.0之后需要加上注解@subscribe()狸眼，并且指定線程模型藤树，默認(rèn)是POSTING。3.0以前必須定義onEvent固定的那幾個(gè)方法
Publisher 事件的發(fā)布者拓萌∷甑觯可以在任意線程發(fā)布事件，使用EventBus.getDefault()就可以得到一個(gè)EventBus對(duì)象微王，然后再調(diào)用post(Object)方法即可屡限。
四種線程模式：
? POSTING (默認(rèn)) 事件處理的線程跟發(fā)布事件的線程在同一個(gè)線程。
? MAIN 表示事件處理函數(shù)的線程在主線程(UI)線程炕倘，因此在這里不能進(jìn)行耗時(shí)操作钧大。
? BACKGROUND 表示事件處理函數(shù)的線程在后臺(tái)線程，因此不能進(jìn)行UI操作罩旋。
? ASYNC 表示無論事件發(fā)布的線程是哪一個(gè)啊央，事件處理函數(shù)始終會(huì)新建一個(gè)子線程運(yùn)行，同樣不能進(jìn)行UI操作瘸恼。
粘性事件：黏性事件劣挫，就是指發(fā)送了該事件之后再訂閱者依然能夠接收到的事件。使用黏性事件的時(shí)候有兩個(gè)地方需要做些修改东帅。一個(gè)是訂閱事件的地方压固，一個(gè)是發(fā)布事件的地方，即調(diào)用EventBus的postSticky方法來發(fā)布事件：
優(yōu)先級(jí)：
priority它用來指定訂閱方法的優(yōu)先級(jí)靠闭，是一個(gè)整數(shù)類型的值帐我，默認(rèn)是0坎炼，值越大表示優(yōu)先級(jí)越大。在某個(gè)事件被發(fā)布出來的時(shí)候拦键，優(yōu)先級(jí)較高的訂閱方法會(huì)首先接受到事件谣光。
14、GreenDao
一對(duì)一
@ToOne
就是一個(gè)主鍵對(duì)應(yīng)一個(gè)值
一對(duì)多
@ToMany(referencedJoinProperty = "parentId")類似于約束外鍵芬为。
比如一個(gè)老師有多個(gè)學(xué)生萄金，要有一個(gè)主鍵，一個(gè)外鍵媚朦，根據(jù)外鍵去查看另外一張表氧敢，反過來就是多對(duì)一
多對(duì)多
@JoinEntity(entity = TeacherJoinStudentBean.class,sourceProperty = "tId",targetProperty ="sId")
比如多個(gè)老師有多個(gè)學(xué)生，這種情況需要另外一張表询张，用來存放老師和學(xué)生的id和自己的主鍵孙乖，直接查看這張表就可以。
實(shí)體注解：
@Entity 用于標(biāo)識(shí)這是一個(gè)需要Greendao幫我們生成代碼的bean
@Id 標(biāo)明主鍵份氧，可以設(shè)置為是否自增唯袄，如果原來字段里就有id，那么就不需要設(shè)置 Long類型的Id,將Id改為不可自增就可以
@Transient表示這個(gè)字段不會(huì)再數(shù)據(jù)庫(kù)里面插入
@Index 通過這個(gè)字段建立索引
@Convert對(duì)不是基本類型進(jìn)行轉(zhuǎn)換
關(guān)鍵的幾個(gè)類：
DaoMaster：用于創(chuàng)建數(shù)據(jù)庫(kù)以及獲取DaoSession
DaoSession：用于獲取各個(gè)表對(duì)應(yīng)的Dao對(duì)象
各個(gè)表對(duì)應(yīng)的Dao：提供了對(duì)表進(jìn)行增刪改查的方法
對(duì)于每一個(gè)實(shí)體類蜗帜，greenDao生成一個(gè)DAO,持有很多持久性的方法恋拷，例如 count， loadAll以及insertInTx钮糖。
greendao加密：
添加依賴梅掠，加密的方法是用了getEncryptedWritableDb，在得到DB并getSession時(shí)需要輸入密鑰店归。
在取數(shù)據(jù)時(shí)使用的session必須也是使用相同的密鑰new出來的，否則只能看到空數(shù)據(jù)酪我。并且把加密后的本地文件拿出來消痛，也是看不到內(nèi)容的。
GreenDao升級(jí)：greendao不支持?jǐn)?shù)據(jù)遷移
第一步：新建一個(gè)類都哭，繼承DaoMaster.DevOpenHelper秩伞，重寫onUpgrade(Database db, int oldVersion, int newVersion)方法，在該方法中使用MigrationHelper進(jìn)行數(shù)據(jù)庫(kù)升級(jí)以及數(shù)據(jù)遷移欺矫。
然后使用MyOpenHelper替代DaoMaster.DevOpenHelper來進(jìn)行創(chuàng)建數(shù)據(jù)庫(kù)等操作
第二步：新增或者修改字段纱新，新增的字段都會(huì)被賦予空值，將原來的getset方法刪除穆趴，重新build,最后修改版本號(hào)
29脸爱、熱修復(fù)
版本發(fā)布之后發(fā)現(xiàn)嚴(yán)重BUG，需要緊急動(dòng)態(tài)修復(fù)
小功能即時(shí)上線未妹、下線簿废，比如節(jié)日活動(dòng)
而熱修復(fù)的開發(fā)流程顯得更加靈活空入，優(yōu)勢(shì)很多：
無需重新發(fā)版，實(shí)時(shí)高效熱修復(fù)
用戶無感知修復(fù)（甚至無需重啟應(yīng)用）族檬，無需下載新的應(yīng)用歪赢，代價(jià)小
修復(fù)成功率高，把損失降到最低
而熱修復(fù)的開發(fā)流程顯得更加靈活单料，優(yōu)勢(shì)很多：
無需重新發(fā)版埋凯，實(shí)時(shí)高效熱修復(fù)
用戶無感知修復(fù)（甚至無需重啟應(yīng)用），無需下載新的應(yīng)用扫尖，代價(jià)小
修復(fù)成功率高白对，把損失降到最低
主流框架：
騰訊，生成dex文件藏斩，因?yàn)閐ex文件是以數(shù)組的形式出錯(cuò)躏结，他通過改變dex文件的順序，實(shí)現(xiàn)熱更新
2.阿里云狰域，添加so庫(kù)媳拴，利用C語言進(jìn)行一些算法，改變執(zhí)行順序
15兆览、視頻上傳屈溉，下載，緩存抬探，壓縮
視頻的壓縮上傳采用集成七牛短視頻子巾，
16、描述Java中斷點(diǎn)續(xù)傳和多線程斷點(diǎn)續(xù)傳的詳細(xì)流程
多線程斷點(diǎn)續(xù)傳流程：
1小压、 HttpUrlConnection去請(qǐng)求服務(wù)器 獲得文件的長(zhǎng)度con.getContentLength()
2线梗、 創(chuàng)建一個(gè)空的RandomAcessFile來接收，并且指定剛剛獲取的長(zhǎng)度setLength
3怠益、開啟N個(gè)線程 計(jì)算每個(gè)線程需要下載的長(zhǎng)度
4仪搔、獲取之前先去看看下載的進(jìn)度保存文件是否存在如果存在就從文件里獲取已經(jīng)下載的進(jìn)度
5、開始文件下載
6蜻牢、臨時(shí)文件的刪除 資源的關(guān)閉
單線程斷點(diǎn)續(xù)傳流程：
1）通過遠(yuǎn)程url和本地保存目錄開始運(yùn)行
2）通過遠(yuǎn)程url獲取文件大小
3）通過本地臨時(shí)文件info和遠(yuǎn)程文件比較大小判斷是否有本地文件下載完畢
4）未下載完成的開始斷點(diǎn)下載
5）完成后刪除臨時(shí)文件
30烤咧、js與Android交互
Android開發(fā)過程中，我們或多或少都會(huì)用到webview抢呆，使用webview來展示一些經(jīng)常變動(dòng)的界面更加方便簡(jiǎn)單煮嫌，
也已于維護(hù)。另一方面hybrid App開發(fā)現(xiàn)在用的也越來越多了抱虐。其中native和h5之間的交互更是必不可少的昌阿。
常用的有web.load Url(“”);
Webview可以對(duì)html頁(yè)面通過指定的幾個(gè)方法做本地緩存，減少用戶流量，
要注意的問題：
在WebView加載頁(yè)面的時(shí)候宝泵，會(huì)自動(dòng)開啟線程去加載好啰，如果不很好的關(guān)閉這些線程，就會(huì)導(dǎo)致電量消耗加大儿奶，可以采用暴力的方法框往，直接在onDestroy方法中System.exit(0)結(jié)束當(dāng)前正在運(yùn)行中的java虛擬機(jī)
17、單例模式闯捎、工廠模式椰弊、觀察者、適配器瓤鼻；
Builder模式
意圖：將一個(gè)復(fù)雜的構(gòu)建與其表示相分離秉版，使得同樣的構(gòu)建過程可以創(chuàng)建不同的表示。
何時(shí)使用：一些基本部件不會(huì)變茬祷，而其組合經(jīng)常變化的時(shí)候清焕。
關(guān)鍵代碼：建造者：創(chuàng)建和提供實(shí)例，導(dǎo)演：管理建造出來的實(shí)例的依賴關(guān)系祭犯。
觀察者模式
發(fā)布訂閱模式秸妥，發(fā)布者發(fā)布信息，訂閱者獲取信息沃粗，訂閱了就能收到信息粥惧，沒訂閱就收不到信息
意圖：定義對(duì)象間的一種一對(duì)多的依賴關(guān)系，當(dāng)一個(gè)對(duì)象的狀態(tài)發(fā)生改變時(shí)最盅，所有依賴于它的對(duì)象都得到通知并被自動(dòng)更新突雪。
何時(shí)使用：一個(gè)對(duì)象（目標(biāo)對(duì)象）的狀態(tài)發(fā)生改變，所有的依賴對(duì)象（觀察者對(duì)象）都將得到通知涡贱，進(jìn)行廣播通知咏删。
如何解決：使用面向?qū)ο蠹夹g(shù)，可以將這種依賴關(guān)系弱化问词。
工廠模式
意圖：定義一個(gè)創(chuàng)建對(duì)象的接口饵婆，讓其子類自己決定實(shí)例化哪一個(gè)工廠類，工廠模式使其創(chuàng)建過程延遲到子類進(jìn)行戏售。
主要解決：主要解決接口選擇的問題。
何時(shí)使用：我們明確地計(jì)劃不同條件下創(chuàng)建不同實(shí)例時(shí)草穆。
關(guān)鍵代碼：創(chuàng)建過程在其子類執(zhí)行灌灾。
19.Activity一共有以下四種啟動(dòng)模式：
1.Standard（默認(rèn)的啟動(dòng)模式）：每次啟動(dòng)一個(gè)Activity都會(huì)創(chuàng)建一個(gè)新的實(shí)例入棧，不管這個(gè)實(shí)例是否存在悲柱。
2.SingleTop（棧頂復(fù)用模式）：當(dāng)一個(gè)singleTop模式的Activity已經(jīng)位于任務(wù)棧的棧頂锋喜，再去啟動(dòng)它時(shí)，不會(huì)再創(chuàng)建新的實(shí)例,如果不位于棧頂，就會(huì)創(chuàng)建新的實(shí)例
3.SingTask（有彈棧的效果）：在同一個(gè)Task中只有一個(gè)實(shí)例嘿般，如果在棧頂段标，系統(tǒng)不會(huì)創(chuàng)建新的Activity實(shí)例，如果不在棧頂炉奴，系統(tǒng)就把這個(gè)Activity移到棧頂逼庞，把他上面的Activity移出去
- SingleInstance（單例模式）SingTask是任務(wù)棧內(nèi)單例，SingleInstance則是Activity單例瞻赶，會(huì)創(chuàng)建一個(gè)新的任務(wù)棧赛糟，這個(gè)任務(wù)棧只有一個(gè)Activity
20、簡(jiǎn)述什么是泛型砸逊，泛型如何使用和項(xiàng)目中如何使用
泛型的本質(zhì)是為了參數(shù)化類型（在不創(chuàng)建新的類型的情況下璧南，通過泛型指定的不同類型來控制形參具體限制的類型）。也就是說在泛型使用過程中师逸，操作的數(shù)據(jù)類型被指定為一個(gè)參數(shù)司倚，這種參數(shù)類型可以用在類、接口和方法中篓像，分別被稱為泛型類动知、泛型接口、泛型方法遗淳。
泛型如何使用
泛型可以用到容器拍柒，方法，接口屈暗，內(nèi)部類拆讯，抽象類
泛型的好處：
增強(qiáng)程序的可讀性和穩(wěn)點(diǎn)性，在實(shí)際使用之前類型就已經(jīng)確定了养叛，不需要強(qiáng)制類型轉(zhuǎn)換
21.Java中線程的實(shí)現(xiàn)的幾種方式种呐、和常用的方法、以及多線程安全問題
線程的三種方式：
1）繼承Thread類創(chuàng)建線程
2）實(shí)現(xiàn)Runnable接口創(chuàng)建線程
3）使用Callable和Future創(chuàng)建線程
常用方法：
start() ：?jiǎn)?dòng)線程弃甥，進(jìn)入就緒狀態(tài)
run()：都用來定義線程對(duì)象被調(diào)度之后所執(zhí)行的操作爽室，都是系統(tǒng)自動(dòng)調(diào)用而用戶程序不得引用的方法。
sleep(int millsecond): 優(yōu)先級(jí)高的線程可以在它的run()方法中調(diào)用sleep方法來使自己休眠一段時(shí)間淆攻。
wait：調(diào)用該方法的線程進(jìn)入等待狀態(tài)阔墩，需要注意的是調(diào)用wait()方法后，會(huì)釋放對(duì)象的鎖瓶珊。
多線程安全問題：
什么情況下會(huì)產(chǎn)生線程安全問題啸箫？
1，多個(gè)線程在操作共享的數(shù)據(jù)伞芹。 ? 2忘苛，操作共享數(shù)據(jù)的線程代碼有多條蝉娜。
解決思路：
將多條操作共享數(shù)據(jù)的線程代碼封裝起來，當(dāng)有線程在執(zhí)行這些代碼的時(shí)候扎唾，其他線程不可以參與運(yùn)算召川。
當(dāng)前線程把這些代碼都執(zhí)行完畢后，其他線程才可以參與運(yùn)算胸遇。
22.Java中線程池的實(shí)現(xiàn)的幾種方式和各自特點(diǎn)與使用場(chǎng)景
實(shí)現(xiàn)方式
線程池的實(shí)現(xiàn)方式是通過Executors類創(chuàng)建幾種不同類型的線程池
四種線程池：
newCacheThreadPool 創(chuàng)建一個(gè)可緩存線程池荧呐，如果線程池長(zhǎng)度超過處理需要，可靈活回收空閑線程狐榔，若無可回收坛增，則新建線程
newFixedpool創(chuàng)建一個(gè)定長(zhǎng)線程池，可控制線程最大并發(fā)數(shù)薄腻，超出的線程會(huì)在隊(duì)列中等待 newScheduledpool創(chuàng)建一個(gè)定長(zhǎng)線程池收捣，支持定時(shí)和周期性任務(wù)執(zhí)行 ? newSingeThreadExecutor創(chuàng)建一個(gè)單線程化的線程池，它只會(huì)用唯一的工作線程來執(zhí)行任務(wù)庵楷，保證所有任務(wù)按照指定順序（FIFO罢艾，LIFO，優(yōu)先級(jí)）執(zhí)行
使用場(chǎng)景：
單個(gè)任務(wù)處理時(shí)間短 ? 將需處理的任務(wù)數(shù)量大
23尽纽、Java中數(shù)組咐蚯、集合、鏈 表弄贿、隊(duì)列的數(shù)據(jù)結(jié)構(gòu)和優(yōu)缺點(diǎn)和他們之間的區(qū)別
數(shù)組：
長(zhǎng)度固定 ? 可以存儲(chǔ)基本類型春锋，也可以存儲(chǔ)引用類型,存儲(chǔ)元素類型一致 ? 數(shù)組可以在內(nèi)存中連續(xù)存儲(chǔ)多個(gè)元素的構(gòu)造，在內(nèi)存中的分配也是連續(xù)的
優(yōu)點(diǎn)：有下標(biāo)差凹，查詢方便期奔，增刪快
缺點(diǎn)： 數(shù)組的大小固定后就不能擴(kuò)容了 ? 數(shù)組只能存儲(chǔ)一種類型的數(shù)據(jù) ? 添加，刪除的操作慢危尿，因?yàn)橐苿?dòng)其他的元素
集合:
長(zhǎng)度可變 ? 只可以存儲(chǔ)引用類型 ? 可以存儲(chǔ)多種類型
List有序可重復(fù) ?
ArrayList： 底層：數(shù)組（存儲(chǔ)空間連續(xù)） 增刪慢呐萌，查詢快 線程不安全，（不同步） 效率高 ?
Vector： 底層：數(shù)組（存儲(chǔ)空間連續(xù)） 增刪慢谊娇，查詢快 線程安全肺孤，（同步） 效率低 ?
LinkedList： 底層：鏈表（兩部分：值域，地址域） 增刪快济欢，查詢慢 線程不安全赠堵，效率高
Set無序不可重復(fù) ?
HashSet 底層：哈希表（hashcode，equals） 線程不安全法褥，效率高 ? LinkedHashSet 底層： 鏈表（保證有序） 哈希表（hashcode顾腊，equals） ? TreeSet 底層：紅黑樹 （有序：1.自然排序 2.比較器排序）
? Hashtable：現(xiàn)在被HashSet取代，特點(diǎn)挖胃，不能存null 線程安全，效率低
Map 雙列集合 只針對(duì)鍵有效 Key，Value ?
HashMap 底層：哈希表（hashcode酱鸭，equals） 線程不安全吗垮，效率高（針對(duì)key） ?
LinkedHashMap 底層： 鏈表（保證有序） 哈希表（hashcode，equals） ? TreeMap 底層：紅黑樹 （有序：1.自然排序 2.比較器排序）
鏈表：
通過一個(gè)鏈子把多個(gè)結(jié)點(diǎn)（元素）連接起來凹髓，由數(shù)據(jù)和地址組成的一個(gè)元素烁登， ? 節(jié)點(diǎn)本身必須有一個(gè)地址值（就是下一個(gè)元素的地址值）
優(yōu)點(diǎn)：
查找不方便，增刪快
隊(duì)列：
是一種先進(jìn)先出的數(shù)據(jù)構(gòu)造蔚舀，也是運(yùn)算受限制的線性表饵沧，只可以在對(duì)頭刪除元素，在隊(duì)尾插入元素 ? 線性表是同一類型數(shù)據(jù)的一個(gè)有限序列 ? 元素之間的先后排列次序蘊(yùn)涵著其線性關(guān)系赌躺。
24.簡(jiǎn)述Java中注解狼牺，并自定義注解。說一下注解處理機(jī)制和使用場(chǎng)景
什么是注解礼患？
Java注解也叫元數(shù)據(jù)是钥，是附加在代碼中的一些元信息，用于一些工具在編譯缅叠、運(yùn)行時(shí)進(jìn)行解析和使用悄泥，起到說明、配置的功能肤粱。注解不會(huì)影響代碼的實(shí)際邏輯弹囚，僅僅起到輔助性的作用。
它主要的作用有以下四方面：
1领曼，生成文檔鸥鹉，通過代碼里標(biāo)識(shí)的元數(shù)據(jù)生成javadoc文檔。
2悯森，編譯檢查宋舷，讓編譯器在編譯期間進(jìn)行檢查驗(yàn)證。
3瓢姻，編譯時(shí)動(dòng)態(tài)處理祝蝠，例如動(dòng)態(tài)生成代碼。
4幻碱，運(yùn)行時(shí)動(dòng)態(tài)處理绎狭，例如使用反射注入實(shí)例。
自定義注解：
自定義注解類編寫的一些規(guī)則: - 參數(shù)成員只能用public或default這兩個(gè)訪問權(quán)修飾
- 參數(shù)成員只能用八種基本數(shù)據(jù)類型和String褥傍、Enum儡嘶、Class、annotations等數(shù)據(jù)類型,以及這一些類型的數(shù)組.
- 要獲取類方法和字段的注解信息恍风，必須通過Java的反射技術(shù)來獲取
25蹦狂、描述Socket誓篱、Tcp和Udp，http凯楔、https區(qū)別窜骄，和使用方式和原理
socket是對(duì)TCP/IP協(xié)議的封裝，Socket本身并不是協(xié)議摆屯，而是一個(gè)調(diào)用接口（API）邻遏，
通過Socket，我們才能使用TCP/IP協(xié)議虐骑。
TCP與UDP區(qū)別總結(jié)：
1准验、TCP面向連接
UDP是無連接的，即發(fā)送數(shù)據(jù)之前不需要建立連接
2廷没、TCP提供可靠的服務(wù)糊饱。也就是說，通過TCP連接傳送的數(shù)據(jù)腕柜，無差錯(cuò)济似，不丟失，不 重復(fù)盏缤，且按序到達(dá);
3砰蠢、TCP面向字節(jié)流，實(shí)際上是TCP把數(shù)據(jù)看成一連串無結(jié)構(gòu)的字節(jié)流;
UDP是面向報(bào)文的
UDP沒有擁塞控制唉铜，因此網(wǎng)絡(luò)出現(xiàn)擁塞不會(huì)使源主機(jī)的發(fā)送速率降低
4台舱、每一條TCP連接只能是點(diǎn)到點(diǎn)的;UDP支持一對(duì)一，一對(duì)多潭流，多對(duì)一和多對(duì)多的交互通信
5竞惋、TCP首部開銷20字節(jié);UDP的首部開銷小，只有8個(gè)字節(jié)
6灰嫉、TCP的邏輯通信信道是全雙工的可靠信道拆宛，UDP則是不可靠信道
HTTP與HTTPS的區(qū)別
1、HTTPS協(xié)議需要到CA申請(qǐng)證書讼撒，一般免費(fèi)證書很少浑厚，需要交費(fèi)。
2根盒、HTTP是超文本傳輸協(xié)議信息是明文傳輸钳幅，HTTPS則是具有安全性的ssl加密傳輸協(xié)議。
3炎滞、HTTP和HTTPS使用的是完全不同的連接方式敢艰，用的端口也不一樣，前者是80册赛，后者是443钠导。
4震嫉、HTTP的連接很簡(jiǎn)單，是無狀態(tài)的辈双；HTTPS協(xié)議是由SSL+HTTP協(xié)議構(gòu)建的可進(jìn)行加密傳輸责掏、身份認(rèn)證的網(wǎng)絡(luò)協(xié)議，比HTTP協(xié)議安全湃望。
26、描述java中的垃圾回收機(jī)制以及內(nèi)部算法
垃圾回收機(jī)制是Java提供的自動(dòng)釋放內(nèi)存空間的機(jī)制痰驱。 垃圾回收器（Garbage Collection证芭，GC）是JVM自帶的一個(gè)線程，用于回收沒有被引用的對(duì)象担映，垃圾回收重點(diǎn)關(guān)注的是堆和方法區(qū)部分的內(nèi)存废士。
java中常用的垃圾收集算法
(1).標(biāo)記-清除算法：
最基礎(chǔ)的垃圾收集算法，算法分為“標(biāo)記”和“清除”兩個(gè)階段：首先標(biāo)記出所有需要回收的對(duì)象蝇完，在標(biāo)記完成之后統(tǒng)一回收掉所有被標(biāo)記的對(duì)象官硝。
(2).復(fù)制算法：
將可用內(nèi)存按容量分成大小相等的兩塊，每次只使用其中一塊短蜕，當(dāng)這塊內(nèi)存使用完了氢架，就將還存活的對(duì)象復(fù)制到另一塊內(nèi)存上去，然后把使用過的內(nèi)存空間一次清理掉朋魔。
復(fù)制算法的缺點(diǎn)顯而易見岖研，可使用的內(nèi)存降為原來一半。
(3).標(biāo)記-整理算法：
標(biāo)記-整理算法在標(biāo)記-清除算法基礎(chǔ)上做了改進(jìn)警检，標(biāo)記階段是相同的標(biāo)記出所有需要回收的對(duì)象孙援，在標(biāo)記完成之后不是直接對(duì)可回收對(duì)象進(jìn)行清理，而是讓所有存活的對(duì)象都向一端移動(dòng)扇雕，在移動(dòng)過程中清理掉可回收的對(duì)象拓售，這個(gè)過程叫做整理。
(4).分代收集算法：
根據(jù)內(nèi)存中對(duì)象的存活周期不同镶奉，將內(nèi)存劃分為幾塊础淤，java的虛擬機(jī)中一般把內(nèi)存劃分為新生代和年老代，當(dāng)新創(chuàng)建對(duì)象時(shí)一般在新生代中分配內(nèi)存空間腮鞍，當(dāng)新生代垃圾收集器回收幾次之后仍然存活的對(duì)象會(huì)被移動(dòng)到年老代內(nèi)存中值骇，當(dāng)大對(duì)象在新生代中無法找到足夠的連續(xù)內(nèi)存時(shí)也直接在年老代中創(chuàng)建。
現(xiàn)在的Java虛擬機(jī)就聯(lián)合使用了分代復(fù)制移国、標(biāo)記-清除和標(biāo)記-整理算法吱瘩，
27、簡(jiǎn)述什么是ANR迹缀、如何產(chǎn)生和解決
ANR定義：應(yīng)用程序無響應(yīng)使碾，會(huì)顯示一個(gè)對(duì)話框蜜徽，這個(gè)對(duì)話框稱作應(yīng)用程序無響應(yīng)（ANR：Application Not Responding）對(duì)話框。用戶可以選擇“等待”而讓程序繼續(xù)運(yùn)行票摇，也可以選擇“強(qiáng)制關(guān)閉”拘鞋。
ANR產(chǎn)生原因
在多線程中做了非常耗時(shí)的操作，比如說是下載矢门，io異常等
潛在的耗時(shí)操作盆色，例如網(wǎng)絡(luò)或數(shù)據(jù)庫(kù)操作，或者高耗時(shí)的計(jì)算如改變位圖尺寸祟剔，應(yīng)該在子線程里或者通過異步請(qǐng)求的方式來完成隔躲。
如何解決ANR
不在主線程做耗時(shí)操作，放在子線程中來實(shí)現(xiàn)物延，采用Handler+mesage的方式宣旱，或者是有時(shí)候需要做一些和網(wǎng)絡(luò)相互交互的耗時(shí)操作就采用asyntask異步任務(wù)的方式等，在主線程中更新UI叛薯。
28浑吟、Android頁(yè)面恢復(fù)
32、圖片的三級(jí)緩存
當(dāng)App需要加載某一張圖片時(shí)耗溜，先去手機(jī)內(nèi)存中去找該圖片组力，如果有，那么直接顯示强霎，如果無忿项，則去手機(jī)sd卡或者手機(jī)外部存儲(chǔ)中找該圖片，如果有城舞，那么直接顯示轩触，如果無，那么此時(shí)才去網(wǎng)絡(luò)下載該圖片家夺。這種機(jī)制常稱為三級(jí)緩存策略脱柱。
內(nèi)存緩存以花費(fèi)寶貴的程序內(nèi)存為前提來快速訪問位圖。
LruCache類（在API Level 4的Support Library中也可以找到)特別適合用來緩存Bitmaps拉馋，
它使用一個(gè)強(qiáng)引用（strong referenced）的LinkedHashMap保存最近引用的對(duì)象,并且在緩存超出設(shè)置大小的時(shí)候剔除（evict）最近最少使用到的對(duì)象榨为。
- 即時(shí)通訊
主流的框架就是環(huán)信。
環(huán)信：流程：
?在線狀態(tài)：客戶端A發(fā)送消息到環(huán)信服務(wù)器煌茴，環(huán)信服務(wù)器推送消息到客戶端B随闺。
?離線狀態(tài)：客戶端A發(fā)送消息到環(huán)信服務(wù)器，環(huán)信服務(wù)器檢測(cè)到客戶端B不在線蔓腐，會(huì)添加到離線緩存中矩乐，當(dāng)客戶端B登錄后服務(wù)器會(huì)把離線消息推送給客戶端B。
聊天記錄保存
客戶端A發(fā)送消息到環(huán)信服務(wù)器的同時(shí)，SDK 會(huì)保存這條消息到本地?cái)?shù)據(jù)庫(kù)（SDK 內(nèi)部創(chuàng)建數(shù)據(jù)庫(kù)散罕，不允許直接操作）分歇，環(huán)信服務(wù)器在推送消息到客戶端B的同時(shí)也會(huì)在服務(wù)器記錄下來（消息歷史記錄免費(fèi)存儲(chǔ)3天），客戶端B收到消息后欧漱，SDK 會(huì)將這條消息存儲(chǔ)到本地?cái)?shù)據(jù)庫(kù)职抡。
自動(dòng)連接:
如果網(wǎng)絡(luò)不通過，用戶應(yīng)該自動(dòng)連接到服務(wù)器,以及時(shí)接收消息
此功能無需程序員自己做误甚，環(huán)信框架已實(shí)現(xiàn),環(huán)信SDK會(huì)調(diào)用自動(dòng)連接的代理方法來通知應(yīng)用程序
MChatManagerBuddyDelegate:
上面的協(xié)議的實(shí)現(xiàn)了對(duì)用戶的基本操作缚甩，如
(1)添加好友
(2)從本地獲取好友列表
(3)從服務(wù)器獲取最新好友列表
(4)接收好友添加請(qǐng)求
(5)刪除好友
(6)被好友從名單上刪除
是否使用過環(huán)信，簡(jiǎn)單的說下環(huán)信的實(shí)現(xiàn)原理:
環(huán)信是一個(gè)即時(shí)通信的服務(wù)提供商
環(huán)信使用的是XMPP協(xié)議窑邦，它是再XMPP的基礎(chǔ)上進(jìn)行二次開發(fā)蹄胰，對(duì)服務(wù)器Openfire和客戶端進(jìn)行功能模型的添加和客戶端SDK的封裝，環(huán)信的本質(zhì)還是使用XMPP奕翔，基本于Socket的網(wǎng)絡(luò)通信
環(huán)信內(nèi)部實(shí)現(xiàn)了數(shù)據(jù)緩存，會(huì)把聊天記錄添加到數(shù)據(jù)庫(kù)浩蓉，把附件(如音頻文件派继，圖片文件)下載到本地，使程序員更多時(shí)間是花到用戶即時(shí)體驗(yàn)上
環(huán)信內(nèi)部已經(jīng)實(shí)現(xiàn)了視頻捻艳，音頻驾窟，圖片，其它附件發(fā)送功能
環(huán)信使用公司可以節(jié)約時(shí)間成本
不需要公司內(nèi)部搭建服務(wù)器
客戶端的開發(fā)认轨，使用環(huán)信SDK比使用XMPPFramework更簡(jiǎn)潔方便
35.支付流程
支付寶支付流程：
1.app攜帶支付信息調(diào)用支付接口請(qǐng)求支付寶客戶端調(diào)起支付界面绅络；
2.用戶操作，輸入密碼支付嘁字，支付成功恩急；直接返回取消支付；出現(xiàn)錯(cuò)誤纪蜒，支付失斨怨А；進(jìn)入支付界面纯续，但輸入密碼支付随珠，支付待確認(rèn)；
3.支付寶客戶端將支付結(jié)果告訴app客戶端猬错，商戶服務(wù)器通知app服務(wù)器支付結(jié)果窗看；
4.app客戶端處理支付結(jié)果；
5.app服務(wù)器處理支付結(jié)果倦炒。
微信支付：
流程解釋： - 客戶端請(qǐng)求訂單
2.認(rèn)證商戶显沈，獲取access_token
3、組裝生成預(yù)定單所需參數(shù)并簽名
4析校、調(diào)用微信統(tǒng)一下單接口并傳遞參數(shù)构罗，得到預(yù)訂單號(hào)
5铜涉、對(duì)得到的預(yù)定單參數(shù)再次簽名
6、調(diào)起微信支付并驗(yàn)證參數(shù)有效性
7遂唧、驗(yàn)證通過芙代，提示用戶輸入支付密碼
8、提交支付盖彭，異步返回支付結(jié)果和訂單詳情
9纹烹、客戶端同步跳轉(zhuǎn)頁(yè)面。
