什么是Android应用程序中最大的内存?

时间:2012-12-02 18:40:05

标签: android

我正在尝试优化应用的内存使用情况。从广播接收器和服务到位图和静态变量,几乎都有。 我认为我的应用程序中有许多内存泄漏我应该处理,但它永远不会给出outofmemory异常。

我想知道避免过多内存消耗的最佳方法是什么,我是否必须始终回收位图?因为我从来没有这样做,注册带有活动上下文或应用程序上下文的广播接收器是否合适,使用静态变量来访问从活动到活动的数据是否安全,我是否应该为我的活动中的每个变量赋予空值它们可以被垃圾收集或者没有必要吗?

有很多问题但是就像它是我的第一个Android应用程序一样,代码在某些地方做得很糟糕但很复杂。

对于性能卓越且做得好的应用程序,最佳做法是什么?

2 个答案:

答案 0 :(得分:2)

答案 1 :(得分:2)

最重要的

如果您正在寻找内存优化,最重要的一步是检查与垃圾收集器相关的logcat消息。类似于:

12-01 19:12:09.138: D/dalvikvm(31828): GC_CONCURRENT freed 158K, 3% free 10259K/10503K, paused 15ms+0ms, total 19ms

第一个值是GC在此次运行中释放的金额,第二个值是您的应用程序使用的金额,第三个值是分配给您的应用程序的金额。随着您的应用程序需要增加内存,最后一个值会增加,直到alocatted内存达到系统允许的最大数量,并且您的应用程序被终止。 Honey Comb之前的SDK必须包含更多值,即Dalvik Vm之外的内存,通常是Bitmap个对象。

因此,最重要的测试是通过使用您的应用程序一段时间来完成的,并检查已使用/已分配内存的值是保持稳定还是持续增加。

如果它保持稳定,你的分析就完成了,你可以去喝咖啡: - )

它不断增加,然后开始检查你的记忆去哪里可能会更好......

怎么做

使用良好内存的最基本的好规则是释放(归零)任何不再需要的对象。对于大多数非静态对象,这是自动完成的,因此您应该首先对static个对象进行处理,确保在不需要时为它们指定null。

棘手的

内存泄漏的最常见原因是静态对象未正确管理并持有对以下内容的引用:

  • 上下文
  • 视图(包含对上下文的引用(也可能是对位图的引用)
  • 线程(GC不易收集)
  • 处理程序(其中包含对上下文的引用)
  • BitMap(主要用于Honey Comb之前的版本,其中GC在收集它时没有那么有效)

最后的注释

如果您可以花一个小时,请观看Google IO 2011中的视频,其中Patrick Dubroy解释了如何使用MAT来识别内存泄漏:Google I/O 2011: Memory management for Android Apps

这真的帮助我在我的应用程序中启动了内存隧道。

问候。