Black box
Suppose an application is a black box. For now, let’s ignore the question of its category (games, business, education, lifestyle), as it is not really important at the moment. Also, let’s assume that our application is written natively for a certain mobile platform (for example, iOS – Swift, Objective-C, Android – Java, Kotlin) with the use of software best practices and project templates. I think if you are considering software efficiency, it makes no sense to go into the details of cross-platform solutions such as Xamarin or hybrids that use 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 mobile app efficiency and the factors that shape it. However, I would like to focus on the most important ones.
Devices
The first factor and probably the one most often forgotten refers to the devices themselves. Depending on the platform and the version of the software available, it is useful to put together 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, programmers use simulators, in addition to one or two mobile devices. This should be a red flag for testers to begin their testing with older devices. Negligence can lead to costly rewriting of functionalities that operate incorrectly on particular devices due to efficiency reasons. In any case, this does not justify programmers, who often copy the wrong project templates out of laziness, and start applications only on the newest devices, the ones that deal with processing complicated operations without any problems. In such cases, we generally learn about the downsides related to end-user efficiency.
Networking
Another point understood the networks and, in particular, when and how often the application uses the Internet connection. The most common errors that directly affect performance are due to the application requesting data from the server too frequently or a poor structure to cache the data. The best solution here is to plan the data generation well, whenever necessary, and cache the responses from the server.
Data generation operations must run asynchronously, without blocking the main thread, which is responsible for rendering the user interface. When downloading images, one must remember two things: save them to hard drive and about proper compression.
In addition, it is also worth making sure that the application works well offline, unless it is not required in the specification included in the documentation. From my experience, problems sometimes occur due to the lack of explicit information that the application must operate online. Sometimes redeveloping an already complex application can be very risky, as this can lead to additional errors (which are difficult to resolve). I think this problem has to do with the development of the communication layer with the server in business rather than in games, which, as can be assumed, must operate offline. By “no connection” I also mean a bad 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 large traffic of questions on the server side. 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 worked with a large project that involved libraries that were not continually updated (especially open source ones!) Will know what I am 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 for a programmer to write from scratch.
The development itself can be supported by additional devices. These can allow for proper monitoring: of application efficiency, the occurrence of crashes and the sudden shutdown 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.
Resume
In summary, we must remember that all the elements listed here form a whole and, ultimately, determine how the application sees the end user. Efficiency influences the user interface as well as your general feelings regarding the use of the application. Therefore, we must not let them feel the need to immediately uninstall our newly developed software or, worse, feel that they have an old phone and need to replace it.