淮北建站大数据查询平台

        其实并没有想完整就设计一个好用的Log系统，然后发出来。记录这个的原因，是在书里看到这么一句话，Log会消耗资源，特别是写文件，因此可以设置一个Log缓冲区，等缓冲区满了再一次性写入文件，以节省资源。

        这个想法绝对是没有问题的，即便是整个缓冲的设计都不是难事，问题在于，如果日志还没有写入缓冲区，游戏闪退了，那这部分缓冲区的日志该如何写入文件呢？特别是闪退前后往往可能是伴随着关键Log信息的。

        一个直观的想法是，是不是需要由SDK或一个独立于应用的进程去完成这项操作，但设计复杂度一下子就上来了，包括参考了很多资料，都没讨论这件事。所以到底是否需要缓存，一个不错的设计该怎么做？

        通过查看项目的日志系统，其实也没有这么做。只要开一个独立的线程去做这件事，就不会对主线程造成太大影响。日志名附上时间信息，然后定期清理老旧的日志即可，代码很短，也很好用。

        然后就是研发环境下有些日志可以不打印到生产环境里。可以用宏做好控制，也可以按输出标签过滤(debug, developDebug,warning, error)等，不意味着生产环境中就不需要debug信息，而只有error，因为debug信息很多时候也打印了许多关键的流程信息，系统设备信息等用于辅助检查问题。

        至于怎么样让打印变的好看，那可以自己研究研究，像ConsolePro等有专门的插件做这件事情，并不关键。

        另外要小心的一点是，遇到帧报错事件，如果处理不好，会有大量的日志往文件里写，每帧写好多个，会造存储的浪费和大量快速的GC问题，这个还是要提防一下。但不是一件太好处理的事情。因为日志里可能会带有stacktrace信息，导致字符串特别大，对比的话会比较消耗性能。一个可能的处理办法是，每一段时间处理一定量的log数目，在正常情况下，日志的出口效率是比进入效率要高的，如果检测到某一刻日志队列已经超出了阈值，就可以清空处理等等。或者检测到日志产生的频率很高，error类型的，以1条/帧的速率在产生，那就可能是遇到了问题。总之可以根据具体情况去看。