再谈日志系统
1. 面相抽象：不直接使用 printf / std::cout
直接使用 printf 或 std::cout 的弊端在于：不够规模化，修改起来麻烦。
例如，除了想往控制台打印，还希望往文件打印； 想确保每一处打印都有 flush； 想通过 CMake Option， 用一个简单的开关来控制日志的开启和关闭。
使用专门的日志库提供的 宏/函数， 而不是直接使用 printf / std::cout, 是基本的要求。
而 Debug/Info/Warning/Error 等级的划分， 算是日志库的基本功能， 这里不探讨了。
2. 有区分度的打印：专属的 tag
在多人协作、多 SDK 集成的场景下， 所有 log 都输出到控制台时， 怎样区分不同模块的日志？ 每个模块应当有自己独特的 tag， 也就是显示在日志打印的每一行的最开头部分的， 如：
[D] module1: xxxxx
[D] module2: xxxxx
这里的 module1 和 module2 就是 tag。 当程序出现 crash，根据 crash 前最后一次打印的 tag， 来判定职责在哪个模块（SDK）中，对应的开发负责人负责排查（也就是甩锅、背锅）。
3. 自证清白：API函数的进入-离开 log
当调用子模块时，子模块的某个 API 函数是否运行完毕， 决定了谁来背锅。例如有 f 和 g 两个模块， f 负责调用 g 模块的 g1(), g2() 两个 API 函数：
f1()
- g1()
- g2()
f2()
当最终的日志打印中，看到了 g2( ) 内的日志打印、没看到 f2() 的日志打印， 并且 f2() 代码中确实写了日志打印， 这时候如何裁定职责呢？
由于我负责 g 模块， 无法主导 f 模块的排查， 只能在 g1(), g2() 函数中自证清白： 在 API 函数执行的最开头、最末尾， 增加日志打印：
class AutoLogger
{
public:
AutoLogger(const char* name):
m_name(name)
{
XX_LOGD("%s begin()", name);
}
~AutoLogger()
{
XX_LOGD("%s end()", name);
}
private:
std::string m_name;
};
void g2()
{
AutoLogger logger(__FUNCTION__);
... // 原有代码
// XX_LOGD("g2() end"); // 原本有这句，但是无法保证是 g2() 最后执行的内容，因为可能有类实例的析构函数在这句之后执行
}
为了进一步简化代码，以及避免 logger 命名冲突，改为宏定义:
#define API_ENTER_LEAVE_LOG AutoLogger logger##__LINE__(__FUNCTION__)
这样一来，看到的日志一定是这两种之一：
// g 模块没crash
[D] module_g: g2() begin()
[D] module_g: .....
[D] module_g: g2() end()
crash info
// crash 在 g 模块内
[D] module_g: g2() begin()
[D] module_g: .....
crash info
4. 保存现场: 多重输出
一个合格的日志库， 应当能让调用者同时往控制台、文件写入日志，并且支持用户往其他地方写入日志，例如 Android logcat， 或 QNX 系统的 slog。
那么作为使用者，就需要这样写：
static void custom_logger(char* line, FILE* fp)
{
char buf[1024];
sprintf(buf, "%s\n", line);
fprintf(stdout, "%s", buf);
fflush(stdout);
if (!fp && fp!=stdout)
{
fprintf(fp, "%s", buf);
fflush(fp);
}
#ifdef ENABLE_SLOG
{
slog2(DEBUG1, "%s\n", buf);
}
#endif
}
static FILE* s_file = NULL;
void g_init()
{
API_ENTER_LEAVE_LOG();
if (s_file)
fclose(s_file);
s_file = fopen("xxx.log", "wt");
xx_log_register_logger(custom_logger);
}
void g_run()
{
API_ENTER_LEAVE_LOG();
...
}
5. 有效性探讨
个人认为上述 log 内容有一定正向作用，但是只能起到有限作用。 当 f 模块遇到了 "Malloc failed: xxxx" 的报错时，那看起来应该是 glibc 的作者们写 bug 了，我们应当找 glibc 的作者去修改 bug 吗？有这种可能，但是也可能是调用者出了问题。
