Replies: 48 comments 92 replies
-
|
The WebView on Android seems to be given less CPU and GPU power than the Google Chrome app itself. I noted this on different web apps. This is primarily the case with long scrollable views with lots of box-shadow and other GPU heavy css styles. This has been a thing for years. I have to say that I am experiencing it less and less every day. Maybe because our devices are getting faster or because we are (unwittingly maybe) taking this GPU bottleneck into consideration when designing stuff for Android. There are dozens of StackOverflow questions about this:
But it is not al bad, because as I mentioned before, it seems to be less and less of an issue everyday. So it can only get better from now on. That said, our app starts within a couple of seconds and sometimes performs (much) better than on iOS. So it is probably a combination of: slow Angular code (which Angular is known for), less GPU power on Android and a lot of GPU heavy CSS styles. |
Beta Was this translation helpful? Give feedback.
-
|
Our app has multiple ion-slides and ion-cards inside, so maybe the limited CPU/GPU could be the reason for this. Ionic + Capacitor is such a great solution for our target application and I hope there will be any workaround for this limitations in the future. Just wondering why Apple gets this combination work much better. |
Beta Was this translation helpful? Give feedback.
-
|
I think you misread my comment. I meant to say "But it is not all bad". I said that because phone's CPUs are only getting faster. Which in turn means this issue will be less and less of an actual issue everyday. At the time of writing that comment (over two years ago), even a simple app was really slow when scrolling. But it's getting better. All that doesn't mean this obvious performance lack shouldn't get fixed though. |
Beta Was this translation helpful? Give feedback.
-
|
flutter/flutter#52211 maybe the same issue but fixed? "fast on iOS, fast on Android browser, slow in Android WebView". He is also on a Galaxy device. I am not sure if this issue relates to Samsung devices. |
Beta Was this translation helpful? Give feedback.
-
|
I still did not find any reason why our app runs slow on Android, but superfast on iOS + desktop browser. There is one strange behaviour I noticed: When I open the app, navigate to another page and press back, the transition animation is fluid. I can also repeat this and it stays fluid. As soon as I scroll one time on the start page in any direction, no matter if vertical through the ion-content or through the horizintal sliders (build with css scroll snap, no JS), the back transition from any page is stuttering and delayed. I also replaced the ion-content with an overflow:auto div with no success. What is happening in Ionic/Capacitor/Android when I leave a page, that could cause this stutterung? There is no scroll/touch listener on my side. The ChangeDetection is handled correctly. All observables are unsubscribed when a component gets destroyed. I thought the page transition would:
So I dont understand the cause of this stuttering. I do not have this behavior in any way on the desktop version nor the iPhone. |
Beta Was this translation helpful? Give feedback.
-
|
We are experiencing a similar issue with capacitor/webview on android. We build a custom Slider which animates really smooth on IOS and desktop but has significant frame drops on android. |
Beta Was this translation helpful? Give feedback.
-
|
I'm working for years with Cordova, this time I decided to use Capacitor and I'm sad with the Android performance :( I thought stuttering of sliders had to be left and forgotten in 2014. Currently, on Cordova + Android it works much better. I found very comfortable and useful approach with native projects, which can be updated directly from Xcode/Android studio, but this stuttering is something terrible. I don't know what to do, migrate to Cordova or I can expect some fix ? |
Beta Was this translation helpful? Give feedback.
-
|
Well, if someone could create a repository with a reproduction, the ionic team could have a look into it. I allready tried to break our code down, but this seems really hard for me right now. This issue does not have to be in directly relation to the ionic framework, but obviously there a many people having problems with Android. So there is the possibility that we (that have this performance issues) are too stupid to create fast angular applications or there must be an issue at some place. |
Beta Was this translation helpful? Give feedback.
-
|
I have a lot of other tasks at this moment, but I will prepare a repo to show the issue. |
Beta Was this translation helpful? Give feedback.
-
|
I created a bug ticket and hope it helps to solve this issue. |
Beta Was this translation helpful? Give feedback.
-
|
Update: Added gifs from a productive project to the ticket to show the issue more clear. |
Beta Was this translation helpful? Give feedback.
-
|
The ticket is closed, because I found the reason of the performance issue in my case. Further tracking of the issue should be done with the chromium bug ticket by @lincolnthree |
Beta Was this translation helpful? Give feedback.
-
|
@AE1NS Have you noticed any difference between "Signed" vs "Un-Signed" apps? For us, the un-signed app performs better. We're trying to figure out if it has something to do with In-App Billing (since that doesn't run in Un-Signed apps.) |
Beta Was this translation helpful? Give feedback.
-
|
I dont think that makes a difference, because our app is running well at beginning, but getting problems after scrolling. |
Beta Was this translation helpful? Give feedback.
-
|
Last month I worked on Vue app with plan to use Capacitor. I really like the concept, documentation is good too. We finished with development. App we built work flawless on web inside browser, but then when we create an Android bundle with Capacitor we were disappointed with animation and page to page transition performance. We tweaked app in order to gain performance, we removed opacity, box-shadows, we even hide some content during transitions, use low res images, use only CSS GPU animations and so on... It was better, but still not as near as it is on web (desktop, or even Chrome mobile was running perfectly smooth). We decided then to try same app (with optimized animation above) with Cordova, everything remains same, we just used Cordova, the result was that animation performance was significantly better. I am not sure what's the difference when it comes to WebView, but transitions are much smoother. However, Chrome for mobile is still number one. I still think this is project with great potential, but when it comes to something like this, probably because project is young, you hit dead end. |
Beta Was this translation helpful? Give feedback.
-
|
I am just wondering, why there is still no response of a capacitor developer, although I created a bug ticket with a reproduction code. The referenced ticket in the first post was closed including these words:
It would be great to hear something like "we can confirm this behavior" from any capacitor developer. |
Beta Was this translation helpful? Give feedback.
-
|
This makes me worried. Trying out the stack right now. While reading the forums for possible issues, I don't see Capacitator team responding much around the forums. |
Beta Was this translation helpful? Give feedback.
-
|
@tadeumaia While I do think this issue is real, I don't think it's problematic enough to avoid the platform. Newer devices with more powerful CPUs have far less trouble. That said, the vast majority of devices is actually trending toward lower-end as time goes on. But new, low-end devices are probably still faster than low-end devices from 3-4 years ago. Capacitor and Ionic are in active development, and they just got a few new rounds of major funding, so I wouldn't worry too much. They are still a start-up, so I don't think they have a full-time customer service department for free users. The have been very generous with their support of the open-source community to this point, and their paid features come with support afaik. Typically if you file an issue with a reproduction, they'll respond. This one seems to be a rare exception. There is also some evidence to suggest this is a WebView problem, not a Capacitor problem, so there may be little the Capacitor team can do to address the issue. However, a response with some info from them would be nice. |
Beta Was this translation helpful? Give feedback.
-
Developed 3 (2 personal, 1 professional) capacitor apps. Always had this issue on capacitor android. |
Beta Was this translation helpful? Give feedback.
-
|
Yes, we also experience this consistently with every app we build with Capacitor. When we install as PWA there are no performance issues - the same app bundled via Capacitor Native on Android has significant slowdowns on many devices. I can also provide a real-world example of this if any Capacitor developer find it useful. |
Beta Was this translation helpful? Give feedback.
-
|
Just acknowledging that we're aware of this discussion and will discuss with the team after the holidays. Seems strange that mobile browser perf would be better since it's just using the Chrome WebView. And doubly so that Cordova would be any faster as it's using the same browser tech. I wonder if there's some option we have enabled that is causing an issue? |
Beta Was this translation helpful? Give feedback.
-
|
I have a brand new Pixel 6 Pro, and my app animations are janky and stutter on almost everything when running in Capacitor. Even virtual-scroll is choppy on simple screens. Running in Chrome or as a Chrome PWA, everything is buttery smooth. |
Beta Was this translation helpful? Give feedback.
-
|
Has anyone cross-tested Capacitor vs Cordova on Android in this regard? |
Beta Was this translation helpful? Give feedback.
-
|
@AE1NS can you please try to reproduce your bugs with your demo repo https://github.com/AE1NS/android-performance-issue with cordova to help clarify if this also persists with cordova. |
Beta Was this translation helpful? Give feedback.
-
|
Unfortunately, I have neither the clue nor the time to do that. |
Beta Was this translation helpful? Give feedback.
-
Just tested my main app with cordova. Performance is slightly better, but still not on par with android browsers (eg. chrome). I have attached a video comparing web with capacitor. Also I wanted to show the differences to cordova, sadly i did already unstage my cordova version therefore the livereload of the app was not available anymore. |
Beta Was this translation helpful? Give feedback.
-
|
Personally, Apple's bone does not stop being more powerful, that's why we do not see iPhones with 16 GB Ram, each new version of iOS consumes less and less Ram, battery, the proof is the M1 chips. So it doesn't surprise me that your application takes less than 2 sec to start with an iPhone 11, the ionic + capacitor are for nothing because they rely on what already exists, of course, the size of the application counts as well as other factors, but for the moment the Apple bone is far superior to Android (I'm Team Android for info, I'm at onePlus ^^, with Linux). Then a Samsung is very crappy with their Android layer it's one of the worst of the market, next to oxygenOs for example. |
Beta Was this translation helpful? Give feedback.
-
|
You're missing the point. Ionic apps work flawlesly in a browser context. Only webview has hiccups and it seems not even all webview versions / implementations. So the question is how to bring webview performance on Android on par with browsers. |
Beta Was this translation helpful? Give feedback.
-
|
I agree, so we don't have control over that, it will depend on Google, to improve all that, because we could optimize our code as well as possible, it won't have significant impact. |
Beta Was this translation helpful? Give feedback.
-
|
FYI. I've opened an issue against Android WebView to try to get a discussion started about this: https://bugs.chromium.org/p/chromium/issues/detail?id=1289741 |
Beta Was this translation helpful? Give feedback.
-
|
Ok just turned off the accessibility settings all together => The lag is gone. Thank you https://bugs.chromium.org/p/chromium/issues/detail?id=1289741#c24 |
Beta Was this translation helpful? Give feedback.
-
|
@maxcodefaster Accessibility settings is a separate issue from what's being discussed here, I believe. But, what exactly did you disable? You said "all of it", but there are a lot of options and choices in Android Accessiblity. That said, if any app accessibility services are enabled on Android, it will bring WebView apps to their knees, even causing ANRs and crashes. This is something that also needs to be explored, as it is a highly reproducible regression in WebView affecting any moderate to complex app. Though, even simple apps can be affected --- So this is definitely something I'd recommend everyone check for their app performance. Definitely be sure to disable any Accessibility features you can. Even so, you may still experience performance issues and differences between Chrome PWA (which is MUCH smoother and faster, even with accessibility disabled.) Additionally, not everyone has the luxury if disabling accessibility features, so both issues still need to be addressed. |
Beta Was this translation helpful? Give feedback.
-
|
I totally agree with you, that it should not be the long term solution to disable all accessibility features. I dont think that each accessibility is causing this issue, but some apps (like LastPass) seems to scan the whole application the whole time. Its also a mystery for me, why the chrome engine inside the browser can handle this on a much more performant way. This issue is "done" on capacitors side for me, because there is obviously nothing the capacitor team can do here. Thats why I wrote this issue should be continued in the bugtracker of chromium. |
Beta Was this translation helpful? Give feedback.
-
According to the Chromium team, simply having any Accessibility App enabled will cause WebView to create a parallel accessibility tree for the DOM. This is a blocking event in the main JS thread which is why performance decreases significantly in this scenario. It does not matter which app is enabled, however, it's certainly possibly that some apps might make this worse than others, but I don't know how that part of the system works. |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
|
I went into my settings app and went to "System > Accessibility" and had Darker (https://play.google.com/store/apps/details?id=com.mlhg.screenfilter) turned on, although not actually active and darkening my screen. Turning it off made my app significantly faster. I even did a one for one comparison loading different pages with the same build on two of the same phone models, one with darker enabled and one with it disabled, and the performance difference that it makes having it turned off was huge. So it looks like accessibility apps made be causing some kind of issue with WebView or Capacitor apps. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks @lostdev - Were you able to create a reproduction app? If you can prove Capacitor is different than Cordova, and provide a sample and a recording (which nobody has been able to do so far,) then it would be interesting to get the Capacitor Devs to look at it. That said... it does not appear to make any difference (to me) between Capacitor and Cordova. Both suffered from this issue in my experience. Also, please add your feedback to these Chromium issues to keep the Android team informed (motivated) & let others know what's going on:
Cheers and "welcome to the club"... |
Beta Was this translation helpful? Give feedback.
-
|
@lincolnthree thanks; I have already voted and commented on those tickets :) I have not compared with Cordova directly - only know that my site running Ionic 2 + Cordova is working fine, but Ionic 6 + Capacitor is not. If I don't find a solution to this problem soon, I won't have a choice but to try Cordova again. |
Beta Was this translation helpful? Give feedback.
-
|
@lostdev For the record. I did create a sample that ONLY used WebView ... not even Cordova or Capacitor. Just WebView opening a URL. It had all the same performance issues that my production Capacitor app exhibits. So I highly doubt this has anything to do with Capacitor OR Cordova. I suspect it's more likely due to the Android performance regressions that have been slowly leaking into WebView over the past few years, and the increased prevalence of "smooth scrolling" 90-120hz displays that cause the JavaScript/Browser engine to have to do twice as much work through the WebView rendering pipeline. (Which is far slower and less-optimized than Chrome's.) In addition, at least our app has gotten far more complex over the years than when we were using Ionic 2. We have a larger and more complex DOM, more script, and more data. So, I'm sure that doesn't help either. But I sure would love to see the same performance that we get in Chrome and iOS where everything is "just perfectly smooth", and always runs at 60+fps. I've actually started directing users to install our PWA until Android WebView gets this fixed. It's... just unacceptable performance. |
Beta Was this translation helpful? Give feedback.
-
|
@lincolnthree I just did a test using WebView + Custom URL that points to my PWA. The app was very fast. Any suggestions on where to start debugging? The only place this is slow, is when built using Capacitor+Android. |
Beta Was this translation helpful? Give feedback.
-
|
@lostdev Interesting. Here's how I would proceed:
That's where I would start. As someone above posted earlier, we've tried all kinds of combinations of WebView settings and none of them have improved performance with Capacitor. So... I think the best way forward is to get a reliable reproduction into the hands of the teams so they can evaluate. Otherwise, I'd look at the Capacitor source code, and try to duplicate the settings Capacitor uses and see if the WebView build slows down the same way: https://github.com/ionic-team/capacitor/tree/main/android/capacitor/src/main/java/com/getcapacitor |
Beta Was this translation helpful? Give feedback.
-
|
The trends seems to be improving here as well, at least for ANRs: |
Beta Was this translation helpful? Give feedback.
-
|
Until this gets resolved, looks like I'm forced to release my app as a PWA. In my case, releasing as "Android vs PWA" makes no difference because the app doesn't use native phone features. And I "think" the end user who installs/uses it would never see a difference (other than the PWA being much faster at this point!) |
Beta Was this translation helpful? Give feedback.
-
But how will you pay Google 15% of all your revenue!?!?!? |
Beta Was this translation helpful? Give feedback.
-
|
I thought I can do in app purchases with a PWA, no? https://chromeos.dev/en/publish/pwa-play-billing |
Beta Was this translation helpful? Give feedback.
-
|
Some interesting notes regarding android performance in this post. Check the performance section. https://engineering.fb.com/2022/09/30/android/launching-a-new-chromium-based-webview-for-android/ |
Beta Was this translation helpful? Give feedback.
-
|
Apparently someone from the Chromium team is going to be looking into the issue next week (2023-06-26) and is asking for more information on how to reproduce the issue. I think it's a tremendous opportunity for the Capacitor team and more experienced Android users who can provide all the necessary information. https://bugs.chromium.org/p/chromium/issues/detail?id=1289741#c55 |
Beta Was this translation helpful? Give feedback.
-
|
Honestly, I think this is the first thing that should be on the ionic capacitor website. I love this project but this is a massive, game-breaking downside. I'm getting like 30fps on an extremely basic app and I wouldn't want to ship something that slow off to a userbase. You would have to ship your own web view in order to fix this, instead of using the OS webview, or use another open source one that's integrated into the project. It would be work but you can't ship a 30fps-capped app out on Android in 2023 |
Beta Was this translation helpful? Give feedback.
-
|
@mlynch in case you guys haven't already seen this, facebook seems to be shipping their own webview: https://engineering.fb.com/2022/09/30/android/launching-a-new-chromium-based-webview-for-android/ considering how crucial the webview is to capacitor it seems to me you should look into what FB is doing here (if you are not on it already), especially since someone from the the chromium team basically said now that the android system webview will always suffer in performance compared to the chrome browser: https://bugs.chromium.org/p/chromium/issues/detail?id=1289741#c59 |
Beta Was this translation helpful? Give feedback.
-
|
@mlynch any chance of having the option for another webview again? This android issue is why everyone says webviews are slower than hybrid / native.. |
Beta Was this translation helpful? Give feedback.
-
|
Eventually, the Capacitor team (Ionic) will have to follow suit, as they did for the cordova-plugin-ionic-webview which explains why @lostdev mentioned that Ionic 2 + Cordova was running fast, compared to the ionic 6 + Capacitor version. Capacitor app run more smoothly on iOS than Android since it uses a defined WKWebView on iOS, unlike On Android 5-6, and 10+ Capacitor uses the Android System WebView. On Android 7-9, Google Chrome provides the WebView. Clearly, the Android user experience is a gamble of sorts as we developers don't know which version of the OS the application is to be installed on plus the "mood" of Google Chrome at any time. This I thought was the reason for the Ionic Web View for Cordova to give a standard for the Ionic Android app experience across all versions. @mlynch I know it is more convenient to rely on the native platform for the webview since it's the platform to deal with all updates and upgrades, however, this works well for platforms that offer stable predictable changes. If at least ONLY for the Android platform Capacitor can come with a webview plugin backed by Ionic to harmonize the chaos, it will have us developers at peace and not always on tenterhooks when Google puts up an update that may cause our applications to "crash" or when we publish app updates and worry if the users will have the correct webview version on their phone. Just as you did for Cordova apps, consider the same for Capacitor apps coz Android is a big (though volatile) market. |
Beta Was this translation helpful? Give feedback.
-
|
@vkyeswa Instead of shipping its own WebView to Android, couldn’t Capacitor ship some code that detects the Web View instance it’s running in (system or chrome) and adjust the Capacitor output to fit? |
Beta Was this translation helpful? Give feedback.
-
|
Yeah, I wonder if Facebook has open-sourced any of that, or if they plan to. I have not seen it, if so. But this issue is a huge problem and doesn't seem like it's going away any time soon. |
Beta Was this translation helpful? Give feedback.
-
|
Hi @AE1NS are you still using Capacitor for your "Portazon" app? |
Beta Was this translation helpful? Give feedback.
-
|
Yes. And the android performance issue is still our biggest enemy. Its based on Angular + Ionic + Capacitor and we love to develop with this architecture. But its a pain to see full native apps performing much better. |
Beta Was this translation helpful? Give feedback.
-
|
I am thinking about switching to flutter. |
Beta Was this translation helpful? Give feedback.
-
|
Cool! There must be a way to improve it. I hope you find it soon! ❤️ |
Beta Was this translation helpful? Give feedback.
-
|
If you want to help, then encourage the Android team to fix this. There is nothing the folks at Ionic / Capacitor can realistically do right now. Vote for this issue and submit a debug trace for the folks at Google to analyze: https://bugs.chromium.org/p/chromium/issues/detail?id=1289741#c55 |
Beta Was this translation helpful? Give feedback.
-
|
Couldn’t Capacitor (ionic team) either ship it’s own WebView like FB, or ship some code that detects the Web View instance the app would be running in (system or chrome) and adjust the Capacitor output to fit? |
Beta Was this translation helpful? Give feedback.
-
|
Shipping a custom WebView would mean building a custom web browser, akin to forking or re-writing chrome or safari. It's not something the Ionic team is going to be able to do. Regarding detecting available WebViews and adjusting output... no. That's not how it works. You can't fix fundamental architectural flaws in WebView by changing web content that it renders. You can work around some things, but by and large the solution needs to be in WebView. There are multiple open tickets with Google that have been linked in this thread already. Please review them and contribute your data/perf traces there and let us know if you find any new information. The only way we are going to get this fixed is if Google has enough pressure on them to fix it. The Ionic team already supports dozens of browsers across dozens of OS versions (including Android and iOS). They work very hard to ensure good performance, but they are also working within the same confines that we are when it comes to WebView. If you review the issue I linked, you will see that webview performance is the same regardless of whether capacitor is used or not. |
Beta Was this translation helpful? Give feedback.
-
|
@lincolnthree @AE1NS Have you tried Capacitor-GeckoView? It purports to interface Capacitor with a bundled GeckoView based on Firefox: https://github.com/recative/recative-system/pkgs/npm/capacitor-geckoview |
Beta Was this translation helpful? Give feedback.
-
|
I've made a simple Capacitor-Geckoview app here: https://github.com/imslp/capacitor.geckoview In addition to using Geckoview it showcases accessing local files and using SQLite. It works well enough but is by no means polished, PRs welcome of course. |
Beta Was this translation helpful? Give feedback.
-
|
Great stuff, thanks for sharing! Did you do some comparison tests already? Bundle size, startup time, UI performance? |
Beta Was this translation helpful? Give feedback.
-
|
Yeah, couple things:
|
Beta Was this translation helpful? Give feedback.
-
|
Well the issue of this webview madness is not yet considered serious by Chromium/Google team which is sad :( , i think i will be wise if the Ionic/Capacitor documentation address this issue for android in the docs. Is using cordova for android release is wise for temporary solution #cmiiw ? |
Beta Was this translation helpful? Give feedback.
-
Cordova / Capacitor has no bearing on this issue. Any app that uses Android Webview will run into these problems. But I share in your disappointment that Google/Chromium team have not made significant progress on this. My only real suggestion is encourage your users to buy faster phones ;) |
Beta Was this translation helpful? Give feedback.
-
|
So Cordova affected too? Btw thx for the reply ✌️ |
Beta Was this translation helpful? Give feedback.
-
Yes, unfortunately. Any WebView based app will run into these issues. WebView is the technology that both Cordova and Capacitor (and pretty much any other hybrid Android app) is based on. That's why GeckoView -- a different embedded browser implementation -- might be an interesting alternative. |
Beta Was this translation helpful? Give feedback.
-
Actually, you are "more safe" relying on cordova since it has a dedicated webview plugin Ionic Web View plugin meaning the behavior of your Ionic app is more predictable on most of the devices unlike using Capacitor The docs have it that
The difference in Webview that's relied upon in the different Android versions brings about "uncertainty" in most developer experiences. Personally, I thought that they(Ionic Team) would have a Webview plugin like they did during the Cordova days but this time they mainly relied on the Android system Webview which makes it easier to maintain the project since there isn't a team dedicated to a new plugin but in turn it created reliance on a "middle man", a volatile one in that matter, the Google Android team At the company, we found out that a Cordova app would run with no issue while a Capacitor version of the same app would fail on the same device just because of a device related issue such as its Webview needing an update. Basically Ionic gave up its control of the app performance to how good or updated the user's phone is when they switched to Capacitor and decided not to give it its own Webview environment. Capacitor came with great improvements, especially in the app bundling process, way better/more predictable than Cordova but if you choose Capacitor your Android target market should be defined as those with high-end devices that are always up to date with device software To conclude this, we need a capacitor-webview-plugin for Android like it was with Cordova, otherwise I would advise considering ionic when building iOS strictly or for a known group of Android devices that you can setup |
Beta Was this translation helpful? Give feedback.
-
|
@vkyeswa That's not accurate. The Ionic WebView Plugin for Cordova provided a way of using WKWebView on iOS and Android's WebView for your Cordova web applications. Capacitor uses the same approach: WKWebView on iOS and Android's WebView. It is true that the kind of webview used on Android depends on the Android version. However, that is true for both Cordova and Capacitor. (Note: I'm excluding CrossWalk here because that project was deprecated several years ago). The Ionic Team has never created custom webviews for Cordova/Capacitor and has always relied on the stock webviews provided by iOS/Android. |
Beta Was this translation helpful? Give feedback.
and others
-
Follow up: #3229
As well as many other users, we have a performance lack in Android with a complex Ionic application. Its optimized with lazy loading and does have the OnPush changeDetection to prevent many angular checks. iOS and the web version is just running fine. Bringing the app on a Galaxy S20+ does not have the performance I expected. Skeleton animations are hanging sometimes and an ion-slides with some images inside are not as smooth as in iOS or web when dragging it. Oddly enough it seems to run better on Googles Pixel devices in our case.
App start: Our app loads some http data (server cached) before hiding the splash manually. These are the approximate starting times:
iPhone 11: <2 seconds
Galaxy S20+: ~3 seconds
Galaxy S7 edge: 5+ seconds
At the moment I cant find any more bottleneck in our code to improve this, so maybe there is an Android based native/web view problem maybe?
Unfortunately I can't give a sample project to reproduce this issue, but I wonder why no Capacitor developer ever noted a more or less strange difference between iOS and android.
Update
I minimized the startup time by moving some unneccessary code after the splashscreen.hide method. Basically we have some mandatory code that needs to be run before the splash gets hidden (APP_INITIALIZER). Its now booted in about 4 seconds on a Galaxy S7 edge, so I am fine with this.
I also changed the ion-slides on our start page to CSS snap scrolling, so its feel much more better on a S7 and on a S20 I get even more frames (feeling like 120FPS now and 60FPS before).
But there are still strange effects, that happens on android but not on the web. When I navigate back and the top layer page closes, the transition starts after about a second. On the web (same device) it starts immediatelly.
Beta Was this translation helpful? Give feedback.
All reactions