前言

前端代码因为需要直接传输到客户端执行，因此代码混淆技术较早的开始发展，当前比较成熟。后端代码长期以来混淆的需求并不突出，然而随着Java代码需要被客户接触到，并不放在公司完全受控的环境，如以apk形式在用户手机上或以应用形式在专有云中，因此后端代码混淆提到了日程中。

选型

成熟的Java混淆工具很多，如下表：

也有不少工具因为长期未更新直接不在考虑范围内，如Jode（LGPL、最后更新：2002年）、JavaGuard（LGPLv2，最后更新：2002年）、jarg（开源，最后更新：2003年）。

一般初步学习适用从开源免费的软件开始，那么我们就从yGuard和ProGuard两者来比较，首先看Google搜索：

很显然ProGuard更加活跃。从混淆情况看，既然是混淆工具，混淆上差别不大，yGuard基于Ant Task，因此在maven中需要maven-antrun-plugins来支持，并且需要写ant task脚本。ProGuard有proguard-maven-plugin + 配置文件的形式，更加方便。同时ProGuard有Facebook ProGuard的Folk版本，和DexGuard商业版本两个较活跃的衍生版本，支持整个生态良好发展。因此我们选择ProGuard。

ProGuard快速上手

配置

因为我们的应用主要是面向专有云的Java EE应用，因此这里不考虑安卓apk什么事了。复杂的JavaEE应用一般是多module的，可能涉及不同module的jar包依赖、各种写着类名的配置文件，但用到反射的情况并不多，主要是某些AOP、hack之类的。因此需要小心的混淆，了解混淆的每一个配置及可能带来的副作用。这里我们仅仅对代码进行适度的混淆，示例中并没有考虑应用中的反射，但一般场景下已经足够。

假设应用名称是$APP_NAME，应用名称与IDE里项目名称相同，项目下有一些子模块（Module），名叫module-1、module-2……，应用代码都属于com.company.appname包下。我们首先创建配置文件在$APP_NAMEtoolsproguardproguard.conf（单独抽到配置文件里，比写到pom.xml里更易读），目录结构大致如下：

$APP_NAME
 ├module-1
 │  └pom.xml
 ├module-2
 │  └pom.xml
 ├tools
 │  └proguard
 │      └proguard.conf
 └pom.xml

配置文件proguard.conf内容如下：

# 忽略警告
-ignorewarnings
#打印处理信息，失败时会打印堆栈信息
-verbose

# 保持目录结构
-keepdirectories
#不能混淆泛型、抛出的异常、注解默认值、原始行号等
-keepattributes Signature,Exceptions,*Annotation*,InnerClasses,Deprecated,EnclosingMethod
# 对于包名、类名不进行混淆
-keeppackagenames com.company.appname.**

# 保留public、protected方法不被混淆
-keep public class * {
      public protected *;
}
# 保留注解不被混淆
-keep public @interface * {
    ** default (*);
}

# 保留枚举类不被混淆
-keepclassmembers enum * {
    public static **[] values();
    public static ** valueOf(java.lang.String);
}

# 保持依赖注入不被混淆
-keepclassmembers class * {
    @org.springframework.beans.factory.annotation.Autowired *;
    @javax.annotation.Resource *;
}

# 保持RMI调用不被混淆
-keep class * implements java.rmi.Remote {
    <init>(java.rmi.activation.ActivationID, java.rmi.MarshalledObject);
}

# 保留JavaBean不被混淆
-keepclassmembers class * implements java.io.Serializable {
    static final long serialVersionUID;
    private static final java.io.ObjectStreamField[] serialPersistentFields;
    private void writeObject(java.io.ObjectOutputStream);
    private void readObject(java.io.ObjectInputStream);
    java.lang.Object writeReplace();
    java.lang.Object readResolve();
}

# 避免类名被标记为final
-optimizations !class/marking/final

然后在$APP_NAME/pom.xml中加入对proguard-maven-plugin的定义，避免每个module里都把公共的代码写一遍：

<?xml version="1.0" encoding="UTF-8"?>
<project ...>
    ....
    <build>
        ....
        <pluginManagement>
            <plugins>
                ....
                <plugin>
                    <groupId>com.github.wvengen</groupId>
                    <artifactId>proguard-maven-plugin</artifactId>
                    <version>2.0.14</version>
                    <dependencies>
                        <dependency>
                            <groupId>net.sf.proguard</groupId>
                            <artifactId>proguard-base</artifactId>
                            <version>5.3.3</version>
                            <scope>runtime</scope>
                        </dependency>
                    </dependencies>
                    <executions>
                        <execution>
                            <phase>package</phase>
                            <goals>
                                <goal>proguard</goal>
                            </goals>
                        </execution>
                    </executions>
                    <configuration>
                        <obfuscate>true</obfuscate>
                        <proguardInclude>../tools/proguard/proguard.conf</proguardInclude>
                    </configuration>
                </plugin>
                ....
            </plugins>
        </pluginManagement>
        ....
    </build>
    ....
</project>

同时在每一个module的pom.xml文件里，加入对proguard-maven-plugin的引用：

<?xml version="1.0" encoding="UTF-8"?>
<project ...>
    ....
    <build>
        ....
        <plugins>
            ....
            <plugin>
                <groupId>com.github.wvengen</groupId>
                <artifactId>proguard-maven-plugin</artifactId>
            </plugin>
            ....
        </plugins>
        ....
    </build>
    ....
</project>

配置文件、pom.xml文件配完，后续开发、打包、上发布系统就和普通的应用没有任何区别了，maven打包完的$filename.jar所在目录下有一个同名的$filename.jar.original包是未经混淆的包。

混淆效果

根据前一节中的配置进行混淆，可以看到源文件行号已经无法还原，普通成员变量、本地变量的变量名已经替换成无意义名字，代码结构有很细微的变化不影响结果。经过混淆和优化后，比原始的class文件小了大致23%。

更多要说

不同类型的应用需要不同对待

对于不被其他应用代码依赖的应用和需要发布为二方包被别的应用依赖的应用，配置可能不同。二方包里的类名、方法名不可混淆，同时可以通过混淆阻止其他应用通过反射来进行不安全的调用，当然对公共数据结构里的方法不可混淆。对于直接发布到服务器上最终使用的应用，类名、变量名，甚至配置文件都可以进行混淆，对于需要被反射的一些类，方法名甚至类名不能被混淆，如装配时By name和By Type就有很大区别。

书写代码时需要考虑混淆后是否影响运行

比如JavaBean混淆后，类成员变量的名称可以变掉，方法名不变。这时候如果成员变量有注解类似于@JsonIgnore、@JSONField(serialize=XX)可能会失效，正确的应该把这些注解写到Setter方法上。

需要考虑Debug的便利性

混淆可以优化代码，去除字节码中关联的行号信息，这时候如果出错，日志会相对难调试。这个是双刃剑，要么接受混淆，要么通过控制参数保留行号信息。

扩展阅读

《Protect Your Java Code — Through Obfuscators And Beyond》
《Tips for using ProGuard with Spring framework》
《ProGuard Examples》
《ProGuard Usage》
《proguard-maven-plugin》