1. 整體性能如何探測(cè)，有哪些方面，什么指標(biāo)，怎么保證更流暢
2. 談?wù)劶軜?gòu)。大項(xiàng)目，邏輯多怎么辦，如何應(yīng)對(duì)多App和多終端
3. android的發(fā)展大事件和主要技術(shù)發(fā)展
4. avtivity(service)啟動(dòng)流程簡(jiǎn)述
5. 動(dòng)態(tài)化的幾種方案
6. 熱修復(fù)的原理
7. 網(wǎng)絡(luò)這塊怎么優(yōu)化
8. 數(shù)據(jù)庫(kù)性能怎么保證
9. 線程安全怎么保證，異步并發(fā)這塊你怎么做的

這幾個(gè)問(wèn)題是我根據(jù)自己的面試經(jīng)歷總結(jié)的，大家一起交流學(xué)習(xí)。

其實(shí)不一定面試時(shí)才了解這些，并且了解絕對(duì)不是重點(diǎn)，而是實(shí)踐，絕知此事要躬行是真理，這樣的問(wèn)題也似乎沒(méi)有“最佳答案”，但是可以發(fā)表一下自己觀點(diǎn)和實(shí)踐結(jié)論。

有些做法或觀點(diǎn)一下子想不起來(lái)，需要具體做的時(shí)候再google一下，或者跟朋友溝通拓展一下，所以先做個(gè)簡(jiǎn)單的回答，請(qǐng)大家補(bǔ)充。

[[274821]]

1. App性能如何探測(cè)，有哪些方面，什么指標(biāo)，怎么保證更流暢?

性能可以根據(jù)幀率、內(nèi)存、CPU、GPU等指標(biāo)的數(shù)據(jù)和表現(xiàn)輔助判斷，可以從/proc文件夾下讀取文件獲取cpu、內(nèi)存等信息，也可以用dumpsys命令獲取幀率等信息，也可以通過(guò)android API獲取相關(guān)信息。

還有很多性能相關(guān)的分析工具很重要，輔助判斷和分析，比如Heap Tool、Memory Monitor、Lint、HierarchyView、WireShark、TraceView等。

保證流暢有很多點(diǎn)可以去研究，比如布局、代碼、緩存、網(wǎng)絡(luò)、數(shù)據(jù)庫(kù)、異步并發(fā)等方面的優(yōu)化，涉及很多的知識(shí)點(diǎn)，可以google下，先簡(jiǎn)單說(shuō)下，有時(shí)間再細(xì)述。

布局充分利用include、viewstub、merge 等標(biāo)簽，控制層級(jí)，避免過(guò)度渲染(繪制)。

代碼上盡量使用final、局部變量、系統(tǒng)函數(shù)如arraycopy等、位移操作是否可以代替乘除、for循環(huán)是否可以避免size計(jì)算和new對(duì)象等等。

緩存方面，線程、位圖、視圖、網(wǎng)絡(luò)數(shù)據(jù)是否可以被緩存，IO用緩沖流。

網(wǎng)絡(luò)方面，如盡量避免輪詢，控制節(jié)奏和頻率，IP直連，采用SPDY方案(或HTTP2.0)來(lái)實(shí)現(xiàn)壓縮header、多路復(fù)用、雙向通信等，API數(shù)據(jù)壓縮，多個(gè)請(qǐng)求是否可以合并，數(shù)據(jù)壓縮和嘗試protocol buffer相關(guān)序列化方案。

數(shù)據(jù)庫(kù)方面，嘗試用SQLiteStatement代替SQLiteDatabase完成操作，索引和事務(wù)的充分理解和使用，注意SQL語(yǔ)句語(yǔ)法和拼接，采用部分查詢和延遲加載。

異步并發(fā)方面，全App只有一個(gè)線程池，控制核心并發(fā)數(shù)量，控制超載時(shí)排隊(duì)數(shù)量和策略，合理調(diào)度任務(wù)，優(yōu)化業(yè)務(wù)邏輯。

最后關(guān)于幀率，你看到的視覺(jué)卡頓，直接原因基本是“掉幀”。關(guān)于幀率，盡量保證主線程里做的事情，不會(huì)超過(guò)16毫秒(其實(shí)這挺難的)，16毫秒大法好，具體可以去理解下CPU、GPU、屏幕三者如何配合完成渲染的，推薦老羅的博客。

2. 談?wù)劶軜?gòu)。大項(xiàng)目，邏輯多怎么辦，如何應(yīng)對(duì)多App和多終端

適當(dāng)參考我的回答 怎樣搭高質(zhì)量的Android項(xiàng)目框架，框架的結(jié)構(gòu)具體描述? ，結(jié)合模塊化、組件化思想去做，多實(shí)踐一下mvp、mvvm等策略。

3. android的發(fā)展大事件和主要技術(shù)發(fā)展

額，挺多的，朋友們補(bǔ)充吧。

這個(gè)問(wèn)題蠻好的 Android 開(kāi)發(fā)有哪些新技術(shù)出現(xiàn)?

4. avtivity(service)啟動(dòng)流程簡(jiǎn)述

可以自己閱讀源代碼，結(jié)合羅老師的博客，研究的非常棒：Android應(yīng)用程序啟動(dòng)過(guò)程源代碼分析

5. 動(dòng)態(tài)化的幾種方案

早期的H5方案，通過(guò)js和java互通增強(qiáng)h5的能力。

