Android ANR 機(jī)制

廣播的 ANR 處理相對簡單，主要是再次判斷是否超時(shí)、記錄日志，記錄 ANR 次數(shù)等。然后就繼續(xù)調(diào)用 processNextBroadcast 函數(shù)，處理下一條廣播了。

創(chuàng)新互聯(lián)公司-專業(yè)網(wǎng)站定制、快速模板網(wǎng)站建設(shè)、高性價(jià)比萬全網(wǎng)站開發(fā)、企業(yè)建站全套包干低至880元,成熟完善的模板庫,直接使用。一站式萬全網(wǎng)站制作公司更省心,省錢,快速模板網(wǎng)站建設(shè)找我們，業(yè)務(wù)覆蓋萬全地區(qū)。費(fèi)用合理售后完善，10多年實(shí)體公司更值得信賴。

ContentProvider 超時(shí)為 CONTENT_PROVIDER_PUBLISH_TIMEOUT = 10s

Activity 的 ANR 是相對最復(fù)雜的，也只有 Activity 中出現(xiàn)的 ANR 會彈出 ANR 提示框。

最終的表現(xiàn)形式是：彈出一個(gè)對話框，告訴用戶當(dāng)前某個(gè)程序無響應(yīng)，輸入一大堆與 ANR 相關(guān)的日志，便于開發(fā)者解決問題。

InputDispatching：

Activity 最主要的功能之一是交互，為了方便交互，Android 中的 InputDispatcher 會發(fā)出操作事件，最終在 InputManagerService 中發(fā)出事件，通過 InputChannel，向 Activity 分發(fā)事件。交互事件必須得到響應(yīng)，如果不能及時(shí)處理，IMS 就會報(bào)出 ANR，交給 AMS 去彈出 ANR 提示框。

KeyDispatching：

如果輸入是個(gè) Key 事件，會從 IMS 進(jìn)入 ActivityRecord.Token.keyDispatchingTimeOut，然后進(jìn)入 AMS 處理，不同的是，在 ActivityRecord 中，會先截留一次 Key 的不響應(yīng)，只有當(dāng) Key 連續(xù)第二次處理超時(shí)，才會彈出 ANR 提示框。

窗口焦點(diǎn)：

Activity 總是需要有一個(gè)當(dāng)前窗口來響應(yīng)事件的，但如果遲遲沒有當(dāng)前窗口（獲得焦點(diǎn)），比如在 Activity 切換時(shí)，舊 Activity 已經(jīng) onPause，新的 Activity 一直沒有 onResume，持續(xù)超過 5 秒，就會 ANR。

App 的生命周期太慢，或 CPU 資源不足，或 WMS 異常，都可能導(dǎo)致窗口焦點(diǎn)。

1. 判斷是否有 focused 組件以及 focused Application：

這種一般是在應(yīng)用啟動時(shí)觸發(fā)，比如啟動時(shí)間過長在這過程中觸發(fā)了 keyevent 或者 trackball moteionevent 就會出現(xiàn)。

對應(yīng)于

2. 判斷前面的事件是否及時(shí)完成：

對應(yīng)于

出現(xiàn)這種問題意味著主線程正在執(zhí)行其他的事件但是比較耗時(shí)導(dǎo)致輸入事件無法及時(shí)處理。

InputDispatcher 超時(shí)是最常見的 ANR 類型，而且其類型也比較多。

當(dāng)用戶觸摸屏幕或者按鍵操作，首次觸發(fā)的是硬件驅(qū)動，驅(qū)動收到事件后，將該相應(yīng)事件寫入到輸入設(shè)備節(jié)點(diǎn)， 這便產(chǎn)生了最原生態(tài)的內(nèi)核事件。接著，輸入系統(tǒng)取出原生態(tài)的事件，經(jīng)過層層封裝后成為 KeyEvent 或者 MotionEvent ；最后，交付給相應(yīng)的目標(biāo)窗口(Window)來消費(fèi)該輸入事件。可見，輸入系統(tǒng)在整個(gè)過程起到承上啟下的銜接作用。

Input 模塊的主要組成：

每一個(gè)應(yīng)用進(jìn)程都會有一個(gè) SignalCatcher 線程，專門處理 SIGQUIT，來到 art/runtime/signal_catcher.cc ：

當(dāng)應(yīng)用發(fā)生 ANR 之后，系統(tǒng)會收集許多進(jìn)程，來 dump 堆棧，從而生成 ANR Trace 文件。收集的第一個(gè)，也是一定會被收集到的進(jìn)程，就是發(fā)生 ANR 的進(jìn)程。接著系統(tǒng)開始向這些應(yīng)用進(jìn)程發(fā)送 SIGQUIT 信號，應(yīng)用進(jìn)程收到 SIGQUIT 后開始 dump 堆棧。

