关于android 内存的分配机制分析以及如何优化android的内存分配

Wince.Android

关于android 内存的分配机制分析以及如何优化android的内存分配 [复制链接]

事情的源头是我的Sate210 （S5pv210） 板子，我用三星代理商给的android2.3.4 和google下的android2.3.7 源码编译出来的system.img烧进去，发现启动很慢很慢，运行起来也很慢很慢。
让我怀疑是否是我没用起来我的Sate210 的512M DDR2 内存，因为我本来Sate210 的光盘system.img 自带镜像运行起来是速度很快的，非常快。检查了一番，虽然uboot我更新了支持ext4的新的uboot，但是应该是512M 内存都跑起来了的。后来用cat  /proc/meminfo  命令发现，原来是Sate210 的android源码是经过优化的，网上下的android源码包占用非常大的内存，没有1G byte 以上的内存根本用不了的。跑起来剩余8MB内存，你说能不慢吗？
来吧，现在来玩一下如何优化android内存吧。O(∩_∩)O~。

Wince.Android

安卓系统不用在意剩余内存的大小，其实很多人都是把使用其他系统的习惯带过来来了。android大多应用没有退出的设计其实是有道理的，这和系统对进程的调度机制有关系。如果你知道java，就能更清楚这机制了。其实和java的垃圾回收机制类似，系统有一个规则来回收内存。进行内存调度有个阀值，只有低于这个值系统才会按一个列表来关闭用户不需要的东西。当然这个值默认设置得很小，所以你会看到内存老在很少的数值徘徊。但事实上他并不影响速度。相反加快了下次启动应用的速度。这本来就是android标榜的优势之一，如果人为去关闭进程，没有太大必要。特别是使用自动关进程的软件。

　　到这里有人会说了，那为什么内存少的时候运行大型程序会慢呢？其实很简单，在内存剩余不多时打开大型程序，会触发系统自身的调进程调度策略，这是十分消耗系统资源的操作，特别是在一个程序频繁向系统申请内存的时候。这种情况下系统并不会关闭所有打开的进程，而是选择性关闭，频繁的调度自然会拖慢系统。所以，论坛上有个更改内存阀值的程序可以有一定改善。但改动也可能带来一些问题，取决于值的设定。

　 那么，进程管理软件有无必要呢？有的。就是在运行大型程序之前，你可以手动关闭一些进程释放内存，可以显著的提高运行速度。但一些小程序，完全可交由系统自己管理。

　 那么，如果不关程序是不是会更耗电。 说说android后台的原理，你就明白了。android的应用在被切换到后台时，它其实已经被暂停了，并不会消耗cpu资源，只保留了运行状态。所以为什么有的程序切出去重进会到主界面。但是，一个程序如果想要在后台处理些东西，如音乐播放，它就会开启一个服务。服务可在后台持续运行，所以在后台耗电的也只有带服务的应用了。这个在进程管理软件里能看到，标签是service。至于广播什么的我就不涉及了。所以没有带服务的应用在后台是完全不耗电的，没有必要关闭。这种设计本来就是一个非常好的设计，下次启动程序时，会更快，因为不需要读取界面资源，何必要关掉他们抹杀这个android的优点呢。

　　还有一个，为什么android一个应用看起来那么耗内存。大家知道，android上的应用是java，当然需要虚拟机，而android上的应用是带有独立虚拟机的，也就是每开一个应用就会打开一个独立的虚拟机。这样设计的原因是可以避免虚拟机崩溃导致整个系统崩溃，但代价就是需要更多内存。

　　以上这些设计确保了android的稳定性，正常情况下最多单个程序崩溃，但整个系统不会崩溃，也永远没有内存不足的提示出现。大家可能是被 windows毒害得太深了，总想保留更多的内存，但实际上这并不一定会提升速度，相反却丧失了程序启动快的这一系统特色，很没必要。

——这个说法是内存比较大的时候才好的，要不然，还没开其他应用，就已经几个M的内存剩余了，想跑的快都难。所以android 内存大跑的快，一旦内存小，O(∩_∩)O哈哈哈~卡死人。

Wince.Android

http://wenku.baidu.com/view/8697c44ce45c3b3567ec8bfb.html

这个也是有点帮助的解释。

Wince.Android

Android单个进程内存分配策略

android不同设备单个进程可用内存是不一样的，可以查看/system/build.prop文件。

# This is a high density device with more memory, so larger vm heaps for it.
dalvik.vm.heapsize=24m

上面heapsize参数表示单个进程可用的最大内存，单如果存在如下参数：

dalvik.vm.heapgrowthlimit=16m

largeheaplimit参数表示单个进程内存被限定在16m,即程序运行过程中实际只能使用16m内存，不过有一个办法可以解决，编辑AndroidManifest.xml中的Application节点，增加属性largeheap="true"参数.

Wince.Android

在 system/build.prop  里参看。
dalvik.vm.heapsize
这个我感觉仅仅是一个小的方面。这个限制就是一旦超过这个内存，这个应用程序就不执行了，但是我还没运行太多程序，这个可用内存已经很少了，真是........太挫了。

Wince.Android

Android虚拟机(DVM)内存分配——内存溢出问题
大家都知道Android的上层应用是基于 Dalvik Virtual Machine的。Dalvik VM的特点是基于寄存器，相比SUN的JVM（基于堆栈，没有寄存器）来说，理论上完成同样的功能需要的指令条数少，但是指令集复杂。到了Android2.2，Dalvik终于实现了JIT（Just In Time）功能，前进了一大步。


近期我们遇到OutOfMemory的错误，通常是堆内存溢出。网上有些帖子说可以通过函数设置应用的HEAP SIZE来解决这个问题，其实是不对的。

VMRuntime.getRuntime().setMinimumHeapSize(NewSize);

堆（HEAP）是VM中占用内存最多的部分，通常是动态分配的。堆的大小不是一成不变的，通常有一个分配机制来控制它的大小。比如初始的HEAP是4M大，当4M的空间被占用超过75%的时候，重新分配堆为8M大；当8M被占用超过75%，分配堆为16M大。倒过来，当16M的堆利用不足30%的时候，缩减它的大小为8M大。重新设置堆的大小，尤其是压缩，一般会涉及到内存的拷贝，所以变更堆的大小对效率有不良影响。


上面只是个例子，不过可以看到三个参数：max heap size, min heap size, heap utilization（堆利用率）。


Max Heap Size，是堆内存的上限值，Android的缺省值是16M（某些机型是24M），对于普通应用这是不能改的。函数setMinimumHeapSize其实只是改变了堆的下限值，它可以防止过于频繁的堆内存分配，当设置最小堆内存大小超过上限值时仍然采用堆的上限值（16M），对于内存不足没什么作用。


setTargetHeapUtilization(float newTarget) 可以设定内存利用率的百分比，当实际的利用率偏离这个百分比的时候，虚拟机会在GC的时候调整堆内存大小，让实际占用率向个百分比靠拢。

//程序onCreate时调用
private final static floatTARGET_HEAP_UTILIZATION = 0.75f;
VMRuntime.getRuntime().setTargetHeapUtilization(TARGET_HEAP_UTILIZATION);



总结：
    手机应用开发资源是很有限的，堆内存的上限值只有16M。不过只要代码写的好，这个值对于目前的手机应用需求已经足够了。
    如果出现内存溢出问题，把精力放在代码优化上吧。