前言

本文收集了我自己工作以來提交代碼前的所有檢查點(diǎn)。事實(shí)證明，這樣能有效提高自己的代碼質(zhì)量和功能的穩(wěn)定性。所以推薦大家以后每次提交代碼前，都可以看下這份 Review 清單哈。

此外，可能還有些檢查點(diǎn)我并沒有發(fā)現(xiàn)，歡迎大家踴躍在評論區(qū)補(bǔ)充哈～

清理操作

1.頁面退出時(shí)，是否完成必要的清理操作

1) 是否調(diào)用 Handler 的 removeCallbacksAndMessages(null) 來清空 Handler 里的消息；

2) 是否取消了還沒完成的請求；

3) 在頁面里注冊的監(jiān)聽，是否反注冊；

4) 假如自己用到觀察者模式，是否反注冊；

5) 假如用了 RxJava 的話，是否解除訂閱；

2.數(shù)據(jù)庫的游標(biāo)是否已經(jīng)關(guān)閉這個(gè)點(diǎn)一般人都知道，出問題一般在于，沒有考慮到多線程并發(fā)時(shí)的情況下，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()，因?yàn)檫@些版本的 Bitmap 全部放到虛擬機(jī)的堆內(nèi)存中，讓 GC 自動回收。

5.WebView 使用完是否調(diào)用了其 destory() 函數(shù)

是否能進(jìn)一步優(yōu)化自己的代碼

1.保存在內(nèi)存中的圖片，是否做過壓縮處理再保存在內(nèi)存里否則可能由于圖片質(zhì)量太高，導(dǎo)致 OOM

2.Intent 傳遞的數(shù)據(jù)太大，會導(dǎo)致頁面跳轉(zhuǎn)過慢。太大的數(shù)據(jù)可以通過持久化的形式傳遞，例如讀寫文件

3.頻繁地操作同一個(gè)文件或者執(zhí)行同一個(gè)數(shù)據(jù)庫操作，是否考慮把它用靜態(tài)變量或者局部變量的形式緩存在內(nèi)存里。用空間換時(shí)間

4.放在主頁面的控件，是否可以考慮用 ViewStub 來優(yōu)化啟動速度

要小心第三方包

1.build.gradle 遠(yuǎn)程依賴第三方包時(shí)，版本號建議寫死，不要使用+號避免由于新版本的第三方包引入了新的問題

2.導(dǎo)入第三方工程時(shí)，記得把編碼轉(zhuǎn)換成自己工程當(dāng)前是用的編碼

3.調(diào)用第三方的包或者 JDK 的方法時(shí)，要跳進(jìn)他們的源碼，看要不要加 try-catch否則可能會導(dǎo)致自己應(yīng)用的崩潰

4.使用第三方包時(shí)，是否加上其混淆規(guī)則若漏掉加上第三方包的混淆規(guī)則，會導(dǎo)致第三方包不該混淆的代碼被混淆。在 Debug 版本沒有發(fā)現(xiàn)問題，但是 Release 版本就會出現(xiàn)問題

5.系統(tǒng)應(yīng)用添加 so 時(shí)，是否在固件對應(yīng)的 Android.mk 文件上加入新增的 so，否則系統(tǒng)可能編譯不過

注意要成對出現(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)比如：

比如以上對 mTitleView、mGreenLabelView 和 mRedLabelView 的操作，都是成對出現(xiàn)。否則 ListView 可能會由于 Item 復(fù)用，導(dǎo)致 Item 顯示錯(cuò)亂問題

防內(nèi)存泄漏

1.內(nèi)部類，比如 Handler、Listener、Callback 是否是成 static class因?yàn)榉庆o態(tài)內(nèi)部類會持有外部類的引用。

2.假如子線程持有了 Activity，要用弱引用來持有比如 Request 的 Activity 就應(yīng)該用弱引用的形式，防止內(nèi)存泄漏。