[1] developer ANRs

[2] Android ANR 分析詳解

[3] 看完這篇 Android ANR 分析，就可以和面試官裝逼了！

[4] 微信 Android 團(tuán)隊(duì)手把手教你高效監(jiān)控 ANR

[5] Input 系統(tǒng)—ANR 原理分析 - Gityuan

[6] 徹底理解安卓應(yīng)用無響應(yīng)機(jī)制 - Gityuan

[7] 理解 Android ANR 的觸發(fā)原理 - Gityuan

android anr怎么解決

ANR (Application Not Responding)

ANR定義：在Android上，如果你的應(yīng)用程序有一段時(shí)間響應(yīng)不夠靈敏，系統(tǒng)會向用戶顯示一個(gè)對話框，這個(gè)對話框稱作應(yīng)用程序無響應(yīng)（ANR：Application Not Responding）對話框。用戶可以選擇“等待”而讓程序繼續(xù)運(yùn)行，也可以選擇“強(qiáng)制關(guān)閉”。所以一個(gè)流暢的合理的應(yīng)用程序中不能出現(xiàn)anr，而讓用戶每次都要處理這個(gè)對話框。因此，在程序里對響應(yīng)性能的設(shè)計(jì)很重要，這樣系統(tǒng)不會顯示ANR給用戶。

默認(rèn)情況下，在android中Activity的最長執(zhí)行時(shí)間是5秒，BroadcastReceiver的最長執(zhí)行時(shí)間則是10秒。

第一：什么會引發(fā)ANR？

在Android里，應(yīng)用程序的響應(yīng)性是由Activity Manager和WindowManager系統(tǒng)服務(wù)監(jiān)視的 。當(dāng)它監(jiān)測到以下情況中的一個(gè)時(shí)，Android就會針對特定的應(yīng)用程序顯示ANR：

1.在5秒內(nèi)沒有響應(yīng)輸入的事件（例如，按鍵按下，屏幕觸摸）

2.BroadcastReceiver在10秒內(nèi)沒有執(zhí)行完畢

造成以上兩點(diǎn)的原因有很多，比如在主線程中做了非常耗時(shí)的操作，比如說是下載，io異常等。

潛在的耗時(shí)操作，例如網(wǎng)絡(luò)或數(shù)據(jù)庫操作，或者高耗時(shí)的計(jì)算如改變位圖尺寸，應(yīng)該在子線程里（或者以數(shù)據(jù)庫操作為例，通過異步請求的方式）來完成。然而，不是說你的主線程阻塞在那里等待子線程的完成——也不是調(diào)用 Thread.wait()或是Thread.sleep()。替代的方法是，主線程應(yīng)該為子線程提供一個(gè)Handler，以便完成時(shí)能夠提交給主線程。以這種方式設(shè)計(jì)你的應(yīng)用程序，將能保證你的主線程保持對輸入的響應(yīng)性并能避免由于5秒輸入事件的超時(shí)引發(fā)的ANR對話框。

第二：如何避免ANR？

1、運(yùn)行在主線程里的任何方法都盡可能少做事情。特別是，Activity應(yīng)該在它的關(guān)鍵生命周期方法（如onCreate()和onResume()）里盡可能少的去做創(chuàng)建操作。（可以采用重新開啟子線程的方式，然后使用Handler+Message的方式做一些操作，比如更新主線程中的ui等）

2、應(yīng)用程序應(yīng)該避免在BroadcastReceiver里做耗時(shí)的操作或計(jì)算。但不再是在子線程里做這些任務(wù)（因?yàn)?BroadcastReceiver的生命周期短），替代的是，如果響應(yīng)Intent廣播需要執(zhí)行一個(gè)耗時(shí)的動作的話，應(yīng)用程序應(yīng)該啟動一個(gè) Service。（此處需要注意的是可以在廣播接受者中啟動Service，但是卻不可以在Service中啟動broadcasereciver,關(guān)于原因后續(xù)會有介紹，此處不是本文重點(diǎn)）

3、避免在Intent Receiver里啟動一個(gè)Activity，因?yàn)樗鼤?chuàng)建一個(gè)新的畫面，并從當(dāng)前用戶正在運(yùn)行的程序上搶奪焦點(diǎn)。如果你的應(yīng)用程序在響應(yīng)Intent廣 播時(shí)需要向用戶展示什么，你應(yīng)該使用Notification Manager來實(shí)現(xiàn)。

