Performance considerations
Mobile mapping application issues
This topic describes the issues encountered by mobile mapping applications written with the ArcGIS for Android API and what to consider when designing map layer types to use in your application. The Map layer types topic is referenced, which contains more detailed information on the available map layer types.
Network speed
Android mobile devices often use 3G or sometimes lower speed radio communication networks to obtain and transfer data. The speed of these networks vary but are much slower (in terms of data per second) than wired or wireless networks. Due to this network latency, small requests can take time to return, which makes your application seem sluggish. Therefore, you need to carefully manage the total amount of data and the number of network requests submitted by your Android application. As an example, it may be more efficient to send a single large request for data rather than multiple small requests and changing the layer types, application functions or the flow of your application will enable this to happen.
If your mobile application users are always in the range of a wireless network, your application can retrieve and submit larger amounts of data. However, even in this scenario, it is always good practice to remember the amount of data and number of requests your application uses, whatever the bandwidth.
By understanding the characteristics of the different types of map layers in the ArcGIS for Android API, you can pick the best layers for your needs and ensure that your application performs for your users.
Network connectivity
Some application users may only have intermittent network access, like intermittent 3G access due to working in remote areas or daily access to a wireless network for synchronizing data. If this is the case, local storage usage is important. The application may be designed to connect to the server to retrieve data the user needs, then store this data on disk or in a local SQLite database. Applications need to be developed robustly with this in mind because the network connection can be dropped anytime. Functions need to fail gracefully and any long running application transactions may need to be rolled back.
Device limitations
Android devices have less processor and memory resources compared to standard desktop machines. For this reason, applications need to be developed to run in an efficient manner. The processing of complex server JavaScript Object Notation (JSON) responses can take time, so responses that contain large or complex geometries as JSON (queries or feature layer map requests) slows down your application. This is due to the processor speed in processing the response, as well as memory usage and the virtual machines garbage collection being invoked.
As Android supports multithreaded programming and threads consume device resources, pay particular attention to minimizing the amount of threads that are created. Contrary to this, it is also important to not hold up the main application thread when developing applications that contain activities, as this slows down the responsiveness of the user interface (UI), so additional threads are often necessary.
Analyzing these issues in Android
There are various debug tools provided by the Android software development kit (SDK) that can help analyze these issues in more detail. SDK tools exist for profiling memory, and viewing thread and network activity. For more information, see the Debugging section in the Android developers Dev Guide.
What do you want from your data?
There are two things you need to consider when designing the data layers for your application. The first is, what functionality you need to provide to your users. The different layer types have different functional characteristics and these are explained in more detail in the Map layer types topic. The second is, to consider the performance characteristics of the data layers, which are also described in the Map layer types topic. You may need to prioritize one of these issues and compromise the other, because often the layer's characteristics will be conflicting. For example, the layer that gives you the best functionality may be the slowest to perform in your scenario.