前言
本文收集了我自己工作以來提交代碼前的所有檢查點谁不。事實證明坐梯，這樣能有效提高自己的代碼質(zhì)量和功能的穩(wěn)定性。所以推薦大家以后每次提交代碼前刹帕，都可以看下這份Review清單哈吵血。
此外谎替，可能還有些檢查點我并沒有發(fā)現(xiàn)，歡迎大家踴躍在評論區(qū)補充哈～
清理操作
1.頁面退出時蹋辅，是否完成必要的清理操作
是否調(diào)用Handler的removeCallbacksAndMessages(null)來清空Handler里的消息钱贯；
是否取消了還沒完成的請求；
在頁面里注冊的監(jiān)聽侦另，是否反注冊秩命；
假如自己用到觀察者模式，是否反注冊褒傅；
假如用了RxJava的話弃锐，是否解除訂閱；
2.數(shù)據(jù)庫的游標(biāo)是否已經(jīng)關(guān)閉
這個點一般人都知道殿托，出問題一般在于霹菊，沒有考慮到多線程并發(fā)時的情況下，Cursor沒有被釋放碌尔。
所以數(shù)據(jù)庫的操作需要加上同步代碼塊
詳細(xì)可參考：http://www.2cto.com/kf/201408/329574.html
3.打開過的文件流是否關(guān)閉
4.Android 3.0以下的版本浇辜，使用完的Bitmap是否調(diào)用recycle()，否則會一直占用內(nèi)存
而Android 3.0及以上的版本不需要調(diào)用recycle()唾戚，因為這些版本的Bitmap全部放到虛擬機的堆內(nèi)存中，讓GC自動回收待诅。
5.WebView使用完是否調(diào)用了其destory()函數(shù)
是否能進一步優(yōu)化自己的代碼
1.保存在內(nèi)存中的圖片叹坦，是否做過壓縮處理再保存在內(nèi)存里
否則可能由于圖片質(zhì)量太高，導(dǎo)致OOM
2.Intent傳遞的數(shù)據(jù)太大卑雁，會導(dǎo)致頁面跳轉(zhuǎn)過慢募书。太大的數(shù)據(jù)可以通過持久化的形式傳遞，例如讀寫文件
3.頻繁地操作同一個文件或者執(zhí)行同一個數(shù)據(jù)庫操作测蹲，是否考慮把它用靜態(tài)變量或者局部變量的形式緩存在內(nèi)存里莹捡。用空間換時間
4.放在主頁面的控件，是否可以考慮用ViewStub來優(yōu)化啟動速度
要小心第三方包
1.build.gradle遠(yuǎn)程依賴第三方包時扣甲，版本號建議寫死篮赢，不要使用+號
避免由于新版本的第三方包引入了新的問題
2.導(dǎo)入第三方工程時，記得把編碼轉(zhuǎn)換成自己工程當(dāng)前是用的編碼
3.調(diào)用第三方的包或者JDK的方法時琉挖，要跳進他們的源碼启泣，看要不要加 try-catch
否則可能會導(dǎo)致自己應(yīng)用的崩潰
4.使用第三方包時，是否加上其混淆規(guī)則
若漏掉加上第三方包的混淆規(guī)則示辈，會導(dǎo)致第三方包不該混淆的代碼被混淆寥茫。在Debug版本沒有發(fā)現(xiàn)問題，但是Release版本就會出現(xiàn)問題
5.系統(tǒng)應(yīng)用添加so時矾麻，是否在固件對應(yīng)的Android.mk文件上加入新增的so纱耻，否則系統(tǒng)可能編譯不過
@lib/armeabi/libcommon.so\@lib/armeabi/libabcdefg.so \
注意要成對出現(xiàn)的地方
1.系統(tǒng)的娄琉、自己寫的姐帚，注冊和反注冊的方法，是否成對出現(xiàn)
2.在生命周期的回調(diào)里，創(chuàng)建和銷毀的代碼是否對應(yīng)起來
比如：onCreate()里面創(chuàng)建了Adapter缘滥，那么對應(yīng)Adapter的退出處理操作(比如清空Image緩存)，一般就要寫在onDestory()于宙，而不能寫在onDestoryView()摩梧。
類似的生命周期對應(yīng)的代碼有：
onStart()、onStop();
onCreate()卖漫、onDestory();
onResume()费尽、onPause();
onCreateView()、onDestoryView()
3.若ListView的item復(fù)用了羊始，對Item里View的操作是否成對出現(xiàn)
比如：
switch (type) {caseArticleListItem.TYPE_AD:? ? ? ? ......? ? ? ? mTitleView.setText(tencentAdBean.title);? ? ? ? mGreenLabelView.setVisibility(VISIBLE);? ? ? ? mRedLabelView.setText("");? ? ? ? mRedLabelView.setVisibility(GONE);break;caseArticleListItem.TYPE_ARTICLE:? ? ? ? ......? ? ? ? mTitleView.setText(mzAdBean.adData.getTitle());? ? ? ? mGreenLabelView.setVisibility(GONE);? ? ? ? mRedLabelView.setText("ABC");? ? ? ? mRedLabelView.setVisibility(VISIBLE);break;}
比如以上對mTitleView旱幼、mGreenLabelView和mRedLabelView的操作，都是成對出現(xiàn)突委。否則ListView可能會由于Item復(fù)用柏卤，導(dǎo)致Item顯示錯亂問題
防內(nèi)存泄漏
1.內(nèi)部類，比如Handler匀油、Listener缘缚、Callback是否是成static class
因為非靜態(tài)內(nèi)部類會持有外部類的引用。
2.假如子線程持有了Activity敌蚜，要用弱引用來持有
比如Request的Activity就應(yīng)該用弱引用的形式桥滨，防止內(nèi)存泄漏。
3.要求傳入Activity作為參數(shù)的函數(shù)弛车，是否可以改用getApplicationContext()來作為參數(shù)
Handler相關(guān)
1.使用View.post()是否會有問題
因為在View處于detached狀態(tài)期間齐媒，post()里面的Runnable是不會被執(zhí)行的。只有在此View處于attached狀態(tài)時才會被執(zhí)行纷跛。
如果想改Runnable每次肯定會被執(zhí)行喻括，那么應(yīng)該是用Handler.post來替代
2.假如程序可能多次在同一個Handler里post同一個Runnable，每次post之前都應(yīng)該先清空這個Handler中還沒執(zhí)行的該Runnable
如：
if(mCloudRun !=null) {? ? mHandler.removeCallbacks(mCloudRun);? ? mCloudRun =null;}mCloudRun =newRunnable() {@Overridepublicvoidrun(){? ? ? ? CloudAccelerateSwitchRequest request =newCloudAccelerateSwitchRequest();? ? ? ? request.setPriority(RequestTask.PRIORITY_LOW);? ? ? ? RequestQueue.getInstance().addRequest(request);? ? }};mHandler.post(mCloudRun);
其他
1.多思考某些情況下贫奠，某變量是否會為空
而且在函數(shù)體內(nèi)唬血，處理參數(shù)前，必須加上判空語句
2.回調(diào)函數(shù)是否處理好
回調(diào)函數(shù)很容易出問題叮阅。比如網(wǎng)絡(luò)請求的回調(diào)刁品，需要判斷此時的Aciivity等是否還存在，再進行調(diào)用浩姥。因為異步操作回來挑随，Activity可能就消失不存在了。
而且還要對一些可能被回收的變量進行判空勒叠。
3.修改數(shù)據(jù)庫后兜挨，是否把數(shù)據(jù)庫的版本號+1
4.啟動第三方的Activity時膏孟，是否判斷了該Intent能否被解析
Intent sendIntent =newIntent(mContext, Demo.class);// 這種方式判斷是否存在if(sendIntent.resolveActivity(getPackageManager()) !=null) {? ? startActivity(sendIntent);}
若Activity不存在，會出現(xiàn)ActivityNotFoundException的異常
5.新注冊的Activity拌汇、Service或Provider柒桑，若AndroidManifest.xml中exported屬性為true，要考慮是否會引發(fā)安全性問題
因為exported屬性為true時噪舀，外部應(yīng)用就可以直接調(diào)用起該Activity魁淳。
可能導(dǎo)致的問題：
1）若外部應(yīng)用直接啟動詳情頁，從而讓某些驗證頁面直接被繞過
2）若外部應(yīng)用給該Activity傳遞亂七八糟的Intent与倡，可能讓該應(yīng)用崩潰界逛。也就是Android中的拒絕服務(wù)漏洞
5.除數(shù)是否做了非0判斷
6.不要在Activity的onCreate里調(diào)用PopupWindow的showAsLoaction方法，由于Activity還沒被加載完纺座，會報錯
功能完成后息拜，自測時的檢查點
1.思考某些情況下，某個變量是否會造成空指針問題
2.把手機橫屏净响，檢查布局是否有Bug
3.在不同分辨率的機型上少欺，檢查布局是否有Bug
4.切換到英文等外文字體下，檢查外文是否能完整顯示
5.從低版本升級上來馋贤，會不會有問題
比如可能會出現(xiàn)數(shù)據(jù)庫不兼容的問題
6.按下Home再返回是否正常
7.熄滅屏幕再打開是否正常
8.切換成其它應(yīng)用再切換回來會怎樣
9.利用手機的開發(fā)者選項中的 “調(diào)試GPU過度繪制” 赞别，“GPU呈現(xiàn)模式分析” 和 “顯示FPS和功耗” 功能，看自己的新功能是否會導(dǎo)致過度繪制掸掸、是否會掉幀
10.測試看是否影響啟動速度
adb shell am start -W 包名/Activity
11.對比看APK大小是否有增大
12.跑1小時Monkey氯庆，測試其穩(wěn)定性
感謝評論區(qū)的 “美猴王丶”、“夢開始陣痛”扰付、“ziabo_yu”? 提出的問題和新的檢查點。已添加到文章中～
碼字不易仁讨，轉(zhuǎn)載請注明出處：http://www.reibang.com/p/4b65967fe4a0
作者：InKenKa
鏈接：http://www.reibang.com/p/4b65967fe4a0
來源：簡書
著作權(quán)歸作者所有羽莺。商業(yè)轉(zhuǎn)載請聯(lián)系作者獲得授權(quán)，非商業(yè)轉(zhuǎn)載請注明出處洞豁。
