移动端日志回捞处理方案可行性探索

开发者可能都会遇到类似的场景，用户安装了app，出现崩溃或出现其他问题时，日志还没有上报或上报失败，导致一些问题无法定位，影响问题处理的进程，下面提出三个日志回捞的方案，结合使用，以达到主动上报的目的。

一、经典的日志回捞方案UNNotificationServiceExtension

经典的日志回捞需依赖Push唤醒app。客户端接到push时，在push的回调方法中调起日志“主动上报”方法，有至少6秒的时间(通知栏弹出收起的时间)，可以用来处理上报接口的请求响应。流程如下图：

经典回捞流程

瓶颈：客户端被唤醒收到Push消息，受一些条件影响：

• Android需要确保Push进程在后台存活；
• iOS需打开通知权限；
• 网络环境太差，Android上Push长连建立不成功。

二、分析用户行为回捞方案

站在用户角度，分析用户反馈途径，在反馈途径中埋点，调起日志“主动上报”方法。流程如下图：

用户行为回捞.png

如：用户在点击我的客服，进行电话投诉时，先触发日志上报，再调起拨打电话。然后客服接到投诉后，收集用户投诉信息的同时，并再次指导用户上报日志，如检查网络功能（这功能也是点击时，先触发上报）等。其他上报功能与此类似。

三、长连接方案

mqtt未完待续......