OOM_ADJ
对于低内存的时候，我们总是想尽量杀掉background的app，尽量保留persist service（比如输入法）,让前台app能够流畅的运行。
1，background app的adj尽量设高一些，但是max和mini之前，尽量还是要保留一些差距，这样让系统可以逐步去kill进程，
而不是一次杀掉很多。一次杀掉很多app很容易造成系统卡顿。
2，previeous app和home launcer的adj一定要独立出来，并且不能设置太低，previous app可能会占用很多的内存。
SWAP
swap主要是阀值的设置，什么时候去触发swap。
swap的使用主要目标是，在为了保证前台app的正常运行，在内存不够的情况作为一个补充。比如browser在小内存机器上
只能打开2个page，如果开了swap，可以打开5个page。
对于后台的其他程序，不需要使用swap，因为swap毕竟会降低一些性能，而是尽量杀掉太慢来让前台应用尽量的使用物理内存。
所以swap的阀值大于Persist service的adj比较合适，这样保证必须的服务还存在，让前台应用可以正常运行。
CMA
low memory killer在计算剩余内存的时候，cma的确是个头疼的问题。
cma不是任何时间可以随意使用的，下一个时刻他可能就需要分配。
cma的使用，基本策略应该还是给前台app用，保证他的运行，对于后台app，不要计算cma为free。
如果当前app不需要使用到cma相关的驱动：
在后台app都被杀光的情况下，可以使用cma的内存。当启动一个新的app的时候，这个app会变成previous app，
而当前内存又是低于previous app要求的free的，所以他会被kill，那么cma的内存就被放出来了，不会出现问题。
如果当前的app会使用cma的内存：
比如当前activity不会使用，但是下一个acitivty可能就需要使用cma相关的驱动，这种情况下cma就无法使用了（或者只能使用部分），因为你不知道什么时候系统会需要使用cma的内存。
是否有途径可以知道当前app是否使用到cma相关的驱动，使用了多少？
在相关的java类没有被使用前是无法知道的，所以目前来看是没法处理的。
那么目前只能把cma当做一个节省内存的途径来使用了。