由于对应用程序的电池使用，RAM和CPU使用率这样的需要关注的，什么是多contentobservers与多个broadcastreceivers的代价？
实施例1：
使用START_STICKY注册5个contentobservers /未注册的正常运行的服务。
实施例2：
服务从清单中设置5个broadcastreceivers被解雇。
实施例3：
服务与START_STICKY使用注册broadcastreceivers 5上运行。
是什么在电池的使用/ RAM / CPU观察者和接收器之间的真实差异？ 任何专业人员可以附和这个吗？ 我假设1个实例将不会有太大的差别，但让我们用5运行上面的例子，在一次。
Service运行VS无Service运行
每个应用程序都至少有一个Process你的应用程序运行时启动。 这个过程至少使用一些内存和人喜欢使用任务杀手释放，虽然Android的自动执行，一旦内存实际需要。 此内存绝对是A缺点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线程上执行。 所以，如果你做任何长期运行的操作就像在任何下载东西onReceive / Service#onCreate等方法，这将导致ANR的同样的方式它例如在Activity#onCreate 。
