App有时可能需要定期运行某些工作.例如,可能要定期备份数据.上传信息到服务器,定期获取新的内容等等. 在app运行期间,我们使用Handler也可以完成定期的功能.在这里我们介绍WorkManager使用定时任务的方法. 前面我们介绍了WorkManager的使用方法,约束和延迟等.本文介绍WorkManager的定时任务.如何创建定时任务,查看任务状态,取消任务. 本文使用kotlin 注意:可以定义的最短重复间隔是 15 分钟(与 JobScheduler API 相同). gradle

[声明] 欢迎转载,但请保留文章原始出处→_→ 生命壹号:http://www.cnblogs.com/smyhvae/ 文章来源:http://www.cnblogs.com/smyhvae/p/3960623.html 联系方式:smyhvae@163.com [正文] 一.广播的功能和特征 广播的生命周期很短,经过调用对象-->实现onReceive-->结束,整个过程就结束了.从实现的复杂度和代码量来看,广播无疑是最迷你的Android 组件,实现往往只需几行代码.广播对象被构造出来后

文章转载至CSDN社区罗升阳的安卓之旅,原文地址:http://blog.csdn.net/luoshengyang/article/details/6744448 前面我们分析了Android应用程序注册广播接收器的过程,这个过程只完成了万里长征的第一步,接下来它还要等待 ActivityManagerService将广播分发过来.ActivityManagerService是如何得到广播并把它分发出去的呢?这就是 本文要介绍的广播发送过程了. 广播的发送过程比广播接收器的注册过程要复杂得多了

必读: Android 12(S) 图像显示系统 - 开篇 一.前言 为了提高Android系统的UI交互速度和操作的流畅度,在Android 4.1中,引入了Project Butter,即"黄油计划".就像该计划的名字那样,Google期望通过这一新的机制可以让Android系统摆脱UI交互时给用户带来的滞后感,从而像黄油一样顺滑. 当然优化是无止境的,Project Butter只是迈出了重要的第一步,后续的Android版本中陆续也有引入一些其它的优化机制,促进UI渲染性能的不

现实中:电台要发布消息,通过广播把消息广播出去,使用收音机,就可以收听广播,得知这条消息.Android中:系统在运行过程中,会产生许多事件,那么某些事件产生时,比如:电量改变.收发短信.拨打电话.屏幕解锁.开机,系统会发送广播. 只要应用程序接收到这条广播,就知道系统发生了相应的事件,从而执行相应的代码.使用广播接收者,就可以收听广播. 系统中任何应用只要注册了对应了Receiver,就会接收到此Broadcast. ###创建广播接收者1. 定义java类继承BroadcastReceive

