Android深入四大组件(三)Service的绑定过程

前言

我们可以通过调用Context的startService来启动Service,也可以通过Context的bindService来绑定Service,建议阅读此篇文章前请阅读Android深入四大组件(二)Service的启动过程这篇文章,知识点重叠的部分,本篇文章将不再赘述。

1.ContextImpl到ActivityManageService的调用过程

我们可以用bindService方法来绑定Service,它的实现在ContextWrapper中,代码如下所示。 frameworks/base/core/java/android/content/ContextWrapper.java

这里mBase具体指向就是ContextImpl,不明白的请查看 Android深入四大组件(二)Service的启动过程这篇文章。接着查看ContextImpl的bindService方法:

frameworks/base/core/java/android/app/ContextImpl.java

在bindService方法中,又return了bindServiceCommon方法,代码如下所示。

frameworks/base/core/java/android/app/ContextImpl.java

在注释1处调用了LoadedApk类型的对象mPackageInfo的getServiceDispatcher方法,它的主要作用是将ServiceConnection封装为IServiceConnection类型的对象sd,从IServiceConnection的名字我们就能得知它实现了Binder机制,这样Service的绑定就支持了跨进程。接着在注释2处我们又看见了熟悉的代码,最终会调用AMS的bindService方法。ContextImpl到ActivityManageService的调用过程如下面的时序图所示。

2.Service的绑定过程

AMS的bindService方法代码如下所示。 frameworks/base/services/core/java/com/android/server/am/ActivityManagerService.java

bindService方法最后会调用ActiveServices类型的对象mServices的bindServiceLocked方法: frameworks/base/services/core/java/com/android/server/am/ActiveServices.java

在注释1处会bringUpServiceLocked方法,在bringUpServiceLocked方法中又会调用realStartServiceLocked方法,最终由ActivityThread来调用Service的onCreate方法启动Service,这一过程在Android深入四大组件(二)Service的启动过程这篇文章中已经讲过,这里不再赘述。

在注释2处s.app != null 表示Service已经运行,其中s是ServiceRecord类型对象,app是ProcessRecord类型对象。b.intent.received表示当前应用程序进程的Client端已经接收到绑定Service时返回的Binder,这样应用程序进程的Client端就可以通过Binder来获取要绑定的Service的访问接口。注释3处调用c.conn的connected方法,其中c.conn指的是IServiceConnection,它的具体实现为ServiceDispatcher.InnerConnection,其中ServiceDispatcher是LoadedApk的内部类,InnerConnection的connected方法内部会调用H的post方法向主线程发送消息,从而解决当前应用程序进程和Service跨进程通信的问题,在后面会详细介绍这一过程。 在注释4处如果当前应用程序进程的Client端第一次与Service进行绑定的,并且Service已经调用过onUnBind方法,则需要调用注释5的代码。 注释6处如果应用程序进程的Client端没有发送过绑定Service的请求,则会调用注释7的代码,注释7和注释5的代码区别就是最后一个参数rebind为false,表示不是重新绑定。 接着我们查看注释7的requestServiceBindingLocked方法,代码如下所示。 frameworks/base/services/core/java/com/android/server/am/ActiveServices.java

注释1处i.requested表示是否发送过绑定Service的请求,从前面的代码得知是没有发送过,因此,!i.requested为true。从前面的代码得知rebind值为false,那么(!i.requested || rebind)的值为true。如果IntentBindRecord中的应用程序进程记录大于0,则会调用注释2的代码,r.app.thread的类型为IApplicationThread,它的实现我们已经很熟悉了,是ActivityThread的内部类ApplicationThread,scheduleBindService方法如下所示。

frameworks/base/core/java/android/app/ActivityThread.java

首先将Service的信息封装成BindServiceData对象,需要注意的BindServiceData的成员变量rebind的值为false,后面会用到它。接着将BindServiceData传入到sendMessage方法中。sendMessage向H发送消息,我们接着查看H的handleMessage方法。

frameworks/base/core/java/android/app/ActivityThread.java

H在接收到BIND_SERVICE类型消息时,会在handleMessage方法中会调用handleBindService方法:

frameworks/base/core/java/android/app/ActivityThread.java

注释1处获取要绑定的Service 。注释2处的BindServiceData的成员变量rebind的值为false,这样会调用注释3处的代码来调用Service的onBind方法,这样Service处于绑定状态了。如果rebind的值为true就会调用注释5处的Service的onRebind方法,结合前文的bindServiceLocked方法的注释4处,我们得知如果当前应用程序进程的Client端第一次与Service进行绑定,并且Service已经调用过onUnBind方法,则会调用Service的onRebind方法。接着查看注释4的代码,实际上是调用AMS的publishService方法。讲到这,先给出这一部分的代码时序图(不包括Service启动过程)

