Question

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

示例1：

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

示例2：

从清单中设置的5个广播接收者发射的服务。

示例3：

使用5注册的START_STICKY运行的服务   broadcastreceivers。

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

Answer 1

Service正在运行而不是Service正在运行

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

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

如果没有Service / Activity正在运行，您只需在清单中注册BroadcastReceiver，您基本上会告诉系统将您的接收器包含在它检查的接收器列表中发送广播。非常少的额外工作。

清单接收器还具有以下优点：当内存压力高时系统不会被杀死。那些接收器只是工作而你根本不需要关心。如果你愿意，你甚至可以enable / disable。

ContentObserver vs BroadcastReceiver

两者都应使用ActivityThread / Looper / MessageQueue机制，通常称之为“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 vs 5其中

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

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

ContentObserver与BroadCastReceiver：电池使用情况，Ram，CPU？

1 个答案: