1.Service的start和bind状态有什么区别？
调用startService，service的完整生命周期从 onCreate=>onStartCommand=>onDestroy。多次调用startService只会多次调用onStartCommand，并不会调用onCreate。start启动的service与该组件没有任何联系，即使该组件被销毁了，service仍然在后台运行，必须调用stopService或者stopSelf来销毁service。
调用bindService,service的完整生命周期从onCreate=>onBind=>onUnBind=>onDestroy。如果service在bind方法调用前已经启动，那么绑定服务后只调用onBind。多次调用bindService并不会调用onCreate和onBind,它们都在服务被创建时调用。bind启动的服务依赖这些组件，当这些组件被销毁时，该服务同样也会被销毁，并且必须调用unbindService来销毁。
2. 同一个Service，先startService，然后再bindService，如何把它停止掉？
- 调用n次startService，只需调用一次stopService或者stopSelf。
调用n次bindService，必须调用n次unbindService。
所有只需调用一次stopService或者stopSelf和n次unbindService，没有执行顺序。
3. 你有注意到Service的onStartCommand方法的返回值吗？不同返回值有什么区别？
3.1 START_STICKY：
系统在调用完onStartCommand()方法后，如果当前服务被终止了，系统会使该服务保持在启动状态，不过它不会保留之前传递的Intent对象。但是由于它保持启动状态，随后系统会尝试重新创建service，但之前的Intent对象没有被保存。在这个情况下，如果期间没有任何启动命令被传递到Service，那么参数Intent将为null。因此使用START_STICKY作为返回值，适用于不执行命令的媒体播放器（或类似的服务），它只是无限期的运行着并等待工作的到来.
3.2 START_NOT_STICKY：
系统在调用完onStartCommand方法后，如果当前服务被终止了并且在此期间没有任何启动命令被传递到Service，那么系统将是使当前服务退出启动状态，并且除非重新调用Context.startService(Intent)，否则不会重新被创建（即不会重新调用onCreate方法）。因为当前服务退出了启动状态，所以除非在此期间启动命令被传递到Service，否则也不会调用。这是最安全的选项，用来避免在不需要的时候运行你的服务。onStartCommand方法。
3.3 START_REDELIVER_INTENT：
重传Intent。使用这个返回值时，如果在执行完onStartCommand后，服务被异常kill掉，系统会自动重启该服务，并将Intent的值传入。
3.4 START_STICKY_COMPATIBILITY：
START_STICKY的兼容版本，但不保证服务被kill后一定能重启。
4. Service的生命周期方法onCreate、onStart、onBind等运行在哪个线程？
- Service的所有方法都是默认运行在主线程。
