Service中是如何产生ANR的?

740 阅读6分钟

Service中是如何产生ANR的?

Service有两种,前台服务超时为SERVICE_TIMEOUT=20S 后台服务超时为SERVICE_BACKGROUD_TIMEOUT=200S 根据变量ProcessRecord.execServicesFg来决定是前台服务还是后台服务 Service TimeOut是位于“ActivityManager”线程中的AMS.MainHandler收到SERVICE_TIMEOUT_MSG消息时触发。

Binder进程通信

客户端(App进程)向中控系统(system_server进程)发起启动服务的请求 中控系统派出一名空闲的通信员(binder_1线程)接收该请求,紧接着向组件管家(ActivityManager线程)发送消息,埋下定时炸弹 通讯员1号(binder_1)通知工地(service所在进程)的通信员准备开始干活 通讯员3号(binder_3)收到任务后转交给包工头(main主线程),加入包工头的任务队列(MessageQueue) 包工头经过一番努力干完活(完成service启动的生命周期),然后等待SharedPreferences(简称SP)的持久化; 包工头在SP执行完成后,立刻向中控系统汇报工作已完成 中控系统的通讯员2号(binder_2)收到包工头的完工汇报后,立刻拆除炸弹。如果在炸弹倒计时结束前拆除炸弹则相安无事,否则会引发爆炸(触发ANR)

Service启动流程

1.当在Activity中调用startService时,会调用ContextWrappper的startService方法,其中mBase为ContextImpl 在这里插入图片描述

2.在里面调用了startServiceCommon方法 在这里插入图片描述

3.调用AMN的getDefult函数创建AMP,并调用AMP的startService函数 在这里插入图片描述

可以看到调用了ActivityManagerNative的getDefult()函数 在这里插入图片描述

该create方法返回的是AMP对象, 在这里插入图片描述

通过Binder通信,创建了一个IActitityManager服务接口,AMP和AMS都实现了该接口。AMP作为Binder通信的客户端,AMS作为Binder通信的服务端,AMP的startService最终会调用到AMS的startService方法 在AMP的startService中,会通过Binder驱动最终回到AMN的onTransact函数:(AMP为AMN的内部类并且实现了IActivityManager接口) 在这里插入图片描述

总结:AMP先调用了getDefult()方法用单例创建了ActivityManager接口(AvtivityManagerProxy和AMS都实现了这个接口),接着又通过getDefult调用了startService函数,其实也就是AMP的startService函数。在这个函数中又通过Binder驱动,回到了AMN的onTransact函数,在onTransact函数中会调用到AMS的startService(AMS继承自AMN)

4.在AMN的onTransact方法中,会生成ATN的代理对象也就是ATP(ApplicationThreadProxy),紧接着调用了AMS的startService方法。ATN(ApplicationThreadNative)相当于Binder通信的服务端,ATP相当于Binder通信的客户端。 (发起开启服务的进程为A,ServiceManagerService 为B。A进程通过Binder机制采用IActivityManager接口像B进程发起请求,进程B也能通过Binder机制采用IApplicationThread接口像A进程发起请求。) 在这里插入图片描述

关于IApplicationThread的类图: 在这里插入图片描述

5.接下来看AMS的startService方法: mService对象就是ActiveServices,在AMS里面构造方法初始化mServices = new ActiveServices(this); 答疑点3:Binder.clearCallingIdentity()和Binder.restoreCallingIdentity分别代表什么意思?有什么作用? 在这里插入图片描述

6.ActivityServices的startServicesLocked方法: 在这里插入图片描述

7.可以看到最后调用了startServieInnerLocked方法: 在这里插入图片描述

8.接下来会调用bringupServiceLocked方法: 在这里插入图片描述

在这里插入图片描述

可以看到会分为两种情况 如果能够根据进程名和pid查询到ProcessRecord的话说明进程已经启动,那么直接调用realStartServiceLocked(); 如果查询不到说明进程不存在,需要先调用startProcessLocked创建进程,在该方法里面会调用AMS.attachApplicationLocked,然后再执行realStartServiceLocked()函数。 9.先分析目标进程不存在的情况下的流程,AMS的attachApplicationLocked方法: 在这里插入图片描述

