1.HandlerThread、IntentService理解

HandlerThread本質(zhì)上就是一個(gè)普通Thread,只不過(guò)內(nèi)部建立了Looper.

IntentService 是繼承自 Service ，內(nèi)部自建線程來(lái)處理異步。

2.int和Integer的區(qū)別

1、Integer是int的包裝類，int則是java的一種基本數(shù)據(jù)類型?

2、Integer變量必須實(shí)例化后才能使用，而int變量不需要?

3、Integer實(shí)際是對(duì)象的引用，當(dāng)new一個(gè)Integer時(shí)，實(shí)際上是生成一個(gè)指針指向此對(duì)象；而int則是直接存儲(chǔ)數(shù)據(jù)值 。

4、Integer的默認(rèn)值是null，int的默認(rèn)值是0

4.android啟動(dòng)模式

5.View的繪制流程

6.事件分發(fā)機(jī)制

7.消息分發(fā)機(jī)制

8.AsyncTask源碼分析

9.如何保證Service不被殺死？如何保證進(jìn)程不被殺死？

10.Binder機(jī)制，進(jìn)程通信Android用到的進(jìn)程通信底層基本都是Binder，AIDL、Messager、廣播、ContentProvider。不是很深入理解的，至少ADIL怎么用，Messager怎么用，可以寫寫看，另外序列化（Parcelable和Serilizable）需要做對(duì)比

11.動(dòng)態(tài)權(quán)限適配問(wèn)題

12.SharedPreference原理，能否跨進(jìn)程？如何實(shí)現(xiàn)？

Android 中的 SharedPreference 是輕量級(jí)的數(shù)據(jù)存儲(chǔ)方式，能夠保存簡(jiǎn)單的數(shù)據(jù)類型，比如 String、int、boolean 值等。其內(nèi)部是以 XML 結(jié)構(gòu)保存在 /data/data/包名/shared_prefs 文件夾下，數(shù)據(jù)以鍵值對(duì)的形式保存

MODE_PRIVATE私有模式，這是最常見(jiàn)的模式，一般情況下都使用該模式。MODE_WORLD_READABLE,MODE_WORLD_WRITEABLE，文件開(kāi)放讀寫權(quán)限，不安全，已經(jīng)被廢棄了，google建議使用FileProvider共享文件。

MODE_MULTI_PROCESS，跨進(jìn)程模式，如果項(xiàng)目有多個(gè)進(jìn)程使用同一個(gè)Preference，需要使用該模式，但是也已經(jīng)廢棄了

推薦使用ContentProivder來(lái)處理多進(jìn)程間的文件共享，F(xiàn)ileProvider也繼承于ContentProvider。實(shí)際上就是一條原則：確保一個(gè)文件只有一個(gè)進(jìn)程在讀寫操作

13.性能優(yōu)化問(wèn)題

UI?

a.合理選擇布局http://www.itdecent.cn/p/2f33c29459b8

b.使用標(biāo)簽<include><merge><ViewStub>

c.減少布局層級(jí)，可以通過(guò)手機(jī)開(kāi)發(fā)者選項(xiàng)>GPU過(guò)渡繪制查看，一般層級(jí)控制在4層以內(nèi)，超過(guò)5層時(shí)需要考慮是否重新排版布局

d.自定義View時(shí)，重寫onDraw()方法，不要在該方法中新建對(duì)象，否則容易觸發(fā)GC，導(dǎo)致性能下降

e.使用ListView時(shí)需要復(fù)用contentView，并使用Holder減少findViewById加載View。

f.去除不必要背景，getWindow().setBackgroundDrawable(null)

g.使用TextView的leftDrawabel/rightDrawable代替ImageView+TextView布局

內(nèi)存優(yōu)化：

主要為了避免OOM和頻繁觸發(fā)到GC導(dǎo)致性能下降

a.Bitmap.recycle(),Cursor.close,inputStream.close()

b.大量加載Bitmap時(shí)，根據(jù)View大小加載Bitmap，合理選擇inSampleSize，RGB_565編碼方式；使用LruCache緩存

c.使用 靜態(tài)內(nèi)部類+WeakReference 代替內(nèi)部類，如Handler、線程、AsyncTask

d.使用線程池管理線程，避免線程的新建

e.使用單例持有Context，需要記得釋放，或者使用全局上下文

f.靜態(tài)集合對(duì)象注意釋放

g.屬性動(dòng)畫造成內(nèi)存泄露

h.使用webView，在Activity.onDestory需要移除和銷毀，webView.removeAllViews()和webView.destory()?

備：使用LeakCanary檢測(cè)內(nèi)存泄露

響應(yīng)速度優(yōu)化 ?

