Android系统原生应用解析之桌面闹钟及相关原理应用之时钟任务的应用(二)

本文涉及的产品
全局流量管理 GTM,标准版 1个月
公共DNS(含HTTPDNS解析),每月1000万次HTTP解析
云解析 DNS,旗舰版 1个月
简介: 这篇文章主要针对http://android.xsoftlab.net/training/scheduling/alarms.html#tradeoffs中的Scheduling Repeating Alarms一文进行大体翻译:Alarms(基于AlarmManager类)可以使你的应用在正常的生命周期之外执行基于时间的任务。

这篇文章主要针对http://android.xsoftlab.net/training/scheduling/alarms.html#tradeoffs中的Scheduling Repeating Alarms一文进行大体翻译:

Alarms(基于AlarmManager类)可以使你的应用在正常的生命周期之外执行基于时间的任务。举个例子,你可以使用Alarm去创建一个长时间的任务,比如说每天启动一个服务来下载天气预报。


Alarms拥有以下特征:

  • 它允许你设置一个Intent在固定的时间或者时间段执行。
  • 你可以用它们和广播进行结合来启动服务去执行其它操作。
  • 它们可以在你的应用程序之外进行操作任务,所以你可以在你的应用没有启动的时候,使用它们去触发任务或者执行任务,甚至是设备在休眠状态时。
  • 它们可以帮助减小你应用资源的需求,你可以在不依赖定时器的情况下安排任务或者连续运行后台任务。

懂得权衡:

在相对有限的应用范围,一个可以执行重复任务的闹钟可以相对简单的解释其原理,它可能对你的应用来说不是一个好的选择,特别是当你需要用它来去执行一个网络任务时。一个不好的设计会导致设备的电量快速消耗并导致服务器很频繁的处于负载状态。
一个常见的触发任务的场景便是在你应用的生命周期之外去与服务器进行数据同步,这种情况下你可能想尝试用重复的时钟任务来完成,但是如果你拥有自己的服务器你就可以通过GCM和Sync Adapter结合来完成这个任务,它可能比AlarmManager效果更好。

权衡练习:

每一种基于时钟的任务设计都可能会导致系统资源被滥用,举个例子,有一个非常受欢迎的有数据同步功能的App,如果这个数据同步操作都在每天晚上11点钟进行,那么去被连接的服务器可能会一直处于高负载状态,甚至是服务器挂掉,请在使用时钟功能时遵循以下原则:

  • 将时钟任务的触发时间使用随机条件上下浮动以下,不要聚集在一个时间点。
    • 1 . 当时钟任务触发时,要先处理一下本地任务,本地任务是指任何不与服务器产生交互的任务。
    • 2 . 在同一时间,需要在一个相同时间间隔周期的基础之上执行基于时钟任务的网络请求。
  • 保证使时钟任务的频率降到最低,最好一天一次。越低越好。
  • 不要在不必要的情况下唤醒设备。
  • 尽可能的避免使用你自己的时钟任务管理器。

设置一个时钟任务:

基于上面的描述,时钟任务对有规律执行事件或者数据查询的事情来说是最好的选择,时钟任务拥有以下特性:

  • 时钟类型,具体请查看下文中的 关于时钟类型的选择。
  • 触发时间,如果你设置了过去的时间,那么闹钟任务就会立即执行。
  • 时钟间隔,比如每一天,每一个小时,每5秒等等。
  • 一个Pending Intent,它可以在时钟任务在触发时被调用,如果你在几秒钟之内设置了相同的Pending Intent,那么前一个会被后一个任务顶掉。


关于选择时钟类型

第一个需要考虑的就是时钟的触发类型了。
这里有两种方式供你选择:一种是相对时间,一种是真实的时间。相对时间就是基于系统启动的时间间隔,真实的时间就是说每天的几点几点。这个的意思就是说,相对时间适合用来做基于过去的时间任务(举个例子,比如说每过30秒执行一次任务),它不受时区的影响。而真实时间它比较适合去执行基于真实世界时间的任务。

每一种选择都都唤醒的功能,也就是说它可以在屏幕关闭的情况下唤醒CPU继续起来干活,它确保了时钟任务可以在被设定的时间呗执行,如果你的App对时间有依赖的情况下特别有用,举个例子,它可以有个小窗口可以使用户进行操作,如果你不使用唤醒的功能,那么所有的时钟任务将会在你的设备下次被打开的时候一起蹦出来。

如果你只是简单的需要每过一段时间就去执行一段时钟任务,(比如每半个小时),那么相对时间就非常适合你。

如果你需要在每一天的固定时间执行一个时钟任务,那么选择一种基于真实时间的闹钟类型,注意,无论如何,这种途径会有一些小缺点,比如APP可能会在不同的时区效果不同,如果用户自己改变了设备的系统时间,那么就可能使你的应用出现一些异常,正如上面所讨论的,使用真实时间可能伸缩性不强。我们还是推荐你尽可能的使用相对时间。