3.要求傳入 Activity 作為參數(shù)的函數(shù)，是否可以改用 getApplicationContext() 來作為參數(shù)

Handler相關(guān)

1.使用 View.post() 是否會有問題因?yàn)樵?View 處于 detached 狀態(tài)期間，post() 里面的 Runnable 是不會被執(zhí)行的。只有在此 View 處于 attached 狀態(tài)時(shí)才會被執(zhí)行。

如果想改 Runnable 每次肯定會被執(zhí)行，那么應(yīng)該是用 Handler.post 來替代

2.假如程序可能多次在同一個(gè) Handler 里 post 同一個(gè) Runnable，每次 post 之前都應(yīng)該先清空這個(gè) Handler 中還沒執(zhí)行的該 Runnable如：

其他

1.多思考某些情況下，某變量是否會為空而且在函數(shù)體內(nèi)，處理參數(shù)前，必須加上判空語句

2.回調(diào)函數(shù)是否處理好回調(diào)函數(shù)很容易出問題。比如網(wǎng)絡(luò)請求的回調(diào)，需要判斷此時(shí)的 Aciivity 等是否還存在，再進(jìn)行調(diào)用。因?yàn)楫惒讲僮骰貋恚珹ctivity 可能就消失不存在了。而且還要對一些可能被回收的變量進(jìn)行判空。

3.修改數(shù)據(jù)庫后，是否把數(shù)據(jù)庫的版本號+1

4.啟動第三方的 Activity 時(shí)，是否判斷了該 Intent 能否被解析

若 Activity 不存在，會出現(xiàn) ActivityNotFoundException 的異常

5.新注冊的 Activity、Service 或 Provider，若 AndroidManifest.xml 中 exported 屬性為 true，要考慮是否會引發(fā)安全性問題

因?yàn)?exported 屬性為 true 時(shí)，外部應(yīng)用就可以直接調(diào)用起該 Activity。可能導(dǎo)致的問題：1）若外部應(yīng)用直接啟動詳情頁，從而讓某些驗(yàn)證頁面直接被繞過2）若外部應(yīng)用給該 Activity 傳遞亂七八糟的 Intent，可能讓該應(yīng)用崩潰。也就是 Android中的拒絕服務(wù)漏洞

5.除數(shù)是否做了非 0 判斷

6.不要在 Activity 的 onCreate 里調(diào)用 PopupWindow 的 showAsLoaction 方法，由于Activity 還沒被加載完，會報(bào)錯(cuò)

功能完成后，自測時(shí)的檢查點(diǎn)

1.思考某些情況下，某個(gè)變量是否會造成空指針問題

2.把手機(jī)橫屏，檢查布局是否有 Bug

3.在不同分辨率的機(jī)型上，檢查布局是否有 Bug

4.切換到英文等外文字體下，檢查外文是否能完整顯示

5.從低版本升級上來，會不會有問題比如可能會出現(xiàn)數(shù)據(jù)庫不兼容的問題

6.按下 Home 再返回是否正常

7.熄滅屏幕再打開是否正常

8.切換成其它應(yīng)用再切換回來會怎樣

9.利用手機(jī)的開發(fā)者選項(xiàng)中的 “調(diào)試 GPU 過度繪制” ，“GPU呈現(xiàn)模式分析” 和 “顯示FPS和功耗” 功能，看自己的新功能是否會導(dǎo)致過度繪制、是否會掉幀

10.測試看是否影響啟動速度adb shell am start -W 包名/Activity

11.對比看APK大小是否有增大

12.跑 1 小時(shí) Monkey，測試其穩(wěn)定性

文章不易，如果大家喜歡這篇文章，或者對你有幫助希望大家多多點(diǎn)贊轉(zhuǎn)發(fā)關(guān)注哦。文章會持續(xù)更新的。絕對干貨?。。?/p>

推薦閱讀：amd顯卡