先把结论放在前面：bindService的核心不是"启动服务"，而是"建立一个跨进程的连接"。服务端在onBind里返回一个 Binder 对象的代理会经 Binder 驱动传到客户端，客户端拿到它之后所有方法调用都在 Binder 线程池里执行，不在主线程。因此"onBind 里做什么"决定了服务的启动成本，"onServiceConnected 里做什么"决定了业务的正确性。面试里这题属于"高频但容易答浅"。答得浅的是"bindService用来绑定服务，unbindService解绑"；答得深的是能讲清BIND_AUTO_CREATE与服务生命周期的关系、绑定计数归零才销毁、同一进程短路不需要 Binder、以及onServiceDisconnected与主动解绑的语义差别。完整链路客户端 服务端 bindService(intent, conn, flags) │ → AMS.bindService(...) │ ① 按 Intent 解析目标 Service（考虑进程是否存在） │ ② 目标进程不存在 → 先拉起进程（可能走 startService 的创建路径） │ ③ ActiveServices 记录一条 ConnectionRecord（含 binder、flags、调用方 uid） │ ④
