Google developing for Android one-relevant context description

A few days ago in g+ see Google developers site, there is an Android series of articles, share to personal Weibo, weekend idle to learn to write the next, the simple translation of the next, did not expect a out of hand, six articles are all translated, Some places omit the description of some examples or change another expression, and if there is an inaccurate understanding of the place, still look.

Original: Developing for Android, i:understanding the Mobile Context

Context or why these suggestions are so important

It is important to understand the context in which these best practices are relevant. In particular, there are some serious restrictions on the mobile side, and the desktop and server-side computing is completely different. Therefore, if these restrictions are not taken into account when developing an application, it will result in significant performance problems and memory consumption, not for one application, but for the entire device, as many apps with the same performance problems have resulted in a poorly performing device.
The following are important constraints, limitations, and realities that are important in the past and future mobile devices.

The memory of the mobile device is very limited. Not all devices, of course, but this is true for most mobile systems. For developers, the phones we use may be faster, better, and newer than most users now or in the future use of devices. For example, having a Nexus 5 with 1GB-2GB memory is reasonable for us, 512M memory-configured handsets are common in the US as well as in some emerging low-end markets. Therefore, it is unrealistic to measure an app with 2GB or larger memory standards.
It is also important to understand that Android will run multiple activity and multiple concurrent service. The way to switch to the recent app list instead of restarting an app is important for creating a great experience. But this means that if these apps consume more memory than they should have, the system memory left to other applications is scarce. If this low-memory situation occurs, the application will not be kept in the background, the system will kill the app process, the user is forced to restart the way to open an app, obviously this experience is poor.

Even the highest-level mobile device has a much slower CPU than a desktop device. Of course even if you realize this, you should also consider the majority of users who use slower CPUs than you. The recommendations for memory also apply to CPUs: The world's low-end devices are being sold, so do not benchmark your own relatively good device performance, as running on most devices with slower processors and lower memory configurations is very different.
Another problem is that CPU processors are not always kept at maximum speed. When the system thinks that the heat level of the battery reaches the critical point, it will cause the CPU to reduce frequency. In general, these situations occur when the user may not notice, such as the screen is off, or the input event is not responding, or the animation is no longer running. Frequency reduction has two implications for apps: (1) Your app may slow down in many cases, so even a good CPU, you can only get a limited speed (2) Your app may have done something to prevent the CPU from falling, Make the CPU always in a state of maximum processing speed (for example, frequent, prolonged, or endless animations should be avoided because during animation, in order to make the animation smoother, the system will attempt to run at maximum power). Obviously, you don't want to weigh the effects of higher CPU rates and usage on reducing battery life, so try to avoid them when you don't need them.

The GPU performance recommendations are similar to CPUs, and there are some additional areas to note:

• Upload is resource-intensive
  Uploading large textures (bitmap) on any system is more resource-intensive, and the larger the bitmap, the longer the operation time. Therefore, this means that frequent large bitmap related large graphical operations can cause performance problems, such as bitmap,paths (which can be rasterized into bitmap), and a large number to new or different text (there is a problem that is caused by a large number of non-English character sets)

• The problem we usually face is not the geometry of the drawing, even some of the texture of the drawing, but a large number of pixels to fill the high-resolution device. These high-resolution screens cause a performance problem because the hardware is not able to fill so many pixels in one frame of the animation. The more common is the transition drawing, which causes the application to redraw the same area multiple times due to overlapping content, such as the window background, the content background, and some translucent view.

Memory = = Performance

In this series, many of the guidance is discussed around the use of memory. It is important, however, that memory is tightly correlated with performance during operation and battery life. Because the more memory you allocate, the more work your device needs to do for your application. Memory allocation and recycling increases the activity during the run. Large heap memory means that your app consumes more memory, but the overall memory of the device is reduced, causing other activities to be forced to reduce their memory overhead, or be killed directly, which will result in the overall performance of the device as the user switches between different activities. And these activity needs to be restarted. More heaps also results in longer GC interrupts, because a larger heap memory can cause memory allocations and recoveries to take longer. All of these behaviors consume more power, because the more work the device does, the more the battery is consumed and the more limited.

So many of the articles in this series involve performance issues, and the fact is that these technologies are important for writing a good app.

So the point of this document's best practice is not that memory is performance, but that these techniques are necessary to write a good app.

Many of the above sections also mention that developers use devices that are likely to be better than most future users. While the 2GB is already in the mainstream in 2015, many of the world's emerging markets still sell 512M of equipment.

Smoother frame rate

The best experience for Android is a frame rate of less than 16 milliseconds. This means that the application must complete all input, layout, drawing, and all other things within 16 milliseconds. This speed allows the system to render at 60 frames at fantastic speed during animation and input events. The animation must be able to finish the necessary part of the redraw in 60 frame rate time to complete the smoothing of the dynamic effect. The problem is that many applications can usually render within 16ms, but it discards the current frame, and then does not continue to the previous frame rate, which can easily be noticed by the user.

A smooth completion of a frame means that any special frame needs to execute all the rendering code (including the one that the framework sends to the GPU and the CPU draws to the buffer) to be completed within 16MS. This is why even 5ms lost in garbage collection events can have a big impact. Because it severely limits the remaining draw time in a frame of time. The closer you get to 16ms, the easier it will be to cause the garbage collection event to trigger.

The buffer can only be

