一、Service没有界面的长跑选手如果说 Activity 是用户能看到的页面那么 Service 就是看不见的长跑选手——它在后台默默工作不与用户直接交互。它适合执行那些用户不需要直接看着、又要持续一段时间的任务比如播放音乐、上传下载、与远程服务保持连接等。一个最简单的 Service 长这样classMyService:Service(){overridefunonCreate(){super.onCreate()// 服务被创建时调用一次}overridefunonStartCommand(intent:Intent?,flags:Int,startId:Int):Int{// 每次有人调用 startService 都会进来returnSTART_STICKY}overridefunonBind(intent:Intent):IBinder?null}注意每个 Service 也要在AndroidManifest.xml中注册否则系统找不到它。serviceandroid:name.MyService/Service 误区新手对于 Service 最大的误区是把它当成自动开线程的后台进程。Service 不是独立进程默认与启动它的 Activity / ContentProvider 跑在同一个进程里共享同一片内存。只有当service标签上显式声明android:process:xxx时它才会跑在新进程中。Service 不是独立线程它的所有回调onCreate/onStartCommand/onBind/onDestroy都跑在主线程。在onStartCommand里直接做网络请求、文件 IO照样会卡死主线程、触发 ANR。要避免 ANR必须自己开子线程或直接用内置工作线程的IntentService/JobIntentService。一句话总结Service 是一个有生命周期、受系统照顾的主线程对象而不是后台线程或后台进程。二、Service 提供的两种能力Service 本身非常简单主要给应用两件事能力启动方式用途后台执行任务Context.startService(intent)告诉系统我要在后台干一阵活被其他组件调用Context.bindService(...)像一个远程对象那样暴露功能给别人调用这两种方式可以单独使用也可以同时使用——这正是理解 Service 生命周期的关键。三、生命周期Service 的一生Service有两条启动路径startService(intent) bindService(intent, conn, flag) │ │ ▼ ▼ onCreate() ◀──── 仅在首次创建时调用一次 ────▶ onCreate() │ │ ▼ ▼ onStartCommand() onBind() ── 返回 IBinder │ │ │ ▼ │ 客户端 onServiceConnected │ │ ▼ ▼ (持续运行) (持续运行) │ │ ▼ ▼ stopSelf() / stopService() 所有客户端 unbindService │ │ └─────────────► onDestroy() ◄────────┘如果一个 Service 同时被startService启动并被bindService绑定它只有在两者都不成立时才会被销毁。所有清理工作停线程、注销监听必须在onDestroy()返回前完成。四、onStartCommand 的四种返回值onStartCommand()的返回值告诉系统如果你因为内存紧张杀了我的进程稍后回过神来该怎么处理我返回值被杀后的行为适用场景START_STICKY系统重建 Service再次调onStartCommand但 Intent 为null像音乐播放器这种服务本身要一直跑、原始命令不重要的情况START_NOT_STICKY系统不会重建除非又有人显式startService一次性任务做完就完START_REDELIVER_INTENT系统重建 Service并原封不动重投上次未完成的 Intent任务必须完成下载、上传命令不能丢START_STICKY_COMPATIBILITY兼容版本几乎不用—五、本地服务示例与客户端在同一进程Service 与你的 Activity 跑在同一个 APK、同一个进程里。这种情况下不需要 IPC可以把 Service 当成普通对象来用。5.1 Service 端暴露一个自定义 BinderclassLocalService:Service(){privatevalbinderLocalBinder()/** 内部类用来暴露 Service 自身。 */innerclassLocalBinder:Binder(){// 返回外层 LocalService 这个实例不是类fungetService():LocalServicethisLocalService}overridefunonBind(intent:Intent):IBinderbinder/** 业务方法。 */fungetRandomNumber():Int(0..100).random()}**thisLocalService**是 Kotlin 的限定 this语法。在inner class里直接写this指的是内部类自己要指代外层 Service 实例就得写thisLocalService返回的是当前这个LocalService 的实例对象。5.2 客户端拿到 IBinder 强转回具体类classLocalServiceActivity:AppCompatActivity(){privatevarservice:LocalService?nullprivatevarbound:Booleanfalseprivatevalconnectionobject:ServiceConnection{overridefunonServiceConnected(name:ComponentName,binder:IBinder){// 同进程可以直接强转vallocalBinderbinderasLocalService.LocalBinder servicelocalBinder.getService()boundtrue}overridefunonServiceDisconnected(name:ComponentName){servicenullboundfalse}}overridefunonStart(){super.onStart()Intent(this,LocalService::class.java).also{intent-bindService(intent,connection,Context.BIND_AUTO_CREATE)}}overridefunonStop(){super.onStop()if(bound){unbindService(connection)boundfalse}}funonButtonClick(){if(bound){valnumservice?.getRandomNumber()Toast.makeText(this,number:$num,Toast.LENGTH_SHORT).show()}}}5.3 需要注意的点bindService是异步的调完它并不会立刻拿到 Service要等系统回调onServiceConnected。所以才需要bound这个开关和一个可空的service字段。Service 实例是由 Android框架创建的你 Activity 根本没机会拿到它——getService()是从 binder 这一头反向取回外层 Service 实例的唯一桥梁。onStart绑 /onStop解是 Google 推荐的配对因为 Activity 在onStop之后用户已经看不见了没必要继续占着 Service。unbindService不会触发onServiceDisconnected那个回调只在异常断开时调用所以要手动置bound false。Context.BIND_AUTO_CREATE告诉系统如果 Service 还没活着就帮我创建它。没有这个 flagService 不存在时绑定会失败。六、远程信使服务跨进程通信如果 Service 跑在另一个进程里或者你想让它对外提供服务就需要走 IPC。AIDL 是终极方案但要写额外文件如果通信只是发消息这种粒度用Messenger会轻量得多。6.1 前置知识6.1.1 Android 的线程间消息通信机制类角色通俗解释Looper“传送带电机”每条想接收消息的线程要先有一个 Looper不停地从MessageQueue里取消息MessageQueue“传送带本体”存放待处理 Message 的队列Handler“投递员 收件人”你用它把消息丢进队列并提供handleMessage(msg)处理派发回来的消息Message“消息包裹”携带what/arg1/2/obj/data(Bundle) /replyToMessengerHandler 的跨进程封装内部用 Binder IPC 把 Message 序列化送到对端 Handler6.2 Service 端暴露一个 HandlerclassMessengerService:Service(){companionobject{constvalMSG_SAY_HELLO1}/** 接收客户端消息的 Handler跑在主线程。 */internalclassIncomingHandler(context:Context,privatevalapplicationContext:Contextcontext.applicationContext):Handler(Looper.getMainLooper()){overridefunhandleMessage(msg:Message){when(msg.what){MSG_SAY_HELLO-Toast.makeText(applicationContext,hello!,Toast.LENGTH_SHORT).show()else-super.handleMessage(msg)}}}privatelateinitvarmessenger:MessengeroverridefunonBind(intent:Intent):IBinder{messengerMessenger(IncomingHandler(this))returnmessenger.binder// 真正穿越进程边界的载体}}6.3 让它跑在远程进程在 Manifest 里加android:process加冒号前缀表示附加在我自己包名后面的私有进程serviceandroid:name.MessengerServiceandroid:process:remote/冒号前缀:是约定写法名字本身remote可以随便取。6.4 客户端用 Messenger 包装跨进程 IBinderclassMessengerActivity:AppCompatActivity(){privatevarservice:Messenger?nullprivatevarbound:Booleanfalseprivatevalconnectionobject:ServiceConnection{overridefunonServiceConnected(name:ComponentName,binder:IBinder){// 跨进程不能强转为具体类必须用 Messenger 包装serviceMessenger(binder)boundtrue}overridefunonServiceDisconnected(name:ComponentName){servicenullboundfalse}}funsayHello(v:View){if(!bound)returnvalmsgMessage.obtain(null,MessengerService.MSG_SAY_HELLO,0,0)try{service?.send(msg)}catch(e:RemoteException){e.printStackTrace()}}overridefunonStart(){super.onStart()Intent(this,MessengerService::class.java).also{bindService(it,connection,Context.BIND_AUTO_CREATE)}}overridefunonStop(){super.onStop()if(bound){unbindService(connection)boundfalse}}}七、权限7.1 静态权限保护在service标签上声明权限其他应用要启动/绑定它就必须uses-permission对应权限serviceandroid:name.PrivateServiceandroid:permissioncom.example.permission.USE_MY_SERVICE/7.2 临时授予 URI 权限调用startService(intent)时可以在 Intent 上加valintentIntent(this,ProcessService::class.java).apply{dataUri.parse(content://com.a.provider/pic/1)addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION)addFlags(Intent.FLAG_GRANT_WRITE_URI_PERMISSION)}startService(intent)这两个 Flag 保护的不是 Service而是 URI 指向的数据。系统会临时、只针对该 URI把读/写权限借给被启动的 Service绕过 ContentProvider 自身的权限和exported限制直到 Service 调用stopSelf(startId)或被销毁。这是 Android 权限模型中的细粒度临时授权机制。7.3 单次 IPC 调用的权限校验Service 可以在某次 IPC 调用的实现里调checkCallingPermission()检查调用方权限决定是否拒绝。八、进程优先级只要一个 Service 处于已启动或被绑定状态承载它的进程优先级会按以下顺序中最高那一档计算优先级条件前台进程正在执行onCreate/onStartCommand/onDestroy代码前台进程调用了startForeground(id, notification)对用户可感知可见进程下一级处于已启动状态——比不可见进程重要但比可见 Activity 低取决于客户端被绑定时重要性不低于最重要的客户端重要认知长时间运行的后台 Service几乎一定会在某个时刻被系统杀掉再重启。所以不要在 Service 里假设自己永远活着——状态要能恢复真正持续可感知的任务音乐播放、定位请用startForeground 通知提升到前台优先级异步任务配合START_FLAG_REDELIVERY避免命令丢失bindService时可以通过 flag 调整客户端对 Service 优先级的影响BIND_ABOVE_CLIENT/BIND_ALLOW_OOM_MANAGEMENT/BIND_WAIVE_PRIORITY/BIND_IMPORTANT/BIND_ADJUST_WITH_ACTIVITY。参考来源Android 官方文档 - Service