Service中是如何产生ANR的？
Service中是如何产生ANR的？
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的内部类。
