1.Activity生命周期(這個(gè)是必問(wèn)的)

onCreate()?創(chuàng)建活動(dòng)您单，做一些數(shù)據(jù)初始化操作

onStart()?由不可見(jiàn)變?yōu)榭梢?jiàn)

onResume()?可以與用戶進(jìn)行交互楷扬，位于棧頂

onPause()?暫停，啟動(dòng)或恢復(fù)另一個(gè)活動(dòng)時(shí)調(diào)用

onStop()?停止喂分，變?yōu)椴豢梢?jiàn)

onDestroy()?銷毀

onRestart()?由停止?fàn)顟B(tài)變?yōu)檫\(yùn)行狀態(tài)

2.Fragment生命周期 (這個(gè)有可能會(huì)問(wèn)到姓迅，問(wèn)的機(jī)率不是很大)

fragment生命周期

3.Service生命周期

onCreate()

首次創(chuàng)建服務(wù)時(shí)瓣俯，系統(tǒng)將調(diào)用此方法夹抗。如果服務(wù)已在運(yùn)行，則不會(huì)調(diào)用此方法纵竖，該方法只調(diào)用一次漠烧。

onStartCommand()

當(dāng)另一個(gè)組件通過(guò)調(diào)用startService()請(qǐng)求啟動(dòng)服務(wù)時(shí)杏愤，系統(tǒng)將調(diào)用此方法。

onDestroy()

當(dāng)服務(wù)不再使用且將被銷毀時(shí)已脓，系統(tǒng)將調(diào)用此方法珊楼。

onBind()

當(dāng)另一個(gè)組件通過(guò)調(diào)用bindService()與服務(wù)綁定時(shí)，系統(tǒng)將調(diào)用此方法度液。

onUnbind()

當(dāng)另一個(gè)組件通過(guò)調(diào)用unbindService()與服務(wù)解綁時(shí)厕宗，系統(tǒng)將調(diào)用此方法。

onRebind()

當(dāng)舊的組件與服務(wù)解綁后堕担，另一個(gè)新的組件與服務(wù)綁定已慢，onUnbind()返回true時(shí)，系統(tǒng)將調(diào)用此方法霹购。

4.Service啟動(dòng)方式(問(wèn)到Service佑惠，這個(gè)肯定是要問(wèn)到的)

1.startService

①.定義一個(gè)類繼承service

②.在manifest.xml文件中配置該service

③.使用context的startService(intent)啟動(dòng)該service

④.不再使用時(shí),調(diào)用stopService(Intent)停止該服務(wù)

2.bindService

①.創(chuàng)建bindService服務(wù)段,繼承自service并在類中,創(chuàng)建一個(gè)實(shí)現(xiàn)binder接口的實(shí)例對(duì)象并提供公共方法給客戶端調(diào)用

②.從onbind()回調(diào)方法返回此binder實(shí)例

③.在客戶端中,從onserviceconnected()回調(diào)方法接收binder,并使用提供的方法調(diào)用綁定服務(wù)

5.Activity的啟動(dòng)方式(偶爾會(huì)問(wèn))

①.standard模式

? ? a.Activity的默認(rèn)啟動(dòng)模式

? ? b.每啟動(dòng)一個(gè)Activity就會(huì)在棧頂創(chuàng)建一個(gè)新的實(shí)例。例如：鬧鐘程序

?? ?缺點(diǎn)：當(dāng)Activity已經(jīng)位于棧頂時(shí)齐疙，而再次啟動(dòng)Activity時(shí)還需要在創(chuàng)建一個(gè)新的實(shí)例膜楷，不能直接復(fù)用。

②.singleTop模式

?? ?特點(diǎn)：該模式會(huì)判斷要啟動(dòng)的Activity實(shí)例是否位于棧頂贞奋，如果位于棧頂直接復(fù)用赌厅，否則創(chuàng)建新的實(shí)例。 例如：瀏覽器的書簽

?? ?缺點(diǎn)：如果Activity并未處于棧頂位置轿塔，則可能還會(huì)創(chuàng)建多個(gè)實(shí)例特愿。

③.singleTask模式

?? ?特點(diǎn)：使Activity在整個(gè)應(yīng)用程序中只有一個(gè)實(shí)例。每次啟動(dòng)Activity時(shí)系統(tǒng)首先檢查棧中是否存在當(dāng)前Activity實(shí)例催训，如果存在

