Shulou(Shulou.com)06/02 Report--

How to carry out user experience-oriented Android application development, in response to this problem, this article details the corresponding analysis and solutions, hoping to help more small partners who want to solve this problem find a simpler and easier way.

Android development is currently the "hot chicken" in mobile development, with a large number of Java programmers flocking to Android and habitually bringing desktop and web development/design experience to mobile devices. The advantage of this is that it makes full use of the commonalities between mobile development and desktop/Web services, such as commonly used components such as lists and local databases; the disadvantage is that mobile and desktop/Web use scenarios and carriers are completely different, and direct transplantation of desktop development experience is harmful.

For example, mobile phones are mainly used in fragmentation time, and users are prone to fatigue with complex interface design; at the same time, Internet access is slow in mobile environments, network connection frequency and failure retransmission mechanism design are more particular; in addition, mobile phone battery life is poor, and complex calculations in the background accelerate power consumption. These development concepts directly affect the user experience, so let's discuss how to optimize user experience in Android.

Although you don't need to know the bottom layer deeply, you need to have a basic understanding of the system. Android system layer is clear, *** layer is Linux Kernel 2.6, which contains Webkit, SQLite, OpenGL ES and other basic C/C++ libraries, while Dalvik virtual machine runs on Kernel, helping applications to perform underlying memory management (so that Android applications cannot directly release memory). These libraries are heavily used by the system on the one hand, and also provide interfaces to developers through the Framework layer on the other. In addition, the Framework layer provides other system-level services, such as message notification services, location acquisition services, device information reading services, etc.

This shows that Android is very open and flexible for developers, but it is still necessary to be careful not to be too casual when developing, so as not to make the product too complex and let users feel overwhelmed. Of course, except for a few system-level application developers who need to understand the Framework layer implementation mechanism in depth, third-party application developers generally do not need to understand each layer principle in depth, and should focus on how to understand and flexibly use the huge Android SDK API.

The following is a description of how to develop around three user feelings.

Smooth environment

It makes the user feel very smooth. Delays can leave a bad impression. When users see the App icon, they draw equal signs with "slow,""card" and "unstable" in their minds, creating "open fear."

Users feel stuck when sliding Listview, Gallery and Coverflow, mostly because the corresponding Adapter does not handle getView well enough. Each Item is bound to a data source, which can be retrieved in a variety of ways: network, local file, SQLite database, SharedPreference, and memory, with transfer times of 7 seconds, 2 seconds, 1 second, 100 milliseconds, and 5 milliseconds, respectively.

For the most time-consuming network requests, many people will operate asynchronously and not let users spend energy waiting for the network. However, in I/O and SQLite queries, the user's waiting time is easily ignored, thus reducing the smoothness of sliding. Android users often encounter ANR (Application Not Responding), which is an upgraded version of this problem. Note that Activity Manager and Window Manager monitor the response of the application, and when it finds that the processing logic has not been executed for 5 seconds after the key or touch occurs, or the BroadcastReceiver processing time exceeds 10 seconds, the system will throw an ANR error and remind the user to force the application to terminate.

My suggestions are as follows:

For operations that cannot be completed in a short time, handle them in separate threads, and Android has a variety of asynchronous processing models available, including Thread-Handler, AsyncTask, and Loader and CursorLoader.

Minimize complex calculations and reduce I/O, fully estimate the frequency of use of objects, and select appropriate data sources. Personally, I don't think there will be too many large objects in most applications, so consider caching data in memory. If there are too many images in the application that cannot be cached all the time, the LRU (Least Recently Used) algorithm can be used to clear the infrequently used cache out of memory, so that the cache size can be controlled, so that Out of Memory bugs will not occur.

However, it should be noted that the algorithm is a double-edged sword. If you enjoy the speed increase brought by LRU, you may try your best to explore more efficient algorithms. Be careful at this time, and we will talk about the problems caused by the algorithm that looks very powerful later.

