Android编程开发内存优化问题解析
在讲到内存优化方案之前，先来介绍下java的内存分配。
内存分配一、java的内存分配主要包括以下几个区域：
1、寄存器(register):最快的存储区，由编译器根据需要进行分配，我们的程序中无法控制。
2、栈(stack):位于通用RAM中，创建程序时候，JAVA编译器必须知道存储在栈内所有数据的确切大小和生命周期，因为它必须生成相应的代码，效率高，但是分配的内存容量有限。存放基本类型的变量数据和对象的引用，但对象本身不存放在栈中，而是存放在堆(new出来的对象)或者常量池中(对象可以在常量池里、字符串常量对象存放在常量池中) 。
3、堆(heap):一种通用性的内存池(也存在于RAM中)，用于存放所以的JAVA对象(new出来的对象)。堆不同于栈的好处是：编译器不需要知道要从堆里分配多少存储区域，也不必知道存储的数据在堆里存活多长时间。因此，在堆里分配存储有很大的灵活性。当你需要创建一个对象的时候，只需要new写一行简单的代码，当执行这行代码时，会自动在堆里进行存储分配。当然，为这种灵活性必须要付出相应的代码。用堆进行存储分配比用堆栈进行存储存储需要更多的时间。堆中的对象的由垃圾回收器负责回收(GC)，因此大小和生命周期不确定。
4、静态存储(static storage):这里的“静态”是指“在固定的位置”。静态存储里存放程序运行时一直存在的数据。你可用关键字static来标识一个对象的特定元素是静态的，但JAVA对象本身从来不会存放在静态存储空间里。一般情况下,如果有些代码必须在项目启动的时候就执行的时候,需要使用静态代码块,这种代码是主动执行的;需要在项目启动的时候就初始化,在不创建对象的情况下,其他程序来调用的时候,需要使用静态方法,这种代码是被动执行的. 静态方法在类加载的时候就已经加载了。
5、常量存储(constant storage):常量值通常直接存放在程序代码内部，这样做是安全的，因为它们永远不会被改变。有时，在嵌入式系统中，常量本身会和其他部分分割离开，所以在这种情况下，可以选择将其放在ROM中 ,存放字符串常量和基本类型常量(public static final)。
6、非RAM:硬盘等永久存储空间。
二、存储速度
寄存器 >栈?> 堆?> 其它
三、主要讨论
这里我们主要关心栈，堆和常量池，对于栈和常量池中的对象可以共享，对于堆中的对象不可以共享。
栈中的数据大小和生命周期是可以确定的，当没有引用指向数据时，这个数据就会消失。堆中的对象的由垃圾回收器负责回收，因此大小和生命周期不需要确定，具有很大的灵活性。?
对于字符串：其对象的引用都是存储在栈中的，如果是编译期已经创建好(直接用双引号定义的)的就存储在常量池中，如果是运行期（new出来的）才能确定的就存储在堆中。对于equals相等的字符串，在常量池中永远只有一份，在堆中有多份。?如以下代码：
Java代码
String s1 = "china";
String s2 = "china";
String s3 = "china";
String ss1 = new String("china");
String ss2 = new String("china");
String ss3 = new String("china");
这里解释一下黄色这3个箭头，对于通过new产生一个字符串（假设为”china”）时，会先去常量池中查找是否已经有了”china”对象，如果没有则在常量池中创建一个此字符串对象，然后堆中再创建一个常量池中此”china”对象的拷贝对象。这也就是有道面试题：String s = new String(“xyz”);产生几个对象？一个或两个，如果常量池中原来没有”xyz”,就是两个。
对于基础类型的变量和常量：变量和引用存储在栈中，常量存储在常量池中。?
如以下代码：
Java代码
int i1 = 9; int i2 = 9; int i3 = 9; public static final int INT1 = 9; public static final int INT2 = 9; public static final int INT3 = 9;
对于成员变量和局部变量：成员变量就是方法外部，类的内部定义的变量；局部变量就是方法或语句块内部定义的变量。局部变量必须初始化。?
形式参数是局部变量，局部变量的数据存在于栈内存中。栈内存中的局部变量随着方法的消失而消失。?
成员变量存储在堆中的对象里面，由垃圾回收器负责回收。?
如以下代码：
Java代码
class BirthDate {
private int day;
private int month;
private int year;
public BirthDate(int d, int m, int y) {
day = d;
month = m;
year = y;
}
省略get,set方法………
}
public class Test{
public static void main(String args[]){
int date = 9;
Test test = new Test();
test.change(date);
BirthDate d1= new BirthDate(7,7,1970);
}
public void change1(int i){
i = 1234;
}
}
对于以上这段代码，date为局部变量，i,d,m,y都是形参为局部变量，day，month，year为成员变量。下面分析一下代码执行时候的变化：?
1. main方法开始执行：int date = 9;?
date局部变量，基础类型，引用和值都存在栈中。?
2. Test test = new Test();?
test为对象引用，存在栈中，对象(new Test())存在堆中。?
3. test.change(date);?
i为局部变量，引用和值存在栈中。当方法change执行完成后，i就会从栈中消失。?
4. BirthDate d1= new BirthDate(7,7,1970);??
d1 为对象引用，存在栈中，对象(new BirthDate())存在堆中，其中d，m，y为局部变量存储在栈中，且它们的类型为基础类型，因此它们的数据也存储在栈中。 day,month,year为成员变量，它们存储在堆中(new BirthDate()里面)。当BirthDate构造方法执行完之后，d,m,y将从栈中消失。?
5.main方法执行完之后，date变量，test，d1引用将从栈中消失，new Test(),new BirthDate()将等待垃圾回收。
内存泄漏当一个对象已经不需要使用了，本该被回收时，而有另外一个正在使用的对象持有它的引用，从而导致了对象不能被GC回收。这种导致了本该被回收的对象不能被回收而停留在堆内存中，就产生了内存泄漏。
内存泄漏与内存溢出的区别
内存泄漏（Memory Leak）
进程中某些对象已经没有使用的价值了，但是他们却还可以直接或间接地被引用到GC Root导致无法回收。当内存泄漏过多的时候，再加上应用本身占用的内存，日积月累最终就会导致内存溢出OOM。
内存溢出（OOM）
当应用的heap资源超过了Dalvik虚拟机分配的内存就会内存溢出。
内存泄漏带来的影响
1.应用卡顿
泄漏的内存影响了GC的内存分配，过多的内存泄漏会影响应用的执行效率
2.应用异常（OOM）
过多的内存泄漏，最终会导致 Dalvik分配的内存，出现OOM
Android开发常见的内存泄漏
1、单例造成的内存泄漏
1.错误示例当调用getInstance时，如果传入的context是Activity的context。只要这个单例没有被释放，那么这个Activity也不会被释放一直到进程退出才会释放。
public class CommUtil {
private static CommUtil instance;
private Context context;
private CommUtil(Context context){
this.context = context; }
if(instance == null){
public static CommUtil getInstance(Context mcontext){
}
instance = new CommUtil(mcontext); }
return instance;
2.解决方案
能使用Application的Context就不要使用Activity的Content，Application的生命周期伴随着整个进程的周期
2、非静态内部类创建静态实例造成的内存泄漏
1.错误示例
private static TestResource mResource = null;
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
if(mManager == null){
setContentView(R.layout.activity_main); mManager = new TestResource();
}
} } class TestResource {
2.解决方案
将非静态内部类修改为静态内部类。（静态内部类不会隐式持有外部类）
3、Handler造成的内存泄漏
1.错误示例
mHandler是Handler的非静态匿名内部类的实例，所以它持有外部类Activity的引用，我们知道消息队列是在一个Looper线程中不断轮询处理消息，那么当这个Activity退出时消息队列中还有未处理的消息或者正在处理消息，而消息队列中的Message持有mHandler实例的引用，mHandler又持有Activity的引用，所以导致该Activity的内存资源无法及时回收，引发内存泄漏。
private MyHandler mHandler = new MyHandler(this);
private TextView mTextView ;
private static class MyHandler extends Handler {
private WeakReference reference;
reference = new WeakReference<>(context);
public MyHandler(Context context) { } @Override
MainActivity activity = (MainActivity) reference.get();
public void handleMessage(Message msg) { if(activity != null){
protected void onCreate(Bundle savedInstanceState) {
activity.mTextView.setText(""); } } } @Override
mTextView = (TextView)findViewById(R.id.textview);
super.onCreate(savedInstanceState); setContentView(R.layout.activity_main); loadData(); }
}
private void loadData() { Message message = Message.obtain();
mHandler.sendMessage(message);
2.解决方案
创建一个静态Handler内部类，然后对Handler持有的对象使用弱引用，这样在回收时也可以回收Handler持有的对象，这样虽然避免了Activity泄漏，不过Looper线程的消息队列中还是可能会有待处理的消息，所以我们在Activity的Destroy时或者Stop时应该移除消息队列中的消息
private MyHandler mHandler = new MyHandler(this);
private TextView mTextView ;
private static class MyHandler extends Handler {
private WeakReference reference;
reference = new WeakReference<>(context);
public MyHandler(Context context) { } @Override
MainActivity activity = (MainActivity) reference.get();
public void handleMessage(Message msg) { if(activity != null){
protected void onCreate(Bundle savedInstanceState) {
activity.mTextView.setText(""); } } } @Override
mTextView = (TextView)findViewById(R.id.textview);
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);
}
4、线程造成的内存泄漏
1.错误示例异步任务和Runnable都是一个匿名内部类，因此它们对当前Activity都有一个隐式引用。如果Activity在销毁之前，任务还未完成， 那么将导致Activity的内存资源无法回收，造成内存泄漏
new AsyncTask() {
@Override
protected Void doInBackground(Void... params) {
SystemClock.sleep(10000); return null;
@Override
} }.execute(); new Thread(new Runnable() {
}
public void run() { SystemClock.sleep(10000);
}).start();
2.解决方案
使用 静态内部类，避免了Activity的内存资源泄漏，当然在Activity销毁时候也应该取消相应的任务AsyncTask::cancel()，避免任务在后台执行浪费资源
static class MyAsyncTask extends AsyncTask {
private WeakReference weakReference;
weakReference = new WeakReference<>(context);
public MyAsyncTask(Context context) { } @Override
return null;
protected Void doInBackground(Void... params) { SystemClock.sleep(10000); } @Override
MainActivity activity = (MainActivity) weakReference.get();
protected void onPostExecute(Void aVoid) { super.onPostExecute(aVoid); if (activity != null) { //... } }
new Thread(new MyRunnable()).start();
} static class MyRunnable implements Runnable{ @Override public void run() { SystemClock.sleep(10000); } }//——————
new MyAsyncTask(this).execute();
5、资源未关闭造成的内存泄漏
1.错误示例对于使用了BraodcastReceiver，ContentObserver，File，Cursor，Stream，Bitmap等资源的使用，应该在Activity销毁时及时关闭或者注销，否则这些资源将不会被回收，造成内存泄漏
2.解决方案在Activity销毁时及时关闭或者注销
6、使用了静态的Activity和View
1.错误示例
static view;
void setStaticView() {
view = findViewById(R.id.sv_button);
}
View svButton = findViewById(R.id.sv_button);
svButton.setOnClickListener(new View.OnClickListener() {
@Override public void onClick(View v) {
});
setStaticView(); nextActivity(); }
activity = this;
static Activity activity; void setStaticActivity() { }
saButton.setOnClickListener(new View.OnClickListener() {
View saButton = findViewById(R.id.sa_button); @Override public void onClick(View v) {
});
setStaticActivity(); nextActivity();
}
2.解决方案
应该及时将静态的应用 置为null，而且一般不建议将View及Activity设置为静态
7、注册了系统的服务，但onDestory未注销
1.错误示例
SensorManager sensorManager = getSystemService(SENSOR_SERVICE); Sensor sensor = sensorManager.getDefaultSensor(Sensor.TYPE_ALL); sensorManager.registerListener(this,sensor,SensorManager.SENSOR_DELAY_FASTEST);
2.解决方案
//不需要用的时候记得移除监听 sensorManager.unregisterListener(listener);
8、不需要用的监听未移除会发生内存泄露
1.错误示例
//add监听，放到集合里面
tv.getViewTreeObserver().addOnWindowFocusChangeListener(new ViewTreeObserver.OnWindowFocusChangeListener() {
@Override public void onWindowFocusChanged(boolean b) {
});
//监听view的加载，view加载出来的时候，计算他的宽高等。
}
2.解决方案
//计算完后，一定要移除这个监听 tv.getViewTreeObserver().removeOnWindowFocusChangeListener(this);
Tip
tv.setOnClickListener();//监听执行完回收对象，不用考虑内存泄漏tv.getViewTreeObserver().addOnWindowFocusChangeListene,add监听，放到集合里面，需要考虑内存泄漏。
内存溢出
(一)Android的内存管理机制
Google在Android的官网上有这样一篇文章，初步介绍了Android是如何管理应用的进程与内存分配：https://developer.android.com/training/articles/memory.html。 Android系统的Dalvik虚拟机扮演了常规的内存垃圾自动回收的角色，Android系统没有为内存提供交换区，它使用paging与memory-mapping(mmapping)的机制来管理内存，下面简要概述一些Android系统中重要的内存管理基础概念。
1）共享内存
Android系统通过下面几种方式来实现共享内存：
Android应用的进程都是从一个叫做Zygote的进程fork出来的。Zygote进程在系统启动并且载入通用的framework的代码与资源之后开始启动。为了启动一个新的程序进程，系统会fork Zygote进程生成一个新的进程，然后在新的进程中加载并运行应用程序的代码。这使得大多数的RAM pages被用来分配给framework的代码，同时使得RAM资源能够在应用的所有进程之间进行共享。大多数static的数据被mmapped到一个进程中。这不仅仅使得同样的数据能够在进程间进行共享，而且使得它能够在需要的时候被paged out。常见的static数据包括Dalvik Code，app resources，so文件等。
大多数情况下，Android通过显式的分配共享内存区域(例如ashmem或者gralloc)来实现动态RAM区域能够在不同进程之间进行共享的机制。例如，Window Surface在App与Screen Compositor之间使用共享的内存，Cursor Buffers在Content Provider与Clients之间共享内存。
2）分配与回收内存
每一个进程的Dalvik heap都反映了使用内存的占用范围。这就是通常逻辑意义上提到的Dalvik Heap Size，它可以随着需要进行增长，但是增长行为会有一个系统为它设定的上限。逻辑上讲的Heap Size和实际物理意义上使用的内存大小是不对等的，Proportional Set Size(PSS)记录了应用程序自身占用以及和其他进程进行共享的内存。
Android系统并不会对Heap中空闲内存区域做碎片整理。系统仅仅会在新的内存分配之前判断Heap的尾端剩余空间是否足够，如果空间不够会触发gc操作，从而腾出更多空闲的内存空间。在Android的高级系统版本里面针对Heap空间有一个Generational Heap Memory的模型，最近分配的对象会存放在Young Generation区域，当这个对象在这个区域停留的时间达到一定程度，它会被移动到Old Generation，最后累积一定时间再移动到Permanent Generation区域。系统会根据内存中不同的内存数据类型分别执行不同的gc操作。例如，刚分配到Young Generation区域的对象通常更容易被销毁回收，同时在Young Generation区域的gc操作速度会比Old Generation区域的gc操作速度更快。如下图所示：
?
vcnlfZ2NfbW9kZQ==" src="/uploadfile/Collfiles/20180222/20180222091458738.png" />
每一个Generation的内存区域都有固定的大小，随着新的对象陆续被分配到此区域，当这些对象总的大小快达到这一级别内存区域的阀值时，会触发GC的操作，以便腾出空间来存放其他新的对象。如下图所示：
通常情况下，GC发生的时候，所有的线程都是会被暂停的。执行GC所占用的时间和它发生在哪一个Generation也有关系，Young Generation中的每次GC操作时间是最短的，Old Generation其次，Permanent Generation最长。执行时间的长短也和当前Generation中的对象数量有关，遍历树结构查找20000个对象比起遍历50个对象自然是要慢很多的。
3）限制应用的内存
为了整个Android系统的内存控制需要，Android系统为每一个应用程序都设置了一个硬性的Dalvik Heap Size最大限制阈值，这个阈值在不同的设备上会因为RAM大小不同而各有差异。如果你的应用占用内存空间已经接近这个阈值，此时再尝试分配内存的话，很容易引起OutOfMemoryError的错误。ActivityManager.getMemoryClass()可以用来查询当前应用的Heap Size阈值，这个方法会返回一个整数，表明你的应用的Heap Size阈值是多少Mb(megabates)。
4）应用切换操作
Android系统并不会在用户切换应用的时候做交换内存的操作。Android会把那些不包含Foreground组件的应用进程放到LRU Cache中。例如，当用户开始启动了一个应用，系统会为它创建了一个进程，但是当用户离开这个应用，此进程并不会立即被销毁，而是会被放到系统的Cache当中，如果用户后来再切换回到这个应用，此进程就能够被马上完整的恢复，从而实现应用的快速切换。如果你的应用中有一个被缓存的进程，这个进程会占用一定的内存空间，它会对系统的整体性能有影响。因此当系统开始进入Low Memory的状态时，它会由系统根据LRU的规则与应用的优先级，内存占用情况以及其他因素的影响综合评估之后决定是否被杀掉。
对于那些非foreground的进程，Android系统是如何判断Kill掉哪些进程的问题，请参考Processes and Threads。
(二)OOM（OutOfMemory）
前面我们提到过使用getMemoryClass()的方法可以得到Dalvik Heap的阈值。简要的获取某个应用的内存占用情况可以参考下面的示例（ 关于更多内存查看的知识，可以参考这篇官方教程：Investigating Your RAM Usage?）
1）查看内存使用情况
通过命令行查看内存详细占用情况：?
2）发生OOM的条件
关于Native Heap，Dalvik Heap，Pss等内存管理机制比较复杂，这里不展开描述。简单的说，通过不同的内存分配方式（malloc/mmap/JNIEnv/etc）对不同的对象（bitmap，etc）进行操作会因为Android系统版本的差异而产生不同的行为，对Native Heap与Dalvik Heap以及OOM的判断条件都会有所影响。在2.x的系统上，我们常常可以看到Heap Size的total值明显超过了通过getMemoryClass()获取到的阈值而不会发生OOM的情况，那么针对2.x与4.x的Android系统，到底是如何判断会发生OOM呢？
Android 2.x系统 GC LOG中的dalvik allocated + external allocated + 新分配的大小 >= getMemoryClass()值的时候就会发生OOM。 例如，假设有这么一段Dalvik输出的GC LOG：GC_FOR_MALLOC free 2K, 13% free 32586K/37455K, external 8989K/10356K, paused 20ms，那么32586+8989+(新分配23975)=65550>64M时，就会发生OOM。
Android 4.x系统 Android 4.x的系统废除了external的计数器，类似bitmap的分配改到dalvik的java heap中申请，只要allocated + 新分配的内存 >= getMemoryClass()的时候就会发生OOM，如下图所示（虽然图示演示的是art运行环境，但是统计规则还是和dalvik保持一致）
(三)如何避免OOM总结
前面介绍了一些基础的内存管理机制以及OOM的基础知识，那么在实践操作当中，有哪些指导性的规则可以参考呢？归纳下来，可以从四个方面着手，首先是减小对象的内存占用，其次是内存对象的重复利用，然后是避免对象的内存泄露，最后是内存使用策略优化。
减小对象的内存占用
避免OOM的第一步就是要尽量减少新分配出来的对象占用内存的大小，尽量使用更加轻量的对象。