The principle of android Log
For android engineers, you may not need to know the details of the bottom jni part of Log. Use a picture to understand the implementation process:
< img alt="Android_Log" width="594" height="467" title="Android_Log" style="border: 0px currentcolor; border-image: none; display: inline; background-image: none;" src="/ wp-content/uploads/images/mobile/android/1626792384940.png" border="0" >
There are three processes involved here:
APP process: Call Log interface Log, and finally send it to Logd process through soctket communication
Logd process: There is a buffer for storing logs (ring buffer, when it is full, old logs will be flushed)
Logcat process: It can be created in adb shell (multiple can be created) to view the log process in the buffer (Android Studio logcat is also a Logcat process).
The ring buffer is a logical circular queue in which writers can write things, and once there is content, readers in the waiting queue will be notified to read Get the content, otherwise the waiting queue is blocked. This means that the Logcat process reading is also blocked.
Cache-based log scheme
For common applications: Implement a set of your own Log, Cache the log of each hit.
For system applications: Start a Logcat process in the application, continuously read the logs in the Logd process to the cache, and refresh the files after the quality reaches a certain threshold on the day . This kind of scheme can collect all application logs.
Disadvantages:
1. Writing files + encryption, there will be a CPU peak
2. The log in the cache may not be flushed to the file if it crashes or the process exits unexpectedly , Critical crash information may be lost.
For smart devices, a log process is dedicated to collect all application logs. This solution is actually simple and feasible.
Shared memory-based solution
mmp-based solution
Reference:
https://blog.csdn.net/tencent_bugly/article/details/53157830
http:/ /ju.outofmemory.cn/entry/224106