據一位Android應用開發者說，這個問題的出現，是java.util.regex.Matcher.findNextImpl(Native method)模組的鍋，開發人員似乎是忽視了正則匹配的問題，把匹配操作放在UI主執行緒裡了，處理超時導致ANR。

原來，類似的問題，在QQ上也曾經出現過，據說當時在手機QQ上，發類似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.的訊息，就會讓手機QQ突然崩潰，也是因為正則匹配的問題，造成的主執行緒/UI執行緒發生阻塞。

這從一定程度上說明了為什麼類似的字元（如：OO00.oo、。。。。。。。。。。）也會產生同樣的效果，以及為什麼這類字元長度達到一定數量才會產生效果。

以下是除錯錯誤的程式碼，想深入瞭解的，可以好好參考一下：

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)

原理我不知道，我就佩服那個能發現這個bug的人

看別人說的，只要把那段資訊給覆蓋掉就好了，就是讓好多發其它訊息，把那個訊息頂掉，或者，直接刪好友，然後訊息就被清空了。