“RxAndroid meets VSYNC rubber” — Icon used with permission from Ray Wenderlich
AndroidSchedulers#from(Looper looper, **boolean async**)
async parameter affects Android APIs 16 and newer, and can significantly improve UI performance when set to
true if your app makes heavy use of RxJava+RxAndroid.
As RxAndroid’s major versions are tied to RxJava’s and we didn’t want to silently introduce a significant behavior change in a minor release, this API is not enabled by default.
To install it, you can use
RxAndroidPlugins to set it as a custom scheduler using this API:
Edit: Due to classloading, the below code is slightly wrong for setInitMainThreadSchedulerHandler. To avoid initialization of the default one, you should call AndroidSchedulers.from(...) from inside the lambda/callable passed in, rather than before.
This is a long time in the making. The main thread scheduler used in RxAndroid has historically always used
Handler#post() to schedule new
Messages. This normally comes at a cost though: by default, this abides by VSYNC locking and will result in waiting until the next frame to run. That’s a delay of up to 16ms for every emission to go through the
post(). To exacerbate things, this happens even if you’re already on the main thread (something Ray Ryan covers in this excellent talk).
So, in 2015 a discussion was started on Jake Wharton’s RxBinding project around “fastpath”-ing the main thread scheduler to immediately run work if it was already on the main thread and avoid the VSYNC cost. This discussion moved to RxAndroid as a proposal PR with a lot of good community feedback, but a consensus was never reached due to concerns around potentially racing the system’s event looper by running events directly and risking deadlocks. So it was punted, but remained a point of friction for consumers with several issues filed around it well into RxAndroid 2.x.
Fast forward to early 2017, at Uber we decided to try to re-hash this internally and found it to be mostly stable. We did see deadlocks from time to time, but they were hard to detect and seemed rare enough to be worth the performance gains we got. After ~1yr in production, we decided to try upstreaming our implementation and rehashing the discussion. This time, Android framework engineers (namely Adam Powell) saw it and chimed in to point us to
asynchronous APIs. This API allows for
Messages to bypass VSYNC locking while still letting the framework handle all the scheduling safely in its looper, which is exactly what we wanted all along!
While the asynchronous APIs have existed since API 16, they’d been hidden in the SDK via
[@hide](<https://android.googlesource.com/platform/frameworks/base/+/jb-release/core/java/android/os/Message.java#395>). In API 22,
[Message#setAsynchronous()](<https://android.googlesource.com/platform/frameworks/base/+/lollipop-mr1-release/core/java/android/os/Message.java#457>) was made public. In the API 28, there’s a new
Handler.createAsync() factory API that sets all
Messages it handles to be asynchronous by default. Since these APIs power some of the most critical parts of the OS they are unlikely to have been changed and should be safe to access. Here’s where it gets a bit fun.
The aforementioned public
setAsynchronous() method is used.
setAsynchronous() is still used but we suppress the lint error that says it’s only 22+. To avoid any (unlikely) OEM situations of deleted/changed internal APIs, we try/catch a quick
Message#setAsynchronous() method call in the
from() Scheduler factory to ensure it’s there at runtime, catching the
NoSuchMethodError if it is missing and falling gracefully back to the standard non-async messaging. It’s not reflection though, because we know this will link at runtime since the method does exist at runtime.