手机休眠被唤醒后timer还继续执行吗

转自:https://zhidao.baidu.com/question/1383642695464417020.html

前段时间在工作的时候碰见一个问题,就是要待机时在设定的时间内执行操作,开始并没有意识到问题的严重,后来尝试很多办法没有成功,最后也是在网上找到解决办法,在此稍作总结,希望能对大家有所帮助,不足之处还望大家指正。
1Android中的handler、timer、thread、在待机时都会停止运行,所设定的时间会在待机结束后继续计算。所以如果想在Android待机时运行某些操作,使用以上几种方法是不可行的。
2Android中有一个Alarmmanager对象,可以使用该对象执行待机时的操作。具体设置的方法如下:
2.1设置闹铃的类型
AlarmManager.RTC,硬件闹钟,不唤醒手机(也可能是其它设备)休眠;当手机休眠时不发射闹钟。
AlarmManager.RTC_WAKEUP,硬件闹钟,当闹钟发躰时唤醒手机休眠;
AlarmManager.ELAPSED_REALTIME,真实时间流逝闹钟,不唤醒手机休眠;当手机休眠时不发射闹钟。
AlarmManager.ELAPSED_REALTIME_WAKEUP,真实时间流逝闹钟,当闹钟发躰时唤醒手机休眠;
AlarmManager.POWER_OFF_WAKEUP:能唤醒系统,他是一种关机闹铃,就是说设备在关机状态下也可以唤醒系统,所以我们把它称为关机闹铃。
RTC闹钟和ELAPSED_REALTIME最大的差别就是前者可以通过修改手机时间触发闹钟事件,后者要通过真实时间的流逝,即使在休眠状态,时间也会被计算。
2.2设置闹铃的开始时间
如果使用ELAPSED_REALTIME或者ELAPSED_REALTIME_WAKEUP类型应该调用SystemClock.elapsedRealtime()获取相对时间在加上你设定的延迟时间
如果使用RTC或者RTC_WAKEUP类型应该调用System.currentTimeMillis()获取从1970.1.1号以来的时间在加上你设定的延迟时间
2.3pendingintent
一个PendingIntent对象,表示到时间后要执行的操作。PendingIntent与Intent类似,可以封装Activity、BroadcastReceiver和Service。
但与Intent不同的是,PendingIntent可以脱离应用程序而存在。

接触Android没几天,不太了解。
本来写好的一个应用在无意中发现,待机的时候,应用中的一个线程停止了运行。
这个线程是每隔一分钟上传一个数据到服务器上。
我当时测试的时候,没想过待机(接开关键)下的情况是怎样的,现在发现,只要手机一进入待机状态,这个线程就停止工作了。
不过有一个奇怪的现象,因为我的应用中同时启动了三个线程。
一个负责每隔一分钟上传一个数据,当待机的时候,这个线程暂停运行,当手机不待机的时候,马上复活。
一个负责接收服务器发过来的UDP数据包,这个线程倒是不受待机的影响,当有数据来的时候,可以正常处理。
难道是因为datagramSocket.receive(datagramPacket);阻塞的原因?
public void run()
{
while(true)
{
datagramSocket.receive(datagramPacket); //阻塞
}
}

到网上搜索了一下,看到别人说的:
实验1:使用Java.util.Timer
当连接USB线进行调试时,会发现一切工作正常,每5秒更新一次界面,即使是按下电源键,仍然会5秒触发一次。
当拔掉USB线,按下电源键关闭屏幕后,过一段时间再打开,发现定时器明显没有继续计数,停留在了关闭电源键时的数字。

实验2:使用AlarmService:
2.1通过AlarmService每个5秒发送一个广播,setRepeating时的类型为AlarmManager.ELAPSED_REALTIME。
拔掉USB线,按下电源键,过一段时间再次打开屏幕,发现定时器没有继续计数。
2.2setRepeating是的类型设置为AlarmManager.ELAPSED_REALTIME_WAKEUP
拔掉USB线,按下电源键,过一点时间再次打开屏幕,发现定时器一直在计数。

如此看来,使用WAKEUP才能保证自己想要的定时器一直工作,但是肯定会引起耗电量的增加。

我最后自已写了一个Service类,然后使用AlarmService每隔一分钟执行一次,在待机的时候也能正常运行。

### NXP S32K3 MCU 中的睡眠唤醒与复位实现 #### 睡眠模式和唤醒机制 S32K3 微控制器提供了多种低功耗模式,这些模式可以通过 MCAL 层中的 `Pmu_SetMode` 函数来配置。具体来说,PMU(Power Management Unit)模块负责管理电源状态转换以及进入不同的低功耗模式。 为了使设备能够从睡眠模式中唤醒,通常需要配置中断源或者外部事件触发器。这一步骤可以在初始化阶段完成,通过调用 `Gpt_Init` 和 `Wdg_Driver_Init` 来启用定时器或看门狗作为唤醒源[^1]。 ```c // 配置 PMU 进入低功耗模式 void EnterLowPowerMode(void) { Pmu_LowPowerConfigType lowPowerConf; // 设置为 STOP 模式或其他合适的模式 lowPowerConf.mode = PMU_STOP_MODE; lowPowerConf.wakeupSource = WAKEUP_PIN | WAKEUP_TIMER; // 应用配置并切换到指定模式 Pmu_SetMode(&lowPowerConf); } ``` 当退出低功耗模式时,MCU 将自动恢复至常运行状态,并继续执行之前保存的任务上下文。需要注意的是,在某些情况下可能还需要重新初始化外设以确保一致性。 #### 复位原因检测与处理 对于复位操作而言,NXP 提供了一个标准 API —— `Mcu_GetResetReason()`,用于获取最近一次导致系统重启的原因代码。此函数内部会读取 RGM 寄存器组内的 DES 字段值,并将其清零以便后续查询不会重复返回相同的结果[^2]。 如果应用程序希望保留原始 reset flags,则应在调用该方法前先手动备份相关寄存器内容;否则一旦执行完毕后便无法再访问初始状态下的 flag 值了。此外,还应注意 FRET/DRET 参数的作用范围仅限于软件层面定义的行为逻辑而非实际硬件行为本身。 以下是关于如何安全地实施上述过程的一个简单例子: ```c #include "Mcal_Mcu.h" uint8_t GetAndClearResetFlags(void){ uint8_t resetFlagsBackup; // Backup current reset reason before clearing it. resetFlagsBackup = Mcu_ReadRawResetRegister(); // Clear the reset register as per standard procedure. Mcu_GetResetReason(); return resetFlagsBackup; } int main(){ uint8_t lastResetCause = GetAndClearResetFlags(); if(lastResetCause & RESET_CAUSE_POWER_ON){ SystemInitializeAfterPOR(); } ... } ``` 以上代码片段展示了怎样在不影响原有功能的前提下扩展额外的信息记录能力,从而帮助诊断潜在问题所在位置。 #### 数据存储优化策略 最后提到的一点是如何有效地把变量分配给 RAM 并隐藏其二进制镜像形式以防泄露敏感信息。可以借助 linker script 定义特定 section 名称并将目标对象显式放置其中[^3]。接着利用编译选项 `-Xlinker --gc-sections` 移除未使用的 sections 达成最终目的。 例如: ```ld SECTIONS{ .ram_data : { *(.data_ram*) } > SRAM } ``` 配合 C 文件声明如下即可生效: ```c __attribute__((section(".data_ram"))) int secretKey[] = {...}; ``` ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值