android内存管理，垃圾回收策略的疑惑

Question

android内存管理gcdalvikvm参数

Answer 1

我之前处理过heap的bug，对配置的Prop研究过，看下http://blog.csdn.net/ykdsea/article/details/38519511
但是你是写一个app是没有办法修改这写prop的，如果你的数据特别零碎，最好自己做内存管理。

Answer 2

比较纳闷的是android中有个隐藏的vmRuntime，通过反射可以设置内存的利用率，却不能设置heapminfree等。那内存管理怎么做的呢，这个我不太懂呢

Answer 3

比较纳闷的是android中有个隐藏的vmRuntime，通过反射可以设置内存的利用率，却不能设置heapminfree等。那内存管理怎么做的呢，这个我不太懂呢
Runtime应该用处不大了，因为不少prop是启动的时候就已经使用了，重新设置已经没有用了。而且对于你的case来说，是内存占用比较大，修改这些prop并不能改变这个事实的。
我是建议把对象放到native去管理。

Answer 4

比较纳闷的是android中有个隐藏的vmRuntime，通过反射可以设置内存的利用率，却不能设置heapminfree等。那内存管理怎么做的呢，这个我不太懂呢
Runtime应该用处不大了，因为不少prop是启动的时候就已经使用了，重新设置已经没有用了。而且对于你的case来说，是内存占用比较大，修改这些prop并不能改变这个事实的。
我是建议把对象放到native去管理。恩恩，是很大的内存，能达到一百多兆，放到native如何管理，能给个方向吗？这一块没有接触过，就没有办法在应用层设置gc策略的吗？减少gc次数，我看有个systemproperties应该存储了系统prop中的参数，android每个应用都会开启一个dalvik，按理来说应用本身可以对dalvik进行特殊的设置的呀，真的谢谢你了

Answer 5

比较纳闷的是android中有个隐藏的vmRuntime，通过反射可以设置内存的利用率，却不能设置heapminfree等。那内存管理怎么做的呢，这个我不太懂呢
Runtime应该用处不大了，因为不少prop是启动的时候就已经使用了，重新设置已经没有用了。而且对于你的case来说，是内存占用比较大，修改这些prop并不能改变这个事实的。
我是建议把对象放到native去管理。恩恩，是很大的内存，能达到一百多兆，放到native如何管理，能给个方向吗？这一块没有接触过，就没有办法在应用层设置gc策略的吗？减少gc次数，我看有个systemproperties应该存储了系统prop中的参数，android每个应用都会开启一个dalvik，按理来说应用本身可以对dalvik进行特殊的设置的呀，真的谢谢你了
dalvik vm是每个进程都有一个，但是你要看看这些参数都有什么意义。gc的速度影响有两个方面，一个是object的数量，另外一个heap的大小。
object的数量，这个是你app绝对的，这些参数不会有影响。
对于heap当前的大小，这几个prop有一定的影响，但是对于你memory消耗本来就很高的情况下，我觉得差距不会大的。放到native管理，就是说你这些对象要用malloc来申请，提供接口让java层可以操作这些对象。如果都是小对象，那么可以用pool来管理，防止碎片化。

Answer 6

第一：增加申请内存大小： android:largeHeap="true"
第二：分散内存， 将你的应用分散在多个进程里面。 dalvik.vm.heapminfree,dalvik.vm.heapmaxfree这些属性属于静态系统属性，运行时修改是没有用的。

Answer 7

比较纳闷的是android中有个隐藏的vmRuntime，通过反射可以设置内存的利用率，却不能设置heapminfree等。那内存管理怎么做的呢，这个我不太懂呢
Runtime应该用处不大了，因为不少prop是启动的时候就已经使用了，重新设置已经没有用了。而且对于你的case来说，是内存占用比较大，修改这些prop并不能改变这个事实的。
我是建议把对象放到native去管理。恩恩，是很大的内存，能达到一百多兆，放到native如何管理，能给个方向吗？这一块没有接触过，就没有办法在应用层设置gc策略的吗？减少gc次数，我看有个systemproperties应该存储了系统prop中的参数，android每个应用都会开启一个dalvik，按理来说应用本身可以对dalvik进行特殊的设置的呀，真的谢谢你了
dalvik vm是每个进程都有一个，但是你要看看这些参数都有什么意义。gc的速度影响有两个方面，一个是object的数量，另外一个heap的大小。
object的数量，这个是你app绝对的，这些参数不会有影响。
对于heap当前的大小，这几个prop有一定的影响，但是对于你memory消耗本来就很高的情况下，我觉得差距不会大的。放到native管理，就是说你这些对象要用malloc来申请，提供接口让java层可以操作这些对象。如果都是小对象，那么可以用pool来管理，防止碎片化。要用到c++吗？是通过jni调用吗？这个不太懂，能具体指导一下吗？麻烦你了！

Answer 8

增加申请内存我知道，可是这个分散内存具体怎么进行啊，也没有找到相关可实施的具体做法，还希望你解惑，谢谢你
因为内存是以进程为分配单位的， 每个进程的可分配内存是独立计算的， 所以分散内存的意思就是分散到不同进程中。
在Androidmanifest里面，如果比较独立的模块，配置android:process属性。 

