線程池原理

參考：
Java 線程池原理分析

線程池工作原理：
1秤茅、線程數(shù)量小于 corePoolSize挎春，直接創(chuàng)建新線程處理新的任務(wù)
2、線程數(shù)量大于等于 corePoolSize，workQueue 未滿，則緩存新任務(wù)
3、線程數(shù)量大于等于 corePoolSize勋桶，但小于 maximumPoolSize脱衙，且 workQueue 已滿。則創(chuàng)建新線程處理新任務(wù)
4例驹、線程數(shù)量大于等于 maximumPoolSize捐韩，且 workQueue 已滿，則使用拒絕策略處理新任務(wù)

如何快速定位ANR

參考：
巧妙定位ANR問(wèn)題

1鹃锈、拿到/data/anr/trace.txt對(duì)應(yīng)的文件荤胁，然后搜索關(guān)鍵字ANR。
2屎债、搜索"Dalvik Thread"關(guān)鍵字找到主線程

Glide緩存與解碼復(fù)用

image

Glide擁有4級(jí)緩存

1仅政、活動(dòng)資源：如果當(dāng)前對(duì)應(yīng)的圖片資源正在使用，則這個(gè)圖片會(huì)被Glide放入活動(dòng)緩存盆驹。
2圆丹、內(nèi)存緩存：如果圖片最近被加載過(guò)，并且當(dāng)前沒(méi)有使用這個(gè)圖片躯喇，則會(huì)被放入內(nèi)存中
3辫封、解碼過(guò)的資源類(lèi)型: 被解碼后的圖片寫(xiě)入磁盤(pán)文件中，解碼的過(guò)程可能修改了圖片的參數(shù)(如:inSampleSize廉丽、inPreferredConfig)
4倦微、原始數(shù)據(jù): 圖片原始數(shù)據(jù)在磁盤(pán)中的緩存(從網(wǎng)絡(luò)、文件中直接獲得的原始數(shù)據(jù))

Bitmap復(fù)用
Glide中正压，在每次解析一張圖片為Bitmap的時(shí)候(磁盤(pán)緩存欣福、網(wǎng)絡(luò)/文件)會(huì)從其BitmapPool中查找一個(gè)可被復(fù)用的Bitmap。
BitmapPool是Glide中的Bitmap復(fù)用池,同樣適用LRU來(lái)進(jìn)行管理焦履。
當(dāng)一個(gè)Bitmap從內(nèi)存緩存 被動(dòng) 的被移除(內(nèi)存緊張劣欢、達(dá)到maxSize)的時(shí)候并不會(huì)被recycle棕诵。而是加入這個(gè)BitmapPool，只有從這個(gè)BitmapPool 被動(dòng)的被移除的時(shí)候,Bitmap的內(nèi)存才會(huì)真正被recycle釋放凿将。

Android Dalvik與ART的區(qū)別

Dalvik和JVM的關(guān)系
1校套、Dalvik是基于寄存器的，而JVM是基于棧的牧抵。
2笛匙、Dalvik運(yùn)行dex文件，而JVM運(yùn)行java字節(jié)碼犀变。

ART 的機(jī)制與 Dalvik 不同妹孙。在Dalvik下，應(yīng)用每次運(yùn)行的時(shí)候获枝，字節(jié)碼都需要通過(guò)即時(shí)編譯器（just in time 蠢正，JIT）轉(zhuǎn)換為機(jī)器碼，這會(huì)拖慢應(yīng)用的運(yùn)行效率省店，而在ART 環(huán)境中嚣崭，應(yīng)用在第一次安裝的時(shí)候，字節(jié)碼就會(huì)預(yù)先編譯成機(jī)器碼懦傍，使其成為真正的本地應(yīng)用雹舀。這個(gè)過(guò)程叫做預(yù)編譯（AOT,Ahead-Of-Time）。這樣的話粗俱，應(yīng)用的啟動(dòng)(首次)和執(zhí)行都會(huì)變得更加快速说榆。Android 4.4引入。
優(yōu)點(diǎn)：
1寸认、系統(tǒng)性能的顯著提升签财。
2、應(yīng)用啟動(dòng)更快偏塞、運(yùn)行更快荠卷、體驗(yàn)更流暢、觸感反饋更及時(shí)烛愧。
3油宜、更長(zhǎng)的電池續(xù)航能力。
4怜姿、支持更低的硬件慎冤。
缺點(diǎn)：
1.機(jī)器碼占用的存儲(chǔ)空間更大，字節(jié)碼變?yōu)闄C(jī)器碼之后沧卢，可能會(huì)增加10%-20%（不過(guò)在應(yīng)用包中蚁堤，可執(zhí)行的代碼常常只是一部分。比如最新的 Google+ APK 是 28.3 MB但狭，但是代碼只有 6.9 MB披诗。）
2.應(yīng)用的安裝時(shí)間會(huì)變長(zhǎng)撬即。

