1. 整體性能如何探測，有哪些方面，什么指標，怎么保證更流暢
2. 談談架構。大項目，邏輯多怎么辦，如何應對多App和多終端
3. android的發展大事件和主要技術發展
4. avtivity(service)啟動流程簡述
5. 動態化的幾種方案
6. 熱修復的原理
7. 網絡這塊怎么優化
8. 數據庫性能怎么保證
9. 線程安全怎么保證，異步并發這塊你怎么做的

這幾個問題是我根據自己的面試經歷總結的，大家一起交流學習。

其實不一定面試時才了解這些，并且了解絕對不是重點，而是實踐，絕知此事要躬行是真理，這樣的問題也似乎沒有“最佳答案”，但是可以發表一下自己觀點和實踐結論。

有些做法或觀點一下子想不起來，需要具體做的時候再google一下，或者跟朋友溝通拓展一下，所以先做個簡單的回答，請大家補充。

[[274821]]

1. App性能如何探測，有哪些方面，什么指標，怎么保證更流暢?

性能可以根據幀率、內存、CPU、GPU等指標的數據和表現輔助判斷，可以從/proc文件夾下讀取文件獲取cpu、內存等信息，也可以用dumpsys命令獲取幀率等信息，也可以通過android API獲取相關信息。

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

保證流暢有很多點可以去研究，比如布局、代碼、緩存、網絡、數據庫、異步并發等方面的優化，涉及很多的知識點，可以google下，先簡單說下，有時間再細述。

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

代碼上盡量使用final、局部變量、系統函數如arraycopy等、位移操作是否可以代替乘除、for循環是否可以避免size計算和new對象等等。

緩存方面，線程、位圖、視圖、網絡數據是否可以被緩存，IO用緩沖流。

網絡方面，如盡量避免輪詢，控制節奏和頻率，IP直連，采用SPDY方案(或HTTP2.0)來實現壓縮header、多路復用、雙向通信等，API數據壓縮，多個請求是否可以合并，數據壓縮和嘗試protocol buffer相關序列化方案。

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

異步并發方面，全App只有一個線程池，控制核心并發數量，控制超載時排隊數量和策略，合理調度任務，優化業務邏輯。

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

2. 談談架構。大項目，邏輯多怎么辦，如何應對多App和多終端

適當參考我的回答 怎樣搭高質量的Android項目框架，框架的結構具體描述? ，結合模塊化、組件化思想去做，多實踐一下mvp、mvvm等策略。

3. android的發展大事件和主要技術發展

額，挺多的，朋友們補充吧。

這個問題蠻好的 Android 開發有哪些新技術出現?

4. avtivity(service)啟動流程簡述

可以自己閱讀源代碼，結合羅老師的博客，研究的非常棒：Android應用程序啟動過程源代碼分析

5. 動態化的幾種方案

早期的H5方案，通過js和java互通增強h5的能力。

還有DexClasssLoader結合反射代理的方案。

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

還有Lua等腳本實現動態化方案。

6. 熱修復的原理

Github上讀一下AndFix這個項目的源碼，還有xposed、dexposed。

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

另外，其實有挺多的策略改變運行時行為的，比如：

• Javasisst：字節碼修改類庫，依賴字節碼修改和DX類庫，可以完成動態替換和切面編程。
• AspectJ：依賴字節碼編織器，需要按照其語法來編寫，需要一點“編織”時間。
• Xposed：簡直是一個Bug，神器般的存在，沒準以后會被Android系統修復呢，不僅可以改變自己的類行為還可以hook系統的方法，root過的機器還可以hook其他App和系統進程。

7. 網絡這塊怎么優化

盡量避免輪詢，控制節奏和頻率。

IP直連節省DNS解析時間。

嘗試其他數據序列化方案比如protocol buffer等。

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

服務器做優化，比如分布式、緩存之類的，減少API涉及的業務操作所需要的時間嘛。

API接口數據精簡，多個請求是否可以合并，增量請求啊、GIP壓縮啊什么的，等等。

8. 數據庫性能怎么保證

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

索引和事務的充分理解和使用，批量操作使用事務極大提升速度，這個我是做過試驗的，效果驚人。

SQL語句拼接和本身的優化，僅查詢部分局部數據，使用延遲加載策略。

10萬條數據插入比系統SQLiteDatabase操作快一倍，推薦我的LiteOrm數據庫框架 https://github.com/litesuits/android-lite-orm

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

理解并使用ReentrantLock，Synchronized保護對象或過程，final來保護不可變對象，無狀態和只讀對象是安全的，合理使用一些 concurrent容器，比如concurrenthashmap等，重量級耗時任務考慮是否可以釋放鎖，多線程下實例化或延遲加載需要保護起來，保護多線程下關鍵數據訪問的原子性，等等還有很多的。。。

推薦研究下Doug Lea主寫和設計的java concurrent包，理解CountDownLatch、CyclicBarrier、Semaphore、FutureTask等對象。

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

在一個 App 中 SmartExecutor 可以有多個實例，每個實例都有獨立核心和等待線程數指標，每個實例都有獨立的調度和滿載處理策略，但它們 **共享一個線程池**。這種機制既滿足不同木塊對線程控制和任務調度的獨立需求，又共享一個池資源。獨立又共享，最大程度上節省資源，提升性能。

控制核心并發數，盡量和CPU核數保持一致(或者多兩個)我認為吞吐量是最佳的，線程過多則調度線程消耗CPU和時間，過少則不能充分利用多核的能力。

控制排隊策略和排隊數量，是否考慮新任務先處理，過度超載丟掉最老的任務。

還有就是業務上，合理調度任務，優化業務邏輯，不要胡搞亂搞，不作惡。