android保活,有效的代码保活

公众号:码农乐园 等级 847 0 0
标签: Java

需要APP暗屏情况下进行后台执行一些任务,但是google现在为了优化手机的体验,以及流畅性,做了很多的限制,电量优化,休眠模式,以及进入深度睡眠状态,进入深入休眠状态系统会根据黑白名单的应用进行管理,杀掉非白名单的后台进程以及网络请求;Android系统的优化是守护后台进程造成了很大困扰,线程之间守护已经是不在可靠,使用wakelock耗电过大也会是系统杀掉应用进程。下面就对我们的经历说说守护进程的。

1,从官网上可以看出google为了系统更加流畅以及优化内存,Google做了很大的处理,在手机暗屏或者睡眠状态就停止后台运行;若要保持service的常驻,需要做一些前端的活动,Notification重要属性:notification.flags = Notification.FLAG_NO_CLEAR|Notification.FLAG_ONGOING_EVENT;然后startForeground(setClass().hashCode(), notification);使得服务能挂在通知栏。

2,通过wakelock占用CPU,若一直占用CPU的话,当然这是比较耗电的,要是耗电太高的话系统会直接回收,杀死程序进程。

我是使用定时器唤醒cpu 后台服务将接收到定时任务执行未完成的任务:下面是我实现的代码

在mainfest中注册

关键代码定时任务:

publicvoidstartAlarm(Context context){      
Intent intent =newIntent(context, WakeCPUAlarmReceiver.class);      
alarmIntent = PendingIntent.getBroadcast(context,0, intent,0);      
alarmMgr = (AlarmManager) context .getSystemService(Context.ALARM_SERVICE);//    alarmMgr.set(AlarmManager.ELAPSED_REALTIME_WAKEUP,//          1000, alarmIntent);
if(Build.VERSION.SDK_INT >= Build.VERSION_CODES.M) {   
     alarmMgr.setExactAndAllowWhileIdle(       
       AlarmManager.ELAPSED_REALTIME_WAKEUP,        
      SystemClock.elapsedRealtime() + chekcTime, alarmIntent);    
  }else if(Build.VERSION.SDK_INT >= Build.VERSION_CODES.KITKAT) {  
      alarmMgr.setExact(AlarmManager.ELAPSED_REALTIME_WAKEUP,              SystemClock.elapsedRealtime() + chekcTime, alarmIntent);    
  }else{      
  alarmMgr.set(AlarmManager.ELAPSED_REALTIME_WAKEUP,             
 SystemClock.elapsedRealtime() + chekcTime, alarmIntent);    
  }     
 FileLogUtil.e(TAG ,"startAlarm 设置定时任务");  }

接收到定时任务:

