关于日志输出的一些研究

研究日志的初衷

Tom 创建于 2017-9-8

最新发表:


浅谈面向对象的SDK的结果处理方式

返回值、代理还是其他方法

你可能感兴趣的内容:


C/C++ 编程需要的注意的问题

关于日志输出的一些研究

无意间发现了一个问题。代码执行的过程中,经常会出现一个高耗时的步骤。这个高耗时的步骤,之前也没有特别注意。在早期的iPhone下执行,偶尔会遇到卡顿的问题。加了一些代码,缩小打印范围。发现这个高耗时步骤,不是必现的,偶然的情况下会卡顿时间较长。这个步骤,经过一定时间的定位,终于在找到是日志的问题。

日志系统

在最早的SDK里面,是不存在日志系统的。日志系统存在的必要性,是为了更好的定位问题,查找开发者、客户反馈的一些问题而设计。现在,日志成为瓶颈的原因,对于iPhone7来说可能也会比较卡顿。因为整个app,放在PC上跑,都会有明显的延时,更不用说手机了。

打印日志耗时对比

最近这段时间,拿了NSLog、fprintf做了对比。使用iPhone5s进行测试,50~100个样本中,测试20次:

NSLog在某一个步骤最长耗时:1.6s,平均耗时50~100ms
fprintf在某一个步骤最长耗时:80ms,平均耗时10~20ms

可参考的,别人的测试数据《再见了 NSLog》

执行一个动作,打印日志就要阻塞1.6秒,在手机上不卡才怪。优化第一步:先把NSLog替换为fprintf(stdout,xxx),性能有所改善。牺牲了一个功能,可以线上看输出的日志。

终极优化思路

要做到日志系统不影响接口的性能,只能把日志文本扔到一个单向链表中,由另一个线程负责终端、文件输出。当前在iPhone5s测试,50~100个样本中,测试20次:

使用队列在某一个步骤最长耗时:40ms,平均耗时0.9~1.4ms

iPhone上换了终极优化后的应用,要的就是这种流畅。