總結(jié)：anr異常也是在程序中自己經(jīng)常遇到的問題，主要的解決辦法自己最常用的就是不要在主線程中做耗時(shí)的操作，而應(yīng)放在子線程中來實(shí)現(xiàn)，比如采用Handler+mesage的方式，或者是有時(shí)候需要做一些和網(wǎng)絡(luò)相互交互的耗時(shí)操作就采用asyntask異步任務(wù)的方式（它的底層其實(shí)Handler+mesage有所區(qū)別的是它是線程池）等，在主線程中更新UI。

Android ANR產(chǎn)生的原因和分析

ANR： ANR全稱是Application No Responding，翻譯過來就是程序無響應(yīng), 他是Android獨(dú)有的概念。定位和解決以及避免ANR是我們需要必備的技能。

1： ANR產(chǎn)生的原因：

Android的UI線程響應(yīng)超時(shí)就會引起ANR， 主要體現(xiàn)在兩種情況中：

2：典型的ANR場景：

1： 當(dāng)一個(gè)ANR的問題產(chǎn)生， 我們無法確認(rèn)是ANR watchdog或者是crash。每一種類型的問題的產(chǎn)生都有不同的影響范圍和表現(xiàn)形態(tài)， 一般凍屏， 一段時(shí)間后程序退出， 這種情況的產(chǎn)生都是ANR。在我們的AP Log中，ANR的filter字段一般有這幾種: ANR low_memory slow_operation. 我們根據(jù)這些關(guān)鍵字搜索到發(fā)生ANR的地方：

2： ANR log日志在系統(tǒng)的data/anr目錄下， 我們將所有的anr log日志pull出來。

3： 打開這個(gè)文件

如何分析解決Android ANR

引發(fā)ANR的原因：

在Android里，應(yīng)用程序的響應(yīng)性是由Activity Manager和WindowManager系統(tǒng)服務(wù)監(jiān)視的 。當(dāng)它監(jiān)測到以下情況中的一個(gè)時(shí)，Android就會針對特定的應(yīng)用程序顯示ANR：

1.在5秒內(nèi)沒有響應(yīng)輸入的事件（例如，按鍵按下，屏幕觸摸）

2.BroadcastReceiver在10秒內(nèi)沒有執(zhí)行完畢

造成以上兩點(diǎn)的原因有很多，比如在主線程中做了非常耗時(shí)的操作，比如說是下載，io異常等。

潛在的耗時(shí)操作，例如網(wǎng)絡(luò)或數(shù)據(jù)庫操作，或者高耗時(shí)的計(jì)算如改變位圖尺寸，應(yīng)該在子線程里（或者以數(shù)據(jù)庫操作為例，通過異步請求的方式）來完成。然而，不是說你的主線程阻塞在那里等待子線程的完成——也不是調(diào)用 Thread.wait()或是Thread.sleep()。替代的方法是，主線程應(yīng)該為子線程提供一個(gè)Handler，以便完成時(shí)能夠提交給主線程。以這種方式設(shè)計(jì)你的應(yīng)用程序，將能保證你的主線程保持對輸入的響應(yīng)性并能避免由于5秒輸入事件的超時(shí)引發(fā)的ANR對話框。

Android ANR,看完不慌

隔壁部門做了一個(gè)評價(jià)器，就是一個(gè)jsp頁面在安卓設(shè)備上一直運(yùn)行，安卓原生部分的很簡單，就是通過webview加載，打了個(gè)apk。最近用戶反饋說在運(yùn)行一段時(shí)間后，有時(shí)4-5個(gè)小時(shí)，有時(shí)10幾個(gè)小時(shí)，再次點(diǎn)擊頁面就會出現(xiàn)程序無響應(yīng)的情況。于是找到我這邊給測試解決，說真的，我比較慌。

1.設(shè)備的問題（因?yàn)榧胁少彽氖且恍┢嫫婀止值脑O(shè)備）。

WebSettings的相關(guān)配置也是添加的

tWebChromeClient 及WebViewClient相關(guān)也是設(shè)置了的，看起來也沒啥問題。

3.頁面的問題。

頁面不是我寫的，沒證據(jù)不能講。

假設(shè)被推翻，出問題的時(shí)間也沒法確定，看來捷徑是走不通了，只能從抓日志下手了，這里用了友盟統(tǒng)計(jì)的sdk去幫助完成這一步，等待兩天之后，錯誤日志收獲滿滿，還是比較興奮的。

