WorkManager 是一个 Android Jetpack 扩展库,它可以让您轻松规划那些可延后、异步但又需要可靠运行的任务。对于绝大部分后台执行任务来说,使用 WorkManager 是目前 Android 平台上的最佳实践。
Android Jetpack 集合了一系列的开发库,旨在帮助开发者更容易地创作高质量的应用,同时也更好地兼容老旧版本的 Android 系统。在正式发布 Jetpack 两年后的今天,我们已经看到大量的应用开发开始采用 Jetpack 中的开发库,这其中既包括大型开发团队的产品,也有那些刚起步的应用。而这一切仅仅是开始,因为近期我们发布了一系列新的开发库,以及过去一年我们对于现有开发库的重要更新。
在Android开发领域,掌握Jetpack是一位专业Android开发者必备的技能。本文将围绕Android Jetpack展开,深度解析面试中可能涉及到的高级疑难问题,我将分享一些关于Android Jetpack的面试技巧,帮助你更好地准备面试。
本文是 MAD Skills 系列 中有关 Hilt 的第四篇文章!在本文中,我们将探讨如何编写自定义的 Hilt 扩展。
Android Jetpack 是一套帮助你轻松构建高质量应用,兼容旧版本系统的类库套件。在 Jetpack 发布两年之后的现在,我们已经看到了很多 app 的广泛采用,并且更多的开发者开始使用了。这只是一个开始:今天,我们将发布过去一年的工作成果,一些新的类库以及现有类库的重大更新。
Android Jetpack 套件是最近比较流行的组件库,它包含了一系列的优秀实践,本文是先介绍 Jetpack 的概貌。
在本系列第二篇文章 协程中的取消和异常 | 取消操作详解 中,我们学到,当一个任务不再被需要时,正确地退出十分的重要。在 Android 中,您可以使用 Jetpack 提供的两个 CoroutineScopes: viewModelScope 和 lifecycleScope,它们可以在 Activity、Fragment、Lifecycle 完成时退出正在运行的任务。如果您正在创建自己的 CoroutineScope,记得将它绑定到某个任务中,并在需要的时候取消它。
我们在不久前刚刚结束了一个 关于 WorkManager 的 MAD Skills 系列课程。在系列的最开始,我们为新接触的开发者们介绍了 WorkManager,随后,我们深入探讨了该库的高级用途,包括如何测试和调试您的 WorkManager 代码。在最后一集中,我们介绍了如何将 GCMNetworkManager 和 FirebaseJobDispatcher 中的旧代码迁移到 WorkManager。
5月8号, I/O大会上推出了Architeture新组件WorkManager。 由于Android版本的不断更新,后台任务的处理变得越来越复杂。 因此,Google发布了 WorkManager(作为JetPack的一部分)来帮助开发者解决这一难题。
WorkManager目前还在Alpha阶段,还存在一些问题。不过等后续Release后,又是开发的一大助力。
随着设备性能提升和软件生态发展,越来越多的 Android 应用需要执行相对更复杂的网络、异步和离线等任务。例如用户想要离线观看某个视频,又不想一直停留在应用界面等待下载完成,那么就需要以一定的方式让这些离线的过程在后台运行。再比如您想将一段精彩的 Vlog 分享到社交媒体,肯定也会希望视频上传时不会影响到自己继续使用设备。这就涉及到了我们今天分享的主题: 使用 WorkManager 管理后台和前台工作。
在Android应用开发中,有效地管理后台任务是至关重要的。Android WorkManager是一个强大的库,旨在简化任务调度和后台工作管理。本文将深入探讨WorkManager的内部实现细节、原理和具体使用。
WorkManager 是 Android Jetpack中的一部分,它主要是封装了 Android 后台任务的调度逻辑。在前文《Android后台任务处理指南》一文中知道,WorkManager 是高级 API,它实际是封装了 JobScheduler, Firebase JobDispatcher, 和 AlarmManager 底层的使用,提供了简单且灵活易用的API,它有很多优势:
绝大部分应用程序都有后台执行任务的需求,根据需求的不同,Android为后台任务提供了多种解决方案,如JobShedule,Loader,Service等。如果这些api没有被正确的使用,则可能导致消耗大量的电量。WorkManager为应用程序中那些不需要及时完成的任务提供了一个统一的解决方案,以便在设备电量和用户体验间达到一个比较好的平衡。WorkManager有三个重要特点,分别如下:
在 上一篇文章 中,我们提到了现代 WorkManager API 对工具支持方面也进行了改进,本文我们将结合实际案例来看看具体有哪些改进。如果您更喜欢通过视频了解此内容,请 点击此处 查看。
在上一文中已经了解到 WorkManager的基本用法之后,今天来看看它的一些高级用法:
注:原文地址 5月8号, I/O大会上又推出了两个新的Architeture Component库: Navigation与 WorkManager. 这里就先介绍一下 WorkManager。
在Android应用开发中,或多或少的会有后台任务的需求,根据需求场景的不同,Android为后台任务提供了多种不同的解决方案,如Service、Loader、JobScheduler和AlarmManger等。后台任务通常用在不需要用户感知的功能,并且后台任务执行完成后需要即时关闭任务回收资源,如果没有合理的使用这些API就会造成电量的大量消耗。为了解决Android电量大量消耗的问题,Android官方做了各种优化尝试,从Doze到app Standby,通过添加各种限制和管理应用程序进程来包装应用程序不会大量的消耗电量。
当需要执行长时间运行的任务,而应用处于后台状态时,您会遇到 后台执行限制,该特性是在 Android 8.0 之后增加的。我们鼓励开发者进行行为变更以提升整个平台的用户体验。
Android应用中大部分都需要执行后台任务,因此也提供了多种解决方案,如JobScheduler、Loader等。但不合理的使用这些API,会造成消耗大量电量。JetPack中的WorkManager为应用程序执行后台任务提供了 一个统一的解决方案。 WorkManager可以自动维护后台任务的执行时机,执行顺序,执行状态。
欢迎来到我们 WorkManager 系列的第二篇文章。WorkManager 是一个 Android Jetpack 库,当满足工作的约束条件时,用来运行可延迟、需要保障的后台工作。对于许多类型的后台工作,WorkManager 是当前的最佳实践方案。在第一篇博文中,我们讨论了 WorkManager 是什么以及何时使用 WorkManager。
在 上一篇文章 中,我展示了 content provider (它出现在应用合并后的 manifest 文件) 是如何在应用启动的时候自动加载第三方库以及模块的。
WorkManager 提供了一系列 API 可以更加便捷地规划异步任务,即使在应用被关闭之后或者设备重启之后,仍然需要保证立即执行的或者推迟执行的任务被正常处理。对于 Kotlin 开发者,WorkManager 为协程提供了最佳的支持。在本文中,我将通过实践 WorkManager codelab 为大家展示 WorkManager 中与协程相关的基本操作。那么让我们开始吧!
Android 12 (API 级别为 31) 引入了 前台服务启动限制。除少部分 特殊场景 外,如果您的应用的 targetSdkVersion 是 Android 12 或者更高 API 级别的话,应用在后台运行时将不能再启动前台服务。这意味着,如果应用当前状态不符合后台启动服务的条件,调用 setForeground 时可能会抛出 异常。
根据我们曾经做的调查,开发者们希望 Android 官方可以维护一些实用的组件库和架构实践,以降低中大型应用的开发门槛,这样开发团队就可以集中更多精力在实际业务的优化和改进上。
作为 Android Jetpack 中的新组件,WorkManager 负责用来管理后台任务,它和一个异步任务以及 Service 有什么区别呢?看完你就知道了。
今天我们来讲以下google推荐我们使用jetpack进行后台任务处理的组件:workManager。 参考: https://mp.weixin.qq.com/s/OorUNDO3GVHATJrZOijh_A
service一直被用来做后台运行的操作,包括一些保活,上传数据之类的,这个后台运行的弊端很多,比如耗电,比如设计用户隐私之类的,谷歌对这些后台行为进行了一些处理,从Android Oreo(API 26) 开始,如果一个应用的目标版本为Android 8.0,当它在某些不被允许创建后台服务的场景下,调用了Service的startService()方法,该方法会抛出IllegalStateException。并且出台了一些新政策:
定义Work类,继承Worker,doWork方法需要返回一个Result的结果,有成功、重试、失败:
随着网上购物消费模式热度的不断提高,网上销售平台上各种促销手段也层出不穷,其中“秒购”已经是各种网站普遍流行的促销方式了。“秒购”对数据的实效性和精确性要求非常高,所以通过分布式运算实现高并发数据处理应该是正确的选择。不过,高并发也意味着高频率的数据操作冲突,而高频使用“锁”又会严重影响效率及容易造成不可控异常,所以又被迫选择单线程运行模式。单线程、分布式虽然表面相悖,不过如上篇博文所述:可以利用akka-cluster-sharding分片可指定调用的特性将一种商品的所有操作放到同一个shard上运算(因为shard即是actor,mailbox里的运算指令是按序执行的)可容许在一个分布式环境下有多个分片来同时操作。如此可在获取分布式运算高效率的同时又保证了数据的安全性和完整性。
链接:https://juejin.im/post/5d3374cee51d4556bb4cd469
在 WorkManager 2.5 中,我们让多进程应用能够更容易地访问在指定进程中运行的特定 WorkManager 实例。
Android Studio 包含了许多像 布局检查器 和 数据库检查器 这样的检查器,来帮助您调查并了解应用在运行时的内部状态。在 Android Studio Arctic Fox 中,我们发布了一个新的检查器 (Background Task Inspector),用于帮助您监控和调试在应用中使用 WorkManager 2.5.0 或更高版本所调度的 Worker。
应用启动时间是应用性能的关键衡量指标。应用启动后,用户期望能够得到快速响应并加载内容,当不符合预期时用户会感到失望。这种糟糕的体验可能会导致用户在 Play 商店上对您的应用给予低分数的评价,甚至不会再次使用。
上一次我们对Paging的应用进行了一次全面的分析,这一次我们来聊聊WorkManager。
WorkManager API 可以很容易的指定可延迟的异步任务。允许你创建任务,并把它交给WorkManager来立即运行或在适当的时间运行。WorkManager根据设备API的级别和应用程序状态等因素来选择适当的方式运行任务。如果WorkManager在应用程序运行时执行你的任务,它会在应用程序进程的新线程中执行。如果应用程序没有运行,WorkManager会根据设备API级别和包含的依赖项选择适当的方式安排后台任务,可能会使用JobScheduler、Firebase JobDispatcher或AlarmManager。你不需要编写设备逻辑来确定设备有哪些功能和选择适当的API;相反,你只要把它交给WorkManager让它选择最佳的方式。
调度任务也是最近产品中需要用的,定时与后台进行数据同步,研究了几种方法后,觉得还是JobSchedule相对效果还好点,主要原因是WorkManager的定时任务最短也需要15分钟,虽然JobSchedule在Android7.0后也这样的,但是可以通过别的办法实现,所以两个都说一下,两个也都会用到。
Hilt 发布于 2020 年 6 月,为 Android 提供了依赖项注入 (DI) 的标准化方案。对于新项目,Hilt 有着编译期校验,良好的运行时性能以及扩展性 (阅读文章 Android 和 Hilt 中限定作用域,获取更多信息)。然而,Hilt 对于已经使用 Dagger 的应用有何优势呢?您是否应该将现有的应用迁移到 Hilt 呢?以下几点阐述了您的团队需要投入精力到迁移工作中的原因。
最近我开始尝试使用 AndroidX 的应用启动 (App Startup) 库。在这个库发 布了 1.0 版本 之后,我觉得是时候深入理解一下为什么需要、什么时候以及如何使用这个库。
Jetpack 是 Android 组件的集合,使您可以更轻松地开发出色的 Android 应用。这些组件可帮助您遵循最佳实践、减少编写样板代码的工作并简化复杂任务,以便您将精力集中放在开发您应用的核心逻辑。
WorkManager能帮我们更好的管理后台任务,可以更好地管理执行时机、执行顺序和执行状态(有无网络、是否在充电)。他会根据系统版本选择合适的方案执行任务,比如在API 23及以上使用JobScheduler,以下则使用BroadcastReceiver和AlarmManager,能兼容到API 14。同时,他会将任务存储进数据库来保证关机重启后任务仍可执行(这点有待验证,因为国内机型太多了)。
最近有读者反馈,在我的新书《Android Jetpack 开发:原理解析与应用实战》中并没有提及到WorkManager,这是因为目前这个东西在国内并不是很好用。最近因为工作需要正好研究了下,也作为补充章节分享给读者。
Android11不光废弃了AsyncTask,还把IntentService一起废掉了,对于后台的异步服务,官方建议改为使用工作管理器WorkManager。 其实除了IntentService之外,Android也提供了其它后台任务工具,例如工作调度器JobScheduler、闹钟管理器AlarmManager等等。当然这些后台工具的用法各不相同,徒增开发者的学习时间而已,于是乎谷歌索性把它们统一起来,在Jetpack库中推出了工作管理器WorkManager。这个WorkManager的兼容性很强,对于Android6.0或更高版本的系统,它通过JobScheduler完成后台任务;对于Android6.0以下版本的系统(不含Android6.0),通过AlarmManager和广播接收器组合完成后台任务。不过无论采取哪种方案,后台任务最终都是由线程池Executor执行。 因为WorkManager来自Jetpack库,所以使用之前要修改build.gradle,增加下面一行依赖配置:
作者 / Florina Muntenescu, Android Developer Advocate
这个其实没啥可说的,其实就是简化了一部分用法,比如把构造器放到activity上去。参考链接 How AndroidX changes the way we work with Activities and Fragments A first look at AndroidX Activity Result APIs
领取专属 10元无门槛券
手把手带您无忧上云