前言
- 我们平时开发中发了版本给测试去测，那么测试提了
bug单只说明了问题怎么出现而且不是必现的，或者测试只提了问题描述和出现过程，又或者发布了灰度测试版本，用户反馈了bug，要怎么处理呢？ - 以上几个问题一般最简单的解决方案可能是直接找测试沟通，或者直接叫测试过来
debug调试，对于灰度用户的问题来说，可能就是立刻找测试复现bug，这些解决方案可能是最直接的，也是开发者常用的手段。那么有没有想过这些方案可能非常耗时而且效率慢也不完全能解决灰度用户反馈的问题。 - 这时候就可以想想，如果我可以通过一些工具去查看数据或者查看
log日志，然后再结合测试或者用户的流程和场景去看问题，这样会不会就可以减少沟通的成本。
解决方案
其实上面的问题，完全就可以通过log日志去解决问题，快速远程定位，这样可以高效去回复用户反馈的问题。
log日志系统搭建
- 在
CocoaLumberjack去封装出log的一些配置，比如：log文件最大总数，log单个文件大小，log等级 等等，更多的具体可以去看下这个开源库，本文下面会提供一个demo关于怎么使用，怎么封装的。 - 把
UIViewController的生命周期都打印输出到log里面，这样就可以知道用户去了哪些界面了，从而可以定位是什么功能的问题 - 开发者在开发的是一定要清楚
log的等级关系，知道在什么情况下用什么等级的，这样在看log的时候就很快知道一些明显的问题。 - 开发者在写功能的时候，加
log的位置要恰当，不要过多，也不要过少，过多会使一些关键的log被冲掉，过少会查不到什么信息。其实开发者在开发的时候应该都清楚大概哪些地方会出bug。
日志导出处理
- 可以把日志压缩一键导出出来，分享到微信或者QQ等等平台都可以。
- 日志经过压缩处理上传到服务器（主要针对正式版用户），平时内部测试不建议这样做，因为日志可能比较大，对服务器内存有压力。
demo功能
- 笔者提供的
demo可直接拿到项目中去用，log系统已经封装好了。 -
demo中封装了一键导出log，以及真机查看沙盒工具。 -
MLeaksFinder是微信读书团队开源的内存泄漏工具，这个工具是基于FBRetainCycleDetector开源库去封装的。 -
ZCFPS是笔者自己写的一个无入侵项目帧率检测工具。
结语
- 一个好的开发者，往往会有自己的一大堆工具去提高效率和质量。
点击传送demo工程
如果你也有好的工具或者其他提高效率的方法，欢迎指正和评论区讨论。
网友评论