以下是类型种类:

  • ELAPSED_REALTIME 设定一个基于时间量的Pending Intent,这个时间量是从系统启动时开始计算的,不过它不会唤醒设备,相对时间还包括设备在睡眠状态下的时间。
  • ELAPSED_REALTIME_WAKEUP 这个和上面基本相同,都是基于开机时间的,不过它会在时间到达时唤醒设备。
  • RTC 这个是基于真实时间的,不过它不会唤醒设备
  • RTC_WAKEUP 这个也基于真实时间的,不过它会在时钟任务被触发的时候唤醒设备。

接下来使用ELAPSED_REALTIME_WAKEUP类型举个例子:


这个例子会在系统启动之后30分钟之后启动一个任务,并且在随后的每30分钟之后都会再次启动。

// Hopefully your alarm will have a lower frequency than this!
alarmMgr.setInexactRepeating(AlarmManager.ELAPSED_REALTIME_WAKEUP,
        AlarmManager.INTERVAL_HALF_HOUR,
        AlarmManager.INTERVAL_HALF_HOUR, alarmIntent);

这个例子会在系统启动一分钟之后启动一个时钟任务,并且会唤醒设备,不过它只会执行一次。

private AlarmManager alarmMgr;
private PendingIntent alarmIntent;
...
alarmMgr = (AlarmManager)context.getSystemService(Context.ALARM_SERVICE);
Intent intent = new Intent(context, AlarmReceiver.class);
alarmIntent = PendingIntent.getBroadcast(context, 0, intent, 0);
alarmMgr.set(AlarmManager.ELAPSED_REALTIME_WAKEUP,
        SystemClock.elapsedRealtime() +
        60 * 1000, alarmIntent);

接下来使用RTC_WAKEUP类型举个例子:

在每天下午接近两点的时候去执行一个任务,并唤醒设备,它并且会在每天的这个时间重复执行。

// Set the alarm to start at approximately 2:00 p.m.
Calendar calendar = Calendar.getInstance();
calendar.setTimeInMillis(System.currentTimeMillis());
calendar.set(Calendar.HOUR_OF_DAY, 14);
// With setInexactRepeating(), you have to use one of the AlarmManager interval
// constants--in this case, AlarmManager.INTERVAL_DAY.
alarmMgr.setInexactRepeating(AlarmManager.RTC_WAKEUP, calendar.getTimeInMillis(),
        AlarmManager.INTERVAL_DAY, alarmIntent);

这个例子是在每天8点半的时候执行一个任务,并且唤醒设备,接着它会在接下来的每20分钟后执行一次。

private AlarmManager alarmMgr;
private PendingIntent alarmIntent;
...
alarmMgr = (AlarmManager)context.getSystemService(Context.ALARM_SERVICE);
Intent intent = new Intent(context, AlarmReceiver.class);
alarmIntent = PendingIntent.getBroadcast(context, 0, intent, 0);
// Set the alarm to start at 8:30 a.m.
Calendar calendar = Calendar.getInstance();
calendar.setTimeInMillis(System.currentTimeMillis());
calendar.set(Calendar.HOUR_OF_DAY, 8);
calendar.set(Calendar.MINUTE, 30);
// setRepeating() lets you specify a precise custom interval--in this case,
// 20 minutes.
alarmMgr.setRepeating(AlarmManager.RTC_WAKEUP, calendar.getTimeInMillis(),
        1000 * 60 * 20, alarmIntent);


下面是如何取消时钟任务的例子:

// If the alarm has been set, cancel it.
if (alarmMgr!= null) {
    alarmMgr.cancel(alarmIntent);
}


以下是当系统启动时如何启动一个时钟任务的方式(同时也可以作为开机启动任务的一种方法):

默认情况下,在系统关机状态下时所有的时钟任务都被取消执行,为了预防这种情况发生,你可以选择在设备重启的时候自动的重新启动时钟任务,这可以确保在用户不需要手动重启的闹钟任务的情况下通过AlarmManager继续执行任务。

以下是实现步骤:

  • 1.在你程序的Manifest文件中设置开机启动权限RECEIVE_BOOT_COMPLETED,它可以使你在系统启动完成之后接受到一个 ACTION_BOOT_COMPLETED的广播,不过这种情况仅限于用户已经启动过你的程序了。
<uses-permission android:name="android.permission.RECEIVE_BOOT_COMPLETED"/>
  • 2.实现一个广播接收器:
public class SampleBootReceiver extends BroadcastReceiver {
    @Override
    public void onReceive(Context context, Intent intent) {
        if (intent.getAction().equals("android.intent.action.BOOT_COMPLETED")) {
            // Set the alarm here.
        }
    }
}
  • 3.在你的广播接收器的中静态添加Intent过滤器:
<receiver android:name=".SampleBootReceiver"
        android:enabled="false">
    <intent-filter>
        <action android:name="android.intent.action.BOOT_COMPLETED"></action>
    </intent-filter>
</receiver>


这里需要注意的是,这个广播接收器的android:enabled="false"属性为false,它的意思是除非程序已经明确的可以使用了,否则则不会调用它,这样阻止了不必要的系统启动广播被调用,你可以使用以下步骤启动广播接收器:

