Android 开发之 - 程序异常退出处理 CrashHandler 的使用

最新推荐文章于 2024-05-15 17:19:51 发布

原创最新推荐文章于 2024-05-15 17:19:51 发布 · 606 阅读

·

0

·

CC 4.0 BY-SA版权

版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。

本文深入探讨了Android开发的核心技术和最佳实践，参考了《Android开发艺术探索》一书，提供了高质量的内容，适合Android开发者深入学习。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

转载自：https://me.csdn.net/gavin_Zippo

原文链接：https://blog.csdn.net/gavin_Zippo/article/details/79557959

这篇文章应该是在参考《Android 开发艺术探索》写的，质量还可以。

博客等级

码龄9年

44
原创

29
点赞

96
收藏

18
粉丝

关注

私信

热门文章

分类专栏

展开全部收起

上一篇：: Android 8.1.0 源码修改之 - 给自己预置到系统的预置应用添加一些默认权限

下一篇：: Android 开发之 - 消除 Permission is only granted to system apps

最新评论

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: 解决方法呢？这个问题怎么解决的？

大家在看

最新文章

目录

展开全部

收起

评论

被折叠的条评论为什么被折叠?

到【灌水乐园】发言

查看更多评论

添加红包

成就一亿技术人!

hope_wisdom

发出的红包

实付元

使用余额支付

点击重新获取

扫码支付

钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。