清單革命之Android開發中必備的代碼Review清單小結

---

導讀

Android開發中養成良好的習慣尤爲重要，大腦按照一定的思考模式系統思考會降低錯誤的發生率。老羅曾推薦《清單革命》，可以讓工作更調條。萬事萬物皆有套路。基於此，我向大家推薦一下Android開發中的代碼檢查清單，請大家多指教，後期我會不斷完善Android開發清單革命。

---

注：以下轉自：
https://www.jianshu.com/p/4b65967fe4a0

前言

本文收集了我自己工作以來提交代碼前的所有檢查點。事實證明，這樣能有效提高自己的代碼質量和功能的穩定性。所以推薦大家以後每次提交代碼前，都可以看下這份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，否則系統可能編譯不過

@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時，是否判斷了該Intent能否被解析

Intent sendIntent = new Intent(mContext, Demo.class);
// 這種方式判斷是否存在
if (sendIntent.resolveActivity(getPackageManager()) != null) {
    startActivity(sendIntent);
}

若Activity不存在，會出現ActivityNotFoundException的異常

5.新註冊的Activity、Service或Provider，若AndroidManifest.xml中exported屬性爲true，要考慮是否會引發安全性問題

<activity android:name="com.inkenka.DemoActivity"
            android: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，測試其穩定性

---

推薦閱讀：
《清單革命》讓工作更條理
https://www.jianshu.com/p/54ece14f61e1