有些书在介绍和讲解android的Service组件时，会使用后台服务一词，并且与运行在主线程的Activity相对。因为后台一词很容易误解，服务一直运行在后台？什么线程在运行？服务一直有条线程在运行？而且后台在不同语境有不同理解。但是如果你开发过COM应用的话，这个Service组件就很容易理解。
我们回顾是如何使用COM的，先实例一个CoInstance，然后通过IUnknown接口QueryInterface查询出我们想要的接口，然后调用接口的方法访问COM组件提供的服务。COM组件可能实例在同一进程，又或者实例在进程外的本地进程（或者远程进程）。对于自由线程的进程内组件，接口调用（COM组件的代码）运行在调用线程。对于套间线程的组件，不论是进程内还是进程外，接口调用都通过IPC（LPC或RPC）串行访问COM组件的功能。
我们来看一下android中Service的使用。
对于非系统服务的使用。
首先Context.bindService，(如果系统范围内没有服务实例则被创建)，他们说绑定到一个服务，其实最重要是获取Service对应的IBinder。在这里要习惯Java或JavaScript编程中常用到的接收结果的类，这些类往往通过提供接口回调方法来接收结果。像这里的第二个参数是一个ServiceConnection类，就这样一看还以为它负责处理connect功能相关的方法，但实质上只是一个用来接收结果的回调接口。哎！没什么好说，要习惯它。
得到的这个IBinder就是我们要访问的关键，但是怎么访问，一般的书和帖都没有说明。我通过系统服务ClipboardManager（只是随手选中）代码来举例。在源代码的注释中，android团队用proxying来表述这种通过ClipboardManager对IClipboard接口照样封装一次，类似桥模式的访问。
对于系统服务的使用。
首先Context.getSystemService，我们得到系统服务接口的一个proxying封装。对于举例的ClipboardManager封装的就是对IClipboard接口的调用。
我们进入ClipboardManager源代码。
static private IClipboard getService() { synchronized (sStaticLock) { if (sService != null) { return sService; } IBinder b = ServiceManager.getService("clipboard"); sService = IClipboard.Stub.asInterface(b); return sService; } }
可以看出，还是要得到服务的IBinder。我们可以会意一笑，IClipboard.Stub.asInterface(b)，不就相当于对IUnknown进行QueryInterface吗？好了，IBinder就相当于一个IUnknown，通过"目标接口.Stub.asInterface"查询目标接口，然后当然就是对不为空的接口进行访问了，访问也就是服务的提供的功能。
对于android来说，服务是一个实例，是系统范围的单例，跟服务同进程的调用运行在调用线程（也可以是主线程），在服务进程外的调用就是一种ActiveObject模式的访问，服务功能调用运行在服务进程内，接口调用进程和服务进程通过IPC传递参数和结果。 通过浏览IBinder的实现Binder的源代码，大部分功能在做ipc和proxy的工作。
对于Service除了像COM组件那样通过提供接口访问功能外，另一种途径就是处理Intent请求，这个处理就在Service.onStartCommand中进行，并不用借助IBinder。访问服务的功能通过startService(Intent)来请求一次访问，再一次吐槽，这个命名怎么都会字面理解成启动服务，其实不然，主要是通过Intent传递参数，请求一次服务。并没有Service.onPause和Service.onStop，也就是Service.onStart并不影响Service的状态，单单只是处理Intent的回调入口，哎~。PendingService则有一专用线程，通过消息方式回调PendingService.onHandleIntent串行处理所有传递进来的Intent。
另外Context.bindService也带参数Intent，并非要在Service.onBind中处理Intent请求，而是作为接口查询参数，返回不同的IBinder，你的Service可以聚集多个IBinder。