1. 整體性能如何探測，有哪些方面，什么指標(biāo)，怎么保證更流暢
2. 談?wù)劶軜?gòu)。大項目，邏輯多怎么辦，如何應(yīng)對多App和多終端
3. android的發(fā)展大事件和主要技術(shù)發(fā)展
4. avtivity（service）啟動流程簡述
5. 動態(tài)化的幾種方案
6. 熱修復(fù)的原理
7. 網(wǎng)絡(luò)這塊怎么優(yōu)化
8. 數(shù)據(jù)庫性能怎么保證
9. 線程安全怎么保證，異步并發(fā)這塊你怎么做的
這幾個問題是我根據(jù)自己的面試經(jīng)歷總結(jié)的，朋友 @AndWang 幫分享出來，大家一起交流學(xué)習(xí)。
其實不一定面試時才了解這些，并且了解絕對不是重點(diǎn)，而是實踐，絕知此事要躬行是真理，這樣的問題也似乎沒有“最佳答案”，但是可以發(fā)表一下自己觀點(diǎn)和實踐結(jié)論。
有些做法或觀點(diǎn)一下子想不起來，需要具體做的時候再google一下，或者跟朋友溝通拓展一下，所以先做個簡單的回答，請大家補(bǔ)充。
1. App性能如何探測，有哪些方面，什么指標(biāo)，怎么保證更流暢？
性能可以根據(jù)幀率、內(nèi)存、CPU、GPU等指標(biāo)的數(shù)據(jù)和表現(xiàn)輔助判斷，可以從/proc文件夾下讀取文件獲取cpu、內(nèi)存等信息，也可以用dumpsys命令獲取幀率等信息，也可以通過android API獲取相關(guān)信息。
還有很多性能相關(guān)的分析工具很重要，輔助判斷和分析，比如Heap Tool、Memory Monitor、Lint、HierarchyView、WireShark、TraceView等。
保證流暢有很多點(diǎn)可以去研究，比如布局、代碼、緩存、網(wǎng)絡(luò)、數(shù)據(jù)庫、異步并發(fā)等方面的優(yōu)化，涉及很多的知識點(diǎn)，可以google下，先簡單說下，有時間再細(xì)述。
布局充分利用include、viewstub、merge 等標(biāo)簽，控制層級，避免過度渲染（繪制）。
代碼上盡量使用final、局部變量、系統(tǒng)函數(shù)如arraycopy等、位移操作是否可以代替乘除、for循環(huán)是否可以避免size計算和new對象等等。
緩存方面，線程、位圖、視圖、網(wǎng)絡(luò)數(shù)據(jù)是否可以被緩存，IO用緩沖流。
網(wǎng)絡(luò)方面，如盡量避免輪詢，控制節(jié)奏和頻率，IP直連，采用SPDY方案（或HTTP2.0）來實現(xiàn)壓縮header、多路復(fù)用、雙向通信等，API數(shù)據(jù)壓縮，多個請求是否可以合并，數(shù)據(jù)壓縮和嘗試protocol? ? buffer相關(guān)序列化方案。
數(shù)據(jù)庫方面，嘗試用SQLiteStatement代替SQLiteDatabase完成操作，索引和事務(wù)的充分理解和使用，注意SQL語句語法和拼接，采用部分查詢和延遲加載。
異步并發(fā)方面，全App只有一個線程池，控制核心并發(fā)數(shù)量，控制超載時排隊數(shù)量和策略，合理調(diào)度任務(wù)，優(yōu)化業(yè)務(wù)邏輯。
最后關(guān)于幀率，你看到的視覺卡頓，直接原因基本是“掉幀”。關(guān)于幀率，盡量保證主線程里做的事情，不會超過16毫秒（其實這挺難的），16毫秒大法好，具體可以去理解下CPU、GPU、屏幕三者如何配合完成渲染的，推薦老羅的博客。
2. 談?wù)劶軜?gòu)。大項目，邏輯多怎么辦，如何應(yīng)對多App和多終端
適當(dāng)參考我在知乎的一個回答 怎樣搭高質(zhì)量的Android項目框架，框架的結(jié)構(gòu)具體描述？ ，結(jié)合模塊化、組件化思想去做，多實踐一下mvp、mvvm等策略。
3. android的發(fā)展大事件和主要技術(shù)發(fā)展
額，挺多的，朋友們補(bǔ)充吧。
這個問題蠻好的 Android 開發(fā)有哪些新技術(shù)出現(xiàn)？?
4. avtivity（service）啟動流程簡述
可以自己閱讀源代碼，結(jié)合羅老師的博客，研究的非常棒：Android應(yīng)用程序啟動過程源代碼分析
5. 動態(tài)化的幾種方案
早期的H5方案，通過js和java互通增強(qiáng)h5的能力。
還有DexClasssLoader結(jié)合反射代理的方案。
還有React Native方案，手淘的Weex框架。
還有Lua等腳本實現(xiàn)動態(tài)化方案。
6. 熱修復(fù)的原理
Github上讀一下AndFix這個項目的源碼，還有xposed、dexposed。
大致原理就是將java方法通過c/c++修改屬性變?yōu)閜ublic native方法，上下文攜帶到native層，然后根據(jù)上下文指向另一個java方法，從而“偷梁換柱”，如果是支持ART的手機(jī)，那么策略不一樣，將bug method的關(guān)鍵信息（classloader、theadid等）保留，將修復(fù)過的方法的各種信息賦給bug method，完成“移花接木”。
另外，其實有挺多的策略改變運(yùn)行時行為的，比如：
Javasisst：字節(jié)碼修改類庫，依賴字節(jié)碼修改和DX類庫，可以完成動態(tài)替換和切面編程。
AspectJ：依賴字節(jié)碼編織器，需要按照其語法來編寫，需要一點(diǎn)“編織”時間。
Xposed：簡直是一個Bug，神器般的存在，沒準(zhǔn)以后會被Android系統(tǒng)修復(fù)呢，不僅可以改變自己的類行為還可以hook系統(tǒng)的方法，root過的機(jī)器還可以hook其他App和系統(tǒng)進(jìn)程。
7. 網(wǎng)絡(luò)這塊怎么優(yōu)化
盡量避免輪詢，控制節(jié)奏和頻率。
IP直連節(jié)省DNS解析時間。
嘗試其他數(shù)據(jù)序列化方案比如protocol buffer等。
采用SPDY方案（或HTTP2.0）來壓縮header、多路復(fù)用、雙向通信等。
服務(wù)器做優(yōu)化，比如分布式、緩存之類的，減少API涉及的業(yè)務(wù)操作所需要的時間嘛。
API接口數(shù)據(jù)精簡，多個請求是否可以合并，增量請求啊、GIP壓縮啊什么的，等等。
8. 數(shù)據(jù)庫性能怎么保證
嘗試使用SQLiteStatement取代SQLiteDatabase對象完成操作，避免直接使用SQLiteDatabase提供的update、inset等方法。
索引和事務(wù)的充分理解和使用，批量操作使用事務(wù)極大提升速度，這個我是做過試驗的，效果驚人。
SQL語句拼接和本身的優(yōu)化，僅查詢部分局部數(shù)據(jù)，使用延遲加載策略。
10萬條數(shù)據(jù)插入比系統(tǒng)SQLiteDatabase操作快一倍，推薦我的LiteOrm數(shù)據(jù)庫框架 https://github.com/litesuits/android-lite-orm
9. 線程安全怎么保證，異步并發(fā)這塊你怎么做的
理解并使用ReentrantLock，Synchronized保護(hù)對象或過程，final來保護(hù)不可變對象，無狀態(tài)和只讀對象是安全的，合理使用一些 concurrent容器，比如concurrenthashmap等，重量級耗時任務(wù)考慮是否可以釋放鎖，多線程下實例化或延遲加載需要保護(hù)起來，保護(hù)多線程下關(guān)鍵數(shù)據(jù)訪問的原子性，等等還有很多的。。。
推薦研究下Doug Lea主寫和設(shè)計的java concurrent包，理解CountDownLatch、CyclicBarrier、Semaphore、FutureTask等對象。
我使用自己寫的SmartExecutor，直接繼承ExecutorService，封裝了一個公共線程池，全App保證只有一個線程池。源碼在這個開源項目里：https://github.com/litesuits/android-lite-http 。
在一個 App 中 SmartExecutor 可以有多個實例，每個實例都有獨(dú)立核心和等待線程數(shù)指標(biāo)，每個實例都有獨(dú)立的調(diào)度和滿載處理策略，但它們 **共享一個線程池**。這種機(jī)制既滿足不同木塊對線程控制和任務(wù)調(diào)度的獨(dú)立需求，又共享一個池資源。獨(dú)立又共享，最大程度上節(jié)省資源，提升性能。
控制核心并發(fā)數(shù)，盡量和CPU核數(shù)保持一致（或者多兩個）我認(rèn)為吞吐量是最佳的，線程過多則調(diào)度線程消耗CPU和時間，過少則不能充分利用多核的能力。
控制排隊策略和排隊數(shù)量，是否考慮新任務(wù)先處理，過度超載丟掉最老的任務(wù)。
還有就是業(yè)務(wù)上，合理調(diào)度任務(wù)，優(yōu)化業(yè)務(wù)邏輯，不要胡搞亂搞，不作惡。
最后我想推薦一下我的個人開源項目：litesuits.com，歡迎關(guān)注嘛
