一窄坦、Android Profiler
1、CPU profiler（優(yōu)化CPU性能）
Call chart
橙色表示系統(tǒng) API 的函數(shù)，綠色表示應用自有函數(shù)韵洋，藍色表示第三方 API（包括 Java 語言 API）的函數(shù)
水平表示調(diào)用時間，垂直表示調(diào)用者
Flame Chart(火焰圖)
相同調(diào)用堆棧聚合在一塊黄锤，耗時最多的放上面
Top Down自上而下（類似與火焰圖）
Bottom Up自下而上
2搪缨、Memory profiler
堆轉(zhuǎn)儲heap dump：記錄某一時間點的內(nèi)存使用情況
紅點按鈕：用于記錄一段時間內(nèi)內(nèi)存分配情況
使用方式：啟動app，使用一段時間觀察內(nèi)存使用情況鸵熟，進行heap dump查看有沒有異常（同一對象重復出現(xiàn)副编，對象占用內(nèi)存過大）場景如：切換橫豎屏，反復進行頁面跳轉(zhuǎn)
二流强、Leakcanary
只關注activity痹届，使用LeakCanary.install(this)；
關注fragment打月，在onDestroy加入RefWatcher队腐；
不能檢測Service的內(nèi)存泄露
三、性能優(yōu)化基礎知識
1奏篙、卡頓優(yōu)化
應用層繪制柴淘，系統(tǒng)層渲染，android系統(tǒng)需要在16ms內(nèi)完成繪制，就不會出現(xiàn)卡頓
RelativeLayout會測量兩次（不推薦）为严，LinerLayout測量一次
卡頓優(yōu)化工具：Profile GPU Rendering敛熬、Debug GPU overDraw過度繪制檢測
2、耗電優(yōu)化
Battery Historian耗電分析工具
3第股、app包大小優(yōu)化
資源優(yōu)化应民、代碼優(yōu)化、代碼混淆
4炸茧、內(nèi)存優(yōu)化
內(nèi)存泄露：持有Activity引用瑞妇，如單例中、Handler中梭冠、內(nèi)部類中辕狰，資源未關閉、使用webview
內(nèi)存優(yōu)化：引用類型（強弱軟虛）控漠、內(nèi)存復用（線程池蔓倍、對象池）、使用合適的數(shù)據(jù)結(jié)構(gòu)盐捷、圖片內(nèi)存優(yōu)化
四偶翅、圖片處理
Bitmap優(yōu)化：對圖片進行尺寸壓縮、質(zhì)量壓縮碉渡，使用二級緩存
圖片常用格式：VectorDrawable/WebP/PNG/JPG
LruCache原理：LinkedHashMap(hashmap+雙向鏈表)訪問最多的移動到表尾聚谁，訪問最少的從表頭移除
在雙向鏈表里進行重排序
三級緩存：內(nèi)存、磁盤滞诺、網(wǎng)絡形导，一般下拉刷新時獲取數(shù)據(jù)，或者定時獲取
AOP編程：如有多個登錄請求操作习霹，把這種操作封裝起來朵耕，在一處實現(xiàn)復雜邏輯編寫，其他位置只需簡單調(diào)用即可淋叶。AOP實現(xiàn)分靜態(tài)實現(xiàn)和動態(tài)實現(xiàn)（反射不推薦）阎曹，靜態(tài)實現(xiàn)常見方式APT（ButterKnife）、AspectJ
網(wǎng)絡編程：tcp/ip五層協(xié)議包括應用層（HTTP煞檩、HTTPS处嫌、SOAP）、傳輸層（TCP形娇、UDP）锰霜、網(wǎng)絡層（IP）、數(shù)據(jù)鏈路層（以太網(wǎng)桐早、WiFi）癣缅、物理層（光纜厨剪、電纜、雙絞線友存、無線電波）
TCP三次握手：
1祷膳、服務器先創(chuàng)建傳輸控制塊，先進入LISTEN監(jiān)聽狀態(tài)屡立，監(jiān)聽客戶端的請求直晨；
2、客戶端創(chuàng)建傳輸控制塊膨俐，然后向服務器發(fā)送請求報文勇皇，此時報文信息為Seq=x，此時進入SYN-SENT同步已發(fā)送狀態(tài)焚刺；（第一次握手）
3敛摘、服務器收到請求報文后，發(fā)出確認報文乳愉，報文信息為ACK=x+1兄淫，Seq=y,此時服務器進入SYN-RCVD同步收到狀態(tài)；（第二次握手）
4蔓姚、客戶端收到確認報文捕虽，向服務器發(fā)出確認報文，報文信息為ACK=y+1,Seq=x+1,此時客戶端進入ESTABLISHED已建立連接狀態(tài)坡脐；（第三次握手）
5泄私、服務端收到確認報文進入ESTABLISHED狀態(tài)，雙方建立連接成功备闲。
第三次握手原因：
第一次客戶端發(fā)送請求報文時挖滤，在傳輸時滯留時間過長，服務器沒有收到就沒有發(fā)出確認報文浅役。客戶端會又一次發(fā)送請求報文伶唯，此時服務器收到并確認觉既，與客戶端建立了連接。
此時第一次的報文到達了服務端乳幸，服務端確認并發(fā)送確認報文瞪讼，又會建立一次連接，造成資源浪費粹断。
而三次握手符欠，在第三次握手時，客戶端收到確認后瓶埋，就不會再發(fā)出錯誤的確認報文了希柿，也就不會繼續(xù)建立連接了诊沪。
TCP四次揮手：
1、客戶端發(fā)出釋放報文曾撤，停止發(fā)送數(shù)據(jù)端姚，釋放報文信息為FIN=1，Seq=x+2,ACK=y+1,此時客戶端進入FIN-WAIT-1終止等待1狀態(tài)挤悉；（第一次揮手）
2渐裸、服務端收到釋放報文，發(fā)出確認報文（包含數(shù)據(jù)）装悲，確認報文信息為ACK=x+3,服務端進入CLOSE-WAIT關閉等待狀態(tài)昏鹃；（第二次揮手）
3、客戶端收到確認報文后诀诊，此時客戶端進入FIN-WAIT-2終止等待2狀態(tài)洞渤，等待服務端發(fā)出釋放報文；
4畏梆、服務端將最后的數(shù)據(jù)發(fā)送完畢后您宪，向客戶端發(fā)送釋放報文，此時服務端進入LAST-ACK最后確認狀態(tài)奠涌，等待客戶端確認宪巨；（第三次揮手）
5、客戶端收到釋放報文后，發(fā)出再次確認報文笆怠，客戶端進入TIME-WAIT時間等待狀態(tài)逗栽，經(jīng)過2??MSL最長報文段壽命后，撤銷TCB傳輸控制塊怠晴，才進入close狀態(tài)；（第四次揮手）
6浴捆、服務端收到確認報文蒜田，立即進入close狀態(tài)，撤銷TCB傳輸控制塊选泻，結(jié)束連接
為什么會有2?MSL時間段冲粤？
（1）服務端在這時已經(jīng)發(fā)送完釋放和確認報文了，客戶端在第四次揮手時發(fā)送再次確認報文页眯，此報文有可能丟失梯捕，服務端沒有收到再次確認，服務端覺得沒有收到反饋窝撵，又發(fā)了一遍釋放和確認報文傀顾，客戶端就可以在2?MSL時間段內(nèi)收到服務端的第二次報文，然后發(fā)送再次確認報文碌奉，并重啟2*MSL計時器短曾。
（2）防止類似出現(xiàn)第三次握手的同樣情況寒砖，客戶端在第四次揮手時發(fā)送再次確認報文，在傳輸時滯留错英。
為什么是四次揮手呢入撒？
服務端數(shù)據(jù)和釋放報文可以分開發(fā)送，就多了一次揮手椭岩。
未完待續(xù)（glide茅逮、android啟動流程、android啟動模式判哥、handler献雅、集合框架）
（RecycleView、fragment塌计、屏幕適配挺身、內(nèi)容提供者、廣播）
（retrofit）
