从 Android 入行开始, 因为工作需求和解决疑难 bug 的原因陆陆续续的看过一些源码, 但都不成系统, 从 2016 年年底开始, 在 Github 上建了一个 Android Open Source Project Analysis , 专门针对 Android 7.0 源码进行系统的分析, 这是一个从实践角度去分析源码的项目, 目前项目一期已经完成
更好的阅读体验?:point_down:
点击进入 GitBook 阅读
第一次阅览本系列文章, 请参见 导读 , 更多文章请参见 文章目录
- Git repositories on android
- Android Open Source Project
代码版本
细分版本: N6F26U
分支: android-7.1.1_r28
版本: Nougat
支持设备: Nexus 6
分析思路
Android 是一个庞大的系统, Android Framework 只是对系统的一个封装, 里面还牵扯到 JNIC++Java 虚拟机 Linux 系统内核指令集等面对如此庞大的系统, 我们得有一定的
章法去阅读源码, 否则就会只见树木不见森林, 陷入卷帙浩繁的细节与琐碎之中
不要去记录那些 API 调用链, 绘制一个序列图理清思路即可, Android Framework 中有很多复杂的 API 调用链, 你去关注这些东西, 用处不大你需要学会的是跟踪调用链和梳理流程的 技巧, 思考一下作者是怎么找到关键入口的, 核心的实现在什么地方
要善于思考, 要多问为什么, 面对一个模块, 你要去思考这个模块解决了什么问题, 这个问题的本质是什么, 为什么这么解决, 如果让我来写, 我会怎么设计事实上不管是是计算机还是 手机, 从 CPU 到内存到操作系统到应用层, 看似纷繁复杂, 但问题的本质无非就是这么几种: 时间片怎么分配? 线程 / 进程怎么调度? 通信的机制是什么? 只是在不同的场景下加了具体 的优化, 但问题的本质没有改变, 我们要善于抓住本质
要善于去粗存精, Android Framework 也是人写的, 有精华也有糟粕, 并不是每行代码你都需要问个为什么, 很多时候没有那么多为什么, 只是当时那种情况下就那样设计了但是 对于关键函数我们要去深究它的实现细节
写作风格
和大家一样, 笔者也是在前人的书籍和博客的基础上开始学习 Android 的底层实现的, 站在前人的肩膀上会看的更远但是这些书籍和博客有个问题在于, 文章中罗列了大量的代码, 这样 很容易把初学者带入到琐碎的细节之中, 所以本系列文章在行文中更多的会以图文并茂和提纲总结的方式来分析问题, 关键的地方才会去解析源码, 力求让大家从宏观上理解 Android 的底 层实现另外, 基本上一个主题对应一篇文章, 所以文章会比较长, 但是文章会有详细的标题划分和提纲总结, 可以有的放矢, 阅读自己需要的内容
好了, 让我们开始我们的寻宝之旅吧~:laughing:
Android 系统架构图
Android 系统架构图
从上到下依次分为六层:
应用框架层
进程通信层
系统服务层
Android 运行时
硬件抽象层
Linux 内核层
在正式阅读本系列文章之前, 请先阅读导读相关内容, 这会帮助你更加快捷的理解文章内容
导读
Android 系统应用框架篇
Android 窗口管理框架
01Android 窗口管理框架: Android 窗口管理框架概述
02Android 窗口管理框架: Android 应用视图的载体 View
03Android 窗口管理框架: Android 应用视图的管理者 Window
04Android 窗口管理框架: Android 应用窗口管理服务 WindowServiceManager
05Android 窗口管理框架: Android 布局解析者 LayoutInflater
06Android 窗口管理框架: Android 列表控件 RecyclerView
Android 组件管理框架
01Android 组件管理框架: Android 组件管理框架概述
02Android 组件管理框架: Android 组件管理服务 ActivityServiceManager
03Android 组件管理框架: Android 视图容器 Activity
04Android 组件管理框架: Android 视图片段 Fragment
05Android 组件管理框架: Android 后台服务 Service
06Android 组件管理框架: Android 内容提供者 ContentProvider
07Android 组件管理框架: Android 广播接收者 BroadcastReceiver
08Android 组件管理框架: Android 应用上下文 Context
Android 包管理框架
01Android 包管理框架: APK 的打包流程
02Android 包管理框架: APK 的安装流程
03Android 包管理框架: APK 的加载流程
Android 资源管理框架
01Android 资源管理框架: 资源管理器 AssetManager
Android 系统底层框架篇
Android 进程框架
01Android 进程框架: 进程的创建启动与调度流程
02Android 进程框架: 线程与线程池
03Android 进程框架: 线程通信的桥梁 Handler
04Android 进程框架: 进程通信的桥梁 Binder
05Android 进程框架: 进程通信的桥梁 Socket
Android 内存框架
01Android 内存框架: 内存管理系统
02Android 内存框架: Ashmem 匿名共享内存系统
Android 虚拟机框架
01Android 虚拟机框架: Java 类加载机制
Android 应用开发实践篇
Android 界面开发
01Android 界面开发: View 自定义实践概览
02Android 界面开发: View 自定义实践布局篇
03Android 界面开发: View 自定义实践绘制篇
04Android 界面开发: View 自定义实践交互篇
Androidy 应用优化
01Android 应用优化: 兼容适配实践指南
02Android 应用优化: 性能优化实践指南
其他
01Android 混合编程: webView 实践
02Android 网络编程: 网络编程实践
Android 系统软件设计篇
01Android 系统软件设计篇: 软件设计原则
02Android 系统软件设计篇: 设计模式
有兴趣参与此项目的小伙伴可以扫码入群, 本群主要讨论 Android Framework 主流开源框架以及 Android 工程化相关技术, 本群不是一个读者群, 希望大家每个人都能成为项目的参与者另外, 为了营造一个 良好的技术氛围, 群里尽量不要灌水闲聊, 如果二维码过期可以加我微信 allenwells 邀请入群
文章的最后再聊一聊工作这几年来的感悟, 其实我一向是比较少的去聊这些事情, 因为觉得这些东西讲多了, 有点夸夸其谈的感觉, 但是这几年工作下来, 有几点东西确实是感触颇深的, 这里 简单总结一下
客户第一 - 人与人之间的关系
这个挺起来好像有点官僚风的味道, 但这里要说的不是我们产品的客户, 而是说我们自己的客户, 有没有想过这个问题, 我们自己的客户是谁? 一般说来, 我们向哪些人提供服务, 哪些人 就是我们的客户, 比如我任职于公司的平台架构部, 我们向业务研发团队产品团队, 运营团队和测试团队输出产品和工具, 所以他们都是我的客户, 除了你提供服务的那些人外, 你的 leader 也是你的客户, 他会给你布置任务, 你去完成他的任务
那么什么是客户第一呢?
比方说你的 leader 在给你布置任务的时候, 他会根据他心目中你的能力大小来制定对任务完成结果的预期, 他觉得以你的能力可以把一个 10 分的事情做到 6 分然后他就会以六分为标准来安排任务, 当你最终 完成了这些任务后, 他并不会进一步的认可你的能力, 因为你做的事情都在他的预期之内所谓客户第一, 就是你需要向办法找到 leader 以及其他团队对这个事情 10 分的预期是什么, 然后按照这个标准去完成 任务, 也就是说要高于客户的预期去完成需求, 不单单是满足需求, 而是去帮助我们的客户解决更多的问题
团队合作 - 人与团队之间的关系
团队合作也是个老生常谈的问题, 但是吧这一点做好并不简单, 尤其是公司越来越大, 团队越来越多的时候, 沟通成本就变得十分巨大团队合作主要解决三个方面的问题: 我如何和我所在 的团队进行合作? 我所在的团队如何和其他团队合作? 我所带领的团队如何和其他团队合作? 那所有的退队集合在一起, 往一个方向去做事
拥抱变化 - 人与产品之间的关系
拥抱变化对产品而言的, 我们所写的程序最终会变成一个产品, 去解决某个商业场景下的问题, 所以对于我们来说, 公司的需求也绝不是只是让我们把程序写好, 只是把程序写好是不够的, 我们还需要设身 处地的去考虑客户在使用我们的产品的时候会遇到哪些问题, 如果去优化解决这些问题也就是说需求是多变的, 我们要设计出能应对复杂需求的产品, 拥抱变化的需求
以上就是想分享的三点, 部分内容也都是老生常谈的问题, 但很多事情就是这样, 万变不离其宗, 做人做事的正确方法始终都是不变的
来源: http://www.tuicool.com/articles/bMrAb2N