Android面试题（五）性能优·2

3.4.1）内存泄露

简介

即 ML （Memory Leak），指 程序在申请内存后，当该内存不需再使用 但 却无法被释放 & 归还给 程序的现象

对应用程序的影响

容易使得应用程序发生内存溢出，即 OOM

内存溢出 简介：

 

 

• 发生内存泄露的本质原因

• 常见内存泄露原因

• 1. 集合类
  2. Static关键字修饰的成员变量
  3. 非静态内部类 / 匿名类
  4. 资源对象使用后未关闭

• 优化方案

集合类内存泄漏解决：

内存泄露原因

集合类 添加元素后，仍引用着 集合元素对象，导致该集合元素对象不可被回收，从而 导致内存泄漏

 

实例演示

 

// 通过 循环申请Object 对象 & 将申请的对象逐个放入到集合List

List<Object> objectList = new ArrayList<>();

for (int i = 0; i < 10; i++) {

Object o = new Object();

objectList.add(o);

o = null;

}

// 虽释放了集合元素引用的本身：o=null）

// 但集合List 仍然引用该对象，故垃圾回收器GC 依然不可回收该对象

 

解决方案

集合类 添加集合元素对象 后，在使用后必须从集合中删除

由于1个集合中有许多元素，故最简单的方法 = 清空集合对象 & 设置为null

// 释放objectList

objectList.clear();

objectList=null;

 

Static 关键字修饰的成员变量内存泄漏解决：

储备知识

被 Static 关键字修饰的成员变量的生命周期 = 应用程序的生命周期

泄露原因

若使被 Static 关键字修饰的成员变量 引用耗费资源过多的实例（如Context），则容易出现该成员变量的生命周期 > 引用实例生命周期的情况，当引用实例需结束生命周期销毁时，会因静态变量的持有而无法被回收，从而出现内存泄露

实例讲解

public class ClassName {

// 定义1个静态变量

private static Context mContext;

//...

// 引用的是Activity的context

mContext = context;

 

// 当Activity需销毁时，由于mContext = 静态 & 生命周期 = 应用程序的生命周期，故 Activity无法被回收，从而出现内存泄露

 

}

————————————————

解决方案

尽量避免 Static 成员变量引用资源耗费过多的实例（如 Context）

若需引用 Context，则尽量使用Applicaiton的Context

 

使用 弱引用（WeakReference） 代替 强引用 持有实例

注：静态成员变量有个非常典型的例子 = 单例模式

储备知识

单例模式 由于其静态特性，其生命周期的长度 = 应用程序的生命周期

 

泄露原因

若1个对象已不需再使用 而单例对象还持有该对象的引用，那么该对象将不能被正常回收 从而 导致内存泄漏

 

实例演示

 

// 创建单例时，需传入一个Context

// 若传入的是Activity的Context，此时单例 则持有该Activity的引用

// 由于单例一直持有该Activity的引用（直到整个应用生命周期结束），即使该Activity退出，该Activity的内存也不会被回收

// 特别是一些庞大的Activity，此处非常容易导致OOM

 

public class SingleInstanceClass {

private static SingleInstanceClass instance;

private Context mContext;

private SingleInstanceClass(Context context) {

this.mContext = context; // 传递的是Activity的context

}

public SingleInstanceClass getInstance(Context context) {

if (instance == null) {

instance = new SingleInstanceClass(context);

}

return instance;

}

}

 

解决方案

单例模式引用的对象的生命周期 = 应用的生命周期

如上述实例，应传递Application的Context，因Application的生命周期 = 整个应用的生命周期

 

public class SingleInstanceClass {

private Context mContext;

private SingleInstanceClass(Context context) {

this.mContext = context.getApplicationContext(); // 传递的是Application 的context

}

 

public SingleInstanceClass getInstance(Context context) {

if (instance == null) {

instance = new SingleInstanceClass(context);

}

return instance;

}

}

 

非静态内部类 / 匿名类内存泄漏解决：

储备知识

非静态内部类 / 匿名类 默认持有 外部类的引用；而静态内部类则不会

常见情况

3种，分别是：非静态内部类的实例 = 静态、多线程、消息传递机制（Handler）

