就可以讓微信卡頓的原理？

最近微信似乎出現(xiàn)了一個Bug，比如發(fā)一個“15。。。。。。。。。。。。。。。”（不帶引號）的符號，就會讓對方的手機(jī)卡死。

如果只是朋友之間互開玩笑，那倒也沒什么關(guān)系，要是抱著好玩的態(tài)度，發(fā)到同事的微信群里，給人家造成了困擾，豈不是開了玩笑不成反被責(zé)怪？

據(jù)一位Android應(yīng)用開發(fā)者說，這個問題的出現(xiàn)，是java.util.regex.Matcher.findNextImpl(Native method)模塊的鍋，開發(fā)人員似乎是忽視了正則匹配的問題，把匹配操作放在UI主線程里了，處理超時導(dǎo)致ANR。

原來，類似的問題，在QQ上也曾經(jīng)出現(xiàn)過，據(jù)說當(dāng)時在手機(jī)QQ上，發(fā)類似Y.oo.O.oo.z.oo.yY.oo.0.oo.z.oo.0.oo.0.oo.y.oo.z.oo.Z.oo.Z.oo.Y.oo.O.oo.Y.oo.Y.oo.Z.oo.y.oo.O.oo.o.oo.Y.oo.z.oo.y.oo.Y.oo.y.oo.y.oo.Y.oo.o.oo.0.oo.Z.oo.O.oo.o.oo.Y.oo.0.oo.0.oo.y.oo.O.oo.0.oo.Z.oo.z.oo.Y.oo.Y.oo.y.oo.Y.oo.Y.oo.z.oo.Y.oo.Y.oo.的消息，就會讓手機(jī)QQ突然崩潰，也是因為正則匹配的問題，造成的主線程/UI線程發(fā)生阻塞。

由此推斷，上述兩個讓微信/QQ突然卡死的原因，可能與長消息解析、正則匹配中的問題有關(guān)。

這從一定程度上說明了為什么類似的字符（如：OO00.oo、。。。。。。。。。。）也會產(chǎn)生同樣的效果，以及為什么這類字符長度達(dá)到一定數(shù)量才會產(chǎn)生效果。

以下是調(diào)試錯誤的代碼，想深入了解的，可以好好參考一下：

09-25 14:41:23.755 597-1157/? I/logserver: ANR, proc_name:com.tencent.mm, f1_name: at java.util.regex.Matcher.findNextImpl(Native method), topcpu_proc:com.tencent.mm 09-25 14:41:23.755 597-1157/? I/logserver: ANR, total_cpu_rate:2800, iowait_cpu_rate:40, app_version:unknownmain" prio=5 tid=1 Runnable | group="main" sCount=0 dsCount=0 obj=0x77106578 self=0xee984f00 | sysTid=19995 nice=0 cgrp=default sched=0/0 handle=0xf173e534 | state=R schedstat=( 12367079176 38333854 4748 ) utm=1177 stm=59 core=5 HZ=100 | stack=0xff13c000-0xff13e000 stackSize=8MB | held mutexes= "mutator lock"(shared held) at java.util.regex.Matcher.findNextImpl(Native method) at java.util.regex.Matcher.find(Matcher.java:437) - locked <0x0c241390> (a java.util.regex.Matcher) at com.tencent.mm.ui.widget.celltextview.g.a.o(SourceFile:96) at com.tencent.mm.ui.widget.celltextview.g.a.dc(SourceFile:55) at com.tencent.mm.ui.widget.celltextview.f.b.a(SourceFile:76) at com.tencent.mm.ui.widget.celltextview.d.a.Cw(SourceFile:467) at com.tencent.mm.ui.widget.celltextview.d.a.Cp(SourceFile:92)