In addition, network waiting, although the most time-consuming, is easily overlooked. Because at first glance the network is uncontrollable and has nothing to do with development. A timeout of a few seconds is usually set, and the timeout is retransmitted. In fact, in China, China Mobile's GRPS network dominates, so mobile Internet access is generally very slow, HTTP connection up and down 10 seconds is very normal, timeout setting 20 seconds is not too much. At the same time, according to the statistics of the use of Android applications by Friends League, the user spends about 1 minute on a startup on each app. In theory, there are 3 retransmission opportunities, but after a timeout (assuming 20 seconds), the user has lost confidence and will not wait again. Therefore, during development, we should design a data prefetching mechanism in combination with specific use scenarios to minimize the number of network requests, and consider data compression and encoding mechanisms such as gzip and protobuf to ensure that the data retrieved at one time is not too large and causes additional delay.

Android architecture

friendly experience

Unfriendly experiences come from three sources.

One is that Android fragmentation brings UI adaptation problems. There are many Android models, and compared with iPhone, interface adaptation has been criticized. To ensure that apps run on phones with different resolutions, you need to understand the automatic adaptation scheme provided by Android. In fact, the Android system has made full consideration for UI adaptation. As long as you understand the careful design of the system, you can take a lot of detours in development and provide a friendly presentation interface for users of different resolutions.

Simply put, it can be explained as follows:

Avoid absolute layouts when developing because they make your app "look good" only on the tester, and then fall apart elsewhere.

Interface control size unit multi-use DIP (Device Independent Pixels), for the same reason.

Try to use the NinePatch technology provided by the system to keep the accuracy of the same small picture on different resolutions of the screen.

The second is the abuse of notification services, which makes users easy to interrupt. Typical scenarios are various notification messages on the notification bar, and irrelevant ones are pushed, making users feel uncomfortable. It is recommended that the notification should be stopped, unless it is really useful to the user, otherwise *** let the user enter the program and then prompt.

The third problem is mainly from designers, which is to copy the design of iPhone applications. Android differs from the iPhone in system features such as stack management, menu buttons, and back buttons, and user expectations vary. For example, I've found that many designers like to ditch the back button and create a soft back button for each page, mimicking the iPhone. A forced migration that results in inconsistency with user expectations is a complete design failure.

save power

Devices that have to be plugged into the wall at all times to charge are not mobile devices. If your App keeps users in the corner, users will quickly throw you in the corner. You ask,"How does he know my app consumes electricity? "Sorry, at present, Android users have a large number of enthusiasts and technical experts, and the system is very rude to record the power consumption of each application, so users will occasionally go to the system background to check the power consumption, and then will open the uninstall tool.

Therefore, the following points should be noted:

First, don't rack your brains to design complex algorithms, don't run services in the background, don't try again when the network is disconnected. Before developing a module, think about whether it will cost electricity. If it does, don't do it. Code is meant to serve users, not to annoy them.

Experts like challenges, especially when implementing sophisticated algorithms on mobile phones, which can bring a stronger sense of conquest. Bloom filters have been implemented on mobile phones (a large and elaborate hash-like table, mostly used on the server side, such as spam lookups), which consume much more memory and compute complexity than ordinary HashMaps, and are not easy to implement. As a result, after the App was released, users complained about high power consumption and frequent bugs, or honestly changed to HashMap. The purpose of any algorithm is to serve users, and if simple, natural methods can do that better, why not? If you really can't find a simple algorithm on the client side, you need to reflect-why do you need complex calculations on mobile phones? Should these calculations be placed on the server side?

Second, do not abuse Service in the background. Android is very open, developers can trigger any processing logic in the background, arbitrarily hogging CPU and memory. In general, the purpose of a Service is to monitor changes, including system and network changes. System changes can be controlled by registering BroadcastReceiver to listen for events such as application installation and uninstallation, which consumes very little power and can completely replace carousel in Service. Network requests cannot be listened to with BroadcastReceiver, but there are two suggestions.

No strict real-time requirements, can extend the carousel interval, such as automatic request once every 6 hours, and the time interval can be updated online through the server. This saves power and occasionally adjusts the time interval online when real-time push is urgently needed.

For real-time requirements, consider using mature push services.

Third, network requests should not be too frequent. The most power-hungry component of the system is the screen, followed by the network. Network error retransmissions degrade the user experience and consume power. The number of network requests can be reduced by combining data prefetching with data compression algorithms.

About how to carry out user experience-oriented Android application development questions to share here, I hope the above content can have some help for everyone, if you still have a lot of doubts not solved, you can pay attention to the industry information channel to learn more related knowledge.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.