Android内存
在Android中，一台Android的物理内存是固定的，所以对于一个app来说，系统会根据系统的版本(如 API 的不同) 和设备的不同，还有手机厂商的内存策略来为每一个app分配一个固定的初始内存，这里所说的初始内存，不一定是固定的，尤其是在一些新的机型上，内存的动态分配策略更加智能。华为MATE10等一众机型采用了新的AI 和算法来动态的为app扩充内存。同样的，在app没有达到一定的程度时，可能也涉及不到内存的问题，随着设备的越来越强大，硬件的性能越来越过剩。可能在一定的时间内app的内存问题也不是很明显。但是处理内存和优化性能对于一个Android程序员来说应该是核心技能，所以彻底的了解内存泄露的原因以及知晓内存优化的方式就变的很重要。
Android中的内存泄露
由于开发语言目前为Java(Kotlin感觉差不多)，Java对内存的控制不如C/C++精准。有时候会导致内存释放的不及时。就会产生内存的泄露问题。
在Java以及Android中主要的体现就是 当一个对象已经不需要再使用了，本该被回收时，而有另外一个正在使用的对象正在持有该对象的引用。从而就会导致对象不能被回收。停留在堆内存中，就产生了内存的泄露
内存分配的策略
想要了解内存的泄露就需要先了解内存的分配策略，以Java情况来说
静态的
- 静态的存储区：内存在程序编译的时候就已经分配好，这块的内存在程序整个运行的期间都一直存在。主要存放静态数据、全局的static数据和一些常量。
栈式的
- 栈是一块连续的内存区域，大小是由操作系统决定的。
- 在执行函数(方法)时，函数一些内部变量的存储都可以放在栈上面创建。函数执行结束的时候这些存储单元被自动释放掉。(方法的作用域)
- 栈内存包括分配的运算速度很快，因为内置在处理器里面，但是容量有限
- 栈的结构是先进后出，进出不会产生碎片，运行效率高且稳定
堆式的
- 堆是不连续的内存区域。空间比较灵活，空间特别大。
- 动态内存分配。可以用new 来申请分配内存。在C/C++中需要自己负责释放。而在Java中直接依赖GC机制来进行内存的释放，相比于C/C++的掌控一切的方式，所以对于Java来说就需要在编程的时候考虑内存回收的问题。
- 堆管理起来比较麻烦，频繁的new/remove会造成大量的内存碎片，这样就会慢慢导致效率低下。
我们讨论的内存泄露的问题，主要是讨论堆内存的问题，堆存放的就是引用指向的对象实体
内存对象有关的Java类
有时候需要用到的引用相关的Java类，在此只是总结记录并不是记录解决方案。
- StrongReference 强引用
回收时机：从不回收 使用场景：对象的一般保存 生命周期：JVM停止的时候才会终止 - SoftReference 软引用
回收时机：当内存不足的时候，使用场景：SoftReference结合ReferenceQueue构造有效期短。生命周期：内存不足时终止 - WeakReference 弱引用
回收时机：在垃圾回收的时候，使用场景：同软引用。生命周期：在JavaGC后终止 - PhatomReference 虚引用
回收时机：在垃圾回收的时候：使用场景：和ReferenceQueue 来跟踪对象被垃圾回收期回收的活动。生命周期：GC后终止
内存泄露的处理以及内存的优化
内存泄露的定位和查找一般都是一件很繁琐的事情，因为大量的引用对象占用的着内存，越复杂的程序中的引用树就越冗长。，所以我们在定位内存泄露的时候所使用的方法也有很多，也有很多工具能够让我们去使用。下面结合工作中遇到的情况和经验，整理一下用过的内存泄露的定位方案和解决办法。
分析内存泄露
- 分析内存泄露可以使用工具有两个，个人觉得第二个比较好用
-
AndroidStudio 自带的Android Monitor 在新版本Android Studio上叫做Android Profiler
AndroidStudio在2.2版本后增加了对设备信息的支持，可以通过Monitor获取更多的设备信息，其中，可以通过Monitor来查看当前运行的app进程的内存实时情况以及CPU、网络、GPU的情况
Android Profile
通过这个软件可以比较清晰的看到对象引用的关系、占用了多少的内存、有多少对象持有引用等。都可以看到。还可以直接看到详情信息。对于分析内存问题比较直观明了。
-
MAT memory analyzer
是Eclipse的一个插件工具，用于查看Java的内存溢出、内存泄露等情况。也有独立的版本。
MAT
这个工具可以很清晰的看到Heap Dump等视图。
定位分析内存泄露主要就是靠工具，查找对象间的互相引用关系，然后一个个的分析，查找可能造成内存泄露的对象。依据 对象的生命周期是否一致，可以通过内存切片的快照。如果生命周期一致，进一步查看引用代码。
由于内存泄露是一个相对复杂的问题，情况比较多，个人经验有限。仅仅介绍所用过的工具。并在下方给出一个比较典型的案例。更多的情况以后会去详细开篇总结
处理内存泄露。
处理内存泄露，需要再定位泄露后进一步的查看相关对象定义的代码。找出有问题的代码，修改代码解决内存的泄露问题
代码优化(案例)
我们在开发Android项目中，经常会写一些工具类来进行工具的封装与开发。而为了程序的健壮，我们还会使用一些设计模式来更好的设计我们的工具类，例如：观察者模式，单例模式等。例如我们在开发中常写的CommonUtils,一般会写成下面这个样子
public class CommonUtils{
private static CommonUtils instance = null;
//Single 单例构造
public static CommonUtils getInstance(Context context){
if (instance == null){
instance = new CommonUtils(context);
}
return instance;
}
//一些工具方法
...
}
在这个CommonUtils中，我们使用了单例的构造方式，使得每次使用的CommonUtils都是同一个CommonUtils，一般都会传入上下文环境Context.我们在Activity中使用的时候调用方式是这样子的
public class DemoActivity extends Activity{
public void onCreate(Bundle bundle){
super.onCreate(bundle);
CommonUtils comm = CommonUtils.getInstance(this);
comm.xxxxx()
}
}
但是这种方式，存在内存泄露的问题。结合Android Monitor 我们发现 再每次屏幕旋转后，内存都会增加。而从引用树中我们看到有两个Activity的引用在占用。说明持有Activity的引用没有办法被垃圾回收GC，知道了问题我们可以分析一下原因。原来，在屏幕旋转后，Activity会被回收并重新创建。而重新创建后又会重新实例化我们写的CommonUtils工具类，又因为CommonUtils是单例的 只会返回已经存在的对象，而这个存在的对象所构造的时候是以未被回收的Activity创建的，也就是说在CommonUtils中持有DemoActivity的引用从从而导致了Activity无法被垃圾回收器回收。造成了内存泄露。
这种情况比较简单，只作为说明问题与解决方法来说。所以，我们只需要将构造CommonUtils的上下文对象改为全局的Application的上下文对象Context就可以避免这种情况下的内存泄漏
CommonUtils.getInstance(this.getApplicationContext());
上面的这个案例虽然很简单，但是很明显的说明了内存泄露的问题以及排查和解决方式。
解决方式整理
如何找到项目中存在的内存泄露的这些地方呢？
-
1.确定是否存在内存泄露
- 1 Android Monitors的内存分析
最直观的看内存增长情况，知道该动作是否发生内存泄露。
动作发生之前：GC完后内存1.4M; 动作发生之后：GC完后内存1.6M - 2 使用MAT内存分析工具
MAT分析heap的总内存占用大小来初步判断是否存在泄露
Heap视图中有一个Type叫做data object，即数据对象，也就是我们的程序中大量存在的类类型的对象。
在data object一行中有一列是“Total Size”，其值就是当前进程中所有Java数据对象的内存总量，
一般情况下，这个值的大小决定了是否会有内存泄漏。
我们反复执行某一个操作并同时执行GC排除可以回收掉的内存，注意观察data object的Total Size值，
正常情况下Total Size值都会稳定在一个有限的范围内，也就是说由于程序中的的代码良好，没有造成对象不被垃圾回收的情况。
反之如果代码中存在没有释放对象引用的情况，随着操作次数的增多Total Size的值会越来越大。
那么这里就已经初步判断这个操作导致了内存泄露的情况。
- 1 Android Monitors的内存分析
2.先找怀疑对象(哪些对象属于泄露的)
MAT对比操作前后的hprof来定位内存泄露是泄露了什么数据对象。（这样做可以排除一些对象，不用后面去查看所有被引用的对象是否是嫌疑）
快速定位到操作前后所持有的对象哪些是增加了(GC后还是比之前多出来的对象就可能是泄露对象嫌疑犯)
技巧：Histogram中还可以对对象进行Group，比如选择Group By Package更方便查看自己Package中的对象信息。-
- MAT分析hprof来定位内存泄露的原因所在。(哪个对象持有了上面怀疑出来的发生泄露的对象)
- 1Dump出内存泄露“当时”的内存镜像hprof，分析怀疑泄露的类；
- 2把上面2得出的这些嫌疑犯一个一个排查个遍。步骤：
- 1)进入Histogram，过滤出某一个嫌疑对象类
- 2)然后分析持有此类对象引用的外部对象（在该类上面点击右键List Objects--->with incoming references）
- 3)再过滤掉一些弱引用、软引用、虚引用，因为它们迟早可以被GC干掉不属于内存泄露
(在类上面点击右键Merge Shortest Paths to GC Roots--->exclude all phantom/weak/soft etc.references) - 4)逐个分析每个对象的GC路径是否正常
此时就要进入代码分析此时这个对象的引用持有是否合理，这就要考经验和体力了！
在开发Android App中 见过的内存泄露情况
1.静态变量引起的内存泄露
当调用getInstance时，如果传入的context是Activity的context。只要这个单利没有被释放，那么这个Activity也不会被释放一直到进程退出才会释放。
public class CommUtil {
private static CommUtil instance;
private Context context;
private CommUtil(Context context){
this.context = context;
}
public static CommUtil getInstance(Context mcontext){
if(instance == null){
instance = new CommUtil(mcontext);
}
// else{
// instance.setContext(mcontext);
// }
return instance;
}
2.非静态内部类引起内存泄露
(包括匿名内部类)
错误的示范：
public void loadData(){//隐士持有MainActivity实例。MainActivity.this.a
new Thread(new Runnable() {
@Override
public void run() {
while(true){
try {
//int b=a;
Thread.sleep(1000);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}
}).start();
}
解决方案：
将非静态内部类修改为静态内部类。
（静态内部类不会隐士持有外部类）
当使用软引用或者弱引用的时候，MainActivity难道很容易或者可以被GC回收吗？》
GC回收的机制是什么？当MainActivity不被任何的对象引用。
虽然Handler里面用的是软引用/弱引用，但是并不意味着不存在其他的对象引用该MainActivity。
我连MainActivity都被回收了，那他里面的Handler还玩个屁。
3.不需要用的监听未移除会发生内存泄露
例子1：
// tv.setOnClickListener();//监听执行完回收对象
//add监听，放到集合里面
tv.getViewTreeObserver().addOnWindowFocusChangeListener(new ViewTreeObserver.OnWindowFocusChangeListener() {
@Override
public void onWindowFocusChanged(boolean b) {
//监听view的加载，view加载出来的时候，计算他的宽高等。
//计算完后，一定要移除这个监听
tv.getViewTreeObserver().removeOnWindowFocusChangeListener(this);
}
});
- 例子2：
SensorManager sensorManager = getSystemService(SENSOR_SERVICE);
Sensor sensor = sensorManager.getDefaultSensor(Sensor.TYPE_ALL);
sensorManager.registerListener(this,sensor,SensorManager.SENSOR_DELAY_FASTEST);
//不需要用的时候记得移除监听
sensorManager.unregisterListener(listener);
4.资源未关闭引起的内存泄露情况
比如：BroadCastReceiver、Cursor、Bitmap、IO流、自定义属性attribute
attr.recycle()回收。
当不需要使用的时候，要记得及时释放资源。否则就会内存泄露。
5.无限循环动画
没有在onDestroy中停止动画，否则Activity就会变成泄露对象。
比如：轮播图效果。
