从 Android 入行开始，因为工作需求和解决疑难bug的原因陆陆续续的看过一些源码，但都不成系统，从2016年年底开始，在Github上建了一个Android Open Source Project Analysis，专门针对 Android 7.0 源码进行系统的分析，这是一个从实践角度去分析源码的项目，目前项目一期已经完成。
更好的阅读体验？
代码版本
细分版本：N6F26U
分支：android-7.1.1_r28
版本：Nougat
支持设备：Nexus 6
分析思路
Android是一个庞大的系统，Android Framework只是对系统的一个封装，里面还牵扯到JNI、C++、Java虚拟机、Linux系统内核、指令集等。面对如此庞大的系统，我们得有一定的 章法去阅读源码，否则就会只见树木不见森林，陷入卷帙浩繁的细节与琐碎之中。
不要去记录那些API调用链，绘制一个序列图理清思路即可，Android Framework中有很多复杂的API调用链，你去关注这些东西，用处不大。你需要学会的是跟踪调用链和梳理流程的 技巧，思考一下作者是怎么找到关键入口的，核心的实现在什么地方。
要善于思考，要多问为什么，面对一个模块，你要去思考这个模块解决了什么问题，这个问题的本质是什么，为什么这么解决，如果让我来写，我会怎么设计。事实上不管是是计算机还是 手机，从CPU、到内存、到操作系统、到应用层，看似纷繁复杂，但问题的本质无非就是这么几种：时间片怎么分配？线程/进程怎么调度？通信的机制是什么？只是在不同的场景下加了具体 的优化，但问题的本质没有改变，我们要善于抓住本质。
要善于去粗存精，Android Framework也是人写的，有精华也有糟粕，并不是每行代码你都需要问个为什么，很多时候没有那么多为什么，只是当时那种情况下就那样设计了。但是 对于关键函数我们要去深究它的实现细节。
写作风格
和大家一样，笔者也是在前人的书籍和博客的基础上开始学习Android的底层实现的，站在前人的肩膀上会看的更远。但是这些书籍和博客有个问题在于，文章中罗列了大量的代码，这样 很容易把初学者带入到琐碎的细节之中，所以本系列文章在行文中更多的会以图文并茂和提纲总结的方式来分析问题，关键的地方才会去解析源码，力求让大家从宏观上理解Android的底 层实现。另外，基本上一个主题对应一篇文章，所以文章会比较长，但是文章会有详细的标题划分和提纲总结，可以有的放矢，阅读自己需要的内容。
好了，让我们开始我们的寻宝之旅吧~
Android系统架构图
Android系统架构图
从上到下依次分为六层：
应用框架层
进程通信层
系统服务层
Android运行时层
硬件抽象层
Linux内核层
在正式阅读本系列文章之前，请先阅读导读相关内容，这会帮助你更加快捷的理解文章内容。
Android系统应用框架篇
Android窗口管理框架
Android组件管理框架
Android包管理框架
Android资源管理框架
Android系统底层框架篇
Android进程框架
Android内存框架
Android虚拟机框架
Android应用开发实践篇
Android界面开发
Android应用优化
其他
Android系统软件设计篇
有兴趣参与此项目的小伙伴可以扫码入群，本群主要讨论Android Framework、主流开源框架以及Android工程化相关技术，本群不是一个读者群，希望大家每个人都能成为项目的参与者。如果微信群提示满额了可以加我微信 allenwells 邀请入群。
后续的技术文章和资料也会做成PDF发送给读者，为了方便群文件管理，这里也建立了一个QQ群。
关于此项目后续的计划
一个人的力量是有限的，后续此项目会做成一个团体项目，在Github建立新的工作组和新的Repo，设计新的名字和Logo，每篇文章会在文章头部注明作者的名字和Github账号。希望有更多的小伙伴参与进来，不仅仅是学习源码原理，也可以提升自己的技术品牌。
后续的文章内容会按照难易程度进行分级，大家可以按照自己擅长的部分进行认领，还会定义文档规范、PR规范与参与方式等，会先出一个草案供大家讨论，这是个比较细致的事情，刚来公司事情比较多，等忙完这一段再着手去做。
大家有空也可以考虑一下自己擅长什么以及想要做哪一块的内容。以及项目运作的一些核心问题：① 如何保护作者的知识产权，署名？核心贡献者？② 项目的名字和Logo ③ 文档规范、绘图规范、PR规范。④ 项目的具体内容和目录。⑤ 参与方式，希望参与内容的可以成为作者，进行实际的内容创作。希望成为读者的可以参与校对，校对人的名字也会被写在文章头上，校对的任务是纠错，包括：错别字、错误排版、错误拼写以及可能有偏差的内容。
文章的最后再聊一聊工作这几年来的感悟，其实我一向是比较少的去聊这些事情，因为觉得这些东西讲多了，有点夸夸其谈的感觉，但是这几年工作下来，有几点东西确实是感触颇深的，这里 简单总结一下。
客户第一 - 人与人之间的关系
这个挺起来好像有点官僚风的味道，但这里要说的不是我们产品的客户，而是说我们自己的客户，有没有想过这个问题，我们自己的客户是谁？一般说来，我们向哪些人提供服务，哪些人 就是我们的客户，比如我任职于公司的平台架构部，我们向业务研发团队、产品团队，运营团队和测试团队输出产品和工具，所以他们都是我的客户，除了你提供服务的那些人外，你的leader 也是你的客户，他会给你布置任务，你去完成他的任务。
那么什么是客户第一呢？
比方说你的leader在给你布置任务的时候，他会根据他心目中你的能力大小来制定对任务完成结果的预期，他觉得以你的能力可以把一个10分的事情做到6分。然后他就会以六分为标准来安排任务，当你最终 完成了这些任务后，他并不会进一步的认可你的能力，因为你做的事情都在他的预期之内。所谓客户第一，就是你需要向办法找到leader以及其他团队对这个事情10分的预期是什么，然后按照这个标准去完成 任务，也就是说要高于客户的预期去完成需求，不单单是满足需求，而是去帮助我们的客户解决更多的问题。
团队合作 - 人与团队之间的关系
团队合作也是个老生常谈的问题，但是吧这一点做好并不简单，尤其是公司越来越大，团队越来越多的时候，沟通成本就变得十分巨大。团队合作主要解决三个方面的问题：我如何和我所在 的团队进行合作？我所在的团队如何和其他团队合作？我所带领的团队如何和其他团队合作？那所有的退队集合在一起，往一个方向去做事
拥抱变化 - 人与产品之间的关系
拥抱变化对产品而言的，我们所写的程序最终会变成一个产品，去解决某个商业场景下的问题，所以对于我们来说，公司的需求也绝不是只是让我们把程序写好，只是把程序写好是不够的，我们还需要设身 处地的去考虑客户在使用我们的产品的时候会遇到哪些问题，如果去优化解决这些问题。也就是说需求是多变的，我们要设计出能应对复杂需求的产品，拥抱变化的需求。
以上就是想分享的三点，部分内容也都是老生常谈的问题，但很多事情就是这样，万变不离其宗，做人做事的正确方法始终都是不变的。
作者：郭孝星
链接：https://juejin.im/post/5a936c5a6fb9a0633229ca74