Block UI thread for WebappActivity post native startup |
|
Issue descriptionDuring startup ChromeBrowserInitializer runs some tasks on the UI thread after native has loaded. The tasks are chained and run such that after one task has finished running, the next task is posted on the UI thread. This allows breaks in between the tasks for the Main loop to process events so that Chrome does not ANR. However we mostly don't care about those events being processed (other than to prevent ANRs). This bug proposes running the tasks synchronously on the UI thread (blocking the UI thread for that duration) during PWA (WebappActivity) startup. Design Doc: https://docs.google.com/document/d/1lg0XnHv6JrpTYRJzCSpmUsuh6I1vBp0l4FoKp0gkSMw/edit?usp=sharing
,
May 16 2018
BTW, I've measured impact of crrev.com/c/1060107 on MapsGo startup on 1GiB Android Go device and didn't find any improvement in StartupToContentfulPaint metric. I used crrev.com/c/974073 to turn UnboundWebApk into "My Maps Go". The device is gobo running OMB1.180504.001. The data is here: https://docs.google.com/spreadsheets/d/1WXh6G59O1QLvuENPJHas3pCnMGxl7kiQHQ4QxjUDV6A/edit?usp=sharing |
|
►
Sign in to add a comment |
|
Comment 1 by dskiba@chromium.org
, May 16 2018