Android的内存管理和内存优化

1. Android内存的分配和使用

内存分配的时候一般会放在三种位置：静态存储区域、堆和栈，他们的位置、功能、速度都各不相同，区别如下：

• 静态存储区：内存在程序编译的时候就已经分配好，这块内存在程序整个运行期间都存在。它主要存放静态数据、全局static数据和常量。
• 栈：就是CPU的寄存器（并不是内存），特点是容量很小但是速度最快，函数或者方法的的方法体内声明的变量或者指向对象的引用、局部变量即分配在这里，生命周期到该函数或者方法体尾部即止。
• 堆：就是动态内存分配去（就是实体的内存RAM），C中malloc和fee，java中的new和垃圾回收直接操作的就是这里的区域，类的成员变量分配在这里。

2.内存的优化方案

1. 尽量减少内存使用

• 尽量使用轻量级的数据结构：比如HashMap换成ArrayMap/SparseArray。
• 尽量不要使用枚举类型（Enum）。
• BitMap对象，尽量使用小图片，载入内存前缩放图片，解码时选择合适的解码格式。

2. 内存对象重复使用，（对象池技术）

• 复用系统的资源，颜色，动画，样式等。
• ListView、GridView复用convertView。
• InBitMap的使用，会复用和解码图片相同格式的图片。
• 避免在ondraw方法里创建对象，这样会迅速增加内存的使用，引起频繁GC，甚至内存抖动。
• 大量进行字符串拼接时，使用StringBuffer代替“+”。

3. 避免内存泄漏（memory leak）

• 常发性内存泄漏。发生内存泄漏的代码会被多次执行到，每次被执行的时候都会导致一块内存泄漏。
• 偶发性内存泄漏。发生内存泄漏的代码只有在某些特定环境或操作过程下才会发生。常发性和偶发性是相对的。对于特定的环境，偶发性的也许就变成了常发性的。所以测试环境和测试方法对检测内存泄漏至关重要。
• 一次性内存泄漏。发生内存泄漏的代码只会被执行一次，或者由于算法上的缺陷，导致总会有一块仅且一块内存发生泄漏。比如，在类的构造函数中分配内存，在析构函数中却没有释放该内存，所以内存泄漏只会发生一次。
• 隐式内存泄漏。程序在运行过程中不停的分配内存，但是直到结束的时候才释放内存。严格的说这里并没有发生内存泄漏，因为最终程序释放了所有申请的内存。但是对于一个服务器程序，需要运行几天，几周甚至几个月，不及时释放内存也可能导致最终耗尽系统的所有内存。所以，我们称这类内存泄漏为隐式内存泄漏。

4. 内存泄漏的原因

• 对象A的生命周期大于对象B的生命周期，对象A引用了对象B，对象B释放之后，导致对象B的堆内存无法被GC回收。

5. 常见的内存泄漏案例

• 某对象被静态变量引用，该对象会产生内存泄漏。
• 单利模式持有，应该被释放的引用。
• Android特殊组件或者类忘记释放，比如：BraodcastReceiver忘记解注册、Cursor忘记销毁、Socket忘记close、TypedArray忘记recycle、callback忘记remove。如果你自己定义了一个类，最好不要直接将一个Activity类型作为他的属性，如果必须要用，要么处理好释放的问题，要么使用弱引用。
• Handler。只要Handler发送的Message尚未被处理，则该Message及发送它的Handler对象将被线程MessageQueue 一直持有。由于 Handler 属于 TLS(ThreadLocal Storage) 变量,生命周期和Activity是不一致的。因此这种实现方式一般很难保证跟 View 或者Activity的生命周期保持一致，故很容易导致无法正确释放。如上所述，Handler的使用要尤为小心，否则将很容易导致内存泄露的发生。
• Thread。如果Thread的run方法一直在循环的执行不停，而该Thread又持有了外部变量，那么这个外部变量即发生内存泄漏。
• 网络请求或者其他异步线程。之前Volley会有这样的一个问题，在Volley的response来到之前如果Activity已经退出了而且response里面含有Activity的成员变量，会导致该Activity发生内存泄漏，该问题一直没有找到合适的解决办法。不过看来Volley官网已经注意到这个问题了，目前最新的版本已经fix this leak。