Service中是如何产生ANR的？

Posted 2022-07-02 北洋洋洋

​

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

客户端(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的内部类。