SDK日志上传性能优化

问题描述

在SDK初始化时，会在init方法中开启一个倒计时，在5s倒计时结束后使用子线程将本地保存的历史日志信息上传到后台。

因业务需要，在日志在发送上传前，对日志数据上传时需要对日志数据做编码和特殊字符替换，而日志文件里包含的日志数据量相比于方面里的局部变量要大很多，所以这样集中对日志文件的编码和替换，直接导致完全占用了CPU造成宿主APP短时间卡住。所以导致了因为SDK的这启动体验问题，日志启动上传功能只能被迫关闭，等待优化。

背景描述

SDK在使用过程中会产生日志，在操作正常情况下，一个流程结束就会把当前单次产生的日志上传到后台。而对于异常退出或其他异常时，日志就保留在了本地，等SDK第二次启动时时再上传。

问题解决情况

优化前：SDK启动时，上传日志对CPU的占用量为100%,占用时间为0.5s左右,

优化后：SDK启动时，上传日志对CPU的占用量为40%左右,占用时间为1.5s左右。

 

CPU使用情况数据采集如下，CPU采集频率为0.5s。

优化前CPU使用情况：

优化后CPU使用情况：

日志上传策略

1.当APP调用SDK的init方法初始时，在init方法中会开启一个倒计时，在5s后使用子线程进行发起上传。

2.上传方法调用后，日志工具会遍历本地日志目录下的日志文件，并将日志文件创建成NSData。

3.然后日志工具逐个读取未上传成功标记的日志数据进行data拼接。

4.每当一个Data日志拼接后会判断当前批次拼接的Data的大小是否大于100k, 如果大于则把数据放入请求参数，异步发送一个网络请求，重新创建一个Data可变对象。

5.循环执行3-4操作，直到所有的本地日志都发送到后台

当前日志上传策略逻辑清晰，但是存在一个问题。

虽然每个上传请求都是使用子线程上传不影响主线程，但是当本地日志量大时，比如有10M日志，那么可能会同时发生100条请求，并在同一时间段内集中对日志数据进行编码和特殊字符替换。这样直接就把CPU资源抢光了，所以会造成APP卡顿。

解决方法

以时间换空间，用户对日志上传时无感知的，只要不影响APP的使用就好。按照这个原则上传策略可以改为只使用一个线程，让这100个上传请求做串行上传。

如何让子线程的网络请求串行执行呢？

将上传方法在成功回调中做递归调用。递归出口是判断带上传的日志个数，如果个数大于0就继续递归调用上传，否则就什么也不做，结束上传操作。

另外，通过可通过后台配置上传开关，从后台下发上传开关标志到本地，上传时读取配置，判断是否开启上传，用于异常情况紧急关闭日志上传功能。