非静态内部类的实例 = 静态

泄露原因

若 非静态内部类所创建的实例 = 静态（其生命周期 = 应用的生命周期），会因 非静态内部类默认持有外部类的引用 而导致外部类无法释放，最终 造成内存泄露

即 外部类中 持有 非静态内部类的静态对象

 

实例演示

// 背景：

a. 在启动频繁的Activity中，为了避免重复创建相同的数据资源，会在Activity内部创建一个非静态内部类的单例

b. 每次启动Activity时都会使用该单例的数据

public class TestActivity extends AppCompatActivity {

// 非静态内部类的实例的引用

// 注：设置为静态

public static InnerClass innerClass = null;

@Override

protected void onCreate(@Nullable Bundle savedInstanceState) {

super.onCreate(savedInstanceState);

 

// 保证非静态内部类的实例只有1个

if (innerClass == null)

innerClass = new InnerClass();

}

// 非静态内部类的定义

private class InnerClass {

//...

}

}

 

// 造成内存泄露的原因：

// a. 当TestActivity销毁时，因非静态内部类单例的引用（innerClass）的生命周期 = 应用App的生命周期、持有外部类TestActivity的引用

// b. 故 TestActivity无法被GC回收，从而导致内存泄漏

解决方案

将非静态内部类设置为：静态内部类（静态内部类默认不持有外部类的引用）

该内部类抽取出来封装成一个单例

尽量 避免 非静态内部类所创建的实例 = 静态

若需使用Context，建议使用 Application 的 Context

多线程：AsyncTask、实现Runnable接口、继承Thread类内存泄漏解决：

储备知识

多线程的使用方法 = 非静态内部类 / 匿名类；即 线程类 属于 非静态内部类 / 匿名类

泄露原因

当 工作线程正在处理任务 & 外部类需销毁时， 由于 工作线程实例 持有外部类引用，将使得外部类无法被垃圾回收器（GC）回收，从而造成 内存泄露

多线程主要使用的是：AsyncTask、实现Runnable接口 & 继承Thread类

前3者内存泄露的原理相同，此处主要以继承Thread类 为例说明

实例演示

/**

* 方式1：新建Thread子类（内部类）

*/

public class MainActivity extends AppCompatActivity {

 

public static final String TAG = "carson：";

@Override

public void onCreate(Bundle savedInstanceState) {

super.onCreate(savedInstanceState);

setContentView(R.layout.activity_main);

 

// 通过创建的内部类 实现多线程

new MyThread().start();

 

}

// 自定义的Thread子类

private class MyThread extends Thread{

@Override

public void run() {

try {

Thread.sleep(5000);

Log.d(TAG, "执行了多线程");

} catch (InterruptedException e) {

e.printStackTrace();

}

}

}

}

 

/**

* 方式2：匿名Thread内部类

*/

public class MainActivity extends AppCompatActivity {

 

public static final String TAG = "carson：";

 

@Override

public void onCreate(Bundle savedInstanceState) {

super.onCreate(savedInstanceState);

setContentView(R.layout.activity_main);

 

// 通过匿名内部类 实现多线程

new Thread() {

@Override

public void run() {

try {

Thread.sleep(5000);

Log.d(TAG, "执行了多线程");

} catch (InterruptedException e) {

e.printStackTrace();

}

 

}

}.start();

}

}

 

/**

* 分析：内存泄露原因

*/

// 工作线程Thread类属于非静态内部类 / 匿名内部类，运行时默认持有外部类的引用

// 当工作线程运行时，若外部类MainActivity需销毁

// 由于此时工作线程类实例持有外部类的引用，将使得外部类无法被垃圾回收器（GC）回收，从而造成 内存泄露

 

解决方案

从上面可看出，造成内存泄露的原因有2个关键条件：

存在 ”工作线程实例 持有外部类引用“ 的引用关系

工作线程实例的生命周期 > 外部类的生命周期，即工作线程仍在运行 而 外部类需销毁

解决方案的思路 = 使得上述任1条件不成立 即可。

 

// 共有2个解决方案：静态内部类 & 当外部类结束生命周期时，强制结束线程

