An example of app Dayton in Android

answered a question about "why Weibo apps are smoother on iphone than Android". The latter part is a typical performance analysis process for the animation, so post it here. There are programming problems that can be exchanged here. Know the link.

=========================================================

I'm going to tell you what I know. I don't know why iOS is fluent, but I know some of the reasons why Android isn't fluent.

First of all, on the subject of the question, I used the ipad and Xiaomi pad to compare the micro-bo slide scrolling This thing (August 10, 2014, the latest version of the microblog app). As the Lord says, the intuitive feeling clearly feels like iOS should be smooth and comfortable.

In this case I think the main reason is these three reasons:

1. Speed curve.
   When you swipe the interface and then let go, the interface continues to slide, and then the speed decreases until the speed is 0 o'clock stop. The slow speed of this process is slower in iOS, especially when it is going to stop slowly, and visually there is a very smooth feeling; Android is a lot quicker from letting go to stopping, compared to a sudden stop feeling.
   From a data/technical point of view, the ultimate goal of our sliding interface is not to "move", but to "stop", so as long as the smooth arrival of the destination, it seems that the faster the process of completing the procedure, so the choice of Android is taken for granted. But the truth is that people generally prefer the way iOS does, which makes them smoother and more elegant.
2. Frame rate.
   Most of the time, both can maintain a full frame rate of around 60FPS. But there will be occasional drops of frames. And it's much more serious on Android than on iOS. (Well, it's a lot better than it was two years ago.) I slipped back and forth dozens of times, and iOS encountered 1 dropped frames in front of me, and it was stable. While Android almost every time it slips, it will be accompanied by a drop frame. This is the real reality of the lag, users will feel that the moment is not smooth. The reason why Android dropped the frame after I detailed analysis.
3. Touch response speed.
   It takes time to touch the touchscreen from your finger to the screen to show that the screen is being processed to produce the touch. The shorter the time, the more hands you feel. It is said that iOS touch screen processing time than the average Android phone faster, this is not my specialty, do not know how to verify. But at the software system level, the Android display mechanism is App-->surfaceflinger-->display, this is a step more than the traditional app-->display, mainly for this reason, The final output of the screen is slower than the traditional way (16.7ms).

I think the 1th is the biggest impact, but the most technical/equipment-independent. If the microblogging app or Android system is to change, it's easy to adjust to iOS. But it is because of the difference in product form rather than purely technical merits that it becomes the most unlikely change for Android.

The 2nd effect is, of course, the case of a full frame at this point in time. This is the most obvious aspect of Android from the early to the present, using a number of methods to optimize the frame rate. But even now Android has evolved a lot, hardware performance has evolved a lot, but it is still impossible to completely eliminate the situation of frame.

The 3rd popular talk is with the hand nature, with the importance of the hand is self-evident, but now the difference is more subtle, and the specific data I do not know.
I thought of a way to make the desktop, Weibo this content and hand to move the application to draw to the screen speed of a frame (16.7ms), in fact, is to counteract the earlier mentioned slow that frame, need the framework layer and the app layer together with the changes, has applied for a patent but the code has not yet entered, there will be time in the future should be into the MIUI. Interested can look at the patent: Sliding operation response method, device and terminal equipment.

Finally, let me analyze the reasons why the Weibo app dropped frames in Android. Non-programmers can not look down. (This process I am using the Xiaomi 3 Qualcomm version + the latest version of the microblog app.) ）

At first, I thought it was like GC (garbage collection), so I opened logcat to see if there were any GC occurrences at each lag. The results were not found. There is a GC when it stops, which means that the microblog app is well-controlled during the swipe process, allocating memory at the moment it stops, leaving the GC unaffected by the frame rate.

Then I open "developer Options", "GPU Rendering Mode Analysis", "Display as a bar on the screen" (as if the option is 4.4, previously only seen in Dumpsys), this will be on the screen visually display the time spent on each frame drawing. On the screen there is a baseline of about 16ms, if more than this line is likely to drop the frame. If the blue section below is long enough to indicate that the part of the software draw is too time consuming, you can continue to analyze draw's Java code through TraceView. (I assume the current app is a hardware-accelerated approach.) If the middle red part is long, it is too time-consuming for the OpenGL ES drawing process. You can use Gltrace to analyze the calling process of OpenGL ES.
Using the Weibo app after opening the options, I found that although there were occasional super-baselines, it was not serious, and there was no obvious abnormality in the lag.

So I started using systrace, which is pretty obvious:

Can be found every few frames, there will be a large gap, the figure I circled the red circle of the two places are significantly more than the normal time spent. Now the question is, what are the code in these places doing? What took so long?

After zooming in, we found all two of these: Obtainview and Setuplistitem. They are all called before draw, which also explains why the previous step ("GPU Rendering Mode Analysis") is not shown because the method only shows the time consumption in draw.
By searching the source code for Obtainview and Setuplistitem, you can find the Abslistview Obtainview method and the Setupchild method of the ListView to lay this log.

Next, we'll use TraceView to see what code is being called in these two methods, resulting in a lengthy process.
Trace Obtainview finally arrived here:

Code confusion, see not too out, also lazy to follow down. But just a little bit and see:

Textview.settext used quite a lot of time. Feel that the Android team should optimize this method for optimization.
Then follow the Setupchild method:

The

is the time that measure takes and the number of calls is greater. This should show that there are a lot of view. Looked at with Hierarchyviewer, indeed many, a micro-blog has more than 50 view:

Conclusion: We finally found the time-consuming code and some reasons. Both of these time-consuming methods should be likely to be reduced, but should not be so easy. The
is easier to implement on Android, but if the default implementation has a performance problem, it's not a good idea to fix it, sometimes it's a long way off.


Finally, some related links are listed:
Android Graphics Architecture (something to say here is a slow frame): http:// Source.android.com/devices/graphics/architecture.html
Android Performance case Study:http://www. Curious-creature.org/docs/android-performance-case-study-1.html