一 首先，我們先了解一下都有哪些性能問題
1够坐、內(nèi)存泄露。
通俗來講崖面，內(nèi)存泄露不僅僅會(huì)造成應(yīng)用內(nèi)存占用過大元咙，還會(huì)導(dǎo)致應(yīng)用卡頓，造成不好的用戶體驗(yàn)巫员，至于庶香，為什么一個(gè)“小小的”內(nèi)存泄露會(huì)造成應(yīng)用卡頓，我不得不拿這幅圖來說說話了简识。
沒錯(cuò)感猛，這就是Android開發(fā)童鞋需要了解的Generational Heap Memory模型，這里我們只關(guān)心當(dāng)對(duì)象在Young Generation中存活了一段時(shí)間之后奢赂，如果沒被干掉陪白，那么會(huì)被移動(dòng)到Old Generation中，同理膳灶，最后會(huì)移動(dòng)到Permanent Generation中拷泽。那么用腳想一想就知道，如果內(nèi)存泄露了袖瞻，那么司致，抱歉，你那塊內(nèi)存隨時(shí)間推移自然而然將進(jìn)入Permanent Generation中聋迎，然鵝脂矫，內(nèi)存不是白菜，想要多少就有多少霉晕，這里庭再，因?yàn)樯澈袡C(jī)制的原因，分配給你應(yīng)用的內(nèi)存當(dāng)然是有那么一個(gè)極限值的牺堰，你不能逾越（有人笑了拄轻，不是有l(wèi)arge heap么，當(dāng)然我也笑了伟葫，我并沒有看到這貨被宗師android玩家青睞過）恨搓，好了，你那塊造成泄露內(nèi)存的對(duì)象占著茅坑不拉屎筏养，剩下來可以供其他對(duì)象發(fā)揮的內(nèi)存空間就少了斧抱；打個(gè)比方，舞臺(tái)小了渐溶，演員要登臺(tái)表演辉浦，沒有多余空間，他就只能等待其他演員下來他才能表演啊茎辐，這等待的時(shí)間宪郊，是沒法連續(xù)表演的，所以就卡了嘛拖陆。
2弛槐、頻繁GC
呵呵，頻繁GC會(huì)造成卡頓慕蔚，想必你經(jīng)過上面的洗禮丐黄，已經(jīng)知道了為什么，不錯(cuò)孔飒，當(dāng)然也是因?yàn)椤拔枧_(tái)空間不足灌闺，新的演員上臺(tái)表演需要先讓表演完的下來”艰争。那么造成這種現(xiàn)象的原因是什么呢？
a桂对、內(nèi)存泄露甩卓，好的，你懂了蕉斜，不用講了逾柿，這個(gè)必須有可能會(huì)造成。
b宅此、大量對(duì)象短時(shí)間被創(chuàng)建机错，又在短時(shí)間內(nèi)“需要”被釋放，注意這里的需要父腕，其實(shí)是不得不弱匪，為什么，同樣是因?yàn)椤拔枧_(tái)空間不夠了”璧亮，舉個(gè)例子萧诫，在onDraw中new 對(duì)象，因?yàn)閛nDraw大約16ms會(huì)執(zhí)行一次（wait枝嘶，你能否確定一下帘饶，什么是大約16ms，對(duì)不起群扶，不能及刻，掉幀了就不是，哪怕掉那么一點(diǎn)點(diǎn)）穷当。腦補(bǔ)一下提茁，每秒中創(chuàng)建大約60個(gè)對(duì)象，嗯馁菜，騷年，你以為Young Generation是白菜么铃岔，想拿多少就拿多少汪疮，對(duì)不起，這里是限量的毁习，這里用完了智嚷，在來申請(qǐng)，我就得去回收一些回來纺且，我回收總得耗時(shí)間吧盏道，耗時(shí)間，好吧载碌，onDraw 等著等著就錯(cuò)過了下一個(gè)16ms的執(zhí)行了猜嘱，如是衅枫，用戶看起來就卡了。
3朗伶、耗電問題
km上有一個(gè)問題很尖銳弦撩，說是微視看小視頻看一會(huì)手機(jī)就會(huì)發(fā)燙，所以论皆，用戶一直就很關(guān)注耗電問題益楼，不過不好意思，我們的app至今還沒有遇到過嚴(yán)重的耗電問題点晴，雖然沒有遇到比較嚴(yán)重的耗電問題感凤，不代表就不需要去了解這樣的問題的解決辦法，我總結(jié)有：
a粒督、沒有什么特別重要的信息俊扭，比如，錢到賬坠陈，電話來了萨惑，100元實(shí)打?qū)崯o門檻代金券方法，等等仇矾，請(qǐng)不要打擾用戶庸蔼，不要頻繁喚醒用戶，否則贮匕，結(jié)果只能是卸載姐仅，或者關(guān)閉一切通知。
b刻盐、適當(dāng)?shù)淖霰镜鼐彺嫣透啵苊忸l繁請(qǐng)求網(wǎng)絡(luò)數(shù)據(jù)，這里敦锌，說起來容易馒疹，做起來并非三刀兩斧就能搞定，要配合良好的緩存策略乙墙，區(qū)分哪些是一段時(shí)間不會(huì)變更的颖变，哪些是絕對(duì)不能緩存的很重要。
c听想、對(duì)某些執(zhí)行時(shí)間較長(zhǎng)的同步操作在用戶充電且有wifi的時(shí)候在做腥刹，除非用戶強(qiáng)制同步..等等，就不扯太多汉买，因?yàn)楹竺孢€有很多內(nèi)容衔峰。
4、OOM問題
呵呵，這個(gè)問題垫卤，想必經(jīng)過前面1威彰、2的洗禮，你應(yīng)該已經(jīng)明白這個(gè)什么原因?qū)е碌暮校憧梢韵胂胍幌?舞臺(tái)上將要上的一個(gè)演員是一個(gè)巨大胖子抱冷，即便不表演的演員都下來了，他還是擠不上去梢褐，怎么辦旺遮，演砸了，還能怎么辦盈咳，直接崩潰耿眉，散場(chǎng)！"造成這個(gè)問題的原因鱼响，可能有鸣剪，（呵呵，保險(xiǎn)起見丈积，只能說可能筐骇，分析的時(shí)候可以從這里出發(fā)）
a、內(nèi)存泄露了江滨，想必你會(huì)心一笑铛纬。
b聚假、大量不可見的對(duì)象占據(jù)內(nèi)存缭乘，這個(gè)其實(shí)，很常見簇秒，只是大家可能一直不太關(guān)心罷了晶密，比如擒悬，請(qǐng)求接口返回了列表有100項(xiàng)數(shù)據(jù)，每項(xiàng)數(shù)據(jù)比如有100個(gè)字段稻艰，其中你用戶展示數(shù)據(jù)的只有10幾個(gè)而已懂牧，但是，你解析的時(shí)候连锯，剩下的99個(gè)不知不覺吃了你的內(nèi)存归苍，當(dāng)，有個(gè)胖子要內(nèi)存時(shí)运怖，呵呵，嗝屁了夏伊。
c摇展、還有一種很常見的場(chǎng)景是一個(gè)頁面多圖的場(chǎng)景，明明每個(gè)圖只需要加載一個(gè)100100的溺忧，你卻使用原始尺寸（10801980）or更大咏连，而且你一下子還加載個(gè)幾十張盯孙，扛得住么？所以了解一下inSampleSize祟滴，或者振惰，如果圖片歸你們上傳管理，你可以借助萬象優(yōu)圖垄懂，他為你做了剪切好不同尺寸的圖片骑晶，這樣省得你在客戶端做圖片縮放了。
二 以上了解了一些性能問題草慧，這里桶蛔，簡(jiǎn)單的串一串導(dǎo)致這些性能問題的原因
1漫谷、人為在ui線程中做了輕微的耗時(shí)操作仔雷，導(dǎo)致ui線程卡頓
嗯，很多小伙伴不以為然舔示，以為在onCreate中讀一下pref算什么碟婆，解析下json數(shù)據(jù)算得了什么，可實(shí)際情況是并不是這樣的惕稻，正確的做法是竖共，將這些操作使用異步封裝起來，小伙伴可以了解一下rxjava缩宜，現(xiàn)在最新版本已經(jīng)是rxjava2了肘迎，如果不清楚使用方式，可以Google一下锻煌。
2妓布、layout過于復(fù)雜，無法在16ms完成渲染
這個(gè)很多小伙伴深有體會(huì)了宋梧，這里簡(jiǎn)單的了解下匣沼，我們先簡(jiǎn)單的把渲染大概分為"layout","measure""draw"這么幾個(gè)階段，當(dāng)然你不要以為實(shí)際情況也是如此捂龄，好释涛，層級(jí)復(fù)雜，layout,measure可能就用到了不該用的時(shí)間倦沧，自然而然唇撬，留給draw的時(shí)間就可能不夠了，自然而然就悲劇了展融。那么以前給出的很多建議是窖认，使用RelativeLayout替換LinearLayout,說是可以減少布局層次，然鵝，現(xiàn)在請(qǐng)不要在建議別人使用RelativeLayout扑浸，因?yàn)镃onstraintLayout才是一個(gè)更高性能的消滅布局層級(jí)的神器烧给。ConstraintLayout 基于Cassowary算法，而Cassowary算法的優(yōu)勢(shì)是在于解決線性方程時(shí)有極高的效率喝噪，事實(shí)證明础嫡，線性方程組是非常適合用于定義用戶界面元素的參數(shù)。由于人們對(duì)圖形的敏感度非常高酝惧，所以UI的渲染速度顯得非常重要榴鼎。因此在2016年，iOS和Android都基于Cassowary算法來研發(fā)了屬于自己的布局系統(tǒng)系奉，這里是ConstraintLayout與傳統(tǒng)布局RelativeLayout檬贰，LinearLayout實(shí)現(xiàn)時(shí)的性能對(duì)比，不過這里是老外的測(cè)試數(shù)據(jù)缺亮，原文可以參考這里翁涤。demo中也提供了測(cè)試的方法，感興趣的小伙伴可以嘗試一下咯萌踱。
測(cè)量/布局（單位：毫秒，100 幀的平均值）
3并鸵、同一時(shí)間執(zhí)行的動(dòng)畫過多鸳粉，導(dǎo)致CPU或者GPU負(fù)載過重
這里主要是因?yàn)閯?dòng)畫一般會(huì)頻繁變更view的屬性，導(dǎo)致displayList失效园担，而需要重新創(chuàng)建一個(gè)新的displayList届谈，如果動(dòng)畫過多，這個(gè)開銷可想而知弯汰，如果你想了解得更加詳細(xì)艰山，推薦看這篇咯，知識(shí)點(diǎn)在第5節(jié)那里咏闪。
4曙搬、view過度繪制的問題。
view過度繪制的問題可以說是我們?cè)趯懖季值臅r(shí)候遇到的一個(gè)最常見的問題之一鸽嫂，可以說寫著寫著一不留神就寫出了一個(gè)過度繪制纵装，通常發(fā)生在一個(gè)嵌套的viewgroup中，比如你給他設(shè)置了一個(gè)不必要的背景据某。這方面問題的排查不太難橡娄，我們可以通過手機(jī)設(shè)置里面的開發(fā)者選項(xiàng)，打開Show GPU Overdraw的選項(xiàng)癣籽，輕松發(fā)現(xiàn)這些問題瀑踢，然后盡量往藍(lán)色靠近扳还。
5橱夭、gc過多的問題，這里就不在贅述了桑逝，上面已經(jīng)講的非常直接了棘劣。
6、資源加載導(dǎo)致執(zhí)行緩慢楞遏。
有些時(shí)候避免不要加載一些資源茬暇，這里有兩種解決的辦法，使用的場(chǎng)景也不相同寡喝。
a糙俗、預(yù)加載，即還沒有來到路徑之前预鬓，就提前加載好巧骚，誒，好像x5內(nèi)核就是醬紫哦格二。
b劈彪、實(shí)在是要等到用到的時(shí)候加載，請(qǐng)給一個(gè)進(jìn)度條顶猜，不要讓用戶干等著沧奴，也不知道什么時(shí)候結(jié)束而造成不好的用戶體驗(yàn)。
7长窄、工作線程優(yōu)先級(jí)設(shè)置不對(duì)滔吠，導(dǎo)致和ui線程搶占cpu時(shí)間。
使用Rxjava的小伙伴要注意這點(diǎn)挠日，設(shè)置任務(wù)的執(zhí)行線程可能會(huì)對(duì)你的性能產(chǎn)生較大的影響疮绷，沒有使用的小伙伴也不能太過大意。
8肆资、靜態(tài)變量矗愧。
嘿嘿，大家一定有過在application中設(shè)置靜態(tài)變量的經(jīng)歷郑原，遙想當(dāng)年唉韭，為了越過Intent只能傳遞1M以下數(shù)據(jù)的坑，我在application中設(shè)置了一個(gè)靜態(tài)變量犯犁，用于兩個(gè)activity“傳遞（共享）數(shù)據(jù)”属愤，然而，一步小心酸役，數(shù)據(jù)中住诸，有著前一個(gè)activity的尾巴驾胆，因此泄露了。不光是這樣的例子贱呐，隨便舉幾個(gè)：
a丧诺、你用靜態(tài)集合保存過數(shù)據(jù)吧？
b奄薇、某某單例的Manger驳阎，比如管理AudioManger遇到過吧？
三 既然遇到問題分析也有了馁蒂，那么接下來呵晚，自然而然是如何使用各種刀棒棍劍來解決這些問題了
1沫屡、GPU過度繪制饵隙，定位過度繪制區(qū)域
這里直接在開發(fā)者選項(xiàng)，打開Show GPU Overdraw沮脖，就可以看到效果金矛，輕松發(fā)現(xiàn)哪塊需要優(yōu)化，那么具體如何去優(yōu)化
a倘潜、減少布局層級(jí)绷柒，上面有提到過，使用ConstraintLayout替換傳統(tǒng)的布局方式涮因。如果你對(duì)ConstraintLayout不了解废睦，沒有關(guān)系，這篇文章教你15分鐘了解如何使用ConstraintLayout养泡。
b嗜湃、檢查是否有多余的背景色設(shè)置，我們通常會(huì)犯一些低級(jí)錯(cuò)誤--對(duì)被覆蓋的父view設(shè)置背景澜掩，多數(shù)情況下這些背景是沒有必要的购披。
2、主線程耗時(shí)操作排查肩榕。
a刚陡、開啟strictmode,這樣一來，主線程的耗時(shí)操作都將以告警的形式呈現(xiàn)到logcat當(dāng)中株汉。
b筐乳、直接對(duì)懷疑的對(duì)象加@DebugLog，查看方法執(zhí)行耗時(shí)乔妈。DebugLog注解需要引入插件hugo蝙云，這個(gè)是Android之神JakeWharton的早期作品，對(duì)于監(jiān)控函數(shù)執(zhí)行時(shí)間非常方便路召，直接在函數(shù)上加入注解就可以實(shí)現(xiàn)勃刨，但是有一個(gè)缺點(diǎn)波材，就是JakeWharton發(fā)布的最后一個(gè)版本沒有支持release版本用空方法替代監(jiān)控代碼，因此身隐，我這里發(fā)布了一個(gè)到公司的maven倉(cāng)庫(kù)廷区，引用的方式和官網(wǎng)類似，只不過抡医，地址是：'com.tencent.tip:hugo-plugin:2.0.0-SNAPSHOT'躲因。
3、對(duì)于measure忌傻，layout耗時(shí)過多的問題
一般這類問題是優(yōu)于布局過于復(fù)雜的原因?qū)е拢F(xiàn)在因?yàn)橛蠧onstraintLayout搞监，所以水孩，強(qiáng)烈建議使用ConstraintLayout減少布局層級(jí)，問題一般得以解決琐驴，如果發(fā)現(xiàn)還存在性能問題俘种，可以使用traceView觀察方法耗時(shí)，來定位下具體原因绝淡。
4宙刘、leakcany
這個(gè)是內(nèi)存泄露監(jiān)測(cè)的銀彈，大家應(yīng)該都使用過牢酵，需要提醒一下的是悬包，要注意
dependencies {
debugImplementation 'com.squareup.leakcanary:leakcanary-android:1.5.4'
releaseImplementation 'com.squareup.leakcanary:leakcanary-android-no-op:1.5.4'
}
引入方式，releaseImplementation保證在發(fā)布包中移除監(jiān)控代碼馍乙，否則布近，他自生不停的catch內(nèi)存快照，本身也影響性能丝格。
5撑瞧、onDraw里面寫代碼需要注意
onDraw優(yōu)于大概每16ms都會(huì)被執(zhí)行一次，因此本身就相當(dāng)于一個(gè)forloop显蝌，如果你在里面new對(duì)象的話预伺，不知不覺中就滿足了短時(shí)間內(nèi)大量對(duì)象創(chuàng)建并釋放，于是頻繁GC就發(fā)生了曼尊，嗯酬诀，內(nèi)存抖動(dòng)，于是涩禀，卡了料滥。因此，正確的做法是將對(duì)象放在外面new出來艾船。
6葵腹、json反序列化問題
json反序列化是指將json字符串轉(zhuǎn)變?yōu)閷?duì)象高每，這里如果數(shù)據(jù)量比較多，特別是有相當(dāng)多的string的時(shí)候践宴，解析起來不僅耗時(shí)鲸匿，而且還很吃內(nèi)存。解決的方式是：
a阻肩、精簡(jiǎn)字段带欢，與后臺(tái)協(xié)商，相關(guān)接口剔除不必要的字段烤惊。保證最小可用原則乔煞。
b、使用流解析柒室，之前我考慮過json解析優(yōu)化渡贾，在Stack Overflow上搜索到這個(gè)。于是了解到Gson.fromJson是可以這樣玩的雄右，可以提升25%的解析效率空骚。
7擂仍、viewStub&merge的使用囤屹。
這里merge和viewStub想必是大家非常了解的兩個(gè)布局組件了，對(duì)于只有在某些條件下才展示出來的組件逢渔，建議使用viewStub包裹起來肋坚，同樣的道理，include 某布局如果其根布局和引入他的父布局一致复局，建議使用merge包裹起來冲簿，如果你擔(dān)心preview效果問題，這里完全沒有必要亿昏，因?yàn)槟憧梢?/p>
tools:showIn=""屬性峦剔，這樣就可以正常展示preview了。
8角钩、加載優(yōu)化
這里并沒有過多的技術(shù)點(diǎn)在里面吝沫，無非就是將耗時(shí)的操作封裝到異步中去了，但是递礼，有一點(diǎn)不得不提的是惨险，要注意多進(jìn)程的問題，如果你的應(yīng)用是多進(jìn)程脊髓，你應(yīng)該認(rèn)識(shí)到你的application的oncreate方法會(huì)被執(zhí)行多次辫愉，你一定不希望資源加載多次吧，于是你只在主進(jìn)程加載将硝，如是有些坑就出現(xiàn)了恭朗，有可能其他進(jìn)程需要那某份資源屏镊，然后他這個(gè)進(jìn)程缺沒有加載相應(yīng)的資源，然后就嗝屁了痰腮。
9而芥、刷新優(yōu)化。
這點(diǎn)在我之前的文章中有提到過膀值，這里舉兩個(gè)例子吧棍丐。
a、對(duì)于列表的中的item的操作沧踏，比如對(duì)item點(diǎn)贊歌逢，此時(shí)不應(yīng)該讓整個(gè)列表刷新，而是應(yīng)該只刷新這個(gè)item悦冀，相比對(duì)于熟練使用recyclerView的你趋翻，應(yīng)該明白如何操作了,不懂請(qǐng)看這里，你將會(huì)明白什么叫做recyclerView的局部刷新盒蟆。
b、對(duì)于較為復(fù)雜的頁面师骗，個(gè)人建議不要寫在一個(gè)activity中历等，建議使用幾個(gè)fragment進(jìn)行組裝，這樣一來辟癌，module的變更可以只刷新某一個(gè)具體的fragment寒屯，而不用整個(gè)頁面都走刷新邏輯。但是問題來了黍少，fragment之間如何共享數(shù)據(jù)呢寡夹？好，看我怎么操作厂置。
Activity將數(shù)據(jù)這部分抽象成一個(gè)LiveData，交個(gè)LiveDataManger數(shù)據(jù)進(jìn)行管理昵济，然后各個(gè)Fragment通過Activity的這個(gè)context從LiveDataManger中拿到LiveData,進(jìn)行操作智绸，通知activity數(shù)據(jù)變更等等。哈哈访忿，你沒有看錯(cuò)瞧栗，這個(gè)確實(shí)和Google的那個(gè)LiveData有點(diǎn)像，當(dāng)然海铆，如果你想使用Google的那個(gè)迹恐，也自然沒問題，只不過卧斟，這個(gè)是簡(jiǎn)化版的殴边。項(xiàng)目的引入
'com.tencent.tip:simple_live_data:1.0.1-SNAPSHOT'
10憎茂、動(dòng)畫優(yōu)化
這里主要是想說使用硬件加速來做優(yōu)化，不過要注意找都，動(dòng)畫做完之后唇辨，關(guān)閉硬件加速，因?yàn)殚_啟硬件加速本身就是一種消耗能耻。下面有一幅圖赏枚，第二幅對(duì)比第一幅是說開啟硬件加速和沒開啟的時(shí)候做動(dòng)畫的效果對(duì)比，可以看到開啟后的渲染速度明顯快不少晓猛，開啟硬件加速就一定萬事大吉么饿幅？第三幅圖實(shí)際上就說明，如果你的這個(gè)view不斷的失效的話戒职，也會(huì)出現(xiàn)性能問題栗恩，第三圖中可以看到藍(lán)色的部曲線圖有了一定的起色，這說明洪燥，displaylist不斷的失效并重現(xiàn)創(chuàng)建磕秤，如果你想了解的更加詳細(xì)，可以查看這里
11耗電優(yōu)化
這里僅僅只是建議；
a再来、在定位精度要求不高的情況下蒙兰，使用wifi或移動(dòng)網(wǎng)絡(luò)進(jìn)行定位，沒有必要開啟GPS定位芒篷。
b搜变、先驗(yàn)證網(wǎng)絡(luò)的可用性，在發(fā)送網(wǎng)絡(luò)請(qǐng)求针炉，比如挠他，當(dāng)用戶處于2G狀態(tài)下，而此時(shí)的操作是查看一張大圖糊识，下載下來可能都200多K甚至更大绩社，我們沒必要去發(fā)送這個(gè)請(qǐng)求，讓用戶一直等待那個(gè)菊花吧赂苗。
四 接下來的一些內(nèi)容就比較輕松了愉耙，是關(guān)于一些代碼的建議
這里不一一細(xì)講了拌滋，僅僅挑標(biāo)記的部分說下朴沿。
pb->model這里的優(yōu)化就不在贅述，前面有講如何優(yōu)化。
然后建議使用SparseArray代替HashMap,這里是Google建議的赌渣，因?yàn)镾parseArray比HashMap更省內(nèi)存魏铅，在某些條件下性能更好，主要是因?yàn)樗苊饬藢?duì)key的自動(dòng)裝箱比如（int轉(zhuǎn)為Integer類型）坚芜，它內(nèi)部則是通過兩個(gè)數(shù)組來進(jìn)行數(shù)據(jù)存儲(chǔ)的览芳，一個(gè)存儲(chǔ)key，另外一個(gè)存儲(chǔ)value鸿竖，為了優(yōu)化性能沧竟，它內(nèi)部對(duì)數(shù)據(jù)還采取了壓縮的方式來表示稀疏數(shù)組的數(shù)據(jù)，從而節(jié)約內(nèi)存空間缚忧。
不到不得已悟泵，不要使用wrap_content,,推薦使用match_parent,或者固定尺寸，配合gravity="center"闪水，哈哈糕非，你應(yīng)該懂了的。
那么為什么說這樣會(huì)比較好球榆。
因?yàn)?在測(cè)量過程中朽肥，match_parent和固定寬高度對(duì)應(yīng)EXACTLY ,而wrap_content對(duì)應(yīng)AT_MOST,這兩者對(duì)比AT_MOST耗時(shí)較多。
五 總結(jié)
這是以上關(guān)于我在工作中遇到的性能問題的及處理的一些總結(jié)持钉，性能優(yōu)化設(shè)計(jì)的方方面面實(shí)在是太多太多鞠呈，本文不可能將全部的性能問題全部總結(jié)的清清楚楚，或許還多多少少存在一些紕漏之處右钾，有不對(duì)的地方歡迎指出補(bǔ)充。