Loop為什么不會(huì)阻塞主線程，死循環(huán)為什么不會(huì)耗盡cpu資源

ActivityThread thread = new ActivityThread();
thread.attach(false);//建立Binder通道 (創(chuàng)建新線程)

主線程的死循環(huán)一直運(yùn)行是不是特別消耗CPU資源呢呈队？ 其實(shí)不然剥槐，這里就涉及到Linux pipe/epoll機(jī)制，簡(jiǎn)單說(shuō)就是在主線程的MessageQueue沒(méi)有消息時(shí)宪摧，便阻塞在loop的queue.next()中的nativePollOnce()方法里粒竖，此時(shí)主線程會(huì)釋放CPU資源進(jìn)入休眠狀態(tài)，直到下個(gè)消息到達(dá)或者有事務(wù)發(fā)生几于，通過(guò)往pipe管道寫(xiě)端寫(xiě)入數(shù)據(jù)來(lái)喚醒主線程工作蕊苗。這里采用的epoll機(jī)制，是一種IO多路復(fù)用機(jī)制沿彭，可以同時(shí)監(jiān)控多個(gè)描述符朽砰，當(dāng)某個(gè)描述符就緒(讀或?qū)懢途w)，則立刻通知相應(yīng)程序進(jìn)行讀或?qū)懖僮骱砹酰举|(zhì)同步I/O瞧柔，即讀寫(xiě)是阻塞的。 所以說(shuō)饱搏，主線程大多數(shù)時(shí)候都是處于休眠狀態(tài)非剃，并不會(huì)消耗大量CPU資源置逻。

xml布局中Include推沸、ViewStub、Merge的區(qū)別

Include：解決布局復(fù)用券坞、如果對(duì)include設(shè)置了id有可能導(dǎo)致找不到layout根布局的id
ViewStub：ViewStub就是一個(gè)寬高都為0的一個(gè)View鬓催，它默認(rèn)是不可見(jiàn)的。
只有通過(guò)調(diào)用 setVisibility() 函數(shù)或者 Inflate() 函數(shù)才會(huì)將其要裝載的目標(biāo)布局給加載出來(lái)恨锚，從而達(dá)到延遲加載的效果宇驾。
在ViewStub布局可顯示之前，系統(tǒng)不會(huì)消耗資源去實(shí)例化里面的布局猴伶，可以節(jié)省系統(tǒng)資源消耗
Merge：merge它可以刪減多余的層級(jí)课舍，優(yōu)化UI。
例如你的主布局文件是垂直的LinearLayout他挎，這時(shí)使用include將 my_layout.xml 引入進(jìn)來(lái)筝尾。
新布局也是垂直的LinearLayout，那么這個(gè)新的LinearLayout就沒(méi)有任何意義了办桨。使用的話反而增加反應(yīng)時(shí)間筹淫。這時(shí)可以使用<merge/>標(biāo)簽優(yōu)化。merge 原理就是在解析xml時(shí)候呢撞，如果是 <merge/> 標(biāo)簽损姜，那么直接將其中的子元素添加到merge 標(biāo)簽parent中饰剥，這樣就保證了不會(huì)引入額外的層級(jí)

view的繪制原理

從ViewRootImpl的performTraversals()開(kāi)始被觸發(fā)，遍歷view的onMeasure摧阅、onLayout汰蓉、onDraw。
onMeasure：MeasureSpec 三種模式逸尖。32位古沥，前2位代表模式，后2位代表size娇跟。

final int childWidthMeasureSpec = getChildMeasureSpec(widthMeasureSpec,
                            mPaddingLeft + mPaddingRight + lp.leftMargin + lp.rightMargin,
                            lp.width);
                    child.measure(childWidthMeasureSpec, childHeightMeasureSpec);

