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í)邻寿。
其實(shí)不一定面試時才了解這些，并且了解絕對不是重點(diǎn)视哑，而是實(shí)踐绣否，絕知此事要躬行是真理，這樣的問題也似乎沒有“最佳答案”挡毅，但是可以發(fā)表一下自己觀點(diǎn)和實(shí)踐結(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）來實(shí)現(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毫秒（其實(shí)這挺難的）锦针，16毫秒大法好，具體可以去理解下CPU置蜀、GPU奈搜、屏幕三者如何配合完成渲染的，推薦老羅的博客盯荤。
2. 談?wù)劶軜?gòu)馋吗。大項目，邏輯多怎么辦秋秤，如何應(yīng)對多App和多終端
適當(dāng)參考我在知乎的一個回答 怎樣搭高質(zhì)量的Android項目框架耗美，框架的結(jié)構(gòu)具體描述？ 航缀，結(jié)合模塊化商架、組件化思想去做，多實(shí)踐一下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等腳本實(shí)現(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诡必，完成“移花接木”奢方。
另外，其實(shí)有挺多的策略改變運(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ù)考慮是否可以釋放鎖烈涮，多線程下實(shí)例化或延遲加載需要保護(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 可以有多個實(shí)例历帚，每個實(shí)例都有獨(dú)立核心和等待線程數(shù)指標(biāo)，每個實(shí)例都有獨(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)注嘛
