Three key elements to ensure a good user experience with Android apps

Article Description: user Experience-oriented Android application development.

Wen/Chen

This article points out that "fluent environment", "friendly experience" and "power saving" are three key elements to ensure a good user experience for Android apps.

Android Development is currently the "hot-fried chicken" in mobile development, with a large number of Java programmers flocking to Android, as well as the habit of bringing desktop and web-side development/design experience to mobile devices. The advantage is to take advantage of the common features of mobile development and desktop/web services, such as widely used lists, local databases, and other common components; The disadvantage is that mobile and desktop/web use scenes and vectors are completely different, direct porting desktop development experience is harmful.

For example, the mobile phone is mainly used in the debris time, users are easily tired of complex interface design, at the same time, the mobile environment of slow internet, network connection frequency and failure of the design of the mechanism is more fastidious; In addition, mobile phone battery life, complex background calculation will speed up the power consumption. These development concepts directly affect the user's final experience, so let's talk about how to optimize the development of the user experience orientation in Android.

Although it is not necessary to have a thorough understanding of the underlying system, you need to have a basic understanding. Android system layered Clear, the bottom is the Linux Kernel 2.6, on top of the WebKit, SQLite, OpenGL es and other basic C/s library, while Dalvik virtual machine running on the Kernel, Helps apply the underlying memory management (so that Android apps cannot be freed directly from memory). These libraries are used on the one hand by the system, on the other hand through the framework layer to provide interfaces to developers. In addition, the framework layer provides other system-level services, such as message Notification Service, location acquisition service, device information reading service, and so on.

This shows that Android is very open and flexible to developers, however, the development should be careful not to be too casual, so that the product is too complex and let the user overwhelmed. Of course, in addition to a few system-level application development needs to delve into the framework layer implementation mechanism, the general Third-party application developers do not need to have an in-depth understanding of each layer of principles, should focus on how to understand and flexibly use the vast Android SDK API.

This article mainly around the user's three kinds of feeling to explain how to develop.

The flow of the environment

Let the user feel the use of very fluent. Slow will subtly leave a bad impression. Users see the app icon, will be in the heart and "slow", "card", "unstable" to draw an equal sign, resulting in "open fear disease."

Users sliding listview, Gallery, Coverflow feel card, mostly because the corresponding adapter to GetView processing is not good enough. Each item is bound to the data source, and the data source can be obtained in a variety of ways: network, local file, SQLite database, Sharedpreference, and memory, which are transmitted in 7 seconds, 2 seconds, 1 seconds, 100 milliseconds, and 5 milliseconds.

For the most time-consuming network requests, many people use asynchronous operations that do not allow users to expend effort in the network waiting process. However, when I/O and SQLite queries, the user's waiting time is easily ignored, thus reducing the smoothness of the sliding. The ANR (application not responding) that Android users often encounter is an upgraded version of this issue. You know, the Activity Manager and Window Manager monitor the application's response, and when it's found that the process logic is not finished 5 seconds after the keystroke or touch occurs, or the Broadcastreceiver processing time exceeds 10 seconds, the system throws a ANR error. And remind the user to force termination of the application.

My suggestion is as follows:

For operations that cannot be completed in a short time, handled in a stand-alone thread, Android has a variety of asynchronous processing models to use, including Thread-handler, Asynctask, and loader and Cursorloader.

Minimize complex calculations and reduce I/O, adequately estimate the frequency of objects used, and choose the right data source. The individual believes that there are not too many objects in most applications, and you can consider caching the data in memory. If there are too many pictures in the application that cannot be cached all the time, you can use the LRU (least recently Used, least recently used) algorithm to clean out the unused cache out of memory, so that the cache size is controllable so that no bugs of out of Memory (memory overflow) occur.

But note that the algorithm is a double-edged sword, if you enjoy a similar LRU brought about by the quick, you may find the brains to explore more efficient algorithm. Be cautious at this point, and then talk about the problems that appear to be a cow's algorithm.

In addition, while network waiting is the most time-consuming, it is easily overlooked. Because coarse looks like the network is not controllable, it has nothing to do with development. Typically, a timeout of several seconds is set, and a timeout is repeated. In fact, at home, China Mobile GRPs network dominates, so the mobile Internet is generally very slow, HTTP connection up and down 10 seconds is very normal, timeout set for 20 seconds can not be too. At the same time, according to friends of the Android application of the statistics, the user on each app startup takes about 1 minutes, theoretically there are 3 times, but a timeout (assuming 20 seconds), the user has lost confidence, will not wait again. So in the development, to combine the specific use of the scene, design data prefetching mechanism, as far as possible to reduce the number of network requests, while considering Gzip, PROTOBUF and other data compression and coding mechanism, to ensure that the data is not too large and cause additional delay.