public static int getChildMeasureSpec(int spec, int padding, int childDimension) {
        int specMode = MeasureSpec.getMode(spec);
        int specSize = MeasureSpec.getSize(spec);

        int size = Math.max(0, specSize - padding);

        int resultSize = 0;
        int resultMode = 0;

        switch (specMode) {
        // Parent has imposed an exact size on us
        case MeasureSpec.EXACTLY:
            if (childDimension >= 0) {
                resultSize = childDimension;
                resultMode = MeasureSpec.EXACTLY;
            } else if (childDimension == LayoutParams.MATCH_PARENT) {
                // Child wants to be our size. So be it.
                resultSize = size;
                resultMode = MeasureSpec.EXACTLY;
            } else if (childDimension == LayoutParams.WRAP_CONTENT) {
                // Child wants to determine its own size. It can't be
                // bigger than us.
                resultSize = size;
                resultMode = MeasureSpec.AT_MOST;
            }
            break;

        // Parent has imposed a maximum size on us
        case MeasureSpec.AT_MOST:
            if (childDimension >= 0) {
                // Child wants a specific size... so be it
                resultSize = childDimension;
                resultMode = MeasureSpec.EXACTLY;
            } else if (childDimension == LayoutParams.MATCH_PARENT) {
                // Child wants to be our size, but our size is not fixed.
                // Constrain child to not be bigger than us.
                resultSize = size;
                resultMode = MeasureSpec.AT_MOST;
            } else if (childDimension == LayoutParams.WRAP_CONTENT) {
                // Child wants to determine its own size. It can't be
                // bigger than us.
                resultSize = size;
                resultMode = MeasureSpec.AT_MOST;
            }
            break;

        // Parent asked to see how big we want to be
        case MeasureSpec.UNSPECIFIED:
            if (childDimension >= 0) {
                // Child wants a specific size... let him have it
                resultSize = childDimension;
                resultMode = MeasureSpec.EXACTLY;
            } else if (childDimension == LayoutParams.MATCH_PARENT) {
                // Child wants to be our size... find out how big it should
                // be
                resultSize = View.sUseZeroUnspecifiedMeasureSpec ? 0 : size;
                resultMode = MeasureSpec.UNSPECIFIED;
            } else if (childDimension == LayoutParams.WRAP_CONTENT) {
                // Child wants to determine its own size.... find out how
                // big it should be
                resultSize = View.sUseZeroUnspecifiedMeasureSpec ? 0 : size;
                resultMode = MeasureSpec.UNSPECIFIED;
            }
            break;
        }
        //noinspection ResourceType
        return MeasureSpec.makeMeasureSpec(resultSize, resultMode);
    }

Android為什么會(huì)出現(xiàn)卡頓

1岩齿、渲染性能，布局層級(jí)過(guò)深苞俘。60fps即一秒鐘需要渲染60幀盹沈，每個(gè)16ms發(fā)出VSYNC信號(hào)，掉幀吃谣。
2乞封、垃圾回收會(huì)阻塞線程。所以避免頻繁的創(chuàng)建對(duì)象和回收對(duì)象岗憋。不要在生命周期短的方法中創(chuàng)建對(duì)象肃晚，比如onDraw中創(chuàng)建Paint對(duì)象。
3仔戈、動(dòng)畫(huà)過(guò)于復(fù)雜关串，超過(guò)16ms。

JVM內(nèi)存結(jié)構(gòu)

1监徘、線程私有：程序計(jì)數(shù)器晋修、jvm虛擬機(jī)棧、本地方法棧
2凰盔、線程共有：堆墓卦、方法區(qū)（包含常量池）（沒(méi)有明確的規(guī)范）
垃圾回收的判斷標(biāo)準(zhǔn)：
1、計(jì)數(shù)法：循環(huán)依賴的對(duì)象不能被回收
2户敬、根查找法（目前采用）
垃圾回收算法：
1落剪、標(biāo)記清理：會(huì)造成內(nèi)存碎片
2、復(fù)制收集法：分成2個(gè)大小相等的區(qū)尿庐，將在使用的對(duì)象復(fù)制到應(yīng)一塊內(nèi)存中忠怖，一次性清理未使用的對(duì)象 會(huì)造成內(nèi)存浪費(fèi)
3、標(biāo)記 整理 清理
4屁倔、分代算法：分成新生代脑又、老年代、持久代。
新生代按8：1：1分成edge和survival區(qū)

Flutter的skia渲染引擎和Android原生渲染引擎的差別

目前问麸，Skia已然是Android官方的圖像渲染引擎了往衷，因此Flutter Android SDK無(wú)需內(nèi)嵌Skia引擎就可以獲得天然的Skia支持；
Dart因?yàn)橥瑫r(shí)支持JIT和AOT严卖，所以既開(kāi)發(fā)效率高席舍，又運(yùn)行速度好、執(zhí)行性能高.
FlutterView集成FrameLayout，內(nèi)部持有FlutterSurfaceView繼承SurfaceView。

View和SurfaceView的區(qū)別:
1码党、View適用于主動(dòng)更新的情況，而SurfaceView則適用于被動(dòng)更新的情況福铅，比如頻繁刷新界面。
2项阴、View在主線程中對(duì)頁(yè)面進(jìn)行刷新滑黔，而SurfaceView則開(kāi)啟一個(gè)子線程來(lái)對(duì)頁(yè)面進(jìn)行刷新。
3环揽、View在繪圖時(shí)沒(méi)有實(shí)現(xiàn)雙緩沖機(jī)制略荡，SurfaceView在底層機(jī)制中就實(shí)現(xiàn)了雙緩沖機(jī)制。