?? ??? ? ? ?? 則直接復(fù)用洽议，并把當(dāng)前Activity之上所有實(shí)例全部出棧。例如：瀏覽器主界面

④.singleInstance模式

?? ?特點(diǎn)：該模式的Activity會(huì)啟動(dòng)一個(gè)新的任務(wù)棧來(lái)管理Activity實(shí)例漫拭，并且該勢(shì)力在整個(gè)系統(tǒng)中只有一個(gè)亚兄。無(wú)論從那個(gè)任務(wù)棧中??? 啟動(dòng)該Activity，都會(huì)是該Activity所在的任務(wù)棧轉(zhuǎn)移到前臺(tái)采驻，從而使Activity顯示审胚。主要作用是為了在不同程序中共享一個(gè)Activity

6.Touch事件傳遞機(jī)制

在我們點(diǎn)擊屏幕時(shí)，會(huì)有下列事件發(fā)生：

Activity調(diào)用dispathTouchEvent()方法礼旅，把事件傳遞給Window膳叨；

Window再將事件交給DecorView（DecorView是View的根布局）；

DecorView再傳遞給ViewGroup痘系；

Activity ——> Window ——> DecorView ——> ViewGroup——> View

事件分發(fā)的主要有三個(gè)關(guān)鍵方法

dispatchTouchEvent() 分發(fā)

onInterceptTouchEvent() 攔截 菲嘴，只有ViewGroup獨(dú)有此方法

onTouchEvent() 處理觸摸事件

Activity首先調(diào)用dispathTouchEvent()進(jìn)行分發(fā)，接著調(diào)用super向下傳遞

ViewGroup首先調(diào)用dispathTouchEvent()進(jìn)行分發(fā)，接著會(huì)調(diào)用onInterceptTouchEvent()（攔截事件）龄坪。若攔截事件返回為true昭雌，表示攔截，事件不會(huì)向下層的ViewGroup或者View傳遞健田；false烛卧，表示不攔截，繼續(xù)分發(fā)事件妓局。默認(rèn)是false总放，需要提醒一下，View是沒(méi)有onInterceptTouchEvent()方法的

事件在ViewGroup和ViewGroup好爬、ViewGroup和View之間進(jìn)行傳遞局雄，最終到達(dá)View；

View調(diào)用dispathTouchEvent()方法抵拘，然后在OnTouchEvent()進(jìn)行處理事件哎榴；OnTouchEvent() 返回true，表示消耗此事件僵蛛，不再向下傳遞尚蝌；返回false，表示不消耗事件充尉，交回上層處理飘言。

7.介紹下實(shí)現(xiàn)一個(gè)自定義View的基本流程

①.自定義View的屬性 編寫attr.xml文件

②.在layout布局文件中引用，同時(shí)引用命名空間

③.在View的構(gòu)造方法中獲得我們自定義的屬性 驼侠，在自定義控件中進(jìn)行讀茸撕琛（構(gòu)造方法拿到attr.xml文件值）

④.重寫onMesure

⑥.重寫onDraw

8.Android中的動(dòng)畫有哪些

逐幀動(dòng)畫(Frame Animation)

加載一系列Drawable資源來(lái)創(chuàng)建動(dòng)畫，簡(jiǎn)單來(lái)說(shuō)就是播放一系列的圖片來(lái)實(shí)現(xiàn)動(dòng)畫效果倒源，可以自定義每張圖片的持續(xù)時(shí)間

補(bǔ)間動(dòng)畫(Tween Animation)

Tween可以對(duì)View對(duì)象實(shí)現(xiàn)一系列動(dòng)畫效果苛预，比如平移，縮放笋熬，旋轉(zhuǎn)热某，透明度等。但是它并不會(huì)改變View屬性的值胳螟，只是改變了View的繪制的位置昔馋，比如，一個(gè)按鈕在動(dòng)畫過(guò)后糖耸，不在原來(lái)的位置秘遏，但是觸發(fā)點(diǎn)擊事件的仍然是原來(lái)的坐標(biāo)。

屬性動(dòng)畫(Property Animation)

動(dòng)畫的對(duì)象除了傳統(tǒng)的View對(duì)象嘉竟，還可以是Object對(duì)象邦危，動(dòng)畫結(jié)束后洋侨，Object對(duì)象的屬性值被實(shí)實(shí)在在的改變了

