jahorton
commented
4 weeks ago Just revisited this today. Took me a while to get profiling, and even longer to actually find SWKeyboard entries as described, but I finally found it... along with something quite interesting.
The biggest thing that stands out to me: what on earth is causing FontManager.registerCustomFonts() to spend such a proportionately high amount of time, and during startup at that?
After a bit further of a drill-down on that angle... we get to [UIFont fontNamesForFamilyName:] from UIFoundation, which accounts for 156.84 Mc of its 196.18 Mc. That's triggered here:
There has to be a better way to do this. Even if not, surely we don't have to do it immediately during system keyboard startup?
There has to be a better way to do this.
Even if there's no clear OS-provided method we could use, FontManager itself is quite, quite unoptimized about this operation.
Note the structure of the code block from above: we do a two-layer loop to detect if one font exists.
There are two more loop layers on top of this:
registerFont directly calls fontExists each time it is called.
So... we'd probably be more efficient there if we just batched up all fonts to check first (two loops), and then check all of them in one pass through the fontExists double-loop.
Is your feature request related to a problem? Please describe. The app has received a number of crash reports (see #1169, #1170, #1172) that are caused by poor system-keyboard startup performance. If a keyboard app-extension takes too long to load, iOS explicitly kills it.
Describe the solution you'd like As documented on #1169, profiling
SWKeyboard's startup time should yield some insight on what components could be sped up, delayed, or performed asynchronously in order to promote responsiveness, both to the user and to the system.Describe alternatives you've considered Apple doesn't really give the app alternatives.
Product context iOS
Additional context
1475 was a good first step toward addressing these issues.
Based on the final profiling obtained during that work, finding a way to streamline
Manager's load time, perhaps by reducing the amount of data necessary to retrieve from 'app group' space at startup, would probably be a decent place to start. Less important but also possible would be to delay creation of the WKWebView, though that may have UI/user impact.