Is it better (for performance) to send a broadcast (ACTION_APPWIDGET_UPDATE in my case), in a separate thread than the UI thread (a runnable)? Or is it acceptable practice to do so on the UI thread?
5 Answers
You can read in documentation for sendBroadcast:
This call is asynchronous; it returns immediately, and you will continue executing while the receivers are run.
so it is perfectly safe to call it on UI thread

- 48,511
- 9
- 79
- 100
Sending broadcast is not a time taking(long running) process. So you can send the broadcast from the main thread(UI thread) also.

- 3,711
- 2
- 18
- 31
-
True, but do you think it'd be lighter for the app/phone to do so thru a runnable? Would there be any downside to using runnable? – Mehmet K May 07 '15 at 13:37
Broadcasts are always sent asynchronously, you do not need to run it in a separate thread to avoid blocking the UI thread. sendBroadcast() is already non blocking. From sendBroadcast's documentation:
public abstract void sendBroadcast (Intent intent)
Broadcast the given intent to all interested BroadcastReceivers, allowing an optional required permission to be enforced. This call is asynchronous; it returns immediately, and you will continue executing while the receivers are run ...

- 62,238
- 13
- 100
- 144
In developer console in some of my apps I check ANR (UI thread blocked) in some devices (less than 0.5%) when call "sendBroadcast" many times. To solve I call sendBroadcast in backround thread.
So it seems that even if it is asynchronous if you call it many times it can be blocked.

- 1,761
- 4
- 19
- 31
As you know BroadcastReceiver.onReceive always run in the UI thread. You register the receiver dynamically, you can specify that another thread handles the onReceive(). This is done through the Handler parameter of registerReceiver().
So, if preferably you should use through UI.

- 1,125
- 2
- 10
- 22