Proguard中保留android.support类是否影响优化？是否为常规配置？

嘿，咱们把你这两个关于ProGuard和android.support库的问题拆解清楚：

问题1：-keep class android.support.** { *; } 是否会影响ProGuard的优化效果？ #

那肯定会啊！ProGuard的核心能力就是代码收缩、优化、混淆，这条规则相当于直接给整个android.support包开了“免死金牌”：

• 收缩阶段：ProGuard不会删掉任何android.support里没被你应用实际用到的类、方法或字段，哪怕它们完全是冗余的。
• 优化阶段：ProGuard没法对这些类做任何优化操作——比如内联小方法、移除无用代码分支、简化控制流这些都不行，因为规则强制要求保留所有内容。
• 混淆阶段：这些类的类名、方法名、字段名都不会被重命名，原封不动保留。

说白了，这条规则直接废掉了ProGuard对android.support包的大部分优化能力。

问题2：保留此类是否属于常规做法？若不是，该语句对ProGuard优化的影响程度如何？ #

这绝对不是常规做法，甚至算是一种图省事的“一刀切”懒方案。

为什么不是常规操作？ #

Android官方自带的ProGuard配置（比如proguard-android.txt）已经针对支持库做了非常合理的规则配置——它只会保留你的应用实际依赖的部分，以及支持库内部运行必需的代码（比如处理反射、回调的部分），而不是一股脑保留整个包。官方配置已经帮你平衡了功能和优化效果。

对优化的影响到底有多大？ #

影响真的不小，主要体现在这几点：

• APK体积暴涨：你会把整个android.support库中所有未被使用的冗余代码都打包进APK，轻则增加几MB，重则更多，完全浪费了ProGuard代码收缩的核心价值。
• 运行效率打折扣：虽然不会有特别明显的卡顿，但ProGuard没法对这些类做代码优化，比如内联常用小方法、移除无用分支，会让这些类的运行效率略低于优化后的状态。
• 混淆不彻底：这些类的命名都保持原样，不仅暴露了支持库的结构，也损失了混淆能带来的一点点体积优化。

正确的姿势是什么？ #

1. 优先使用Android官方提供的默认ProGuard配置文件，它已经帮你处理了支持库的大部分规则，不用自己瞎加。
2. 如果遇到支持库相关的崩溃（比如反射找不到类/方法），再针对性地添加-keep规则，而不是保留整个包。比如某个回调接口被反射调用，只需要保留这个接口：

   -keep interface android.support.v4.app.FragmentManager$OnBackStackChangedListener { *; }
   

内容的提问来源于stack exchange，提问作者Jim Layhey