29 Feb 2012 6:21 PM #1
Best practice to prevent App peformance from Slowly degrading after drilling around
I've built a rather complex app using iphone4s where the Home page would have 5 horizontal scrolls using Dataview each with 15 thumbnails using inline setting.
------- horizontal scroll dataview1 -----
[ ] [ ] [ ] [ ] [ ] .... [ ]
---------- data view2 -----
[ ] [ ] [ ] [ ] [ ] .... [ ]
From there, clicking on a certain content would take you to various parts of my app all of which has 5 different type of TabPanel classes (Say video,blogs,photos) and each has 4 dockedBottom tabs linking to either Lists or Sub panels.
After using the app and drilling into content, going back to home, drilling into other parts of the app about 6-10 iterations, I start to notice the app degrading in performance quite a bit for the Home page horizontal list scrolls and the standard vertical list scrolls from other content panels within the app. As I go to 20 iterations of drilling into content and coming back to home panel, the app would basically be so slow that you would think Sencha Touch 2 has very poor list scroll peformances. Page transitions in itself would feel clunky as well.
If I were to reload my app, it all runs very smooth and fast again.
What general best practices are there to keep the App running lean instead of getting bloated after normal usage in Sencha Touch 2?
1 Mar 2012 8:00 AM #2
- Join Date
- Mar 2007
- Gainesville, FL
- Vote Rating
You need to keep things as lightweight as possible meaning if it's not the active item or being transitioned to being the active item, it shouldn't be rendered.Mitchell Simoens @LikelyMitch
Sencha Inc, Senior Software Engineer
Check out my GitHub, lots of nice things for Ext JS 4 and Sencha Touch 2
Think my support is good? Get more personalized support via a support subscription. https://www.sencha.com/store/
Need more help with your app? Hire Sencha Services firstname.lastname@example.org
Want to learn Sencha Touch 2? Check out Sencha Touch in Action that is in print!
When posting code, please use BBCode's CODE tags.
16 Oct 2012 12:56 AM #3
What does that mean exactly? Do we need to manually call hide() on views/components that are not active?
Is it a wrong assumption that when a view is activated (and the last one automatically deactivated), everything that is not visible to the user is therefore not rendered and does not affect performance?
16 Oct 2012 1:53 AM #4
Use View#destroy() on all items that you don't have in the viewport wherever possible. Much rather suffer the time to reinitialize the views than the performance hit on keeping them in the DOM.
16 Oct 2012 2:38 AM #5
Thanks for your answer!
Doesn't this mean it makes things like nested lists and navigation view with many cards to slide back and forth pretty much useless?
So basically, every view in its deactivate-listener should destroy itself right away?
The sencha API sure doesn't suggest that it is to be used like this...
16 Oct 2012 2:41 AM #6
It's really up to your discretion as a developer. Personally, I leave nested lists/navigationview subviews in the DOM unless I really need the performance upgrade of destroying them.
For TabPanels, I personally lean towards destroying all views whenever you switch to another tab. Again, depends on your exact situation - which devices you're deploying to, how memory intensive the views are, and how important the performance is.
Remember you can always remember the state of a view and restore it like that!
16 Oct 2012 2:51 AM #7
That's good input, how do I do that? What's the keyword for that in the Sencha doc?
Thanks & best regards,
16 Oct 2012 2:54 AM #8
You mean remembering the state and restoring it? There's no easy way... for instance, if I have a tabpanel, and one of the tabs has a navigationview with 3 views in it, when the tab is deactivated I might destroy the navigationpanel and all its views, but if you've setup routing properly and the browser's back button is hit, the function that showed the deepest view in the navigationview would create the navigationview and all the parent views if they didn't already exist.
It gets fiddly, but that's necessary I guess to allow developers the exact balance of performance and usability they want.
16 Oct 2012 2:58 AM #9
Oh, I thought from the way you said it, that it was an easy built-in function of Sencha, to serialize and restore Views, so to speak.
Well, I'll do some tests with deleting all inactive views first and see how that works for the performance. I think rebuilding my views on the fly should be easy.
16 Oct 2012 3:00 AM #10
Incidentally, I've been trying to get an answer to a related question for a while that maybe someone from sencha (Mitchell?!) might be able to help with....
Basically I can never work out exactly when I should destroy my views. The deactivate event fires when the animation to deactivate the view starts, not when it ends. So I just use Ext.defer at the moment which is ugly; what's the best practice here? I feel the framework needs an event called "afterdeactivate"!