9.ANR是什么？怎樣避免和解決ANR

Application Not Responding倦蚪，即應(yīng)用無(wú)響應(yīng)

出現(xiàn)的原因有三種：

a）KeyDispatchTimeout（5 seconds）主要類型按鍵或觸摸事件在特定時(shí)間內(nèi)無(wú)響應(yīng)

b）BroadcastTimeout（10 seconds）BoradcastReceiver在特定的時(shí)間內(nèi)無(wú)法處理

c）ServiceTimeout（20 seconds）小概率類型Service在特定的時(shí)間內(nèi)無(wú)法處理完成

避免ANR最核心的一點(diǎn)就是在主線程減少耗時(shí)操作凰兑。通常需要從那個(gè)以下幾個(gè)方案下手：

a）使用子線程處理耗時(shí)IO操作

b）降低子線程優(yōu)先級(jí)，使用Thread或者HandlerThread時(shí)审丘，調(diào)用Process.setThreadPriority（Process.THREAD_PRIORITY_BACKGROUND）設(shè)置優(yōu)先級(jí)，否則仍然會(huì)降低程序響應(yīng)勾给，因?yàn)槟J(rèn)Thread的優(yōu)先級(jí)和主線程相同

c）使用Handler處理子線程結(jié)果滩报，而不是使用Thread.wait()或者Thread.sleep()來(lái)阻塞主線程

d）Activity的onCreate和onResume回調(diào)中盡量避免耗時(shí)的代碼

e）BroadcastReceiver中onReceiver代碼也要盡量減少耗時(shí)操作，建議使用intentService處理播急。intentService是一個(gè)異步的脓钾，會(huì)自動(dòng)停止的服務(wù)，很好解決了傳統(tǒng)的Service中處理完耗時(shí)操作忘記停止并銷毀Service的問(wèn)題

10.如何優(yōu)化ListView(偶爾會(huì)問(wèn))

①Item布局桩警，層級(jí)越少越好可训，使用hierarchyview工具查看優(yōu)化。

②復(fù)用convertView

③使用ViewHolder

④item中有圖片時(shí)捶枢，異步加載

⑤快速滑動(dòng)時(shí)握截，不加載圖片

⑥item中有圖片時(shí)，應(yīng)對(duì)圖片進(jìn)行適當(dāng)壓縮

⑦實(shí)現(xiàn)數(shù)據(jù)的分頁(yè)加載

11.設(shè)備橫豎屏切換的時(shí)候烂叔，生面周期的變化(這個(gè)偶爾會(huì)問(wèn))

不設(shè)置Activity的android:configChanges時(shí)谨胞，切屏?xí)匦抡{(diào)用各個(gè)生命周期，切橫屏?xí)r會(huì)執(zhí)行一次蒜鸡，切豎屏?xí)r會(huì)執(zhí)行兩次

設(shè)置Activity的android:configChanges=”orientation”時(shí)胯努，切屏還是會(huì)重新調(diào)用各個(gè)生命周期，切橫逢防、豎屏?xí)r只會(huì)執(zhí)行一次

設(shè)置Activity的android:configChanges=”orientation|keyboardHidden”時(shí)叶沛，切屏不會(huì)重新調(diào)用各個(gè)生命周期，只會(huì)執(zhí)行onConfigurationChanged方法

12.AndroidUI的適配

字體使用sp,使用dp忘朝，多使用match_parent灰署，wrap_content，weight

圖片資源辜伟，不同圖片的的分辨率氓侧，放在相應(yīng)的文件夾下可使用百分比代替。

13.RecyclerView和ListView的區(qū)別(這個(gè)是必問(wèn)的)

RecyclerView可以完成ListView,GridView的效果导狡，還可以完成瀑布流的效果约巷。同時(shí)還可以設(shè)置列表的滾動(dòng)方向（垂直或者水平）；

RecyclerView中view的復(fù)用不需要開發(fā)者自己寫代碼旱捧，系統(tǒng)已經(jīng)幫封裝完成了独郎。

RecyclerView可以進(jìn)行局部刷新踩麦。

RecyclerView提供了API來(lái)實(shí)現(xiàn)item的動(dòng)畫效果。

在性能上：

