Java 如何减少节俭膨胀

我目前正在尝试减少Android应用程序的方法数，以便让它重新编译。我想改进的一个方面是正在使用的所有节俭生成的文件。过度膨胀的简单储蓄结构变得如此疯狂

例如，以下节俭结构：

struct AccessoryLocalization {
    1: required string displayName;
    2: required string displaySummary;
}

变成475行的java类！！！这对我来说似乎很疯狂，我不完全理解为什么它会产生这么多。我想知道是否有人知道如何让节俭在代码生成中不那么冗长

---

我正在使用Thrift 0.9.0，并在运行Thrift命令时使用

java:android_legacy

标志。我只关心如何支持姜饼和姜饼。所以这肯定是一个老问题，但本周我发布了一个特定于Android的Thrift编译器和运行时，解决了这些问题：

它生成的代码

使用尽可能少的方法-无getter/setters/isSetters/setIsSetters

对Proguard更友好（不在静态映射中存储伪反射TField）

提供了一些特定于Android的选项，如

@Nullable

/

@NonNull

注释

---

我们的应用程序从2万个节俭类方法发展到5万个。希望它能帮助您（或其他发现此问题的人）。

也许像Proguard这样的工具可以帮助您？您是对的，我同意生成的代码中有些部分可能不那么冗长。但OTOH生成的代码（不仅仅是Thrift）一般不打算逐行读取和/或打印出来。主要目标是使代码能够正确工作，速度极快。->我想问一下，除了担心更大的文件之外，到底是什么问题？如果有（真正的）问题，我们应该做点什么。我建议在邮件列表中启动一个线程，讨论您认为不必要、臃肿或过于冗长的部分。主要问题是在Android中，给定应用程序中允许的方法数量有64k的限制。当你开始包含多个巨大的库时，不难找到它：例如AWS、Google Play Services、Google Analytics等等。有一些方法可以解决这个问题，但最终这是一个痛苦。即使是在方法限制下，你仍然有dalvik的linearalloc缓冲限制…尤其是姜饼。拥有大量节省的资源似乎是帮助缓解这些问题的一个简单方法。Proguard可以有所帮助，但如果所有的版本都是模糊的发布版本，则很难开发。@Jay Soyer您可以在其中添加-dontobfuscate选项，但不会这样做。这允许您将其用作纯粹的优化工具。