當前位置:首頁 » 原因查詢 » 造成anr的原因如何避免
擴展閱讀
有黑眼圈的原因怎麼化妝 2025-07-17 09:52:03

造成anr的原因如何避免

發布時間: 2022-05-09 11:08:15

Ⅰ 安卓開發ANR怎麼處理

原因分析:android系統中處理用戶操作的工作時在主線程中執行的,如果我們的程序在主線程中進行一些耗時的操作,導致用戶的操作6秒不能夠處理,就會出現異常。
主線程休眠,那麼再點擊程序,必須等主線程睡醒後才會反應。
所以在主線程中不要做太耗時的工作,因為主界面會阻塞。

解決辦法:讓這些耗時的操作放在新線程裡面操作。
注意:如果新線程裡面做的事情要更新界面的話,就要使用handler來操作。
連接網路的事都要放在新線程裡面的。
解決代碼(包括更新界面的操作,使用的是handler):

import android.app.Activity;
import android.os.Bundle;
import android.os.Handler;
import android.view.View;
import android.widget.TextView;
import android.widget.Toast;

public class MainActivity extends Activity {
private TextView numTV;
private Handler handler = new Handler();
private int i;

public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.main);

numTV = (TextView) findViewById(R.id.numTV);
}

public void doSomething(View view) throws Exception {
new Thread() {
public void run() {
for (i = 1; i < 20; i++) {
handler.post(new Runnable() {
public void run() {
numTV.setText(i + "");
}
});
System.out.println(i);
try {
Thread.sleep(1000);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
};
}.start();
}

public void toast(View view) {
Toast.makeText(this, "十八大開幕了!", 0).show();
}
}

Ⅱ 什麼是ANR

雅詩蘭黛Advanced Night Repair 簡稱ANR,棕色小瓶子的奇跡~
即時修護:每天使用可加強肌膚自然修護能力,持續修復肌膚日積月累因紫外線、環境污染、生活壓力等因素造成的各項問題,持續使用會預防衰老,預防細紋和皺紋。

膚色均勻:持續使用可舒緩每日肌膚所承受的各項刺激,補充抗氧化物質,可淡化疤痕、痘印痕,勻亮膚色。

立即保濕:經過時間驗證的透明質酸保濕鎖水,保持肌膚水嫩,為健康皮膚創造最佳環境。眾所周知的天然"水分磁場",能鎖住比自身重量多1500倍的水分。
我在使用,效果很好,改善皮膚乾燥,抗氧化,提高皮膚緊致力,還有祛痘消痕的作用~~

Ⅲ android開發過程中遇到 ANR問題怎麼解決

ANR: 很多初入Android開發的網友可能發現ANR的字樣,到底Android ANR是什麼呢? 其實ANR就是Application Not Responding的全稱,當某個應用處於長期假死狀態時Android系統會彈出一個窗口上面寫道,XXX is not responding給出兩個按鈕一個為force close一個為wait。 可能觸發ANR的情況 1. 長時間的I/O處理,比如讀寫大文件,網路訪問時造成的阻塞。 2. 執行耗時的運算,Android默認為超過5000ms即5秒開始彈出ANR窗口,某些應用可能首次執行時沒有緩存十分耗時,可以通過Splash播放閃屏Logo等方式來延緩載入 3. Service和appWidget中也要注意多線程的使用,除非它和Activity工作在不同的進程。 避免ANR的方法 1. 單獨開工作者線程,通過獨立的Thread或使用類似AsyncTask的方式來處理耗時的內容。 2. 耗時的操作盡量分段處理,使用類似狀態機的方法,類似Symbian的活動對象將一個復雜的事情,分段執行。 3. UI線程中不要處理過多的內容,比如將一個5MB的文本,讓TextView去setText,要知道這種UI操作,沒有什麼好方法去解決的,所以Android123提示,遇到UI中需要執行復雜的操作,可以參考上面2提到的分段處理方式。

Ⅳ 請教android service ANR問題

ANR(ApplicationNotResponding)ANR定義:在Android上,如果你的應用程序有一段時間響應不夠靈敏,系統會向用戶顯示一個對話框,這個對話框稱作應用程序無響應(ANR:ApplicationNotResponding)對話框。用戶可以選擇「等待」而讓程序繼續運行,也可以選擇「強制關閉」。所以一個流暢的合理的應用程序中不能出現anr,而讓用戶每次都要處理這個對話框。因此,在程序里對響應性能的設計很重要,這樣系統不會顯示ANR給用戶。默認情況下,在android中Activity的最長執行時間是5秒,BroadcastReceiver的最長執行時間則是10秒。第一:什麼會引發ANR?在Android里,應用程序的響應性是由ActivityManager和WindowManager系統服務監視的。當它監測到以下情況中的一個時,Android就會針對特定的應用程序顯示ANR:在5秒內沒有響應輸入的事件(例如,按鍵按下,屏幕觸摸)2.BroadcastReceiver在10秒內沒有執行完畢造成以上兩點的原因有很多,比如在主線程中做了非常耗時的操作,比如說是下載,io異常等。潛在的耗時操作,例如網路或資料庫操作,或者高耗時的計算如改變點陣圖尺寸,應該在子線程里(或者以資料庫操作為例,通過非同步請求的方式)來完成。然而,不是說你的主線程阻塞在那裡等待子線程的完成——也不是調用Thread.wait()或是Thread.sleep()。替代的方法是,主線程應該為子線程提供一個Handler,以便完成時能夠提交給主線程。以這種方式設計你的應用程序,將能保證你的主線程保持對輸入的響應性並能避免由於5秒輸入事件的超時引發的ANR對話框。第二:如何避免ANR?1、運行在主線程里的任何方法都盡可能少做事情。特別是,Activity應該在它的關鍵生命周期方法(如onCreate()和onResume())里盡可能少的去做創建操作。(可以採用重新開啟子線程的方式,然後使用Handler+Message的方式做一些操作,比如更新主線程中的ui等)2、應用程序應該避免在BroadcastReceiver里做耗時的操作或計算。但不再是在子線程里做這些任務(因為BroadcastReceiver的生命周期短),替代的是,如果響應Intent廣播需要執行一個耗時的動作的話,應用程序應該啟動一個Service。(此處需要注意的是可以在廣播接受者中啟動Service,但是卻不可以在Service中啟動broadcasereciver,關於原因後續會有介紹,此處不是本文重點)3、避免在IntentReceiver里啟動一個Activity,因為它會創建一個新的畫面,並從當前用戶正在運行的程序上搶奪焦點。如果你的應用程序在響應Intent廣播時需要向用戶展示什麼,你應該使用NotificationManager來實現。總結:anr異常也是在程序中自己經常遇到的問題,主要的解決法自己最常用的就是不要在主線程中做耗時的操作,而應放在子線程中來實現,比如採用Handler+mesage的方式,或者是有時候需要做一些和網路相互交互的耗時操作就採用asyntask非同步任務的方式(它的底層其實Handler+mesage有所區別的是它是線程池)等,在主線程中更新UI。

Ⅳ 在android中anr什麼意思

ANR是Application Not Responding的簡稱,主要是說應用程序出現無響應的情況。在這個情況出現的時候同時在手機界面會彈出響應的對話框,提示應用程序無響應
ANR的幾種類型:

當運行指定的APP,如果Android系統檢測到符合下邊的幾種條件那就會彈出應用程序無響應的界面。
1)按鍵超時:Android默認的響應時間是5s,如果一個觸屏事件超過5s,那麼就會發生此現象。
2)廣播超時:廣播的默認響應時間是10s,如果一個廣播在10s之內還美柚執行完,那麼就會出現此現象。
3)服務超時:服務的默認響應事件是20s,如果請求的服務在20s內失敗,那麼就會發生此現象。
ANR事件與異常的區別
ANR事件是由於一些操作的原因或者是反應事件較慢會出現程序無響應的情況,而異常是程序由於代碼或者是一些其他的原因出現程序停止運行的情況,這兩種情況的性質是完全不一樣的。

