淺議那些Android中的性能優(yōu)化
性能優(yōu)化是一個(gè)大的范疇，如果有人問(wèn)你在Android中如何做性能優(yōu)化的，也許都不知道從哪開始說(shuō)起。首先要明白的是，為什么我們的App需要優(yōu)化，最顯而易見的時(shí)刻：用戶say，什么狗屎，刷這么久都沒(méi)反應(yīng)，取關(guān)卸載算了。
這跟什么有關(guān)，我們先蒼白的反駁下，尼瑪用戶設(shè)備老舊網(wǎng)又爛，關(guān)我屁事，根本不用優(yōu)化。可是，老板拍板了，施壓給CTO，然后CTO又來(lái)找你：Y的今天必須給我想辦法優(yōu)化了，不然不準(zhǔn)回家。
好吧，為什么從UI的表象上看，App又卡又慢而且還錯(cuò)亂。我們?cè)囍鴣?lái)剖析下吧。
題外話：把minSDK改到4.0+，去特么的low用戶，連手機(jī)都不愿意換，還能指望它能給你帶來(lái)多少營(yíng)收么，直接pass掉吧。4.0前的系統(tǒng)bug不少，不能為了彌補(bǔ)這些bug而降低了整體的高性能。
好了，讓我們先從UI說(shuō)起：
首先要明白的是UI的繪制流程：measure-layout-draw，measure與layout都需要for loop所有的子控件，匯集起來(lái)才能完成繪制，布局。所以子控件越多，所消耗的時(shí)間越長(zhǎng)(inflate，layout_weight，relative，多層嵌套等)，減少不必要的子控件或?qū)蛹?jí)，是相當(dāng)有必要的。你可以通過(guò)merge,viewstub這些標(biāo)簽來(lái)減少層級(jí)嵌套。如果你的空間觀念沒(méi)那么好，可以用HierarchyViewer工具來(lái)檢查。
對(duì)于Listview或者GridView這種多item的組件來(lái)說(shuō)，復(fù)用item可以減少inflate次數(shù)，通過(guò)setTag，getTag的ViewHolder方式實(shí)現(xiàn)復(fù)用，這里要注意的是，holder中的控件最好reset后再賦值，避免圖片，文字錯(cuò)亂。
對(duì)于ViewPager第一次顯示時(shí)卡頓以及左右滑動(dòng)卡頓，有以下幾種優(yōu)化方式：
- ViewPager同時(shí)緩存page數(shù)最好為最小值3，如果過(guò)多，那么第一次顯示時(shí)，ViewPager所初始化的pager就會(huì)很多，這樣pager累積渲染耗時(shí)就會(huì)增多，看起來(lái)就卡。
- 每個(gè)pager應(yīng)該只在顯示時(shí)才加載網(wǎng)絡(luò)或數(shù)據(jù)庫(kù)(UserVisibleHint=true)，最好不要預(yù)加載數(shù)據(jù)，以免造成浪費(fèi)
圖片顯示不出來(lái)或者加載時(shí)間太長(zhǎng)，怎么辦?分兩部分，下載速度，加載速度。
對(duì)于下載，要控制好同時(shí)下載的最大任務(wù)數(shù)(平均速度慢)，同時(shí)給InputStream再包一層緩沖流會(huì)更快(如BufferedInputStream)。
對(duì)于加載速度，我們要知道一點(diǎn)，雖然下載的圖片可能只有幾百K，但是decode 成bitmap所占用的內(nèi)存可是成倍的，盡可能的減小圖片size是根本因素，讓服務(wù)端提供不同分辨率的圖片才是最好的解決方案，內(nèi)存總有耗盡的時(shí)刻，別老想著大分辨率會(huì)更清晰，實(shí)際就只有150*150的空間，非給弄張1000*1000的圖片是不恰當(dāng)?shù)?。另外論加載速度：內(nèi)存>硬盤>網(wǎng)絡(luò)，合理的使用內(nèi)存緩存也是關(guān)鍵。假如自己寫不好，沒(méi)關(guān)系，有那么多開源的圖片緩存框架，不用自己操心。
再說(shuō)緩存
有很多種緩存方式，也不用Stay列舉了，我們要說(shuō)的是搭配使用。
比方說(shuō)，以前我們一直在用強(qiáng)引用，HashMap，后來(lái)我們發(fā)現(xiàn)占內(nèi)存，我們就用軟引用，弱引用來(lái)及時(shí)回收，再后來(lái)因?yàn)榛厥諜C(jī)制不可控，所以又有了 lrucache，disklrucache通過(guò)算法來(lái)平衡內(nèi)存與硬盤緩存。隨著android版本的推進(jìn)與演化，我們也應(yīng)該擁抱變化。如果你的App里還有軟引用，弱引用的地方，不妨再check下。
比方說(shuō)網(wǎng)絡(luò)+數(shù)據(jù)庫(kù)。網(wǎng)絡(luò)我們一般都是去主動(dòng)獲取，而非被動(dòng)接受。那如果說(shuō)數(shù)據(jù)是重復(fù)的或者未更改的呢?那我們?nèi)ト∫淮尉W(wǎng)絡(luò)數(shù)據(jù)有什么意義呢?我的解決方案是給每個(gè)activity或 fragment或每個(gè)組件設(shè)置一個(gè)最大請(qǐng)求間隔，比如一個(gè)listview，第一次請(qǐng)求數(shù)據(jù)時(shí)，保存一份到數(shù)據(jù)庫(kù)，并記下時(shí)間戳，當(dāng)下次重新初始化時(shí)，判斷是否超過(guò)最大時(shí)間間隔(如5分鐘)，如果沒(méi)有，只加載數(shù)據(jù)庫(kù)數(shù)據(jù)，不需要再做網(wǎng)絡(luò)請(qǐng)求。當(dāng)然，還有一些隱式的http請(qǐng)求框架會(huì)緩存服務(wù)器數(shù)據(jù)，在一定時(shí)間內(nèi)不再請(qǐng)求網(wǎng)絡(luò)，或者當(dāng)服務(wù)器返回304時(shí)將之前緩存的數(shù)據(jù)直接返回。
反正也說(shuō)到網(wǎng)絡(luò)了，那我們也來(lái)說(shuō)說(shuō)
現(xiàn)在有很多現(xiàn)成HTTP框架供我們使用，我們幾乎只用寫配置就可以搞定一個(gè)url請(qǐng)求，但是這里有很多需要服務(wù)端配合的，比如：json數(shù)據(jù)格式，WebP代替jpg，支持?jǐn)帱c(diǎn)續(xù)傳，多個(gè)請(qǐng)求合并成一個(gè)，盡量不做重定向，服務(wù)器緩存以及負(fù)載均衡等。
對(duì)客戶端本身，除了上述的實(shí)現(xiàn)，我們還需要合理的緩存，控制最大請(qǐng)求并發(fā)量，及時(shí)取消已失效的請(qǐng)求，過(guò)濾重復(fù)請(qǐng)求，timeout時(shí)間設(shè)置，請(qǐng)求優(yōu)先級(jí)設(shè)置等。
優(yōu)化可不是一個(gè)人的事，實(shí)現(xiàn)一個(gè)功能簡(jiǎn)單，但是想優(yōu)化重構(gòu)，那是很不容易的事。需要多方面的預(yù)判與聯(lián)調(diào)。合理的假設(shè)與實(shí)踐是優(yōu)化最重要的手段。
說(shuō)完這些具體的點(diǎn)，我們?cè)賮?lái)說(shuō)說(shuō)一些常識(shí)，或者稱之為代碼規(guī)范。
- 你要知道for loop中不要聲明臨時(shí)變量，不到萬(wàn)不得已不要在里面寫try catch。
- 明白垃圾回收機(jī)制，避免頻繁GC，內(nèi)存泄漏，OOM(有機(jī)會(huì)專門說(shuō))
- 合理使用數(shù)據(jù)類型，比如StringBuilder代替String，(筆試題最常見的是str+="str"中有幾個(gè)對(duì)象) ，少用枚舉enum，少用父類聲明(List,Map)
- 如果你有頻繁的new線程，那最好通過(guò)線程池去execute它們，減少線程創(chuàng)建開銷。
- 你要知道單例的好處，并正確的使用它。
- 多用常量，少用顯式的"action_key"，并維護(hù)一個(gè)常量類，別重復(fù)聲明這些常量。
- 如果可以，至少要弄懂設(shè)計(jì)模式中的策略模式，組合模式，裝飾模式，工廠模式，觀察者模式，這些能幫助你合理的解耦，即使需求頻繁變更，你也不用害怕牽一發(fā)而動(dòng)全身。需求變更不可怕，可怕的是沒(méi)有在寫代碼之前做合理的設(shè)計(jì)。
當(dāng)然還有很多很多，Stay所說(shuō)的也只是一個(gè)大的輪廓，還是需要自己不斷的嘗試。會(huì)開發(fā)寫代碼跟會(huì)做產(chǎn)品的區(qū)別還是蠻大的，僅僅是態(tài)度就能刷死80%的碼農(nóng)了。當(dāng)你碰到一些需要優(yōu)化的地方，耐心的去分析，時(shí)間的累積會(huì)讓你成為真正的工程師。
另外優(yōu)化也沒(méi)有絕對(duì)的完美，每一次優(yōu)化都是基于當(dāng)前的環(huán)境來(lái)做的，要明白溝通是最好的優(yōu)化，不盲從，不隨便，三思而后行。
Android上如何做性能優(yōu)化的?大概寫三年代碼就能差不多知道了。
