AlarmManager 具有待更新小部件的意图
我有一个要求，我需要每 15 秒更新一次我的小部件。有一个名为 android:updatePeriodMillis 的方法，但似乎仅在 30 分钟后才会被触发。
我采取了在 AlarmManager 的帮助下更新我的小部件的方法。 小部件更新，但问题是它会降低设备的性能。当我的应用程序的 AlarmManager 在后台运行时，我可以看到设备响应用户事件有很大的延迟。 拥有一个经常更新的小部件是否明智？
这是更新小部件的推荐方法..或者任何人都可以为我提供一些代码示例或任何应用程序，其中更新频繁？
为什么android:updatePeriodMillis设置为30分钟？是因为 Android 不希望我们在该时间间隔之前更新小部件吗？
I have a requirement where in i need to updated my widget once in every 15 seconds. There is a method called android:updatePeriodMillis but that seems to be getting fired only after 30 minutes.
I took an approach of updating my Widget with the help of AlarmManager. The widget updates but the issue is it slows down the performance of the device. When the AlarmManager of my application runs on the background i could see a big delay on the device to respond to user events. Is it wise to have a widget that updates frequently?
Is it the recommended approach to update the widget..or can any one provide me some code samples or any application where the update happens frequently?.
Why is that the android:updatePeriodMillis is set to 30 mins?. Is it because Android does not want us to update a widget before that time interval?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
这将对您的电池寿命产生影响。请将此设置为可配置的。
它是一个 XML 属性，而不是一种方法，是的，它的最短时间为 30 分钟，因为安装了每 15 秒更新一次的应用程序小部件的用户对电池寿命提出了抱怨。
将您耗时的工作放入
IntentService中，由警报触发。如果您直接在BroadcastReceiveronReceive()方法中执行工作，该方法以前台优先级运行，将对 CPU 使用率产生更大影响。此外，它还会占用进程的主应用程序线程，因此当BroadcastReceiver执行其工作时，您正在运行的任何活动都将被卡住。恕我直言，不，但是如果您将其设置为可配置，那么用户可以选择他们认为合适的值。
That is going to have repercussions for your battery life. Please make this configurable.
It is an XML attribute, not a method, and yes, it has a 30-minute minimum, because of complaints regarding battery life from users who install app widgets that update, say, every 15 seconds.
Put your time-consuming work in an
IntentService, triggered by the alarm. If you are doing your work directly in aBroadcastReceiveronReceive()method, that runs at foreground priority and will have a greater impact on CPU usage. Also, it ties up the main application thread of your process, and so any activities you have running will be stuck while theBroadcastReceiverdoes its work.IMHO, no, but if you make it configurable, then the user can choose what value they feel is appropriate.