Ⅰ 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架构分析及日志系统初始化