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

A problem is found

The occupation of CPU in browsing kernel is a key factor affecting users' use, which will cause stutters in operation, power consumption of mobile phones and applications.

Problems such as collapse. Due to the influence of page, model and application framework, it is difficult to locate and optimize CPU occupancy. In the browsing kernel performance test, it is found that the CPU occupies more than the previous version. By analyzing the CPU curve, it is found that it may be caused by the lack of convergence of CPU in some scenarios, so a special test is done on the convergence of CPU.

The old test scenario-the kernel's previous test for CPU convergence was by loading the user's access to the Top 100page, and the application was put in the background to observe CPU convergence through the TOP command.

Disadvantages: 1. The testing workload is very heavy; the 2.Top page structure is complex and difficult to analyze is the non-convergence phenomenon caused by that element in the page; 3. The page changes frequently, and the convergence state is difficult to reproduce stably.

New test scheme-through the analysis of the page and communication with RD, the main problems that cause CPU non-convergence are the dynamic elements in the page, such as CSS animation, video playback, Timer timer, js loading, gif dynamic graph, etc., and the test page of dynamic elements is developed by QA to test. In the test scene, the application cuts the background and the page switches to the invisible window.

Advantages: 1. Small test workload and strong pertinence; 2. The page is fixed, the element is simple, and it is easy to reproduce. The scene is closer to the user's use.

Test results:

After completing the test with the new test scheme, the following problems are found:

Question 1: switch to invisible window scenario: test center, CSS, H5, GIF and other pages do not converge

Question 2: APP cuts the background scenario: the test center page does not converge

Second, preliminary analysis

Problem 1, through the analysis of the test results, when the user creates a blank page and switches the test page to the scene where the test page is invisible, the CPU of the page containing GIF diagram and CSS dynamic elements still fluctuates, but does not converge to 0. Here, it can be guessed that when the page is not visible, the page drawing is not pause, and the kernel judges that the page dynamic elements are updated, so the CPU is not zero.

Question 2 the test center page does not converge, the page is the navigation page of the test platform, there are no dynamic elements, but there is still non-convergence. QA analyzes the data of the page loading process through the drawing tool systrace and finds that after switching the background, the kernel's main (scheduler) / thread_proxy (cc) is working and still drawing content. It is speculated that there are two possibilities: 1.APP switch to the background, there is no pause current webview;2. Some logic on the home page of the test center caused the kernel not to be pause.

3. Business and code analysis

Kernel loading process-browsing the network part of the kernel loading page initiates a request to the network and downloads the web page resources to Loader, then HTML Parser parses HTML and Script into DOM trees, and then combines CSS cascading style sheets to generate the corresponding Render trees. The Render tree contains various attributes of each element, font, color, coordinates on the screen, length, width, and so on. The Render tree further generates Graphics Context and gives it to the platform-related graphics library to display the page on the screen. The general process is shown in the following figure, but the kernel is actually drawn while loading.

Kernel rendering process-browsing the kernel in order to reduce unnecessary rendering and ensure the speed of page rendering and the fluency of page sliding, the Render Tree is layered to make it more convenient to update the page locally. The updated layer will update the data through the synthesis composite stage, will really need to draw regional data to GL for draw, and finally complete the display of the image. The whole process is multithreaded and is driven by messages.

Because of the high update frequency, dynamic elements are usually divided into separate layer. If the update message of this layer is not paused, it will cause the message to drive the composition of layer, calculate the update area, and call drawGL to draw the image. So CPU will always be occupied.

The four truths come to light

Question one

The dynamic elements of the page do not converge, and after deleting the dynamic elements in the page, the test results are convergent, which can be proved to be caused by the dynamic elements. Dynamic elements have frequent update messages, so that the layer containing dynamic elements is constantly synthesized and drawn, resulting in the non-convergence of CPU. First of all, when you need to check whether the webview is switched to invisible by pause,webview, you should pause all page processing in order to save more CPU and memory resources to ensure the processing of the current active window.

/ / webview onPause processing public void onPause () {if (mIsPaused | | mNativeAwContents = = 0) return; mIsPaused = true; nativeSetIsPaused (mNativeAwContents, mIsPaused);}

The kernel does not pause document parsing, js loading, and motion graphics.

Solution:

/ / Network loading pause void ContentViewCoreImpl::SetIsPaused (JNIEnv* env, jobject obj, bool paused) {GetWebContents ()-> Send (new ViewMsg_SetIsPaused (GetWebContents ()-> GetRoutingID (), paused));} / / drawing pause void RenderViewImpl::OnSetIsPaused (bool paused) {if (! webview ()) return; webview ()-> setIsPaused (paused) } / / void WebViewImpl::setIsPaused (bool paused) {Document* document = page ()-> mainFrame ()-> document (); if (! document) return; if (paused) document- > suspendScheduledTasks (); else document- > resumeScheduledTasks ();}

Question two

The test center page can not converge, there are no dynamic elements on this page, so using the above method of analysis is not effective, we need to find other methods. Baidu browsing the kernel is a version developed again based on Blink 35, so want to verify whether there is a problem with the native kernel, so verify that Blink 35 and 36 are not convergent, and blink 37 can converge, so it can be concluded that it is the bug of the Blink kernel. Through the search of the code related to the drawing process, we found a comment from the google engineer on this problem.

If (RenderView* view = renderView ()) {ASSERT (! view- > needsLayout ()); view- > compositor ()-> updateCompositingLayers (); / / FIXME: we should not have any dirty bits left at this point. Unfortunately, this is not yet the case because / / the code in updateCompositingLayers sometimes creates new dirty bits when updating direct compositing reasons. / / See crbug.com/354100. View- > compositor ()-> scheduleAnimationIfNeeded ();}

As can be seen from the above notes, in the process of composing layer with updates, dirty data will be introduced to cause layer to be updated all the time, and subsequent data processing and drawing will be carried out, resulting in non-convergence of CPU. It can also be proved by adding print Log that non-convergent pages are indeed constantly calling this function.

Through the study of the patch repaired by Blink 37, the kernel modifies the state of judging the Layer update, adjusts the structure of the update judgment, deletes the scheduleAnimationIfNeeded method, judges whether the layer needs to be updated by other states, and carries on the data synthesis to draw, through the 37 patch into the test found that can effectively solve the problem of non-convergence.

Solution:

CompositingReasonFinder::requiresCompositingForPosition method is added to judge whether synthesis is needed or not.

The problem of dirty data is still not fundamentally solved, but the judgment is added, and the previous cyclic processing will not occur.

Void RenderLayerCompositor::assertNoUnresolvedDirtyBits () {ASSERT (! compositingLayersNeedRebuild ()); ASSERT (! m_needsUpdateCompositingRequirementsState); ASSERT (m_pendingUpdateType = = CompositingUpdateNone); ASSERT (! m_rootShouldAlwaysCompositeDirty); ASSERT (! m_needsToRecomputeCompositingRequirements);} five summaries

CPU convergence is a very important item in CPU performance testing, and it also has a great impact on the user experience. First of all, this case makes a great breakthrough in the test scheme of CPU convergence, discovering the non-convergence scenario through low cost; secondly, it helps RD locate the problem through the stable reproduction of bug on the test page and weak network environment, and finally finds a solution by consulting the official documents of blink kernel, code records and bug system, and improves the experience of the overall product.

Baidu MTC is the leading mobile application testing service platform in the industry, which provides solutions to the cost, technology and efficiency problems faced by developers in mobile application testing. At the same time, share the industry's leading Baidu technology, written by Baidu employees and industry leaders.

If you have any questions, please feel free to communicate with me

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.