雙緩沖技術(shù)是游戲開(kāi)發(fā)中的一個(gè)重要的技術(shù)歉胶。當(dāng)一個(gè)動(dòng)畫(huà)爭(zhēng)先顯示時(shí)汛兜，程序又在改變它，前面還沒(méi)有顯示完通今，程序又請(qǐng)求重新繪制粥谬，這樣屏幕就會(huì)不停地閃爍。而雙緩沖技術(shù)是把要處理的圖片在內(nèi)存中處理好之后衡创，再將其顯示在屏幕上帝嗡。雙緩沖主要是為了解決 反復(fù)局部刷屏帶來(lái)的閃爍晶通。把要畫(huà)的東西先畫(huà)到一個(gè)內(nèi)存區(qū)域里璃氢，然后整體的一次性畫(huà)出來(lái)。

sync和lock的區(qū)別和原理狮辽。

image.png

synchronized是在JVM層面上實(shí)現(xiàn)的一也，不但可以通過(guò)一些監(jiān)控工具監(jiān)控synchronized的鎖定，而且在代碼執(zhí)行時(shí)出現(xiàn)異常喉脖，JVM會(huì)自動(dòng)釋放鎖定椰苟，但是使用Lock則不行，lock是通過(guò)代碼實(shí)現(xiàn)的树叽，要保證鎖定一定會(huì)被釋放舆蝴，就必須將unLock()放到finally{}中。

存儲(chǔ)優(yōu)化

SharedPreferences：
1、跨進(jìn)程不安全
2洁仗、加載緩慢
3层皱、全量寫(xiě)入
4、卡頓 apply異步寫(xiě)入在崩潰火其他異常情況下會(huì)導(dǎo)致數(shù)據(jù)丟失赠潦。
Protocol Buffers：
1叫胖、性能。使用了二進(jìn)制編碼壓縮她奥，相比 JSON 體積更小瓮增，編解碼速度也更快，感興趣的同學(xué)可以參考protocol-buffers 編碼規(guī)則
2哩俭、兼容性绷跑。跨語(yǔ)言和前后兼容性都不錯(cuò)凡资，也支持基本類(lèi)型的自動(dòng)轉(zhuǎn)換你踩，但是不支持繼承與引用類(lèi)型
3、使用成本讳苦。Protocol Buffers 的開(kāi)發(fā)成本很高带膜，需要定義.proto 文件，并用工具生成對(duì)應(yīng)的輔助類(lèi)鸳谜。輔助類(lèi)特有一些序列化的輔助方法膝藕，所有要序列化的對(duì)象，都需要先轉(zhuǎn)化為輔助類(lèi)的對(duì)象咐扭，這讓序列化代碼跟業(yè)務(wù)代碼大量耦合芭挽，是侵入性較強(qiáng)的一種方式。

sqlite：
便于管理蝗肪，除非保存的數(shù)據(jù)比較大否則不建議使用袜爪。

Binder

Binder IPC 機(jī)制中涉及到的內(nèi)存映射通過(guò) mmap() 來(lái)實(shí)現(xiàn)，mmap() 是操作系統(tǒng)中一種內(nèi)存映射的方法薛闪。內(nèi)存映射簡(jiǎn)單的講就是將用戶空間的一塊內(nèi)存區(qū)域映射到內(nèi)核空間辛馆。映射關(guān)系建立后，用戶對(duì)這塊內(nèi)存區(qū)域的修改可以直接反應(yīng)到內(nèi)核空間豁延；反之內(nèi)核空間對(duì)這段區(qū)域的修改也能直接反應(yīng)到用戶空間昙篙。
內(nèi)存映射能減少數(shù)據(jù)拷貝次數(shù)，實(shí)現(xiàn)用戶空間和內(nèi)核空間的高效互動(dòng)诱咏。兩個(gè)空間各自的修改能直接反映在映射的內(nèi)存區(qū)域苔可，從而被對(duì)方空間及時(shí)感知。也正因?yàn)槿绱舜瑑?nèi)存映射能夠提供對(duì)進(jìn)程間通信的支持焚辅。
一次完整的 Binder IPC 通信過(guò)程通常是這樣：
1.首先 Binder 驅(qū)動(dòng)在內(nèi)核空間創(chuàng)建一個(gè)數(shù)據(jù)接收緩存區(qū)映屋；
2.接著在內(nèi)核空間開(kāi)辟一塊內(nèi)核緩存區(qū)，建立內(nèi)核緩存區(qū)和內(nèi)核中數(shù)據(jù)接收緩存區(qū)之間的映射關(guān)系同蜻，以及內(nèi)核中數(shù)據(jù)接收緩存區(qū)和接收進(jìn)程用戶空間地址的映射關(guān)系秧荆；
3.發(fā)送方進(jìn)程通過(guò)系統(tǒng)調(diào)用 copyfromuser() 將數(shù)據(jù) copy 到內(nèi)核中的內(nèi)核緩存區(qū)，由于內(nèi)核緩存區(qū)和接收進(jìn)程的用戶空間存在內(nèi)存映射埃仪，因此也就相當(dāng)于把數(shù)據(jù)發(fā)送到了接收進(jìn)程的用戶空間乙濒，這樣便完成了一次進(jìn)程間的通信。

