Android mobile QQ swiped up and down to exchange the prize list in health-points mall, and found that the Web page was delayed, not smooth, and the user experience was poor. In this case, the lag problem not only appears in low-end phones, but also in the configuration of high-end hammer and LG G3 phones, which are still more serious. Therefore, we need some other methods to debug and query the performance of Web pages. The most common method is to use Chrome+DevTools. Here is a brief description of its functions and debugging methods.
Chrome uses Inspect to remoting Debug, and what you see on the phone is what you get on the PC. The following describes how to debug the WebView page of the mobile phone.
The main functions of evTools panels are as follows.
Elements as the name suggests, view page Elements, which are various DOM and CSS attributes.
Resources Various resource classes such as fonts, images, DB, and sessions can be viewed here.
Network Allows you to view all Network requests on the page, including the JS script, size, delay, and TimeLine.
Sources execution scripts can be viewed here, and support code formatting, breakpoint debugging, very easy to use.
TimeLine Allows you to view the TimeLine, Events, frames, and Memory based on the following criteria.
Profiles views CPU execution, heap, and memory allocation over a period of time.
If you want to do a good job, you must first sharpen your tools. With good debugging tools, you can start analyzing.
First of all, I suspected that there might be a problem of loading large images. Through the Resources panel, I found that there were no large images, generally PNG images between 10 and 30KB, and there were several Banner images around 10KB, all of which were loaded, about 20 pictures, so I ruled out the suspicion that large images were eating memory. The page is implemented in a lazy-hold mode. After all rewards of the integral mall are loaded, there are no additional Network requests, and the problem of Network condition can also be excluded. In cases where there is no way to determine the cause of the problem, you can use TimeLine to see where the lag occurred, as shown in the figure.
As shown in the figure, on the time axis in the box, which is the time range of the lag, there is indeed a large section of Recalculatestyle in the box, and then switch to the Events panel, the Touchend event, which occupies a long time slice. In addition, the time interval of the delay is also after the middle of the Touchend event. The following is to find out by entering the corresponding JS script. The touchend callback (_end) is just a stop operation. There is no other operation. Are there any other events that affect this function? We continue to listen for other events as well and find something suspicious, and the webkitTransitionEnd event is thrown at the page interval. The webkitTransitionEnd message causes the slider to stall before sliding to the end, as shown in the figure below.
When we remove the Banner from the Elements panel and slide the page again, the whole process is basically smooth. This seems to be the crux of the problem. Why two or more events can cause stalling remains to be analyzed. Since the page previously used the iScroll component, I’ll focus on iScroll’s TouchEnd method. Touchend is a key point and difficulty of this control. If you understand this method thoroughly, you can basically understand the whole iScroll event mechanism. The first is the initialization operation, which saves the state before the finger leaves. Determine if move is true, and if so, createEvent triggers the event. If it is not a click event, inertia moves to the target position. The first is initialization, which hides native events, which can cause invalid clicks and a blank screen if not handled properly, as shown in the figure below.
Here’s what happens when your finger leaves the screen, as shown.
Duration is the current drag event, not the finger touch to leave, because it changes every 300ms when moving. Record the current x and y positions, record the current moving position distanceY, and then reset the end time. There is a resetPosition method, as shown in the figure.
It records whether it has left the boundary, and if it has left the boundary it does not perform the following logic and resets the DOM position directly. This also uses our scrollTo method, which is particularly critical, as shown in the figure.
This method is very important, passing in distance and time, it will move to the corresponding position. Here, setTimeout is used to implement the animation scheme described above. One point needs to go back to the Start section to reconsider: why does CSS stop animation? The cause is the transitionEnd event. The transitionEnd event is triggered after the CSS transition ends. When the transition is removed before completion, such as removing the transition-property property of the CSS, the event will not be emitted, as shown in the figure.
So the second touchStart stops the animation and should be unanimated before moving. If not, slide to where you should be. Of course, the user might just want to click, which triggers the associated click event. If you need to get focus, get focus. In fact, caton’s reason is pretty much clear: the transactionEnd in the Banner breaks the animation. There are two message events that need to be processed throughout the DOM, and as a result, the slippage feels stuck and the cause is not well located. The main causes of this are as follows.
To bind event on the document, not on the specific elements of the wrap, in this way, even if another hidden elements, sliding actually was performed two logic, thus appeared the caton phenomenon, of course, if the Banner element is not visible, to release the event handlers, did not do so. The solution the developers came up with was to remove iScroll and use the native scrolling method, which proved to solve the stutter problem later.
From: wemedia.ifeng.com/54566459/we…