本文来自于腾讯bugly开发者社区,非经作者同意,请勿转载,原文地址:http://dev.qq.com/topic/57ff5932cde42f1f03de29b1
本文来源: 微信客户端开发团队
前言
mars 是微信官方的终端基础组件,是一个使用 C++ 编写的业务性无关,平台性无关的基础组件。目前已接入微信 Android、iOS、Mac、Windows、WP 等客户端。现正在筹备开源中,它主要包括以下几个部分:
- comm:可以独立使用的公共库,包括 socket、线程、消息队列等
- xlog:可以独立使用的日志模块
- sdt:可以独立使用的网络诊断模块
- stn:可以独立使用的信令分发网路模块
本文章是 mars 系列的第一篇:高性能跨平台日志模块。
正文
对于移动开发者来说,最大的尴尬莫过于用户反馈程序出现问题,但因为不能重现且没有日志无法定位具体原因。这样看来客户端日志颇有点“养兵千日,用兵一时”的感觉,只有当出现问题且不容易重现时才能体现它的重要作用。为了保证关键时刻有日志可用,就需要保证程序整个生命周期内都要打日志,所以日志方案的选择至关重要。
常规方案
方案描述: 对每一行日志加密写文件
例如 Android 平台使用 java 实现日志模块,每有一句日志就加密写进文件。这样在使用过程中不仅存在大量的 GC,更致命的是因为有大量的 IO 需要写入,影响程序性能很容易导致程序卡顿。选择这种方案,在 release 版本只能选择把日志关掉。当有用户反馈时,就需要给用户重新编一个打开日志的安装包,用户重新安装重现后再通过日志来定位问题。不仅定位问题的效率低下,而且并不能保证每个需要定位的问题都能重现。这个方案可以说主要是为程序发布前服务的。
来看一下直接写文件为什么会导致程序卡顿
当写文件的时候,并不是把数据直接写入了磁盘,而是先把数据写入到系统的缓存(dirty page)中,系统一般会在下面几种情况把 dirty page 写入到磁盘:
- 定时回写,相关变量在/proc/sys/vm/dirty_writeback_centisecs和/proc/sys/vm/dirty_expire_centisecs中定义。
- 调用 write 的时候,发现 dirty page 占用内存超过系统内存一定比例,相关变量在/proc/sys/vm/dirty_background_ratio( 后台运行不阻塞 write)和/proc/sys/vm/dirty_ratio(阻塞 write)中定义。
- 内存不足。
数据从程序写入到磁盘的过程中,其实牵涉到两次数据拷贝:一次是用户空间内存拷贝到内核空间的缓存,一