AIDL:

IBinder : IBinder 是一個(gè)接口卵蛉，代表了一種跨進(jìn)程通信的能力颁股。只要實(shí)現(xiàn)了這個(gè)借口，這個(gè)對(duì)象就能跨進(jìn)程傳輸傻丝。
IInterface : IInterface 代表的就是 Server 進(jìn)程對(duì)象具備什么樣的能力（能提供哪些方法甘有，其實(shí)對(duì)應(yīng)的就是 AIDL 文件中定義的接口）
Binder : Java 層的 Binder 類(lèi)，代表的其實(shí)就是 Binder 本地對(duì)象葡缰。BinderProxy 類(lèi)是 Binder 類(lèi)的一個(gè)內(nèi)部類(lèi)亏掀，它代表遠(yuǎn)程進(jìn)程的 Binder 對(duì)象的本地代理；這兩個(gè)類(lèi)都繼承自 IBinder, 因而都具有跨進(jìn)程傳輸?shù)哪芰Ψ菏停粚?shí)際上滤愕，在跨越進(jìn)程的時(shí)候，Binder 驅(qū)動(dòng)會(huì)自動(dòng)完成這兩個(gè)對(duì)象的轉(zhuǎn)換怜校。
Stub : AIDL 的時(shí)候间影，編譯工具會(huì)給我們生成一個(gè)名為 Stub 的靜態(tài)內(nèi)部類(lèi)；這個(gè)類(lèi)繼承了 Binder, 說(shuō)明它是一個(gè) Binder 本地對(duì)象茄茁，它實(shí)現(xiàn)了 IInterface 接口魂贬，表明它具有 Server 承諾給 Client 的能力；Stub 是一個(gè)抽象類(lèi)裙顽，具體的 IInterface 的相關(guān)實(shí)現(xiàn)需要開(kāi)發(fā)者自己實(shí)現(xiàn)付燥。
1、創(chuàng)建實(shí)體類(lèi)Book實(shí)現(xiàn)Parcelable接口
2愈犹、創(chuàng)建接口BookManager.aidl并提供相應(yīng)的方法
3键科、編寫(xiě)服務(wù)端代碼AIDLService extends Service。內(nèi)部創(chuàng)建BookManager.Stub對(duì)象甘萧。并重寫(xiě)服務(wù)端的方法萝嘁“鸬В客戶綁定service并與服務(wù)端進(jìn)行通信扬卷。

APT

HashMap 和 HashTable 以及 CurrentHashMap 的區(qū)別。

一般來(lái)說(shuō)酸钦，這三個(gè)東西基本在面試中 70% 會(huì)被問(wèn)到怪得，而問(wèn)的方向也不太一樣。比如初級(jí)的問(wèn)法是講講它們之前的區(qū)別，這個(gè)我想沒(méi)什么難度徒恋，大多數(shù)人還是知道主要核心區(qū)別是并發(fā)上的處理蚕断。此外，內(nèi)部數(shù)據(jù)結(jié)構(gòu)的實(shí)現(xiàn)入挣、擴(kuò)容亿乳、存取操作這些問(wèn)題應(yīng)該是很老生常談了，這并沒(méi)有什么好說(shuō)的径筏，大多數(shù)人也都知道葛假。稍微問(wèn)的深一點(diǎn)的可能會(huì)在下面這些點(diǎn)上出問(wèn)題。哈希碰撞滋恬，哈希計(jì)算聊训，哈希映射，為什么是頭插法恢氯，擴(kuò)容為什么是 2 的冪次等這樣的問(wèn)題带斑。

synchronized 和 volatile 、ReentrantLock 勋拟、CAS 的區(qū)別勋磕。

這個(gè)問(wèn)題被問(wèn)頻率不在 HashMap 之下，因?yàn)椴l(fā)編程敢靡，真的很重要朋凉。能問(wèn)到這幾個(gè)點(diǎn)的方式真的是太多了，我們能發(fā)揮的空間也同樣很大醋安。CAS 的 ABA 問(wèn)題杂彭？上面幾個(gè)東西的特性？使用場(chǎng)景吓揪？大概我不用再例舉了吧亲怠？對(duì)了，我多次被問(wèn)到的一個(gè)問(wèn)題是：synchronized 修飾實(shí)例方法和修飾靜態(tài)方法有啥不一樣柠辞。

