实现Service.onStartCommand是否会自动将绑定服务置为启动状态？

仅实现onStartCommand()方法，完全不会在客户端调用bindService()时自动将服务置为启动状态。你之前验证的「先调用startService()再调用bindService()」是满足需求的唯一标准方案。

你看到的文档表述很容易让人误解，它的实际逻辑和“重写方法就改变服务模式”没有任何关系：

• Android系统对服务的启动状态、绑定状态是分开标记的，两个状态完全独立。只有服务接收到startService()调用时，才会被打上启动状态标记，这个逻辑和你是否重写onStartCommand()没有关联。
• 文档中“实现onStartCommand()就必须显式停止服务”的描述，有个未明说的前提：服务已经通过startService()真正进入了启动状态。这种场景下，无论是否有客户端绑定，服务都会持续运行，必须主动调用stopSelf()或其他组件调用stopService()才能销毁。
• 如果服务从来没有被startService()启动过，哪怕你写了完整的onStartCommand()实现，纯靠bindService()拉起的服务依然属于纯绑定模式，当所有客户端解绑后，系统会直接销毁服务，和你没重写onStartCommand()的表现完全一致。实测从API 21到API 34的所有官方版本，纯bindService()流程都不会触发onStartCommand()回调。

你目前采用的先调用startService()再调用bindService()的写法，是官方推荐的双模式服务实现，没有更简便的捷径，实操时注意几个点即可：

• 重复调用startService()不会重复创建服务实例，只会多次触发onStartCommand()回调，只要在回调里做好逻辑幂等处理，就不会有额外问题。
• 如果不需要服务在所有客户端解绑后继续后台运行，可以在onUnbind()生命周期回调里主动调用stopSelf()，避免服务空跑造成不必要的耗电。
• 不要尝试通过反射或者其他非公开API修改服务的启动状态标记，这类实现会在不同系统版本上出现兼容性问题，不推荐使用。

内容的提问来源于stack exchange，提问作者user19309143