关于android service的几点学习总结和梳理

这两天都在学习服务。下面对这两天的学习做一个简单的总结。
1.Service不是一个单独的进程,它和它的应用程序在同一个进程中
2.Service不是一个线程,这样就意味着我们应该避免在Service中进行耗时操作。
3.Android给我们提供了解决上述问题的替代品，就是下面要讲的IntentService； IntentService是继承与Service并处理异步请求的一个类,
在IntentService中有一个工作线程来处理耗时操作,请求的Intent记录会加入队列
工作流程：
客户端通过startService(Intent)来启动IntentService; 我们并不需要手动地区控制IntentService,当任务执行完后,IntentService会自动
停止; 可以启动IntentService多次,每个耗时操作会以工作队列的方式在IntentService的 onHandleIntent回调方法中执行,并且每次只会执行
一个工作线程,执行完一，再到二这样!
下面是没有怎么理解透的内容。
一、activity和service的通信。官方给的书写步骤是:
1.自定义Service中，自定义一个Binder类，然后将需要暴露的方法都写到该类中！
2.Service类中，实例化这个自定义Binder类，然后重写onBind()方法，将这个Binder对象返回！
3.Activity类中实例化一个ServiceConnection对象，重写onServiceConnected()方法，然后 获取Binder对象，然后调用相关方法即可！
这里往深了走涉及到进程之间的通信机制，目前来说只能知其然。网上很多实例都是说service在后台下载，前台显示下载进度的。这很容易，
onServiceConnected成功后便可以得到onBind()返回的binder，binder差不多可以理解为一个自定义类，想封装什么都可以，比如把下
载的进度放进去，然后activity每隔一秒读一次binder。但这样有点不科学，为什么要activity每隔一秒读一次binder，如果能让service主动告诉
activity下载进度会更好，这种机制尤其在不需要知道执行进度，只关心执行结果时很有用，比如使用定位服务，不用知道进度，只要定位成功告诉我坐
标就好。怎么样实现这个等完成了通知我一声。有两种方法，一种是用回调函数，一种是广播。我今天就绕在回调函数里了。广播很好理解，不用多说。重点
说下回调函数。参考这篇文章http://m.blog.csdn.net/article/details?id=8703708。
Class A实现接口CallBack callback——背景1
class A中包含一个class B的引用b ——背景2
class B有一个参数为callback的方法f(CallBack callback) ——背景3
A的对象a调用B的方法 f(CallBack callback) ——A类调用B类的某个方法C
然后b就可以在f(CallBack callback)方法中调用A的方法 ——B类调用A类的某个方法D
还是用定位举例，我自己的理解就是A要求B，确定设备所在地理坐标，让B做完后把结果告诉A（或者还要实时报告进度）。
B怎样告诉A呢？答案是通过接口，A调用B的f(CallBack callback) 时把自己实现了的接口引用传递给B，当B定位成功后便可以调用A实现了的接口
里的方法。这样成功通过回调来告诉A定位的结果。注意:回调嵌套的层次不要太深，不然代码可读性会很差，比如A问B，B再问C，C再问D。
－－－－－－－－－－－－－－－－－－－－－－－－－以上是上周末写的一些总结－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
这周前几天主要实现了使用回调函数来完成服务执行完毕后通知activity执行相应操作。以下是实际写代码时的一点经验总结：
一、android service与activity的通信，特别是回调函数方式通信的一般做法是：
1、定义一个接口，接口里定义需要回调的方法。如果工程需要定义很多种接口，最好定义一个类，或者包，把所有的接口放在一起。
2、定义一个bind类，类里返回服务的实例，重写onBinder()方法，返回自定义的binder，也就是将binder传递给activity。
3、service中定义一个该接口实例。
4、在activity中实例化一个ServiceConnection(),按要求重写onServiceConnected和onServiceDisconnected方法。在
onServiceConnected(ComponentName componentName, IBinder iBinder)中得到从service返回的自定义binder，然后从binder
中得到service的实例。
5、activity中实现接口，重写回调方法，然后将这个接口通过得到的service实例传递给第3步中定义的服务中的实例。
通过上面5个步骤，便实现了service和activity的互联。示例代码网上很多，需要使用时直接搜索下。
二、不能在onServiceConnected(ComponentName componentName, IBinder iBinder)方法中直接更新UI，目前还不明白为什么。
三、关于bindService（）需要注意的几点。
1、bindService(Intent, ServiceConnection, int)最后一个参数一般是Context.BIND_AUTO_CREATE。下面是官方的关于该参
数的描述。
Flag for bindService(Intent, ServiceConnection, int): automatically create the service as long as the binding 
exists.  Note that while this will create the service, its onStartCommand(Intent, int, int) method will still only be 
called due to an explicit call to startService(Intent).  Even without that, though, this still provides you with access
 to the service object while the service is created. 
（只要绑定存在便自动创建service。需要注意的是虽然bindservice创建service，但是它的onStartCommand方法仍然只能通过调用
startService()实现调用。不过即使没有startService，bindService在创建service时仍然会提供一个service的入口。意思就是bindService
启动服务只会调用onBind和onCreate。而且服务已经运行，并且之间已经与别的activity绑定，这两个方法都不会执行，直接返回一个binder。）
Note that prior to ICE_CREAM_SANDWICH, not supplying this flag would also impact how important the system consider's
 the target service's process to be.  When set, the only way for it to be raised was by binding from a service in which 
case it will only be important when that activity is in the foreground.  Now to achieve this behavior you must explicitly 
supply the new flag BIND_ADJUST_WITH_ACTIVITY.  For compatibility, old applications that don't specify BIND_AUTO_CREATE
 will automatically have the flags BIND_WAIVE_PRIORITY and BIND_ADJUST_WITH_ACTIVITY set for them in order to achieve 
the same result.
          
Constant Value:                1          (0x00000001) 
四、关于IntentService。
默认onBind返回null，网上有些文章说IntentService不支持bind，自己实验后其实是支持的。这里总结一下就是bindService（）这个函数启动
service，只会触发onCreate和onBind函数。如果需要触发onStartCommond，需要startService。