JVM 類(lèi)加載機(jī)制团秽、垃圾回收算法對(duì)比、Java 虛擬機(jī)結(jié)構(gòu)等叭首。

這三個(gè)問(wèn)題大概出現(xiàn)概率 40%习勤，基本只需要看我每日一問(wèn)系列的推文就差不多了吧，希望更清楚明白的可以直接看《深入理解 Java 虛擬機(jī)》焙格。當(dāng)你講到分代回收算法的時(shí)候图毕，不免會(huì)被追問(wèn)到新生對(duì)象是怎么從年輕代到老年代的，以及可以作為 root 結(jié)點(diǎn)的對(duì)象有哪些兩個(gè)問(wèn)題眷唉。

Java 的四大引用

四大引用面試出現(xiàn)概率比我想象中要高予颤，我原本以為就強(qiáng)引用囤官、軟引用、弱引用蛤虐、虛引用這四個(gè)玩意兒沒(méi)啥可講的党饮。實(shí)際上也確實(shí)沒(méi)啥好講的，稍微問(wèn)的深一些的面試官會(huì)和內(nèi)存泄漏檢測(cè)原理以及垃圾回收糅雜在一起驳庭。

Java 的泛型刑顺，<? super T> 和 <? extends T> 的區(qū)別。

<? extends T>：是指 上界通配符（Upper Bounds Wildcards） 只有讀取權(quán)限 沒(méi)有寫(xiě)入權(quán)限
<? super T>：是指 下界通配符（Lower Bounds Wildcards）只有寫(xiě)入權(quán)限 沒(méi)有讀取權(quán)限
頻繁往外讀取內(nèi)容的饲常，適合用上界Extends捏检。
經(jīng)常往里插入的，適合用下界Super不皆。

Java 線程有哪些狀態(tài)贯城，有哪些鎖，各種鎖的區(qū)別霹娄。

線程狀態(tài)：新建能犯、就緒、運(yùn)行犬耻、阻塞踩晶、死亡
對(duì)應(yīng)的方法：
進(jìn)入就緒狀態(tài)：star
運(yùn)行狀態(tài)：由CPU進(jìn)行調(diào)控
阻塞狀態(tài)：sleep()、wait()枕磁、join()渡蜻、suspend()(已廢棄)
死亡狀態(tài):run()方法的正常退出

線程鎖：
1、synchronized必須有對(duì)應(yīng)的鎖對(duì)象计济，ReentrantLock沒(méi)有對(duì)應(yīng)的鎖對(duì)象茸苇，這兩個(gè)鎖之間無(wú)論如何都不會(huì)互斥。
2沦寂、ReentrantLock提供了更多功能学密，比如tryLock()、設(shè)置鎖的公平性传藏、是否可以接收中斷信號(hào)等腻暮。3、synchronized沒(méi)有對(duì)應(yīng)的功能毯侦。synchronized關(guān)鍵字是從虛擬機(jī)層次上保證互斥的哭靖，而ReentrantLock是從代碼層次上保證互斥的。

sleep 侈离、wait试幽、yield 的區(qū)別，wait 的線程如何喚醒它霍狰？

wait和sleep的區(qū)別 面試 wait和notify yield
很基本的區(qū)別：wait是object類(lèi)的方法抡草，sleep饰及、yield是thread類(lèi)的方法蔗坯。
wait釋放cpu資源康震，同時(shí)釋放鎖
sleep也釋放cpu資源，但不釋放鎖
wait需要搭配notify

final 宾濒、finally腿短、finalize 區(qū)別。
final 用于申明屬性绘梦，方法和類(lèi)橘忱，表示屬性不可變，方法不可以被覆蓋卸奉，類(lèi)不可以被繼承钝诚。
finally 是異常處理語(yǔ)句結(jié)構(gòu)中，表示總是執(zhí)行的部分榄棵∧模　　
finallize 表示是object類(lèi)一個(gè)方法，在垃圾回收機(jī)制中執(zhí)行的時(shí)候會(huì)被調(diào)用被回收對(duì)象的方法疹鳄。允許回收此前未回收的內(nèi)存垃圾拧略。所有object都繼承了finalize（）方法

計(jì)算機(jī)網(wǎng)絡(luò)部分。

計(jì)算機(jī)網(wǎng)絡(luò)部分還是挺容易考察的瘪弓，不過(guò)考察的點(diǎn)不會(huì)那么深入垫蛆。通常來(lái)說(shuō)也就是這些問(wèn)題：

TCP 有哪些狀態(tài)。
三次握手腺怯、四次揮手袱饭。為啥是三次不是兩次？
參考：
通俗大白話來(lái)理解TCP協(xié)議的三次握手和四次分手

image.png

