当前位置: 移动技术网 > IT编程>移动开发>Android > Android编程开发内存优化问题解析

Android编程开发内存优化问题解析

2018年02月23日  | 移动技术网IT编程  | 我要评论

废土法则,恶棍侯爵,双恋迷情

在讲到内存优化方案之前,先来介绍下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"); 

6020744_1

这里解释一下黄色这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; 

6020744_2?
对于成员变量和局部变量:成员变量就是方法外部,类的内部定义的变量;局部变量就是方法或语句块内部定义的变量。局部变量必须初始化。?
形式参数是局部变量,局部变量的数据存在于栈内存中。栈内存中的局部变量随着方法的消失而消失。?
成员变量存储在堆中的对象里面,由垃圾回收器负责回收。?
如以下代码:

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;  
    } 
} 

6020744_3?
对于以上这段代码,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操作速度更快。如下图所示:

memory_mode_generation?android_memZ喎?/kf/ware/vc/vcnlfZ2NfbW9kZQ==" src="/uploadfile/Collfiles/20180222/20180222091458738.png" />

每一个Generation的内存区域都有固定的大小,随着新的对象陆续被分配到此区域,当这些对象总的大小快达到这一级别内存区域的阀值时,会触发GC的操作,以便腾出空间来存放其他新的对象。如下图所示:

gc_threshold

通常情况下,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)查看内存使用情况

通过命令行查看内存详细占用情况:

android_perf_oom_dumpsys_meminfo.png

通过Android Studio的Memory Monitor查看内存中Dalvik Heap的实时变化

android_perf_oom_studio_mem_monitormemory_monitor_free_allocation?memory_monitor_gc_event

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保持一致)

android_perf_oom_gc_log.png

(三)如何避免OOM总结

前面介绍了一些基础的内存管理机制以及OOM的基础知识,那么在实践操作当中,有哪些指导性的规则可以参考呢?归纳下来,可以从四个方面着手,首先是减小对象的内存占用,其次是内存对象的重复利用,然后是避免对象的内存泄露,最后是内存使用策略优化。

减小对象的内存占用

避免OOM的第一步就是要尽量减少新分配出来的对象占用内存的大小,尽量使用更加轻量的对象。

如对本文有疑问,请在下面进行留言讨论,广大热心网友会与你互动!! 点击进行留言回复

相关文章:

验证码:
移动技术网