安卓service关闭后怎么自动重启

Posted 2023-04-28

　　首先申明service关闭有两种情况：
　　1、程序进入后台，系统可能会销毁应用，可以理解为android端监听推送消息的服务在启动后是一直在后台运行的，但是当内存不足时，或者第三方应用清理内存时会杀死后台服务，此时该服务需要自动重启。

　　该问题只需要在推送服务的onStartCommand方法返回类型设置成START_STICKY，官方文档对此的解释是：public static final int START_STICKY = 1;
　　大致意思是，在服务被系统杀死时会重新被创建，onStartCommand方法会被调用，但是需要注意的是，在调用onStartCommand时传入的intent值可能为空，如果该方法中会用到该参数需要特别注意。
　　设置该参数可以解决第三方应用在清理内存时或者内存不足时杀掉推送服务之后重启推送服务。
　　2、服务被用户在应用管理-》正在运行中点击“停止”销毁该服务，服务不能重启。
　　当用户执行该操作时，服务中的onDestory方法被调用。所以我们可以在onDestory方法中再次启动服务。但是此方案不能解决用户在应用管理-》已下载中，强行停止该应用程序时服务被关闭后重启，对比腾讯新闻，同等条件下，该问题也存在，即不能重启服务。 参考技术A 　　Android开发的过程中，每次调用startService(Intent)的时候，都会调用该Service对象的onStartCommand(Intent,int,int)方法，然后在onStartCommand方法中做一些处理。然后我们注意到这个函数有一个int的返回值，这篇文章就是简单地讲讲int返回值的作用。
　　从Android官方文档中，我们知道onStartCommand有4种返回值：
　　START_STICKY：如果service进程被kill掉，保留service的状态为开始状态，但不保留递送的intent对象。随后系统会尝试重新创建service，由于服务状态为开始状态，所以创建服务后一定会调用onStartCommand(Intent,int,int)方法。如果在此期间没有任何启动命令被传递到service，那么参数Intent将为null。

　　START_NOT_STICKY：“非粘性的”。使用这个返回值时，如果在执行完onStartCommand后，服务被异常kill掉，系统不会自动重启该服务。

　　
　　START_REDELIVER_INTENT：重传Intent。使用这个返回值时，如果在执行完onStartCommand后，服务被异常kill掉，系统会自动重启该服务，并将Intent的值传入。

　　START_STICKY_COMPATIBILITY：START_STICKY的兼容版本，但不保证服务被kill后一定能重启。本回答被提问者和网友采纳

解决 CentOS 在 mariadb 数据库服务因某些原因自动关闭后，服务重启的配置方法

解决 CentOS 在 mariadb 数据库服务因某些原因自动关闭后，服务重启的配置方法

一台运行数年的 centos 服务器，发生了一次 解决 mariadb 服务自动关闭的情况。我当时不以为意，直接运行 systemctl start mariadb.service 命令，重启了服务。
但是又过去了几个月，这玩意儿又自动关闭了。不清楚是啥原因，但老这样不是个事儿呀，虽然几个月才发生一次，但是只要发生了，那么运行的 web 服务就产生了影响了。
因此，决定配置上服务关闭后自动重启。

运行 vim /etc/systemd/system/multi-user.target.wants/mariadb.service 命令，在 [Service] 节中增加 Restart=always 参数。如下图所示：

修改配置后，执行 systemctl daemon-reload 重新加载配置文件，然后再执行 systemctl restart mariadb.service 命令重启服务。
然后测试了一下手动杀进程，看看服务有没有自动重启，如下图所示：

可以看到，服务自动重启了，已经换了一个进程号了。
归根结底，还是服务器配置低呀。。。好吧，总算是解决问题了，记录一下。

本文由 FungLeo 原创，允许转载，但转载必须保留首发链接。