Select to view content in your preferred language

Optimizing or drawing for low-end devices

791
4
Jump to solution
01-31-2024 02:51 AM
SalvadorApltp
Emerging Contributor

Hello, Esri Community,

In lower-end devices, once my map draws enough graphical entities, the device can't handle it, and the application freezes.

I'd appreciate any manner of tips on how to avoid this. Either catching the issue of CPU/GPU/Memory usage before the application crashes, creating a limit of drawn entities, undrawing and redrawing entities as they slide into view? Any other optimizing tips?

We are currently using version 100.13.0. If this is "solved" in the newer 200.X kotlin versions, we'd consider upgrading more urgently. (It is planned, but we haven't gotten around to it.)

Any suggestion will be evalued, thank you.

0 Kudos
1 Solution

Accepted Solutions
MichaelBranscomb
Esri Frequent Contributor

Hi,

It would be great to know what specific lower-end devices you're developing for / supporting and how they compare to our minimum recommended hardware covered in the System requirements.

You can find performance considerations in the Guide doc for both the previous ArcGIS Runtime SDK for Android and the current ArcGIS Maps SDK for Kotlin - note they're essentially the same because the underlying architecture is common:

Performance considerations | ArcGIS Runtime API for Android | ArcGIS Developers

Performance considerations | ArcGIS Maps SDK for Kotlin | ArcGIS Developers

 

Other contributors here may have more Android-specific suggestions as well.

 

Thanks

View solution in original post

0 Kudos
4 Replies
MichaelBranscomb
Esri Frequent Contributor

Hi,

It would be great to know what specific lower-end devices you're developing for / supporting and how they compare to our minimum recommended hardware covered in the System requirements.

You can find performance considerations in the Guide doc for both the previous ArcGIS Runtime SDK for Android and the current ArcGIS Maps SDK for Kotlin - note they're essentially the same because the underlying architecture is common:

Performance considerations | ArcGIS Runtime API for Android | ArcGIS Developers

Performance considerations | ArcGIS Maps SDK for Kotlin | ArcGIS Developers

 

Other contributors here may have more Android-specific suggestions as well.

 

Thanks

0 Kudos
SalvadorApltp
Emerging Contributor

Thank you kindly, I'll be checking these out.

We're having trouble with drawing 2mb DXF files in the tablet "EM-Q86", which... has rather little information online about its internals, specially none about the GPU. It has eight cores, at least, but otherwise it seems to be on the lower end of things.

I'll see about the performance considerations, perhaps we can optimize things some more. I'll chime in later once we investigate this.

0 Kudos
MichaelBranscomb
Esri Frequent Contributor

The first thing I'd try is explicitly setting any graphics overlays and feature layers to use the Static RenderingMode (although polyline and polygon should default to Static): FeatureLayer.RenderingMode (ArcGIS Runtime SDK for Android 100.15.4).

Note the latest 100.x version is 100.15.4 - I highly recommend updating to this not only for possible performance gains, but also 3rd party library updates that resolve security vulnerabilities.

You may also want to look for Android APIs to determine the rendering capability, if you're trying to build a generic app that will work well on multiple devices.

0 Kudos
SalvadorApltp
Emerging Contributor

Thank you very much for your messages, Michael, they pointed me in the right way.

Changing the processes to batch processes as was indicated, already helped out with performance a great amount. Rendering mode was already static otherwise. I have a question:

Is it possible for me to signal a Canvas to stop drawing Graphics? As it stands I add the elements in the Graphics collection, and Esri maps keeps drawing things until my clients' devices lags so much it eventually crashes. If I could force it to stop drawing, I would prevent the crash, based on available memory etc, at the very least.

0 Kudos