Activity如果5秒之內(nèi)無(wú)法響應(yīng)屏幕觸碰事件和鍵盤輸入事件，就會(huì)出現(xiàn)ANR，而B(niǎo)roadcastReceiver如果10秒之內(nèi)還未執(zhí)行操作也會(huì)出現(xiàn)ANR，Serve20秒會(huì)出現(xiàn)ANR 為了避免ANR，可以開(kāi)啟子線程執(zhí)行耗時(shí)操作，但是子線程不能更新UI，因此需要Handler消息機(jī)制、AsyncTask、IntentService進(jìn)行線程通信。備：出現(xiàn)ANR時(shí)，adb pull data/anr/tarces.txt 結(jié)合log分析

其他性能優(yōu)化

a.常量使用static final修飾

b.使用SparseArray代替HashMap

c.使用線程池管理線程

d.ArrayList遍歷使用常規(guī)for循環(huán)，LinkedList使用foreache.不要過(guò)度使用枚舉，枚舉占用內(nèi)存空間比整型大

f.字符串的拼接優(yōu)先考慮StringBuilder和StringBufferg.數(shù)據(jù)庫(kù)存儲(chǔ)是采用批量插入+事務(wù)

14.設(shè)計(jì)模式

1.單例模式：好幾種寫法，要求會(huì)手寫，分析優(yōu)劣。一般雙重校驗(yàn)鎖中用到volatile，需要分析volatile的原理

2.觀察者模式：要求會(huì)手寫，有些面試官會(huì)問(wèn)你在項(xiàng)目中用到了嗎？實(shí)在沒(méi)有到的可以講一講EventBus，它用到的就是觀察者模式

3.適配器模式：要求會(huì)手寫，有些公司會(huì)問(wèn)和裝飾器模式、代理模式有什么區(qū)別？

4.建造者模式+工廠模式：要求會(huì)手寫

5.策略模式：這個(gè)問(wèn)得比較少，不過(guò)有些做電商的會(huì)問(wèn)。

6.MVC、MVP、MVVM：比較異同，選擇一種你拿手的著重講就行

15.數(shù)據(jù)結(jié)構(gòu)

1.HashMap、LinkedHashMap、ConcurrentHashMap，在用法和原理上有什么差異，很多公司會(huì)考HashMap原理，通過(guò)它做一些擴(kuò)展。https://blog.csdn.net/maowenbei/article/details/80252178

ConcurrentHashMap和Hashtable的區(qū)別

Hashtable和ConcurrentHashMap有什么分別呢？它們都可以用于多線程的環(huán)境，但是當(dāng)Hashtable的大小增加到一定的時(shí)候，性能會(huì)急劇下降，因?yàn)榈鷷r(shí)需要被鎖定很長(zhǎng)的時(shí)間。因?yàn)镃oncurrentHashMap引入了分割(segmentation)，不論它變得多么大，僅僅需要鎖定map的某個(gè)部分，而其它的線程不需要等到迭代完成才能訪問(wèn)map。簡(jiǎn)而言之，在迭代的過(guò)程中，ConcurrentHashMap僅僅鎖定map的某個(gè)部分，而Hashtable則會(huì)鎖定整個(gè)map。

2.ArrayList和LinkedList對(duì)比，這個(gè)相對(duì)簡(jiǎn)單一點(diǎn)。

對(duì)于隨機(jī)訪問(wèn)get和set（查、改），ArrayList覺(jué)得優(yōu)于LinkedList，因?yàn)長(zhǎng)inkedList要移動(dòng)指針。?

對(duì)于新增和刪除操作add和remove，LinedList比較占優(yōu)勢(shì)，因?yàn)锳rrayList要移動(dòng)數(shù)據(jù)。

3.平衡二叉樹(shù)、二叉查找樹(shù)、紅黑樹(shù)，這幾個(gè)我也被考到。

https://blog.csdn.net/wanderlustLee/article/details/81297253

二叉查找樹(shù)就是左結(jié)點(diǎn)小于根節(jié)點(diǎn)，右結(jié)點(diǎn)大于根節(jié)點(diǎn)的一種排序樹(shù)，也叫二叉搜索樹(shù)。也叫BST，英文Binary Sort Tree。

二叉查找樹(shù)比普通樹(shù)查找更快，查找、插入、刪除的時(shí)間復(fù)雜度為O（logN）。但是二叉查找樹(shù)有一種極端的情況，就是會(huì)變成一種線性鏈表似的結(jié)構(gòu)。此時(shí)時(shí)間復(fù)雜度就變味了O（N），為了解決這種情況，出現(xiàn)了二叉平衡樹(shù)。

平衡二叉樹(shù)全稱平衡二叉搜索樹(shù)，也叫AVL樹(shù)。是一種自平衡的樹(shù)。

AVL樹(shù)也規(guī)定了左結(jié)點(diǎn)小于根節(jié)點(diǎn)，右結(jié)點(diǎn)大于根節(jié)點(diǎn)。并且還規(guī)定了左子樹(shù)和右子樹(shù)的高度差不得超過(guò)1。這樣保證了它不會(huì)成為線性的鏈表。AVL樹(shù)的查找穩(wěn)定，查找、插入、刪除的時(shí)間復(fù)雜度都為O（logN），但是由于要維持自身的平衡，所以進(jìn)行插入和刪除結(jié)點(diǎn)操作的時(shí)候，需要對(duì)結(jié)點(diǎn)進(jìn)行頻繁的旋轉(zhuǎn)。