如果需要頻繁的刷新數(shù)據(jù)氓癌，需要添加動(dòng)畫谓谦，則RecyclerView有較大的優(yōu)勢(shì)。

如果只是作為列表展示贪婉，則兩者區(qū)別并不是很大反粥。

14，Android異步消息處理機(jī)制(這個(gè)也會(huì)經(jīng)常問(wèn)到)

異步消息處理機(jī)制主要是用來(lái)解決子線程更新UI的問(wèn)題

主要有四個(gè)部分：

①. Message （消息）

在線程之間傳遞疲迂，可在內(nèi)部攜帶少量信息才顿，用于不同線程之間交換數(shù)據(jù)

可以使用what、arg1尤蒿、arg2字段攜帶整型數(shù)據(jù)

obj字段攜帶Object對(duì)象

②. Handler （處理者）

主要用于發(fā)送和處理消息郑气，sendMessage（）用來(lái)發(fā)送消息，最終會(huì)回到handleMessage（）進(jìn)行處理

③. MessageQueue （消息隊(duì)列）

主要存放所有通過(guò)Handler發(fā)送的消息腰池，它們會(huì)一直存在于隊(duì)列中等待被處理

每個(gè)線程只有一個(gè)MessageQueue

④.?Looper （循環(huán)器）

調(diào)用loop（）方法后尾组，會(huì)不斷從MessageQueue 取出待處理的消息，然后傳遞到handleMessage進(jìn)行處理

15.內(nèi)存泄漏和內(nèi)存溢出是什么示弓？一般怎么處理內(nèi)存泄漏讳侨？

（1）內(nèi)存溢出（OOM）和內(nèi)存泄露（對(duì)象無(wú)法被回收）的區(qū)別。

（2）引起內(nèi)存泄露的原因

（3）內(nèi)存泄露檢測(cè)工具 ------>LeakCanary

內(nèi)存溢出 out of memory：是指程序在申請(qǐng)內(nèi)存時(shí)避乏，沒(méi)有足夠的內(nèi)存空間供其使用爷耀，出現(xiàn)out of memory；比如申請(qǐng)了一個(gè)integer,但給它存了long才能存下的數(shù)拍皮，那就是內(nèi)存溢出歹叮。內(nèi)存溢出通俗的講就是內(nèi)存不夠用。

內(nèi)存泄露 memory leak：是指程序在申請(qǐng)內(nèi)存后铆帽，無(wú)法釋放已申請(qǐng)的內(nèi)存空間咆耿，一次內(nèi)存泄露危害可以忽略，但內(nèi)存泄露堆積后果很嚴(yán)重爹橱，無(wú)論多少內(nèi)存,遲早會(huì)被占光

內(nèi)存泄露原因以及解決：

一萨螺、Handler 引起的內(nèi)存泄漏。

解決：將Handler聲明為靜態(tài)內(nèi)部類愧驱，就不會(huì)持有外部類SecondActivity的引用慰技，其生命周期就和外部類無(wú)關(guān)，

如果Handler里面需要context的話组砚，可以通過(guò)弱引用方式引用外部類

二吻商、單例模式引起的內(nèi)存泄漏。

解決：Context是ApplicationContext糟红，由于ApplicationContext的生命周期是和app一致的艾帐，不會(huì)導(dǎo)致內(nèi)存泄漏

三乌叶、非靜態(tài)內(nèi)部類創(chuàng)建靜態(tài)實(shí)例引起的內(nèi)存泄漏。

解決：把內(nèi)部類修改為靜態(tài)的就可以避免內(nèi)存泄漏了

四柒爸、非靜態(tài)匿名內(nèi)部類引起的內(nèi)存泄漏准浴。

解決：將匿名內(nèi)部類設(shè)置為靜態(tài)的。

五捎稚、注冊(cè)/反注冊(cè)未成對(duì)使用引起的內(nèi)存泄漏乐横。

注冊(cè)廣播接受器、EventBus等今野，記得解綁晰奖。

六、資源對(duì)象沒(méi)有關(guān)閉引起的內(nèi)存泄漏腥泥。

在這些資源不使用的時(shí)候，記得調(diào)用相應(yīng)的類似close（）啃匿、destroy（）蛔外、recycler（）、release（）等方法釋放溯乒。

