运城市住房和城乡建设部网站,莱芜网逃人员,网站在线咨询系统,深圳保障性住房规划其实并没有想完整就设计一个好用的Log系统#xff0c;然后发出来。记录这个的原因#xff0c;是在书里看到这么一句话#xff0c;Log会消耗资源#xff0c;特别是写文件#xff0c;因此可以设置一个Log缓冲区#xff0c;等缓冲区满了再一次性写入文件#xff0c;以节省资… 其实并没有想完整就设计一个好用的Log系统然后发出来。记录这个的原因是在书里看到这么一句话Log会消耗资源特别是写文件因此可以设置一个Log缓冲区等缓冲区满了再一次性写入文件以节省资源。 这个想法绝对是没有问题的即便是整个缓冲的设计都不是难事问题在于如果日志还没有写入缓冲区游戏闪退了那这部分缓冲区的日志该如何写入文件呢特别是闪退前后往往可能是伴随着关键Log信息的。 一个直观的想法是是不是需要由SDK或一个独立于应用的进程去完成这项操作但设计复杂度一下子就上来了包括参考了很多资料都没讨论这件事。所以到底是否需要缓存一个不错的设计该怎么做 通过查看项目的日志系统其实也没有这么做。只要开一个独立的线程去做这件事就不会对主线程造成太大影响。日志名附上时间信息然后定期清理老旧的日志即可代码很短也很好用。 然后就是研发环境下有些日志可以不打印到生产环境里。可以用宏做好控制也可以按输出标签过滤(debug, developDebug,warning, error)等不意味着生产环境中就不需要debug信息而只有error因为debug信息很多时候也打印了许多关键的流程信息系统设备信息等用于辅助检查问题。 至于怎么样让打印变的好看那可以自己研究研究像ConsolePro等有专门的插件做这件事情并不关键。 另外要小心的一点是遇到帧报错事件如果处理不好会有大量的日志往文件里写每帧写好多个会造存储的浪费和大量快速的GC问题这个还是要提防一下。但不是一件太好处理的事情。因为日志里可能会带有stacktrace信息导致字符串特别大对比的话会比较消耗性能。一个可能的处理办法是每一段时间处理一定量的log数目在正常情况下日志的出口效率是比进入效率要高的如果检测到某一刻日志队列已经超出了阈值就可以清空处理等等。或者检测到日志产生的频率很高error类型的以1条/帧的速率在产生那就可能是遇到了问题。总之可以根据具体情况去看。 翻译 搜索 复制
