Dynamic Class Loading

[shop.servic...@gmail.com]

If you are experiencing an issue please mention the full platform your issue applies to:
IDE: NetBeans/Eclipse/IDEA NetBeans 8.2
Desktop OS Windows 10 Pro
Simulator

Device Android, IOS

For My Edification, Curious on how Android & IOS manages memory regarding classes in a given ap.

I understand in Jave 8+ classes are dynamically loaded as needed and removed when garbage cleaned.

Briefly, How does Android and IOS manage this?

Regards.

[Dave Dyer]

Classes are all static.  If you use constructs that would load classes

dynamically (ie; class.forName("foo")) they will not work unless there

is a static reference to the class somewhere.

[Shai Almog]

There is no need for that as class memory is small by comparison to application memory. We limit the size of the API so API classes aren't a noticeable memory hog.

On Android the size of the .class files roughly corresponds to the overhead which is usually well under 1mb even for large apps. On iOS the size is also pretty small (albeit larger). You can unzip the IPA to find the 32/64 bit binary to get a sense of how much ram is taken by the classes. It's nothing. Most RAM is taken by images by a huge margin.

[shop.servic...@gmail.com]

Thanks.

Currently my app size uploaded to Codename one is 6MB,

I have many re-usable Theme images,

My app is expected to grow by a factor of 5 this year.

Any concerns for an app 30+ MB (I know this is a vague/broad question)

So far performance is good, with one exception Apple iPad II Air appears sluggish when I load approx. 1.5 MB of Images

Thoughts?

On Tuesday, February 26, 2019 at 9:59:10 PM UTC-5, Shai Almog wrote:

[Shai Almog]

We have much larger apps built with Codename One but a rule of thumb is problematic as bytecode/binaries can translate to vastly different things after compilation.

Having said that performance is a big topic. I spent a lot of time talking about it in the online course and I still feel it's a nail that's hard to hit on the head. The problem starts with the description "performance" which is way too vague.  I doubt memory is the issue on that ipad. I'm guessing there are two many repaints and complex styles which trigger slow code pathways. Use the performance monitor on a particularly slow form. Then go through the tree of operations you see occurring within the hierarchy. A graphics operation that doesn't make sense might lead you down an optimization path.

You can also use standard Java profilers to find bottlenecks in your code. Performance improvements on the simulator are usually translated to improvements on the device.