(资料图片)

问题描述在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就继续递归调用上传，否则就什么也不做，结束上传操作。另外，通过后台配置上传开关，在SDK调用时从后台请求到上传开关保存到本地，等上传时读取开关配置信息，判断是否开启上传。这样可用于紧急情况关闭日志上传功能。