1、腾讯buly的崩溃上传原理，简单说一下
通过异常捕获机制收集崩溃信息，在应用下次启动时异步上报到服务器。整个过程分为崩溃捕获、数据收集、本地存储、延迟上报四个核心环节。
2、崩溃捕获阶段
Bugly通过以下方式捕获异常：
- Java层崩溃：设置
Thread.UncaughtExceptionHandler作为全局异常处理器，捕获未处理的异常 - Native层崩溃：通过信号处理器（signal handler）捕获SIGSEGV、SIGABRT等信号
- ANR检测：通过监控主线程消息队列的执行时间来判断应用无响应 当崩溃发生时，系统会调用Bugly注册的异常处理器，此时应用进程即将终止。
3、数据收集与存储
在异常处理器被调用后的极短时间内（通常几十毫秒），Bugly会：
- 收集崩溃堆栈信息、设备信息（机型、系统版本等）、应用版本等关键数据
- 将数据序列化后写入本地文件（通常在应用私有目录的特定文件夹）
- 记录崩溃时间戳和上报状态标记
关键点：这个过程必须快速完成，因为应用即将被系统终止，长时间操作可能导致数据丢失。
4、延迟上报机制
崩溃数据不会在崩溃发生时立即上传，而是：
- 在应用下次正常启动时（用户再次打开App）
- 检查本地是否有未上报的崩溃日志
- 在后台线程异步发起网络请求，将数据上传到Bugly服务器
- 上传成功后删除本地文件，失败则保留等待下次尝试
这种"崩溃时存本地，启动时再上传"的设计，避免了崩溃时网络不稳定导致数据丢失的问题。
5、上报触发时机
上报操作在应用启动后的合适时机触发：
- 通常在初始化完成后，网络可用时
- 可能延迟几秒到几分钟，避免影响应用启动性能
- 支持批量上传（多个崩溃日志一起发送）
6、网络与重试机制
- 使用HTTP/HTTPS协议与服务器通信
- 支持断点续传和失败重试（通常有最大重试次数限制）
- 在WiFi环境下优先上传，移动网络下可能延迟或限制大小
7、本地存储策略
崩溃日志采用文件形式存储，通常包含：
- 崩溃堆栈（已符号化或原始地址）
- 设备环境信息
- 自定义附加数据（如用户ID、业务场景标签）
- 时间戳和版本标识
存储时会进行压缩和加密处理，减少存储空间占用并保护用户隐私。
8、为什么这样设计？
这种"先存后传"的方案主要基于以下考虑：
可靠性：崩溃时网络可能不可用，立即上传容易失败。本地存储确保数据不丢失。
性能影响：崩溃时应用即将终止，复杂操作可能被系统强制终止。简单存储操作更可靠。
用户体验：崩溃时用户可能立即关闭应用，网络请求可能被中断。延迟上传不影响用户当前操作。
数据完整性：可以收集更完整的上下文信息（如崩溃前的用户操作路径），这些信息在崩溃时可能无法完整获取。
