自定义博客皮肤VIP专享

*博客头图：

点击选择上传的图片

格式为PNG、JPG，宽度*高度大于1920*100像素，不超过2MB，主视觉建议放在右侧，请参照线上博客头图

请上传大于1920*100像素的图片！

博客底图：

点击选择上传的图片

图片格式为PNG、JPG，不超过1MB，可上下左右平铺至整个背景

栏目图：

点击选择上传的图片

图片格式为PNG、JPG，图片宽度*高度为300*38像素，不超过0.5MB

主标题颜色：

RGB颜色，例如：#AFAFAF

Hover：

RGB颜色，例如：#AFAFAF

副标题颜色：

RGB颜色，例如：#AFAFAF

预览取消提交

自定义博客皮肤

-+

上一步保存

Water_Marking的博客

博客等级

码龄10年

44
原创

29
点赞

99
收藏

18
粉丝

关注

私信

热门文章

分类专栏

最新评论

Android SDK 开发 - sdk 中依赖第三方jar 包的情况
Water_Marking: 方案2：显式构建胖JAR（不混淆时）添加Gradle任务合并所有依赖： groovy task fatJar(type: Jar) { archiveBaseName = 'c-fat' from { configurations.runtimeClasspath.collect { it.isDirectory() ? it : zipTree(it) } } with jar } 运行：./gradlew :module-c:fatJar 方案3：声明API依赖（部分解决）在模块b中使用api代替implementation： diff // module-b/build.gradle dependencies { - implementation files('libs/a.jar') + api files('libs/a.jar') } 但这只能解决编译问题，运行时仍需提供所有JAR。关键结论特性不混淆构建混淆构建模块边界严格保持被打破输出内容仅当前模块类所有被引用的类依赖处理需要完整依赖链自包含（FatJAR）技术本质标准Java编译模型全局代码优化+内联这个现象不是bug而是特性：混淆工具的代码优化无意中实现了"依赖内聚"，解决了模块化开发中的依赖传递问题。对于SDK交付场景，建议始终开启混淆构建，既保护代码又简化依赖管理。补充建议：在ProGuard规则中显式保留公共API，避免混淆暴露给用户的类/方法： text -keep public class com.your.sdk.public.** { *; }
Android SDK 开发 - sdk 中依赖第三方jar 包的情况
Water_Marking: 为什么混淆后能工作？混淆工具执行了以下关键操作：打破模块边界：将跨模块的类调用视为同一代码库强制内联：把B和A的字节码直接复制到C的类中扁平化输出：最终生成单个包含所有必需类的JAR java // 混淆前 // C.java public class C { public void callB() { new B().doSomething(); // 需要外部B类 } } // 混淆后等效代码 public class C { public void a() { // 方法被重命名 // B类的实现被内联到这里 int x = 10; System.out.println(x); } } 解决方案：统一构建策略方案1：始终使用混淆构建（推荐）在库模块的build.gradle中强制启用混淆： groovy android { buildTypes { release { minifyEnabled true proguardFiles 'proguard-rules.pro' } debug { minifyEnabled true // 调试版也开启 proguardFiles 'proguard-rules.pro' } } }
Android SDK 开发 - sdk 中依赖第三方jar 包的情况
Water_Marking: 这个现象确实令人困惑，但核心原因在于混淆工具（如 ProGuard/R8）的代码优化机制改变了打包行为，而不仅仅是重命名类/方法。以下是详细解释：根本原因：混淆工具的代码内联（Inlining）优化混淆工具在压缩代码时会执行以下关键操作：类内联（Class Inlining）：将依赖类的字节码直接嵌入到调用方类中方法内联（Method Inlining）：将被调用方法体直接嵌入到调用位置无用代码移除（Dead Code Elimination）：删除未被引用的类和成员当开启混淆时，工具会分析代码调用链：图表代码混淆工具发现： App直接使用C的类 C的类又调用了B的类 B的类又调用了A的类为了确保最终可执行文件能运行，混淆工具会将整个调用链（A→B→C）的字节码都内联打包到同一个JAR中，形成"胖JAR"（FatJAR）。不混淆时的正常编译行为常规编译（无混淆）时： implementation依赖是非传递性的每个模块只包含自己编译的类依赖关系通过Gradle依赖链解决图表代码当只提供c.jar时： JVM在运行时找不到b.jar和a.jar 抛出ClassNotFoundException: B 为什么混淆后能工作？
Android SDK 开发 - sdk 中依赖第三方jar 包的情况
LittleLoveBoy: 这是很基础的问题啊类没有被使用(可能会从某些类开始作为root查找，发现这个代码没用) 就可能被删掉，你需要用混淆规则将类保留下来。
浅谈 Android Tombstone（墓碑日志）分析步骤
Greeting coder: 解决方法呢？这个问题怎么解决的？

网络相关

关注

关注数：文章数：2 文章阅读量：3262 文章收藏量：2

作者: Water_Marking

Just Do IT。

展开

专栏收录文章