java 内存泄漏 基础知识
java 内存的分配策略
静态分配， 栈式分配，堆式分配
对应的
- 静态存储区，也叫方法区，这个内存区里 主要存放一些 静态数据，全局变量等等，这块内存，程序编译的时候已经分配好了，并且在静态存储区中存储的变量，在整个程序运行期间 都存在
- 栈区 ，方法执行的时候，方法体内的局部变量，会在栈上创建内存空间，并在方法执行结束之后，这些变量所持有的内存会被自动释放，因为栈内存分配运算，内置于处理器中，所以效率很高，但是栈区的内存空间 容量有限
- 堆区，又称为动态内存分配，通常就是我们 new 对象出来的内存，这部分内存在不使用的时候，会被 java 的垃圾回收器来负责回收。
栈区，跟堆区 ：
栈区：在方法 体内定义的基本类型的变量，和对象的引用变量都是在方法的栈内存中分配的，当一段方法中定义变量时，java就会在栈中为该变量分配内存空间，当超过这个变量的作用域时，这变量就无效了，分配给它的内存空间就被释放，这时候栈区以前占着的内存空间就会被其他方法所使用。
堆区：存放所有 由new 创建的对象，以及数组，在堆中分配的内存，将由java 的垃圾回收器来管理，其中产生的一个数组，或者对象，还可以在栈中定义一个特殊的变量，也就是通过引用变量访问堆中的东西。
java是如何管理内存的
java 内存管理，就是对象的分配和释放问题， 通过 new 为对象申请内存空间，所有的对象都是在堆中分配的，gc 自动释放。简化了程序员的工作，但是加重了java虚拟的工作，这也是java 为啥慢的原因之一。 gc 是有很大作用的，为了正确的释放对象，他必须监控每一个对象的运行状态，包括，对象的申请，引用，被引用，复制等等。
可以把对象考虑为有向图的顶点，将引用关系考虑为有向图的边，从进程顶点开始的一颗有向根树，在有向图中，根顶点可达的对象 都是有效对象，根顶点不可达的对象是可以回收的对象。
java 中的内存泄漏
内存泄漏是指无用对象 持续占有内存，或者 无用对象的内存得不到及时的释放，从而造成的内存空间的浪费称为内存泄漏
Android 中的内存泄漏
单例
不恰当的使用单例，会导致内存泄漏
public class AppManager {
//有内存泄漏的问题：
//private static AppManager instance;
// private Context context;
// private AppManager(Context context) {
// this.context = context;
// }
// public static AppManager getInstance(Context context) {
// if (instance == null) {
// instance = new AppManager(context);
// }
// return instance;
// }
// 修复内存泄漏的写法：
private static AppManager instance;
private Context context;
private AppManager(Context context) {
this.context = context.getApplicationContext();// 使用Application 的context
}
public static AppManager getInstance(Context context) {
if (instance == null) {
instance = new AppManager(context);
}
return instance;
}
}
匿名内部类
非静态内部类默认会持有外部类的引用，应该设为 静态内部类
handler
handler 是非静态内部类。
解决：把handler 设为静态内部类，同时 在handler 的内部持有activity 外部类的弱引用。
//容易造成内存泄漏的写法：
// private Handler mHandler = new Handler() {
// @Override
// public void handleMessage(Message msg) {
// //...
// }
// };
//
// @Override
// protected void onCreate(Bundle savedInstanceState) {
// super.onCreate(savedInstanceState);
// setContentView(R.layout.activity_main);
// loadData();
// }
//
// private void loadData() {
// //...request
// Message message = Message.obtain();
// mHandler.sendMessage(message);
// }
//
// static class TestResource {
// private static final String TAG = "";
// //...
// }
// 修复内存泄漏的方法：
★import java.lang.ref.WeakReference;
private MyHandler mHandler = new MyHandler(this);
private TextView mTextView ;
private static class MyHandler extends Handler {
private WeakReference<Context> reference;
public MyHandler(Context context) {
reference = new WeakReference<>(context);
}
@Override
public void handleMessage(Message msg) {
MainActivity activity = (MainActivity) reference.get();
if(activity != null){
// activity.mTextView.setText("");
}
}
}
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
loadData();
}
private void loadData() {
//...request
Message message = Message.obtain();
mHandler.sendMessage(message);
}
@Override
protected void onDestroy() {
super.onDestroy();
mHandler.removeCallbacksAndMessages(null);
}
}
避免使用 static 成员变量
如果把成员变量声明为static，那么他的生命周期，和整个App的 生命周期是一致的，如果App进程 设计上是常驻内存的，那即使App 切到后台，这部分的static 变量也是不会被释放的，按照我们现在App内存管理机制，占内存较大的后台进程，将优先被回收，所以说当你的进程被回收了之后，你所存的那些变量，那些数据是不安全的。
所以这类问题，在类设计的时候要考虑好，是不是要在初始化的时候去设为静态成员，是不是可以考虑懒加载。如果一定要使用，一定要对这些变量的生命周期做一个管理。
资源未关闭造成的内存泄漏
使用广播啊，contenProvider ，文档啊，游标，socket，Bitmap，在 生命周期销毁的时候，关闭和注销这些资源
AsyncTask 造成的内存泄漏
跟 handler 一样，需要在 声明周期销毁的时候，cancle
Bitmap c 端的内存，需要 recycle()
内存管理机制
从操作系统的角度来说，内存就是一块数据存储区域，而且属于被操作系统调度的资源。
分配内存：操作系统会为每一个进程分配一个合理的内存大小，从而保证每一个进程正常使用。
回收机制：操作系统里的内存回收机制，在内存不足的时候会有一个合理的回收再分配的作用。
Android 内存管理机制
分配机制
安卓 在为每一个进程分配内存的时候，采用了一个弹性的分配方式，也就是说：系统一开始，不会为这个APP分配太多的内存，而是为每一个APP进程分配一个小额的量，而这个小额的量是根据每一个移动设备的物理RAM尺寸大小决定的，随着App的不断运行，当前内存不足，android 就会继续为 app 分配更多的内存，当然是有限的。总之，android系统的内存分配机制，就是让更多的进程存活在内存中，当用户下一次启动该APP进程时候，就不需要重新创建进程，而是恢复已有的进程就可以了，提高了体验。回收机制
android对内存的使用，是尽最大限度地使用，这是继承Linux 的特点。
当系统发现内存不足的时候，就会杀死其他进程。为新进程分配内存
所以就有个优先级
前台进程
可见进程
服务进程 ：会开启一些服务
前三个不会被杀死
后台进程：存放在一个缓存列表中，数据结构是LRU，先杀死的处于列表的尾部
空进程 ：为了平衡系统的性能，Android不会保存这些进程。
还有个回收效益的概念，当Android系统开始杀死进程的时候，系统会判断每一个进程杀死后带来的回收效益，因为android总是倾向于 回收更多的内存，当然杀死的越少越好。
内存管理的目标
- 更少的占用内存
- 在合适的时候，合理的释放系统资源
- 在合理的生命周期中，保存或者还原重要的数据
内存优化的方法
service 完成任务后，尽量停止它。因为他是优先级比较低的服务进程，影响内存回收， 用IntentService 替代 service，因为IntentService 继承service内部开启子线程，可以做耗时操作，还可以自动退出。而不是像Service 要手动 stopService。
在Ui 不可见的时候，释放掉一些只有Ui使用的资源，有个 OnTreeMemory() 通知App回收资源
内存紧张的时候，也是用OnTreeMemory() 通知App回收资源
Bitmap 导致的，根据当前设备的分辨率来压缩bitmap，使用bitmap之后 使用recycle() 释放c内存，使用软引用，使用LRU。
使用针对内存优化过的数据结构，替代hashmap 的 SparseArray、ArrayMap，同时，尽量少用 枚举，消耗的内存是常量的两倍
避免使用依赖注入框架，使用這些框架 除了方便，也会带来一些扫描注解带来的系统资源
使用ZIP 对齐的APK
使用多进程，定位，push，webView。当然多进程 的安全，数据传输 很难的问题
内存溢出 VS 内存泄漏
内存溢出，其实就是OOM, 还是bitmap ，比如未压缩的bitmap。压缩啊，使用bitmap的属性，裁剪啊，回收啊。
内存泄漏， 就是本该被垃圾回收器 gc 的内存没有被回收。dump 分析 扯一下子。
