AppErrorsTracking 数据持久化剖析JSON 存储机制与旧版数据自动迁移原理【免费下载链接】AppErrorsTrackingAdded more features to apps crash dialog, fixed custom rom deleted dialog, the best experience to Android developer.项目地址: https://gitcode.com/gh_mirrors/ap/AppErrorsTrackingAppErrorsTracking 是一款增强 Android 崩溃对话框的开源追踪工具核心能力是把应用崩溃记录持久化到本地。本文剖析它的JSON 存储机制与旧版数据自动迁移原理带你用 5 分钟看懂崩溃数据是如何被写入、读取并平滑升级的。一、AppErrorsTracking 是什么AppErrorsTracking 运行在 Android 系统服务进程中目标是替换原生简陋的崩溃对话框并在应用崩溃后做到三件事 弹出更美观、功能更完整的自定义崩溃对话框 将每一次崩溃包名、异常类、完整堆栈、版本信息等持久化保存 在应用内查看、筛选、分享、导出崩溃历史模块的注入入口在 HookEntry.kt启动后加载系统框架钩子 FrameworkHooker.kt而全部持久化逻辑集中在一个文件AppErrorsRecordData.kt。二、崩溃记录的产生从系统钩子到数据对象应用崩溃时系统会走到ActivityManagerService的handleAppCrashInActivityController方法。AppErrorsTracking 通过钩子接管这个时机FrameworkHooker.kt#L493-L504从系统错误报告中提取崩溃信息封装为 AppErrorsInfoBean 数据对象。该对象共 17 个字段一次崩溃的体检报告如下字段说明pid/userId进程 ID 与用户 ID支持多用户环境packageName崩溃应用包名versionName/versionCode应用版本名称与版本号cpuAbi/targetSdk/minSdkCPU 架构与 SDK 信息isNativeCrash是否为 Native 层崩溃exceptionClassName/exceptionMessage异常类名与异常信息throwClassName/throwFileName/throwMethodName/throwLineNumber异常抛出的精确位置stackTrace完整异常堆栈timestamp崩溃时间戳Native 崩溃如 SIGSEGV会被特别识别判断异常类名是否为native crash并尝试从堆栈中提取Abort message作为异常信息让 C 崩溃同样有可读的摘要AppErrorsInfoBean.kt#L110-L136。三、JSON 存储机制一次崩溃 一个 JSON 文件这是 AppErrorsTracking 数据持久化最核心的设计每一条崩溃记录都以独立的 JSON 文件落盘而不是挤在一张表或一个大文件里。3.1 存储位置系统分区目录数据目录固定为AppErrorsRecordData.kt#L44/data/misc/app_errors_records/它位于系统分区而非应用私有目录带来两个好处崩溃记录不随普通应用卸载而丢失对运行在系统服务中的模块天然可读写目录在模块启动时由initializeDataDirectory()自动创建创建失败会打印错误日志但不中断流程AppErrorsRecordData.kt#L75-L81。3.2 文件命名规则唯一且自描述每条记录的文件名由三段信息拼接AppErrorsInfoBean.kt#L149{包名}_{进程ID}_{时间戳}.json 例如com.example.app_12345_1716000000000.json这套命名带来三个好处文件名全局唯一不同进程、不同时刻的记录不会互相覆盖按文件修改时间倒序即可得到崩溃时间线AppErrorsRecordData.kt#L59单条记录损坏不影响其他记录隔离了故障范围3.3 序列化Gson 宽松模式 失败安全JSON 序列化由 GsonFormatFactory.kt 提供全局懒加载的Gson实例开启setLenient()宽松模式提供toJsonOrNull/toEntityOrNull等失败返回 null的安全包装也就是说任何一次序列化或解析异常都只会跳过这一条绝不会让整个崩溃记录功能崩溃——这对运行在系统进程中的模块至关重要。3.4 内存 磁盘双写AppErrorsRecordData采用内存列表 磁盘文件双写架构层数据结构作用内存CopyOnWriteArrayListAppErrorsInfoBean多线程读写安全UI 查询快磁盘独立 JSON 文件断电不丢、跨重启保留新增记录的流程AppErrorsRecordData.kt#L118-L121新记录插入内存列表头部最新崩溃置顶序列化为 JSON 文本以固定文件名写入数据目录启动时由onCreate生命周期钩子触发init()FrameworkHooker.kt#L227确保目录存在 → 读取目录下全部 JSON 文件 → 反序列化装填内存列表读取顺序按修改时间倒序天然对应 UI 上最近崩溃在前的展示顺序。3.5 为什么选每崩溃一个文件而不是数据库方案主要缺点SharedPreferences全部记录挤在一个 XML每次新增都要重写整个文件SQLite需建表、处理 schema 迁移与并发锁单个大 JSON 文件同上且一处损坏全部丢失每条记录独立 JSON 文件✅原子写入、损坏隔离、按文件名即可检索崩溃记录是典型的只增很少改场景独立文件方案与它最为匹配。四、旧版数据自动迁移原理早期版本把所有崩溃记录序列化成一个大 JSON 字符串整体存放在系统 Settings 数据库的 Secure 表键名app_errors_data。这种大杂烩式存储读取慢、无法隔离损坏新版改为独立 JSON 文件方案并内置了一次性的自动迁移逻辑。4.1 迁移流程读旧 → 转新 → 清旧每次启动加载数据时readAllDataFromFiles()会优先尝试迁移函数copyOldDataFromResolverString()AppErrorsRecordData.kt#L87-L112读旧从Settings.Secure读取app_errors_data键值转新用 Gson 将大 JSON 解析为记录列表逐条补全新版字段cpuAbi、versionName、versionCode都是后续版本才加入的字段并写入各自的 JSON 文件清旧将旧键值置为空字符串完成交接4.2 迁移的健壮性设计幂等旧键被清空后下次读取得到空串、解析返回 null自动走文件读取分支——迁移只发生一次绝不重复容错整个迁移包裹在runCatching中即使旧数据格式异常也不会阻塞新版文件加载兼容新版缺失字段用unknown/-1兜底老记录迁移后依然可完整展示这套读旧 → 转新 → 清旧模式是 Android 工具模块升级存储方案时值得借鉴的经典做法。✨五、数据生命周期管理AppErrorsRecordData提供完整的增删清能力并通过事件回调与 UI 联动FrameworkHooker.kt#L248-L255操作方法行为新增add(bean)内存置顶 写 JSON 文件删除单条remove(bean)内存移除 删除对应文件清空全部clearAll()清空列表 递归删除目录 重建目录所有文件操作都被runCatching保护即使文件系统出现异常也只会在内存与磁盘之间短暂不一致而不会抛出未捕获异常拖垮宿主进程。六、配置数据与记录数据的分离存储AppErrorsTracking 把两类数据彻底分开这是架构上另一个值得学习的设计数据类型存储方式位置崩溃记录独立 JSON 文件/data/misc/app_errors_records/应用配置SharedPreferencesPrefsData封装模块私有偏好文件配置项如仅前台显示对话框、Material 3 风格由 ConfigData.kt 统一管理而 AppErrorsConfigData.kt 还维护了按应用区分的对话框 / 通知 / Toast / 不显示四套展示模板。两类存储互不干扰崩溃记录再多也不会撑爆配置文件清空记录也不会误删用户配置。七、设计亮点速览亮点收益一次崩溃一个文件写入原子、损坏隔离、天然增量内存列表 磁盘文件双写查询快、断电不丢读旧 → 转新 → 清旧迁移幂等、容错、用户无感升级记录与配置分离存储各取所需互不影响全链路runCatching容错存储异常不影响主功能八、相关源码索引数据持久化核心存储 迁移AppErrorsRecordData.kt崩溃数据对象17 字段 文件名规则AppErrorsInfoBean.ktJSON 序列化工具GsonFormatFactory.kt系统钩子与事件分发FrameworkHooker.kt模块注入入口HookEntry.kt全局配置存储ConfigData.kt应用展示模板配置AppErrorsConfigData.kt【免费下载链接】AppErrorsTrackingAdded more features to apps crash dialog, fixed custom rom deleted dialog, the best experience to Android developer.项目地址: https://gitcode.com/gh_mirrors/ap/AppErrorsTracking创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 AppErrorsTracking 数据持久化剖析：JSON 存储机制与旧版数据自动迁移原理
AppErrorsTracking 数据持久化剖析JSON 存储机制与旧版数据自动迁移原理【免费下载链接】AppErrorsTrackingAdded more features to apps crash dialog, fixed custom rom deleted dialog, the best experience to Android developer.项目地址: https://gitcode.com/gh_mirrors/ap/AppErrorsTrackingAppErrorsTracking 是一款增强 Android 崩溃对话框的开源追踪工具核心能力是把应用崩溃记录持久化到本地。本文剖析它的JSON 存储机制与旧版数据自动迁移原理带你用 5 分钟看懂崩溃数据是如何被写入、读取并平滑升级的。一、AppErrorsTracking 是什么AppErrorsTracking 运行在 Android 系统服务进程中目标是替换原生简陋的崩溃对话框并在应用崩溃后做到三件事 弹出更美观、功能更完整的自定义崩溃对话框 将每一次崩溃包名、异常类、完整堆栈、版本信息等持久化保存 在应用内查看、筛选、分享、导出崩溃历史模块的注入入口在 HookEntry.kt启动后加载系统框架钩子 FrameworkHooker.kt而全部持久化逻辑集中在一个文件AppErrorsRecordData.kt。二、崩溃记录的产生从系统钩子到数据对象应用崩溃时系统会走到ActivityManagerService的handleAppCrashInActivityController方法。AppErrorsTracking 通过钩子接管这个时机FrameworkHooker.kt#L493-L504从系统错误报告中提取崩溃信息封装为 AppErrorsInfoBean 数据对象。该对象共 17 个字段一次崩溃的体检报告如下字段说明pid/userId进程 ID 与用户 ID支持多用户环境packageName崩溃应用包名versionName/versionCode应用版本名称与版本号cpuAbi/targetSdk/minSdkCPU 架构与 SDK 信息isNativeCrash是否为 Native 层崩溃exceptionClassName/exceptionMessage异常类名与异常信息throwClassName/throwFileName/throwMethodName/throwLineNumber异常抛出的精确位置stackTrace完整异常堆栈timestamp崩溃时间戳Native 崩溃如 SIGSEGV会被特别识别判断异常类名是否为native crash并尝试从堆栈中提取Abort message作为异常信息让 C 崩溃同样有可读的摘要AppErrorsInfoBean.kt#L110-L136。三、JSON 存储机制一次崩溃 一个 JSON 文件这是 AppErrorsTracking 数据持久化最核心的设计每一条崩溃记录都以独立的 JSON 文件落盘而不是挤在一张表或一个大文件里。3.1 存储位置系统分区目录数据目录固定为AppErrorsRecordData.kt#L44/data/misc/app_errors_records/它位于系统分区而非应用私有目录带来两个好处崩溃记录不随普通应用卸载而丢失对运行在系统服务中的模块天然可读写目录在模块启动时由initializeDataDirectory()自动创建创建失败会打印错误日志但不中断流程AppErrorsRecordData.kt#L75-L81。3.2 文件命名规则唯一且自描述每条记录的文件名由三段信息拼接AppErrorsInfoBean.kt#L149{包名}_{进程ID}_{时间戳}.json 例如com.example.app_12345_1716000000000.json这套命名带来三个好处文件名全局唯一不同进程、不同时刻的记录不会互相覆盖按文件修改时间倒序即可得到崩溃时间线AppErrorsRecordData.kt#L59单条记录损坏不影响其他记录隔离了故障范围3.3 序列化Gson 宽松模式 失败安全JSON 序列化由 GsonFormatFactory.kt 提供全局懒加载的Gson实例开启setLenient()宽松模式提供toJsonOrNull/toEntityOrNull等失败返回 null的安全包装也就是说任何一次序列化或解析异常都只会跳过这一条绝不会让整个崩溃记录功能崩溃——这对运行在系统进程中的模块至关重要。3.4 内存 磁盘双写AppErrorsRecordData采用内存列表 磁盘文件双写架构层数据结构作用内存CopyOnWriteArrayListAppErrorsInfoBean多线程读写安全UI 查询快磁盘独立 JSON 文件断电不丢、跨重启保留新增记录的流程AppErrorsRecordData.kt#L118-L121新记录插入内存列表头部最新崩溃置顶序列化为 JSON 文本以固定文件名写入数据目录启动时由onCreate生命周期钩子触发init()FrameworkHooker.kt#L227确保目录存在 → 读取目录下全部 JSON 文件 → 反序列化装填内存列表读取顺序按修改时间倒序天然对应 UI 上最近崩溃在前的展示顺序。3.5 为什么选每崩溃一个文件而不是数据库方案主要缺点SharedPreferences全部记录挤在一个 XML每次新增都要重写整个文件SQLite需建表、处理 schema 迁移与并发锁单个大 JSON 文件同上且一处损坏全部丢失每条记录独立 JSON 文件✅原子写入、损坏隔离、按文件名即可检索崩溃记录是典型的只增很少改场景独立文件方案与它最为匹配。四、旧版数据自动迁移原理早期版本把所有崩溃记录序列化成一个大 JSON 字符串整体存放在系统 Settings 数据库的 Secure 表键名app_errors_data。这种大杂烩式存储读取慢、无法隔离损坏新版改为独立 JSON 文件方案并内置了一次性的自动迁移逻辑。4.1 迁移流程读旧 → 转新 → 清旧每次启动加载数据时readAllDataFromFiles()会优先尝试迁移函数copyOldDataFromResolverString()AppErrorsRecordData.kt#L87-L112读旧从Settings.Secure读取app_errors_data键值转新用 Gson 将大 JSON 解析为记录列表逐条补全新版字段cpuAbi、versionName、versionCode都是后续版本才加入的字段并写入各自的 JSON 文件清旧将旧键值置为空字符串完成交接4.2 迁移的健壮性设计幂等旧键被清空后下次读取得到空串、解析返回 null自动走文件读取分支——迁移只发生一次绝不重复容错整个迁移包裹在runCatching中即使旧数据格式异常也不会阻塞新版文件加载兼容新版缺失字段用unknown/-1兜底老记录迁移后依然可完整展示这套读旧 → 转新 → 清旧模式是 Android 工具模块升级存储方案时值得借鉴的经典做法。✨五、数据生命周期管理AppErrorsRecordData提供完整的增删清能力并通过事件回调与 UI 联动FrameworkHooker.kt#L248-L255操作方法行为新增add(bean)内存置顶 写 JSON 文件删除单条remove(bean)内存移除 删除对应文件清空全部clearAll()清空列表 递归删除目录 重建目录所有文件操作都被runCatching保护即使文件系统出现异常也只会在内存与磁盘之间短暂不一致而不会抛出未捕获异常拖垮宿主进程。六、配置数据与记录数据的分离存储AppErrorsTracking 把两类数据彻底分开这是架构上另一个值得学习的设计数据类型存储方式位置崩溃记录独立 JSON 文件/data/misc/app_errors_records/应用配置SharedPreferencesPrefsData封装模块私有偏好文件配置项如仅前台显示对话框、Material 3 风格由 ConfigData.kt 统一管理而 AppErrorsConfigData.kt 还维护了按应用区分的对话框 / 通知 / Toast / 不显示四套展示模板。两类存储互不干扰崩溃记录再多也不会撑爆配置文件清空记录也不会误删用户配置。七、设计亮点速览亮点收益一次崩溃一个文件写入原子、损坏隔离、天然增量内存列表 磁盘文件双写查询快、断电不丢读旧 → 转新 → 清旧迁移幂等、容错、用户无感升级记录与配置分离存储各取所需互不影响全链路runCatching容错存储异常不影响主功能八、相关源码索引数据持久化核心存储 迁移AppErrorsRecordData.kt崩溃数据对象17 字段 文件名规则AppErrorsInfoBean.ktJSON 序列化工具GsonFormatFactory.kt系统钩子与事件分发FrameworkHooker.kt模块注入入口HookEntry.kt全局配置存储ConfigData.kt应用展示模板配置AppErrorsConfigData.kt【免费下载链接】AppErrorsTrackingAdded more features to apps crash dialog, fixed custom rom deleted dialog, the best experience to Android developer.项目地址: https://gitcode.com/gh_mirrors/ap/AppErrorsTracking创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考