七夹厌、集合對(duì)象沒(méi)有及時(shí)清理引起的內(nèi)存泄漏。

通常會(huì)把一些對(duì)象裝入到集合中裆悄，當(dāng)不使用的時(shí)候一定要記得及時(shí)清理集合矛纹，讓相關(guān)對(duì)象不再被引用。

16.圖片加載框架有哪些光稼？他們之間的區(qū)別是什么或南？(這個(gè)也是必問(wèn)的)

ImageLoader ：

優(yōu)點(diǎn)：

①　支持下載進(jìn)度監(jiān)聽(tīng)；

②　可以在 View 滾動(dòng)中暫停圖片加載艾君；

③　默認(rèn)實(shí)現(xiàn)多種內(nèi)存緩存算法這幾個(gè)圖片緩存都可以配置緩存算法采够，不過(guò) ImageLoader 默認(rèn)實(shí)現(xiàn)了較多緩存算法，如 Size 最大先刪除冰垄、使用最少先刪除蹬癌、最近最少使用、先進(jìn)先刪除虹茶、時(shí)間最長(zhǎng)先刪除等逝薪；

④　支持本地緩存文件名規(guī)則定義；

缺點(diǎn):

缺點(diǎn)在于不支持GIF圖片加載, 緩存機(jī)制沒(méi)有和http的緩存很好的結(jié)合, 完全是自己的一套緩存機(jī)制

Picasso：

優(yōu)點(diǎn)：

①　自帶統(tǒng)計(jì)監(jiān)控功能蝴罪，支持圖片緩存使用的監(jiān)控董济，包括緩存命中率、已使用內(nèi)存大小洲炊、節(jié)省的流量等感局。

②　支持優(yōu)先級(jí)處理

③　支持延遲到圖片尺寸計(jì)算完成加載

④　支持飛行模式尼啡、并發(fā)線程數(shù)根據(jù)網(wǎng)絡(luò)類型而變，手機(jī)切換到飛行模式或網(wǎng)絡(luò)類型變換時(shí)會(huì)自動(dòng)調(diào)整線程池最大并發(fā)數(shù)询微。

⑤ “無(wú)”本地緩存崖瞭。Picasso 自己沒(méi)有實(shí)現(xiàn)本地緩存，而由okhttp 去實(shí)現(xiàn)撑毛，這樣的好處是可以通過(guò)請(qǐng)求 Response Header 中的 Cache-Control 及 Expired 控制圖片的過(guò)期時(shí)間书聚。

缺點(diǎn)：

于不支持GIF，默認(rèn)使用ARGB_8888格式緩存圖片藻雌，緩存體積大雌续。

Glide：

優(yōu)點(diǎn)：

①　圖片緩存->媒體緩存 ，支持 Gif胯杭、WebP驯杜、縮略圖。甚至是 Video做个。

②　支持優(yōu)先級(jí)處理

③　與 Activity/Fragment 生命周期一致鸽心，支持 trimMemory

④　支持 okhttp、Volley居暖。Glide 默認(rèn)通過(guò) UrlConnection 獲取數(shù)據(jù)顽频，可以配合 okhttp 或是 Volley 使用。實(shí)際 ImageLoader太闺、Picasso 也都支持 okhttp糯景、Volley。

⑤　內(nèi)存友好省骂，內(nèi)存緩存更小圖片蟀淮，圖片默認(rèn)使用默認(rèn) RGB565 而不是 ARGB888

缺點(diǎn)：

清晰度差，但可以設(shè)置

Fresco：

優(yōu)點(diǎn):

①　圖片存儲(chǔ)在安卓系統(tǒng)的匿名共享內(nèi)存, 而不是虛擬機(jī)的堆內(nèi)存中,所以不會(huì)因?yàn)閳D片加載而導(dǎo)致oom, 同時(shí)也減少垃圾回收器頻繁調(diào)用回收Bitmap導(dǎo)致的界面卡頓,性能更高.

②　漸進(jìn)式加載JPEG圖片, 支持圖片從模糊到清晰加載

③　圖片可以以任意的中心點(diǎn)顯示在ImageView, 而不僅僅是圖片的中心.

④ JPEG圖片改變大小也是在native進(jìn)行的, 不是在虛擬機(jī)的堆內(nèi)存, 同樣減少OOM

⑤　很好的支持GIF圖片的顯示

