相信大家在找工作的时候，肯定或多或少都被面试官问到过安卓的八股文。比如ActivityManagerService(简称AMS)，或者WindowManagerService(WMS) 怎么实现的啊，有些什么细节需要注意啊，View被加入到ViewRoot的流程啊等等。每每看到这些文章，教人怎么准备安卓framework面试，我都觉得很痛心。。。
因为在我看来，对于应用开发来说，面试考这些纯粹就是扯淡，很有可能面试官自己也只是在网上看看文章，然后照本宣科的再去问面试者。这种现象其实说白了就是卷。因为面试的内容已经在app层挖掘完了，再想提高面试门槛就只能往深了挖。
安卓的系统framework的代码就成了最好的替罪羔羊，因为framework的内容足够多。多到什么程度呢，你下载一套新的AOSP代码可能都要一个小时，全量编译就更不用说了，我自己每次开新的Repo都非常开心，因为我可以心安理得的边看视频边等代码下载了。所以在代码量如此庞大的情况下，面试官想出什么问题都可以，只要你面试者有时间，我总可以问倒你。
但是这些代码都是好代码么？或者说安卓framework里面的所有代码都值得面试者学习么?
答案是NO。这也是一个非常明显的答案。
安卓的framework经过快十二年的迭代，很多地方其实是又臭又长。比如臭名昭著的View class:
https://android.googlesource.com/platform/frameworks/base/+/a175a5b/core/java/android/view/View.java#15354
已经演变成一个一万五千行的类了。。。。。
很多地方不是不想优化，而是没人敢动，搞出问题了咋办，你负责？
一不小心扯远了。。。回到面试的问题。
那么对于有些面试官考到的八股文。那些考点，或者考点指向的代码同样也不是圣经。他们很有可能只是谷歌的安卓团队在当初定义的一些规则而已，在谷歌里面做安卓framework，或者说有权限能改安卓framework代码的人数不胜数，难道每个人都是天才，可以一点错误都不犯？显然不可能。
那难道看framework源码就一文不值了？那也肯定不是，前提是我们在看源代码的时候能够做到取其精华去其糟粕。
有的读者肯定会说我站着说话不腰疼，话都可以说的好听，具体怎么操作，我怎么知道什么是精华什么是糟粕？
在说具体怎么操作之前，我想先举个反例
源码分析？
很多初学者一上来就雄心壮志，觉得要全面学习安卓系统，起头就开始读源码，或者看源码分析:
这样做的后果往往就是在起跑线就被劝退了。 原因很简单，当你连framework某个类具体是干什么都不知道的情况下，就去读源代码，你是不会有动力的。这和很多学生刚刚毕业，代码还没写多少行就想开始看开源项目，学习源代码一样，基本上可以说没有意义。
很多尝试阅读安卓源代码的朋友，甚至连刷写设备都没试过，这怎么可能可以学到framework的精华呢。说白了，想不动手操作就学习源码，也是一种偷懒的行为，以为自己学习很努力，其实都在做无用功。
刷机！
学习源码的第一步，其实是刷设备。跟着官方教程，从第一步下载AOSP源代码开始:
1 . https://source.android.com/setup/develop
再到用AOSP源代码build操作系统
- https://source.android.com/setup/build
最后把build好的系统image刷到手机上:
3.https://source.android.com/setup/build/running
学代码？先修bug
最后，就是动手操作了。
落实到具体的操作就是，修bug！！！
没错，学习任何庞大的框架，一个人都没办法从面到点的学习，都是从点到面，从下到上。因为你不可能一开始就对全局都有认识。
所以修bug就成了一个最好的切入点。 安卓的AOSP有数不尽的bug，每天都会有一大堆进入到bug tracker里面。Framework的bug tracker:
https://issuetracker.google.com/issues?q=componentid:192705%2B
大到系统fatal error，小到注释没加，都在里面。大家不要觉得参与进去很难，我随手一看，就找到一个简直不能再弱智的bug:
https://issuetracker.google.com/issues/196574813
同样的，这个解决它的code review，就一行改动:
https://android-review.googlesource.com/c/platform/frameworks/base/+/1799607
是不是顿时觉得自己也能参与到安卓的开源行动里面了？
只要有毅力，哪怕是自己解决不了，你都可以跟踪一个你感兴趣的bug，看看别人是怎么解决的，看看别人是怎么复现这个bug的，对自己也是有很大帮助的。至少，这样的方式会比自己苦读源码要强。源码分析不是不可以看，而是要用对的方式去看，比如把源码分析的博文当成一个字典，有遇到相关的bug的时候翻一番。
接下来的篇章
在今后的更新里，我会把自己解决过，而且觉得有学习价值的bug写下来，或者以小作业的形式要求大家对某些代码进行改动让大家可以在写代码，编译，刷机，验证在这个动手的过程中学习。在WearOS团队工作大半年的感触，就是对framework有了更多的了解，同时也向很多安卓framework早期的开发者学习了不少。
(比如谷歌很多在公司待了10年以上的老鸟，其中有一位大神叫dianne hackborn ，这位程序员可以说是安卓系统的殿堂级人物，谷歌里面都有段子说，在安卓组里面的一个成就是在内部技术论坛发问题是否有得到过Dianne的回复，本人发过的两个安卓问题都得到了Dianne大神的临幸 0.0)
最后的最后！我也不是说让大家以后面试都不准备了，而是提供另外一个平时可以学习的思路，两手抓难道不是更稳 :)