原創 王小二的技術棧
如果問我什麼ANR問題最難解，那肯定是no focus window anr。
這個anr的觸發原理很簡單，inputflinger中focus window長時間為null，這個時候來了一些key事件需要分發，就會導致anr。
那這個問題難解在哪裡呢，導致focus window長時間為null的原因很難從日誌中分析。整個問題的發生問題的線路太長，APP-AMS-WMS-SurfaceFlinger-InputFlinger。
如果這個focus window是觸發ANR問題的應用主線程繁忙或阻塞，導致了進入這個app後，沒有及時的觸發activity的visiable的調用，這個問題可能還比較好解決，一般通過問題應用的主線程相關的日誌以及data/anr的trace，或者通過字節移動之前做的主線程的message的history功能，可以快速的日誌中找到相關的問題。
1.CPU負載高，ANR in日誌看到
2.記憶體不足，導致swap機制線程負載高，ANR in日誌看到
3.死鎖等問題，data/anr的trace檔中看到。
最難解的問題就是這個鍋不是出ANR的應用，而是別的原因，導致了focus window沒有觸發更新，而且一般這個問題是monkey跑出來的，很難找到復現路徑，我舉例幾個我遇到過場景。
一、Launcher啟動應用程式動畫異常，導致了遠端動畫沒有及時finish
二、轉屏動畫過程中，部分需要ready的介面沒有繪製完成，導致了轉屏逾時。
三、手勢上劃的遠端動畫沒有異常結束，導致介面處於recents動畫階段
四、SurfaceSyncGroup機制中，部分介面沒有ready導致了已經準備顯示的activity也沒有visible
五、莫名其妙的別的ANR觸發的dump導致了目前應用的運行異常
大家可以發現這種情況下你可能很難從日誌中快速發現問題點了，尤其一看data/anr的trace文件，出問題的應用主線程就在looper中休眠著呢。這時候只能盡可能的去看adb日誌中，尋找出現anr時候的蛛絲馬跡，盡可能的還原現場，這種問題就是及其難的，有時候就需要不斷加日誌，不斷的復現，再去解決。
在公司，這類問題，也是摔鍋的大戶，因為app分析不出來，framework也很難分析出來，然後這個問題還能偶發的複現。
如何破局，我覺得系統中要對一些window事務切換的場景做一些針對性日誌增強，這樣子一旦出問題的時候可以比較快速定位出問題的場景。盡可能的縮小分析範圍。當然要大家分析這類問題都抱著認真的態度，而不是monitor幾個版本，不復現就解決了。
可以說目前我有效解決過的偶現的no focus window不超過10個，有時候也是稀里糊塗的在解決別的內存洩漏，cpu異常的問題中順便運氣好解決了，希望今天的感想對你有幫助。
好久沒更新文章了，感謝大家沒有把我拿關，祝大家國慶中秋快樂！ ！ ！
PS：最近換了一下iPhone 17以及IOS26，其他都很不錯，唯一就是系統的流暢度是我有史以來體驗最差的新iPhone，我去線下體驗了Pro，也是一副鳥樣，很多基礎的滑動切換場景都會偶發的卡一下，因為我之前我性能優化，對畫面很敏感，看的最難受，希望蘋果公司好好努力優化吧。
Leave a Reply