作者: InKenKa
簡書: http://www.lxweimin.com/u/97315b81287a
前言
本文收集了我自己工作以來提交代碼前的所有檢查點。事實證明，這樣能有效提高自己的代碼質量和功能的穩定性。所以推薦大家以后每次提交代碼前，都可以看下這份Review清單哈。
此外，可能還有些檢查點我并沒有發現，歡迎大家踴躍在評論區補充哈～
清理操作
1.頁面退出時，是否完成必要的清理操作
- 是否調用Handler的removeCallbacksAndMessages(null)來清空Handler里的消息
- 是否取消了還沒完成的請求
- 在頁面里注冊的監聽等，是否取消注冊
2.數據庫的游標是否已經關閉
這個點一般人都知道，出問題一般在于，沒有考慮到多線程并發時的情況下，Cursor沒有被釋放。
所以數據庫的操作需要加上同步代碼塊
詳細可參考：http://www.2cto.com/kf/201408/329574.html
3.打開過的文件流是否關閉
4.使用完的Bitmap是否調用recycle()回收
否則會很耗內存，導致OOM或者卡頓
5.WebView使用完是否調用了其destory()函數
是否能進一步優化自己的代碼
1.保存在內存中的圖片，是否做過壓縮處理再保存在內存里
否則可能由于圖片質量太高，導致OOM
2.Intent傳遞的數據太大，會導致頁面跳轉過慢。太大的數據可以通過持久化的形式傳遞，例如讀寫文件
3.頻繁地操作同一個文件或者執行同一個數據庫操作，是否考慮把它用靜態變量或者局部變量的形式緩存在內存里。用空間換時間
4.放在主頁面的控件，是否可以考慮用ViewStub來優化啟動速度
要小心第三方包
1.build.gradle遠程依賴第三方包時，版本號建議寫死，不要使用+號
避免由于新版本的第三方包引入了新的問題
2.導入第三方工程時，記得把編碼轉換成自己工程當前是用的編碼
3.調用第三方的包或者JDK的方法時，要跳進他們的源碼，看要不要加 try-catch
否則可能會導致自己應用的崩潰
4.系統應用添加so時，是否在固件對應的Android.mk文件上加入新增的so，否則系統可能編譯不過
@lib/armeabi/libcommon.so
@lib/armeabi/libabcdefg.so
注意要成對出現的地方
1.系統的、自己寫的，注冊和反注冊的方法，是否成對出現
2.在生命周期的回調里，創建和銷毀的代碼是否對應起來
比如：onCreate()里面創建了Adapter，那么對應Adapter的退出處理操作(比如清空Image緩存)，一般就要寫在onDestory()，而不能寫在onDestoryView()。
類似的生命周期對應的代碼有：
onStart()、onStop();
onCreate()、onDestory();
onResume()、onPause();
onCreateView()、onDestoryView()
3.若ListView的item復用了，對Item里View的操作是否成對出現
比如：
switch (type) {
case ArticleListItem.TYPE_AD:
......
mTitleView.setText(tencentAdBean.title);
mGreenLabelView.setVisibility(VISIBLE);
mRedLabelView.setText("");
mRedLabelView.setVisibility(GONE);
break;
case ArticleListItem.TYPE_ARTICLE:
......
mTitleView.setText(mzAdBean.adData.getTitle());
mGreenLabelView.setVisibility(GONE);
mRedLabelView.setText("ABC");
mRedLabelView.setVisibility(VISIBLE);
break;
}
比如以上對mTitleView、mGreenLabelView和mRedLabelView的操作，都是成對出現。否則ListView可能會由于Item復用，導致Item顯示錯亂問題
防內存泄漏
1.內部類，比如Handler、Listener、Callback是否是成static class
因為非靜態內部類會持有外部類的引用。
2.假如子線程持有了Activity，要用弱引用來持有
比如Request的Activity就應該用弱引用的形式，防止內存泄漏。
3.要求傳入Activity作為參數的函數，是否可以改用getApplicationContext()來作為參數
Handler相關
1.使用View.post()是否會有問題
因為在View處于detached狀態期間，post()里面的Runnable是不會被執行的。只有在此View處于attached狀態時才會被執行。
如果想改Runnable每次肯定會被執行，那么應該是用Handler.post來替代
2.假如程序可能多次在同一個Handler里post同一個Runnable，每次post之前都應該先清空這個Handler中還沒執行的該Runnable
如：
if (mCloudRun != null) {
mHandler.removeCallbacks(mCloudRun);
mCloudRun = null;
}
mCloudRun = new Runnable() {
@Override
public void run() {
CloudAccelerateSwitchRequest request = new CloudAccelerateSwitchRequest();
request.setPriority(RequestTask.PRIORITY_LOW);
RequestQueue.getInstance().addRequest(request);
}
};
mHandler.post(mCloudRun);
其他
1.多思考某些情況下，某變量是否會為空
而且在函數體內，處理參數前，必須加上判空語句
2.回調函數是否處理好
回調函數很容易出問題。比如網絡請求的回調，需要判斷此時的Aciivity等是否還存在，再進行調用。因為異步操作回來，Activity可能就消失不存在了。
而且還要對一些可能被回收的變量進行判空。
3.修改數據庫后，是否把數據庫的版本號+1
4.啟動第三方的Activity / Service時，是否加上try...catch
若Activity不在會爆出ActivityNotFoundException的異常
5.除數是否做了非0判斷
6.不要在Activity的onCreate里調用PopupWindow的showAsLoaction方法，由于Activity還沒被加載完，會報錯
功能完成后，自測時的檢查點
1.某些情況下某個變量是否會造成空指針問題
2.自測功能，通用的幾個檢查點
- 按下Home再返回是否正常；
- 熄滅屏幕再打開會怎樣；
- 切換成其它應用再切換回來會怎樣；
- onResume,onPause是否處理好;
3.從低版本升級上來，會不會有問題
4.打開 手機的開發者選項，看新功能是否會導致過度繪制、是否會掉幀
5.測試看是否影響啟動速度
adb shell am start -W 包名/Activity
6.對比看APK大小是否有增大
7.跑1小時Monkey測試其穩定性
8.試試看看App是否能被反編譯
9.檢查Log是否關閉
10.看看是否走的Https,能否被抓包
更多文章請關注公眾號
