Another Poor Performance on Android thread.

i hope google fix the issue soon

I dont think they know what it is. If you follow that bug report through that you posted above, it just fizzles out. They ask each other if they have any idea what could be causing it.. then nothing.

A quote from one of the devs in that thread:

"Bo, any suggestions for how to figure out why this app on this device is slower in WebView than equivalent HTML content in Chrome?"

After that... No resolution and no more discussion.

Same thing happens in the related bug report I posted above. A lot of discussion but ultimately no resolution.

SO... As Chadori has said in another thread, its possible that web worker support for Android Apps could be introducted in the future. That might help performance, but who knows when. Ashley posted about WebGPU as an alternative to WebGL. Maybe that would help, but thats probably years away??

So with things as they are, I am basically looking at holding off from publishing on Android for the time being, and hope for improvements in the future. Next Ill be testing out iOS, I have to hope I get better performance there. Hopefully I dont get the same jankiness, so I can at least publish on iPhone.

Beyond that Ill look at Facebook Instant Games if that is still a thing... my game *should* play well there as its flawless on Chrome and mobile Chrome, although I havent tested yet.

Seems they have updates that new issue report with "Labels: Hotlist-DeveloperPain" - So they might be working on it.

Anyway, last time 'bo' reply was something like(i don't remember 100%): literally they have no control over webview, and can't see what exactly adds extra performance downfall aka webview itself could take % off from each frame perf and not much left for other stuff, when more perf is needed.

His answer was not 100% clear, and you could interpret it diffently

You should find his answer to see the reason correctly.

Anyway, they updated that last issue with "Labels: Hotlist-DeveloperPain" only because that's different case and something to do with blacklist. Which I think might not be the case.

OK i found last bo reply for you:

"Webview and chrome do not have the same graphics pipeline. Chrome renders web content into a surface that it created and owns, and has complete control over scheduling GPU work. Webview renders web content into the surface that the rest of java views draws into; that surface is created and owned by android side, and webview only gets callbacks of when it should render, so webview does not have control over scheduling and does not get much feedback on the scheduling. Also webview exercises more gles APIs than chrome does for compositing, which possibly some drivers are slower at them. It's not clear what exactly is happening here, but symptom is swap is slow.

There isn't much apps can do to influence this. Chrome custom tabs / pwa is the way to go if you want to use chrome's rendering pipeline and still look like an app."

Chowdren runtime

That's seems to be some custom runtime/engine, what some guy makes and changes for each game separately and if you want it, you have to pay % share or his monthly working salary(which could be a lot for dev). That does not seems to be automated or what not.

You could possible buy game port to Unity much cheaper, ofc you then could/would also have to pay for port to Switch, but having port in Unity and not in some custom engine gives you much more options.

Looked more into this.

Ashley

back in 2018

There isn't much apps can do to influence this. Chrome custom tabs / pwa is the way to go if you want to use chrome's rendering pipeline and still look like an app."

"AFAICT Chrome Custom Tabs always show additional browsing UI, making them unsuitable for a fullscreen app, and PWA cannot be hosted in the Google Play store. So WebView is a key part of Android publishing."

At 2019 : medium.com/@firt/google-play-store-now-open-for-progressive-web-apps-ec6f3c6ff3cc

Chrome 72 for Android is now shipping from the Play Store to all users and this version included Trusted Web Activity (TWA), that in a nutshell is a way to open Chrome in standalone mode (without any toolbar or Chrome UI) within the scope of our own native Android package.

which means we can now distribute PWAs in the Google Play Store!

Ofc this means a lot of extra work for maybe almost nothing. But this could be possible fix for this rare case that some people seems to have "Perf different in chrome vs webview"

Or maybe apps already use it and it was implemented in previous years? Somewhere between 2019 and 2021 ?

It's true that worker mode is not supported in Android apps, but you can do a quick test to work out if it's relevant: disable worker mode and try it in the Chrome browser. If it's still better, worker mode is most likely not relevant. If it causes the same performance issue in the Chrome browser, that's actually quite good news since it suggests supporting worker mode in Android apps could improve the situation.

I think filing issues as I described is still the right way to approach this: the more issues filed by the more users, the clearer it is to Google that it's a significant problem that ought to be prioritised. It also increases the chance one of these reports hits on a discovery that helps get to the bottom of the problem.

People have long tried to suggest "make a native engine" as a solution to every HTML5 problem, but apart from the fact it is probably infeasible anyway, it may well not actually solve the problem - lots of other tools with native engines have users who make similar complaints about poor performance on Android, like here, here and here. Android graphics drivers are notoriously poor. If that's the cause of most of these types of problems, writing native code does not save you from that.

Trusted Web Activities (TWAs) are interesting, and you can probably try them today with an existing HTML5 export. The big problem though is they are not Cordova, so you lose IAP, ads, and all other third-party addons that involve a Cordova plugin. There's a Digital Goods API that may allow for IAP only, but you still need a full web export, hosting, and a lot of configuration with the Play Store. Do you think that's viable? We could try to support it better if that level of mobile support would do.

It's true that worker mode is not supported in Android apps, but you can do a quick test to work out if it's relevant: disable worker mode and try it in the Chrome browser. If it's still better, worker mode is most likely not relevant. If it causes the same performance issue in the Chrome browser, that's actually quite good news since it suggests supporting worker mode in Android apps could improve the situation.

Well for me, Chrome for Android still has far better performance with worker mode disabled than an APK.

I just though that in this case workers might be relevant, because going by the description in Ashley's blog post about workers, they help performance by putting the runtime into a separate thread so it can't be interrupted by other processes (causing jank). Since slight jankiness is what Im experiencing in APKs it seems workers might be helpful..

Trusted Web Activities (TWAs) are interesting, and you can probably try them today with an existing HTML5 export. The big problem though is they are not Cordova, so you lose IAP, ads, and all other third-party addons that involve a Cordova plugin. There's a Digital Goods API that may allow for IAP only, but you still need a full web export, hosting, and a lot of configuration with the Play Store. Do you think that's viable? We could try to support it better if that level of mobile support would do.

Im not sure about this.. I dont understand enough about it to know if it would be worthwhile.

For my current project I am using IAPs, MobileAds and GoogplePlay Achievements. And I wouldnt want to give any of those functions up?

But on the other hand if using a TWA meant we could get 'Chrome on Android' performance in an APK, that is definitely desirable! Id try it out if it were implemented.

Completely unrelated. Hey skymen , interested to know whats your 'Affiliate' tag all about?