悬浮窗服务开发遇到的问题
Q:为什么在小米手机中service的onStartCommand使用START_STICKY作为返回值无效？
A:本人使用的是MIUI7。
高版本的MIUI都有安全中心，其中有个功能为授权管理，授权管理中的自启动管理功能就对应了服务的自启动，如果没有开启，则设置了START_STICKY也无法使服务被杀掉后重新启动。
据说微信在MIUI中默认允许自启动是因为和小米签了协议。
Q:为什么小米手机无法显示悬浮窗？
A:类似上一个问题，小米手机所有APP安装之后默认悬浮窗权限也是没有打开的。
Q:为什么stopService后悬浮窗还在屏幕上？
A:stopService之后虽然服务已经停止，但是，服务中为WindowManager添加View的代码却已经执行并且生效。View在屏幕中存在的时间取决于View的Context。
Activity中启动服务后，悬浮窗View的Context与Activity、服务的Context一致，当App被Kill时Context失效，因此刚添加的View在WindowManager中失效。
而自启动的Service中如果在WindowManager中添加视图，视图的Context则与Service的一致，生命周期也与Service一致。
所以，服务是否运行与悬浮窗是否存在是相互独立的，悬浮窗存在与否只取决于其Context。
Q:startService和bindService如何一起使用？
A:想要服务被杀掉后自动启动，必须指定onStartCommand的返回值START_STICKY，必须使用startService的方式启动。
此后想要与服务进行交互，必须执行bindService与服务建立连接。
注意：先start再bind的Service直接stop是无效的。必须执行unBindService程序才会走到onDestroy中。
另：start了START_STICKY的服务再bind后，依然是可以自启动的。
Q:Service的优势？
A:Service被杀掉的次序排在后台进程和空进程的前面，不容易被杀死。
可以指定自动启动，被清理后不影响业务，不像后台进程。
可以执行较耗时的操作，不像BroadCast，只能执行十秒以内的操作。