Android(安卓)Service Framework分析
16lz
2021-12-04
当我在为fetion client工作时，我那个时候逐渐意识到消息处理框架的重要性和设计的精妙，现在在Android中，Service已经是 一个非常重要的组件（one of Application Fundamentals），而且Android的Service Framework设计的更为精妙，这使得我更有兴趣去研究它。
读了一些Service Framework代码之后，我回过头去看这两篇文章（ IPC框架分析 Binder，Service，Service manager， Service深入分析），感觉又有新的理解。
首先是从观念上的改变。思考我过去的软件行为，最多的是为了实现某个功能、达到某个效率、解决某个问题去看事情，这种做法我现在看来非常具有局限性（而这一点在我阅读了 冷冰的几篇博文尤为深刻），冷冰的博文提供了一种思路，蕴含一种哲学意味的思想，我虽然不能很理解，但是就目前而言，这些文章的警醒作用是很明显的：我开始纠正自己思维方式（为了这个问题，曾经在javaeye上提问，得到了一些有建设性的意见），我开始关注一些在之前看起来有点遥远的东西比如说架构图、类图、流程图等等，我开始使用uml工具帮助自己理解一些软件设计模式，我开始动手总结自己的认知与疑问（写博客），等等。尤其是最近，当我经过努力，认识到自己以前所未能认识到的一些知识（像设计者的意图、类图、巧妙之处、精彩之处、自己设计的方法跟牛人设计之间的差距等等），我真的体会到了喜悦，而这种喜悦又督促我去理解更多。总之，从设计者的角度去考量他人的作品，将收获更多超越使用者的认知与乐趣，一件件软件作品、架构，那真的是一件件思想的瑰宝，蕴含着无数深思熟虑和未雨绸缪，总是有挖掘不完的东西在里面。
接着来看具体的Service框架。
分析Service框架时始终把下面两张图放在脑海里（前一张来自Service本质框图，后一张来自冷冰对Android Service的分析框图）：
Service本质框图
冷冰分析的Android Service框图
另外带着几个问题去看（出自冷冰博文）：
1.闭合循环结构放置在哪里？
2.处理请求是如何分发和管理？
3.处理光加是如何建立的？
4.概念框架是如何建立的？
看了一下午的Service相关的源码，总体感觉是明白了一半，迷糊一半。IPC的东西因为之前没接触过，所以一时半会理解不全，但是对于Service架构我现在有了深入一些的理解，而冷冰的博文以及他提出的问题也逐渐解答了我的不少疑问。
我在看Service框架时，一直以为Service框架没有闭合循环结构来处理请求，但是根据冷冰的分析，Service的闭合循环结构是在c++空间的（对于只懂java的我来说是有点难找，~(>_<)~ ），拿跨进程Service为例，AIDL描述了客户端与Service之间通讯的接口，通讯的数据体在java空间中是要实现Parcelable接口的，IBinder、Binder这些概念已经接近linux底层。假如多次接口（AIDL生成的接口）中定义方法的调用，还是会被加入到Service在c++空间中的消息处理队列中，由c++代码去处理这些请求。我在理解这些概念的时候一直疑惑于Handler（本来我一直认为Service是没有消息处理结构的，所以Handler与Service结合为Service添加消息处理结构就变的理所应当），而Service自身有存在消息处理结构，那么Handler的存在是什么意义呢？想了好久，才发现，Handler是一个通用的消息处理框架，任何想用循环队列这种方式处理请求的组件或者其它都可以使用Handler为自己轻松构建这样一套处理结构（之前我在fetion client看到的消息处理框架与这个类似，虽然这算不上什么很难的功能，但是在高要求下维护起来还是会小头疼，除非你自认为能写出比google程序员更好的代码），而不少代码设计已经证明，这的确很通用（Broadcast、EventHandler等神马的东东都可以用嘛），也更灵活且易于维护需求代码而不是框架代码本身。
关于Service框架的其它深入的信息，我还会再补充。
读了一些Service Framework代码之后，我回过头去看这两篇文章（ IPC框架分析 Binder，Service，Service manager， Service深入分析），感觉又有新的理解。
首先是从观念上的改变。思考我过去的软件行为，最多的是为了实现某个功能、达到某个效率、解决某个问题去看事情，这种做法我现在看来非常具有局限性（而这一点在我阅读了 冷冰的几篇博文尤为深刻），冷冰的博文提供了一种思路，蕴含一种哲学意味的思想，我虽然不能很理解，但是就目前而言，这些文章的警醒作用是很明显的：我开始纠正自己思维方式（为了这个问题，曾经在javaeye上提问，得到了一些有建设性的意见），我开始关注一些在之前看起来有点遥远的东西比如说架构图、类图、流程图等等，我开始使用uml工具帮助自己理解一些软件设计模式，我开始动手总结自己的认知与疑问（写博客），等等。尤其是最近，当我经过努力，认识到自己以前所未能认识到的一些知识（像设计者的意图、类图、巧妙之处、精彩之处、自己设计的方法跟牛人设计之间的差距等等），我真的体会到了喜悦，而这种喜悦又督促我去理解更多。总之，从设计者的角度去考量他人的作品，将收获更多超越使用者的认知与乐趣，一件件软件作品、架构，那真的是一件件思想的瑰宝，蕴含着无数深思熟虑和未雨绸缪，总是有挖掘不完的东西在里面。
接着来看具体的Service框架。
分析Service框架时始终把下面两张图放在脑海里（前一张来自Service本质框图，后一张来自冷冰对Android Service的分析框图）：
Service本质框图
冷冰分析的Android Service框图
另外带着几个问题去看（出自冷冰博文）：
1.闭合循环结构放置在哪里？
2.处理请求是如何分发和管理？
3.处理光加是如何建立的？
4.概念框架是如何建立的？
看了一下午的Service相关的源码，总体感觉是明白了一半，迷糊一半。IPC的东西因为之前没接触过，所以一时半会理解不全，但是对于Service架构我现在有了深入一些的理解，而冷冰的博文以及他提出的问题也逐渐解答了我的不少疑问。
我在看Service框架时，一直以为Service框架没有闭合循环结构来处理请求，但是根据冷冰的分析，Service的闭合循环结构是在c++空间的（对于只懂java的我来说是有点难找，~(>_<)~ ），拿跨进程Service为例，AIDL描述了客户端与Service之间通讯的接口，通讯的数据体在java空间中是要实现Parcelable接口的，IBinder、Binder这些概念已经接近linux底层。假如多次接口（AIDL生成的接口）中定义方法的调用，还是会被加入到Service在c++空间中的消息处理队列中，由c++代码去处理这些请求。我在理解这些概念的时候一直疑惑于Handler（本来我一直认为Service是没有消息处理结构的，所以Handler与Service结合为Service添加消息处理结构就变的理所应当），而Service自身有存在消息处理结构，那么Handler的存在是什么意义呢？想了好久，才发现，Handler是一个通用的消息处理框架，任何想用循环队列这种方式处理请求的组件或者其它都可以使用Handler为自己轻松构建这样一套处理结构（之前我在fetion client看到的消息处理框架与这个类似，虽然这算不上什么很难的功能，但是在高要求下维护起来还是会小头疼，除非你自认为能写出比google程序员更好的代码），而不少代码设计已经证明，这的确很通用（Broadcast、EventHandler等神马的东东都可以用嘛），也更灵活且易于维护需求代码而不是框架代码本身。
关于Service框架的其它深入的信息，我还会再补充。
更多相关文章
- 1.1.2 Android的系统框架
- 处理固定宽度下的长字符串绘制(Android)
- Android中几种图像特效处理
- android UI横竖屏的处理
- android HAL框架
- Android(安卓)模拟J2me 通过连接框架
- afinal快速开发框架
- Android(安卓)的用户层 uevent处理机制
- (转载)Instrumentation 框架简介