android studio 原生不支持像 c++ 预处理器那样通过宏定义完全跳过单个 java 类的编译；proguard 或 r8 仅能移除已编译的字节码，无法规避编译阶段的语法检查，因此无法真正“忽略”类文件。目前最可行的方案是结合构建变体（build variants）与源集（source sets）实现物理级隔离。

android studio 原生不支持像 c++ 预处理器那样通过宏定义完全跳过单个 java 类的编译；proguard 或 r8 仅能移除已编译的字节码，无法规避编译阶段的语法检查，因此无法真正“忽略”类文件。目前最可行的方案是结合构建变体（build variants）与源集（source sets）实现物理级隔离。

在 Android 构建系统中，真正的条件性“排除整个 Java 类文件”不能依赖编译期开关（Java 本身无 #ifdef），而应通过 Gradle 的源集组织机制实现——将敏感类（如违反 Google Play Family Policy 的工具类）移出主源码路径，仅在允许使用的构建变体中引入。

✅ 推荐实践：使用 Build Variants + Source Sets

1. 按功能拆分源目录结构
   在 src/ 下为不同变体创建独立源集：

   src/
   ├── main/              // 公共代码（不含敏感类）
   ├── debug/             // 可包含调试工具类
   ├── release/           // 生产环境（默认不含敏感类）
   └── familySafe/        // 自定义变体，显式排除敏感类

2. 定义自定义构建类型或风味（Flavor）
   在 app/build.gradle 中配置：

   android {
       flavorDimensions "policy"
       productFlavors {
           compliant {
               dimension "policy"
               applicationIdSuffix ".compliant"
           }
           nonCompliant {
               dimension "policy"
               applicationIdSuffix ".noncompliant"
           }
       }
   }

3. 将敏感类放入专属源集，而非 main/

   • 将违规类 UnsafeUtils.java 放入 src/nonCompliant/java/com/example/UnsafeUtils.java
   • 确保 src/compliant/ 中不包含该文件，也不引用它
   • 所有调用该类的代码也必须限定在 nonCompliant 源集内（例如放在 src/nonCompliant/java/...）

4. 编译时自动隔离
   执行以下命令仅构建合规版本，UnsafeUtils.java 根本不会被编译器扫描：

   ./gradlew assembleCompliantRelease

   此时 compliant 变体的 classpath 中完全不存在 UnsafeUtils，零编译风险，零运行时残留。

   

   Java Maven Code Review

   审查Java Maven项目（ZIP压缩包或GitLab仓库URL），检查代码规范、命名、模块边界、可维护性问题以及重复代码。

   下载

⚠️ 注意事项与替代方案对比

• ❌ ProGuard/R8 不适用：它们作用于 .class 字节码阶段，而 javac 在此之前已报错（如类引用缺失、方法未定义等），无法解决编译依赖问题。
• ❌ 全文件注释（如答案所述）是反模式：易遗漏、不可审计、破坏 Git 历史可追溯性，且无法保证 IDE 实时校验一致性。
• ✅ BuildConfig 动态控制仅适用于运行时逻辑分支：BuildConfig.IS_FAMILY_SAFE 可控制方法执行，但类仍会被编译、打包，违反政策要求。
• ✅ Kotlin Multiplatform 或注解处理器（Advanced）：对复杂项目可考虑生成式方案，但对单类排除属过度设计。

总结

Android 的构建本质是“源码路径聚合”，而非“条件编译”。要彻底排除一个 Java 类，唯一健壮的方式是让它物理上不出现在目标变体的源集路径中。这不仅是技术最佳实践，也符合 Google Play 审核对二进制纯净性的要求——最终 APK 中既无该类的字节码，也无任何相关符号引用。从工程角度看，此举还强化了模块边界与合规责任分离，值得在团队规范中明确落地。

立即学习“Java免费学习笔记（深入）”；