缺點(diǎn):

框架較大, 影響Apk體積钞澳，使用較繁瑣

17.網(wǎng)絡(luò)框架有哪些灭贷？他們之間的區(qū)別是什么？(這個(gè)也會(huì)問(wèn)到)

Xutils

這個(gè)框架非常全面略贮，可以進(jìn)行網(wǎng)絡(luò)請(qǐng)求甚疟，可以進(jìn)行圖片加載處理，可以數(shù)據(jù)儲(chǔ)存逃延，還可以對(duì)view進(jìn)行注解览妖，使用這個(gè)框架非常方便，但是缺點(diǎn)也是非常明顯的揽祥，使用這個(gè)項(xiàng)目讽膏，會(huì)導(dǎo)致項(xiàng)目對(duì)這個(gè)框架依賴非常的嚴(yán)重，一旦這個(gè)框架出現(xiàn)問(wèn)題拄丰，那么對(duì)項(xiàng)目來(lái)說(shuō)影響非常大的

OKhttp

Android開發(fā)中是可以直接使用現(xiàn)成的api進(jìn)行網(wǎng)絡(luò)請(qǐng)求的府树。就是使用HttpClient,HttpUrlConnection進(jìn)行操作俐末。okhttp針對(duì)Java和Android程序，封裝的一個(gè)高性能的http請(qǐng)求庫(kù)奄侠，支持同步卓箫，異步，而且okhttp又封裝了線程池垄潮，封裝了數(shù)據(jù)轉(zhuǎn)換烹卒，封裝了參數(shù)的使用，錯(cuò)誤處理等弯洗。API使用起來(lái)更加的方便旅急。但是我們?cè)陧?xiàng)目中使用的時(shí)候仍然需要自己在做一層封裝，這樣才能使用的更加的順手牡整。

Volley

Volley是Google官方出的一套小而巧的異步請(qǐng)求庫(kù)藐吮，該框架封裝的擴(kuò)展性很強(qiáng)，支持HttpClient逃贝、HttpUrlConnection炎码， 甚至支持OkHttp，而且Volley里面也封裝了ImageLoader秋泳，所以如果你愿意你甚至不需要使用圖片加載框架，不過(guò)這塊功能沒(méi)有一些專門的圖片加載框架強(qiáng)大攒菠，對(duì)于簡(jiǎn)單的需求可以使用迫皱，稍復(fù)雜點(diǎn)的需求還是需要用到專門的圖片加載框架。Volley也有缺陷辖众，比如不支持post大數(shù)據(jù)卓起，所以不適合上傳文件。不過(guò)Volley設(shè)計(jì)的初衷本身也就是為頻繁的凹炸、數(shù)據(jù)量小的網(wǎng)絡(luò)請(qǐng)求而生戏阅。

Retrofit

Retrofit是Square公司出品的默認(rèn)基于OkHttp封裝的一套R(shí)ESTful網(wǎng)絡(luò)請(qǐng)求框架，RESTful是目前流行的一套api設(shè)計(jì)的風(fēng)格啤它， 并不是標(biāo)準(zhǔn)奕筐。Retrofit的封裝可以說(shuō)是很強(qiáng)大，里面涉及到一堆的設(shè)計(jì)模式,可以通過(guò)注解直接配置請(qǐng)求变骡，可以使用不同的http客戶端离赫，雖然默認(rèn)是用http ，可以使用不同Json Converter 來(lái)序列化數(shù)據(jù)塌碌，同時(shí)提供對(duì)RxJava的支持渊胸，使用Retrofit + OkHttp + RxJava + Dagger2 可以說(shuō)是目前比較潮的一套框架，但是需要有比較高的門檻台妆。

Volley VS OkHttp

