Android 基础之性能优化(一)

作者: Kevin_小飞象 | 来源:发表于2019-02-21 11:15 被阅读1次

快（流畅的体验）
稳（稳定）
省（省电/流量）
小（安装包小）
这四点很形象的代表了性能的四个方面，同时也让我们知道我们 App 现在是否是款性能良好的 APP，如果有一项不达标，那么说明我们的应用有待优化。

布局优化

屏幕上的某个像素在同一帧的时间内被绘制了多次。在多层次的 UI 结构里面，如果不可见的 UI 也在做绘制的操作，这就会导致某些像素区域被绘制了多次。这就浪费大量的 CPU 以及 GPU 资源。

如果父控件有颜色，也是自己需要的颜色，那么就不必在子控件加背景颜色
如果每个自控件的颜色不太一样，而且可以完全覆盖父控件，那么就不需要再父控件上加背景颜色
尽量减少不必要的嵌套
能用LinearLayout和FrameLayout，就不要用RelativeLayout，因为RelativeLayout控件相对比较复杂，测绘也想要耗时。
使用 include 和 merge 增加复用，减少层级
ViewStub 按需加载，更加轻便
复杂界面可选择 ConstraintLayout（约束布局），可有效减少层级

参考：那些 Android 程序员必会的视图优化策略

绘制优化

View的绘制频率保证60fps是最佳的，这就要求每帧绘制时间不超过16ms(16ms = 1000/60)，虽然程序很难保证16ms这个时间，但是尽量降低onDraw方法中的复杂度总是切实有效的。

onDraw 中不要创建新的局部对象
onDraw 方法中不要做耗时的任务

内存优化

内存泄露，即Memory Leak，指程序中不再使用到的对象因某种原因从而无法被 GC 正常回收。发生内存泄露，会导致一些不再使用到的对象没有及时释放，这些对象占用了宝贵的内存空间，很容易导致后续需要分配内存的时候，内存空间不足而出现 OOM（内存溢出）。无用对象占据的内存空间越多，那么可用的空闲空间也就越少，GC 就会更容易被触发，GC 进行时会停止其他线程的工作，因此有可能会造成界面卡顿等情况。

那么什么情况下会出现这样的对象呢？
基本可以分为以下四大类：
1、集合类泄漏
说明：集合类添加元素后，将会持有元素对象的引用，导致该元素对象不能被垃圾回收，从而发生内存泄漏。
举例：

 List<Object> objectList = new ArrayList<>();
        for (int i = 0; i < 10; i++) {
            Object o = new Object();
            objectList.add(o);
            o = null;
        }

解决方法：

清空集合对象

objectList.clear();
objectList=null;

** 2、单例/静态变量造成的内存泄漏 **
说明：静态变量的生命周期跟整个程序的生命周期一致。只要静态变量没有被销毁也没有置null，其对象就一直被保持引用，也就不会被垃圾回收,从而出现内存泄露。

举例：

public class SingleInstance {

   private static SingleInstance mInstance;
   private Context mContext;

   private SingleInstance(Context context){
       this.mContext = context;
   }

   public static SingleInstance newInstance(Context context){
       if(mInstance == null){
           mInstance = new SingleInstance(context);
       }
       return sInstance;
   }
}

解决方案:

针对静态变量
在不用静态变量时置为空
针对Context
如果用到Context，尽量去使用Applicaiton的Context，避免直接传递Activity
针对Activity
若一定要使用Activity，建议使用弱引用或者软引入来代替强引用。

public class SingleInstance {

    private static SingleInstance mInstance;
    private Context mContext;

    private SingleInstance(Context context){
        this.mContext = context.getApplicationContext();
    }

    public static SingleInstance newInstance(Context context){
        if(mInstance == null){
            mInstance = new SingleInstance(context);
        }
        return sInstance;
    }
}

3、匿名内部类/非静态内部类
说明：非静态内部类（匿名类）默认就持有外部类的引用，当非静态内部类（匿名类）对象的生命周期比外部类对象的生命周期长时，就会导致内存泄露。

3.1 Handler内存泄露
如果Handler中有延迟的任务或者是等待执行的任务队列过长，都有可能因为Handler继续执行而导致Activity发生泄漏。

1.首先，非静态的Handler类会默认持有外部类的引用，包含Activity等。
2.然后，还未处理完的消息（Message）中会持有Handler的引用。
3.还未处理完的消息会处于消息队列中，即消息队列MessageQueue会持有Message的引用。
4.消息队列MessageQueue位于Looper中，Looper的生命周期跟应用一致。

因此，此时的引用关系链是Looper -> MessageQueue -> Message -> Handler -> Activity。所以，这时退出Activity的话，由于存在上述的引用关系，垃圾回收器将无法回收Activity，从而造成内存泄漏。

解决方法：

静态内部类默认不持有外部类的引用,所以改成静态内部类即可。同时，这里采用弱引用来持有Activity的引用。
Activity退出时，移除所有信息
移除信息后，Handler将会跟Activity生命周期同步。

3.2 多线程引起的内存泄露
举例：

new Thread(new Runnable() {
            @Override
            public void run() {
              ...
            }
        }).start();

解决方法：

静态内部类不持有外部类的引用
Activity退出时，结束线程
同样，这里也是让线程的生命周期跟Activity一致。

