1. #1
    Sencha User
    Join Date
    Oct 2011
    Location
    Austin, TX
    Posts
    43
    Vote Rating
    0
    tthai is on a distinguished road

      0  

    Default Best practice to prevent App peformance from Slowly degrading after drilling around

    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?

  2. #2
    Sencha - Senior Forum Manager mitchellsimoens's Avatar
    Join Date
    Mar 2007
    Location
    Gainesville, FL
    Posts
    37,647
    Vote Rating
    899
    mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute

      0  

    Default


    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 @SenchaMitch
    Sencha Inc, Senior Forum Manager
    ________________
    Check out my GitHub, lots of nice things for Ext JS 4 and Sencha Touch 2
    https://github.com/mitchellsimoens

    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 services@sencha.com

    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.

  3. #3
    Sencha User
    Join Date
    Jan 2012
    Posts
    12
    Vote Rating
    -1
    lestu is an unknown quantity at this point

      0  

    Default


    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?

    Best regards,
    Le stu

  4. #4
    Sencha User
    Join Date
    Jan 2012
    Location
    London, UK
    Posts
    508
    Vote Rating
    74
    shepsii is a jewel in the rough shepsii is a jewel in the rough shepsii is a jewel in the rough shepsii is a jewel in the rough

      0  

    Default


    Correct, very possible for views to be in the memory of the phone but not displayed to the user. The HTML is still sitting there, with a ton of event listeners attached in javascript.

    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.

  5. #5
    Sencha User
    Join Date
    Jan 2012
    Posts
    12
    Vote Rating
    -1
    lestu is an unknown quantity at this point

      0  

    Default


    Thanks for your answer!

    But, wow...

    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...

    Best regards,
    Le stu

  6. #6
    Sencha User
    Join Date
    Jan 2012
    Location
    London, UK
    Posts
    508
    Vote Rating
    74
    shepsii is a jewel in the rough shepsii is a jewel in the rough shepsii is a jewel in the rough shepsii is a jewel in the rough

      0  

    Default


    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!

  7. #7
    Sencha User
    Join Date
    Jan 2012
    Posts
    12
    Vote Rating
    -1
    lestu is an unknown quantity at this point

      0  

    Default


    That's good input, how do I do that? What's the keyword for that in the Sencha doc?

    Thanks & best regards,
    Le stu

  8. #8
    Sencha User
    Join Date
    Jan 2012
    Location
    London, UK
    Posts
    508
    Vote Rating
    74
    shepsii is a jewel in the rough shepsii is a jewel in the rough shepsii is a jewel in the rough shepsii is a jewel in the rough

      0  

    Default


    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.

  9. #9
    Sencha User
    Join Date
    Jan 2012
    Posts
    12
    Vote Rating
    -1
    lestu is an unknown quantity at this point

      0  

    Default


    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.

    Thanks!
    Le stu

  10. #10
    Sencha User
    Join Date
    Jan 2012
    Location
    London, UK
    Posts
    508
    Vote Rating
    74
    shepsii is a jewel in the rough shepsii is a jewel in the rough shepsii is a jewel in the rough shepsii is a jewel in the rough

      0  

    Default


    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"!