AVL樹(shù)每一個(gè)節(jié)點(diǎn)只能存放一個(gè)元素，并且每個(gè)節(jié)點(diǎn)只有兩個(gè)子節(jié)點(diǎn)。當(dāng)進(jìn)行查找時(shí)，就需要多次磁盤IO，（數(shù)據(jù)是存放在磁盤中的，每次查詢是將磁盤中的一頁(yè)數(shù)據(jù)加入內(nèi)存，樹(shù)的每一層節(jié)點(diǎn)存放在一頁(yè)中，不同層數(shù)據(jù)存放在不同頁(yè)。）這樣如果需要多層查詢就需要多次磁盤IO。為了解決AVL樹(shù)的這個(gè)問(wèn)題，就出現(xiàn)了B樹(shù)（平衡樹(shù)，也叫作B-樹(shù)，英文為Blance-Tree。是一種多路平衡樹(shù)。）

紅黑樹(shù)也叫RB樹(shù)，RB-Tree。是一種自平衡的二叉查找樹(shù)，它的節(jié)點(diǎn)的顏色為紅色和黑色。它不嚴(yán)格控制左、右子樹(shù)高度或節(jié)點(diǎn)數(shù)之差小于等于1。也是一種解決二叉查找樹(shù)極端情況的數(shù)據(jù)結(jié)構(gòu)

4.Set原理，這個(gè)和HashMap考得有點(diǎn)類似，考hash算法相關(guān)，被問(wèn)到過(guò)常用hash算法。HashSet內(nèi)部用到了HashMap

16.源碼理解

https://blog.csdn.net/qq_27053103/article/details/79564062

17.Butterknife

Butterknife使用的是java的注解處理技術(shù)，也就是在代碼編譯的時(shí)候，編譯成字節(jié)碼的時(shí)候，它就處理好了注解操作

注意：java的注解處理技術(shù)是在編譯階段執(zhí)行的，它的原理是通過(guò)讀入我們的源代碼，解析注解然后生產(chǎn)新的java代碼，而新生產(chǎn)的java代碼當(dāng)中，最后被編譯成java字節(jié)碼，由于注解解釋器它是不能改變讀入的java類的。這就是butterknife的注解原理。

18.多線程

volatile和synchronized區(qū)別

對(duì)于volatile修飾的變量，當(dāng)一條線程修改了這個(gè)變量的值，新值對(duì)于其他線程來(lái)說(shuō)是可以立即得知的

volatile變量對(duì)所有線程是立即可見(jiàn)的，對(duì)volatile變量的所有寫操作都能立刻反應(yīng)到其他線程之中

JVM規(guī)范規(guī)定了任何一個(gè)線程修改了volatile變量的值都需要立即將新值更新到主內(nèi)存中, 任何線程任何時(shí)候使用到volatile變量時(shí)都需要重新獲取主內(nèi)存的變量值

兩者區(qū)別:

1.volatile本質(zhì)是在告訴jvm當(dāng)前變量在寄存器（工作內(nèi)存）中的值是不確定的，需要從主存中讀?。籹ynchronized則是鎖定當(dāng)前變量，只有當(dāng)前線程可以訪問(wèn)該變量，其他線程被阻塞住。

2.volatile僅能使用在變量級(jí)別；synchronized則可以使用在變量、方法、和類級(jí)別的

3.volatile僅能實(shí)現(xiàn)變量的修改可見(jiàn)性，不能保證原子性；而synchronized則可以保證變量的修改可見(jiàn)性和原子性

4.volatile不會(huì)造成線程的阻塞；synchronized可能會(huì)造成線程的阻塞。

5.volatile標(biāo)記的變量不會(huì)被編譯器優(yōu)化（禁止指令重排序優(yōu)化，即執(zhí)行順序與程序順序一致）；synchronized標(biāo)記的變量可以被編譯器優(yōu)化

volatile

一旦一個(gè)共享變量（類的成員變量、類的靜態(tài)成員變量）被volatile修飾之后，那么就具備了兩層語(yǔ)義：

1）保證了不同線程對(duì)這個(gè)變量進(jìn)行操作時(shí)的可見(jiàn)性，即一個(gè)線程修改了某個(gè)變量的值，這新值對(duì)其他線程來(lái)說(shuō)是

??? 立即可見(jiàn)的。

2）禁止進(jìn)行指令重排序。

程序的原子性指：整個(gè)程序中的所有操作，要么全部完成，要么全部不完成，不可能停滯在中間某個(gè)環(huán)節(jié)。

原子性操作：原子性在一個(gè)操作是不可中斷的，要么全部執(zhí)行成功要么全部執(zhí)行失敗，有著“同生共死”的感覺(jué)。及時(shí)在多個(gè)線程一起執(zhí)行的時(shí)候，一個(gè)操作一旦開(kāi)始，就不會(huì)被其他線程所干擾。