-
Notifications
You must be signed in to change notification settings - Fork 1.9k
Move UI dispatcher to common Dispatchers.Main #641
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
…discoverable via ServiceLoader * Dispatchers.Main can be consistently used and easily discovered, its implementation is discovered with ServiceLoader * It allows us to add iOS Dispatchers.Main implementation in the future thus opening the door for multiplatform UI-dispatched code * Workaround for #626, now Android users can start migration to RC coroutines Fixed #626
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I suspect this might cause start performance regression for all Android users based on putting ServiceLoader usage on the critical path. It's performance on Android isn't great.
public abstract override val immediate: HandlerDispatcher | ||
} | ||
|
||
internal class AndroidDispatcherFactory : MainDispatcherFactory { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This class needs annotated with @Keep
or it will be removed automatically as being unused for all R8/ProGuard users requiring manual configuration.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good catch, thank you.
I suspect this might cause start performance regression for all Android users based on putting ServiceLoader usage on the critical path
mainDispatcher
is initialized only once when Dispatchers
object is instantiated, it is not on the critical path.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I suspect most Android apps will launch something during startup which requires a Dispatchers.Main
reference and will force initialization.
Perhaps we can get R8 to rewrite any ServiceLoader
usage with a constant array determined at compile-time. This could avoid the need for @Keep
on the implementations as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I get your point. Is an access to ServiceLoader
a regression significant enough to postpone this change?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't know what the impact is off-hand. Android definitely isn't optimized for this case though which is why it has its own resource and asset system. I can measure, but it won't be until Friday at the earliest.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We will merge it then, mostly to stabilize our API.
If you (or anyone else) report a significant regression, we will rework this part without changing the API (e.g. with Class.forName
or any other hack like this)
How will this work in hybrid Swing-JavaFX apps? |
@kirill-grouchnikov JavaFx will win as a main dispatcher. |
Main thread dispatchers are grouped under Dispatchers object and are discoverable via ServiceLoader
Fixed #626