可以看到是调用了mServices的attachApplicationLocked方法: 在这里插入图片描述

可以看到这里还是会调用到readlStartServiceLocked方法。 10,所以目标进程存在那么直接调用readlStartServiceLocked方法,如果进程不存在的话会先创建进程起最后也会调用readlStartServiceLocked: 在这里插入图片描述

11.可以看到调用了bumpServiceExecutingLocked方法发送延时消息。在后面的scheduleCreateService中取消延时消息,如果超时未取消则会发送ANR。 在这里插入图片描述

12.可以看到最后一行发送延时消息。分析完bumpServiceExecutingLocked方法,接下来分析服务进入OnCreate时的流程也就是ApplicationThreadProxy的scheduleCreateService方法: 在这里插入图片描述

13.在ATN的onTransact接收到并在AT中准备创建所需要的数据没接着发送消息在ActivityThread中进行处理该消息 在这里插入图片描述

总结:借助于ATP/ATN这对Binder对象,便完成了从system_server所在进程到Service所在进程调用过程

14.在ActivityThread中handlerMessage会回调通过筛选会调用到handleCreateServices 在这里插入图片描述

15.可以看到会调用到Service的OnCreate方法,进入到Service的生命周期,并且在最后移除了刚才发送的延时消息 在这里插入图片描述

总结:1.ContextImpl会调用AMN来获取AMT,AMT中通过Binder和AMS通信(在AMN中获取到ATP后调用AMS),AMS中会判断Service所处的进程是否存在。(AMT处于app进程对应Binder客户端,AMS处于system_server进程对应Binder服务端)

2.在AMS中创建AS(ActivityServices)并调用AS的startServiceInnerLocked函数。Service的进程存在的情况下调用realStartServicLocked函数,首先发送延时消息,接着通过ATP(Binder客户端)像app进程发送通信;如果进程不存在的情况下去创建进程,后面会执行到新启的进程通过Binder调用到AMS的attachApplicatiionLocked函数,在里面也会调用到realStartServiceLocked

遗留问题:

1.进程间通信是通过Binder驱动,systemserver进程通知Zygote fork进程是通过sokect。在Service中涉及的两对Binder是什么?是怎么完成通信的?

app进程通知AMS所处的systemserver进程通信是通过AMP(客户端)和AMS(服务端)这对Binder完成的。

AMS所处的systemserver进程通知app进程开始启动服务是通过ATP(客户端)和ATN(服务端)这对Binder完成的。

AMP是AMN的内部类而AMS继承自AMN。

2.为什么ATP是在AMN中创建的?

这种方式在api26之后被弃用。

android api 26 ActivityManagerNative类被弃用。代理类ActivityManagerProxy已经被删除。改用AIDL方式。

3:Binder.clearCallingIdentity()和Binder.restoreCallingIdentity分别代表什么意思?有什么作用?

Binder.clearCallingIdentity()作用是清除远程调用端的pid和uid用当前进程的pid和uid代替

而Binder.restoreCallingIdentity的作用是恢复远程调用端的pid和uid

当调用同一个线程中的其他组件时,需要先清除远程调用端的pid和uid,当调用完时要恢复。

4.api26和api25启动Service的不同?

上述分析的是api25的Service启动流程。

先看app进程到AMS中的通信方式有什么变化:

在上面的第三步中是通过AMN的静态方法asInterface生成的IActivityManager。

而在26中使用的是:IActivityManager.Stub.asInterface(b);通过AIDL中的Stub实现的,stub.asInterface其实调用的也是queryLocalInterface,api25和api26的本质是一样的。

再看下AMS到app进程的通信方式:

api25使用的是ATP和ATN实现的,对应Binder的客户端和服务端。

而api26使用的是app.thread也就是ApplicationThread,该类是ActivityThread的内部类。