我有一个应用程序,我正在设置近50个类android:largeHeap="true",如下所示.这是一个好习惯吗？
<application
android:name=".MyApplication"
android:allowBackup="true"
android:icon="@drawable/ic_launcher"
android:label="Mall"
android:largeHeap="true"
android:logo="@drawable/logo_for_up"
android:screenOrientation="portrait"
android:theme="@style/AppTheme" >
</application>
请建议使用它的优点和缺点.
我得到记忆问题,这就是我问这个问题的原因.
在启用largeHeap选项之前,我正在处理大型位图,它几乎消耗了应用程序可用的整个内存,并且通过导航回收它并加载新的内存几乎可以在完整的堆上运行.但是,当某些操作需要更多内存时,应用程序崩溃.所以我启用largeHeap=true了更多的内存.
但这样做有一个意外的行为,它看起来像recycle()位图的方法不工作的大部分时间,并在58MB工作的内存(并超过有时抛出的应用程序OutOfMemoryException)现在消耗内存成倍而且还在不断增加(目前测试我确实来了231Mb分配的内存),预期的行为是内存管理继续工作,应用程序将不会使用超过60Mb.
我怎么能避免这种情况？还是有效地回收位图？
编辑:实际上,我OutOfMemoryError在设备上分配超过390Mb的内存时给了它一个.读取GC_*日志显示只有GC_FOR_ALLOC有时会释放3.8Mb,但几乎从未在其他GC运行中释放过某些内容.
最近我将应用程序的最大内存峰值从100 MB减少到45 MB,我很好奇使用android有什么缺点:largeHeap ="true" 除了可能会推动其他应用程序内存不足之外？如果规模不足以证明推出其他应用程序是不合理的,那么它是不是一个很好的故障保护,例如,如果你的应用程序只会在会议中使用四天,那么崩溃可能是灾难性的？还是有一些我正在寻找的其他骗局？
我们有一个为平板电脑制作的客户应用程序，我们需要的不仅仅是常规堆，因此我们的应用程序在 AndroidManifest.xml 中为应用程序标记定义了 largeHeap="true" 属性。这很好用。
但是，当我们使用 android.test.InstrumentationTestRunner 和 android.test.ActivityInstrumentationTestCase2 在设备上运行测试时，当我们尝试使用超过标准堆的内存时，我们会收到 java.lang.OutOfMemoryError 错误。
我们尝试在测试项目以及应用程序项目的 AndroidManifest.xml 中设置 largeHeap="true"。
在配置了大堆大小的模拟器上运行测试是可行的。该设置增加了一般最大堆大小，而不是 LargeHeap 的限制。这是一种解决方法，但我们也想在实际设备上运行测试。
有没有办法在具有大堆的设备上运行测试？
我很想在Manifest中使用Android:LargeHeap ="true"选项来获得额外的内存(我们在高分辨率的1980x1200显示器上处理5+ MB位图,并且很快就会期待更大的显示.
我已经完成了处理Android中用于位图的糟糕内存处理的所有常规技巧(即无法知道碎片内存中是否有足够大的洞,而不是试图祈祷它不会崩溃).我已经花了数周优化,修剪和应用其他技巧来最小化内存并防止崩溃.这是在2.x vs 3.x/4.x中可以完成哪些功能的技巧,但是将它们全部保存在一个应用程序中.无需指出"如何优化位图" - 我已经完成了这些并应用了我能做到的事情.
版本2.x不支持LargeHeap,并且我在2.x中不需要LargeHeap选项的较低分辨率屏幕使用不同的图像.(也没有内存不足问题).
当android:minSdkVersion ="8"时,它根本不允许使用Android:LargeHeap选项.
有没有办法有条件地为包含3.x的系统包含LargeHeap,并在2.x中忽略它？或者如果检测到3.x,应用程序本身是否尝试设置LargeHeap？我找不到任何办法,但也许我忽略了一些技巧.
我也意识到LargeHeap相当糟糕,但我们已经没有其他技巧了.理想情况下,只有在OnCreate程序中真正需要(和允许)时,以编程方式执行LargeHeap会很好.