Manual testing and automatic testing
Manual testing involves a real user playing around with an application and some defined use-case scenarios, but also with more free will and the ability to leave the road of predefined tests and explore new paths.
Automatic tests are tests written by developers to ensure consistency of the application throughout the evolution in the life of a system. There are a few different types: unit tests, integration tests, or UI tests
ANR and delays in software
ANR stands forApplication Not Responding. The Android operating system analyzes the status of apps and threads, and when certain conditions are met it triggers an ANR dialog, blocking the user from any interactive experience.This happens mostly when an operation is being executed in the UI Thread.
Android systems trigger ANRs in two different situations:
1. When there has been no response for an event in five seconds
2. If a BroadcastReceiver is still executing 10 seconds after its execution
Dalvik Virtual Machine
As we have seen, programs are typically written in Java and then compiled to bytecode. From the bytecode (.classles) they are afterwards transformed into DEX format, commonly using a special tool provided by the Android SDK called dx. This DEX format is more optimized and designed to have a smaller memory footprint in comparison with normal Java .classles, since mobile devices lack the computational capabilities of desktops. This is achieved through compression and merging/optimization of the multiple .classles.
Memory management
An Android application has a maximal amount of RAM memory that it can manage. It is different for each device and can be particularly checked by calling the function getMemoryClass() on the ActivityManager. Early devices had a per-app cap of 16 MB. Later devices increased that to 24 MB or 32 MB, and it will not be surprising to see devices up to 48 or 64 MB.
Some techniques can also bypass this limitation, such as using the NDK or requesting from the system a larger heap. This last is, however, considered to be poor form for an Android app.
When a process starts, it is forked from an existing or root process called Zygote. Zygote starts every time the system boots and loads the resources common to all the apps. By doing this, Android tries to share all the common resources among the applications, avoiding duplicating memory usage for the same frameworks.
Energy consumption
This implies that managing energy well is paramount in such devices. Good energy management requires a good understanding of where and how the energy is used.
Native Development Kit or how to develop with native code when needed
Using Native Development Kit(NDK) can mean sometimes the difference between a performing application or an application that just does its job. We will generally use NDK in the following contexts:
1. Use of existing C/C++ libraries: This is an obvious advantage, since you have access to powerful existing software such as OpenCV1, audio encoders, and so on.
2. Performance: For some critical inner loops, the marginal performance advantage of C/C++ over Java, especially before Just-In-Time compilation(JIT) is available in the Android compiler, may be a deciding factor.
3. To do something that the NDK allows that the Java API can't manage: Low-level operations close to the hardware, particularly to impact manufacturer-specific hardware, might only be possible through C/C++.
4. Obfuscation: Compiled code is somehow more difficult to reverse-engineer than Java bytecode. Security by obscurity is, however, not the ideal solution, but it can complement your already existing system.
Three limits in application responsiveness
There are three different thresholds accepted as limits to the user experience in any software system:
1 0.1 seconds is perceived by the user as instantaneous responsiveness. In such operations, there is no need to display any visual feedback or notification to the user, and this includes most operations in normal scenarios (for example, the lapse between clicking on a button and displaying a dialog, or showing a different activity).
2 1.0 seconds is the lapse when the user flow gets interrupted. Between 0.1 and 1.0 there is still no need to provide any feedback, but after a second, the user has lost the perception of performing an immediate operation.
3 10 seconds is the final limit, when the user loses concentration and interest in the application. More than 10 seconds in an operation generally means that the user will lose her/his interest in the system and procrastinate while the operation is being performed. Visual feedback is crucial here; without it, the user will get frustrated and reject our system.
Google suggests keeping all interactions under 100 to 200 ms. That is the threshold beyond which users will perceive slowness in an application. Although this is not always possible (think about downloading a large amount of data, such as media and so on).
Business value of software quality
Developers often need to justify to non-technical peers why some decisions are taken that do not bring immediate value (think about refactoring an old module or developing some test coverage).
Making some decisions, in the long run, is equivalent to saving money and providing direct value to the software. This graph has been taken from a document by David Chappell, and it explains some examples of when bad software quality incurs financial loss.