我们接着来查看AMS的publishService方法,代码如下所示。 frameworks/base/services/core/java/com/android/server/am/ActivityManagerService.java

publishService方法中,调用了ActiveServices类型的mServices对象的publishServiceLocked方法:

frameworks/base/services/core/java/com/android/server/am/ActiveServices.java

注释1处的代码,我在前面介绍过,c.conn指的是IServiceConnection,它的具体实现为ServiceDispatcher.InnerConnection,其中ServiceDispatcher是LoadedApk的内部类,ServiceDispatcher.InnerConnectiond的connected方法的代码如下所示。

frameworks/base/core/java/android/app/LoadedApk.java

在注释1处调用了ServiceDispatcher 类型的sd对象的connected方法,代码如下所示。 frameworks/base/core/java/android/app/LoadedApk.java

注释1处调用Handler类型的对象mActivityThread的post方法,mActivityThread实际上指向的是H。因此,通过调用H的post方法将RunConnection对象的内容运行在主线程中。RunConnection的定义如下所示。

frameworks/base/core/java/android/app/LoadedApk.java

在RunConnection的run方法中调用了doConnected方法:

frameworks/base/core/java/android/app/LoadedApk.java

在注释1处调用了ServiceConnection类型的对象mConnection的onServiceConnected方法,这样在客户端中实现了ServiceConnection接口的类的onServiceConnected方法就会被执行。至此,Service的绑定过程就分析到这。最后给出剩余部分的代码时序图。

原文发布于微信公众号 - 刘望舒(liuwangshuAndroid)

原文发表时间:2017-04-28

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏腾讯移动品质中心TMQ的专栏

结合静态代码扫描来给插件间接口把把脉

如火如荼的EP建设中小鹅收到了一个小小的需求,如何知道每个版本变更了哪些插件间接口呢,有没有及时覆盖?

24460
来自专栏Flutter知识集

Flutter与Native通信 - PlatformChannel源码分析

Flutter是一个跨平台的方案,在UI、触控及基本的网络请求上已经基本做到平台无关,但是在某些平台特性的功能上,还是必须要对不同的平台做处理。这就涉及到与Na...

1.4K00
来自专栏向治洪

蘑菇街Android组件与插件化

插件化的基石 -- apk动态加载 随着我街业务的蓬勃发展,产品和运营随时上新功能新活动的需求越来越强烈,经常可以听到“有个功能我想周x上,行不行”。行么?...

216100
来自专栏极客编程

EOS开发中区块链数据持久性(上) 原

要了解数据持久性,请编写一个简单的智能合约,作为地址记录。虽然这个用例由于各种原因而不太适合作为生产智能合约,但开始学习数据持久性如何在EOSIO上运行而不被与...

9820
来自专栏美团技术团队

不可不说的Java“锁”事

Java提供了种类丰富的锁,每种锁因其特性的不同,在适当的场景下能够展现出非常高的效率。本文旨在对锁相关源码(本文中的源码来自JDK 8)、使用场景进行举例,为...

15320
来自专栏别先生

基于jsp+servlet图书管理系统之后台用户信息修改操作

上一篇的博客写的是查询操作,且附有源码和数据库,这篇博客写的是修改操作,附有从头至尾写的代码(详细的注释)和数据库!  此次修改操作的源码和数据库:http:...

570100
来自专栏醒者呆

Controller:EOS区块链核心控制器

命名空间namespace定义了一个范围,这个范围本身可作为额外的信息,类似于地址,或者位置。如果有两个名字相同的变量或者函数,例如foshan::linshu...

18830
来自专栏岑玉海

hbase源码系列(七)Snapshot的过程

  在看这一章之前,建议大家先去看一下snapshot的使用。可能有人会有疑问为什么要做Snapshot,hdfs不是自带了3个备份吗,这是个很大的误区,要知道...

35860
来自专栏别先生

基于jsp+servlet图书管理系统之后台用户信息查询操作

上一篇的博客写的是插入操作,且附有源码和数据库,这篇博客写的是查询操作,附有从头至尾写的代码(详细的注释)和数据库!   此次查询操作的源码和数据库:http:...

461100
来自专栏Java架构沉思录

再谈如何优雅地使用Redis之位图操作

在之前的文章《如何优雅地使用Redis之位图操作》里为大家介绍了Redis位图操作常见的应用场景,今天继续聊聊Redis位图的其他应用。

17410

扫码关注云+社区

领取腾讯云代金券