性能優(yōu)化是一個大的范疇，如果有人問你在Android中如何做性能優(yōu)化的深寥，也許都不知道從哪開始說起。
首先要明白的是贤牛，為什么我們的App需要優(yōu)化惋鹅，最顯而易見的時刻：用戶say，什么狗屎殉簸，刷這么久都沒反應闰集，取關卸載算了沽讹。
這跟什么有關，我們先蒼白的反駁下武鲁，尼瑪用戶設備老舊網(wǎng)又爛爽雄，關我屁事，根本不用優(yōu)化沐鼠≈课粒可是，老板拍板了饲梭，施壓給CTO乘盖，然后CTO又來找你：Y的今天必須給我想辦法優(yōu)化了，不然不準回家憔涉。
好吧订框，為什么從UI的表象上看，App又卡又慢而且還錯亂兜叨。我們試著來剖析下吧穿扳。
題外話：把minSDK改到4.0＋，去特么的low用戶浪腐，連手機都不愿意換纵揍，還能指望它能給你帶來多少營收么，直接pass掉吧议街。4.0前的系統(tǒng)bug不少泽谨，不能為了彌補這些bug而降低了整體的高性能。
好了特漩，讓我們先從UI說起：
首先要明白的是UI的繪制流程：measure-layout-draw吧雹，measure與layout都需要for loop所有的子控件，匯集起來才能完成繪制涂身，布局雄卷。所以子控件越多，所消耗的時間越長(inflate蛤售，layout_weight丁鹉，relative，多層嵌套等)悴能，減少不必要的子控件或層級揣钦，是相當有必要的。你可以通過merge,viewstub這些標簽來減少層級嵌套漠酿。如果你的空間觀念沒那么好冯凹，可以用HierarchyViewer工具來檢查。
對于Listview或者GridView這種多item的組件來說炒嘲，復用item可以減少inflate次數(shù)宇姚，通過setTag匈庭，getTag的ViewHolder方式實現(xiàn)復用，這里要注意的是浑劳，holder中的控件最好reset后再賦值阱持，避免圖片，文字錯亂呀洲。
對于ViewPager第一次顯示時卡頓以及左右滑動卡頓紊选，有以下幾種優(yōu)化方式：
- ViewPager同時緩存page數(shù)最好為最小值3，如果過多道逗，那么第一次顯示時，ViewPager所初始化的pager就會很多献烦，這樣pager累積渲染耗時就會增多滓窍，看起來就卡。
- 每個pager應該只在顯示時才加載網(wǎng)絡或數(shù)據(jù)庫(UserVisibleHint=true)巩那，最好不要預加載數(shù)據(jù)吏夯，以免造成浪費
圖片顯示不出來或者加載時間太長，怎么辦即横？分兩部分噪生，下載速度，加載速度东囚。
- 對于下載跺嗽，要控制好同時下載的最大任務數(shù)(平均速度慢)，同時給InputStream再包一層緩沖流會更快(如BufferedInputStream)页藻。
- 對于加載速度桨嫁，我們要知道一點闯传，雖然下載的圖片可能只有幾百K灌危，但是decode成bitmap所占用的內存可是成倍的，盡可能的減小圖片size是根本因素俯树，讓服務端提供不同分辨率的圖片才是最好的解決方案废境，內存總有耗盡的時刻畜挨，別老想著大分辨率會更清晰，實際就只有150150的空間噩凹，非給弄張10001000的圖片是不恰當?shù)陌驮Ａ硗庹摷虞d速度：內存>硬盤>網(wǎng)絡，合理的使用內存緩存也是關鍵栓始。假如自己寫不好务冕，沒關系，有那么多開源的圖片緩存框架幻赚，不用自己操心禀忆。
再說緩存
有很多種緩存方式臊旭，也不用Stay列舉了，我們要說的是搭配使用箩退。
- 比方說离熏，以前我們一直在用強引用，HashMap戴涝，后來我們發(fā)現(xiàn)占內存滋戳，我們就用軟引用，弱引用來及時回收啥刻，再后來因為回收機制不可控奸鸯，所以又有了lrucache，disklrucache通過算法來平衡內存與硬盤緩存可帽。隨著android版本的推進與演化娄涩，我們也應該擁抱變化。如果你的App里還有軟引用映跟，弱引用的地方蓄拣，不妨再check下。
- 比方說網(wǎng)絡＋數(shù)據(jù)庫努隙。網(wǎng)絡我們一般都是去主動獲取球恤，而非被動接受。那如果說數(shù)據(jù)是重復的或者未更改的呢荸镊？那我們去取一次網(wǎng)絡數(shù)據(jù)有什么意義呢咽斧？我的解決方案是給每個activity或fragment或每個組件設置一個最大請求間隔，比如一個listview贷洲，第一次請求數(shù)據(jù)時收厨，保存一份到數(shù)據(jù)庫，并記下時間戳优构，當下次重新初始化時诵叁，判斷是否超過最大時間間隔(如5分鐘)，如果沒有钦椭，只加載數(shù)據(jù)庫數(shù)據(jù)拧额，不需要再做網(wǎng)絡請求。當然彪腔，還有一些隱式的http請求框架會緩存服務器數(shù)據(jù)侥锦，在一定時間內不再請求網(wǎng)絡，或者當服務器返回304時將之前緩存的數(shù)據(jù)直接返回德挣。
反正也說到網(wǎng)絡了恭垦，那我們也來說說
- 現(xiàn)在有很多現(xiàn)成HTTP框架供我們使用，我們幾乎只用寫配置就可以搞定一個url請求，但是這里有很多需要服務端配合的番挺，比如：json數(shù)據(jù)格式唠帝，WebP代替jpg，支持斷點續(xù)傳玄柏，多個請求合并成一個襟衰，盡量不做重定向，服務器緩存以及負載均衡等粪摘。
- 對客戶端本身瀑晒，除了上述的實現(xiàn)，我們還需要合理的緩存徘意，控制最大請求并發(fā)量苔悦，及時取消已失效的請求，過濾重復請求映砖，timeout時間設置间坐，請求優(yōu)先級設置等。
優(yōu)化可不是一個人的事邑退，實現(xiàn)一個功能簡單，但是想優(yōu)化重構劳澄，那是很不容易的事地技。需要多方面的預判與聯(lián)調。合理的假設與實踐是優(yōu)化最重要的手段秒拔。
說完這些具體的點莫矗，我們再來說說一些常識，或者稱之為代碼規(guī)范砂缩。
- 你要知道for loop中不要聲明臨時變量作谚，不到萬不得已不要在里面寫try catch。
- 明白垃圾回收機制庵芭，避免頻繁GC妹懒，內存泄漏，OOM(有機會專門說)
- 合理使用數(shù)據(jù)類型双吆，比如StringBuilder代替String眨唬，(筆試題最常見的是str+="str"中有幾個對象) ，少用枚舉enum好乐，少用父類聲明(List,Map)
- 如果你有頻繁的new線程匾竿，那最好通過線程池去execute它們，減少線程創(chuàng)建開銷蔚万。
- 你要知道單例的好處岭妖，并正確的使用它。
- 多用常量，少用顯式的"action_key"昵慌，并維護一個常量類假夺，別重復聲明這些常量。
- 如果可以废离，至少要弄懂設計模式中的策略模式侄泽，組合模式，裝飾模式蜻韭，工廠模式悼尾，觀察者模式，這些能幫助你合理的解耦肖方，即使需求頻繁變更闺魏，你也不用害怕牽一發(fā)而動全身。需求變更不可怕俯画，可怕的是沒有在寫代碼之前做合理的設計析桥。
當然還有很多很多，Stay所說的也只是一個大的輪廓艰垂，還是需要自己不斷的嘗試泡仗。會開發(fā)寫代碼跟會做產(chǎn)品的區(qū)別還是蠻大的，僅僅是態(tài)度就能刷死80%的碼農了猜憎。當你碰到一些需要優(yōu)化的地方娩怎，耐心的去分析，時間的累積會讓你成為真正的工程師胰柑。
另外優(yōu)化也沒有絕對的完美截亦，每一次優(yōu)化都是基于當前的業(yè)務來做的，要明白溝通是最好的優(yōu)化柬讨，不盲從崩瓤，不隨便，三思而后行踩官。
