Android 7.0 源码分析项目一期竣工啦

时间 2019-11-05

原文原文链接

从Android入行开始，由于工做需求和解决疑难bug的缘由陆陆续续的看过一些源码，但都不成系统，从2016年年末开始，在Github上建了一个Android Open Source Project Analysis，专门针对 Android 7.0 源码进行系统的分析，这是一个从实践角度去分析源码的项目，目前项目一期已经完成。android

更好的阅读体验？👇git

点击进入GitBook阅读

第一次阅览本系列文章，请参见导读，更多文章请参见文章目录。github

代码版本编程

细分版本：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资源管理框架

01Android资源管理框架：资源管理器AssetManager

Android系统底层框架篇

Android进程框架

Android内存框架

Android虚拟机框架

01Android虚拟机框架：Java类加载机制

Android应用开发实践篇

Android界面开发

Android应用开发

Android媒体开发

其余

Android系统软件设计篇

欢迎关注咱们的微信公众号，新文章会第一时间发布到掘金博客与微信公众平台，咱们也有本身的交流群，下方是QQ交流群，微信群已满，能够加我微信 allenwells 邀请入群。

微信公众平台

QQ交流群

关于此项目后续的计划

一我的的力量是有限的，后续此项目会作成一个团体项目，在Github创建新的工做组和新的Repo，设计新的名字和Logo，每篇文章会在文章头部注明做者的名字和Github帐号。但愿有更多的小伙伴参与进来，不只仅是学习源码原理，也能够提高本身的技术品牌。

后续的文章内容会按照难易程度进行分级，你们能够按照本身擅长的部分进行认领，还会定义文档规范、PR规范与参与方式等，会先出一个草案供你们讨论，这是个比较细致的事情，刚来公司事情比较多，等忙完这一段再着手去作。

你们有空也能够考虑一下本身擅长什么以及想要作哪一块的内容。以及项目运做的一些核心问题：① 如何保护做者的知识产权，署名？核心贡献者？② 项目的名字和Logo ③ 文档规范、绘图规范、PR规范。④ 项目的具体内容和目录。⑤ 参与方式，但愿参与内容的能够成为做者，进行实际的内容创做。但愿成为读者的能够参与校对，校对人的名字也会被写在文章头上，校对的任务是纠错，包括：错别字、错误排版、错误拼写以及可能有误差的内容。

文章的最后再聊一聊工做这几年来的感悟，其实我一贯是比较少的去聊这些事情，由于以为这些东西讲多了，有点夸夸其谈的感受，可是这几年工做下来，有几点东西确实是感触颇深的，这里简单总结一下。

客户第一 - 人与人之间的关系

这个挺起来好像有点官僚风的味道，但这里要说的不是咱们产品的客户，而是说咱们本身的客户，有没有想过这个问题，咱们本身的客户是谁？通常说来，咱们向哪些人提供服务，哪些人就是咱们的客户，好比我任职于公司的平台架构部，咱们向业务研发团队、产品团队，运营团队和测试团队输出产品和工具，因此他们都是个人客户，除了你提供服务的那些人外，你的leader 也是你的客户，他会给你布置任务，你去完成他的任务。

那么什么是客户第一呢？

比方说你的leader在给你布置任务的时候，他会根据他心目中你的能力大小来制定对任务完成结果的预期，他以为以你的能力能够把一个10分的事情作到6分。而后他就会以六分为标准来安排任务，当你最终完成了这些任务后，他并不会进一步的承认你的能力，由于你作的事情都在他的预期以内。所谓客户第一，就是你须要向办法找到leader以及其余团队对这个事情10分的预期是什么，而后按照这个标准去完成任务，也就是说要高于客户的预期去完成需求，不仅仅是知足需求，而是去帮助咱们的客户解决更多的问题。

团队合做 - 人与团队之间的关系

团队合做也是个老生常谈的问题，可是吧这一点作好并不简单，尤为是公司愈来愈大，团队愈来愈多的时候，沟通成本就变得十分巨大。团队合做主要解决三个方面的问题：我如何和我所在的团队进行合做？我所在的团队如何和其余团队合做？我所带领的团队如何和其余团队合做？那全部的退队集合在一块儿，往一个方向去作事

拥抱变化 - 人与产品之间的关系

拥抱变化对产品而言的，咱们所写的程序最终会变成一个产品，去解决某个商业场景下的问题，因此对于咱们来讲，公司的需求也毫不是只是让咱们把程序写好，只是把程序写好是不够的，咱们还须要设身处地的去考虑客户在使用咱们的产品的时候会遇到哪些问题，若是去优化解决这些问题。也就是说需求是多变的，咱们要设计出能应对复杂需求的产品，拥抱变化的需求。

以上就是想分享的三点，部份内容也都是老生常谈的问题，但不少事情就是这样，万变不离其宗，作人作事的正确方法始终都是不变的。