(转)总结Android开发中必备的代码Review清单

前言

本文收集了我自己工作以来提交代码前的所有检查点。事实证明，这样能有效提高自己的代码质量和功能的稳定性。所以推荐大家以后每次提交代码前，都可以看下这份Review清单哈。

此外，可能还有些检查点我并没有发现，欢迎大家踊跃在评论区补充哈～

清理操作

页面退出时，是否完成必要的清理操作
1. 是否调用Handler的removeCallbacksAndMessages(null)来清空Handler里的消息；
2. 是否取消了还没完成的请求；
3. 在页面里注册的监听，是否反注册；
4. 假如自己用到观察者模式，是否反注册；
5. 假如用了RxJava的话，是否解除订阅；
数据库的游标是否已经关闭这个点一般人都知道，出问题一般在于，没有考虑到多线程并发时的情况下，Cursor没有被释放。所以数据库的操作需要加上同步代码块详细可参考：http://www.2cto.com/kf/201408/329574.html
打开过的文件流是否关闭
Android 3.0以下的版本，使用完的Bitmap是否调用recycle()，否则会一直占用内存而Android 3.0及以上的版本不需要调用recycle()，因为这些版本的Bitmap全部放到虚拟机的堆内存中，让GC自动回收。
WebView使用完是否调用了其destory()函数

是否能进一步优化自己的代码

保存在内存中的图片，是否做过压缩处理再保存在内存里否则可能由于图片质量太高，导致OOM
Intent传递的数据太大，会导致页面跳转过慢。太大的数据可以通过持久化的形式传递，例如读写文件
频繁地操作同一个文件或者执行同一个数据库操作，是否考虑把它用静态变量或者局部变量的形式缓存在内存里。用空间换时间
放在主页面的控件，是否可以考虑用ViewStub来优化启动速度

要小心第三方包

build.gradle远程依赖第三方包时，版本号建议写死，不要使用+号避免由于新版本的第三方包引入了新的问题
导入第三方工程时，记得把编码转换成自己工程当前是用的编码
调用第三方的包或者JDK的方法时，要跳进他们的源码，看要不要加 try-catch 否则可能会导致自己应用的崩溃
使用第三方包时，是否加上其混淆规则若漏掉加上第三方包的混淆规则，会导致第三方包不该混淆的代码被混淆。在Debug版本没有发现问题，但是Release版本就会出现问题
系统应用添加so时，是否在固件对应的Android.mk文件上加入新增的so，否则系统可能编译不过
1
2
@lib/armeabi/libcommon.so \
@lib/armeabi/libabcdefg.so \

注意要成对出现的地方

系统的、自己写的，注册和反注册的方法，是否成对出现
在生命周期的回调里，创建和销毁的代码是否对应起来比如：onCreate()里面创建了Adapter，那么对应Adapter的退出处理操作(比如清空Image缓存)，一般就要写在onDestory()，而不能写在onDestoryView()。

类似的生命周期对应的代码有： onStart()、onStop(); onCreate()、onDestory(); onResume()、onPause(); onCreateView()、onDestoryView()

若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显示错乱问题

防内存泄漏

内部类，比如Handler、Listener、Callback是否是成static class 因为非静态内部类会持有外部类的引用。
假如子线程持有了Activity，要用弱引用来持有比如Request的Activity就应该用弱引用的形式，防止内存泄漏。
要求传入Activity作为参数的函数，是否可以改用getApplicationContext()来作为参数

Handler相关

使用View.post()是否会有问题因为在View处于detached状态期间，post()里面的Runnable是不会被执行的。只有在此View处于attached状态时才会被执行。

如果想改Runnable每次肯定会被执行，那么应该是用Handler.post来替代

假如程序可能多次在同一个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);

其他

多思考某些情况下，某变量是否会为空而且在函数体内，处理参数前，必须加上判空语句
回调函数是否处理好回调函数很容易出问题。比如网络请求的回调，需要判断此时的Aciivity等是否还存在，再进行调用。因为异步操作回来，Activity可能就消失不存在了。而且还要对一些可能被回收的变量进行判空。
修改数据库后，是否把数据库的版本号+1

启动第三方的Activity时，是否判断了该Intent能否被解析

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

若Activity不存在，会出现ActivityNotFoundException的异常

新注册的Activity、Service或Provider，若AndroidManifest.xml中exported属性为true，要考虑是否会引发安全性问题
1
2
<activity android:name="com.inkenka.DemoActivity"
android:exported="true"/>

因为exported属性为true时，外部应用就可以直接调用起该Activity。可能导致的问题：

