基于逃逸分析的优化是 Proguard 的一项计划功能。同时，是否有任何现有的工具，如 proguard，已经进行了需要逃逸分析的优化？
问问题
1320 次
2 回答
3
是的，我认为Soot 框架执行逃逸分析。
于 2010-06-14T16:17:54.553 回答
1
您对编译器级别的逃逸分析有何期望？Java 类更像是 C 中的目标文件——它们在 JVM 中链接，因此只能在单一方法级别执行转义分析，其可用性有限并且会妨碍调试（例如，您将有几行代码通过你不能踩）。
在 Java 的设计中，编译器非常愚蠢——它检查正确性（如 Lint），但不尝试优化。智能部件被放置在 JVM 中——它使用多种优化技术在当前条件下在当前平台上生成性能良好的代码。由于 JVM 知道当前加载的所有代码，它可以假设比编译器更多的内容，并执行推测优化，这些优化在假设失效时被恢复。HotSpot JVM 可以在函数运行时用更优化的版本动态替换代码（例如，在循环中间，因为代码变得“更热”）。
当不在调试器中时，具有非重叠生命周期的变量被折叠，不变量被提升出循环，循环被展开等等。所有这些都发生在 JIT-ted 代码中，并且取决于在这个函数中花费了多少时间（花时间优化从不运行的代码没有多大意义）。如果我们预先执行其中的一些优化，JIT 的自由度就会降低，总体结果可能是净负数。
另一个优化是不逃避当前方法的对象的堆栈分配 - 这是在某些情况下完成的，尽管我在某处读过一篇论文，执行严格的逃避分析的时间与优化所获得的时间表明这是不值得的，所以当前的策略更具启发性。
总体而言，JVM 对原始代码的了解越多，它对它的优化就越好。JVM 所做的优化也在不断改进，因此我只会在谈到手机等非常受限和基本的 JVM 时才会考虑编译代码优化。在这些情况下，您无论如何都希望通过混淆器运行您的应用程序（以缩短类名等）
于 2010-06-20T02:39:58.110 回答