10.2 内存优化" class="reference-link">10.2 内存优化

应用App内存的使用,也是评价一个应用性能高低的一个重要指标。虽然现在智能手机的内存越来越大,但是一个好的应用应当将效率发挥到极致,精益求精。而现在有很多应用,为了自己的利益,使用一些非常影响系统效率的方法,不仅败坏了Android的口碑,更极大地影响了系统的稳定性。例如某“X米”团购应用,在启动应用时会fork一个子线程,用于监听用户卸载应用。在KK下,该线程在卸载时不能被kill,而且每次启动都将fork新的进程,这就导致内存消耗不断增高,极大地影响了低端机的使用体验。因此,不管是什么应用,都应该把内存效率、用户体验放在首位,而不是为了满足自己的利益。

10.2.1 什么是内存" class="reference-link">10.2.1 什么是内存

由于Android应用的沙箱机制,每个应用所分配的内存大小是有限度的,内存太低就会触发LMK——Low Memory Killer机制。那么到底什么是内存呢?通常情况下我们所说的内存是指手机的RAM,它包括以下几个部分。

  • 寄存器(Registers)

速度最快的存储场所,因为寄存器位于处理器内部,在程序中无法控制。

  • 栈(Stack)

存放基本类型的数据和对象的引用,但对象本身不存放在栈中,而是存放在堆中。

  • 堆(Heap)

堆内存用来存放由new创建的对象和数组。在堆中分配的内存,由Java虚拟机的自动垃圾回收器(GC)来管理。

  • 静态存储区域(Static Field)

静态存储区域就是指在固定的位置存放应用程序运行时一直存在的数据,Java在内存中专门划分了一个静态存储区域来管理一些特殊的数据变量如静态的数据变量。

  • 常量池(Constant Pool)

JVM虚拟机必须为每个被装载的类型维护一个常量池。常量池就是该类型所用到常量的一个有序集合,包括直接常量(基本类型,String)和对其他类型、字段和方法的符号引用。

在这些概念中最容易搞错的就是堆和栈的区分。当定义一个变量,Java虚拟机就会在栈中为该变量分配内存空间,当该变量作用域结束后,这部分内存空间会马上被用作新的空间进行分配。如果使用new的方式创建一个变量,那么就会在堆中为这个对象分配内存空间,即使该对象的作用域结束,这部分内存也不会立即被回收,而是等待系统GC进行回收。堆的大小随着手机的不断发展而不断变大。在程序中,可以使用如下所示的代码来获得堆的大小,所谓的内存分析,正是分析Heap中的内存状态。

  1. ActivityManager manager =
  2. (ActivityManager)getSystemService(Context.ACTIVITY_SERVICE);
  3. int heapSize = manager.getLargeMemoryClass();

10.2.2 获取Android系统内存信息" class="reference-link">10.2.2 获取Android系统内存信息

10.2.2.1 Process Stats

Process Stats是KK上新增的一个系统内存监视服务,可以通过“Setting-Developer options-Process Stats”来开启该功能的界面,如图10.12所示。

10.2 内存优化 - 图1 图10.12 Process Stats

同样,也可以使用Dumpsys命令来获取这些信息,命令如下所示。

  1. adb shell dumpsys procstats

10.1.1.1 Meminfo

Meminfo也是系统上的一个非常重要的内存监视工具,可以通过在Settings-Apps- Running中打开这一界面,如图10.13所示。

10.2 内存优化 - 图2 图10.13 Running App

同样,也可以使用Dumpsys命令,命令如下所示。

  1. adb shell dumpsys meminfo

10.2.3 内存回收" class="reference-link">10.2.3 内存回收

Java对于C、C++这类语言最大的优势就是不用手动管理系统资源,Java创建了垃圾收集器线程(Garbage Collection Thread)来自动进行资源的管理。这样做的好处是大大降低了程序开发人员对内存管理的繁琐工作。但这也带来了很多问题,例如Java的GC是系统自动进行的,但何时进行却是开发者无法控制的,即使调用System.gc()方法,也只是建议系统进行GC,但系统是否采纳你的建议,那就不一定了。JVM虚拟机虽然能够自动控制GC,但是再强大的算法,也难免会存在部分对象忘记回收的现象发生,这就是造成内存泄漏的原因。

10.2.4 内存优化实例" class="reference-link">10.2.4 内存优化实例

下面来看两个内存优化的实例,分别从Bitmap和代码两个角度来对内存进行优化。

10.2.4.1 Bitmap优化

Bitmap是造成内存占用过高甚至是OOM(Out Of Memory)的最大威胁。下面给出一些使用Bitmap的小技巧。

  • 使用适当分辨率和大小的图片

由于Android系统在做资源适配的时候会对不同分辨率文件夹下的图片进行缩放来适配相应的分辨率,如果图片分辨率与资源文件夹分辨率不匹配或者图片分辨率太高,就会导致系统消耗更多的内存资源。同时,在适当的时候,应该显示合适大小的图片,例如在图片列表界面可以使用图片的缩略图thumbnails,而在显示详细图片的时候再显示原图;或者在对图像要求不高的地方,尽量降低图片的精度。

  • 及时回收内存

一旦使用完Bitmap后,一定要及时使用bitmap.recycle()方法释放内存资源。自Android 3.0之后,由于Bitmap被放置到了堆中,其内存由GC管理,就不需要进行释放了。

  • 使用图片缓存

通过内存缓存(LruCache)和硬盘缓存(DiskLruCache)可以更好地使用Bitmap。

10.2.4.2 代码优化

任何Java类,都将占用大约500字节的内存空间。创建一个类的实例会消耗大约15字节的内存。从代码的实现方式上,也可以对内存进行优化,这里同样总结了一些小的 技巧。

  • 对常量使用static修饰符。
  • 使用静态方法,静态方法会比普通方法提高15%左右的访问速度。
  • 减少不必要的成员变量,这点在Android Lint工具上已经集成检测了,如果一个变量可以定义为局部变量,则会建议你不要定义为成员变量。
  • 减少不必要的对象,使用基础类型会比使用对象更加节省资源,同时更应该避免频繁创建短作用域的变量。
  • 尽量不要使用枚举、少用迭代器。
  • 对Cursor、Receiver、Sensor、File等对象,要非常注意对它们的创建、回收与注册、解注册。
  • 避免使用IOC框架,IOC通常使用注解、反射来进行实现,虽然现在Java对反射的效率已经进行了很好的优化,但大量使用反射依然会带来性能的下降。
  • 使用RenderScript、OpenGL来进行非常复杂的绘图操作。
  • 使用SurfaceView来替代View进行大量、频繁的绘图操作。
  • 尽量使用视图缓存,而不是每次都执行inflate()方法解析视图。