待俺趕上前去，選取一條仔細(xì)觀瞧，不由得一身冷汗，尷尬了，看不懂。

莫慌，看不不要緊，根據(jù)指導(dǎo)原則猜猜也是有用的。

[DEBUG] runtime trace: 33,20,/data/anr/traces.txt 這句告訴我們anr日志保存路徑（沒卵用）

main prio=7 tid=1 Native main 表示主線程 prio線程優(yōu)先級 tid不是線程的id,它是一個(gè)在Java虛擬機(jī)中用來實(shí)現(xiàn)線程鎖的變量，隨著線程的增減，這個(gè)變量的值是可能被復(fù)用的. Native不必多說。

tid對應(yīng)值解釋說明

group是線程組名稱。sCount是此線程被掛起的次數(shù)，dsCount是線程被調(diào)試器掛起的次數(shù)，當(dāng)一個(gè)進(jìn)程被調(diào)試后，sCount會重置為0，調(diào)試完畢后sCount會根據(jù)是否被正常掛起增長，但是dsCount不會被重置為0，所以dsCount也可以用來判斷這個(gè)線程是否被調(diào)試過。obj表示這個(gè)線程的Java對象的地址，self表示這個(gè)線程本身的地址。

此后是線程的調(diào)度信息

sysTid是Linux下的內(nèi)核線程id，nice是線程的調(diào)度優(yōu)先級，sched分別標(biāo)志了線程的調(diào)度策略和優(yōu)先級，cgrp是調(diào)度屬組，handle是線程的處理函數(shù)地址。

然后是線程當(dāng)前上下文信息

state=S schedstat=( 303590361913 618664734427 651535 ) utm=19466 stm=10893 core=0

state是調(diào)度狀態(tài)；schedstat從 /proc/[pid]/task/[tid]/schedstat讀出，三個(gè)值分別表示線程在cpu上執(zhí)行的時(shí)間、線程的等待時(shí)間和線程執(zhí)行的時(shí)間片長度，有的android內(nèi)核版本不支持這項(xiàng)信息，得到的三個(gè)值都是0；utm是線程用戶態(tài)下使用的時(shí)間值(單位是jiffies）;stm是內(nèi)核態(tài)下的調(diào)度時(shí)間值；core是最后執(zhí)行這個(gè)線程的cpu核的序號。

最后就是這個(gè)線程的調(diào)用棧信息。

看了日志文件，對于如何找出ANR的真正原因，還是一件難事，其實(shí)說難不難，文本冗長我們沒必要弄懂每一行的意思，一般的，如果是我們的應(yīng)用造成的anr,至少能夠在這個(gè)文件里看到包名com.xxx.xx的表述，結(jié)合上下文分析應(yīng)該不難，但我這個(gè)沒找到。

除了找應(yīng)用信息，查找wating ,anr等關(guān)鍵字，因?yàn)閍nr的情況一般是讓主線程做了很多耗時(shí)的操作，我這個(gè)是應(yīng)用長駐的，放在柜臺員前讓辦事用戶再辦完事情進(jìn)行評價(jià)的，很簡答的功能，原生并沒有耗時(shí)操作，jsp頁面問了問寫的人員也沒有做耗時(shí)操作，這就很奇怪。

苦苦閱讀這個(gè)anr日志時(shí)，事情出現(xiàn)了轉(zhuǎn)機(jī)，外派員反饋另一個(gè)地區(qū)的設(shè)備是來自不同廠商的，出現(xiàn)問題后廠商過來給設(shè)備進(jìn)行過處理，目前那一批設(shè)備是好的（為啥不早說），于是聯(lián)系那邊詢問，做了什么騷操作，發(fā)來了一個(gè)文件夾：

簡單看了看，主要是給更新了WebViewGoogle_arm32.apk,手機(jī)上是見過這東西的，開發(fā)者選項(xiàng)下查看`webView實(shí)現(xiàn)'就能夠看到，小米華為都有，然而我手里這臺設(shè)備在設(shè)置里搜尋一圈都沒有（什么鬼設(shè)備）

網(wǎng)頁標(biāo)題：android的anr,android的anr機(jī)制
網(wǎng)頁路徑：http://chinadenli.net/article45/dseidhi.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供營銷型網(wǎng)站建設(shè)、靜態(tài)網(wǎng)站、品牌網(wǎng)站建設(shè)、手機(jī)網(wǎng)站建設(shè)、網(wǎng)站導(dǎo)航、全網(wǎng)營銷推廣

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來源： 創(chuàng)新互聯(lián)