应用内存限制

不同的ROM 限制不一样，下面以乐视电视分析：

dalvik.vm.heapgrowthlimit = 96M
在应用在Manifest里面没有设置android:largeHeap="true"，则应用最大使用的内存为96M
2.dalvik.vm.heapsize=256m
在应用在Manifest里面没有设置android:largeHeap="true"，则应用最大使用的内存为256M
3.dalvik.vm.heapstartsize = 8M 应用在创建时候分配的内存的原始大小，如果APP分配内存不足会成倍扩容，值小于dalvik.vm.heapgrowthlimit或dalvik.vm.heapsize
前三者限制的是堆的起始大小，增长的限制，一般是系统内存越大设置的值越大。如果dalvik.vm.heapstartsize设置较大会增快应用创建时候的启动速度，其余两个限制了内存最大申请的内存，增大会减少GC触发的频率，增大内存的消耗，对调优无实质影响；如果超过此值会分配不到内存空间，进入回收软引用阶段，这里gcForMalloc的参数是ture，所以需要回收软引用。然后调用dvmHeapSourceAllocAndGrow尝试分配，如果失败则抛出OOM。
4.dalvik.vm.heaptargetutilization=0.75 堆得利用率，可以设定内存利用率的百分比，当实际的利用率偏离这个百分比的时候，虚拟机会在GC的时候调整堆内存大小，让实际占用率向个百分比靠拢。当前理想的堆内存利用率. GC后, Dalvik的Heap内存会进行相应的调整, 调整到当前存活的对象的大小和 / Heap大小接近这个选项的值, 即这里的0.75. 注意, 这只是一个参考值.
5.dalvik.vm.heapminfree 堆最小释放地址
dalvik.vm.heapmaxfree 堆最大释放的地址
堆利用率heaptargetutilization、堆最空闲内存heapminfree和堆最空闲内存heapmaxfree这三个值的设置则对垃圾回收(GC)的某些性能有影响。
GC触发后，垃圾回收回收应再使的垃圾对象，这样应的空闲内存就可能很或者由于回收垃圾够多导致空闲内存还是很。如果此空闲内存很，Android系统出于提内存率的考虑是会把这么块内存都给应程序的，它会根据应预先设定的堆率 (heaptargetutilization)、最和最空闲内存数(heapmaxfree、heapminfree)等参数来调整此空闲内存的 ;如果此空闲内存很，那么势必此空闲内存将很快分配光，下次GC会来的很快，所以遇到这种情况，ART会扩此空闲内存的。
计算扩展方法
此计算法先会获取个堆扩展系数，它是根据前后台GC来区分的，般前台GC此系数是2，也就是把空闲内存扩 2倍，后台GC此系数是1。因为对于前台GC来说，此时应程序是运行在前台的，如果堆扩展较小，那么空闲内存就会很快的用光，也就是说下次GC来的很快， GC会给应用造成短时间的暂停，影响应用的性能，所以说为了使前台应用有更好的性能，ART运时会给前台应用分配多的堆空闲空间。然后由堆率(utilization)算出论上所需的空闲内存，堆率按照歌的推荐般设为 0.75。此时算出来的堆空余时间还不是最终结果，还需考虑另外两个限制值:最小空闲内存 (min_free_)和最空闲内存(max_free_)。也就是需要把预留空闲内存控制在两倍的最小空闲内存和两倍的最空闲内存之间。这样获得的target_size才是堆的最终，也就是已分配对象的和预空闲内存之和。

乐视6A918,6A928平台：
dalvik.vm.heapstartsize=8m
dalvik.vm.heapgrowthlimit=96m
dalvik.vm.heapsize=256m
dalvik.vm.heaptargetutilization=0.75
dalvik.vm.heapminfree=512k
dalvik.vm.heapmaxfree=8m
乐视938平台
dalvik.vm.heapstartsize=8m
dalvik.vm.heapgrowthlimit=192m
dalvik.vm.heapsize=512m
dalvik.vm.heaptargetutilization=0.75
dalvik.vm.heapminfree=512k
dalvik.vm.heapmaxfree=8m

参考文章
https://www.zhihu.com/question/40371025

更多相关文章

随机推荐