这篇具有很好参考价值的文章主要介绍了SDK日志上传性能优化。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。
问题描述
在SDK初始化时,会在init方法中开启一个倒计时,在5s倒计时结束后使用子线程将本地保存的历史日志信息上传到后台。
因业务需要,在日志在发送上传前,需要对日志数据做编码和特殊字符替换,而日志文件里包含的日志数据量相比于一般方法中的局部变量要大很多,所以这样集中对日志文件数据的编码和替换就直接导致了CPU占用过高,造成了宿主APP短时间卡住的情况。所以导致了因为SDK体验问题,日志启动上传功能只能被迫关闭,等待优化。
文章来源地址https://www.toymoban.com/news/detail-441094.html
背景描述
SDK在使用过程中会产生日志,在操作正常情况下,一个流程结束就会把当前单次产生的日志上传到后台。而对于异常退出或其他异常时,日志就保留在了本地,等SDK第二次启动时时再上传。
问题解决情况
优化前:SDK启动时,上传日志对CPU的占用量为100%,占用时间为0.5s左右,
优化后:SDK启动时,上传日志对CPU的占用量为40%左右,占用时间为1.5s左右。
CPU使用情况数据采集如下,CPU采集频率为0.5s。
优化前CPU使用情况:
优化后CPU使用情况:
文章来源:https://www.toymoban.com/news/detail-441094.html
日志上传策略
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调用时从后台请求到上传开关保存到本地,等上传时读取开关配置信息,判断是否开启上传。这样可用于紧急情况关闭日志上传功能。
到了这里,关于SDK日志上传性能优化的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!