1. Wechat is super Bug
Hello, everyone, introduce to you, this is the Bug:
Many Android users should be familiar with the above diagram.
(synchronous published in this article: http://www.52im.net/thread-1099-1-1.html)
2. Event background
A few days before the National Day, a large number of wechat Android users reported receiving or sending similar “15… Messages cause the wechat chat interface to freeze and the app to crash. This is a very serious matter for wechat, and the feedback will soon be overwhelming. When we learned of this problem, we immediately repaired the problem and covered most users of the whole network within two days, and finally the problem was solved. Trace back to the source, there is no doubt that the pot development younger brother to back, this time can not be wronged the product MM ha ha.
At the same time, many enthusiastic netizens also began to analyze the cause. On the day of 25th, a great god in the industry worked out the root of the ANR step by step through the ANR log and decompilation debug, and gave the cause of the stuck. Please accept a little brother worship, really admire!
Details refer to link: http://androidwing.net/index.php/243
The figure below is the analysis result of netizens:
According to the user’s analysis, the real reason for the deadlock is: “the WWK is always equal to 0, that is, it does not meet the null condition of dVar2 inside the while, which causes the while loop”. How do you do dynamic decompilation here?
The zhihu answer very detailed: https://www.zhihu.com/question/65828771
3. The real reason
The real reason, as analyzed by netizens, is mainly stuck in the while loop, which is mainly used to break the current text content according to specific rules, as shown in the picture below.
Because dVar2 and dvar2. getText are never empty, this condition is always satisfied, so an infinite loop is created.
The condition that dVar2 is null depends on the following function:
Dvar2.getlength () is actually the text length of the current line. Here, because of the bug of the sentence breaking algorithm, the variable “i4” keeps returning 0, while the current line text length dvar2.getLength() is >0. So this dVar2 will never be assigned to null.
To get to the bottom of the question: why does the clause breaker keep returning 0? It actually calls the following function:
This function returns an object a that takes two arguments, the position of the break (a.wwk) and the length of the text after the break (a.width). This is mainly because the last non-punctuation character on the current line needs to be truncated to the next line when judging the newline because of the rule that punctuation should not be at the beginning of the line. Truncation is restricted by another rule, which states that truncation cannot be English or numeric, resulting in “15…” Finally, the truncated position is returned as 0, and the result is returned, so the endless loop is generated, causing this bug.
So here’s the problem
Many netizens also began to discuss, why typesetting their own, put a good system TextView does not need? What’s so good about it? What was the effect?
Don’t worry, let my little brother explain the ins and outs of many problems one by one.
5. Why this demand?
In fact, most of the world’s demand comes from users. This demand also benefits from several users who will feedback that “wechat Android chat bubbles seem not as beautiful as iOS, more rigid”. This issue has also caught our attention.
Is that the case? We compared iOS and Android, as shown below:
IOS looks better than Android, at least there’s not as much padding on the far right. Simply speaking, the extra padding is caused by the bubble width being limited by the screen size, so TextView is the bubble with the maximum width limit. The problem arises when system typography chooses to wrap lines when there is not enough space left for a single character.
6. Another question
Is the typography perfect on iOS? A closer look at the picture shows that it’s not. IOS also has this problem, which is that the text in the bubble is uneven.
At first we wondered if it was the wechat app itself that was using the component incorrectly, rather than the system component. As a result, on mobile phones, we randomly found some popular apps and carefully compared, the same problem still exists.
Zhihu:
The nuggets:
Pay treasure:
Wait…
And in addition to mobile, there are also problems on PCS. Combined with these comparisons, it’s true that most apps on the market have this problem. Through this feedback, we began to think about whether we could make text typesetting on mobile client more humanized and have a better experience. . On this issue, we found the design students together to discuss, think it is really necessary. So the next step began.
7. How to arrange typesetting?
For text typesetting, it is easy to think of, “my (Word) brother”, Microsoft for this application, do you have any method or scheme for text left and right alignment reference?
The following is the left alignment effect of Word, which is the default TextView on Android:
The image below shows the centered ‘hard’ alignment of Word:
The image below shows the centered ‘soft’ alignment of Word:
From this point of view, “soft alignment” is more aesthetically pleasing and has the best experience. The only way we can think of to achieve this effect is to dynamically adjust the spacing between words (which is what Word does).
So if you want to adjust the font spacing dynamically, can you just do that? The answer, of course, is not, if it’s like ‘hard alignment,’ it’s too blunt.
We will discuss this problem with the design team colleagues, through their research and attempt to come up with a reasonable solution, that is allowed to have an English character width adjusting range, will adjust the width of the average allocation to the current line each character, influence is the smallest for users, but also keep some beautiful.
Practice custom typesetting
For Android, it is not difficult to implement this rule, either to transform the system TextView, or to write a custom view to achieve text typesetting and rendering, we finally adopted the latter scheme.
Here’s why:
The logic of typesetting and drawing of TextView is not in itself, but given to three subclasses that inherit Layout, namely StaticLayout, DynamicLayout and BoringLayout. StaticLayout is more commonly used. It is only responsible for static word processing, about the difference between the respective Layout, here will not expand. The system TextView does not expose interfaces to proxy them. Of course, just because we don’t have an interface doesn’t mean we can’t do it, we can proxy it by means of reflection and so on, but in fact, to do so, the cost is relatively high.
There are three reasons:
1) Firstly:From Android 2.3 to Android 8.0, although the TextView code will not change much, but from the Layout point of view, the implementation of logic or interface have changed, if through this way, the proxy compatibility will be a problem;
2) Second:TextView is one of the most complex components of Android. Several Layout logic codes are very complex. It is a complicated and heavy work to implement all Layout interfaces by ourselves.
3) Third:In fact, their own implementation of a Layout, basically to achieve a display component, Layout and rendering are to deal with, so this implementation is not significant, even not flexible.
Returning to the topic, we compared the rules of TextView system, and finally determined the following rules:
1.A maximum of one letter character width is allowed to adjust word spacing;
2,Avoid punctuation at the beginning of the line;
3,Do not truncate typesetting for English words or numbers.
So we started with a simple demo implementation. The effect is shown below:
Compared to the effect before optimization, the effect is indeed obvious. However, after careful observation, it is still found that for some special Chinese full-corner symbols (such as “” () [], etc.), because of the existence of redundant padding, placing them at the beginning and end of the line will also lead to uneven effect.
So we added another rule:
For some common full-corner symbols with extra padding at the beginning or end of a line, the default is to subtract the extra padding for better alignment.
The final optimization effect is shown as follows:
The last one is a rendering with the four rules applied, and the overall text alignment is much better than the system’s default typography.
The problem comes again
So since the results are good, are there any other problems? That’s true.
9.1 Minor language processing problems
Because wechat supports small languages, for some special small languages, such as Thai, Arabic, etc., the typesetting method of Thai is not simply horizontal, there is a top-down relationship between characters, but for Arabic, it is arranged from right to left. If only according to the above several rules, then typesetting after the effect is certainly unreasonable.
Considering the small language diversity, typesetting rules are not unified, and the use of small language user scale is small, but also can’t let its typographical errors, so in this case, we through a simple regular expression to match whether belong to within the scope of string can handle, which is why netizens to analyze 15 “……” This event is initially suspected to be caused by the length of the re match.
The following is the user’s analysis:
In fact, this simple regular expression, as the user tested, is very fast to process, basically within 1ms, the impact on performance is negligible. After judging by the re, if it is a string that can be processed, the above rules will be applied to typesetting. If it is a special string, it will be displayed by the system’s TextView agent.
9.2 Compatibility Problem
Now that the problem of small languages can be solved, the question arises: how often do people on the Internet use special characters? This question is directly related to the fit rate of our composition component, that is, how much it improves the user experience? In our opinion, ordinary people do not send some strange symbols in wechat, so it should be the majority of people who can apply this layout rule. Of course, this is just a guess, and it would be premature to determine the feasibility.
Therefore, we conducted a round of grayscale for this problem, and the grayscale results are as follows:
Through the gray scale, the users of the live network can apply the adaption of this component to achieve the expected results.
9.3 Performance Problems
It is also not desirable if the performance of the component is too different from that of the system, or even seriously affects the frame rate and causes users to run out of time. To solve this problem, we carried out local automatic frame rate test and function comparison with system TextView.
The following figure is the experimental data:
Conclusion:
On the micro level:By function comparison, CellTextView comparison system TextView performance is slightly worse 2 times, the main gap lies in the need to adjust the spacing of single words when drawing text;
On the macro level:CellTextView has a small effect on the actual frame rate, and users have no obvious perception of performance deterioration.
Through the above attempts and gray results, it is actually meaningful to do this thing, so the optimization scheme was finally finalized.
10. The end of the event
This is the context of the whole requirement. In fact, sorting out the context of this process can not only help me to reflect on some problems existing in the process, but also, because this bug has really caused a bad impact on everyone (really deeply sorry!). “, so that you can understand how this thing happened, at least you don’t get stuck in the dark.
You have to be very careful when writing code. Remember the pain this time, a fall into the pit, a gain in your wit. Wish the world’s programs all without bugs. No, nothing!
Finally, paste an optimized effect diagram:
Article write bad place, hope forgive, big god don’t spray don’t spray. I’m gonna take the fall for this, buddy.
(Original link: click here to enter)
Appendix: more wechat, QQ technical articles summary
[1] Technical articles on QQ and wechat:
”
Wechat team revealed: wechat interface stuck super bug “15…” The ins and outs of”
”
QQ 18 years: Decrypt 800 million months of QQ background service interface isolation technology”
”
How does the super IM wechat with a monthly life of 889 million carry out Android compatibility test”
”
Discussion on “Light Application” in MOBILE IM by Taking MOBILE QQ as an Example”
”
Get wechat open source mobile database component WCDB everything!”
”
Technical interview with wechat Client Team leader: How to start client performance Monitoring and optimization”
”
Design practice of time-sequence-based cold and hot classification architecture for massive data in wechat background”
”
Wechat team original sharing: Android version of wechat bloated trapped and modular practice road”
”
Wechat background team: sharing the optimization and upgrade practice of wechat background asynchronous message queue”
”
Wechat team original share: wechat client SQLite database damage repair practice”
”
Tencent original share (a) : how to greatly improve the mobile QQ picture transmission speed and success rate under the mobile network”
”
(2) How to greatly reduce the Traffic consumption of APP in mobile Network (Part 2)”
”
How to greatly reduce APP traffic Consumption in mobile Network (Part 1)”
”
Wechat Mars: network layer encapsulation library being used inside wechat, which will be open source”
”
As promised: Mars, a cross-platform component library for wechat’s mobile IM network layer, has been officially open source”
”
Open source Libco library: the foundation of background framework supporting 800 million users of wechat”
”
Wechat new generation communication security solution: MMTLS based on TLS1.3”
”
Wechat team original sharing: Android version of wechat background to keep alive combat sharing (process to keep alive)”
”
Wechat team original sharing: Android version of wechat background to live combat sharing (network to live)”
”
The evolution of wechat for Android from 300KB to 30MB”
”
Wechat’s technical evolution from 300KB to 30MB for Android”
”
Speech by technical Director of wechat on Architecture: The Way of wechat — Avenue to Simplicity”
”
Wechat Technical Director’s Talk on Architecture: The Way of wechat — Avenue to Simplicity (PPT presentation)”
”
How to interpret “wechat Technical Director on Architecture: The Way of wechat — The Road to Simplicity””
”
Background system storage architecture behind massive wechat users (Video +PPT)”
”
Wechat asynchronous transformation practice: background solution behind 800 million monthly live, single machine 10 million connections”
”
Wechat Moments of mass technology PPT [Attachment download]”
”
Technical Experiment and Analysis of wechat’s Influence on Network”
”
A summary note of wechat background technology architecture”
”
The way of architecture: 3 programmers have achieved 1 billion daily releases in wechat Moments ”
”
Fast Fission: Witness the evolution of wechat’s powerful background architecture from 0 to 1 (I)”
”
Fast Fission: Witness the evolution of wechat’s powerful background architecture from 0 to 1 (II)”
”
Android memory leak monitoring and optimization tips summary”
”
A comprehensive summary of iOS version wechat upgrade iOS9 encountered a variety of “pit””
”
Wechat team original resource confusion tool: reduce your APK by 1M immediately”
”
Android source obfuscation tool: AndResGuard”
”
Android version of wechat installation package “weight loss” combat record”
”
IOS version of wechat installation package “weight loss” combat record”
”
Mobile IM practice: iOS version of wechat interface lag monitoring scheme”
”
Technical difficulties behind wechat’s “red envelope photos””
”
Mobile IM practice: iOS version oF wechat small video function technical scheme record”
”
Mobile IM Practice: How to greatly improve the Interactive performance of wechat on Android (I)”
”
Mobile IM Practice: How to greatly improve the Interactive Performance of wechat on Android (II)”
”
Mobile IM practice: To realize the intelligent heartbeat mechanism of wechat on Android”
”
Mobile IM practice: Analysis of heartbeat strategy of WhatsApp, Line and wechat”
”
Mobile IM Practices: A Study of Google’s Push Messaging Service (GCM) (from wechat)”
”
Mobile IM practice: Discussion on multi-device font adaptation scheme of iOS version wechat”
”
Walk through the APNS pit on iOS10 together”
”
Tencent carrier pigeon technology sharing: ten billion real time message push experience”
>>
More of the same…
[2] Technical stories about QQ and wechat:
”
Technology past: Tencent in the early stage of business – 16 years ago in the winter, who moved ma Huateng’s code”
”
Technical past: the most complete QQ icon change process in history, tracing the evolution history of IM giants”
”
Technology past: how do “QQ group” and “wechat red envelope” come from?”
”
Development past: the depth of 2010 to 2015, wechat all the way behind the wind and rain”
”
Development of the past: wechat millennium unchanged that flash screen picture origin”
”
Development past: Record the story behind wechat 3.0 (9 months after the release of wechat 1.0)”
”
A wechat intern: The wechat development team in my eyes”
”
First revealed: QQ real-time video chat behind the mysterious organization”
>>
More of the same…
(synchronous published in this article: http://www.52im.net/thread-1099-1-1.html)