I remember when I first started working, looking at the source code of ART or Binder was like reading a book in the sky, with no clue at all.Binder is a little better, there are many related blogs and books that can be referred to. Binder is a bit better, there are many related blogs and books to refer to, while ART is completely dark, because there is no book on the market to introduce ART, only from the JVM knowledge system to find some reference.
Zeng Guofan once summarized his military strategy with six words: “build a hard fortress, fight a dull battle”, and these six words are also applicable to source code learning. When there is a lack of external reference to a piece of knowledge, reading the source code over and over again may be the best way. This reminds me of a chat with a Xiaomi predecessor, he said that he set up his own technical signboard in the early days of his career by virtue of a move: at that time engaged in the work will often encounter complex underlying problems, and the debugging of these problems rely heavily on the use of GDB, so he read the thick GDB official manual from cover to cover many times, and know it by heart, and then in the debugging of complex problems, shine, known as the “GDB”, the “GDB”, the “GDB”, the “GDB”, the “GDB”, and so on. He is well known for this. I deeply agree with this point of view, because in this road of learning, not taking shortcuts is the best shortcut.
In my opinion, learning source code is a long and arduous process. As time goes by, methods and perceptions change. Here are my perceptions at three different stages of learning source code.
The first realm: see the mountain as a mountain.
“Seeing is believing” emphasizes the process of understanding the details of knowledge, the process of “knowing”. Typical of this stage is the tendency to post large portions of source code when writing blogs, such as my early blogs. This is like a tour guide leading you to a beautiful palace, introducing every detail inside, letting you know that a pillar is a pillar and a window is a window.
The process of moving from “not knowing” to “knowing” is therefore intensely rewarding, but also limiting. We can take the source code and argue with others: look, the code is designed this way. But if someone asks us: why was it designed this way? We will most likely be dumbfounded.
The second realm: the mountain is not a mountain when you look at it.
“Seeing the mountain is not a mountain” has a two-dimensional meaning. One is to look beyond the details and think in a macro dimension about the relevance of each place and why it was designed that way; the other is to look at the source code with a historical perspective and understand the process of how it changed, rather than being singularly and isolatedly confined to a particular version. It emphasizes understanding the designer’s intent, as well as breaking through authority and thinking about the mistakes the designer may have made. This stage is the process of “getting to know what’s going on”. Since a few years ago, I’ve made a conscious effort to reduce the amount of source code I post in my blogs, and instead develop descriptions in the form of block diagrams. This will force me to summarize the knowledge in a structured way, and try to tell it in a clear and concise language. At this stage, we will slowly feel that many of the design patterns of the code are actually born out of real life, and the importance of algorithms in it.
Two tips are mentioned here that can help us understand the reason behind the design faster. One is to use cs.android.com to find the specific change introduced by a particular mechanism through git blame and git history. Then, on android-review.googlesource.com, you can find the commit message and specific discussion of the change when it was committed, which helps us understand the designer’s original intent. Secondly, git history allows us to see the committer’s email address, so if we have further questions, we can contact the original author directly by email without having to guess the designer’s intent there.
The third realm: it is better to look at the mountain than to go up it.
Marx once said: philosophers just explain the world in different ways, and the problem is to change the world. For source code learning, the best way must be to learn by doing, which is my epiphany only in the past year. Understanding and learning is actually a passive process that lacks a practical testing mechanism; and when we take the initiative to write some new code and a new framework, if the knowledge is not understood properly, the code will run with problems, so such a feedback mechanism can help us understand the knowledge correctly and deeply.
Two examples.
One was a JNI optimization I contributed to the main ART thread a while back, and there were over twenty issues I ran into during development. Some of the problems were reported out of their own despair, because according to the understanding of the source code at the time that it could not happen, and Google from the limited error logs can not see the problem. Hard-headed step by step to debugging, comparison, reading the source code, and finally realized that in fact, their understanding is not comprehensive enough, ignoring certain situations to consider. Practice like this process will often fall into the helpless emotion, but I generally advise themselves: today can not be solved, that is not clear tomorrow will figure it out. Miraculously, such mental suggestion often has good results.
The other is the ART Java Hook program I’ve been messing around with lately. About ART Java Hook, I have paid attention to a few years ago, but only limited to some blog reading, understanding is very superficial. Recently, the reason why I started to write a set, one is because I am interested in it, and the other is because some friends said they have such a claim, and the ART Java Hooks on the market are not stable enough. In the process of writing, I focused on referencing the source code of epic and pine, and also carefully studied the principle articles of SandHook, FastHook, and YAHFA. On their basis, overlaid with my understanding of ART, a lot of new ideas and thoughts came out. Some of these ideas are hazy, and in order to verify whether they are feasible or not, I need to go back and study some specific details in the ART source code, as well as the possible impact of optimizations in ART on the Hook scheme. In short, it may not be difficult to write a usable scheme, but it is more difficult to write a well-considered scheme with high stability and compatibility. The latter requires a detailed understanding of many mechanisms within ART, not just a general concept. This process is actually forcing myself to deepen my understanding of the source code.
There are so many materials on the Internet today that most people are used to start with books, blogs, and videos when learning something new, but I strongly recommend that you also check out the source code. From the source code of these excellent open source projects, we can learn excellent frameworks, superb algorithms and beautiful writing style. As Confucius said, we can learn from these excellent projects over a long period of time, and I believe it will be very beneficial for us to improve our own capabilities.
