自研18KB AAR库集成后APK体积激增3.5MB，新增classes3.dex求助

这种明明AAR才18KB，引入后主APK却胖了3.5MB的情况确实挺闹心的，我帮你梳理几个最可能的原因和排查方向：

1. 传递依赖偷偷“夹带私货” #

这是最常见的原因——你的AAR本身很小，但它可能依赖了某个体积较大的第三方库，哪怕你只用到了这个库中g...相关的一小部分，Gradle默认会把整个依赖库都拉进主应用的打包流程里。

• 用Android Studio自带的Dependency Analyzer（在File > Analyze > Analyze Dependencies）或者执行命令：

  ./gradlew app:dependencies
  

  查看你的AAR带来了哪些传递依赖，重点找体积大的库。
• 如果发现多余的依赖，在主应用的build.gradle里给AAR依赖加上排除规则：

  implementation('com.your.group:your-library:1.0.0') {
      exclude group: '冗余依赖的group', module: '冗余依赖的module'
  }
  

2. 混淆/代码压缩没生效 #

如果你的AAR没有开启代码混淆，或者主应用的压缩规则没配置好，会导致大量无用代码被保留下来：

• 检查AAR的build.gradle里是否开启了混淆：

  android {
      buildTypes {
          release {
              minifyEnabled true
              proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro'
          }
      }
  }
  

• 检查主应用的ProGuard/R8规则，有没有误把AAR的整个包都keep住了（比如-keep class com.your.library.** { *; }这种太宽泛的规则会阻止压缩）。如果只需要保留g...相关的类，要把规则改得更精准。

3. AAR包含了多余的资源或代码 #

有时候AAR的打包配置可能出错，把不该打包的内容加进去了：

• 手动解压AAR文件（用unzip your-library.aar -d temp命令），查看里面的classes.jar大小、res/目录有没有多余的图片/布局、assets/有没有无关文件。
• 确认AAR的main目录里没有混入测试代码（比如把test目录下的代码误放到main里，会被打包进AAR）。

4. 注解处理器生成了大量辅助类 #

如果你的AAR依赖了注解处理器（比如ButterKnife、Dagger这类），编译时可能会生成大量辅助类，这些类会被打包进APK：

• 查看AAR的build.gradle里有没有annotationProcessor或kapt依赖，确认这些处理器是否真的必要。如果只是用了一小部分功能，看看能不能替换成轻量方案，或者调整处理器的配置减少生成代码。

5. 多DEX触发的额外打包 #

新增classes3.dex说明你的APK方法数可能接近或超过了65536的限制，但核心问题还是体积暴涨——本质还是引入了大量额外方法（大概率是传递依赖带来的）。解决了前面的依赖和压缩问题，多DEX的情况也会随之缓解。

最后给你个快速定位的小技巧：用Android Studio的APK Analyzer打开主APK，查看classes3.dex里的具体包名，直接定位到是哪个库带来的这些代码，再针对性处理就好。

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