4、资源未关闭造成的内存泄漏
说明：一些资源对象需要在不再使用的时候主动去关闭或者注销掉，否则的话，他们不会被垃圾回收，从而造成内存泄露。

1.注销广播
如果广播在Activity销毁后不取消注册，那么这个广播会一直存在系统中，由于广播持有了Activity的引用，因此会导致内存泄露。
2.关闭输入输出流等
在使用IO、File流等资源时要及时关闭。这些资源在进行读写操作时通常都使用了缓冲，如果不及时关闭，这些缓冲对象就会一直被占用而得不到释放，以致发生内存泄露。因此我们在不需要使用它们的时候就应该及时关闭，以便缓冲能得到释放，从而避免内存泄露。
3.回收Bitmap
Bitmap对象比较占内存，当它不再被使用的时候，最好调用Bitmap.recycle()方法主动进行回收。
4.停止动画
属性动画中有一类无限动画，如果Activity退出时不停止动画的话，动画会一直执行下去。因为动画会持有View的引用，View又持有Activity,最终Activity就不能给回收掉。只要我们在Activity退出把动画停掉即可。

内存泄露检测工具

lint

lint是一个静态代码分析工具，同样也可以用来检测部分会出现内存泄露的代码，平时写码注意lint飘出来的各种黄色警告即可。

leakcanary

leakcanary是square开源的一个库，能够自动检测发现内存泄露，其使用也很简单：
在build.gradle中添加依赖：

dependencies {
  debugImplementation 'com.squareup.leakcanary:leakcanary-android:1.6.1'
  releaseImplementation 'com.squareup.leakcanary:leakcanary-android-no-op:1.6.1'

  //可选项，如果使用了support包中的fragments
  debugImplementation 'com.squareup.leakcanary:leakcanary-support-fragment:1.6.1'
}

如果遇到下面这个问题：
Failed to resolve: com.squareup.leakcanary:leakcanary-android
根目录下的build.gradle添加mavenCentral()即可，如下：

allprojects {
    repositories {
        google()
        jcenter()
        mavenCentral()
    }
}

然后在自定义的Application中调用以下代码就可以了。

public class MyApplication extends Application {
    @Override
    public void onCreate() {
        super.onCreate();
        if (LeakCanary.isInAnalyzerProcess(this)) {
            return;
        }
        LeakCanary.install(this);

        //正常初始化代码
    }
}

举例：

public class MainActivity extends Activity {

    public static Context sContext;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        sContext = this;
    }
}

如果检测到有内存泄漏，通知栏会有提示，点击通知栏或者点击Leaks那个图标，可以得到内存泄露的信息，如下图所示，然后就可以知道是哪里出现了内存泄漏。

leakcanary

Memory Profiler

Memory Profiler 是 Android Profiler 中的一个组件，可以帮助你分析应用卡顿，崩溃和内存泄露等等问题。

打开 Memory Profiler后即可看到一个类似下图的视图。

memory-profiler

上面的红色数字含义如下：

1.用于强制执行垃圾回收事件的按钮。
2.用于捕获堆转储的按钮。
3.用于记录内存分配情况的按钮。 此按钮仅在连接至运行 Android 7.1 或更低版本的设备时才会显示。
4.用于放大/缩小/还原时间线的按钮。
5.用于跳转至实时内存数据的按钮。
6.Event 时间线，其显示 Activity 状态、用户输入 Event 和屏幕旋转 Event。
7.内存使用量时间线，其包含以下内容：
* 一个显示每个内存类别使用多少内存的堆叠图表，如左侧的 y 轴以及顶部的彩色键所示。
* 虚线表示分配的对象数，如右侧的 y 轴所示。
* 用于表示每个垃圾回收事件的图标。

如何使用Memory Profiler分析内存泄露呢？按以下步骤来即可：
1.使用Memory Profiler监听要分析的应用进程
2.旋转几次要分析的Activity。（这是因为旋转Activity后会重新创建）
3.点击捕获堆转储按钮去捕获堆转储
4.在捕获结果中搜索要分析的类。（这里是MainActivity）
5.点击要分析的类，右边会显示这个类创建对象的数量。

MAT(Memory Analysis Tools)

一个Eclipse的Java Heap内存分析工具,使用Android Studio进行开发的需要另外单独下载它。关于MAT的使用，可以查看《Android开发艺术探索》上面的介绍，也可以网上查看相关资料。这里就不细说了。

面试题

内存泄露的场景有哪些？内存泄漏分析工具使用方法？
参考回答：
常见的内存泄露有：

单例模式引起的内存泄露。
静态变量导致的内存泄露。
非静态内部类引起的内存泄露。
使用资源时，未及时关闭引起内存泄露。
使用属性动画引起的内存泄露。
Webview导致的内存泄露。
而对于内存泄露的检测，常用的工具有 LeakCanary、MAT（Memory Analyer Tools）、Android Studio自带的Profiler。

Android 基础之性能优化(一)

布局优化

绘制优化

内存优化

内存泄露检测工具

lint

leakcanary

Memory Profiler

MAT(Memory Analysis Tools)

面试题

相关文章

网友评论

延伸阅读

深度阅读

栏目导航

热点阅读

Android 基础