Android的log机制小结_android log机制-CSDN博客

本文链接：https://blog.csdn.net/snail_coder/article/details/12619029

Android的log机制小结

本文是对Android的log机制学习的小结，内容包括对log框架的理解、写log、读log和log的驱动这几个部分。

一、 log框架

log机制包括三部分：底层驱动、读和写。关于写log，我们可以在Java文件中，或者jni层的C/C++代码中添加类似log.d（）这样的代码来实现写log，通过logcat命令来输出我们想要查看的log，驱动的任务则是真正地帮助我们实现读和写。

http://blog.csdn.net/mickeyfirst/article/details/6233885

引用这张图来说明log的框架。我们在JavaProgram或者Native Program中通过android.util.Log或者System.out或者log.h为我们提供的一下方法如Log.d或者ALOGD，就能把log添加进去，最终这些log都被底层驱动写到了如下四个设备中：

/dev/log/main

/dev/log/radio

/dev/log/event

/dev/log/system

之后我们可以通过logcat命令或者Eclipse中的logcat来查看和过滤log，不过这些最本质上是调用logcat命令，Eclipse中的logcat或者adblogcat命令都是对通过adbd进程远程调用logcat命令罢了。这就是基本的框架，下面将详细分析各个部分。

二、写log

这里我们把写log的方式简单分为两类：Javaprogram和Native Program。首先来看Java层的log写入。以最简单的android.util.Log为例。

public staticfinal int VERBOSE = 2;

public static final int DEBUG = 3;

public static final int INFO = 4;

public static final int WARN = 5;

public static final int ERROR = 6;

publicstatic final int ASSERT = 7;

log分级别，对应的数字越大，则级别越高，这在过滤log时会用到。这个文件提供了许多公共的静态方法，我们可以直接通过类名调用。下面是Log.d()方法：

publicstatic int d(String tag, String msg) {

return println_native(LOG_ID_MAIN,DEBUG, tag, msg);

}

这个方法大家都很熟悉，不再叙述，只请注意一点：LOG_ID_MAIN

这个类中的其它方法最终也会调用这个本地方法：

publicstatic native int println_native(int bufID, int priority, String tag, Stringmsg);

它的实现则在jni层：android_util_Log.cpp文件中，有如下定义：

staticJNINativeMethod gMethods[] = {

    { "isLoggable",      "(Ljava/lang/String;I)Z",(void*) android_util_Log_isLoggable },

    { "println_native", "(IILjava/lang/String;Ljava/lang/String;)I", (void*)android_util_Log_println_native },

};

从这里可以看出，println_native这个方法对应的是该文件中的android_util_Log_println_native方法。继续看这个方法，发现它最终调用logd_write.c文件中__android_log_buf_write方法，调用层次如下：

__android_log_buf_write

write_to_log

__write_to_log_init

__write_to_log_kernel

log_writev

writev

log_fds[LOG_ID_MAIN]= log_open("/dev/"LOGGER_LOG_MAIN, O_WRONLY);

log_fds[LOG_ID_RADIO]= log_open("/dev/"LOGGER_LOG_RADIO, O_WRONLY);

log_fds[LOG_ID_EVENTS]= log_open("/dev/"LOGGER_LOG_EVENTS, O_WRONLY);

log_fds[LOG_ID_SYSTEM]= log_open("/dev/"LOGGER_LOG_SYSTEM, O_WRONLY);

#defineLOGGER_LOG_MAIN          "log/main"

#defineLOGGER_LOG_RADIO              "log/radio"

#defineLOGGER_LOG_EVENTS     "log/events"

#defineLOGGER_LOG_SYSTEM     "log/system"

这些调用过程比较简单，在不断调用的过程中也对数据进行了一些判断和处理。这里需要说的是，一般我们使用Log.d方法输出的log，都会写入到/dev/log/main中，因为这个函数定义中传入了 LOG_ID_MAIN这个参数。而对于以slog.d这种方式添加的log，一般都写到了/dev/log/system，因为它的定义如下：

publicstatic int d(String tag, String msg) {

return Log.println_native(Log.LOG_ID_SYSTEM,Log.DEBUG, tag, msg);

}

而/dev/log/radio中一般都是些和通讯相关的log会保存在这里，/dev/log/event则保存了一些事件相关的log，再具体的我不是很清楚。

我们通过一步步跟踪方法调用，最终找到了writev这个方法。这里先留个疑问，接下来再看C/C++文件中使用log。以ALOGD方法为例：

system/core/include/cutils/log.h

ALOGD

(void)ALOG(LOG_DEBUG,LOG_TAG, __VA_ARGS__)

