1. 概览
前两章涉及的是LOG系统的使用方法，本章则是深入的分析这些LOG接口的实现原理，如此在使用时能够更加的得心应手的。下面给出粗略的关系图
上面的概览图中，黄色的圈代表logd的一个socket客户端，他们属于不同的进程，因为在Android的Log子系统中一个进程只允许创建一个logd的客户端。
至于logd，这里先将其理解为一个带网络功能的log储存器即可，它和它的客户端是通过socket进行通讯的。
2.C 风格的LOG接口实现
此处就不对每一个接口进行说明了，以 RLOGD 接口为例子进行讲解，希望能起到抛砖引玉的作用。下面看看它的实现
//file:system\logging\liblog\include\log\log_radio.h
#define RLOGD(...) \
((void)__android_log_buf_print(LOG_ID_RADIO, ANDROID_LOG_DEBUG, LOG_TAG, \
__VA_ARGS__))
对于C风格的log输出，它的级别以及所属的log buffer都由不同的宏决定。
a) LOG_ID_RADIO 意味着该log最终被打入logd的radio buffer。
b) ANDROID_LOG_DEBUG 代表该log的级别为调试级别，优先级是最低的。
c) LOG_TAG为什么需要在头文件 log/log.h 之前定义，在此可见一斑，因为log_radio.h被 log/log.h所包含。
d)至于 VA_ARGS 宏，则是代表可变参数，和printf中的一致。
下面看看 __android_log_buf_print 的实现
2.1 __android_log_buf_print 的实现
//system\logging\liblog\logger_write.cpp
int __android_log_buf_print(int bufID, int prio, const char* tag, const char* fmt, ...) {
...
va_start(ap, fmt);
vsnprintf(buf, LOG_BUF_SIZE, fmt, ap);
va_end(ap);
__android_log_message log_message = {
sizeof(__android_log_message),
bufID,
prio,
tag,
nullptr,
0,
buf
};
__android_log_write_log_message(&log_message);
return 1;
}
该函数则是来自于 logger_write.cpp 文件了，所有写log的操作都是经过它的，包括后面c++风格的log输出也不例外。它的入参类型为 __android_log_message ，这也是 __android_log_buf_print 存在的意义及根据RLOGD的入参组合出对应的 __android_log_message 类型的数据，下面来看看它的定义
2.2 __android_log_buf_print 定义
//system/logging/liblog/include/android/log.h
struct __android_log_message {
/** Must be set to sizeof(__android_log_message) and is used for versioning. */
size_t struct_size;
/** {@link log_id_t} values. */
int32_t buffer_id;
/** {@link android_LogPriority} values. */
int32_t priority;
/** The tag for the log message. */
const char* tag;
/** Optional file name, may be set to nullptr. */
const char* file;
/** Optional line number, ignore if file is nullptr. */
uint32_t line;
/** The log message itself. */
const char* message;
};
注释的非常清楚，此处则不再赘述。
在组装好了__android_log_message 数据后，就调用 __android_log_write_log_message 处理，
2.3 __android_log_write_log_message 实现
//system\logging\liblog\logger_write.cpp
void __android_log_write_log_message(__android_log_message* log_message) {
...
logger_function(log_message);
}
2.4 logger_function 的选择
此处的 logger_function 可能会有些疑惑它来自于哪，实际上它在C++风格的LOG接口中是支持配置的，但在C风格中则是使用默认值的，最终输出到logd中去
static __android_logger_function logger_function = __android_log_logd_logger;
void __android_log_logd_logger(const struct __android_log_message* log_message) {
...
write_to_log(static_cast<log_id_t>(buffer_id), vec, 3);
}
2.5 SetLogger 的实现
实际上这个函数决定着来自客户端的log信息的去除，在c++分格的log输出中提到过接口 SetLogger，它最终设置的就是这个值
//system\libbase\logging.cpp
LogFunction SetLogger(LogFunction&& logger)
//system\logging\liblog\logger_write.cpp
__android_log_set_logger(...)
当然c风格的是不支持这种使用的，所以它的实现此处暂略。
2.6 接口实现的文件分布及调用关系
下面给出接口实现的文件分布及调用关系，用于理解接口实现的软件分层
3.C++ 风格的LOG接口实现
同样的，对于C++风格的LOG接口也不一一个说明，以 LOG(INFO) 接口为例子进行讲解，希望能起到抛砖引玉的作用。下面看看它的实现
//system\libbase\include\android-base\logging.h
#define LOG(severity) LOGGING_PREAMBLE(severity) && LOG_STREAM(severity)
LOGGING_PREAMBLE(severity)则是用于展示log前的条件检查，例如其log级别是否规范，下面则是它的展开
3.1 LOGGING_PREAMBLE(severity)
//system\libbase\include\android-base\logging.h
LOGGING_PREAMBLE(severity)
(
WOULD_LOG(severity)//code 1
(
UNLIKELY(
::android::base::ShouldLog(
SEVERITY_LAMBDA(severity),
(//code 1-1
[&]() { \
using ::android::base::VERBOSE; \
using ::android::base::DEBUG; \
using ::android::base::INFO; \
using ::android::base::WARNING; \
using ::android::base::ERROR; \
using ::android::base::FATAL_WITHOUT_ABORT; \
using ::android::base::FATAL; \
return (severity);
}()
)
_LOG_TAG_INTERNAL
)
)
||
MUST_LOG_MESSAGE(severity)
(SEVERITY_LAMBDA(severity) == ::android::base::FATAL)
)
&&
ABORT_AFTER_LOG_EXPR_IF((SEVERITY_LAMBDA(severity)) == ::android::base::FATAL, true)
(//code 2
(
(c)//code 2-1
&&
::android::base::LogAbortAfterFullExpr()
)
||
(x)
)
&&
::android::base::ErrnoRestorer()//code 3
)
其实LOGGING_PREAMBLE 就做一件事，只不过把一件事分成了2个时间做，一个是在编译阶段，另一个则是在代码运行阶段
前者对应code1-1代码，如果传入非using的宏，那么在编译阶段就直接报错了。
后者对应code2-1代码，如果c条件满足那么就直接运行后面的LogAbortAfterFullExpr使程序异常退出。所以也算巧妙吧，如果是fatal级别的就直接走abort分支。
ABORT_AFTER_LOG_EXPR_IF的描述如下，意思就是说前后都为true的话就直接使程序异常退出
Provides an expression that evaluates to the truthiness of `x`, automatically aborting if `c` is true.
3.2 LOG_STREAM(severity)
LOG_STREAM(severity)
//system\libbase\logging.cpp
::android::base::LogMessage(__FILE__, __LINE__, SEVERITY_LAMBDA(severity), _LOG_TAG_INTERNAL, -1).stream()
data_(new LogMessageData(file, line, severity, tag, error))
this->stream()//this ->LogMessage
return data_->GetBuffer()
return buffer_;
LOG_STREAM 则是LOG显示的实现的部分，一个log在使用C++风格的log接口到被现实结果如下几个步骤
a) 实例化 LogMessage 对象，其内部的 LogMessageData 用于描述log数据本身。
b) LoMessage::stream会返回 stringiostream供用户往里添加string 日志。
c) 待 LogMessage 析构时调用对应的接口来显示log。
//file:system\libbase\logging.cpp
LogMessage::~LogMessage() {
std::string msg(data_->ToString());
...
LogLine(data_->GetFile(), data_->GetLineNumber(), data_->GetSeverity(), data_->GetTag(),
msg.c_str());
// Abort if necessary.
if (data_->GetSeverity() == FATAL) {
if (__builtin_available(android 30, *)) {
__android_log_call_aborter(msg.c_str());
} else {
Aborter()(msg.c_str());
}
}
}
从代码上能看出 LogMessage 析构方法中只做两件事
1) Log内容的处理。
2) 如果时FATAL级别的LOG，那么在打印完LOG内容出后调用abort让程序异常退出。很简单在Andorid30及以上的系统使用 __android_log_call_aborter ， 而小于android30的就走Aborter接口，反正最终都会调用我们熟知的 abort 接口的。
NAME
abort - cause abnormal process termination
SYNOPSIS
#include <stdlib.h>
void abort(void);
DESCRIPTION
The abort() function first unblocks the SIGABRT signal, and then raises that signal for the calling process (as though raise(3) was called). This
results in the abnormal termination of the process unless the SIGABRT signal is caught and the signal handler does not return (see longjmp(3)).
If the SIGABRT signal is ignored, or caught by a handler that returns, the abort() function will still terminate the process. It does this by
restoring the default disposition for SIGABRT and then raising the signal for a second time.
RETURN VALUE
The abort() function never returns.
下面来看看 LogLine是怎么处理Log内容的
//file:system\libbase\logging.cpp
void LogMessage::LogLine(...)
__android_log_message log_message = {sizeof(__android_log_message), LOG_ID_DEFAULT, priority, tag, file, line, message};
__android_log_write_log_message(&log_message);
很熟悉吧，和上面C格式的LOG输出接口实现是一致的，最终还是调用了 __android_log_write_log_message，它属于 logger_write.cpp。另外还需要注意一个细节
__android_log_message log_message = {...,LOG_ID_DEFAULT,...};
在使用C++风格的LOG接口是不支持 logd buffer类型选择的，它是代码写死为 LOG_ID_DEFAULT 了
//system\logging\liblog\include\android\log.h
typedef enum log_id {
LOG_ID_MIN = 0,
/** The main log buffer. This is the only log buffer available to apps. */
LOG_ID_MAIN = 0,
/** The radio log buffer. */
LOG_ID_RADIO = 1,
/** The event log buffer. */
LOG_ID_EVENTS = 2,
/** The system log buffer. */
LOG_ID_SYSTEM = 3,
/** The crash log buffer. */
LOG_ID_CRASH = 4,
/** The statistics log buffer. */
LOG_ID_STATS = 5,
/** The security log buffer. */
LOG_ID_SECURITY = 6,
/** The kernel log buffer. */
LOG_ID_KERNEL = 7,
LOG_ID_MAX,
/** Let the logging function choose the best log target. */
LOG_ID_DEFAULT = 0x7FFFFFFF
} log_id_t;
从注释上看，是让log系统自己找到最合适的buffer进行打印，但是理想很美好显示却很骨感，在logd中就是使用 LOG_ID_MAIN 的，即 main buffer。这也就是为什么C++风格的LOG不像C语言风格LOG那样可以自选logd 中的buffer类型。
3.3 接口实现的文件分布及调用关系
下面给出接口实现的文件分布及调用关系，用于理解接口实现的软件分层
4.总结
经过上面的分析可见，不论是那种风格的LOG接口实现，最终调用的都是logger_write.cpp中过提供的一些列接口，对于这部分接口实现请见下一章。
5906
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
