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, to help the application of the underlying memory management ( This makes it impossible for Android applications to 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.

Android Diagram (Image source: http://developer.Android.com/guide/basics/what-is-Android.html)

A friendly experience

The unfriendly experience comes from three aspects.

One is that the fragmentation of Android brings the UI adaptation problem. There are many Android models, and interface adaptation is a lot of criticism compared to the iphone. To ensure that applications run on different resolution phones, you need to understand the automatic adaptation program that Android offers. In fact, the Android system for UI adaptation has been fully considered, as long as the understanding of the system carefully designed, it can be in the development of a lot less detours, to the different resolution of the user to provide a friendly rendering interface.

In simple terms, it can be explained as follows:

Avoid absolute layout when developing (Absolutelayout), as this will allow your application to "look beautiful" on the test machine and disorder it elsewhere.

Interface Control size unit more use Dip (Device independent Pixels), the reason ditto.

The picture tries to use the system to provide the Ninepatch technology, can make the same small picture to be able to maintain the accuracy free scaling on the different resolution screen.

The second is the misuse of the notification service, which causes users to be easily interrupted. The typical scene is a variety of notification messages on the notification bar, all related to the push, so that users feel unwell. The suggestion is that the notice is enough, unless the user is really useful information, it is best to let users enter the program after the prompts.

The third is mainly from the designer's problem, is to copy the iphone application design. Android's system features are different from the iphone, such as a program's stack-style management mechanism, menu buttons, and return buttons, so the user's expectations vary. For example, I found that many designers like to discard the return key, imitate the iphone to design a soft return button for each page. A blunt, contrived transplant can lead to inconsistent user expectations and a complete design failure.

Save Electricity

Devices that have to be plugged into the wall at any time, not mobile devices. If your app keeps users in the corner, users will soon throw you into the corner. You ask, "How does he know that my application consumes power?" I'm sorry, at the moment, the Android users have a large number of enthusiasts and technical experts, while the system is very blunt record of the power consumption of each application, so the user occasionally go to the system backstage check the power consumption, and then open the Uninstall tool without any polite.

Therefore, the following points should be noted:

First, do not rack your brains to design complex algorithms, do not run the service in the background, do not break the network has been repeatedly tried. Before you develop a module, think about whether it will cost electricity, and if it does, don't do it. The code is intended to serve the user rather than toss the user.

Experts like challenges, especially on the mobile phone to achieve sophisticated algorithms, so as to bring a stronger sense of conquest. Someone has implemented the Prum filter on the phone (a large and sophisticated class hash table, used on the server side such as spam search), its memory consumption and computational complexity is much higher than the ordinary hashmap, and implementation is not easy. Results after the release of the app, users complained about the power consumption, and often bugs, and finally the honest replaced HashMap. The purpose of any algorithm is to serve the users, if the simple and natural way to do this better, why not? If you really can't find a simple algorithm on the client, you need to rethink-why do you need a complex calculation on your phone? Should I put these calculations on the server side?

Second, do not misuse the service in the background. Android is very open, and developers can trigger any processing logic in the background, consuming CPU and memory indiscriminately. In general, the purpose of service is to monitor changes, including system and network changes. System changes can be registered Broadcastreceiver monitoring control, such as the application of installation and uninstall, such as events, so the power consumption is very small, completely alternative to the service in the carousel. Network requests cannot be monitored with broadcastreceiver, but there are two recommendations.

No stringent real-time requirements, can extend the carousel interval, such as 6-hour automatic request once, while the time interval can be updated through the server online. This saves electricity and occasionally requires real-time push to adjust time intervals online.

For real-time, consider using mature push services, such as Google's C2DM (http://code.google.com/Android/c2dm/), and Amazon's AWS SDK (http://aws.amazon.com/ Sdkforandroid/).

Third, the network request not too frequently. The most power consumption in the system component is the screen, followed by the network. As mentioned earlier, a network error restart can reduce the user experience and consume power. Data prefetching combined with data compression algorithm can reduce the number of network requests.

All in all, we need to think about whether we have done a "smooth, friendly, power saving" for our users in the development to ensure that the app has a good user experience.

The author, Chen, has been working in Microsoft Research, engaged in data mining and machine learning related studies, on spatio-temporal data mining, pervasive computing and other fields have in-depth understanding. Joined the League of Friends in April 2010, began to build a friendship Alliance mobile development Platform.

Source: Programmer's website