三次握手：因?yàn)榭蛻舳撕头?wù)端兩邊都需要確認(rèn)收到對(duì)方的消息呛占，這樣才能表示網(wǎng)絡(luò)通道是連通的宁赤。客戶端發(fā)起占了一次栓票，然后雙方各自確認(rèn)又占了一次决左，所以需要三次握手。
四次揮手:
那四次分手又是為何呢走贪？TCP協(xié)議是一種面向連接的佛猛、可靠的、基于字節(jié)流的運(yùn)輸層通信協(xié)議坠狡。TCP是全雙工模式继找，這就意味著，當(dāng)主機(jī)1發(fā)出FIN報(bào)文段時(shí)逃沿，只是表示主機(jī)1已經(jīng)沒(méi)有數(shù)據(jù)要發(fā)送了婴渡，主機(jī)1告訴主機(jī)2幻锁，它的數(shù)據(jù)已經(jīng)全部發(fā)送完畢了；但是边臼，這個(gè)時(shí)候主機(jī)1還是可以接受來(lái)自主機(jī)2的數(shù)據(jù)哄尔；當(dāng)主機(jī)2返回ACK報(bào)文段時(shí)，表示它已經(jīng)知道主機(jī)1沒(méi)有數(shù)據(jù)發(fā)送了柠并，但是主機(jī)2還是可以發(fā)送數(shù)據(jù)到主機(jī)1的岭接；當(dāng)主機(jī)2也發(fā)送了FIN報(bào)文段時(shí)，這個(gè)時(shí)候就表示主機(jī)2也沒(méi)有數(shù)據(jù)要發(fā)送了臼予，就會(huì)告訴主機(jī)1鸣戴，我也沒(méi)有數(shù)據(jù)要發(fā)送了，之后彼此就會(huì)愉快的中斷這次TCP連接粘拾。如果要正確的理解四次分手的原理窄锅，就需要了解四次分手過(guò)程中的狀態(tài)變化。
還是用打電話舉例：
1缰雇、A跟B說(shuō) 我要掛斷電話了
2入偷、B回復(fù)A 我收到你要掛斷電話的消息了
3、B跟A說(shuō) 那我也要掛斷了
4寓涨、A回復(fù)B說(shuō) 我確認(rèn)你要掛斷了

HTTPS 和 HTTP 的區(qū)別盯串。HTTPS 2.0，3.0戒良？
瀏覽器輸入一個(gè) URL体捏，按下回車(chē)網(wǎng)絡(luò)傳輸?shù)牧鞒蹋?br> 喜歡深問(wèn)一點(diǎn)的還會(huì)問(wèn)到網(wǎng)絡(luò)架構(gòu)，每層有些什么協(xié)議糯崎，F(xiàn)TP 這些相關(guān)原理几缭，印象比較深刻的還有一個(gè)問(wèn)題是：TCP 建立連接后，發(fā)包頻率是怎樣的沃呢？

image.png

Kotlin

優(yōu)點(diǎn)：
1年栓、完全兼容Java
2、NULL safe
3薄霜、支持lambda表達(dá)式
4某抓、支持?jǐn)U展方法和屬性
5、優(yōu)秀的IDE支持

缺點(diǎn)：
1惰瓜、編譯速度變慢
2否副、增大代碼量
3、額外的學(xué)習(xí)成本

Android 部分

Android 很廣崎坊，所以這里只是簡(jiǎn)單說(shuō)下有些什么問(wèn)題备禀。這個(gè)的話其實(shí)真的 70% 問(wèn)題出自你的簡(jiǎn)歷。