LOG_PRI(ANDROID_##priority,tag, __VA_ARGS__)

android_printLog(priority,tag, __VA_ARGS__)

__android_log_print(prio,tag, fmt)

__android_log_print

__android_log_write

write_to_log

……

writev

最终也会调用writev这个方法（在开始写log之前还调用了open这个方法去打开设备），但是再向下就不能继续跟踪了，之后就会执行驱动层的相关代码。在调用驱动层的代码时，会根据传入的filedes这个参数找到对应设备的驱动，这里这个值为/dev/log/main对应的那个设备。

三、log的底层驱动

相关文件位置：

kernel/drivers/staging/android/logger.c

kernel/drivers/staging/android/logger.h

首先，前面已多次提到，被驱动的设备有四个，位置在dev/log下。

yutao@yutao:~$adb shell

root@android:/ #ll dev/log

crw-rw-rw-root log 10, 46 2013-01-01 08:00 events

crw-rw-rw-root log 10, 47 2013-01-01 08:00 main

crw-rw-rw-root log 10, 45 2013-01-01 08:00 radio

crw-rw-rw-root log 10, 44 2013-01-01 08:00 system

其中的c 标示这是一个字符设备文件characterdevice ，也表示硬件设备，但是数据是以字节流发送的，这些设备包括终端设备和串口设备。我们不能利用adb pull命令将其取出来。这里的10是主设备号，表明它是misc设备。我们可以通过logcat–g –b main这样的命令来查看各个设备的大小信息

root@android:/ #logcat -g -b main

/dev/log/main:ring buffer is 256Kb (255Kb consumed), max entry is 5120b, max payload is 4076b

这里显示/dev/log/main这个设备的buffer大小为256Kb，没条log包含的内容最大为4076b。我们不断地向这个设备中写log，当它的buffer不够用时，它就会从头开始写，也意味着之前的log就会被覆盖掉，这些可以在代码中看到。

然后，我们来看设备驱动的主要工作。我对驱动的理解比较肤浅，就是应该要做一些初始化的工作，然后提供读和写的借口给上层，所以我也只关注这些内容。关于初始化工作，请看如下代码：

static conststruct file_operations logger_fops = {

.owner = THIS_MODULE,

.read = logger_read,

.aio_write = logger_aio_write,

.poll = logger_poll,

.unlocked_ioctl = logger_ioctl,

.compat_ioctl = logger_ioctl,

.open = logger_open,

.release = logger_release,

};

这里声明了一个static结构体变量logger_fops，它是file_operations结构体，这个file_operations结构体似乎在linux系统中很常见，这里我们只需要知道它为上层调用提供了接口。举例：上层想要往这个设备文件里写内容的话，就可以调用read方法，当然在使用read方法时还传入了一个与设备名称绑定的值，可能是 LOG_ID_MAIN这样的值，它指向了/dev/log/main这个设备，因此就会调用我们这个驱动的与read关联的方法，就是logger_read。而如果用户调用了aio_write方法时，就会执行这里的logger_aio_write方法。不过logger_aio_write方法的注释中有提到，当用户调用aio_write、write或者writev方法时，都会执行logger_aio_write方法。这首先解释了我们在之前的疑问：在logd_write.c文件中最终走到了writev之后就再看不到更底层的代码了，现在知道是到了驱动层。至于为何使用哪个write方法都会走这里，我也不清楚，猜测是不是因为它只提供了一个write方法，所以只能走这里。

下面的代码是四个设备的创建（个人理解）：

#defineDEFINE_LOGGER_DEVICE(VAR, NAME, SIZE) \

static unsignedchar _buf_ ##VAR[SIZE]; \

static structlogger_log VAR = { \

.buffer = _buf_ ## VAR, \

.misc = { \

        .minor = MISC_DYNAMIC_MINOR, \

        .name = NAME, \

        .fops = &logger_fops, \

        .parent = NULL, \

}, \

.wq = __WAIT_QUEUE_HEAD_INITIALIZER(VAR .wq), \

.readers = LIST_HEAD_INIT(VAR .readers), \

.mutex = __MUTEX_INITIALIZER(VAR .mutex), \

.w_off = 0, \

.head = 0, \

.size = SIZE, \

};

 

DEFINE_LOGGER_DEVICE(log_main,LOGGER_LOG_MAIN,256*1024)

DEFINE_LOGGER_DEVICE(log_events,LOGGER_LOG_EVENTS,256*1024)

DEFINE_LOGGER_DEVICE(log_radio,LOGGER_LOG_RADIO,256*1024)

DEFINE_LOGGER_DEVICE(log_system,LOGGER_LOG_SYSTEM,256*1024)

这里每个设备的buffer大小都是256Kb，它们都是misc设备，且在.fops= &logger_fops中指明了上层调用这个设备的关联的方法或接口为刚才提到的logger_fops静态结构体变量。

device_initcall(logger_init);这里指明初始化方法为logger_init，之后调用init_log方法，通过misc_register这个方法来注册misc设备，这里的细节我也不清楚。

这些应该就是初始化工作了，稍微总结一下就能得到如下关心的结果：当上层调用read、writev和open方法时，就会执行这里的logger_read、logger_aio_write和logger_open方法。当然，在调用时一定也在参数中指明了操作的设备是哪个，这可以通过类似LOG_ID_MAIN这样的量来知名。了解这些就够了。

为了更深入地了解对log的操作，我们来简单分析下logger_aio_write中的关键代码。

log的读取和写入都是以一条记录为单位进行的，每条记录包含的内容都在logger_entry这个结构体中定义，包含进程和线程ID，时间，target和输出信息等内容。可是我们知道，我们在添加log时只是指定了优先级、target和输出信息这些内容，并未给出进程和线程id、时间等信息，这些都是在这个方法中添加的：

structlogger_entry header;

struct timespecnow;

now =current_kernel_time();

header.pid = current->tgid; //进程id

header.tid = current->pid; //线程id

header.sec = now.tv_sec; //时间s

header.nsec = now.tv_nsec; //时间ns

header.euid = current_euid();

header.len = min_t(size_t, iocb->ki_left,LOGGER_ENTRY_MAX_PAYLOAD);

header.hdr_size = sizeof(struct logger_entry);

target和输出内容等信息已经被包装在了structiovec *iov中，所以只要将这里的信息和header中的内容写入到设备的buf中即可：log->buffer。关于这些结构体各项代表的内容有兴趣的可以仔细研究。这里的buffer就是之前在创建设备时申请的具有256Kb大小的数组。

真正写log的方法是do_write_log，

do_write_log(log,&header, sizeof(struct logger_entry));

nr =do_write_log_from_user(log, iov->iov_base, len);

多次调用这个方法将header和iov中的信息写入到设备的buffer中。

static ssize_tdo_write_log_from_user(struct logger_log *log, const void __user *buf, size_tcount)

//log就代表了设备，我们需要将信息写入到设备的buffer中：log->buffer

//buf则存储了log信息

//count为log信息的大小

{

size_t len;

 

len = min(count, log->size - log->w_off);

//log->size为buffer的大小

//log->w_off为当前缓冲区偏移量

//此处比较count（log大小）与缓冲区剩余字节（log->size- log->w_off），取其小者首先复制

if (len &©_from_user(log->buffer + log->w_off, buf, len))

        return -EFAULT;

 

//如果这里不相等，则意味着缓冲区剩余空间比log的字节数小，因此剩余的log信息则需要写到缓冲区的最前面

if (count != len)

        if (copy_from_user(log->buffer, buf +len, count - len))

               return -EFAULT;

//重新定向buffer的偏移量

log->w_off = logger_offset(log,log->w_off + count);

 

return count;

}

这部分分析我们可以得出如下结论：每个设备有256Kb的缓冲区域，新的log信息会一条条地依次写入到缓冲区，当缓冲区满后，则又从缓冲区的头开始继续写，因此，最前面的log就会被覆盖。但是每条log的大小也有限制：

#defineLOGGER_ENTRY_MAX_PAYLOAD 4076

#define LOGGER_ENTRY_MAX_LEN(5*1024)

四、读log

log的读取则由logcat命令来完成。相关文件为system/core/logcat/logcat.cpp。logcat命令可以过滤和查看log信息，关于它的使用这里不提。logcat命令的入口函数当然是该文件的main方法。实际读取log的方法是readLogLines方法，当然最终还是要调用我们前面提到的read方法：

ret =read(dev->fd, entry->buf, LOGGER_ENTRY_MAX_LEN);

一般地当我们输出log时，输出的是/dev/log/main设备中的log信息，如果想输出其它三个设备的log，可以使用-bradio参数来输出radio设备中的信息。

对于adblogcat命令输出log和Eclipse中的logcat输出log，它实际也是使用logcat命令，只是那是通过一些其它方式来间接地调用而已。

这部分只能分享到这里，更多的细节请大家自己学习。

五、小结

根据个人片面的理解，Android的log机制主要包括三部分：读、写和驱动，而驱动是核心。但是我们真正需要熟练掌握的应该是读和写。由于log机制贯穿了应用层、framework层和驱动层，学习它对于我们深入学习android还是有帮助的。