zTraceV和zTraceQ是所有程序日志使用的；zTraceP和zTracePV则是用来给SHELL用的，且只用在明确的提示信息输出，比如在ShowTaskName()函数里使用。SHELL的运行错误等内容，同样是调用zTraceV或是zTraceQ。TraceHex是个额外的封装，按16进制方式，输出buff内容。这里的V表示包含刚刚那个verbose调试信息，而Q则表示不包含。
zTraceV和zTraceQ都需要提供level。以前哥是把它们做成函数的，但后来发现，有时候用户会传进非法的level；再就是，函数会造成不必要的开销，即便level判断不需要打印，也会造成相当大的运行开销。因此，现在它们被改成了宏，如此一来，level判断在生成打印函数的堆栈信息前，就做了判断，避免了不必要的堆栈变化。
对于使用者来说，这些也都还是透明的。只有再下面的定义，才是他们要关心和使用的。哥给出的zTrace，分5个级别：zTraceFatal，zTraceAlarm，zTraceError，zTraceWarn，zTraceInfo，和zTraceDebug。针对不同的需求，有分为V，Q，Hex，HexQ四个类别。编程的时候，大约95%的情况下，我们只用那5个基本接口（默认Verbose模式）。
下面是个样例：
int DataBlockFreeCount(void* pool) { zDataPool_t *pPool = (zDataPool_t *)pool; if(!pool) { zTraceWarn(); return -1; } return pPool->freeCount; }
注意了，level是个bit位，每个level都是独立的。这里哥用的是warn，而不是其它level。建议是，系统初始化代码里，多用fatal，因为那会出错了就意味着系统没法运行；alarm级别多用在系统性错误，表示系统已经没法服务了；error级别则不要随便用于运行错误，只能用于编码错误；warn级别用于业务或是一般程序运行错误；info级别专供输出主要业务逻辑，比如接口消息的输出，用于定位业务故障；debug级别就是开放给程序员用的，想用就用吧！
info级别其实可以被扩展成msginfo和runinfo的，那样可能更好用。另外，level可以定义成32bits的，那样的话，应用程序可以把info级别扩展成若干个feature相关的level。
在程序设计中，除了专供中断等需要频繁调用高效处理场合使用的代码，zTrace没什么限制。而且，zTrace不需要使用前做初始化(g_zTraceLock编译初始化成unlock)，因此程序可以在任何时间使用。
如何做到让zTrace根据模块或是线程来定制日志输出级别？在zTrace编程大家看到的样子前，我是用模块号来定制输出的。但那么做，就需要在zTrace的参数里提供模块号。这么做挺好的，可以把一个任务切割成几个不同的功能模块来定制日志级别；缺点是，很多函数是公用的，而且应用中，常常看到打印后，却不知道到底是哪个任务打印的。于是，慢慢的，就演进到现在的样子：根据线程来决定级别。
为避免不必要的CPU开销，zTrace首先判断是否使用common的level配置；只有在调试状态（这时候，性能不再重要），才会出现定制的level。当然，针对线程的定制level也并不是那么可怕，只不过微微多占用点CPU罢了。
在结束前，哥建议使用者多利用zTraceLevelSet函数。比如，以前我做电话交换系统，会在消息入口处，对将主、被叫电话号码同跟踪列表进行比对，当发现需要跟踪时，会使用zTraceLevelSet置日志info级别，而处理完消息后，则重置成默认级别。之前我讲状态机编程的时候，提到了FsmTrace。在使用中，FsmTrace一样需要选择性的trace，那是通过traceId来控制的。
好了，差不多讲完了。zTrace虽好，但仍需配合其它手段使用，比如EOS等，绝不可偏废。做任何系统，都应该目标“5分钟找到问题”，“没必要重现故障”。当然，开发工作量也至少会多出一倍。
相关文章
精彩导读
热门资讯
关注我们
