关于SDK异常捕获后的实时上传-产品向

ps：我是个产品，虽然是java转的，但是代码都忘光了，这篇文章纯粹是记录讨论解决方案，不涉及具体技术实现方法。

背景介绍：
一个bugly多年的忠实粉问我：
他：你们的产品在获取崩溃bug的时候是实时上传的吗？
我：不是，我这边是用户发生崩溃后，再次启动应用的时候下拉配置（上传）；
他：哦。那这样有个问题呀，如果用户崩了，直接卸载应用，岂不是我永远也统计不到这个数据了？数据不准确呀！
我：嗯，确实是这样。
他：那我就不敢用了，有隐患。
我：（卧槽！你的东西是多烂，崩溃了人家立马卸载）好，我这边跟研发童鞋商量一下，把这里优化一下。

场景分析：
1、用户定位为新用户，因为老用户对应用会有一定的忍耐力，不会那么随便的就卸载（烂得突破天际除外）；
2、新用户首次进入刚开始体验（未发现亮点）的时候就发生了崩溃，才会导致其在使用者眼里失去价值，从而卸载；

实现目标：应用崩溃时直接将crash数据下拉，并上传到平台数据库中；

问题难点：
1、当前下拉的崩溃数据分为两部分，一为崩溃截图，一位崩溃信息（设备信息、堆栈信息什么），这两部分是异步请求的，以安卓为例：在发生崩溃时，SDK会自动对界面进行截图和下拉错误数据保存在本地，然后在应用再次启动时，将错误数据上报到SDK Android的库，然后在上报到平台的数据库中，上报成功则返回值，再将截图上报到平台数据库中；
2、要实现崩溃实时上报数据，就需要在发生崩溃到进程结束中间的时间内执行，或者通过其他办法在进程结束后也可以执行；
3、当网络不稳定的时候，如何避免数据上报不上来或者重复上报；
4、数据准确性和完整性；

解决方案：
方案一：
1、通过api控制截图的开启和关闭，开启截图则不进行实施上报，关闭则实时上报；最大量的避免网络影响。
2、为错误数据添加id，当上传重复数据的时候根据id进行去重；
3、数据上传失败后进行重复上传，保障数据不丢失；
4、通过跑脚本的方式，在进程结束后执行上报操作（但是不稳定）；
方案二：
1、截图和错误数据都是进行实时，首次上报失败后则等下次启动时再上报‘；
2、其他步骤相同；

担心点：
1、数据准确性和性能问题：客户担心点就是丢数据，但是我担心这样这样还是会丢数据，而且更严重；
2、性能问题：无论是脚本还是在控制进程结束时间，都可能存在更多不确定因素，会不会对用户使用造成影响；
3、SDK负载：SDK包瘦身以及缓存机制问题；

结论：哎。。。。。走一步看一步吧，帮不上忙只能听听看。