Activity 的生命周期；
Android 的 4 大啟動(dòng)模式曲尸，注意 onNewIntent() 的調(diào)用赋续；
組件化架構(gòu)思路，如何從一個(gè)老項(xiàng)目一步一步實(shí)現(xiàn)組件化另患，主要問(wèn)實(shí)現(xiàn)思路纽乱，考察應(yīng)試者的架構(gòu)能力和思考能力。
這一塊內(nèi)容真的很多柴淘，你需要考慮的問(wèn)題很多迫淹，哪一步做什么秘通，順序很重要为严。
MVC、MCP肺稀、MVVP 的區(qū)別和各種使用場(chǎng)景第股，如何選擇適合自己的開(kāi)發(fā)架構(gòu)？
Router 原理话原，如何實(shí)現(xiàn)組件間通信夕吻，組件化平級(jí)調(diào)用數(shù)據(jù)方式。
系統(tǒng)打包流程繁仁；
APP 啟動(dòng)流程涉馅；
如何做啟動(dòng)優(yōu)化？
冷啟動(dòng)什么的肯定是基礎(chǔ)黄虱，后續(xù)應(yīng)該還有的是懶加載稚矿，丟線程池同步處理，需要注意這里可能會(huì)有的坑是捻浦，丟線程池如何知道全部完成晤揣。
事件分發(fā)機(jī)制。
事件分發(fā)已經(jīng)不是直接讓你講了朱灿，會(huì)給你具體的場(chǎng)景昧识，比如 A 嵌套 B ，B 嵌套 C盗扒，從 C 中心按下跪楞，一下滑出到 A，事件分發(fā)的過(guò)程侣灶，這里面肯定會(huì)有 ACTION_CANCEL 的相關(guān)調(diào)用時(shí)機(jī)甸祭。
如何檢測(cè)卡頓，卡頓原理是什么炫隶，怎么判斷是頁(yè)面響應(yīng)卡頓還是邏輯處理造成的卡頓淋叶？
生產(chǎn)者模式和消費(fèi)者模式的區(qū)別？
單例模式雙重加鎖，為什么要這樣做煞檩。
Handler 機(jī)制原理处嫌，IdleHandler 什么時(shí)候調(diào)用。
LeakCanary 原理斟湃，為什么檢測(cè)內(nèi)存泄漏需要兩次熏迹？
BlockCanary 原理。
ViewGroup 繪制順序凝赛；
Android 有哪些存儲(chǔ)數(shù)據(jù)的方式注暗。
SharedPrefrence 源碼和問(wèn)題點(diǎn)；
講講 Android 的四大組件墓猎；
屬性動(dòng)畫(huà)捆昏、補(bǔ)間動(dòng)畫(huà)、幀動(dòng)畫(huà)的區(qū)別和使用場(chǎng)景毙沾；
自定義 ViewGroup 如何實(shí)現(xiàn) FlowLayout骗卜？如何實(shí)現(xiàn) FlowLayout 調(diào)換順序？
自定義 View 如何實(shí)現(xiàn)打桌球效果左胞；
自定義 View 如何實(shí)現(xiàn)拉弓效果寇仓，貝瑟爾曲線原理實(shí)現(xiàn)？
APK 瘦身是怎么做的烤宙，只用 armabi-v7a 沒(méi)有什么問(wèn)題么遍烦？
APK 瘦身這個(gè)基本是 100% 被面試問(wèn)到，可能是我簡(jiǎn)歷上提到的原因躺枕。
ListView 和 RecyclerView 區(qū)別服猪？RecyclerView 有幾層緩存，如何讓兩個(gè) RecyclerView 共用一個(gè)緩存屯远？
如何判斷一個(gè) APP 在前臺(tái)還是后臺(tái)蔓姚？
如何做應(yīng)用保活慨丐？全家桶原理坡脐？
講講你所做過(guò)的性能優(yōu)化。
Retrofit 在 OkHttp 上做了哪些封裝房揭？動(dòng)態(tài)代理和靜態(tài)代理的區(qū)別备闲，是怎么實(shí)現(xiàn)的。
講講軌跡視頻的音視頻合成原理捅暴；
AIDL 相關(guān)恬砂；
Binder 機(jī)制，講講 Linux 上的 IPC 通信蓬痒，Binder 有什么優(yōu)勢(shì)泻骤，Android 上有哪些多進(jìn)程通信機(jī)制?
RxJava 的線程切換原理。
OkHttp 和 Volloy 區(qū)別；
Glide 緩存原理狱掂，如何設(shè)計(jì)一個(gè)大圖加載框架演痒。
LRUCache 原理；
講講咕咚項(xiàng)目開(kāi)發(fā)中遇到的最大的一個(gè)難題和挑戰(zhàn)趋惨；
這個(gè)問(wèn)題基本是 95% 必問(wèn)的一個(gè)問(wèn)題鸟顺；
說(shuō)說(shuō)你開(kāi)發(fā)最大的優(yōu)勢(shì)點(diǎn)。
出現(xiàn)率同上器虾。

算法

洗牌算法：隨機(jī)打亂一個(gè)數(shù)組的順序

java.util.Collections.shuffle(List<?> list);

如何層次遍歷樹(shù)結(jié)構(gòu)

String 轉(zhuǎn) int讯嫂。
核心算法就三行代碼，不過(guò)臨界條件很多兆沙，除了判空欧芽，還需要注意負(fù)數(shù)、Integer 的最大最小值邊界等挤悉；
如何判斷一個(gè)單鏈表有環(huán)渐裸？
鏈表翻轉(zhuǎn)巫湘；
快排装悲；
100 億個(gè)單詞，找出出現(xiàn)頻率最高的單詞尚氛。要求幾種方案诀诊；
鏈表每 k 位逆序；
鏡像二叉樹(shù)阅嘶；
找出一個(gè)無(wú)序數(shù)組中出現(xiàn)超過(guò)一半次數(shù)的數(shù)字属瓣；
計(jì)算二叉樹(shù)的最大深度，要求非遞歸算法讯柔。
String 方式計(jì)算加法抡蛙。