// 具体描述如下

 

/**

* 解决方式1：静态内部类

* 原理：静态内部类 不默认持有外部类的引用，从而使得 “工作线程实例 持有 外部类引用” 的引用关系 不复存在

* 具体实现：将Thread的子类设置成 静态内部类

*/

public class MainActivity extends AppCompatActivity {

 

public static final String TAG = "carson：";

@Override

public void onCreate(Bundle savedInstanceState) {

super.onCreate(savedInstanceState);

setContentView(R.layout.activity_main);

 

// 通过创建的内部类 实现多线程

new MyThread().start();

 

}

// 分析1：自定义Thread子类

// 设置为：静态内部类

private static class MyThread extends Thread{

@Override

public void run() {

try {

Thread.sleep(5000);

Log.d(TAG, "执行了多线程");

} catch (InterruptedException e) {

e.printStackTrace();

}

}

}

}

 

/**

* 解决方案2：当外部类结束生命周期时，强制结束线程

* 原理：使得 工作线程实例的生命周期 与 外部类的生命周期 同步

* 具体实现：当 外部类（此处以Activity为例） 结束生命周期时（此时系统会调用onDestroy（）），强制结束线程（调用stop（））

*/

@Override

protected void onDestroy() {

super.onDestroy();

Thread.stop();

// 外部类Activity生命周期结束时，强制结束线程

}

 

消息传递机制：Handler

解决方案1：静态内部类+弱引用

• 原理

静态内部类 不默认持有外部类的引用，从而使得 “未被处理 / 正处理的消息 -> Handler实例 -> 外部类” 的引用关系 的引用关系 不复存在。

• 具体方案

将Handler的子类设置成 静态内部类

• 同时，还可加上 使用WeakReference弱引用持有Activity实例
• 原因：弱引用的对象拥有短暂的生命周期。在垃圾回收器线程扫描时，一旦发现了只具有弱引用的对象，不管当前内存空间足够与否，都会回收它的内存

解决方案2：当外部类结束生命周期时，清空Handler内消息队列

• 原理

不仅使得 “未被处理 / 正处理的消息 -> Handler实例 -> 外部类” 的引用关系 不复存在，同时 使得 Handler的生命周期（即 消息存在的时期） 与 外部类的生命周期 同步

• 具体方案

当 外部类（此处以Activity为例） 结束生命周期时（此时系统会调用onDestroy（）），清除 Handler消息队列里的所有消息（调用removeCallbacksAndMessages(null)）

• 具体代码

