Deep understanding of the story behind Android writing

Originally published in programmer magazine, the results were edited into a book review, with the content and depth greatly reduced. Today, I post the original article, hoping to attract others.

 

The exact time for my formal access to Android should be in August. During that time, I heard people in the company say that Donut, CupCake, Eclair and other very strange words (until now, I do not like the Android version name), and I can't help but admire it: there are so many things I have never heard. So I am very curious. Soon, I joined Android development. The first major module I came into contact with was Audio. When you look at the code, you will find more words that you don't understand, such as Binder, AudioFlinger, sp, and wp. At that time, I remember buying the "Android system principles and key points for development" by Han Chao. I tried my best to get into the door.

As my work went deeper, I found that my learning and understanding about Android had entered a very embarrassing situation. After careful analysis, I found that it is related to my work content. Most of my work is to maintain the existing Android system. To put it simply, it is to change the bug. After a large number of bugs have been changed, I have associated my understanding of Android with the Bug. For example, if I have an understanding of Audio, I can quickly talk about the relevant bugs and modifications. However, sadly, I cannot explain how the whole Audio works. Isn't that typical? This outcome is unacceptable to me (and to all software engineers. If there is a problem, you need to correct it (there are so many bugs changed). So I am determined to connect all the knowledge points to build a complete Android knowledge framework as soon as possible. With this mentality, let's look at Audio and find that it contains so rich content, it involves sp/wp, Binder, AudioTrack/AudioRecord, AudioFlinger, AudioPolicyService, and many other modules. (when I changed the bug, I saw bugs in my eyes and didn't pay attention to them at all ).

As a result, I started my research on Android. Obviously, the future is bright, but the road must be tortuous. The first twist is that the research work can only be carried out after work, so the idea is often interrupted by work. For example, when you see a logic, a task needs to be modified as soon as possible, and you have to stop the study. When I came back, I found that there was almost no information in my mind. To solve this problem, I adopted a method that everyone knows about interrupt processing. How can this problem be solved? I carefully divided the research process, recorded my thoughts and ideas for each small step, and summarized them at any time. When the research process is interrupted by work, you only need to look at the train of thought track before the interruption, you can quickly restore the site before the interruption, to maintain the continuity of thinking. The tool I used is Wiz cloud notes, and all the notes are synchronized to the cloud. Therefore, no matter at home, company, or even any place where Internet access is available, you can connect your thinking everywhere. Figure 1 shows the notes I recorded on Wiz over the past two years:

 

 

Figure 1 My Wiz notes

Figure 1 is part of my accumulated notes on Wiz. On the left side is the record of the 2.3 Framework. Basically every module has a note. On the right is the study notes for ActivityManagerService.

In addition, I have been pondering the research methods of various modules in Android. For the Native Framework layer, it mainly focuses on data flows, such as Audio and Surface systems. For such modules, you can use Source Insight to track the code several times. However, for Java Framework, the focus is on management and interaction rules. For example, ActivityManagerService has a large segment of code to process different startup modes of the Activity (such as SingleTop and SingleInstance. For this type of module, I used the Source insight and manmanxian method before. The result was no progress for two weeks. Because there are too many branches and the stack is too deep, the brain is hard to handle.

What should I do? Of course, it is best to debug relevant modules in person. Therefore, it took me a day to find the method to debug System_Process from the Internet. The results of a Google Forum turned to the bottom of the day to find a post, but it is indeed a link to the Android official web page on the http://source.android.com/source/using-eclipse.html (here there is a detailed debugging method. It seems that it is necessary to study the official webpage first ). After mastering the debugging method, I got into trouble again: At that time, Android 4.0 just came out, is it necessary to take the real machine for debugging? (I never thought it would be possible to debug it using a simulator ). There is only one HTC G7 at hand. I tried to compile an Android native system and set it to [1] (boot. image is flushed to CM7 and 2.3, while system. image is compiled by myself in the 4.0 system ). Due to the lack of relevant HAL library support, this system is barely able to run, in fact, it is also a simulator (when it reaches 4.1, I did not try again, directly go to the simulator debugging ). However, for Java Framework learning, this is enough. With Eclipse, a powerful debugging tool, the subsequent research work is really amazing, and the progress is very fast. Even so, it took nearly a month to study ActivityManagerService. I did not write until I felt that I was not lacking in the knowledge structure. Of course, writing a book is actually a reflection process, which will prompt me to look back at whether the previous conclusions are correct.

After understanding the two books of Android in depth, I am also thinking about a question. What kind of realm should the reader reach after reading these two books? I have two goals in my mind:

Q can view and analyze Android from the "Android-based and higher than Android" perspective. For the readers of volume I, they may be chip manufacturers and engineers from underlying manufacturers. For this part of readers, it is very likely to turn to other platforms in the future. Therefore, we must learn Android from a higher perspective, not limited to this platform.

Q can initially analyze large and complex code. For readers of Volume II, they are more likely to be Java programmers. Java has many excellent open-source frameworks, but most programmers will not study the details. For them, What they lack is the ability to analyze large and complex code (of course, if you can complete the book "Linux kernel Scenario Analysis", it is not in this category ). This capability is actually an internal skill. You need to be down-to-earth and drill down to cultivate it.

This is a deep understanding of the story behind Android writing. Readers are welcome to participate in the discussion. In addition, this set of books has a detailed development plan (http://blog.csdn.net/innost/article/details/7648869), please also actively participate.

[1] See author blog http://blog.csdn.net/innost/article/details/6977167