There are two operating environments that need to be major: Dalvik and art. Before the 5.0 release, Android uses Dalvik. Developers can choose art to test in version 4.4. But it will only run in 5.0 of the system.

Dalvik is a JIT compiler that can perform some fine optimizations, but it is different from many other JIT compilers. Art is a ahead-of-time compiler that will do more optimizations than Dalvik. However, the level of optimization offered by Dalvik or art is different from the server and desktop operating platforms. Examples include methods for inline and escape analysis. There are some inline, art will be executed on the leaf method, but further optimizations will only be possible in future versions, as there is a new optimization compiler in the future. Because app developers may need to support older versions, they need to continue to be concerned with the limitations of the current and previous compilers.

In general, art performance is higher than Dalvik 30-200+%. The art compiler performs more optimizations, such as the distribution of substantial elevation interfaces. Art is optimized to a greater extent and memory allocation is faster. Eventually, the threads of the application are less subject to garbage collection and fewer interruptions.

Garbage collector

The garbage collector is a process that frees memory that is no longer referenced by running. GC is also one of the causes of serious performance problems, and if the GC does more work than is necessary, the less time is left to apply the smoothed frame rate.

The garbage collector in Dalvik and art is essentially different. One of the main differences is that Dalvik is not a mobile collector. This means that all assigned objects will stay in the same place in the heap, which is more difficult and time-consuming for Dalvik to find the allocated memory for new objects, especially when the heap is grainy and fragmented and a large number of objects are in dire need of memory. Heap fragmentation can also cause the GC to break more frequently because Dalvik tries to clean up the heap from those that are useless. These GC interrupts are very resource-intensive and, under normal circumstances, a faster mobile phone can easily consume 10-20ms time. It is important that the garbage collection time is proportional to the number of objects in the heap, which is another reason to avoid allocating objects as much as possible.

Art will dynamically increase the efficiency of garbage collection. For example, art is a mobile garbage collector that makes the heap compact without impacting the user's experience when the application is long-time single-aborted. Also, there are separate heap for large objects, such as bitmap, where art will find memory faster rather than an orderly traversal of the fragmented heap. Interruptions in art are usually between 2-3ms.

Although art has a big performance boost compared to Dalvik's garbage collection. But while writing the Android app, it's still important to note that even the 2-3ms time is sufficient for exceeding the 16ms frame rate limit. Therefore, although garbage collection is no longer a resource-intensive behavior after 5.0, it is always necessary to avoid it as much as possible, especially in the case of animations, which can lead to some dropped frames that make the user feel noticeably.

UI Thread

Many of the performance and lag issues are due to the amount of work we do in the UI thread. Android is a standalone thread of the UI system, where all the actions that occur on the view, including the drawing of the view, occur on the activity's UI thread. Any action that occurs on the same UI thread, even if the view is drawn, can cause stuttering because it does not have time to achieve a smooth frame rate in 16ms of time.

In version 5.0, the framework introduced "Render Thread", which is used to send actual rendering operations to the GPU. This thread mitigates some of the UI thread reduction operations. But the input, scrolling, and animation are still in the UI thread, because the thread must be able to respond to the operation.

The metrics stored are different on different Android devices, but they may be slow and restricted. Mobile devices are only 8G (2015, common in less-than-mid-level devices) or even 4G with a sdcard, to store the entire system, all applications and all the audio are easily filled. In this case, an app may cause the user to delete other content for it to get more space, or to unload it directly because there is enough space for each.

Storage performance is also a point to be concerned about. Mobile devices and desktop devices are quite different than hard drives.

It is also important to note that external storage sdcard memory may have significant uncertainties in I/O performance, depending on the vendor, chip, and speed indicators. But apps should not prevent users from using SDcard, because many devices do have small memory and need it as an extension.

It is easy to have some modern infrastructure and mobile networks in most software developers in the city. However, many other areas do not have such facilities. Not to mention LTE or 4 G. Many countries have a 2G network and may have to withstand large amounts of data transmission. This can lead to two common problems:

• Relies on fast network speed
  Apps that rely heavily on big media data (video,audio,images) may not have a choice where the network base is poor. But avoid downloading until the conditions allow to download it is also part of the app experience

• Multi-degree synchronization
  Maybe your app wants to update some information, but the user doesn't need it, and the more important question is that the device should not be able to withstand the constant interaction of all applications with the network. This dynamic makes it easy for the device to continue working without being able to hibernate, ultimately affecting battery life.

Every single device is a village.

Many apps are installed on the user's device, including the system's UI and the Launcher app. If your app uses more resources (memory, CPU,GPU, battery), the less other apps will be, the worse the device will be for the user to present. 如果你的处理越多，当系统需要更多内存的时候，就越有可能试图从内存中干掉它, that means your app will take longer to open, which can lead to a bad experience.

So, be a good citizen on Android devices. It's what every app should do, because if every app is greedy, the ultimate pain is the device and the user.

The disaster of the civilian population

The biggest problem with mobile devices is that some apps that are interested in their activities lead to the overall performance and experience of the device. Analyzing a specific app may not be the hallmark issue that the app needs to fix. However, the overall impact on the device, all apps are subject to resource constraints, the end-user experience is poor.

A good example is to see if an app is syncing too often. That means that a particular application is accessing the server at a specific frequency. But if the user has more than 100 applications to do so, compared to those of the delay, batch synchronization system, the result is that the device will never be able to hibernate and run out of power soon.

Google developing for Android one-relevant context description