As many other Ionic developers I'm experiencing slow state changes on Android. My problem; it takes a few hundred milliseconds before the app starts to make the transition. I'm using native transitions and crosswalk, so the when the transition is being performed it's smooth.
My best guess is that the timeline looks like this:
1) Button is pressed, activating the state change.
2) App loads the new state
3) Transition being performed to the new state
Step number 2 is what seems to take a few hundred milliseconds, and I really thought this would be solved by Ionics view caching, but it didn't seem to make any difference.
My views are mostly static, so my idea is to find a way to cache the views properly, and manually trigger when the cache should be cleared.
Do you know how this can be done? Or if you have a better idea of how this can be solved, I'd really appreciate it if you could share your advice.
Related
I am new to JetPack Compose. I am leanring Compose and was following https://developer.android.com/jetpack/compose/tutorial
But when I ran the application in my android device, the app was extremely slow.
Simple things like expanding long message and changing color of message is taking so much time.
I have googled the problem and found:
https://www.reddit.com/r/androiddev/comments/oatiur/why_simple_app_with_jetpack_compose_is_5x_times/
https://github.com/android/compose-samples/issues/21
https://jetc.dev/slack/2021-03-14-why-so-slow.html
Jetpack Compose Performance Issue that only occurs in multi module project
But none of these were helpful to me.
If there is any confusion, please tell in the comments.
I experienced the same thing. What is currently happening is:-
1.) App Startup is kinda slow
2.) App is glitchy upon start
The good news is:-
1.) The glitches only happen for the first few times you run the animation,
2.) The glitches seem to disappear from every element after you break one of the elements in.
The bad news is of course, you have to repeat the above steps upon EVERY startup. I have heard that running the production builds instead of the debug variants boosts up the performance significantly. As of now, there's nothing you can do about it. It will only break in as Compose develops. You can check the official Compose Samples too. They are as glitchy as your apps.
All you can really do at this point is wait.
EDITS BASED ON THE COMMENTS BELOW:-
1.) By The glitches seem to disappear from every element after you break one of the elements in., I mean that if you have a lot of animated content, like maybe two LazyColumns, and a few others, then upon swiping the Column back and forth a few times (breaking it in), the lag will be gone from the other columns, as well as the animated content. Element there meant element of the screen, so individual LazyColumns are each elements.
2.) To get the production build, all you need to do is click on the release tab in the left edge of the screen in studio, then select release from the dropdown list instead of debug. 'Production' was substituted by me for 'release', but it's one and the same thing you see.
Ever since I started using one of the newer devices from Google for testing, my tests have gotten stuck whenever we call waitForIdleSync(). When going over the documentation for espresso for another reason, I found this amazing tidbit: "To avoid flakiness, we highly recommend that you turn off system animations". See the main page and how to do it programmatically.
However, I've followed the instructions (disable animations and restart my device) and my tests are still getting stuck. Google's documentation has a habit of getting stale fast, so, is there something else I need to do to get this working on newer devices?
I have the same issue and it broke our tests completely for the last two days.
Problem
I researched this issue a lot. In fact it is an AOSP bug: https://code.google.com/p/android/issues/detail?id=82046
(re-opened from this https://code.google.com/p/android/issues/detail?id=61111)
The problem occurs when you have a a animation, loading spinner, progressbar etc. in your Activity/ Layout that runs for a long time.
waitForIdleSync() will therefore wait forever.
In our case it is very problematic, because the methods getActivity(),launchActivity() and launchActivityWithIntent() of ActivityInstrumentationTestCase2and also the new AndroidTestCase have waitForIdleSync() inside.
Solution Suggestions
You can try turning the animations off or set the Visibility of any ProgressSpinner to GONE via an Intent Flag and start it with that. (Personally, I don't like that solution as it would affect the Activity itself and not the Testcode)
Another way would be to mock the preconditions for the Activity to let it not fall into this state.
Other suggestions are welcome!
I am writing an android app that uses Fragments and an ActionBar.
Is there a simple way to know when the entire app has finished starting up? Each fragment has it's own layout, and my startup code needs to touch them all. Is there an event I could use to accomplish this?
Thanks!!
onCreateView is called after the view is "all there", so its a good place for code that needs to run late in the game. You could set a flag here or send an event to notify other views that you're ready, but it is per fragment.
However, fragments are kind of based on the idea that they will be created as needed. In a normal app they come and go dynamically so there isnt ever a time when the "whole app is loaded". So, there isnt going to be a single place you can check for whether all fragments are ready unless you make your own. Before doing that you might want to consider other ways to accomplish the task at hand. Your design may not be a good one if you are having to fight against the underlying system.
I've been asked to create an app for a client which could potentially be on both android and iOS (concentrating on iOS first). So I thought that Qt may be the answer. I would like to use Qt Quick to create the app but I can't seem to find a way to efficiently handle multiple pages, baring in mind that each page could be fairly heavyweight.
So far I've tried:
Pagination with loaders i.e. dynamically pulling in the needed screen. This works but there is a noticeable delay the first time a screen is loaded
Making each page a component and showing only the necessary screen. This loads all pages on startup which is too memory heavy
Making each page a component and displaying them through a ListView. Same problem as above.
There has to be a middle ground where views can essentially go to a low memory mode like in native iOS apps. Any suggestions welcome.
NOTE: The progression of the screens is not necessarily linear
My experience with QML is rather limited but from other UX experiences I would think the solution would involve re-factoring your pages to utilize the Loader item for their inner children/Components. From what I read it sounds like you are using the Loader item on each page itself.
For example, when your program starts load in your pages, it should be pretty light on memory otherwise there many still be large components that need to be dynamically loaded.
When the user provides input to go to a specific page, animate/show as you would normally which shouldn't be delayed. The page itself should then utilize a Loader item for each component that needs to be loaded (i.e. ones with large memory footprints).
While components are loading you could show a progress bar/wheel animation. Once the component has finished loading via the onLoaded signal you can hide the progress bar/wheel.
You may also want to look at the Loader item's asynchronous property to ensure any animation (i.e. the progress bar/wheel) while the component loads avoid glitches.
Finally when the page needs to be hidden simply set each Loader item's active property to false and it should release the loaded component.
Hope that helps and isn't repeating something you've already tried.
Old question, but Qt.Controls's StackView has support for pushing and popping with various animations.
As the previous answers indicate, using a Loader is also an option but it doesn't let you easily animate the change (when changing views, the old and new are not available at the same time so you can't do nice animations).
An alternative is to use Components, lazily instantiate views and animate the transitions. Check out the example in by QtWS 2015 talk, slides and code available here.
I've been building for Android for six months now, and I'm still confused about how things happen in the UI. When I learned iOS programming, the books and docs were very clear about what happened when: for instance, that view changes and animations didn't take effect until the next iteration through the run loop. This understanding is critical to debugging UI glitches, and without it I'm having trouble tracking stuff down in our Android app (http://emu.is/download/).
For instance:
We had a situation where pressing a button brought up a fragment, and also displayed an animation as feedback for the button click. I started the animation before pulling in the fragment, yet it didn't actually run until after the fragment appeared. Why?
Often, opening a new Activity will take a long time, during which the user doesn't have great feedback that anything is happening. I'd love to pull up a minimal container for the Activity, then load its content, so the user knows what's happening. How do I do that?
Sometimes our chat bubbles (which are drawn programmatically via a custom Drawable) flash a bit, and it looks like they're being rendered halfway through their drawing process. Why? How do I avoid that?
And so forth. Basically I'd like to understand as much as possible about what happens when in the Android UI -- not just the lifecycle stuff that's well-documented, but the relationship between various UI calls and when/how things actually happen onscreen. Thanks.