咱们为何要优化内存
在 Android 中咱们写的 .java 文件，最终会编译成 .class 文件, class 又由类装载器加载后，在 JVM 中会造成一份描述 class 结构的元信息对象，经过该元信息对象能够知道 class 的结构信息 (构造函数、属性、方法)等。JVM 会把描述类的数据从 class 文件加载到内存，Java 有一个很好的管理内存的机制，垃圾回收机制 GC 。为何 Java 都给咱们提供了垃圾回收机制，程序有时还会致使内存泄漏，内存溢出 OOM，甚至致使程序 Crash 。接下来咱们就对实际开发中出现的这些内存问题，来进行优化。php
JAVA 虚拟机
咱们先来大概了解一下 Java 虚拟机里面运行时的数据区域有哪些，若是想深刻了解 Java 虚拟机 建议能够购买<<深刻理解 Java 虚拟机>> 或者直接点击我这里的 PDF 版本 密码: jmnf html
线程独占区
程序计数器java
- 至关于一个执行代码的指示器，用来确认下一行执行的地址
- 每一个线程都有一个
- 没有 OOM 的区
虚拟机栈android
- 咱们平时说的栈就是这块区域
- java 虚拟机规范中定义了 OutOfMemeory , stackoverflow 异常
本地方法栈面试
- java 虚拟机规范中定义了 OutOfMemory ，stackoverflow 异常
注意算法
- 在 hotspotVM 中把虚拟机栈和本地方法栈合为了一个栈区
线程共享区
方法区windows
- ClassLoader 加载类信息
- 常量、静态变量
- 编译后的代码
- 会出现 OOM
- 运行时常量池
- public static final
- 符号引用类、接口全名、方法名
java 堆 (本次须要优化的地方)设计模式
- 虚拟机能管理的最大的一块内存 GC 主战场
- 会出现 OOM
- 对象实例
- 数据的内容
JAVA GC 如何肯定内存回收
随着程序的运行，内存中的实例对象、变量等占据的内存愈来愈多，若是不及时进行回收，会下降程序运行效率，甚至引起系统异常。数组
目前虚拟机基本都是采用可达性分析算法，为何不采用引用计数算法呢？下面就说说引用计数法是若是统计全部对象的引用计数的，再对比可达性分析算法是如何解决引用计数算法的不足。下面就来看下这 2 个算法：缓存
引用计数算法
每一个对象有一个引用计数器，当对象被引用一次则计数器加一，当对象引用一次失效一次则计数器减一，对于计数器为 0 的时候就意味着是垃圾了，能够被 GC 回收。
下面经过一段代码来实际看下
public class GCTest {
private Object instace = null;
public static void onGCtest() {
//step 1
GCTest gcTest1 = new GCTest();
//step 2
GCTest gcTest2 = new GCTest();
//step 3
gcTest1.instace = gcTest2;
//step 4
gcTest2.instace = gcTest1;
//step 5
gcTest1 = null;
//step 6
gcTest2 = null;
}
public static void main(String[] arg) {
onGCtest();
}
}
复制代码
分析代码
//step 1 gcTest1 引用 + 1 = 1
//step 2 gcTest2 引用 + 1 = 1
//step 3 gcTest1 引用 + 1 = 2
//step 4 gcTest2 引用 + 1 = 2
//step 5 gcTest1 引用 - 1 = 1
//step 6 gcTest2 引用 - 1 = 1
复制代码
很明显如今 2 个对象都不能用了都为 null 了，可是 GC 确不能回收它们，由于它们自己的引用计数不为 0 。不能知足被回收的条件，尽管调用 System.gc() 也仍是不能获得回收, 这就形成了 内存泄漏 。固然，如今虚拟机基本上都不采用此方式。
可达性分析算法
从 GC Roots 做为起点开始搜索，那么整个连通图中额对象边都是活对象，对于 GC Roots 没法到达的对象便成了垃圾回收的对象，随时可能被 GC 回收。
能够做为 GC Roots 的对象
- 虚拟机栈正在运行使用的引用
- 静态属性 常量
- JNI 引用的对象
GC 是须要 2 次扫描才回收对象，因此咱们可使用 finalize 去救活丢失的引用
@Override
protected void finalize() throws Throwable {
super.finalize();
instace = this;
}
复制代码
到了这里，相信你们已经可以弄明白这 2 个算法的区别了吧？反正对于对象之间循环引用的状况，引用计数算法没法回收这 2 个对象，而可达性是从 GC Roots 开始搜索，因此可以正确的回收。
不一样引用类型的回收状态
强引用
Object strongReference = new Object()
复制代码
若是一个对象具备强引用，那垃圾回收器毫不会回收它，当内存空间不足， Java 虚拟机宁愿抛出 OOM 错误，使程序异常 Crash ,也不会靠随意回收具备强引用的对象来解决内存不足的问题.若是强引用对象再也不使用时，须要弱化从而使 GC 可以回收，须要：
strongReference = null; //等 GC 来回收
复制代码
还有一种状况，若是：
public void onStrongReference(){
Object strongReference = new Object()
}
复制代码
在 onStrongReference() 内部有一个强引用，这个引用保存在 java 栈 中，而真正的引用内容 （Object）保存在 java 堆中。当这个方法运行完成后，就会退出方法栈，则引用对象的引用数为 0 ，这个对象会被回收。
可是若是 mStrongReference 引用是全局时，就须要在不用这个对象时赋值为 null ,由于 强引用 不会被 GC 回收。
软引用 (SoftReference)
若是一个对象只具备软引用，则内存空间足够，垃圾回收器就不会回收它；若是内存空间不足了，就会回收这些对象的内存，只要垃圾回收器没有回收它，该对象就能够被程序使用。软引用可用来实现内存敏感的高速缓存。
软引用能够和一个引用队列（ReferenceQueue）联合使用，若是软引用所引用的对象被垃圾回收器回收， java 虚拟机就会把这个软引用加入到与之关联的引用队列中。
注意: 软引用对象是在 jvm 内存不够的时候才会被回收，咱们调用 System.gc() 方法只是起通知做用， JVM 何时扫描回收对象是 JVM 本身的状态决定的。就算扫描到了 str 这个对象也不会回收，只有内存不足才会回收。
弱引用 (WeakReference)
弱引用与软引用的区别在于: 只具备弱引用的对象拥有更短暂的生命周期。在垃圾回收器线程扫描它所管辖的内存区域的过程当中，一旦发现了只具备弱引用的对象，无论当前内存空间足够与否，都会回收它的内存。不过因为垃圾回收器是一个优先级很低的线程，所以不必定会很快发现那些只具备弱引用的对象。
弱引用能够和一个引用队列联合使用，若是弱引用所引用的对象被垃圾回收，Java 虚拟机就会把这个弱引用加入到与之关联的引用队列中。
可见 weakReference 对象的生命周期基本由 GC 决定，一旦 GC 线程发现了弱引用就标记下来，第二次扫描到就直接回收了。
注意这里的 referenceQueuee 是装的被回收的对象。
虚引用 (PhantomReference)
@Test
public void onPhantomReference()throws InterruptedException{
String str = new String("123456");
ReferenceQueue queue = new ReferenceQueue();
// 建立虚引用，要求必须与一个引用队列关联
PhantomReference pr = new PhantomReference(str, queue);
System.out.println("PhantomReference:" + pr.get());
System.out.printf("ReferenceQueue:" + queue.poll());
}
复制代码
虚引用顾名思义，就是形同虚设，与其余几种引用都不一样，虚引用并不会决定对象的生命周期。若是一个对象仅持有虚引用，那么它就和没有任何引用同样，在任什么时候候均可能被垃圾回收器回收。
虚引用主要用来跟踪对象被垃圾回收器回收的活动。虚引用与软引用和弱引用的一个区别在于: 虚引用必须和引用队列 (ReferenceQueue) 联合使用。当垃圾回收器准备回收一个对象时，若是发现它还有虚引用，就会在回收对象的内存以前，把这个虚引用加入到与之关联的引用队列中。
总结
| 引用类型 | 调用方式 | GC | 是否内存泄漏 |
|---|---|---|---|
| 强引用 | 直接调用 | 不回收 | 是 |
| 软引用 | .get() | 视内存状况回收 | 否 |
| 弱引用 | .get() | 回收 | 不可能 |
| 虚引用 | null | 任什么时候候均可能被回收，至关于没有引用同样 | 否 |
分析内存经常使用工具
工具不少，掌握原理方法，工具随意挑选使用。
top/procrank
meinfo
Procstats
DDMS
MAT
Finder - Activity
LeakCanary
LeakInspector
内存泄漏
产生的缘由: 一个长生命周期的对象持有一个短生命周期对象的引用，通俗点讲就是该回收的对象，由于引用问题没有被回收，最终会产生 OOM。
下面咱们来利用 Profile 来检查项目是否有内存泄漏
怎么利用 profile 来查看项目中是否有内存泄漏
-
在 AS 中项目以 profile 运行
-
在 MEMORY 界面中选择要分析的一段内存，右键 export
Allocations: 动态分配对象个数
Deallocation: 解除分配的对象个数
Total count: 对象的总数
Shalow Size: 对象自己占用的内存大小
Retained Size: GC 回收能收走的内存大小
-
转换 profile 文件格式
-
将 export 导出的 dprof 文件转换为 Mat 的 dprof 文件
-
cd /d 进入到 Android sdk/platform-tools/hprof-conv.exe
//转换命令 hprof-conv -z src des D:\Android\AndroidDeveloper-sdk\android-sdk-windows\platform-tools>hprof-conv -z D:\temp_\temp_6.hprof D:\temp_\memory6.hprod 复制代码
-
-
打开 MemoryAnalyzer.exe 点击左上角 File 菜单中的 Open Heap Dupm
-
查看内存泄漏中的 GC Roots 强引用
这里咱们得知是一个 ilsLoginListener 引用了 LoginView,咱们来看下代码最后怎么解决的。
代码中咱们找到了 LoginView 这个类，发现是一个单例中的回调引发的内存泄漏，下面怎么解决勒，请看第七小点。
-
2种解决单例中的内存泄漏
-
将引用置为 null
/** * 销毁监听 */ public void unRemoveRegisterListener(){ mMessageController.unBindListener(); } public void unBindListener(){ if (listener != null){ listener = null; } } 复制代码 -
使用弱引用
//将监听器放入弱引用中 WeakReference<IBinderServiceListener> listenerWeakReference = new WeakReference<>(listener); //从弱引用中取出回调 listenerWeakReference.get()； 复制代码
-
-
经过第七小点就能完美的解决单例中回调引发的内存泄漏。
Android 中常见的内存泄漏经典案例及解决方法
-
单例
示例 :
public class AppManager { private static AppManager sInstance; private CallBack mCallBack; private Context mContext; private AppManager(Context context) { this.mContext = context; } public static AppManager getInstance(Context context) { if (sInstance == null) { sInstance = new AppManager(context); } return sInstance; } public void addCallBack(CallBack call){ mCallBack = call； } } 复制代码-
经过上面的单列，若是 context 传入的是 Activity , Service 的 this，那么就会致使内存泄漏。
以 Activity 为例，当 Activity 调用 getInstance 传入 this ，那么 sInstance 就会持有 Activity 的引用，当 Activity 须要关闭的时候须要 回收的时候，发现 sInstance 还持有 没有用的 Activity 引用，致使 Activity 没法被 GC 回收，就会形成内存泄漏
-
addCallBack(CallBack call) 这样写看起来是没有毛病的。可是当这样调用在看一下勒。
//在 Activity 中实现单例的回调 AppManager.getInstance(getAppcationContext()).addCallBack(new CallBack(){ @Override public void onStart(){ } })； 复制代码这里的 new CallBack() 匿名内部类 默认持有外部的引用，形成 CallBack 释放不了，那么怎么解决了，请看下面解决方法
解决方法:
-
getInstance(Context context) context 都传入 Appcation 级别的 Context,或者实在是须要传入 Activity 的引用就用 WeakReference 这种形式。
-
匿名内部类建议你们单独写一个文件或者
public void addCallBack(CallBack call){ WeakReference<CallBack> mCallBack= new WeakReference<CallBack>(call)； } 复制代码
-
-
Handler
示例:
//在 Activity 中实现 Handler class MyHandler extends Handler{ private Activity m; public MyHandler(Activity activity){ m=activity; } // class..... } 复制代码这里的 MyHandler 持有 activity 的引用，当 Activity 销毁的时候，致使 GC 不会回收形成 内存泄漏。
解决方法:
1.使用静态内部类 + 弱引用 2.在 Activity onDestoty() 中处理 removeCallbacksAndMessages() @Override protected void onDestroy() { super.onDestroy(); if(null != handler){ handler.removeCallbacksAndMessages(null); handler = null; } } 复制代码 -
静态变量
示例:
public class MainActivity extends AppCompatActivity { private static Police sPolice; @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.activity_main); if (sPolice != null) { sPolice = new Police(this); } } } class Police { public Police(Activity activity) { } } 复制代码这里 Police 持有 activity 的引用，会形成 activity 得不到释放，致使内存泄漏。
解决方法:
//1. sPolice 在 onDestory（）中 sPolice = null; //2. 在 Police 构造函数中 将强引用 to 弱引用； 复制代码 -
非静态内部类
参考 第二点 Handler 的处理方式
-
匿名内部类
示例:
public class MainActivity extends AppCompatActivity { @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.activity_main); new Thread(){ @Override public void run() { super.run(); } }; } } 复制代码不少初学者都会像上面这样新建线程和异步任务，却不知这样的写法很是地不友好，这种方式新建的子线程
Thread和AsyncTask都是匿名内部类对象，默认就隐式的持有外部Activity的引用，致使Activity内存泄露。解决方法:
//静态内部类 + 弱引用 //单独写一个文件 + onDestory = null; 复制代码 -
未取消注册或回调
示例:
public class MainActivity extends AppCompatActivity { @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.activity_main); registerReceiver(mReceiver, new IntentFilter()); } private BroadcastReceiver mReceiver = new BroadcastReceiver() { @Override public void onReceive(Context context, Intent intent) { // TODO ------ } }; } 复制代码在注册观察则模式的时候，若是不及时取消也会形成内存泄露。好比使用
Retrofit + RxJava注册网络请求的观察者回调，一样做为匿名内部类持有外部引用，因此须要记得在不用或者销毁的时候取消注册。解决方法:
//Activity 中实现 onDestory（）反注册广播获得释放 @Override protected void onDestroy() { super.onDestroy(); this.unregisterReceiver(mReceiver); } 复制代码 -
定时任务
示例:
public class MainActivity extends AppCompatActivity { /**模拟计数*/ private int mCount = 1; private Timer mTimer; private TimerTask mTimerTask; @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.activity_main); init(); mTimer.schedule(mTimerTask, 1000, 1000); } private void init() { mTimer = new Timer(); mTimerTask = new TimerTask() { @Override public void run() { MainActivity.this.runOnUiThread(new Runnable() { @Override public void run() { addCount(); } }); } }; } private void addCount() { mCount += 1; } } 复制代码当咱们
Activity销毁的时，有可能Timer还在继续等待执行TimerTask，它持有Activity 的引用不能被 GC 回收，所以当咱们 Activity 销毁的时候要当即cancel掉Timer和TimerTask，以免发生内存泄漏。解决方法:
//当 Activity 关闭的时候，中止一切正在进行中的定时任务，避免形成内存泄漏。 private void stopTimer() { if (mTimer != null) { mTimer.cancel(); mTimer = null; } if (mTimerTask != null) { mTimerTask.cancel(); mTimerTask = null; } } @Override protected void onDestroy() { super.onDestroy(); stopTimer(); } 复制代码 -
资源未关闭
示例:
ArrayList,HashMap,IO,File,SqLite,Cursor 等资源用完必定要记得 clear remove 等关闭一系列对资源的操做。 复制代码解决方法:
用完即刻销毁 复制代码 -
属性动画
示例:
动画一样是一个耗时任务，好比在 Activity 中启动了属性动画 (ObjectAnimator) ，可是在销毁的时候，没有调用 cancle 方法，虽然咱们看不到动画了，可是这个动画依然会不断地播放下去，动画引用所在的控件，所在的控件引用 Activity ，这就形成 Activity 没法正常释放。所以一样要在Activity 销毁的时候 cancel 掉属性动画，避免发生内存泄漏。 复制代码解决方法:
@Override protected void onDestroy() { super.onDestroy(); //当关闭 Activity 的时候记得关闭动画的操做 mAnimator.cancel(); } 复制代码 -
Android 源码或者第三方 SDK
示例:
//若是在开发调试中碰见 Android 源码或者 第三方 SDK 持有了咱们当前的 Activity 或者其它类，那么如今怎么办了。 复制代码解决方法:
//当前是经过 Java 中的反射找到某个类或者成员，来进行手动 = null 的操做。 复制代码
内存抖动
什么是内存抖动
内存频繁的分配与回收,(分配速度大于回收速度时) 最终产生 OOM 。
也许下面的录屏更能解释什么是内存抖动
能够看出当我点击了一下 Button 内存就频繁的建立并回收（注意看垃圾桶）。
那么咱们找出代码中具体那一块出现问题了勒，请看下面一段录屏
mButton.setOnClickListener(new View.OnClickListener() {
@Override
public void onClick(View v) {
imPrettySureSortingIsFree();
}
});
/** * 排序后打印二维数组，一行行打印 */
public void imPrettySureSortingIsFree() {
int dimension = 300;
int[][] lotsOfInts = new int[dimension][dimension];
Random randomGenerator = new Random();
for (int i = 0; i < lotsOfInts.length; i++) {
for (int j = 0; j < lotsOfInts[i].length; j++) {
lotsOfInts[i][j] = randomGenerator.nextInt();
}
}
for (int i = 0; i < lotsOfInts.length; i++) {
String rowAsStr = "";
//排序
int[] sorted = getSorted(lotsOfInts[i]);
//拼接打印
for (int j = 0; j < lotsOfInts[i].length; j++) {
rowAsStr += sorted[j];
if (j < (lotsOfInts[i].length - 1)) {
rowAsStr += ", ";
}
}
Log.i("ricky", "Row " + i + ": " + rowAsStr);
}
}
复制代码
最后咱们以后是 onClick 中的 imPrettySureSortingIsFree() 函数里面的 rowAsStr += sorted[j]; 字符串拼接形成的 内存抖动 ，由于每次拼接一个 String 都会申请一块新的堆内存，那么怎么解决这个频繁开辟内存的问题了。其实在 Java 中有 2 个更好的 API 对 String 的操做很友好，相信应该有人猜到了吧。没错就是将 此处的 String 换成 StringBuffer 或者 StringBuilder，就能很完美的解决字符串拼接形成的内存抖动问题。
修改后
/** * 打印二维数组，一行行打印 */
public void imPrettySureSortingIsFree() {
int dimension = 300;
int[][] lotsOfInts = new int[dimension][dimension];
Random randomGenerator = new Random();
for(int i = 0; i < lotsOfInts.length; i++) {
for (int j = 0; j < lotsOfInts[i].length; j++) {
lotsOfInts[i][j] = randomGenerator.nextInt();
}
}
// 使用StringBuilder完成输出，咱们只须要建立一个字符串便可， 不须要浪费过多的内存
StringBuilder sb = new StringBuilder();
String rowAsStr = "";
for(int i = 0; i < lotsOfInts.length; i++) {
// 清除上一行
sb.delete(0, rowAsStr.length());
//排序
int[] sorted = getSorted(lotsOfInts[i]);
//拼接打印
for (int j = 0; j < lotsOfInts[i].length; j++) {
sb.append(sorted[j]);
if(j < (lotsOfInts[i].length - 1)){
sb.append(", ");
}
}
rowAsStr = sb.toString();
Log.i("jason", "Row " + i + ": " + rowAsStr);
}
}
复制代码
这里能够看见没有垃圾桶出现，说明内存抖动解决了。
注意: 实际开发中若是在 LogCat 中发现有这些 Log 说明也发生了 内存抖动 (Log 中出现 concurrent copying GC freed ....)
回收算法
ps:我以为这个只是为了应付面试，那么能够参考这里，我也只了解概念这里就不用在多写了，点击看这个帖子吧
标记清除算法 Mark-Sweep
复制算法 Copying
标记压缩算法 Mark-Compact
分代收集算法
总结 (只要养成这样的习惯，至少能够避免 90 % 以上不会形成内存异常)
-
数据类型: 不要使用比需求更占用空间的基本数据类型
-
循环尽可能用 foreach ,少用 iterator, 自动装箱也尽可能少用
-
数据结构与算法的解度处理 (数组，链表，栈树，树，图)
- 数据量千级之内可使用 Sparse 数组 (Key为整数)，ArrayMap (Key 为对象) 虽然性能不如 HashMap ，但节约内存。
-
枚举优化
缺点:
- 每个枚举值都是一个单例对象,在使用它时会增长额外的内存消耗,因此枚举相比与 Integer 和 String 会占用更多的内存
- 较多的使用 Enum 会增长 DEX 文件的大小,会形成运行时更多的 IO 开销,使咱们的应用须要更多的空间
- 特别是分 Dex 多的大型 APP，枚举的初始化很容易致使 ANR
优化后的代码:能够直接限定传入的参数个数
public class SHAPE { public static final int TYPE_0=0; public static final int TYPE_1=1; public static final int TYPE_2=2; public static final int TYPE_3=3; @IntDef(flag=true,value={TYPE_0,TYPE_1,TYPE_2,TYPE_3}) @Target({ElementType.PARAMETER,ElementType.METHOD,ElementType.FIELD}) @Retention(RetentionPolicy.SOURCE) public @interface Model{ } private @Model int value=TYPE_0; public void setShape(@Model int value){ this.value=value; } @Model public int getShape(){ return this.value; } } 复制代码 -
static , static final 的问题
- static 会由编译器调用 clinit 方法进行初始化
- static final 不须要进行初始化工做，打包在 dex 文件中能够直接调用，并不会在类初始化申请内存
基本数据类型的成员，能够全写成 static final
-
字符串的拼接尽可能少用 +=
-
重复申请内存问题
- 同一个方法屡次调用，如递归函数 ，回调函数中 new 对象
- 不要在 onMeause() onLayout() ,onDraw() 中去刷新UI（requestLayout）
-
避免 GC 回收未来要从新使用的对象 (内存设计模式对象池 + LRU 算法)
-
Activity 组件泄漏
- 非业务须要不要把 activity 的上下文作参数传递，能够传递 application 的上下文
- 非静态内部类和匿名内部内会持有 activity 引用（静态内部类 或者 单独写文件）
- 单例模式中回调持有 activity 引用（弱引用）
- handler.postDelayed() 问题
- 若是开启的线程须要传入参数，用弱引接收可解决问题
- handler 记得清除 removeCallbacksAndMessages(null)
-
Service 耗时操做尽可能使用 IntentService,而不是 Service