下圖是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()/…等方法同樣的輸出效果，只是在用它時，要指定對應的優先級。
