android 内存优化(避免OOM)--面试经典问题

如何避免OOM

OOM（内存溢出）已使用的内存+新分配的内存>可分配的内存就会抛出OOM，那么避免OOM的思路就是如何去减少内存的使用。

通常Android里的oom是堆内存溢出，但是Native heap在物理内存不够时也会抛出oom

Bitmap

Bitmap无疑是内存大户，首先看看使用Bitmap的时候可以怎么样优化。
1.根据实际情况使用合适分辨率的Bitmap
2.注意原始分辨率和内存缩放结果（比如drawable-xdpi,drawable-xxdpi这些文件夹多放几套图和只放一套图的区别）
3.少使用逐帧动画，多实用代码画动画
4.考虑对Bitmap的重采样和重配置（比如在不需要很清晰或者不需要透明通道的情况下可以重新创建一个ARGB_4444或RGB_565的Bitmap）

使用合适的数据结构

比如HashMap，我们在实际项目中经常会用到，但是其实HashMap也有几个具有差不多功能的数据结构可以替代使用：ArrayMap，SparseArray。
那么这三个数据结构在什么时候使用呢？
1.当数据量比较多或者频繁增删的时候使用HashMap（大于1000）因为HashMap的查询和插入都接近于O(1)。
2.否则当储存的数据的key是整形的则使用SparseArray，SparseArray的key使用的是int基本类型省略了装箱拆箱的步骤并且节省了内存。
3.如果key类型不是int类型则使用ArrayMap

避免使用枚举

枚举和int变量所占用的内存相差甚远，一个枚举占用24bytes而一个int占用4bytes。

但是使用int类型就没有类型安全限制了，这个时候我们就可以使用java的注解@intDef去解决。

这样又有一个问题了kotlin怎么解决呢？
kotlin里可以使用内联类解决。

谨慎使用多进程

我们知道android每个进程使用的内存是有限的，如果一个app在一个进程中使用过多的内存会抛出oom。所以多开一个进程可以多一倍可用的内存。
但是一个进程fork出来的时候就已经占用一部分内存了，因为空进程本身就拥有一些系统共享的资源，所以在设备本身物理内存不多的时候.就需要谨慎了，不然本不多的内存会雪上加霜。

谨慎使用Large Heap

使用Large Heap有可能会让我们的进程能够使用更多的内存，之所以说是有可能是因为有些手机os使用Large Heap后是没有变化的。

使用Large Heap除了能让应用使用更多的内存之外还有一些弊端，更大的内存控件必然会导致gc过程更久，有可能会导致gc的时候应用卡顿。

使用NDK

NDK的代码是直接在物理内存上分配内存的，所以不受虚拟机限制。理论上可以使用全部可分配的物理内存。
比如一些游戏和地图软件因为对内存的使用比较多，所以有一部分功能会直接用native 代码写的，并且native代码执行效率也会更高
o/flowchart.js/