按照Service的启动方式可以分类为unbounded service和bounded service

对于unbounded service，客户端调用startService，将Intent发送给AMS，AMS查找（若没有创建）相应的ServiceRecord，找出客户端要启动的Service

startService

主要逻辑在bringUpServiceLocked中：

若Service没有启动，Service所在进程也没有启动，AMS负责启动进程，放入pendingServices中，等到进程正式启动，在attachApplicationLocked中正式将待启动的Service通过
realStartServiceLocked启动

真正启动Service的地方在realStartServiceLocked中，通过反射的方式创建出Service实例，调用其onCreate函数；待Service启动完成后，调用Service的onStartCommand函数进行处

第一次statrtService是这个流程，后续客户端再次start这个Service时，直接调用Service的onStartCommand函数

onStartCommand返回值-在Service启动时，serviceDoneExecuting中会根据其返回值决定当service被stop时的操作
start-sticky 重启Service
start-not-sticky 不重启
START_REDELIVER_INTENT 不重启，并重构startItem；适用于断点续传之类的业务

断点续传延伸- 关键点 HttpURLConnection.setRequestProperty("Range", "bytes=2097152-4194303"); Range 请求报文
断点续传关键点 Service onStartCommand返回值；http请求报文；多线程下载

stopService

对于unbounded Service，Service一直在运行，客户端调用stopService或者服务端调用stopSelf会stop Service,回调Service的onDestroy函数，并清除相关信息

bindService

客户端与服务端通信前，先调用bindService，传递Intent，客户端ServiceConnection对应的binder代理，以及flag到AMS中,AMS和startService一样，先根据Intent找到ServiceRecord

只有客户端的flag包含Context.BIND_AUTO_CREATE，才会真正调用bringUpServiceLocked，启动Service所在进程以及Service，调用onCreate创建完Service实例之后，调用requestServiceBindingsLocked，对IntentBindRecord代表的客户端第一次调用时，调用Service的onBind对象，onBind返回Service实例的binder对象，将其通过AMS的publishService保存在AMS中，AMS得到Service的binder对象后，将其作为参数并调用客户端的onServiceConnection，之后就可以在其中通过Service binder代理直接通过binder驱动调用服务端的方法，不再需要通过AMS

同时Service的binder对象已经被保存在AMS中，下面的客户端再bind时直接通过AMS中保存的对象作为参数调用客户端ServiceConnection的onServiceConnected，不再调用Service实例的onBind来查询其binder代理了

unbindService

客户端必须主动调用unbindService与Service解绑,只有一个参数，为客户端的ServiceConnection,一次性对这个ServiceConnection绑定的所有服务进行操作；调用Service的onUnBind(只有IntentBindRecord中记录的所有客户端ProcessRecord都被移除时才会调用)，当Service的所有带有BIND_AUTO_CREATE flag的客户端都被移除时(Service可能根据不同的Intent对象，保存了不同的IntentBindRecord)，调用onDestroy,然后回调客户端的onServiceDisconnected函数

简单例子，没必要自己写了，参考Android Service两种启动方式详解（总结版）