ComponentName receiver = new ComponentName(context, SampleBootReceiver.class);
PackageManager pm = context.getPackageManager();
pm.setComponentEnabledSetting(receiver,
        PackageManager.COMPONENT_ENABLED_STATE_ENABLED,
        PackageManager.DONT_KILL_APP);


只要有一次通过这种方式启动了广播,那么它会一直保持可用状态,甚至是用户重启了设备,换句话说,除非你的程序自己关掉了它,否则,它会一直保持可用状态,你可以通过以下方式来关掉它:

ComponentName receiver = new ComponentName(context, SampleBootReceiver.class);
PackageManager pm = context.getPackageManager();
pm.setComponentEnabledSetting(receiver,
        PackageManager.COMPONENT_ENABLED_STATE_DISABLED,
        PackageManager.DONT_KILL_APP);


好了,以上的文章就翻译完了,从整体上来说,老外写的文档可真是负责,对于某些细节会强调好几遍,大拇哥~

目录
相关文章
|
14天前
|
缓存 Java Shell
Android 系统缓存扫描与清理方法分析
Android 系统缓存从原理探索到实现。
39 15
Android 系统缓存扫描与清理方法分析
|
5天前
|
算法 JavaScript Android开发
|
7天前
|
安全 搜索推荐 Android开发
揭秘安卓与iOS系统的差异:技术深度对比
【10月更文挑战第27天】 本文深入探讨了安卓(Android)与iOS两大移动操作系统的技术特点和用户体验差异。通过对比两者的系统架构、应用生态、用户界面、安全性等方面,揭示了为何这两种系统能够在市场中各占一席之地,并为用户提供不同的选择。文章旨在为读者提供一个全面的视角,理解两种系统的优势与局限,从而更好地根据自己的需求做出选择。
20 2
|
10天前
|
安全 测试技术 数据安全/隐私保护
原生鸿蒙应用市场开发者服务的技术解析:从集成到应用发布的完整体验
原生鸿蒙应用市场开发者服务的技术解析:从集成到应用发布的完整体验
|
6天前
|
安全 搜索推荐 程序员
深入探索Android系统的碎片化问题及其解决方案
在移动操作系统的世界中,Android以其开放性和灵活性赢得了广泛的市场份额。然而,这种开放性也带来了一个众所周知的问题——系统碎片化。本文旨在探讨Android系统碎片化的现状、成因以及可能的解决方案,为开发者和用户提供一种全新的视角来理解这一现象。通过分析不同版本的Android系统分布、硬件多样性以及更新机制的影响,我们提出了一系列针对性的策略,旨在减少碎片化带来的影响,提升用户体验。
|
6天前
|
安全 Android开发 iOS开发
深入探索iOS与Android系统的差异性及优化策略
在当今数字化时代,移动操作系统的竞争尤为激烈,其中iOS和Android作为市场上的两大巨头,各自拥有庞大的用户基础和独特的技术特点。本文旨在通过对比分析iOS与Android的核心差异,探讨各自的优势与局限,并提出针对性的优化策略,以期为用户提供更优质的使用体验和为开发者提供有价值的参考。
|
8天前
|
安全 Android开发 iOS开发
安卓系统与iOS系统的比较####
【10月更文挑战第26天】 本文将深入探讨安卓(Android)和iOS这两大主流移动操作系统的各自特点、优势与不足。通过对比分析,帮助读者更好地理解两者在用户体验、应用生态、系统安全等方面的差异,从而为消费者在选择智能手机时提供参考依据。无论你是技术爱好者还是普通用户,这篇文章都将为你揭示两大系统背后的故事和技术细节。 ####
21 0
|
10天前
|
安全 5G Android开发
安卓与iOS的较量:技术深度解析
【10月更文挑战第24天】 在移动操作系统领域,安卓和iOS无疑是两大巨头。本文将深入探讨这两个系统的技术特点、优势和不足,以及它们在未来可能的发展方向。我们将通过对比分析,帮助读者更好地理解这两个系统的本质和内涵,从而引发对移动操作系统未来发展的深思。
22 0
|
Android开发
Android远程桌面助手(Build 0787)
Android远程桌面助手(Build 0787) 新增:       增加了输入法的快速切换功能,支持通过Google拼音输入法在PC端快速输入中文;       增加了Broadcast的暂停和继续功能;       某些应用截屏失败时在PC端给出提示;Android端截屏失败的提示,Can't take screenshot due to limited storage space, or it isn't allowed by the app or your organisation/无法抓取屏幕截图.此应用或贵单位不允许进行屏幕截图。
1619 0
|
Android开发
Android远程桌面助手(Build 0737)
Android Remote Displayer and Controller Build 0737, Aug 02, 2017 新增功能:   录制MP4文件,突破了Android原生180S的限制   截屏并保存成png   拖动左右边框调整窗口大小   adb连接设备时,增加了详细的状态指示 修复:一堆bugs         下载:http://files.
1282 0

推荐镜像

更多