black box
Suppose an application is a black box. For now, let’s ignore the question of your category (gaming, business, education, lifestyle) as it’s not really important at the moment. Also, let’s assume that our app is written natively for a given mobile platform (for example, iOS – Swift, Objective-C, Android – Java, Kotlin) using best software practices and project templates. I think if you are considering the efficiency of the software, it doesn’t make sense to go into the details of cross-platform solutions like for example Xamarin or hybrid ones using HTML5. That is even if, in the case of simple software, we can assume that the efficiency of a Xamarin-based solution will be comparative to the native language.
I am aware of the fact that I will not be able to discuss all aspects of the efficiency of mobile applications and the factors that shape it. However, I would like to focus on the most important ones.
Devices
The first factor, and probably the most overlooked, concerns the devices themselves. Depending on the platform and the version of the software available, it is useful to make a list of devices on which the software will eventually be installed.
Those devices not only determine the user interface, but primarily how particular software layers will operate on older mobile devices. These can include devices with worse drives (weaker processor, less RAM). You should also consider the availability of devices, especially older ones. More often than not, programmers use simulators in addition to one or two mobile devices. This should be a warning sign for testers to start their tests with the older devices. Negligence can lead to costly rewriting of malfunctioning functionality on particular devices due to efficiency reasons. In any case, this does not justify the programmers, who often copy the wrong project templates out of laziness and launch the applications only on the newest devices, those that deal with complicated processing operations without any problems. In such cases, we usually learn about drawbacks related to the efficiency of the end user.
networks
Another point includes networking and, in particular, when and how often the application uses the Internet connection. The most frequent errors that directly affect performance are due to the application requesting data from the server too frequently or due to a bad data caching structure. Here, the best solution turns out to be to plan well the generation of data, whenever it is necessary, and to cache the responses from the server.
Data generation operations must be executed asynchronously, without blocking the main thread, which is responsible for rendering the user interface. When downloading images, one must remember two things: saving them on the hard drive and about proper compression.
In addition, it’s also worth making sure your app works fine offline, unless it’s not required by the spec included in the documentation. From my experience, problems sometimes occur due to the lack of explicit information that the application should operate offline. Sometimes redeveloping an already complex application can be very risky as it can lead to additional bugs (which are difficult to resolve). I think this problem has more to do with the development of the communication layer with the server in business than in games, which, as can be assumed, should operate offline. By ‘offline’ I also mean a poor Internet connection, such as 3G or EDGE, which is not always 100% sufficient.
We must also consider the effectiveness of the communication layer of the server. It is particularly important when our application generates a high traffic of questions regarding the server part. The problem can be further complicated by, for example, streaming audio or video. Unfortunately, in this case, we don’t always have a direct impact through continuous development. However, I think it’s good to keep this in mind as well.
Third parties
The third point involves the use of external company libraries. This has become very popular recently. Anyone who has dealt with a large project that involved libraries that were not continuously updated (especially open source ones!) will know what I’m talking about. They facilitate the development process and speed it up, especially if they are complex. They provide functionality that would normally take a long time to be written by a programmer from scratch.
The development itself can be supported with additional devices. These can allow for proper monitoring: of application efficiency, occurrence of crashes and crashes of an application, or additional logging of application events. Such devices include, for example: Fabric, Crashlytics, Flurry, HockeyApp, AppDynamics, New Relic. They must be added and used from the beginning of the project.
Summary
In summary, we must remember that all the elements listed here form a whole and ultimately determine how the application is viewed by the end user. Efficiency influences the user interface as well as your general feelings related to using the app. So we shouldn’t let them feel the need to immediately uninstall our newly developed software or, worse yet, feel like they have an old phone and need to replace it.