Ⅰ android進程間和線程間通信方式
進程：是具有一定獨立功能的程序關於某個數據集合上的一次運行活動，進程是系統進行資源分配和調度的一個獨立單位。
線程：是進程的一個實體,是CPU調度和分派的基本單位,它是比進程更小的能獨立運行的基本單位。線程自己基本上不擁有系統資源,只擁有一些在運行中必不可少的資源(如程序計數器,一組寄存器和棧)，但是它可與同屬一個進程的其他的線程共享進程所擁有的全部資源。
區別：
（1）、一個程序至少有一個進程，一個進程至少有一個線程；
（2）、線程的劃分尺度小於進程，使得多線程程序的並發性高；
（3）、進程在執行過程中擁有獨立的內存單元，而多個線程共享內存，但線程之間沒有單獨的地址空間，一個線程死掉就等於整個進程死掉。
---------------------
一、Android進程間通信方式
1.Bundle
由於Activity，Service，Receiver都是可以通過Intent來攜帶Bundle傳輸數據的，所以我們可以在一個進程中通過Intent將攜帶數據的Bundle發送到另一個進程的組件。
缺點：無法傳輸Bundle不支持的數據類型。
2.ContentProvider
ContentProvider是Android四大組件之一，以表格的方式來儲存數據，提供給外界，即Content Provider可以跨進程訪問其他應用程序中的數據。用法是繼承ContentProvider，實現onCreate,query,update,insert,delete和getType方法，onCreate是負責創建時做一些初始化的工作，增刪查改的方法就是對數據的查詢和修改，getType是返回一個String，表示Uri請求的類型。注冊完後就可以使用ContentResolver去請求指定的Uri。
3.文件
兩個進程可以到同一個文件去交換數據，我們不僅可以保存文本文件，還可以將對象持久化到文件，從另一個文件恢復。要注意的是，當並發讀/寫時可能會出現並發的問題。
4.Broadcast
Broadcast可以向android系統中所有應用程序發送廣播，而需要跨進程通訊的應用程序可以監聽這些廣播。
5.AIDL方式
Service和Content Provider類似，也可以訪問其他應用程序中的數據，Content Provider返回的是Cursor對象，而Service返回的是java對象，這種可以跨進程通訊的服務叫AIDL服務。
AIDL通過定義服務端暴露的介面，以提供給客戶端來調用，AIDL使伺服器可以並行處理，而Messenger封裝了AIDL之後只能串列運行，所以Messenger一般用作消息傳遞。
6.Messenger
Messenger是基於AIDL實現的，服務端（被動方）提供一個Service來處理客戶端（主動方）連接，維護一個Handler來創建Messenger，在onBind時返回Messenger的binder。
雙方用Messenger來發送數據，用Handler來處理數據。Messenger處理數據依靠Handler，所以是串列的，也就是說，Handler接到多個message時，就要排隊依次處理。
7.Socket
Socket方法是通過網路來進行數據交換，注意的是要在子線程請求，不然會堵塞主線程。客戶端和服務端建立連接之後即可不斷傳輸數據，比較適合實時的數據傳輸
二、Android線程間通信方式
一般說線程間通信主要是指主線程（也叫UI線程）和子線程之間的通信，主要有以下兩種方式：
1.AsyncTask機制
AsyncTask，非同步任務，也就是說在UI線程運行的時候，可以在後台的執行一些非同步的操作；AsyncTask可以很容易且正確地使用UI線程，AsyncTask允許進行後台操作，並在不顯示使用工作線程或Handler機制的情況下，將結果反饋給UI線程。但是AsyncTask只能用於短時間的操作（最多幾秒就應該結束的操作），如果需要長時間運行在後台，就不適合使用AsyncTask了，只能去使用Java提供的其他API來實現。
2.Handler機制
Handler，繼承自Object類，用來發送和處理Message對象或Runnable對象；Handler在創建時會與當前所在的線程的Looper對象相關聯(如果當前線程的Looper為空或不存在，則會拋出異常，此時需要在線程中主動調用Looper.prepare()來創建一個Looper對象)。使用Handler的主要作用就是在後面的過程中發送和處理Message對象和讓其他的線程完成某一個動作（如在工作線程中通過Handler對象發送一個Message對象，讓UI線程進行UI的更新，然後UI線程就會在MessageQueue中得到這個Message對象（取出Message對象是由其相關聯的Looper對象完成的），並作出相應的響應）。
三、Android兩個子線程之間通信
面試的過程中，有些面試官可能會問Android子線程之間的通信方式，由於絕大部分程序員主要關注的是Android主線程和子線程之間的通信，所以這個問題很容易讓人懵逼。
主線程和子線程之間的通信可以通過主線程中的handler把子線程中的message發給主線程中的looper，或者，主線程中的handler通過post向looper中發送一個runnable。但looper默認存在於main線程中，子線程中沒有Looper，該怎麼辦呢？其實原理很簡單，把looper綁定到子線程中，並且創建一個handler。在另一個線程中通過這個handler發送消息，就可以實現子線程之間的通信了。
子線程創建handler的兩種方式：
方式一：給子線程創建Looper對象：
new Thread(new Runnable() {
public void run() {
Looper.prepare(); // 給這個Thread創建Looper對象，一個Thead只有一個Looper對象
Handler handler = new Handler(){
@Override
public void handleMessage(Message msg) {
Toast.makeText(getApplicationContext(), "handleMessage", Toast.LENGTH_LONG).show();
}
};
handler.sendEmptyMessage(1);
Looper.loop(); // 不斷遍歷MessageQueue中是否有消息
};
}).start();
---------------------
方式二：獲取主線程的looper，或者說是UI線程的looper：
new Thread(new Runnable() {
public void run() {
Handler handler = new Handler(Looper.getMainLooper()){ // 區別在這！！！
@Override
public void handleMessage(Message msg) {
Toast.makeText(getApplicationContext(), "handleMessage", Toast.LENGTH_LONG).show();
}
};
handler.sendEmptyMessage(1);
};
}).start();
---------------------
Ⅱ Android可以讓主線程在其他子線程執行完後再執行嗎如果可以，該怎麼做
android中什麼時候會選擇用廣播來進行線程間的通信 Android 多線程 通信 線程中通信就不要用廣播了吧 進程中通信可以用廣播或者aidl 可是，這兩天看到的項目都是這么做的；然後，自己分析了下，覺得一下的理由也是可以成立的； 1.正常情況下我們選擇handler消息機制來進行單向的線程間的通信；（工作線程向主線程發送消息） 因為主線程有現成的handler，而工作線程沒有現成的handler，這樣的話，主線程將handler交給工作線程而讓工作線程將工作的結果交給主線程； 相反，工作線程中沒有現成的handler（事實上是沒有消息隊列，也就是handler沒有綁定到工作線程），那麼，如果開辟的話，代碼角度上是挺麻煩的（相對應廣播機制來說）； 2.廣播機制本身就是雙向的（工作線程向主線程發送廣播，主線程向工作線程發送廣播）； //另外，對於像一個activity中通過fragment來進行界面的處理； 我們大多數情況下是採用廣播的機制來實現fragment中adapter的數據的更新；這樣做主要是考慮到工作線程的任務載入完成，而具體的對應刷新的activity可能還沒有啟動； 另外，基於介面隔離原則，如果用handler進行通信的話，則不能很好的滿足這一原則； 你要是周期比較長 用廣播好些吧 應該與周期關系不是很密切。最主要的原因是兩條線成是雙向通信。 Handler類似於P2P的通信。 廣播則類似於一個server端，用來處理分發不同線程的請求，從控制器的角度來說用廣播更好一點。 一般使用Handler的，多用於子線程處理事務，完成時告知主線程這一類的情況。 而類似樓主所說的多條線程之間需要頻繁交互的話，廣播是個很好的選擇，並且結構清晰，只是不知道廣播的性能與handler相比會怎麼樣。
Ⅲ 怎樣實現2個app的點對點通訊
要用android實現點對點通信,可以使用socket完成,使用socket需要知道對方的IP地址以及埠號,這里我省略了伺服器端(編寫正規的通信軟體還是得需要伺服器做中轉,用伺服器得知A的IP地址,然後讓A做伺服器端,B用A的Ip地址去獲取數據),只是展示相關原理,首先看伺服器端
1 package polly.liu;
2
3 import java.io.BufferedReader;
4 import java.io.IOException;
5 import java.io.InputStreamReader;
6 import java.net.InetAddress;
7 import java.net.NetworkInterface;
8 import java.net.ServerSocket;
9 import java.net.Socket;
10 import java.net.SocketException;
11 import java.util.Enumeration;
12
13 import android.app.Activity;
14 import android.os.Bundle;
15 import android.os.Handler;
16 import android.util.Log;
17 import android.widget.TextView;
18
19 import java.io.BufferedReader;
20 import java.io.IOException;
21 import java.io.InputStreamReader;
22 import java.net.ServerSocket;
23 import java.net.Socket;
24 import android.app.Activity;
25 import android.os.Bundle;
26 import android.os.Handler;
27 import android.os.Message;
28 import android.widget.TextView;
29
30 public class ServerActivity extends Activity {
31 ServerSocket ss = null;
32 String mClientMsg = "";
33 Thread myCommsThread = null;
34 protected static final int MSG_ID = 0x1337;
35 public static final int SERVERPORT = 6000;
36
37 @Override
38 public void onCreate(Bundle savedInstanceState) {
39 super.onCreate(savedInstanceState);
40 setContentView(R.layout.main);
41 TextView tv = (TextView) findViewById(R.id.TextView01);
42 tv.setText("Nothing from client yet");
43 this.myCommsThread = new Thread(new CommsThread());
44 this.myCommsThread.start();
45 }
46
47 @Override
48 protected void onStop() {
49 super.onStop();
50 try {
51 // 確保你退出時要關閉socket連接
52 ss.close();
53 } catch (IOException e) {
54 e.printStackTrace();
55 }
56 }
57
58 Handler myUpdateHandler = new Handler() {
59 public void handleMessage(Message msg) {
60 switch (msg.what) {
61 case MSG_ID:
62 TextView tv = (TextView) findViewById(R.id.TextView01);
63 tv.setText(mClientMsg);
64 break;
65 default:
66 break;
67 }
68 super.handleMessage(msg);
69 }
70 };
71 class CommsThread implements Runnable {
72 public void run() {
73 Socket s = null;
74 try {
75 ss = new ServerSocket(SERVERPORT );
76 } catch (IOException e) {
77 e.printStackTrace();
78 }
79 while (!Thread.currentThread().isInterrupted()) {
80 Message m = new Message();
81 m.what = MSG_ID;
82 try {
83 if (s == null)
84 s = ss.accept();
85 BufferedReader input = new BufferedReader(new InputStreamReader(s.getInputStream()));
86 String st = null;
87 st = input.readLine();
88 mClientMsg = st;
89 myUpdateHandler.sendMessage(m);
90 } catch (IOException e) {
91 e.printStackTrace();
92 }
93 }
94 }
95 }
96 }
伺服器端和平時在PC上的代碼差不多,只不過現在把在PC上的代碼轉到了手機端,注意耗時間的操作要放在子線程上去做,再來看看客戶端代碼:
1 package polly.liu;
2
3 import java.io.BufferedWriter;
4 import java.io.IOException;
5 import java.io.OutputStreamWriter;
6 import java.io.PrintWriter;
7 import java.net.InetAddress;
8 import java.net.Socket;
9 import java.net.UnknownHostException;
10
11 import android.app.Activity;
12 import android.os.Bundle;
13 import android.util.Log;
14 import android.view.View.OnClickListener;
15 import android.widget.Button;
16 import android.widget.EditText;
17 import android.widget.TextView;
18 import android.view.View;
19
20 public class ClientActivity extends Activity {
21 private Button bt;
22 private TextView tv;
23 private Socket socket;
24 private String serverIpAddress = "192.168.1.104";
25
26 private static final int REDIRECTED_SERVERPORT = 6000;
27 @Override
28 public void onCreate(Bundle savedInstanceState) {
29 super.onCreate(savedInstanceState);
30 setContentView(R.layout.main);
31 bt = (Button) findViewById(R.id.myButton);
32 tv = (TextView) findViewById(R.id.myTextView);
33 try {
34 InetAddress serverAddr = InetAddress.getByName(serverIpAddress);
35 socket = new Socket(serverAddr, REDIRECTED_SERVERPORT);
36 } catch (UnknownHostException e1) {
37 e1.printStackTrace();
38 } catch (IOException e1) {
39 e1.printStackTrace();
40 }
41 bt.setOnClickListener(new OnClickListener() {
42 public void onClick(View v) {
43 try {
44 EditText et = (EditText) findViewById(R.id.EditText01);
45 String str = et.getText().toString();
46 PrintWriter out = new PrintWriter(new BufferedWriter(new OutputStreamWriter(socket.getOutputStream())),true);
47 out.println(str);
48 Log.d("Client", "Client sent message");
49 } catch (UnknownHostException e) {
50 tv.setText("Error1");
51 e.printStackTrace();
52 } catch (IOException e) {
53 tv.setText("Error2");
54 e.printStackTrace();
55 } catch (Exception e) {
56 tv.setText("Error3");
57 e.printStackTrace();
58 }
59 }
60 });
61 }
62 }
Ⅳ Android大廠面試經驗分享（OPPO，位元組，華為，阿里）
我是從小公司跳出來的，最終入職OPPO，說實話這段時間的經歷讓我深深地感受到，我們為跳槽做的一些臨時抱佛腳的提升跟那些大佬的沉澱比起來太渺小了。我們都知道找資料學習、刷面試題，但也許只能應付這一次的面試，後面還是會技術發愁，那些短時間背下來的東西遲早會忘掉， 大家還是做好長期提升自己的准備，好好沉澱的東西最後才是屬於自己的。
說說當時的面試過程，我是內推獲得的面試機會，很感謝當時幫我內推的兄弟，總共三輪面試，兩輪技術，一輪HR面，當天面試結束。
我10：10分到的公司，10：30開始面試，第一輪面試將近一個小時，聊的點我基本上都答得上來，自我感覺良好。然後面試官讓我等一下，他去叫他們老大來給我二面，我等了有二十幾分鍾吧，二面有一個多小時，這次問的比較深，有些地方答的有些嗑吧，總體來說我自己是滿意的。HR面約到下午了，整個流程下來每輪面試官都讓人感覺很不錯，我自己做的准備也讓我面試感覺下來很爽。
我把面試遇到過的以及自己學慣用到過相關內容都整理到一起了，方便自己進行復盤和後續的查漏補缺：
一、 Java基礎
1.1 靜態內部類和非靜態內部類的比較
1.2 多態的理解與應用
1.3 java方法的多態性理解
1.4 java中介面和繼承的區別
1.5 線程池的好處，詳解，單例（絕對好記）
1.6 線程池的優點及其原理
1.7 線程池的優點（重點）
1.8 為什麼不推薦通過Executors直接創建線程池
1.9 不怕難之BlockingQueue及其實現
1.10 深入理解ReentrantLock與Condition
1.11 Java多線程：線程間通信之Lock
1.12 Synchronized 關鍵字原理
1.13 ReentrantLock原理
1.14 HashMap中的Hash沖突解決和擴容機制
1.14 Java並發
1.15 Java虛擬機
1.16 JVM常見面試題
1.17 JVM內存結構
1.18 類載入機制/雙親委託
二、 Android基礎
2.1 Activity知識點(必問)
2.2 Fragment知識點
2.3 Service知識點
2.4 Intent知識點
2.5 數據存儲
三、UI控制項篇
3.1 屏幕適配
3.2 主要控制項優化
3.3 事件分發與嵌套滾動
3.4 動態化頁面構建方案
四、網路通信篇
4.1 網路協議
五、架構設計篇
5.1 MVP架構設計
5.2 組件化架構
六、性能優化篇
6.1 啟動優化
6.2 內存優化
6.3 繪制優化
6.4 安裝包優化
七、源碼流程篇
7.1 開源庫源碼分析
7.2 Glide源碼分析
7.3 day 20 面試題：Glide面試題
7.4 聊一聊關於Glide在面試中的那些事
7.5 面試官：簡歷上如果寫Glide，請注意以下幾點…
7.6 Glide OOM問題解決方法匯總
7.7 LeakCanary源碼分析
7.8 OkHttp源碼分析
7.9 okhttp連接池復用機制
7.10 okhttp 流程和優化的實現
7.11 一篇讓你受用的okhttp分析
7.12 OkHttp面試之–OkHttp的整個非同步請求流程
7.13 OkHttp面試之–HttpEngine中的sendRequest方法詳解
7.14 OkHttp解析大總結
7.15 Okhttp任務隊列工作原理
7.16 Android高頻面試專題 - 架構篇（二）okhttp面試必知必會
7.17 Android 網路優化，使用 HTTPDNS 優化 DNS，從原理到 OkHttp 集成
7.18 Retrofit源碼分析
7.19 RxJava源碼分析
7.20 RxJava原理與源碼分析
7.21 RxJava如何進行線程切換的？
7.22 Rxjava內存泄漏防止方案——RxLifecycle，AutoDispose，RxLife框架
7.23 Tinker源碼分析
7.24 ARouter源碼分析
7.25 Android框架層源碼解析
7.26 演算法設計
八、新技術篇
8.1 實戰問題篇
九、面試篇
9.1 開源文檔
9.2 面試文獻
以上就是我的學習和面試積累，有自己面試經歷過的，也有整理的一些大廠面試題，篇幅有限，具體內容就不展示了，我已經整理成文檔了。
還是開頭說的，僅靠面試期間臨時抱佛腳和刷題對自身發展不是長久之計，做好長期提升的規劃，好好沉澱每一次的學習和面試經歷，把這些最終都轉化成屬於自己的東西才是實質上對自己最有用的。
Ⅳ Android通信方式篇（七）-Binder機制（Native層（下））
本篇文章針對向ServiceManager注冊服務 和 獲取服務兩個流程來做總結。在這兩個過程中，ServiceManager都扮演的是服務端，與客戶端之間的通信也是通過Binder IPC。
在此之前先了解下Binder的進程與線程的關系：
用戶空間 :ProcessState描述一個進程，IPCThreadState對應一個進程中的一個線程。
內核空間 ：binder_proc描述一個進程，統一由binder_procs全局鏈表保存，binder_thread對應進程的一個線程。
ProcessState與binder_proc是一一對應的。
Binder線程池 ：每個Server進程在啟動時會創建一個binder線程池，並向其中注冊一個Binder線程；之後Server進程也可以向binder線程池注冊新的線程，或者Binder驅動在探測到沒有空閑binder線程時會主動向Server進程注冊新的的binder線程。對於一個Server進程有一個最大Binder線程數限制15，(#define DEFAULT_MAX_BINDER_THREADS 15)。對於所有Client端進程的binder請求都是交由Server端進程的binder線程來處理的。我的理解是：binder線程是進程進行binder ipc時的一條數據處理路徑。
MediaPlayerService向ServiceManager注冊過程如下：
相關類：
整個過程總結如下：
1 獲取BpServiceManager 與 BpBinder
由defaultServiceManager()返回的是BpServiceManager，同時會創建ProcessState對象和BpBinder對象。然後通過BpBinder執行transact，把真正工作交給IPCThreadState來處理。
2 BpBinder transact
Binder代理類調用transact()方法，真正工作還是交給IPCThreadState來進行transact工作。
3 通過IPCThreadState 包裝並轉換數據並進行transact事務處理
每個線程都有一個IPCThreadState，每個IPCThreadState中都有一對Parcel變數：mIn、mOut。相當於兩根數據管道：
最後執行talkWithDriver。
writeTransactionData：將BC Protocol + binder_transaction_data結構體 寫入mOut， 然後執行waitForResponse：
由talkWithDriver將數據進一步封裝到binder_write_read結構體，通過ioctl（BINDER_WRITE_READ）與驅動通信。同時等待驅動返回的接收BR命令，從mIn取出返回的數據。
mIn包裝的數據結構(注冊服務handle = 0 ，code 為ADD_SERVICE_TRANSACTION)：
4 Binder Driver
把binder_write_read結構體write_buffer里數據取出來，分別得到BC命令和封裝好數據的事務binder_transaction_data, 然後根據handler，在當前binder_proc中，找到相應的binder_ref，由binder_ref再找到目標binder_node實體，由目標binder_node再找到目標進程binder_proc。然後就是插入數據：當binder驅動可以找到合適的線程，就會把binder_transaction節點插入到servciemanager的線程的todo隊列中，如果找不到合適的線程，就把節點之間插入servciemanager的binder_proc的todo隊列。
5 ServiceManager
經過Binder Driver的處理，數據已經到了ServiceManager進程，在BR_TRANSACTION的引導下，在binder_loop（）中執行binder_parser（）取出數據，執行do_add_service（）操作，最終向 svcinfo 列表中添加已經注冊的服務（沒有數據的返回）。最後發送 BR_REPLY 命令喚醒等待的線程，通知注冊成功。結束MediaPlayerService進程 waitForResponse()的狀態，整個注冊過程結束。
獲取服務的過程與注冊類似，首先 ServiceManager 向 Binder 驅動發送 BC_TRANSACTION 命令攜帶 CHECK_SERVICE_TRANSACTION 命令，同時獲取服務的線程進入等待狀態 waitForResponse()。Binder 驅動收到請求命令向 ServiceManager 的發送 BC_TRANSACTION 查詢已注冊的服務，會區分請求服務所屬進程情況。
查詢到直接響應 BR_REPLY 喚醒等待的線程。若查詢不到將與 binder_procs 鏈表中的服務進行一次通訊再響應。
以startService為例來簡單總結下執行流程：
3.1 從方法執行流程來看：
Client ：
1 AMP.startService 標記方法以及通過Parcel包裝數據；
2 BinderProxy.transact 實際調用native的 android_os_BinderProxy_transact 傳遞數據；
3 獲取BpServiceManager 與 BpBinder 同時會創建ProcessState。然後通過BpBinder執行transact，把真正工作交給IPCThreadState來處理；
4 IPC.transact 主要執行writeTransactionData，將上層傳來的數據重新包裝成binder_transaction_data，並將BC Protocol + binder_transaction_data結構體 寫入mOut；
5 IPC waitForResponse talkWithDriver + 等待返回數據；
6 talkWithDriver 將數據進一步封裝成binder_write_read，通過ioctl（BINDER_WRITE_READ）與驅動通信；
Kernel :
7 binder ioctl 接收BINDER_WRITE_READ ioctl命令；
8 binder_ioctl_write_read 把用戶空間數據ubuf拷貝到內核空間bwr；
9 binder_thread_write 當bwr寫緩存有數據，則執行binder_thread_write；當寫失敗則將bwr數據寫回用戶空間並退出；
10 binder_transaction 找到目標進程binder_proc並插入數據到目標進程的線程todo隊列，最終執行到它
時，將發起端數據拷貝到接收端進程的buffer結構體；
11 binder_thread_read 根據binder_transaction結構體和binder_buffer結構體數據生成新的binder_transaction_data結構體，寫入bwr的read_buffer，當bwr讀緩存有數據，則執行binder_thread_read；當讀失敗則再將bwr數據寫回用戶空間並退出；最後，把內核數據bwr拷貝到用戶空間ubuf。
12 binder_thread_write + binder_ioctl BR命令和數據傳遞
Server:
13 IPC.executeCommand 解析kernel傳過來的binder_transaction_data數據，找到目標BBinder並調用其transact()方法;
14 IPC.joinThreadPool 採用循環不斷地執行getAndExecuteCommand()方法, 處理事務。當bwr的讀寫buffer都沒有數據時,則阻塞在binder_thread_read的wait_event過程. 另外,正常情況下binder線程一旦創建則不會退出.
15 BBinder.transact 到Binder.exeTransact 調用 AMN.onTransact
16 AMN.onTransact 把數據傳遞到AMS.starService去執行
17 AMS.starService Server處理了Client的請求了
然後原路replay回去，talkWithDriver 到Kernel ，然後找到Client進程，把數據拷貝到read_buffer里，最終喚醒IPC，把反饋傳遞回AMP.startService。完成啟動服務。
3.2 從通信協議流程來看：
非oneWay:
oneway:
oneway與非oneway區別: 都是需要等待Binder Driver的回應消息BR_TRANSACTION_COMPLETE. 主要區別在於oneway的通信收到BR_TRANSACTION_COMPLETE則返回,而不會再等待BR_REPLY消息的到來. 另外，oneway的binder IPC則接收端無法獲取對方的pid.
3.3 從數據流來看
從用戶空間開始：
進入驅動後：
回到用戶空間：
參考：
http://gityuan.com/2016/09/04/binder-start-service/
http://gityuan.com/2015/11/28/binder-summary/
http://gityuan.com/2015/11/14/binder-add-service/
http://gityuan.com/2015/11/15/binder-get-service/
Ⅵ Android 日誌系統分析(二)：logd
logd 守護進程是日誌系統的管家，內部維持三個日誌 Socket : logd、logdr、logdw 來與客戶端進行通信。同時負責維護幾個環形緩沖區，用於存放系統中的各種日誌，緩沖區包含 main、system、events、radio、crash、kernel ；但是在 Android 5.0 之前， logd 進程並不存在，日誌是保留在 /dev/log/main、/dev/log/system、/dev/log/radio、/dev/log/event 等節點中，但是這樣面臨的一個問題就是當 Android 系統大版本升級時， linux kernel 需要升級對應的日誌驅動，因此在後續的版本中就有了 logd 進程。
在 Android 日誌系統分析(一)：概述 一文中，總結了整個日誌讀寫的主要流程，因此對於 logd 進程是如何同外界溝通進而讀寫日誌的過程不再贅述，而著重於 logd 本身的一些知識點，這里先看一下 logd 的系統框圖：
知識點：
① logd 是日誌系統的核心進程，由 init 啟動，是屬於守護進程常駐後台
② logd 維護各個日誌節點緩存隊列，提供 socket 介面進行讀、寫、控制功能
③ logd 進程啟動後，分別啟動 LogReader、LogListener、CommandListener 三個線程，監聽並處理來自三個 socket 的消息。在收到消息後，會通過 LogBuffer 類保存日誌到對應的 RAM buffer 中
④ LogAudit 模塊用於接收 Kernel selinux 信息，即可以在用戶空間列印 selinux 日誌信息
⑤ LogKlog 用於接收 kernel 日誌信息，通過設置 property ，可以通過 logcat 命令讀取內核日誌
⑥ LogStatistics 是日誌統計模塊，默認開啟統計數據較少，僅能以 pid/uid 緯度統計列印日誌的數量。如果設置了 logd.statistic = true 。會列印更多緯度的統計信息，包括哪些 pid/uid/tid/TAG 日誌量比較大，可用於日誌裁剪相關
在 main 函數中，會打開 /dev/kmsg 來讀取內核日誌，通過 LogKlog 來進行存儲；若是配置了 ro.logd.kernel 屬性，則打開 /proc/kmsg 讀取內核日誌；
logd 作為 Native Service ，系統啟動時會讀取 init.rc 腳本去啟動，它的相關屬性被定義在 logd.rc 文件中：
這里主要分為兩部分： 啟動 logd 服務 和 啟動 logd-reinit 服務 （在Android 10 上添加了 logd-auditctl 服務，目的是為了限制 selinux denia列印日誌為5秒一次）；先來看一下 啟動 logd 服務 的同時做了些什麼：
① 創建 logd、logdr、logdw 這三個 socket 為後面的通信做准備
② logdw 定義為 dgram 類型的 socket ，類似與 UDP類型的 Socket ，這么做的原因是考慮到性能問題，在多個進程同時寫日誌的情況下， write 函數寫入到 socket 的 buffer 中即可返回，這樣不會 block 業務邏輯太長時間。如果是 TCP 類型的 Socket ，客戶端需要等到 TCP 收到 ACK 響應才能返回，這樣就會過多的消耗性能和資源；
啟動 logd-reinit 服務：
這個服務的主要作用是重新初始化 logd 的 LogBuffer，在配置中 oneshot 表示開機只啟動一次。在上面的 main.cpp 中的 main 函數內， logd 在啟動後，會創建一個線程 reinit_thread_start () ，當 logd-reinit 傳入參數 reinit 後，進行功能執行:
① 如果 reinit 啟動後，並且 /deg/kmsg 打開成功，把 logd.daemon: renit 寫入 kmsg
② 重新初始化各個 log buffer 的大小，以及其他參數的初始化，但不會重新生成 LogBuffer 對象
main.cpp##main
main.cpp#reinit_thread_start()
[ 1 ] 深入理解安卓日誌系統（logcat / liblog / logd）
[ 2 ] Android10.0 日誌系統分析(二)-logd、logcat架構分析及日誌系統初始化