若外部应用直接启动详情页，从而让某些验证页面直接被绕过
若外部应用给该Activity传递乱七八糟的Intent，可能让该应用崩溃。也就是Android中的拒绝服务漏洞

除数是否做了非0判断
不要在Activity的onCreate里调用PopupWindow的showAsLoaction方法，由于Activity还没被加载完，会报错

功能完成后，自测时的检查点

思考某些情况下，某个变量是否会造成空指针问题
把手机横屏，检查布局是否有Bug
在不同分辨率的机型上，检查布局是否有Bug
切换到英文等外文字体下，检查外文是否能完整显示
从低版本升级上来，会不会有问题,比如可能会出现数据库不兼容的问题
按下Home再返回是否正常
熄灭屏幕再打开是否正常
切换成其它应用再切换回来会怎样
利用手机的开发者选项中的 “调试GPU过度绘制” ，“GPU呈现模式分析” 和 “显示FPS和功耗” 功能，看自己的新功能是否会导致过度绘制、是否会掉帧
测试看是否影响启动速度adb shell am start -W 包名/Activity
对比看APK大小是否有增大
跑1小时Monkey，测试其稳定性

转自: 良心推荐：总结Android开发中必备的代码Review清单

补充:总结工作中的Android内存泄漏问题

简单判断是否有内存泄漏

判断内存泄漏的定位的大单位是Activity。

可以通过反复进入退出一个Activity，然后用adb shell dumpsys meminfo + 包名查看虚拟机的堆是否有不断地增长

定位内存泄漏

1.使用Leak Canary

在代码上加入Leak Canary，然后不断跑Monkey或者手动反复进出不同页面。若出现内存泄漏问题，会自动导出来，生成以下页面。

2.使用DDMS导出hprof，并用MAT工具进行分析

强烈建议先跑30分钟Monkey测试
使用eclipse的ddms找到对应的进程，触发一次gc后，dump出里面的内存快照hprof文件以分析当前应用内存的堆有什么东西
使用Android SDK 里的platform-tools文件夹的 hprof-conv工具，对刚才 hprof 文件进行转换，以至于后面MAT工具能正常打开
使用MAT打开hprof文件，进入Histogram。输入自己猜测可能泄漏的Activity（项目中Activity不多时，可每个Activity都重复以下3、4、5步骤）
键该其中一项，打开菜单选择list objects ->with incoming refs将列出该类的实例
右健Path to GC Roots–>exclue all phantom/weak/soft etc. reference，找出这个实例GC后，还会存在什么对象的引用关系。

常见导致内存泄漏的几个点

生命周期的原因

比如：Activity中关联了一个生命周期超过Activity的Thread，这个Thread 若持有该Activity的引用，就会导致内存泄漏。

内部类的原因

因为内部类会隐式地持有外部类的引用，若内部类不被释放，外部类也是无法释放。常见的有内部的Listener、Callback、Handler等导致。

情景1：若外部类应该释放的时候，内部类还在执行里面的函数，会导致外部类无法释放。

情景2：若一个异步操作，会回调内部类的Listener、Callback、Handler。当外部类应该释放的时候，但是这个异步操作还存在，而这个异步操作类又持有了Listener、Callback、Handler，导致外部类无法被释放。PS：这个原因也属于生命周期的原因。

静态变量的原因

单例类里包含Activity

静态变量的类里引用到Activity

注册与反注册、打开与关闭没成对出现的原因

比如：注册广播接收器、注册观察者（典型的譬如数据库的监听）等。或者自己写的跟Activity引用有关的clear()函数没有成对出现

解决方法

解决内部类的问题（以Handler作为例子）

onDestroy时候remove所有msgActivity finish后未处理的msg是问题根源，所以清空所有未被执行的msg
1
mHandler.removeCallbacksAndMessages(null);

PS：比如Listener、Callback等其他内部类的问题，页面退出的时候，应该完成必要的清理操作，比如Cancel 请求

使用静态内部类 + weakReference 静态内部类不会保留对外部类的引用，如果一定要引用外部类，使用weakReference

static class MyHandler extends Handler {
        WeakReference<Activity > mActivityReference;
        MyHandler(Activity activity) {
            mActivityReference= new WeakReference<Activity>(activity);
        }

        @Override
        public void handleMessage(Message msg) {
            final Activity activity = mActivityReference.get();
            if (activity != null) {
                mImageView.setImageBitmap(mBitmap);
            }
        }
    }

PS:比如Listener、Callback等其他内部类的问题，也可以通过这个方法来解决