publicclassWakeCPUAlarmReceiverextendsWakefulBroadcastReceiver{
privateAlarmManageralarmMgr;
privatePendingIntentalarmIntent;
privatefinallong chekcTime =30*1000;    
public static boolean isCheckFlag =false;
privatestaticStringTAG=WakeCPUAlarmReceiver.class.getSimpleName();
@Override
public void onReceive(Contextcontext,Intentintent) {
// TODO Auto-generated method stub
Intentservice =newIntent(context,WakecpuIntentService.class);
FileLogUtil.e(TAG,"onReceive 接收定时任务");          
startWakefulService(context, service);  
}

在service中执行需要执行的任务:

public class WakecpuIntentService extends IntentService{
private static String TAG=WakecpuIntentService.class.getSimpleName() +" :";
private NotificationManager mNotificationManager;
private PowerManager.WakeLockwl;
NotificationCompat.Builderbuilder;  
public WakecpuIntentService() {
super("WakecpuIntentService");
// TODO Auto-generated constructor stub
}
@Override
protected void onHandleIntent(Intentintent) {
// TODO Auto-generated method stubBundle
extras = intent.getExtras();
FileLogUtil.e(TAG,"Service接收到WakeLock定时任务。");
PollService.startService(getApplicationContext());
FileLogUtil.e(TAG,"Service接收到WakeLock定时任务在定时任务中启动轮询Service。");
// Do the work that requires your app to keep the CPU running.
// Release the wake lock provided by the WakefulBroadcastReceiver.
//checkScreenOff();
WakeCPUAlarmReceiver.completeWakefulIntent(intent);//释放wake
WakeCPUAlarmReceiver.setCheckFlag(false);
WakeCPUAlarmReceivermAlarmReceiver =newWakeCPUAlarmReceiver();      
mAlarmReceiver.startAlarm(WakecpuIntentService.this);
FileLogUtil.e(TAG,"Service释放wakelock后设置定时任务。");  
    }
}

service在后台也能够打印log 保持一直执行,最重要的是不耗电也不会卡机的问题。欢迎大家一起讨论学习。 关注公众号获取更多干货 android保活,有效的代码保活

收藏
评论区

相关推荐

Android 内存管理机制
前言:Android系统是基于Linux内核开发的操作系统,而Linux系统有其独到的内存管理机制,会在进程活动停止后结束该进程。Android在此基础上优化了内存管理,会把进程都保存在内存中,直到系统需要更多内存为止,释放部分进程。这些被保存在内存中的进程,并不会影响系统的运行速度,相反,在重新打开这些进程时,会提升进程启动速度 Android 内存管
android保活,有效的代码保活
需要APP暗屏情况下进行后台执行一些任务,但是google现在为了优化手机的体验,以及流畅性,做了很多的限制,电量优化,休眠模式,以及进入深度睡眠状态,进入深入休眠状态系统会根据黑白名单的应用进行管理,杀掉非白名单的后台进程以及网络请求;Android系统的优化是守护后台进程造成了很大困扰,线程之间守护已经是不在可靠,使用wakelock耗电过大也会是系统杀
Compose Weekly #1: 小狗领养应用
本文同步发表于我的微信公众号,在微信搜索 OpenCV or Android 即可关注。 前言 最近Android官方发起了Jetpack Compose的推广活动:Jetpack Compose开发者挑战赛。活动时间一个月,每周一题,广大开发者根据官方需求,Clone官方模板工程并使用Jetpack Compose技术结题后按要求提交,即可参与活动。
深度剖析APP保活案例
这是作者在去年处理的一个关于进程保活的案例一. 引言 1.1 保活概述什么是保活?保活就是在用户主动杀进程,或者系统基于当前内存不足状态而触发清理进程后,该进程设法让自己免于被杀的命运或者被杀后能立刻重生的手段。保活是”应用的蜜罐,系统的肿瘤“,应用高保活率给自己赢得在线时长,甚至做各种应用想做而用户不期望的行为,给系统带来的是不必要的耗电,以及系统额外的性
DeDeCMS v5.7 SP2 正式版 前台任意用户密码修改
写在前面 学了这么久了回过头来一看,这居然是我自己复现的第一个漏洞,哪怕是之前打 hvv 的时候都是百度到了就用,没有进行深入的研究,刚好这回网络渗透测试课安排了复现漏洞的任务,所以水一篇博客记录一下,以后有时间了也得搭环境复现一下其他的洞 漏洞简介+ 在用户密码重置功能处,php 代码存在弱类型比较,如果用户没有设置密保问题,可以直接绕过验证密保问题,直接
JUC
Java 5.0 在 java.util.concurrent 包中提供了多种并发容器类来改进同步容器 的性能。 =========================================================== * CountDownLatch 一个同步辅助类,在完成一组正在其他线程中执行的操作 之前,它允许一个或多个线程一
Activity的启动方式和flag详解
**Activity的4种状态:** **活动的**:当一个Activity在栈顶,它是可视的、有焦点、可接受用户输入的。Android试图尽最大可能保持它活动状态,杀死其它Activity来确保当前活动Activity有足够的资源可使用。当另外一个Activity被激活,这个将会被暂停。 **暂停**:在很多情况下,你的Activity可视但是它没有焦
android保存文件到手机内存
首先要指定文件保存的位置,在Java中,我们可以直接使用 Filefile=new File(“info.txt”),但是在Android中,使用这个路径文件会被保存到data/app文件夹(应用程序根目录)下,Android是不允许在这里保存文件的。Android保存文件都是保存在“data/data/包名”文件夹下的。故应该: Filefile=ne
2020年了,Android后台保活还有戏吗?看我如何优雅的实现!
1、引言 ======= 对于移动端IM应用和消息推送应用的开发者来说,Android后台保活这件事是再熟悉不过了。 自从Android P(即Android 8.0)出现以后,Android已经从系统层面将后台保活这条路给堵死了(详见:《[Android P正式版即将到来:后台应用保活、消息推送的真正噩梦](https://www.oschina
2020年了,Android后台保活还有戏吗?看我如何优雅的实现!
1、引言 ======= 对于移动端IM应用和消息推送应用的开发者来说,Android后台保活这件事是再熟悉不过了。 自从Android P(即Android 8.0)出现以后,Android已经从系统层面将后台保活这条路给堵死了(详见:《[Android P正式版即将到来:后台应用保活、消息推送的真正噩梦](https://www.oschina
Android P正式版即将到来:后台应用保活、消息推送的真正噩梦
1、前言 ==== 对于广大Android开发者来说,Android O(即Android 8.0)还没玩热,Andriod P(即Andriod 9.0)又要来了。 ![](https://upload-images.jianshu.io/upload_images/1500839-bb004a3b7fb25eed.jpeg?imageMogr2/au
Android保活从入门到放弃:乖乖引导用户加白名单吧
1、引言 ==== IM在Android上的保活问题经常在即时通讯网的论坛和技术群里被讨论,自从Android 8.0后系统大大降低了后台运行应用的保活容忍度(详见《[Android P正式版即将到来:后台应用保活、消息推送的真正噩梦](https://www.oschina.net/action/GoToLink?url=http%3A%2F%2Fwww
Android保活从入门到放弃:乖乖引导用户加白名单吧(附7大机型加白示例)
1、引言 ======= IM在Android上的保活问题经常在即时通讯网的论坛和技术群里被讨论,自从Android 8.0后系统大大降低了后台运行应用的保活容忍度(详见《[Android P正式版即将到来:后台应用保活、消息推送的真正噩梦](https://www.oschina.net/action/GoToLink?url=https%3A%2
Android后台保活实践总结:即时通讯应用无法根治的“顽疾”
**前言** ====== Android进程和Service的保活,是困扰Android开发人员的一大顽疾。因涉及到省电和内存管理策略,各厂商基于自家的理解,在自已ROOM发布于都对标准Android发行版作为或多或少的改动,使得应用层程序在处理进程和Service保活问题上变的异常复杂,且很难兼容,因为说不定哪款手机或者哪个版本的省电策略发生改变,那么