ContentObserver与BroadCastReceiver:电池使用情况,Ram,CPU？

Question

由于应用程序的电池使用,内存和CPU使用需要关注,多个内容服务器与多个广播接收器的费用是多少？

例1:

使用START_STICKY运行的服务,使用5个正确注册/未注册的contentobservers.

例2:

从清单中设置的5个广播接收器触发的服务.

例3:

使用START_STICKY运行的服务,使用5个注册的广播接收器.

观察者和接收者之间电池使用/ ram/cpu的真正区别是什么？有没有专业人士可以参与其中？我假设1个实例不会产生太大影响,但让我们一起运行5个以上的例子.

Answer 1

Service运行vs没有Service运行

每个应用至少有一个Process在您的应用运行时启动.该过程使用至少一些内存,人们喜欢使用任务杀手释放,尽管Android会在实际需要内存后自动执行此操作.这种记忆绝对是一个缺点Service.

CPU /电池使用量仅在发生某些事情时增加,因此主动使用CPU或当您的应用程序强制系统保持资源启用时,例如当您保留时WakeLock.如果你没有做任何这个,你的应用程序使用大约0 CPU /电池,并且就像一个停在内存中的已停止的应用程序,以加快重新启动它.如果您的代码正在运行,您无意中使用某些资源的可能性肯定会更高.

如果没有Service/ Activity正在运行并且您只是BroadcastReceiver在清单中注册了一个,那么您基本上会告诉系统将您的接收器包含在它发送广播时检查的接收器列表中.非常少的额外工作.

显示接收器还具有以下优点:当存储器压力高时系统不会被杀死.那些接收器只是工作而你根本不需要关心.如果您愿意,甚至可以启用/禁用它们.

ContentObserver VS BroadcastReceiver

双方应该使用ActivityThread/ Looper/ MessageQueue机制通常refered为它提供了所有事件以您的应用程序,并呼吁所有的"UI线程" onCreate,onTouch等方法.当您在这些方法中出现问题时查看堆栈跟踪时,可以轻松查看:

AndroidRuntime(521): FATAL EXCEPTION: main
AndroidRuntime(521): java.lang.RuntimeException: MotionEvent{405215b0 action=0 x=66.0 y=78.0 pressure=1.0 size=0.0} recycled twice!
AndroidRuntime(521):     at android.view.MotionEvent.recycle(MotionEvent.java:659)
AndroidRuntime(521):     at android.view.ViewRoot.handleMessage(ViewRoot.java:1880)
AndroidRuntime(521):     at android.os.Handler.dispatchMessage(Handler.java:99)
AndroidRuntime(521):     at android.os.Looper.loop(Looper.java:123)
AndroidRuntime(521):     at android.app.ActivityThread.main(ActivityThread.java:3647)

如果没有传递广播或内容更改通知,则该线程只是等待.等待不使用CPU(即主动循环在循环中),但告诉系统它不需要为该线程安排处理时间.在那段时间内,CPU使用率实际上是~0.因此IMO在运行时注册其中一个之间没有任何区别.

如果方法更频繁地触发,那么唯一可能给其中一种方法带来好处的区别就是如果有的话.

1对5他们

没关系.系统中有如此多的接收器/观察器,如果添加1或5则无关紧要.如果添加1000,您可能会注意到

旁注:不要阻止UI线程执行它的工作.虽然接收器和服务没有UI,但它们的回调方法在UI线程上执行.因此,如果您执行任何长时间运行的操作,例如在任何onReceive/ Service#onCreateetc方法中下载内容,这将导致ANR以与其中相同的方式执行Activity#onCreate.