Volley的優(yōu)勢(shì)在于封裝的更好翎猛，而使用OkHttp你需要有足夠的能力再進(jìn)行一次封裝胖翰。而OkHttp的優(yōu)勢(shì)在于性能更高，因?yàn)?OkHttp基于NIO和Okio 切厘，所以性能上要比 Volley更快萨咳。IO 和 NIO這兩個(gè)都是Java中的概念，如果我從硬盤讀取數(shù)據(jù)迂卢，第一種方式就是程序一直等某弦，數(shù)據(jù)讀完后才能繼續(xù)操作這種是最簡(jiǎn)單的也叫阻塞式IO,還有一種是你讀你的,程序接著往下執(zhí)行，等數(shù)據(jù)處理完你再來(lái)通知我而克，然后再處理回調(diào)靶壮。而第二種就是 NIO 的方式，非阻塞式员萍， 所以NIO當(dāng)然要比IO的性能要好了,而 Okio是 Square 公司基于IO和NIO基礎(chǔ)上做的一個(gè)更簡(jiǎn)單腾降、高效處理數(shù)據(jù)流的一個(gè)庫(kù)。理論上如果Volley和OkHttp對(duì)比的話碎绎，更傾向于使用 Volley螃壤，因?yàn)閂olley內(nèi)部同樣支持使用OkHttp,這點(diǎn)OkHttp的性能優(yōu)勢(shì)就沒(méi)了， 而且 Volley 本身封裝的也更易用筋帖，擴(kuò)展性更好些码荔。

OkHttp VS Retrofit

毫無(wú)疑問(wèn)，Retrofit 默認(rèn)是基于 OkHttp 而做的封裝内列，這點(diǎn)來(lái)說(shuō)沒(méi)有可比性纽哥，肯定首選 Retrofit。

Volley VS Retrofit

這兩個(gè)庫(kù)都做了不錯(cuò)的封裝代箭，但Retrofit解耦的更徹底,尤其Retrofit2.0出來(lái)墩划，Jake對(duì)之前1.0設(shè)計(jì)不合理的地方做了大量重構(gòu)， 職責(zé)更細(xì)分嗡综，而且Retrofit默認(rèn)使用OkHttp,性能上也要比Volley占優(yōu)勢(shì)乙帮，再有如果你的項(xiàng)目如果采用了RxJava ，那更該使用 Retrofit 极景。所以這兩個(gè)庫(kù)相比察净，Retrofit更有優(yōu)勢(shì)，在能掌握兩個(gè)框架的前提下該優(yōu)先使用 Retrofit盼樟。但是Retrofit門檻要比Volley稍高些塞绿，要理解他的原理，各種用法恤批，想徹底搞明白還是需要花些功夫的异吻，如果你對(duì)它一知半解，那還是建議在商業(yè)項(xiàng)目使用Volley吧。

18.熟悉哪些設(shè)計(jì)模式诀浪？

按照自己的實(shí)際情況回答棋返，當(dāng)然是越多越好。比如我自己也就熟悉個(gè)單例模式雷猪。

19.三級(jí)緩存(這個(gè)偶爾會(huì)問(wèn))

網(wǎng)絡(luò)加載睛竣，不優(yōu)先加載，速度慢求摇，浪費(fèi)流量

本地緩存射沟，次優(yōu)先加載，速度快

內(nèi)存緩存与境，優(yōu)先加載验夯，速度最快

首次加載Android App時(shí)，肯定要通過(guò)網(wǎng)絡(luò)交互來(lái)獲取圖片摔刁，之后我們可以將圖片保存至本地SD卡和內(nèi)存中挥转，之后運(yùn)行APP時(shí)，優(yōu)先訪問(wèn)內(nèi)存中的圖片緩存共屈，若內(nèi)存中沒(méi)有绑谣，則加載本地SD卡中圖片，最后選擇訪問(wèn)網(wǎng)絡(luò)

20.Android與服務(wù)器交互的方式中的對(duì)稱加密和非對(duì)稱加密是什么拗引？

對(duì)稱加密借宵，就是加密和解密數(shù)據(jù)都是使用同一個(gè)key，這方面的算法有DES矾削。

非對(duì)稱加密壤玫，加密和解密是使用不同的key。發(fā)送數(shù)據(jù)之前要先和服務(wù)端約定生成公鑰和私鑰怔软，使用公鑰加密的數(shù)據(jù)可以用私鑰解密，反之择镇。這方面的算法有RSA挡逼。ssh 和 ssl都是典型的非對(duì)稱加密。

————————————————

版權(quán)聲明：本文為CSDN博主「請(qǐng)叫我空空大人」的原創(chuàng)文章腻豌，遵循CC 4.0 by-sa版權(quán)協(xié)議家坎，轉(zhuǎn)載請(qǐng)附上原文出處鏈接及本聲明。

原文鏈接：https://blog.csdn.net/wen_haha/article/details/88362469