Ⅵ 如何產生ANR,ANDROID中的。

引發ANR的原因:
在Android里,應用程序的響應性是由Activity Manager和WindowManager系統服務監視的 。當它監測到以下情況中的一個時,Android就會針對特定的應用程序顯示ANR:
1.在5秒內沒有響應輸入的事件(例如,按鍵按下,屏幕觸摸)
2.BroadcastReceiver在10秒內沒有執行完畢
造成以上兩點的原因有很多,比如在主線程中做了非常耗時的操作,比如說是下載,io異常等。

潛在的耗時操作,例如網路或資料庫操作,或者高耗時的計算如改變點陣圖尺寸,應該在子線程里(或者以資料庫操作為例,通過非同步請求的方式)來完成。然而,不是說你的主線程阻塞在那裡等待子線程的完成——也不是調用 Thread.wait()或是Thread.sleep()。替代的方法是,主線程應該為子線程提供一個Handler,以便完成時能夠提交給主線程。以這種方式設計你的應用程序,將能保證你的主線程保持對輸入的響應性並能避免由於5秒輸入事件的超時引發的ANR對話框。

Ⅶ 如何分析解決Android ANR

一:什麼是ANR

ANR:Application Not Responding,即應用無響應二:ANR的類型

ANR一般有三種類型:

1:KeyDispatchTimeout(5 seconds) --主要類型

按鍵或觸摸事件在特定時間內無響應

2:BroadcastTimeout(10 seconds)

BroadcastReceiver在特定時間內無法處理完成

3:ServiceTimeout(20 seconds) --小概率類型

Service在特定的時間內無法處理完成三:KeyDispatchTimeout

Akey or touch event was not dispatched within the specified time(按鍵或觸摸事件在特定時間內無響應)

具體的超時時間的定義在framework下的

ActivityManagerService.java

//How long we wait until we timeout on key dispatching.

staticfinal int KEY_DISPATCHING_TIMEOUT = 5*1000四:為什麼會超時呢?

超時時間的計數一般是從按鍵分發給app開始。超時的原因一般有兩種:

(1)當前的事件沒有機會得到處理(即UI線程正在處理前一個事件,沒有及時的完成或者looper被某種原因阻塞住了)

(2)當前的事件正在處理,但沒有及時完成五:如何避免KeyDispatchTimeout

1:UI線程盡量只做跟UI相關的工作

2:耗時的工作(比如資料庫操作,I/O,連接網路或者別的有可能阻礙UI線程的操作)把它放入單獨的線程處理

3:盡量用Handler來處理UIthread和別的thread之間的交互六:UI線程

說了那麼多的UI線程,那麼哪些屬於UI線程呢?

UI線程主要包括如下:

Activity:onCreate(), onResume(), onDestroy(), onKeyDown(), onClick(),etc

AsyncTask: onPreExecute(), onProgressUpdate(), onPostExecute(), onCancel,etc

Mainthread handler: handleMessage(), post*(runnable r), etc

other
從LOG可以看出ANR的類型,CPU的使用情況,如果CPU使用量接近100%,說明當前設備很忙,有可能是CPU飢餓導致了ANR

如果CPU使用量很少,說明主線程被BLOCK了

如果IOwait很高,說明ANR有可能是主線程在進行I/O操作造成的

除了看LOG,解決ANR還得需要trace.txt文件,

如何獲取呢?可以用如下命令獲取

$chmod 777 /data/anr

$rm /data/anr/traces.txt

$ps

$kill -3 PID

adbpull data/anr/traces.txt ./mytraces.txt

從trace.txt文件,看到最多的是如下的信息:

-----pid 21404 at 2011-04-01 13:12:14 -----
Cmdline: com.android.email

DALVIK THREADS:
(mutexes: tll=0tsl=0 tscl=0 ghl=0 hwl=0 hwll=0)
"main" prio=5 tid=1NATIVE
| group="main" sCount=1 dsCount=0obj=0x2aad2248 self=0xcf70
| sysTid=21404 nice=0 sched=0/0cgrp=[fopen-error:2] handle=1876218976
atandroid.os.MessageQueue.nativePollOnce(Native Method)
atandroid.os.MessageQueue.next(MessageQueue.java:119)
atandroid.os.Looper.loop(Looper.java:110)
at android.app.ActivityThread.main(ActivityThread.java:3688)
at java.lang.reflect.Method.invokeNative(Native Method)
atjava.lang.reflect.Method.invoke(Method.java:507)
atcom.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:866)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:624)
at dalvik.system.NativeStart.main(Native Method)

說明主線程在等待下條消息進入消息隊列

Ⅷ Android ANR異常,沒找到原因,緊急求助

root失敗。文件異常或有缺失。最好還原一下,恢復出廠設置

Ⅸ Android中ANR造成的原因以及如何避免

產生ANR的原因,是在主線程(即UI線程)做了太多耗時的操作,應該把非UI操作,例如網路數據獲取,資料庫操作等,放在非同步線程中。

Ⅹ 如何分析解決androidanr

2:耗時的工作(比如資料庫操作,I/O,連接網路或者別的有可能阻礙UI線程的操作)把它放入單獨的線程處理
3:盡量用Handler來處理UIthread和別的thread之間的交互

如何調查並解決ANR
1:首先分析log
2: 從trace.txt文件查看調用stack.
3: 看代碼
4:仔細查看ANR的成因(iowait?block?memoryleak?)

