静态Java字节码优化器（如proguard的）与逃逸分析？

Question

基于逃逸分析优化为Proguard的有计划的功能。在此期间，有没有像proguard的任何现有的工具，已经在做这需要逃逸分析优化？

Answer 1

是的，我认为煤烟框架进行逃脱分析

Answer 2

那你从编译器级别逃逸分析指望什么呢？ Java类更像C的对象的文件 - 它们在JVM链接，因此只能在单方法的水平，这是有限的可用性来执行逃逸分析和将阻碍调试（例如，你将有代码行通过你不可能一步到位）。

在Java的设计，编译器是相当愚蠢的 - 它检查的正确性（如皮棉），但不尝试优化。智能片放在JVM - 它采用多种优化技术来产生以及当前平台上执行代码，在当前条件下。由于JVM知道所有当前加载它可以承担很多比编译并执行其恢复的假设是无效的瞬间投机优化的代码。热点JVM可以在功能正在运行（例如，在环的中部作为代码获取“热”）在飞行替换更优化版本的代码。

当没有调试器，具有非重叠寿命变量倒塌，不变量环吊出，环路展开，等等这一切发生在JIT泰德代码和完成依赖于有多少时间花在这个功能（它没有太大的意义，花时间优化代码，从来没有运行）。如果我们进行一些这些优化前期时，JIT将有更少的自由和总的结果可能是一个净负。

另一种优化是，不要逃避当前方法的对象堆栈分配 - 这是在某些情况下完成的，虽然我读报纸的地方，时间VS通过优化获得的时间进行严格的逃逸分析表明，它不值得它，所以目前的策略是更多的启发。

总体而言，更多的信息，JVM有关于你的原代码，更好它可以优化它。和JVM确实在不断改善优化，因此我会考虑的编译代码的优化，只有当谈到非常严格的限制和基本的JVM，如移动电话。在这些情况下仍要贯穿混淆你的应用程序（缩短类名，等等。）