android内存优化详解Word格式.docx
《android内存优化详解Word格式.docx》由会员分享，可在线阅读，更多相关《android内存优化详解Word格式.docx（18页珍藏版）》请在冰豆网上搜索。
如果我们仅仅是把它的引用设置为null,而不关闭它们，往往会造成内存泄露。
因为有些资源性对象，比如SQLiteCursor（在析构函数finalize（）,如果我们没有关闭它，它自己会调close（）关闭），如果我们没有关闭它，系统在回收它时也会关闭它，但是这样的效率太低了。
因此对于资源性对象在不使用的时候，应该调用它的close（）函数，将其关闭掉，然后才置为null.在我们的程序退出时一定要确保我们的资源性对象已经关闭。
程序中经常会进行查询数据库的操作，但是经常会有使用完毕Cursor后没有关闭的情况。
如果我们的查询结果集比较小，对内存的消耗不容易被发现，只有在常时间大量操作的情况下才会复现内存问题，这样就会给以后的测试和问题排查带来困难和风险。
3，一些不良代码成内存压力
有些代码并不造成内存泄露，但是它们，或是对没使用的内存没进行有效及时的释放，或是没有有效的利用已有的对象而是频繁的申请新内存，对内存的回收和分配造成很大影响的，容易迫使虚拟机不得不给该应用进程分配更多的内存，造成不必要的内存开支。
3.1，Bitmap没调用recycle（）
Bitmap对象在不使用时,我们应该先调用recycle（）释放内存，然后才它设置为null.
虽然recycle（）从源码上看，调用它应该能立即释放Bitmap的主要内存，但是测试结果显示它并没能立即释放内存。
但是我它应该还是能大大的加速Bitmap的主要内存的释放。
3.2，构造Adapter时，没有使用缓存的
convertView
以构造ListView的BaseAdapter为例，在BaseAdapter中提共了方法：
public
View
getView（int
position,
convertView,
ViewGroup
parent）
来向ListView提供每一个item所需要的view对象。
初始时ListView会从BaseAdapter中根据当前的屏幕布局实例化一定数量的view对象，同时ListView会将这些view对象缓存起来。
当向上滚动ListView时，原先位于最上面的list
item的view对象会被回收，然后被用来构造新出现的最下面的list
item。
这个构造过程就是由getView（）方法完成的，getView（）的第二个形参
convertView就是被缓存起来的list
item的view对象（初始化时缓存中没有view对象则convertView是null）。
由此可以看出，如果我们不去使用convertView，而是每次都在getView（）中重新实例化一个View对象的话，即浪费时间，也造成内存垃圾，给垃圾回收增加压力，如果垃圾回收来不及的话，虚拟机将不得不给该应用进程分配更多的内存，造成不必要的内存开支。
ListView回收list
item的view对象的过程可以查看:
viewplaincopytoclipboardprint?
1.android.widget.AbsListView.java
-->
void
addScrapView（View
scrap）
方法。
2.示例代码：
3.public
parent）
{
4.
view
=
new
Xxx（...）;
5.
...
6.
return
view;
7.}
8.修正示例代码：
9.public
10.
null;
11.
if
（convertView
!
null）
12.
convertView;
13.
populate（view,
getItem（position））;
14.
15.
}
else
16.
17.
18.
19.
20.}
[java]viewplaincopyprint?
Android内存管理
概述
在android的开发中，要时刻主要内存的分配和垃圾回收，因为系统为每一个dalvik虚拟机分配的内存是有限的，在google的G1中，分配的最大堆大小只有16M，后来的机器一般都为24M，实在是少的可怜。
这样就需要我们在开发过程中要时刻注意。
不要因为自己的代码问题而造成OOM错误。
JAVA的内存管理
大家都知道，android应用层是由java开发的，android的davlik虚拟机与jvm也类似，只不过它是基于寄存器的。
因此要了解android的内存管理就必须得了解java的内存分配和垃圾回收机制。
在java中，是通过new关键字来为对象分配内存的，而内存的释放是由垃圾收集器（GC）来回收的，工程师在开发的过程中，不需要显式的去管理内存。
但是这样有可能在不知不觉中就会浪费了很多内存，最终导致java虚拟机花费很多时间去进行垃圾回收，更严重的是造成JVM的OOM。
因此，java工程师还是有必要了解JAVA的内存分配和垃圾回收机制。
1.内存结构
上面这张图是JVM的结构图，它主要四个部分组成：
ClassLoader子系统和执行引擎，运行时方法区和本地方法区，我们主要来看下RUNTIMEDATAAREA区，也就是我们常说的JVM内存。
从图中可以看出，RUNTIMEDATAAREA区主要由5个部分组成：
∙MethodArea:
被装载的class的元信息存储在MethodArea中，它是线程共享的
∙Heap（堆）：
一个java虚拟机实例中只存在一个堆空间，存放一些对象信息，它是线程共享的
∙Java栈：
java虚拟机直接对java栈进行两种操作，以帧为单位的压栈和出栈（非线程共享）
∙程序计数器（非线程共享）
∙本地方法栈（非线程共享）
1.JVM的垃圾回收（GC）
JVM的垃圾原理是这样的，它把对象分为年轻代（Young）、年老代（Tenured）、持久代（Perm），对不同生命周期的对象使用不同的垃圾回收算法。
∙年轻代（Young）
年轻代分为三个区，一个eden区，两个Survivor区。
程序中生成的大部分新的对象都在Eden区中，当Eden区满时，还存活的对象将被复制到其中一个Survivor区，当此Survivor区的对象占用空间满了时，此区存活的对象又被复制到另外一个Survivor区，当这个Survivor区也满了的时候，从第一个Survivor区复制过来的并且此时还存活的对象，将被复制到年老代。
∙年老代（Tenured）
年老代存放的是上面年轻代复制过来的对象，也就是在年轻代中还存活的对象，并且区满了复制过来的。
一般来说，年老代中的对象生命周期都比较长。
∙持久代（Perm）
用于存放静态的类和方法，持久代对垃圾回收没有显著的影响。
Android中内存泄露监测
在了解了JVM的内存管理后，我们再回过头来看看，在android中应该怎样来监测内存，从而看在应用中是否存在内存分配和垃圾回收问题而造成内存泄露情况。
在android中，有一个相对来说还不错的工具，可以用来监测内存是否存在泄露情况：
DDMS—Heap
使用方法比较简单：
∙选择DDMS视图，并打开Devices视图和Heap视图
∙点击选择要监控的进程，比如：
上图中我选择的是system_process
∙选中Devices视图界面上的"
updateheap"
图标
∙点击Heap视图中的"
CauseGC"
按钮（相当于向虚拟机发送了一次GC请求的操作）
在Heap视图中选择想要监控的Type，一般我们会观察dataobject的totalsize的变化，正常情况下totalsize的值会稳定在一个有限的范围内，也就说程序中的代码良好，没有造成程序中的对象不被回收的情况。
如果代码中存在没有释放对象引用的情况，那么dataobject的totalsize在每次GC之后都不会有明显的回落，随着操作次数的增加而totalsize也在不断的增加。
（说明：
选择好dataobject后，不断的操作应用，这样才可以看出totalsize的变化）。
如果totalsize确实是在不断增加而没有回落，说明程序中有没有被释放的资源引用。
那么我们应该怎么来定位呢？
Android中内存泄露定位
Mat（memoryanalyzertools）是我们常用的用来定位内存泄露的工具，如果你使用ADT，并且安装了MAT的eclipse插件，你需要做的是进入DDMS视图的Devices视图：
点击"
dumpHPROFfile"
按钮，然后使用MAT分析下载下来的文件。
下面列出了存在的问题，点击detail进去，会列出详细的，可能会存在问题的代码：
关于MAT的使用可以参考：
这位兄弟写的比较详细。
总结
不管是java还是android，都应该了解内存分配和垃圾回收机制，工程师要做到写的代码中没有badcode很难，关键是在出现问题的时候该怎么去排查
Android内存优化
一、
Android的内存机制
Android的程序由Java语言编写，所以Android的内存管理与Java的内存管理相似。
程序员通过new为对象分配内存，所有对象在java堆内分配空间；
然而对象的释放是由垃圾回收器来完成的。
C／C++中的内存机制是“谁污染，谁治理”，java的就比较人性化了，给我们请了一个专门的清洁工（GC）。
那么GC怎么能够确认某一个对象是不是已经被废弃了呢？
Java采用了有向图的原理。
Java将引用关系考虑为图的有向边，有向边从引用者指向引用对象。
线程对象可以作为有向图的起始顶点，该图就是从起始顶点开始的一棵树，根顶点可以到达的对象都是有效对象，GC不会回收这些对象。
如果某个对象
（连通子图）与这个根顶点不可达（注意，该图为有向图），那么我们认为这个（这些）对象不再被引用，可以被GC回收。
二、Android的内存溢出
Android的内存溢出是如何发生的?
Android的虚拟机是基于寄存器的Dalvik，它的最大堆大小一般是16M，有的机器为24M。
因此我们所能利用的内存空间是有限的。
如果我们的内存占用超过了一定的水平就会出现OutOfMemory的错误。
为什么会出现内存不够用的情况呢？
我想原因主要有两个：
∙由于我们程序的失误，长期保持某些资源（如Context）的引用，造成内存泄露，资源造成得不到释放。
∙保存了多个耗用内存过大的对象（如Bitmap），造成内存超出限制。
三、万恶的static
static是Java中的一个关键字，当用它来修饰成员变量时，那么该变量就属于该类，而不是该类的实例。
所以用static修饰的变量，它的生命周期是很长的，如果用它来引用一些资源耗费过多的实例（Context的情况最多），这时就要谨慎对待了。
1.public
class
ClassName
2.
private
static
Context
mContext;
3.
//省略
4.}
以上的代码是很危险的，如果将Activity赋值到么mContext的话。
那么即使该Activity已经onDestroy，但是由于仍有对象保存它的引用，因此该Activity依然不会被释放。
我们举Android文档中的一个例子。
1.private
Drawable
sBackground;
@Override
protected
onCreate（Bundle
state）
super.onCreate（state）;
7.
TextView
label
TextView（this）;
8.
label.setText（"
Leaks
are
bad"
）;
9.
（sBackground
==
sBackground
getDrawable（R.drawable.large_bitmap）;
label.setBackgroundDrawable（sBackground）;
setContentView（label）;
sBackground,
是一个静态的变量，但是我们发现，我们并没有显式的保存Contex的引用，但是，当Drawable与View连接之后，Drawable就将View设置为一个回调，由于View中是包含Context的引用的，所以，实际上我们依然保存了Context的引用。
这个引用链如下：
Drawable->
TextView->
Context
所以，最终该Context也没有得到释放，发生了内存泄露。
如何才能有效的避免这种引用的发生呢？
第一，应该尽量避免static成员变量引用资源耗费过多的实例，比如Context。
第二、Context尽量使用Application
Context，因为Application的Context的生命周期比较长，引用它不会出现内存泄露的问题。
第三、使用WeakReference代替强引用。
比如可以使用WeakReference<
Context>
mContextRef;
该部分的详细内容也可以参考Android文档中Article部分。
四、都是线程惹的祸
线程也是造成内存泄露的一个重要的源头。
线程产生内存泄露的主要原因在于线程生命周期的不可控。
我们来考虑下面一段代码。
MyActivity
extends
Activity
savedInstanceState）
super.onCreate（savedInstanceState）;
setContentView（R.layout.main）;
MyThread（）.start（）;
MyThread
Thread{
run（）
super.run（）;
//do
somthing
16.}
这段代码很平常也很简单，是我们经常使用的形式。
我们思考一个问题：
假设MyThread的run函数是一个很费时的操作，当我们开启该线程后，将设备的横屏变为了竖屏，一般情况下当屏幕转换时会重新创建Activity，按照我们的想法，老的Activity应该会被销毁才对，然而事实上并非如此。
由于我们的线程是Activity的内部类，所以MyThread中保存了Activity的一个引用，当MyThread的run函数没有结束时，MyThread是不会被销毁的，因此它所引用的老的Activity也不会被销毁，因此就出现了内存泄露的问题。
有些人喜欢用Android提供的AsyncTask，但事实上AsyncTask的问题更加严重，Thread只有在run函数不结束时才出现这种内存泄露问题，然而AsyncTask内部的实现机制是运用了ThreadPoolExcutor,该类产生的Thread对象的生命周期是不确定的，是应用程序无法控制的，因此如果AsyncTask作为Activity的内部类，就更容易出现内存泄露的问题。
这种线程导致的内存泄露问题应该如何解决呢？
第一、将线程的内部类，改为静态内部类。
第二、在线程内部采用弱引用保存Context引用。
解决的模型如下：
abstract
WeakAsyncTask<
Params,
Progress,
Result,
WeakTarget>
AsyncTask<
Result>
WeakReference<
mTarget;
WeakAsyncTask（WeakTarget
target）
mTarget
（target）;
/**
{@inheritDoc}
*/
final
onPreExecute（）
WeakTarget
target
mTarget.get（）;
（target
this.onPreExecut
升级会员 