App size reduction

General Discussion
#1

I’m new to app inventor but not to programming so I’m just trying to figure out how to reduce file sizes. I’ve found in PICs for example where size is very limited that loops consume less than goto.

For example, I’ve added blank labels to add space between components on the screen because I have found any other way. Does that add a lot to the file size? Do lists add much? Where is the break even point for making a list of objects and using the for each as opposed to brute coding? Or is the code in a simple app such a small percent of overall file size that it doesn’t matter. Is there a list somewhare that gives the added size of components? ex. textBox 1k, TinyDB 35kb plus data etc.

I’ve searched and haven’t been able to get any info like this. Mostly they talk about picture size and other “added external” items.

#2

You can find out most of it yourself by adding elements (blocks: lists, labels, …) and watching how the size of the aia behaves. And yes, the crucial parameter for the size of the project is the size of the media files (images, audio, video etc.) and not the blocks.

See also here:

1 Like
#3

If you’ve only programmed PICs, see FAQ Section: Waiting and Timing to break the wait loop habit.

TinyDB is an XML file. If you want to store enough data locally to require indexing, use an SQLite extension.

Your interface component count should not increase with your volume of data, otherwise you are doing something wrong.

The break even point for using lists is 3, in my experience.
Sometimes at 2.

#4

just to clarify, I used PIC in a generic sense of programmable IC’s. That’s very interesting about Tiny being XML. That’s text based isnt it?

I used a csv to a list for a DB of 4 cols and 30 rows of mostly static data. Actually it’s just a lookup table.

#5

Here’s a short case study using one of our apps we use for testing.

An empty project compiled contains the following breakdown:

  • APK size (compressed): 3,480,247
  • APK size (uncompressed): 6,972,040
    • classes size: 5,965,428
    • res size: 907,902
    • other size: 98,710

The example project, which has 1 screen with 67 components and 1245 blocks:

  • APK size (compressed): 3,504,823
  • APK size (uncompressed): 7,081,544
    • classes size: 6,074,956
    • res size: 907,902
    • other size: 98,686

I removed all the blocks from the screen leaving just the design:

  • APK size (compressed): 3,488,439
  • APK size (uncompressed): 7,011,016
    • classes size: 6,004,428
    • res size: 907,902
    • other size: 98,686

So the presence of the components resulted in an increase in the compiled code of ~39 kb or about 582 bytes/component. The blocks account for ~70 kb or about 57 bytes/block.

I should note that in this particular example app, none of the components used require additional libraries. Some components, such as Maps, require further dependencies that are included in the final build and will therefore contribute more to the final size of the app.

The companion app includes all of the dependencies for all components, here is a breakdown of its contents:

  • APK size (compressed): 16,243,394
  • APK size (uncompressed): 35,244,396
    • native libraries for WebRTC: 20,405,828
    • classes size: 13,453,212
    • res size: 1,062,387
    • assets size: 206,739
    • other size: 116,230
3 Likes
#6

Ahhh, this is pretty much what I was looking to know - and what I was beginning to suspect. i.e. The minimum overhead is so high that basic UI objects and code are usually an insignificant portion and not a do-or-die concern. The size of my first apk gave me a shock and I thought I had done something wrong.

Thanks