(转自:http://wenku.baidu.com/view/af39b3164431b90d6c85c72f.html) 九.Android学习第八天——广播机制与WIFI网络操作 今天熟悉了Android中的广播机制与WIFI网络的一些基本操作,总结如下: Android的广播机制 我们知道广播机制中,发送方不会关心接收方时候接收到数据或者如何去处理数据. 这里总结下Android中BroadcastReceiver的注册方法: (一)在应用程序中进行注册 (二)在Manifest.xml

1.Android广播机制概述 Android广播分为两个方面:广播发送者和广播接收者,通常情况下,BroadcastReceiver指的就是广播接收者(广播接收器).广播作为Android组件间的通信方式,可以使用的场景如下: 1.同一app内部的同一组件内的消息通信(单个或多个线程之间): 2.同一app内部的不同组件之间的消息通信(单个进程): 3.同一app具有多个进程的不同组件之间的消息通信: 4.不同app之间的组件之间消息通信: 5.Android系统在特定情况下与App之间的消息

在Android系统中,广播(Broadcast)是在组件之间传播数据(Intent)的一种机制:这些组件甚至是可以位于不同的进程中,这样它就像Binder机制一样,起到进程间通信的作用:本文通过一个简单的例子来学习Android系统的广播机制,为后续分析广播机制的源代码作准备. 在Android系统中,为什么需要广播机制呢?广播机制,本质上它就是一种组件间的通信方式,如果是两个组件位于不同的进程当中,那么可以用Binder机制来实现,如果两个组件是在同一个进程中,那么它们之间可以用来通信的方式

前 面我们介绍了Android系统的广播机制,从本质来说,它是一种消息订阅/发布机制,因此,使用这种消息驱动模型的第一步便是订阅消息:而对 Android应用程序来说,订阅消息其实就是注册广播接收器,本文将探讨Android应用程序是如何注册广播接收器以及把广播接收器注册到哪里去的. 在Android的广播机制中,ActivityManagerService扮演着广播中心的角色,负责系统中所有广播的注册和发布操作,因 此,Android应用程序注册广播接收器的过程就把是广播接收器注册到Activ

上一篇文章实现了自定义广播: android中实现自定义广播 自定义广播允许被其他应用使用,有些情况下只允许广播在本应用范围内使用,可以用本地广播的方式实现 下面是实现的代码部分,MainActivity.java: package com.example.chenrui.app1; import android.content.BroadcastReceiver; import android.content.ComponentName; import android.content.Cont

广播是一种被动跨进程通讯的方式.当某个程序向系统发送广播时,其他的应用程序只能被动地接收广播数据.这就象电台进行广播一样,听众只能被动地收听,而不能主动与电台进行沟通,在应用程序中发送广播比较简单.只需要调用sendBroadcast方法即可.该方法需要一个Intent对象.通过Intent对象可以发送需要广播的数据. 先建一个android工程:sendbroadcast.在XML布局文件中放两个组件:EditText和Button,当单击按钮后,会弹出显示 EditText组件中文本的对话框

广播主要分为两种类型,标准广播和有序广播,通过实践的方式来看下这两种广播具体的区别. 一.发送标准广播 在发送广播之前,我们还是需要先定义一个广播接收器来准备接收此广播才行,不然发出去也是白发.因此新建一个MyBroadcastReceiver继承自BroadcastReceiver,代码如下所示: public class MyBroadcastReceiver extends BroadcastReceiver { @Override public void onReceive(Contex

1 前言 为了更深刻的理解Android图形系统抽象的概念和BufferQueue的工作机制,这篇文章我们将从Native Level入手,基于Android图形系统API写作一个简单的图形处理小程序.透过这个小程序我们将学习如何使用Native API创建Surface,如何请求图形缓冲区,如何向图形缓冲区中写入数据等知识.Talk is cheap, show me the code.让我们马上开始吧! 注:本系列文章的分析及代码均基于Android 12(S) Source Code,可参

1 前言 Android图形系统是系统框架中一个非常重要的子系统,与其它子系统一样,Android 框架提供了各种用于 2D 和 3D 图形渲染的 API供开发者使用来创建绚丽多彩的应用APP.图形渲染的 API的底层可与制造商的图形驱动程序实现代码交互,了解这些API的工作原理及图形系统框架层的处理逻辑可以帮助我们更好的使用这些功能. 本系列文章将侧重于图形系统BufferQueue的知识做分析讲解.BufferQueues 是 Android 图形组件之间的粘合剂,BufferQueue 类

1 前言 上一篇文章中我们已经创建了一个Native示例应用,从使用者的角度了解了图形显示系统API的基本使用,从这篇文章开始我们将基于这个示例应用深入图形显示系统API的内部实现逻辑,分析运作流程. 本篇将聚焦应用和SurfaceFlinger的活动,即应用是如何与SurfaceFlinger这个服务建立连接并进行通信的.让我们开始吧! 注:本篇涉及的代码位置: /frameworks/native/libs/gui/ /frameworks/native/libs/gui/include/g

1 前言 SurfaceFlinger作为Android图形显示系统处理逻辑的核心单元,我们有必要去了解其是如何启动,初始化及进行消息处理的.这篇文章我们就来简单分析SurfaceFlinger这个Binder系统服务的一些基本处理逻辑.接下来分两部分讲解: >> SurfaceFlinger启动与初始化 >> SurfaceFlinger消息队列处理机制 Tips: 本篇涉及的代码位置: /frameworks/native/services/surfaceflinger/ 2

题外话 刚刚开始着笔写作这篇文章时,正好看电视在采访一位92岁的考古学家,在他的日记中有这样一句话,写在这里与君共勉"不要等待幸运的降临,要去努力的掌握知识".如此朴实的一句话,此时此刻,正适合我们. 1 前言 回到前面的文章:Android 12(S) 图形显示系统 - 示例应用(二)  ,在上一篇文章中已经讲解了应用如何与SurfaceFlinger建立连接和通信,接下来就要去创建Surface了,当然在此之前,还有获取屏幕Display信息的操作,这不是关注的重点,先不展开讲解.

题外话 你有没有听见,心里有一声咆哮,那一声咆哮,它好像在说:我就是要从后面追上去! 写文章真的好痛苦,特别是自己对这方面的知识也一知半解就更加痛苦了.这已经是这个系列的第六篇了,很多次都想放弃了,但最终还是坚持下来了,因为我真的好像搞懂这一块. 1 前言 前面一篇文章中,我们已经介绍了createSurface的流程,也在SurfaceFlinger中去创建了图层layer,但一直没有看到buffer queue的踪影.其实,据我观察 Android 12 将BufferQueue的相关逻辑移

题外话 "行百里者半九十",是说步行一百里路,走过九十里,只能算是走了一半.因为步行越接近目的地,走起来越困难.借指凡事到了接近成功,往往是最吃力.最艰难的时段.劝人做事贵在坚持,有始容易,有终实难. 不多说了,希望自己能坚持写完这个系列 ...... 1 前言 在前几篇文章中,你应该已经看到文中有冒出来比较多的陌生的类,比如 Surface/SurfaceControl/ANativeWindow/ANativeWindowBuffer,这些类有什么作用?它们之间有什么关系?以及它们

题外话 最近总有一个感觉:在不断学习中,越发的感觉自己的无知,自己是不是要从"愚昧之巅"掉到"绝望之谷"了,哈哈哈 邓宁-克鲁格效应 一.前言 前面的文章中已经讲解了如何去创建一个Surface,也讲了一些操作Surface的知识,接下来就是如何利用这个Surface进行绘图呢? 在此开始讲解buffer queue的工作流程,看看图形数据是怎样流转的? 图形缓冲区的申请和消费流程是怎样的?有哪些核心类?等等问题在接下来的文章中陆续展开. 这篇文章中,先介绍一些基本

题外话 Covid-19疫情的强烈反弹,小区里检测出了无症状感染者.小区封闭管理,我也不得不居家办公了.既然这么大把的时间可以光明正大的宅家里,自然要好好利用,八个字 == 努力工作,好好学习 一.前言 这篇文章中,将详细讲解 生产者 -- 图形缓冲队列 -- 消费者 这个模型的的具体工作流程.我们还是从我们的demo运行流程着手. 可以再回头看看 Android 12(S) 图形显示系统 - 示例应用(二) 在demo示例中,我们获取buffer --> 填充数据 --> 送出显示的代码如下