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。
LOG输出帮助类
Android的Java程序通过android.util.Log类来输出Log，下图列出了我们常用的Log的静态方法。
一般，要输出Log信息，可直接调用Log.v()/Log.d()/Log.i()/Log.w()/Log.e()等类方法。这里之所以有这么多有区分的方法，这也是Log的分类。Log的分类就如同Log的静态常量成员定义的那样，而Log的优先级按照数字大小排列，数字大的优先级高。而Log.wtf()记录的则是非常致命的FAULT信息（What a Terrible Failure），报这个错误，不光是在Log里记录，还要在界面上有提示，并可能杀死当前的进程。
有了这些分类，如果要输出的LOG优先级低于当前设置的优先级，则该Log信息不会显示。一般的，在Java程序中用Log的方法打印Log之前，应先用isLoggable()判断一下，该级别是否能被记录。
另外，用Log.println()能达到与Log.v()/Log.d()/…等方法同样的输出效果，只是在用它时，要指定对应的优先级。