【问题标题】：How to measure class memory size on Dalvik JVM?如何测量 Dalvik JVM 上的类内存大小？
【发布时间】：2015-04-13 07:44:16
【问题描述】：
阅读'Managing You App's Memory' 文章后，我开始通过编写“干净代码”来研究内存影响。我的意思是，例如，有一个责任的小类，面向接口的编程，做一件事的方法等。
但是，我不确定如何获得类或接口的二进制表示在 Dalvik JVM 中实际占用多少空间的实际读数。我目前正在查看中间文件夹中已编译类的字节大小。在这里我可以看到，不是让一个大方法做 3 件事，而是 3 个不同的方法实际上增加了大约 100 个字节。 问题：这项措施有效吗？
我猜想在创建 dex 时，或者在构建版本时由 proguard 或通过类加载器进行一些优化，但是我对这个主题相当陌生。
非常感谢任何解释 Dalvik 记忆模型的文献的良好链接
【问题讨论】：
标签：
android
memory-management
dalvik
【解决方案1】：
每个类都有固定的类定义开销，加上每个方法和字段的几个字节，以及静态字段的一些存储。您可以在 Dalvik 源代码 (struct ClassObject) 中查看结构。
您确实为每个类、字段和方法支付了少量成本，因此如果您用一个巨大的方法编写整个程序，您将节省一些空间。这不是一个好主意。 （一些代码优化器/混淆器程序会做这样的事情，生成大型复杂的 switch 语句。）
应用程序的开销很难衡量，因为在 Dalvik 中，大部分开销都位于本机堆或“线性分配”区域（Facebook 必须达到hack around 的限制）。中间 .class 文件的大小完全没有代表性。 .dex 文件的大小也不是非常有用，因为其中大部分都存在于内存映射 RAM 中，与“脏” RAM 相比，它对系统的负担更小（有关内存使用情况，请参阅 hackbod's post）。
我能提供的最好建议是编写易于维护的代码，而不必过多担心细节。如果您将每一行代码都放在自己的类中，您可能会遇到麻烦，但如果您走极端，代码无论如何都会变得难以维护。
现代应用程序中的大部分内存成本都与图形有关，因为显示器越来越大，越来越密集，而不是因为编码风格或数量。 Facebook 为使其超大型应用程序运行而采取的措施是将姜饼设备上的 VM 缓冲区大小从 5MB 增加到 8MB，这与应用程序的其他需求相比微不足道。