@Override protected void onDestroy() { super.onDestroy(); mHandler.removeCallbacksAndMessages(null); // 外部类Activity生命周期结束时，同时清空消息队列 & 结束Handler生命周期 }

使用建议

为了保证Handler中消息队列中的所有消息都能被执行，此处推荐使用解决方案1解决内存泄露问题，即 静态内部类 + 弱引用的方式

资源对象使用后未关闭

泄露原因

对于资源的使用（如 广播BraodcastReceiver、文件流File、数据库游标Cursor、图片资源Bitmap等），若在Activity销毁时无及时关闭 / 注销这些资源，则这些资源将不会被回收，从而造成内存泄漏

解决方案

在Activity销毁时 及时关闭 / 注销资源

// 对于 广播BraodcastReceiver：注销注册

unregisterReceiver()

// 对于 文件流File：关闭流

InputStream / OutputStream.close()

// 对于数据库游标cursor：使用后关闭游标

cursor.close（）

// 对于 图片资源Bitmap：Android分配给图片的内存只有8M，若1个Bitmap对象占内存较多，当它不再被使用时，应调用recycle()回收此对象的像素所占用的内存；最后再赋为null

Bitmap.recycle()；

Bitmap = null;

// 对于动画（属性动画）

// 将动画设置成无限循环播放repeatCount = “infinite”后

// 在Activity退出时记得停止动画

总结

下面，我将用一张图总结Android中内存泄露的原因 & 解决方案

 

1. 代码优化

Android官方建议，编写高效的代码的准则如下：

• 不要做冗余的工作
• 进来避免次数过多的分配内存
• 其实还需要再添加一条准则：深入理解所用语言特性和系统平台的API，具体到Android开发，熟练掌握Java语言，并对Android SDK所提供的API了如指掌。

对常量使用static final修饰

对于基本数据类型和String类型的变量，建议使用static final修饰，因为final类型的常量会在会进入静态dex文件的与初始化部分，这是对基本数据类型和String类型常量的调用不会涉及类的初始化，而是直接调用字面量。

不要将视图控件声明为static,因为View对象会引用Activity对象,当Activity退出时其对象本身无法被销毁,会造成内存溢出

避免内部的Getters/Setters

在面向对象编程中，Getters/Setters的作用主要是对外屏蔽具体的变量定义，从而达到更好封装性。而如果是在类内部还是用Getters/Setters函数访问变量的话，会降低访问的速度。根据Android官方文档，在没有JIT（Just In Time）编译器时，直接访问变量的速度是调用Getter方法的3倍；在JIT编译时，直接访问变量的速度是调用Getter方法的7倍。当然，如果你的应用中使用了ProGuard的话，那么ProGuard会对Getters/Setters进行内联擦做，从而达到直接访问的效果。

数据类型的选择

字符串拼接用StringBuilder代替String，在非并发情况下用StringBuilder代替StringBuffer，如果你对字符串的长度有大致了解，如100字符左右，可以直接new StringBuilder(128)指定初始大小，减少空间不够时的再次分配。64位类型如long double的处理比32位如int慢，final类型存储在常量区中读取效率更高

数据结构选择

常见的数据结构选择如:

ArrayList和LinkedList 

ArrayList根据index取值更快,LinkedList更占内存、随机插入删除更快速、扩容效率更高。一般推荐ArrayList。

ArrayList、HashMap、LinkedHashMap、HashSet 

hash系列数据结构查询速度更优,ArrayList存储有序元素,HashMap为键值对数据结构,LinkedHashMap可以记住加入次序的hashMap,HashSet不允许重复元素。

HashMap、WeakHashMap 

WeakHashMap中元素可在适当时候被系统垃圾回收器自动回收,所以适合在内存紧张型中使用。

Collections.synchronizedMap和ConcurrentHashMap 

ConcurrentHashMap为细分锁,锁粒度更小,并发性能更优。Collections.synchronizedMap为对象锁,自己添加函数进行锁控制更方便。

Android也提供了一些性能更优的数据类型,如SparseArray、SparseBooleanArray、SparseIntArray、Pair 

Sparse系列的数据结构是为key为int情况的特殊处理,采用二分查找及简单的数组存储,加上不需要泛型转换的开销,相对Map来说性能更优

代码的重构

代码重构是一项持之以恒的工作，需要依靠团队中每一个成员来维护代码库的高质量，如何有效的进行代码重构，推荐阅读《重构-改善既有的代码设计》和《代码整洁之道》

1. 电量优化

• 尽量减少唤醒屏幕的次数和持续的时间 使用wakelock来处理唤醒的问题
• 某些非必须马上执行的操作例如上传歌曲 图片处理等可以等到设备处于充电状态或电量充足的时候才进行
• 触发网络请求的操作 每次都会保持无线信号保持一段时间 可以把零散的网络请求打包后进行一次操作 避免过多的无线醒后引起的电量消耗 关于网络延迟再批量处理 Android官方提供jobScheduler的api来达成
• 预取数据 批量处理 减少连接这三种方法是优化电量的网络连接方式 具体参考文章优化下载以高效地访问网络
• 除此之外 还可以压缩上传或者下载的网络数据来减少网络传输时间 从而导致减少电量使用的目的 观看网络请求发生的时间可以使用Android studio的networking traffic tool来查看
• 轮询数据访问时最耗费电量的 所以严重不建议这么做 可以使用回退机制来避免固定频率的同步请求 例如在发现返回数据相同的情况下 推迟下次的请求时间

1. 其他优化

• 减少程序安装包大小 在build.gradle文件中配置 buildTypes的minifyEnabled为true minifyEnabled为true同时起到代码混淆的作用 
• shrinkResource为true 可以帮助移除程序使用不到的代码和资源