面试的时候,有些问题并不是每个程序员都解决过,没解决过这类问题并不代表这个程序员不合适这个工作。但解决过并有一定经验的话,却能客观地反应出面试者某一方面的能力。如内存问题,很多应用都或多或少有这个问题(内存泄露),但如果没有到OOM的程度,很多这方面的问题都不会被解决。
因为有GC的存在,很多人都不需要去管理内存,一般OOM很容易从LOG发现问题根源,而且现今的手机内存都增大了很多,OOM的现像也比较少见了。所以,很多时候我们面试时,对于一般经验的开发,也不会问他们这方面的问题,因为他实际中可能基本上没有“遇到”过这样的问题。
但对于资深的开发来说,内存问题却又是必问的问题,因为在公司里往往受信任的开发才会被安排去解决内存问题。今天就来说说这道一般人咱不问他的面试题。
面试题:如何检测内存泄露,如何进行内存优化?
所谓“知己知彼,百战不殆”,我们要解决内存问题前,至少应该先了解一下内存是什么。说到内存有两个概念要先搞清楚:RAM和ROM。手机的RAM即我们常说的内存,是Random Access Memory的缩写,即随机存储器,在工作状态时可以随机读写数据,断电以后会丢失数据。手机的ROM和传统的ROM(Read Only Memory)又有些不一样,手机上的ROM在一定条件下是可写的,用户层级的写入被限制(所以有些用应需要ROOT权限)。它分为两部分,一部分是供系统使用(/System和/Cache),另外一部分是用作用户存储数据(/data),用户安装的应用就在这个data空间中。
Android 2.0后的系统可以把APK应用安装在SD卡上,但4.0后又取消了这个做法,不允许安装在SD卡上,而且随着手机内部存储容量的扩大,很多手机都不支持外插一个TF卡了。
我们为什么需要内存?
先来复习一个操作系统的知识,CPU执行运算时需要从内存(RAM)获取操作数据,对于多任务系统来说同时有多个进程在运行,不可能给每个进程都分配置大量的内存,因为RAM容量(即物理内存的容量)始终是有限的。“解决不了的问题,可以通过增加中间层来解决”,前人们通过给进程增加一个虚拟内存,让每个进程都有独立的虚拟内存空间,由系统来管理虚拟内存到物理内存的映射,保证各个进程的数据不会错乱。
在32位的系统中,内存的寻址空间是2的32次方,即4GB。
从上图也可以明白,你的应用中的对象所能所使用的内存在理论上也不能操过Heap区域的大小。
Android系统是基于Linux的,但Android中的进程分为两种,一种是Native进程,一种是Java进程。我们常接触的APK应用都是运行在Java进程中的。Android应用运行于Dalvik虚拟机之上的进程,由Dalvik虚拟机负责分配和管理应用的Java对象需要的内存。而对应到内存上,就存在Natvie内存和Java内存,由Dalvik虚拟机管理的就是Java内存(或者叫Java Heap内存)。
Native进程:采用C/C++实现,不包含Dalvik实例的进程,/system/bin/目录下面的程序文件运行后都是以native 进程形式存在的,/system/bin/surfaceflinger、/system/bin/rild、procrank等就是Native进程。
一般我们常遇到的内存问题,基本上都集中在Java内存。一些游戏或视频之类的应用,有可能会更多的面对Native的内存问题。
虽然有些手机的RAM很大(如小米5S有4G RAM),但Android系统为了能同时让比较多的进程常驻内存(这样程序启动时就不用每次都重新加载到内存,从而加快切换应用的速度),它们给每一个应用进程都分配了一个有限制的较小的heapsize,当Java申请的堆内存空间超过阈值时,就会抛出OOM异常。也就是说,程序发生OMM并不表示RAM不足,而是因为程序申请的Java Heap对象超过了Dalvik虚拟机设直heapgrowthlimit。
目前主流的一些机型这个值都有190M上下,想想几年前只有16到32M,是不是很幸福?
正如我们在“图片到底是什么”那个面试题中也有说过,Bitmap图片可以放在Java堆内存中,也有些情况可以放在Native内存中来获得更大的内存,避免OOM。因为APK应用的Java进程也是运行在Native进程之上的,而Native的内存空间是不受Dalvik虚拟机的heapsize限制,相对而言大很多(Java和Native可以通过JNI进行通信)。
了解了这些基础知识后,在面试进,你可能会遇到这样的问题:“如果一个项目的代码量很大,通过代码直接分析内存问题不太现实时,你有什么手段或者工具去发现这个项目中是否存在内存问题?并说一下解决的办法或者相关的案例。对于初级的开发,你对他们有什么建议能让他们避免内存问题吗?”
未完待续。。。
网友评论
int heapSize = activityManager.getLargeMemoryClass();
我是用这个去获取的,居然有512,感觉好不可思议,和你说的190M也差了好几倍,是我获取错了吗??
而你这个方法有些像是声明更大的heap空间的。