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

郭孝星  |  2018. 02. 26   |  阅读 770 次

从 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界面开发

Androidy应用优化

其他

Android系统软件设计篇

有兴趣参与此项目的小伙伴可以扫码入群,本群主要讨论Android Framework、主流开源框架以及Android工程化相关技术,本群不是一个读者群,希望大家每个人都能成为项目的参与者。另外,为了营造一个 良好的技术氛围,群里尽量不要灌水闲聊,如果二维码过期可以加我微信allenwells邀请入群。

文章的最后再聊一聊工作这几年来的感悟,其实我一向是比较少的去聊这些事情,因为觉得这些东西讲多了,有点夸夸其谈的感觉,但是这几年工作下来,有几点东西确实是感触颇深的,这里 简单总结一下。

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

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

那么什么是客户第一呢?

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

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

团队合作也是个老生常谈的问题,但是吧这一点做好并不简单,尤其是公司越来越大,团队越来越多的时候,沟通成本就变得十分巨大。团队合作主要解决三个方面的问题:我如何和我所在 的团队进行合作?我所在的团队如何和其他团队合作?我所带领的团队如何和其他团队合作?那所有的退队集合在一起,往一个方向去做事

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

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

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

分享到

   
一种智能识别车商装修程度的方法