2

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

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

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

对于性能出色且做得好的应用程序,有哪些最佳实践?

4

2 回答 2

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 在这次运行中释放的数量,第二个是您的应用程序使用的数量,第三个是分配给您的应用程序的数量。最后一个值随着您的应用程序需要的内存增加而增长,直到分配的内存达到系统允许的最大数量,并且您的应用程序被终止。SDK 之前必须Honey Comb有更多的值,即外部使用的内存Dalvik Vm,通常由Bitmap对象使用。

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

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

它不断增加,那么也许最好开始检查你的记忆去向......

该怎么办

实现良好内存使用的最基本的良好规则是释放(清空)您不再需要的任何对象。对于大多数非静态对象,这是自动完成的,因此您应该主要关注static那些,确保在不需要时将 null 分配给它们。

棘手的

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

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

最后说明

如果您可以花一小时,请观看来自 Google IO 2011 的视频,其中 Patrick Dubroy 解释了如何使用 MAT 来识别内存泄漏:Google I/O 2011:Android 应用程序的内存管理

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

问候。

于 2012-12-02T20:21:47.393 回答
2

我认为手册就足够了:http: //developer.android.com/training/best-performance.html

于 2012-12-02T18:52:50.343 回答