启用ProGuard后，如何在UI插桩测试中保留对混淆类的引用？

方案1：为测试构建保留Foo类的关键签名（最直接） #

如果你希望发布版正常混淆Foo类，但测试时（比如debug构建）能让插桩代码直接引用Foo，可以通过Gradle为不同构建类型配置差异化的ProGuard规则：

1. 首先在Module级别的build.gradle中，给debug构建单独指定测试用的ProGuard规则：

   android {
       buildTypes {
           release {
               minifyEnabled true
               proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro'
           }
           debug {
               minifyEnabled true // 开启混淆，模拟发布环境的行为
               proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro', 'proguard-test-rules.pro'
           }
       }
   }
   

2. 然后在proguard-test-rules.pro中添加规则，保留Foo类的测试所需成员：

   # 保留Foo类的所有公共方法和字段，让测试代码直接调用
   -keep class com.yourpackage.Foo {
       public <methods>;
       public <fields>;
   }
   
   # 如果测试需要调用非公共成员，就放开下面的规则
   # -keepclassmembers class com.yourpackage.Foo {
   #     <methods>;
   #     <fields>;
   # }
   

这样一来，debug构建（用于插桩测试）中Foo的关键签名不会被混淆，测试代码能正常引用；而release构建中Foo会被完全混淆，满足发布要求。

方案2：用反射调用混淆后的Foo类（兜底方案） #

如果必须在测试时和发布版完全一致（Foo类完全混淆），那可以用反射绕过类名/方法名的引用问题：

// 插桩测试代码示例
try {
    // 从mapping.txt里获取Foo混淆后的类名（比如com.yourpackage.a）
    Class<?> fooClass = Class.forName("com.yourpackage.a");
    // 创建实例（如果有构造参数需对应调整）
    Object fooInstance = fooClass.getConstructor().newInstance();
    // 获取混淆后的方法名（比如原方法doSomething变成了a）
    Method targetMethod = fooClass.getMethod("a");
    // 调用方法
    targetMethod.invoke(fooInstance);
} catch (Exception e) {
    e.printStackTrace();
}

⚠️ 注意：这种方式维护成本很高——每次ProGuard的混淆结果可能变化，你需要同步更新测试代码里的类名/方法名，除非万不得已不推荐。

方案3：用测试替身解耦（最优雅的长期方案） #

如果测试代码不需要依赖Foo类的真实实现，推荐用依赖注入+测试替身的方式彻底解耦：

1. 先给Foo类抽象出一个接口：

   // 应用代码中的接口
   public interface FooContract {
       void doSomething();
   }
   
   // 原Foo类实现接口
   public class Foo implements FooContract {
       @Override
       public void doSomething() {
           // 真实业务逻辑
       }
   }
   

2. 应用代码通过接口获取实例（比如用DI框架或者简单的工厂模式）：

   // 应用中获取Foo实例的方式
   public class App {
       private FooContract foo;
   
       public App(FooContract foo) {
           this.foo = foo;
       }
   
       public void run() {
           foo.doSomething();
       }
   }
   

3. 测试代码中创建一个Mock替身类：

   // 测试模块中的替身类
   public class MockFoo implements FooContract {
       @Override
       public void doSomething() {
           // 模拟测试需要的行为
       }
   }
   

4. 测试时注入MockFoo替代真实的Foo：

   // 插桩测试代码
   @Test
   public void testAppRun() {
       MockFoo mockFoo = new MockFoo();
       App app = new App(mockFoo);
       app.run();
       // 验证mockFoo的方法是否被调用等
   }
   

这种方式下，即使Foo类在发布版被完全混淆，测试代码也完全不依赖它，同时还能让测试更聚焦于业务逻辑，是测试最佳实践的推荐方案。

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