前言
本文收集了我自己工作以來提交代碼前的所有檢查點。事實證明，這樣能有效提高自己的代碼質量和功能的穩定性。所以推薦大家以后每次提交代碼前，都可以看下這份 Review 清單哈。
清理操作
1.頁面退出時，是否完成必要的清理操作
1) 是否調用 Handler 的 removeCallbacksAndMessages(null) 來清空 Handler 里的消息；
2) 是否取消了還沒完成的請求；
3) 在頁面里注冊的監聽，是否反注冊；
4) 假如自己用到觀察者模式，是否反注冊；
5) 假如用了 RxJava 的話，是否解除訂閱；
2.數據庫的游標是否已經關閉
這個點一般人都知道，出問題一般在于，沒有考慮到多線程并發時的情況下，Cursor 沒有被釋放。
所以數據庫的操作需要加上同步代碼塊
詳細可參考：http://www.2cto.com/kf/201408/329574.html
3.打開過的文件流是否關閉
4.Android 3.0 以下的版本，使用完的 Bitmap 是否調用 recycle()，否則會一直占用內存
而 Android 3.0 及以上的版本不需要調用 recycle()，因為這些版本的 Bitmap 全部放到虛擬機的堆內存中，讓 GC 自動回收。
5.WebView 使用完是否調用了其 destory() 函數
是否能進一步優化自己的代碼
1.保存在內存中的圖片，是否做過壓縮處理再保存在內存里
否則可能由于圖片質量太高，導致 OOM
2.Intent 傳遞的數據太大，會導致頁面跳轉過慢。太大的數據可以通過持久化的形式傳遞，例如讀寫文件
3.頻繁地操作同一個文件或者執行同一個數據庫操作，是否考慮把它用靜態變量或者局部變量的形式緩存在內存里。用空間換時間
4.放在主頁面的控件，是否可以考慮用 ViewStub 來優化啟動速度
要小心第三方包
1.build.gradle 遠程依賴第三方包時，版本號建議寫死，不要使用+號
避免由于新版本的第三方包引入了新的問題
2.導入第三方工程時，記得把編碼轉換成自己工程當前是用的編碼
3.調用第三方的包或者 JDK 的方法時，要跳進他們的源碼，看要不要加 try-catch
否則可能會導致自己應用的崩潰
4.使用第三方包時，是否加上其混淆規則
若漏掉加上第三方包的混淆規則，會導致第三方包不該混淆的代碼被混淆。在 Debug 版本沒有發現問題，但是 Release 版本就會出現問題
5.系統應用添加 so 時，是否在固件對應的 Android.mk 文件上加入新增的 so，否則系統可能編譯不過
注意要成對出現的地方
1.系統的、自己寫的，注冊和反注冊的方法，是否成對出現
2.在生命周期的回調里，創建和銷毀的代碼是否對應起來
比如：onCreate() 里面創建了 Adapter，那么對應 Adapter 的退出處理操作(比如清空Image 緩存)，一般就要寫在 onDestory()，而不能寫在 onDestoryView()。
類似的生命周期對應的代碼有：
onStart()、onStop();
onCreate()、onDestory();
onResume()、onPause();
onCreateView()、onDestoryView()
3.若 ListView 的 item 復用了，對 Item 里 View 的操作是否成對出現
比如：
比如以上對 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
如：
其他
1.多思考某些情況下，某變量是否會為空
而且在函數體內，處理參數前，必須加上判空語句
2.回調函數是否處理好
回調函數很容易出問題。比如網絡請求的回調，需要判斷此時的 Aciivity 等是否還存在，再進行調用。因為異步操作回來，Activity 可能就消失不存在了。
而且還要對一些可能被回收的變量進行判空。
3.修改數據庫后，是否把數據庫的版本號+1
4.啟動第三方的 Activity 時，是否判斷了該 Intent 能否被解析
若 Activity 不存在，會出現 ActivityNotFoundException 的異常
5.新注冊的 Activity、Service 或 Provider，若 AndroidManifest.xml 中 exported 屬性為 true，要考慮是否會引發安全性問題
因為 exported 屬性為 true 時，外部應用就可以直接調用起該 Activity。
可能導致的問題：
1）若外部應用直接啟動詳情頁，從而讓某些驗證頁面直接被繞過
2）若外部應用給該 Activity 傳遞亂七八糟的 Intent，可能讓該應用崩潰。也就是 Android中的拒絕服務漏洞
5.除數是否做了非 0 判斷
6.不要在 Activity 的 onCreate 里調用 PopupWindow 的 showAsLoaction 方法，由于Activity 還沒被加載完，會報錯
功能完成后，自測時的檢查點
1.思考某些情況下，某個變量是否會造成空指針問題
2.把手機橫屏，檢查布局是否有 Bug
3.在不同分辨率的機型上，檢查布局是否有 Bug
4.切換到英文等外文字體下，檢查外文是否能完整顯示
5.從低版本升級上來，會不會有問題
比如可能會出現數據庫不兼容的問題
6.按下 Home 再返回是否正常
7.熄滅屏幕再打開是否正常
8.切換成其它應用再切換回來會怎樣
9.利用手機的開發者選項中的 “調試 GPU 過度繪制” ，“GPU呈現模式分析” 和 “顯示FPS和功耗” 功能，看自己的新功能是否會導致過度繪制、是否會掉幀
10.測試看是否影響啟動速度
adb shell am start -W 包名/Activity
11.對比看APK大小是否有增大
12.跑 1 小時 Monkey，測試其穩定性
注：非原創。來源自掘金code小生
