App中耗时的操作都会放到service中去完成。那么这个Service究竟是什么？线程or进程？
Service与线程和进程的关系
service是Android的四大组件之一，Android系统的一个宗旨就是弱化进程的概念，强化组件。App中的不同组件可以运行在不同的进程里，也可以运行在相同的进程。
简单的说，service和线程，进程半毛钱关系都没有。service是一个组件，一个对象而已。这个组件对象可以运行某个进程中的某个线程。然而进程线程中可以存在多个对象。
zygote孵化而来的进程的代码执行入口点是ActivityThread.main()方法。main()方法初始化运行环境，最后创建一个looper并进入looper消息处理循环。main()方法所在的线程是进程的主线程，也称为UI线程。当启动的service没有通过android:process属性指定运行在一个新的进程中时，这个service也是运行在UI线程中的。那么这种情况下的service作用就大大折扣了，因为一旦这里执行耗时操作，后果可想而知。
Service生命周期
service既然是一个组件，那么必然有其生命周期了。其生命周期相较于activity来说简单的太多了，
上图是两种启动service的方法下启动的service的生命周期图示。
第一次 startService 会触发 onCreate 和 onStartCommand，以后在服务运行过程中，每次 startService 都只会触发 onStartCommand。而且不论 startService 多少次，stopService 一次就会停止服务。
第一次 bindService 会触发 onCreate 和 onBind，以后在服务运行过程中，每次 bindService 都不会触发任何回调。这里要注意的是 bindService 多少次，就要有对应多少次的 unbindService， 最后的一次uunbindService执行完后，就会停止当前服务。
service在AMS中的代表
组件的生命周期方法都是AMS负责管理的，service当然也不例外了。一个运行着的service在AMS中的代表是ServiceRecord：
final class ServiceRecord extends Binder {
...............
final ActivityManagerService ams;
final ComponentName name; // service component.
final String shortName; // name.flattenToShortString().
final Intent.FilterComparison intent;// original intent used to find service.
final ServiceInfo serviceInfo;// all information about the service.
final ApplicationInfo appInfo; // information about service's app.
final int userId; // user that this service is running as
final String packageName; // the package implementing intent's component
final String processName; // process where this component wants to run
final String permission;// permission needed to access service
final boolean exported; // from ServiceInfo.exported
final Runnable restarter; // used to schedule retries of starting the service
final long createTime; // when this service was created
final ArrayMap<Intent.FilterComparison, IntentBindRecord> bindings
= new ArrayMap<Intent.FilterComparison, IntentBindRecord>();// All active bindings to the service.
final ArrayMap<IBinder, ArrayList<ConnectionRecord>> connections
= new ArrayMap<IBinder, ArrayList<ConnectionRecord>>();// IBinder -> ConnectionRecord of all bound clients
// service所在的进程
ProcessRecord app; // where this service is running or null.
}
serviceInfo和appInfo都是从PMS中获取的，PMS又是在该apk安装的时候通过解析AndroidManifest.xml中的service和applictaion标签获取的，并将信息存储到serviceInfo和appInfo。
重点介绍一下后面三个成员，其他成员注释已经解释的很清楚了。
每个Service均可能有不同的应用进程来bind，bind service时需要用到intent。 AMS为每类bind 该service的Intent分配了一个IntentBindRecord类型对象，并存储在ServiceRecord.bindings成员变量中；注意这里说的是一类，在启动service时，一般是显示的intent，只需要指定service组件的名字，不需要设置其他参数，这类intent，只会创建一个IntentBindRecord类型对象。
AMS为每次bind的连接分配一个ConnectionRecord类型对象，并存储在ServiceRecord.connections成员变量中:
/**
* Description of a single binding to a service.
*/
final class ConnectionRecord {
final AppBindRecord binding; // The application/service binding.
final ActivityRecord activity; // If non-null, the owning activity.
// 这里是绑定服务的客户端的一个binder，通过它可以调用客户端的方法
// ServiceConnection.onServiceConnected()
final IServiceConnection conn; // The client connection.
final int flags; // Binding options.
final int clientLabel; // String resource labeling this client.
final PendingIntent clientIntent; // How to launch the client.
String stringName; // Caching of toString.
boolean serviceDead; // Well is it?
这里暂时不关心clientIntent，这个数据结构在一个特殊情况下会使用：多个不同进程可能使用同一个Intent来bind serice。
重点关注IServiceConnection对象conn。这是app进程中的一个代理binder对象，通过这个对象AMS最终可以调用ServiceConnection.onServiceConnected()。后面会详细分析。
ProcessRecord是一个运行的进程在AMS中的代表，与service相关的重要成员：
final class ProcessRecord {
.........
IApplicationThread thread; // the actual proc... may be null only if
// all ServiceRecord running in this process
final ArraySet<ServiceRecord> services = new ArraySet<>();
// All ConnectionRecord this process holds
final ArraySet<ConnectionRecord> connections = new ArraySet<>();
.........
}
其中IApplicationThread类型的对象thread就是app进程中的ActivityThread.mAppThread这个binder在AMS中的代理。通过这个代理binder对象，AMS就可以间接跨进程调用app进程中的ActivityThread中的相关方法来创建一个service对象，并执行其生命周期方法了。
ProcessRecord中的services是这个进程中的运行着的service的集合。connections是bind这个进程中的service时，分配的所有ConnectionRecord集合。
另外ServiceRecord继承自Binder,说明在AMS中，负责管理service的ServiceRecord节点本身就是个binder实体。
service在app进程的代表
app开发中都需要继承Service类，来自定义一个service,service在App的进程就是Service类对象了:
public abstract class Service extends ContextWrapper implements ComponentCallbacks2 {
// set by the thread after the constructor and before onCreate(Bundle icicle) is called.
private ActivityThread mThread = null;
private String mClassName = null;
private IBinder mToken = null;
private Application mApplication = null;
private IActivityManager mActivityManager = null;
private boolean mStartCompatibility = false;
}
通过以上代码可以看出来，service紧紧是一个Context而已，与线程啊，进程啊真没啥关系。
注释中也说的很清楚了，在这个service被创建之后，有thread，也就是ActivityThread来设置这些属性成员，之后在执行service的第一个声明周期方法：onCreate.
mThread就是service所在进程的ActivityThread对象。
mToken就是这个service在AMS中的代表ServiceRecord的一个代理对象。
mActivityManager是AMS在当前进程的代理对象。
当service创建之后，它和AMS的关系如下：
service所在的进程是一个普通的app进程，是由zygote孵化的，这样的进程中有一个唯一的ActivityThread对象；
app进程在AMS中用ProcessRecord对象来表示；
ActivityThread.mAppThread是一个ApplicationThread类型的binder实体对象，在app进程启动后，会在ActivityThread.main()方法中传递给AMS，在AMS进程中这个binder的代理binder保存在ProcessRecord.thread中，这样的AMS可以通过这个代理binder跨进程调用某个app进程中的方法；
ActivityThread同样保存了AMS的代理binder，这样app进程也可以跨进程请求AMS中的方法。
ActivityThread.mServices：
final ArrayMap<IBinder, Service> mServices = new ArrayMap<>();
这个map中的key 是一个运行在该进程中的service在AMS中的代表ServiceRecord这个实体binder在app进程中的代理binder。当AMS请求app进程运行一个service时，会将这个代理binder传递到app进程，然后作为key保存mservice中。value就是运行在这个进程中的service。这个代理binder还会在Service对象创建之后，在service.attach中以参数的形式传入service,并作保存在service.mToken中。
- AMS中代表一个运行着的Service的ServiceRecord对象中保存了其所在的ProcessRecord。