Answer 9

增加申请内存我知道，可是这个分散内存具体怎么进行啊，也没有找到相关可实施的具体做法，还希望你解惑，谢谢你
因为内存是以进程为分配单位的， 每个进程的可分配内存是独立计算的， 所以分散内存的意思就是分散到不同进程中。
在Androidmanifest里面，如果比较独立的模块，配置android:process属性。 那是不是两个进程之间就不能相互的访问数据了呢，彼此都独立了，

Answer 10

我觉得还得从app怎么样使用内存来着手解决这个问题。
思路无非就是时间换空间。

Answer 11

增加申请内存我知道，可是这个分散内存具体怎么进行啊，也没有找到相关可实施的具体做法，还希望你解惑，谢谢你
因为内存是以进程为分配单位的， 每个进程的可分配内存是独立计算的， 所以分散内存的意思就是分散到不同进程中。
在Androidmanifest里面，如果比较独立的模块，配置android:process属性。 那是不是两个进程之间就不能相互的访问数据了呢，彼此都独立了，是的， 不过还是可以通过service,provider等方式来相互访问。

Answer 12

目前遇到的问题就是：由于内存使用的太大，内存里面保存了大量我所需要的数据，当堆达到100多m的时候，只是继续加载几兆数据都耗时特别长

这个和具体需求有关。你能不能解释一下你的需求？
我觉得类似需求的程序，都有替代方法解决。我前一阵写过一个程序是要给非常多的数据做排序，在内存里完全装不下。
我的程序需要先加载很大的xml文件。x数据加载完以后大概有100多兆了，然后在应用中做操作的时候，就会去调用部分数据（1m到2m左右）将数据填充到我创建的对象里面进而显示出来。操作的时候gc20多次，耗时20s左右有效。不知道该如何优化

Answer 13

目前遇到的问题就是：由于内存使用的太大，内存里面保存了大量我所需要的数据，当堆达到100多m的时候，只是继续加载几兆数据都耗时特别长

这个和具体需求有关。你能不能解释一下你的需求？
我觉得类似需求的程序，都有替代方法解决。我前一阵写过一个程序是要给非常多的数据做排序，在内存里完全装不下。
我的程序需要先加载很大的xml文件。x数据加载完以后大概有100多兆了，然后在应用中做操作的时候，就会去调用部分数据（1m到2m左右）将数据填充到我创建的对象里面进而显示出来。操作的时候gc20多次，耗时20s左右有效。不知道该如何优化
是用sax解析吗？如果是dom解析可以换成sax。
我不知道你加载的数据的使用方式，但是可以考虑把部分数据换出到文件上（类似OS的内存页面换出机制）。

Answer 14

目前遇到的问题就是：由于内存使用的太大，内存里面保存了大量我所需要的数据，当堆达到100多m的时候，只是继续加载几兆数据都耗时特别长

这个和具体需求有关。你能不能解释一下你的需求？
我觉得类似需求的程序，都有替代方法解决。我前一阵写过一个程序是要给非常多的数据做排序，在内存里完全装不下。
我的程序需要先加载很大的xml文件。x数据加载完以后大概有100多兆了，然后在应用中做操作的时候，就会去调用部分数据（1m到2m左右）将数据填充到我创建的对象里面进而显示出来。操作的时候gc20多次，耗时20s左右有效。不知道该如何优化
是用sax解析吗？如果是dom解析可以换成sax。
我不知道你加载的数据的使用方式，但是可以考虑把部分数据换出到文件上（类似OS的内存页面换出机制）。

本质上还是你业务逻辑的算法设计问题，怎么样去分解问题域，怎么样分而治之。

Answer 15

xml解析完成之后你可以转移到数据库处理啊 

Answer 16

目前遇到的问题就是：由于内存使用的太大，内存里面保存了大量我所需要的数据，当堆达到100多m的时候，只是继续加载几兆数据都耗时特别长

这个和具体需求有关。你能不能解释一下你的需求？
我觉得类似需求的程序，都有替代方法解决。我前一阵写过一个程序是要给非常多的数据做排序，在内存里完全装不下。
我的程序需要先加载很大的xml文件。x数据加载完以后大概有100多兆了，然后在应用中做操作的时候，就会去调用部分数据（1m到2m左右）将数据填充到我创建的对象里面进而显示出来。操作的时候gc20多次，耗时20s左右有效。不知道该如何优化
是用sax解析吗？如果是dom解析可以换成sax。
我不知道你加载的数据的使用方式，但是可以考虑把部分数据换出到文件上（类似OS的内存页面换出机制）。

本质上还是你业务逻辑的算法设计问题，怎么样去分解问题域，怎么样分而治之。我也想换解析方式，可是那些处理逻辑已经封装在公司的框架里面了，我所能处理的就是调用公司框架，在那么大的内存状况下，如何能运行起来流畅

Answer 17

啊，绑定什么东东啊，这个我不清楚呀，还请赐教呀应该就是bundle吧