Layouts.xml and memory usage per layout

I am just experimenting and playing around with Layouts and noticed that for each additional layout that I use, I am consuming memory. (Is it largely just due to additional code - even unused?)

eg:
1 layout file = xKB
2 layout file = x * 2 kB (just a number. not definite)

so, when I added like 4 layout files (for 4 diff views / screens) - I'm getting the memory size ballon upwards and I'm hitting the max.
Even w/ my current 1 single layout, all the code is making the app close to 45/64kB max.

I need to figure out ways to reduce the memory footprint. (does anyone has optimisation clues / guidance?)

Thanks
  • In my experience, the memory used for a layout that is just defined (and not currently being used) is not that bad. The following table shows the memory usage (as reported at the bottom of the simulator window) for a test app with various numbers of layouts. The If Used column shows the memory used by the application if I've got a Ui.View that is using the layout. In the case where multiple layouts are defined, the most complicated is the one that is loaded.

    Layouts Drawables Labels Memory If Used
    0 0 0 9kb -
    1 4 2 10kb 12kb
    1 6 4 10kb 13kb
    1 8 6 11kb 14kb
    1 10 8 11kb 16kb
    2 10 6 11kb 16kb
    3 18 16 12kb 16kb
    4 28 20 14kb 19kb


    Note that this data is from a debug build. I'm pretty sure that if you tested a release binary you'd see smaller numbers.

    Nothing says you need to use the layout system. It just makes it a lot easier to place your user interface elements for the various different devices. If you are very tight on memory, you can go back to coding all of the dc.draw... calls directly. If you are just coding for a single device, then there will probably be a savings. If you are coding for multiple devices and want pixel perfect placement, I'm betting the layout system will produce equally small code and be simpler to maintain.

    Travis
  • While this is about the memory overhead of using layouts, I wonder if anyone has looked into the performance overhead of layouts.

    How much more processor does it take to use layouts vs dc.xxx() calls? (I'm thinking when layouts are used, it actually worked it's way down to doing dc.xxx() calls)

    Granted it might not matter much if you are only doing updates every minute on a watchface, but if you are updating every second while recording an activity, it might come into play...
  • Former Member
    Former Member over 10 years ago
    eg:
    1 layout file = xKB
    2 layout file = x * 2 kB (just a number. not definite)


    I might be misunderstanding what you're saying but this makes me think you are loading them all into memory at once. Do you still see this if you only load one layout into memory at a time (as Travis suggests)?

    There should be some overhead with each layout as they would all be compiled into the app but - as Travis mentioned - I wouldn't expect to see a doubling of the memory.
  • Honestly don't know if I am loading all into app at once.
    I have 4 layouts defined. but in the app, I've actually ONLY specifically asked to load 1 into it. The rest are basically just placeholders until I figure out next steps.

    but when I do the compilation, I see a diff between when I add the 3 XML into the compilation command line vs if I do not (I am using a windows box, monkeyc on the command line)
  • I see a diff between when I add the 3 XML into the compilation command line vs if I do not (I am using a windows box, monkeyc on the command line)

    This is expected.

    Every layout that you define is compiled into the code necessary to generate the visuals that the layout describes. When you make a layout named TestLayout, you end up with a function named Rez.Layouts.TestLayout() that generates a list of drawables from the data specified in the xml. The compiler may need to generate a few drawable classes as well to do some things.

    This code takes space.