還有DexClasssLoader結(jié)合反射代理的方案。

還有React Native方案，手淘的Weex框架。

還有Lua等腳本實(shí)現(xiàn)動(dòng)態(tài)化方案。

6. 熱修復(fù)的原理

Github上讀一下AndFix這個(gè)項(xiàng)目的源碼，還有xposed、dexposed。

大致原理就是將java方法通過(guò)c/c++修改屬性變?yōu)閜ublic native方法，上下文攜帶到native層，然后根據(jù)上下文指向另一個(gè)java方法，從而“偷梁換柱”，如果是支持ART的手機(jī)，那么策略不一樣，將bug method的關(guān)鍵信息(classloader、theadid等)保留，將修復(fù)過(guò)的方法的各種信息賦給bug method，完成“移花接木”。

另外，其實(shí)有挺多的策略改變運(yùn)行時(shí)行為的，比如：

• Javasisst：字節(jié)碼修改類庫(kù)，依賴字節(jié)碼修改和DX類庫(kù)，可以完成動(dòng)態(tài)替換和切面編程。
• AspectJ：依賴字節(jié)碼編織器，需要按照其語(yǔ)法來(lái)編寫(xiě)，需要一點(diǎn)“編織”時(shí)間。
• Xposed：簡(jiǎn)直是一個(gè)Bug，神器般的存在，沒(méi)準(zhǔn)以后會(huì)被Android系統(tǒng)修復(fù)呢，不僅可以改變自己的類行為還可以hook系統(tǒng)的方法，root過(guò)的機(jī)器還可以hook其他App和系統(tǒng)進(jìn)程。

7. 網(wǎng)絡(luò)這塊怎么優(yōu)化

盡量避免輪詢，控制節(jié)奏和頻率。

IP直連節(jié)省DNS解析時(shí)間。

嘗試其他數(shù)據(jù)序列化方案比如protocol buffer等。

采用SPDY方案(或HTTP2.0)來(lái)壓縮header、多路復(fù)用、雙向通信等。

服務(wù)器做優(yōu)化，比如分布式、緩存之類的，減少API涉及的業(yè)務(wù)操作所需要的時(shí)間嘛。

API接口數(shù)據(jù)精簡(jiǎn)，多個(gè)請(qǐng)求是否可以合并，增量請(qǐng)求啊、GIP壓縮啊什么的，等等。

8. 數(shù)據(jù)庫(kù)性能怎么保證

嘗試使用SQLiteStatement取代SQLiteDatabase對(duì)象完成操作，避免直接使用SQLiteDatabase提供的update、inset等方法。

索引和事務(wù)的充分理解和使用，批量操作使用事務(wù)極大提升速度，這個(gè)我是做過(guò)試驗(yàn)的，效果驚人。

SQL語(yǔ)句拼接和本身的優(yōu)化，僅查詢部分局部數(shù)據(jù)，使用延遲加載策略。

10萬(wàn)條數(shù)據(jù)插入比系統(tǒng)SQLiteDatabase操作快一倍，推薦我的LiteOrm數(shù)據(jù)庫(kù)框架 https://github.com/litesuits/android-lite-orm

9. 線程安全怎么保證，異步并發(fā)這塊你怎么做的

理解并使用ReentrantLock，Synchronized保護(hù)對(duì)象或過(guò)程，final來(lái)保護(hù)不可變對(duì)象，無(wú)狀態(tài)和只讀對(duì)象是安全的，合理使用一些 concurrent容器，比如concurrenthashmap等，重量級(jí)耗時(shí)任務(wù)考慮是否可以釋放鎖，多線程下實(shí)例化或延遲加載需要保護(hù)起來(lái)，保護(hù)多線程下關(guān)鍵數(shù)據(jù)訪問(wèn)的原子性，等等還有很多的。。。

推薦研究下Doug Lea主寫(xiě)和設(shè)計(jì)的java concurrent包，理解CountDownLatch、CyclicBarrier、Semaphore、FutureTask等對(duì)象。

我使用自己寫(xiě)的SmartExecutor，直接繼承ExecutorService，封裝了一個(gè)公共線程池，全App保證只有一個(gè)線程池。源碼在這個(gè)開(kāi)源項(xiàng)目里：https://github.com/litesuits/android-lite-http 。

在一個(gè) App 中 SmartExecutor 可以有多個(gè)實(shí)例，每個(gè)實(shí)例都有獨(dú)立核心和等待線程數(shù)指標(biāo)，每個(gè)實(shí)例都有獨(dú)立的調(diào)度和滿載處理策略，但它們 **共享一個(gè)線程池**。這種機(jī)制既滿足不同木塊對(duì)線程控制和任務(wù)調(diào)度的獨(dú)立需求，又共享一個(gè)池資源。獨(dú)立又共享，最大程度上節(jié)省資源，提升性能。

控制核心并發(fā)數(shù)，盡量和CPU核數(shù)保持一致(或者多兩個(gè))我認(rèn)為吞吐量是最佳的，線程過(guò)多則調(diào)度線程消耗CPU和時(shí)間，過(guò)少則不能充分利用多核的能力。

控制排隊(duì)策略和排隊(duì)數(shù)量，是否考慮新任務(wù)先處理，過(guò)度超載丟掉最老的任務(wù)。

還有就是業(yè)務(wù)上，合理調(diào)度任務(wù)，優(yōu)化業(yè)務(wù)邏輯，不要胡搞亂搞，不作惡。