我们知道,一个进程发生了什么情况,不会发生在另一个进程中。App在XXXActivity(在主进程中)运行过程中发生了crash,crash监听之后通过inten启动恢复界面RecoveryUI(在RecoveryUI进程,不受主进程影响),这种情况不像安全模式那样,安全气垫对用户是有感知的,会进入到恢复界面,用户通过点击恢复直接运行到RecoveryService进程的RecoveryService,这里之所以重新启动一个进程,是因为不想影响在最小化功能的RecoveryUI进程的RecoveryUI界面,RecoveryService会做一些逻辑,如网络请求,如有些逻辑鉴定,可能会存在崩溃的情况。这里RecoveryService会尽量使用到的API最小化,如网络请求会直接使用系统自带的URLConnection等,通过RecoveryService来判断是否有版本升级,上报crash日志、获取远程配置、查询hotpatch等。
本文详细解析了App在主进程发生Crash后,如何通过独立的RecoveryUI进程引导用户进入恢复界面,并由RecoveryService进程执行恢复逻辑,如网络请求、版本升级检查及crash日志上报等,确保不影响主功能。

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



