android:persistent和android:priority的区别，对进程优先级有什么影响？

天天Lotay

发布于 2024-01-25 08:34:58

3040

发布于 2024-01-25 08:34:58

前言：写的apk因为系统busy给我kill了，(adj 900): kill all background，在AndroidManifest.xml添加android:persistent="true"后，被甲方要求不能这样做，还是得从adj改，把 priority改成1000

android:persistent和android:priority是两个不同的属性，它们分别用于不同的目的。

android:persistent：用于设置应用组件是否具有持久性。当android:persistent设置为true时，表示该组件具有持久性，即使在设备重启后也会保留其状态。而设置为false，则表示该组件不具有持久性，重启后会被销毁。
android:priority：用于设置组件的优先级。这个属性通常用于广播接收器（BroadcastReceiver），可以通过设置android:priority来定义接收广播的顺序和优先级。数值越高表示优先级越高。

这两个属性对进程优先级没有直接的影响。进程优先级是由Android系统动态管理的，根据当前运行的应用程序的活动程度和资源需求来进行调整。系统会根据一些因素（例如用户当前正在与之交互的应用、前台服务等）来确定进程的优先级。

虽然android:priority可以在某种程度上影响广播接收器的执行顺序，但它并不会直接影响进程的优先级。进程的优先级是由系统根据一系列的策略和算法来决定的，而不仅仅取决于某个组件的属性设置。

关于Service保活和提高Android应用中Service组件优先级的方法，可以总结如下：

设置最高优先级：在AndroidManifest.xml文件中，通过设置android:priority属性为较高的值（例如1000）来设置最高优先级。这适用于广播接收器。
使用startForeground()方法：在Service的onStartCommand()方法中调用startForeground()方法，将Service提升为前台进程级别。在Service的onDestroy()方法中记得调用stopForeground()方法。
返回START_STICKY：在Service的onStartCommand()方法中手动返回START_STICKY，以便在Service被系统销毁后能够重新启动。
发送广播重启Service：在Service的onDestroy()方法中发送一个自定义广播，在收到广播后重新启动Service。请注意，这种方式无法保证在第三方应用或系统设置中强制停止应用时能够执行。
监听系统广播判断Service状态：通过监听系统广播，如手机重启、界面唤醒、应用状态改变等，判断Service是否存活。
多个App相互拉活：不同的App之间相互绑定、互相拉活。
设置闹钟定时唤醒：使用AlarmManager设置闹钟，在指定时间周期性地唤醒Service。
开启前台Service：将Service设置为前台Service，提高其优先级。
Service中循环播放无声音频：在Service中循环播放一段无声音频，可以一定程度上提高保活效果，但会增加耗电量。
双进程守护（Android 5.0前有效）：通过启动一个独立的守护进程与主进程相互监控和拉活。
JobScheduler（Android 5.0后引入，8.0后失效）：使用JobScheduler调度任务来定期唤醒Service。
像素Activity保活方案（不推荐）：创建一个透明的1像素Activity，并设置为悬浮窗口，以维持应用的运行。
广播锁屏、自定义锁屏（不推荐）：通过监听锁屏广播或自定义锁屏界面来保活，但这种方式可能对用户体验产生负面影响。
第三方推送SDK唤醒：使用第三方推送SDK的唤醒机制来保活，但需要接入第三方服务。
Native层fork子进程：在native层创建一个子进程并与主进程进行通信，实现互相拉活。
与手机厂商沟通：与手机厂商沟通，将应用放入系统白名单，降低oom_adj值，以确保进程不被系统杀死。
在AndroidManifest.xml中添加Persistent属性：在application节点中添加android:persistent="true"属性，表示应用具有持久性。