最小化处理程序、消息和包的内存分配

Question

我有一个activity，它经常(每秒几次)通过AIDL将byte[]数据发送到service。service使用message-bundle*将这些消息转发给网络线程的handler。网络线程还不断地接收数据，并以message-bundle的形式发送给handler，service通过AIDL将bundle发送给其他activities。

如您所知，为bundles分配了大量内存。

在查看DDMS上的内存分配后，我看到内存被分配给：

• 正在初始化的bundle
• 正在创建的哈希映射
• 作为哈希表条目添加的byte[]数据

我想把内存分配减少到尽可能少。

是否有更好的方式通过活动/线程发送字节，而不是通过带包的消息？

* message-bundle，指的是以bundle作为数据的message

尝试:创建一个bundle对象池，但这并不能很好地在活动之间进行管理，而且我也不知道如何用byte[]数据预先分配它.

Answer 1

这些字节数组有那么大，你真的需要担心吗？在不了解您的应用程序的情况下，我猜您所描述的应用程序中的瓶颈将出现在网络处理程序中，而不是服务和活动之间的消息传递。除非您在某个地方泄漏了Bundles，否则GC应该处理所有未使用的内存，并恢复它以供应用程序重用。

如果有的话，我会尽量保持这些数组足够小(避免一次分配和回收大量内存)，并发送几条小消息。这样，应用程序不会一次性使用可用内存，让GC以轻松的时间(即CPU空闲时)完成其工作，而不是强制GC立即收集对象。

当然，什么是“太大”或“足够小”是你应该测试在你自己的应用程序，并衡量什么(如果有的话)是什么是通过一种或另一种方法。

更新：

从android站点文章逐字复制

在性能敏感的代码路径中，如视图的布局或绘图方法或游戏的逻辑代码，任何分配都要付出代价。分配太多之后，垃圾收集器会启动并停止应用程序，让它释放一些内存。大多数情况下，垃圾收集发生得足够快，以至于您没有注意到。但是，如果在滚动项目列表或在游戏中试图击败敌人时发生集合，则可能会突然看到应用程序的性能/响应能力下降。--垃圾收集需要100到200毫秒的，这并不少见。比较而言，一个平滑的动画需要在16到33毫秒内画出每一帧。如果动画突然中断10帧，您可以确定您的用户会注意到。

根据您的意见，我将重新考虑GC是否与您的案件相关。堆限制可能在16到32 MB之间。 (上限可能在增长)。假设每秒分配10个字节，每分配64个字节，则每30分钟分配1MB(大约)。如果GC需要200 ms来释放该内存，那么的效果将是可以忽略不计的。我知道这里的数字没有考虑到散列映射或包所需的内存，但它们仍然与我们讨论的数量级有关。现在，考虑一下网络请求从网络中获取64字节的时间。即使它只需要50毫秒，也就是GC所需时间的1/4到1/2，每一个净请求。这甚至不考虑您的活动处理该数据所需的时间。

因此，总之，在重新构造代码以提高其效率之前，请确保您正在修改的步骤实际上是一个瓶颈，否则可能会浪费您的全部精力。只是我的0.02美元。

Answer 2

为了提供一些“流控制”(如果池是空的，线程必须等待消息从其他地方释放)，为了防止失控的malloc/新耗尽我所拥有的小堆，我经常在嵌入的东西上使用池。如果每个池消息包含对其池的私有引用，则管理池更容易。这意味着活动/线程不需要任何池引用来显式地传递给它，从而使它能够将消息释放回池--消息的“释放”方法可以在没有任何参数的情况下完成它，而且如果由于某种原因有多个池，则不存在消息被释放回错误池的危险。

雷格斯·马丁