Android性能优化(二)—— 内存优化

Android系统中,垃圾回收是自动的,比较隐蔽,这就导致一些内存问题表现的并不明显,出现问题后难以定位。常见的内存问题有内存泄漏、内存溢出(Out of Memory)、内存抖动等。

我们做内存优化的主要原因有以下几点:

  • 降低OOM率,内存问题最常见的就是OOM,申请的内存得不到释放就有可能造成OOM
  • 减少卡顿,Android系统中造成卡顿的原因有很多,其中就有内存引起的卡顿。内存问题之所以会影响到界面流畅度,是因为垃圾回收机制,在GC的时候,所有的线程都要停止工作,包括主线程。因此,当GC和绘制界面的操作同时触发时,绘制的任务就会被搁置,导致掉帧,也就是界面卡顿;
  • 增加应用存活时间,Android系统会按照特定的流程清理进程,优先考虑清理后台进程,如果某个应用在后台运行且占用的内存很多,就会被优先清理掉。如果我们希望APP可以存活的久一点,不使用的内存应该尽快清理掉;

至于哪些对象是需要回收的?使用跟搜索算法/可达性算法,选定一些对象作为GC Roots,向下搜索,搜索所经过的路径称为引用链,当一个对象到GC Roots没有应用链相连,则表明此对象需要回收。以下是可以作为GC Roots的对象:

  • 本地方法栈中引用的对象;
  • 虚拟机栈中引用的对象;
  • 全局静态变量引用的对象;
  • 全局常量引用的对象;

Java虚拟机(四)—— Java虚拟机中的对象

1 内存泄漏

内存泄漏指的是我们的应用已经不需要某些对象了,但是,该对象的某些引用依旧没有释放,导致这些对象没有办法被回收。从内存上来看,就是某块内存已经不再被使用了,但是却没有办法被回收掉,从而造成了内存浪费。 比如说匿名内部类持有外部类的引用,导致外部类无法被回收,就会出现内存泄漏的问题。

内存泄漏会导致无法回收的内存越来越多,可用的内存越来越少,直到应用无更多可用的内存申请,严重的甚至出现OOM

内存泄漏

2 内存溢出(OOM Out Of Memory

内存泄漏一般导致应用卡顿,极端情况会导致OOMOOM的原因是因为超过内存的阈值。原因主要有两方面:

  • 内存泄漏,导致无法及时释放导致OOM
  • 一些逻辑消耗了大量内存,无法及时释放或者超过导致OOM

Android性能优化(二)—— 内存优化_第1张图片

能够消耗大量内存的,绝大多数是因为图片加载。这是OOM出现最频繁的地方。图片加载,一个是控制每次加载的数量,二是保证每次滑动的时候不进行加载,滑动完进行加载。一般情况使用先进后出,而不是先进先出。 不过一般我们图片加载都是使用fresco或者Glide等开源库。

下面是导致内存溢出的两种情况:

通过命令行查看内存消耗情况(adb shell dumpsys meminfo 包名 -d):


对于图片的内存优化:

  • 图片缩放,比如说一张图片的饿宽高为200 x 200,但是View的宽高为100 x 100,这个时候就要对图片进行缩放,通过inSampleSize实现;
  • 减少每个像素所占用的内存,在API 29中,将Bitmap分为ALPHA_8RGB_565ARGB_4444RGBA_F16HARDWARE六个等级:
    • ALPHA_8:不存储颜色信息,每个像素占1个字节;
    • RGB_565:仅存储RGB通道,每个像素占2个字节,对Bitmap色彩没有高要求,可以使用该模式;
    • ARGB_4444:已弃用,用ARGB_8888代替;
    • ARGB_8888:每个像素占用4个字节,保持高质量的色彩保真度,默认使用该模式;
    • RGBA_F16:每个像素占用8个字节,适合宽色域和HDR
    • HARDWARE:一种特殊的配置,减少了内存占用同时也加快了Bitmap的绘制;
  • 每个等级每个像素所占用的字节是不一样的,所存储的色彩值也不同,同一张100像素的图片,ARGB_8888占用了400字节,RGB_565才占用200字节。所以在某些场景中,修改图片格式也可以达到减少一半内存的效果。
    内存复用,避免重复分配内存。Bitmap所占用的内存比较大,如果频繁的创建和回收Bitmap,很容易造成内存抖动,所以应该尽量复用Bitmap内存。在 Android 3.0(API 级别 11)开始,系统引入了 BitmapFactory.Options.inBitmap 字段。如果设置了此选项,那么采用 Options 对象的解码方法会在生成目标 Bitmap 时尝试复用 inBitmap,这意味着 inBitmap 的内存得到了重复使用,从而提高了性能,同时移除了内存分配和取消分配。不过 inBitmap 的使用方式存在某些限制,在 Android 4.4(API 级别 19)之前系统仅支持复用大小相同的位图,4.4 之后只要 inBitmap 的大小比目标 Bitmap 大即可
  • 大图局部加载策略:对于图片加载还有种情况,就是单个图片非常巨大,并且还不允许压缩。比如显示:世界地图、清明上河图、微博长图等。首先不压缩,按照原图尺寸加载,那么屏幕肯定是不够大的,并且考虑到内存的情况,不可能一次性整图加载到内存中。所以这种情况的优化思路一般是局部加载,通过BitmapRegionDecoder来实现

上面所说的这些关于Bitmap的内存优化策略其实都比较简单,而且我们在开发中可能很少用到
因为我们常用的图片框架比如Glide已经将这些都封装在里面了,所以一般情况下我们加载图片时不需要做这些特殊操作。

3 内存抖动

在短时间内频繁的创建或者销毁的对象,容易触发GC,会引起内存抖动,比如在一个for循环中创建临时对象实例。

因为GC的时候所有的线程都会停止工作,因此导致卡顿。为了避免内存抖动,应该避免以下操作:

  • 尽量避免在循环体中创建对象;
  • 尽量不要在自定义View.onDraw()方法中创建对象,因为这个方法会被频繁调用;
  • 对于能够复用的对象,可以考虑使用对象池把它们缓存起来;

参考

Android内存优化深入解析
关于android 性能优化——内存篇
Android性能优化——内存优化

你可能感兴趣的:(android,性能优化,jvm)