Optimizing for small Android devices

[Sannyasin Brahmanathaswami]

This looks very useful . 

I think we need to wait until HQ weighs in on my bug report. Regardless of the fact that it works on iOS and Oreo, one has to wonder how on earth we can close a stack which is set to destroy on close, turn acceleratedRendering to false (assume previously cached controls are  cleared); open a new stack and *still* see the old stack behind the new, one, as if they two are still fighting for the pixel map…. even if the old one "loses" on iOS and Oreo…and the new stack "wins" the display.. .the old one could still be in the heap.

So if this indicates a failure at garbage collection (my very un-informed guess) the app will run out of RAM very fast. So however hard we work to optimize any script…it will get us nothing, 5 minutes into using the app, moving from stack to stack, crash is imminent.

That said the new script profiler in 9 is awesome (when it runs…often I start it, stop it and it is empty…)

e.g. I found a repeat loop that keeps setting the left of a large parent group  being build up from copying child groups run time…everytime a child group is added (100 times) and this one task of setting the left of group "item-list" to 0 on every loop, even with lockscreen on, was taking 80% of the time needed to do the job. it was this developer's (not me) attempt to overcome the challenge issue of the coords/ ect of the group constantly being lost despite use of 

on layoutGroup pNum
   -- general list group stuff
   set the lockupdates of group "item list" to true
   set the lockupdates of me to true

the coords still keep getting lost…and require resetting the parent group so that 0,0, us actually "known" to the subgroup being appended as a "row" at the bottom.  

Me thinks we are working too hard at this one… and I'm noodling a refactor… it will be interesting if DataGrid2 represents a "leap" forward for this kind of graphically complex list group.  I have stayed away from it as more complex than needed… OTOH if DataGrid2 will be more performant, then we should use it.

Meanwhile, other operations, like fetch data from the database, setting props on the next-copied subgroup  etc. which I thought (wrongly) would be costly were all profiling in at 1 millisecond.. So this new tool is going to be really helpful … I just have to figure out why it so often appear blank after running scripts.






 Richard Gaskin wrote:

    While looking for one of the URLs I included in my last post, I came 
    across this:
    
        How we reduced our Android app’s memory footprint by 50%
    <https://medium.freecodecamp.org/how-we-reduced-memory-footprint-by-50-in-our-android-app-49efa5c93ad8>
    
    I have no idea if those strategies would make sense in LC's internals, 
    or whether LC is already doing some of that sort of bitmap reuse.  But 
    an interesting read just the same.