当我在为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的分析框图):
![](https://i-blog.csdnimg.cn/blog_migrate/759d604590aa213fc1ff145fe3bc98a2.gif)
Service本质框图
![](https://i-blog.csdnimg.cn/blog_migrate/2c1a8d18c2a1953e7a8592f2c62ff08a.gif)
冷冰分析的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框架的其它深入的信息,我还会再补充。