解读Android LOG机制的实现

Android提供了用户级轻量的LOG机制，它的实现贯穿了Java，JNI，本地c/c++实现以及LINUX内核驱动等Android的各个层次，而且足够简单清晰，是一个相当不错的解读案例。本系列文章针对LOG机制的内部实现机理进行解读，本文是系列的第一篇，解读LOG机制的实现架构。

LOG的运行环境

    下图是Android官方网站上给出的Android的Debug环境。

    Android的LOG机制当然也在这个环境中运行。我们重点关注Emulator和Device上运行的部分，App VMs产生LOG信息，并与ADB Device Daemon交互输出这些信息，而ADB Device Daemon又通过相应的协议通过USB（Device）或本地连接（Emulator），与PC上运行的ADB Host Daemon交互，通过PC上的调试工具呈现给用户。JDWP Debugger、DDMS、ADB Host Daemon以及ADB Device Daemon之间的交互与其使用的协议，不在本文讨论范围之内。本文讨论的内容运行在Emulator/Device上，产生LOG信息，并通过程序LogCat输出。

LOG的实现架构

    Android中LOG的实现架构如下图所示，这基本上也是Android的某个模块实现各个层次的经典架构。

    Android应用程序通过Framework提供的机制操作；Java领域需要本地c/c++提供服务的地方，通过JNI实现；JNI调用底层库；库函数通过操作映射的设备文件操作设备，LINUX kernel中的Driver完成相应的操作。另外，抛开Java和JNI，LINUX上用户域的c/c++程序，也可以通过操作设备文件来完成。

    Android的LOG也是这样实现的，并将在本系列文章中分别讲述。应用程序通过android.util.Log里的各种静态方法，输出LOG信息[系列之二中具体讲述]；Log通过JNI接口调用c/c++的实现，而本地实现的写LOG，也基本就是写信息到设备文件[系列之三中具体讲述]；设备文件是Android为了LOG机制而写的LINUX的一个轻量级的驱动logger[系列之四中具体讲述]；LOG信息的显示可以是Emulator/Device上运行的LogCat程序[系列之五中具体讲述]；另外，Android的本地实现库也可利用现有机制，在c/c++的空间 直接输出LOG[系列之六中具体讲述]。