分析ANR
先看個LOG:
04-01 13:12:11.572 I/InputDispatcher( 220): Application is not responding:Window{2b263310com.android.email/com.android.email.activity.SplitScreenActivitypaused=false}. 5009.8ms since event, 5009.5ms since waitstarted
04-0113:12:11.572 I/WindowManager( 220): Input event dispatching timedout sending tocom.android.email/com.android.email.activity.SplitScreenActivity
04-01 13:12:14.123 I/Process( 220): Sending signal. PID: 21404 SIG: 3---發生ANR的時間和生成trace.txt的時間
04-01 13:12:14.123 I/dalvikvm(21404):threadid=4: reacting to signal 3
……
04-0113:12:15.872 E/ActivityManager( 220): ANR in com.android.email(com.android.email/.activity.SplitScreenActivity)
04-0113:12:15.872 E/ActivityManager( 220): Reason:keyDispatchingTimedOut
04-0113:12:15.872 E/ActivityManager( 220): Load: 8.68 / 8.37 / 8.53
04-0113:12:15.872 E/ActivityManager( 220): CPUusage from 4361ms to 699ms ago ----CPU在ANR發生前的使用情況

04-0113:12:15.872 E/ActivityManager( 220): 5.5%21404/com.android.email: 1.3% user + 4.1% kernel / faults: 10 minor
04-0113:12:15.872 E/ActivityManager( 220): 4.3%220/system_server: 2.7% user + 1.5% kernel / faults: 11 minor 2 major
04-0113:12:15.872 E/ActivityManager( 220): 0.9%52/spi_qsd.0: 0% user + 0.9% kernel
04-0113:12:15.872 E/ActivityManager( 220): 0.5%65/irq/170-cyttsp-: 0% user + 0.5% kernel
04-0113:12:15.872 E/ActivityManager( 220): 0.5%296/com.android.systemui: 0.5% user + 0% kernel
04-0113:12:15.872 E/ActivityManager( 220): 100%TOTAL: 4.8% user + 7.6% kernel + 87% iowait
04-0113:12:15.872 E/ActivityManager( 220): CPUusage from 3697ms to 4223ms later:-- ANR後CPU的使用量
04-0113:12:15.872 E/ActivityManager( 220): 25%21404/com.android.email: 25% user + 0% kernel / faults: 191 minor
04-0113:12:15.872 E/ActivityManager( 220): 16% 21603/__eas(par.hakan: 16% user + 0% kernel
04-0113:12:15.872 E/ActivityManager( 220): 7.2% 21406/GC: 7.2% user + 0% kernel
04-0113:12:15.872 E/ActivityManager( 220): 1.8% 21409/Compiler: 1.8% user + 0% kernel
04-0113:12:15.872 E/ActivityManager( 220): 5.5%220/system_server: 0% user + 5.5% kernel / faults: 1 minor
04-0113:12:15.872 E/ActivityManager( 220): 5.5% 263/InputDispatcher: 0% user + 5.5% kernel
04-0113:12:15.872 E/ActivityManager( 220): 32%TOTAL: 28% user + 3.7% kernel

從LOG可以看出ANR的類型,CPU的使用情況,如果CPU使用量接近100%,說明當前設備很忙,有可能是CPU飢餓導致了ANR
如果CPU使用量很少,說明主線程被BLOCK了
如果IOwait很高,說明ANR有可能是主線程在進行I/O操作造成的
除了看LOG,解決ANR還得需要trace.txt文件,
如何獲取呢?可以用如下命令獲取
$chmod 777 /data/anr
$rm /data/anr/traces.txt
$ps
$kill -3 PID
adbpull data/anr/traces.txt ./mytraces.txt
從trace.txt文件,看到最多的是如下的信息:
-----pid 21404 at 2011-04-01 13:12:14 -----
Cmdline: com.android.email

DALVIK THREADS:
(mutexes: tll=0tsl=0 tscl=0 ghl=0 hwl=0 hwll=0)
"main" prio=5 tid=1NATIVE
| group="main" sCount=1 dsCount=0obj=0x2aad2248 self=0xcf70
| sysTid=21404 nice=0 sched=0/0cgrp=[fopen-error:2] handle=1876218976
atandroid.os.MessageQueue.nativePollOnce(Native Method)
atandroid.os.MessageQueue.next(MessageQueue.java:119)
atandroid.os.Looper.loop(Looper.java:110)
at android.app.ActivityThread.main(ActivityThread.java:3688)
at java.lang.reflect.Method.invokeNative(Native Method)
atjava.lang.reflect.Method.invoke(Method.java:507)
atcom.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:866)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:624)
at dalvik.system.NativeStart.main(Native Method)
說明主線程在等待下條消息進入消息隊列