『壹』 android activity 中的 service 方法是否非同步執行拜託各位大神
非同步執行
android中，activity、service都是在主線程，service與activity的主要區別就是service沒有前台界面，不能直接與用戶交互，另外可以相對保證不會被系統隨便的kill掉。所以service適用於一些無需交互的後台操作，但如果你直接在service中進行耗時操作的話，因為在主線程所以依然會出現和activity主線程一樣的超時的問題，所以好的方式是在service中啟動其他的線程去執行耗時操作。
『貳』 請教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 service ANR問題
剛拿到anr的trace，還是無頭緒，都是調用棧的mp，仔細看看，發現一個很好的信息隱藏在這個棧幀信息中：
如下一個棧幀：
----- pid 861 at 2012-02-11 14:57:50 -----
Cmd line: system_server
DALVIK THREADS:
(mutexes: tll=0 tsl=0 tscl=0 ghl=0)
"main" prio=5 tid=1 MONITOR
| group="main" sCount=1 dsCount=0 obj=0x2ba9c460 self=0x8e820
| sysTid=861 nice=0 sched=0/0 cgrp=[fopen-error:2] handle=716342112
| schedstat=( 0 0 0 ) utm=464 stm=65 core=0
at com.android.server.am.ActivityManagerService.isUserAMonkey(ActivityManagerService.java:~6546)
- waiting to lock <0x2c1141c8> (a com.android.server.am.ActivityManagerService) held by tid=59 (Binder Thread #6)
at android.app.ActivityManagerNative.onTransact(ActivityManagerNative.java:1273)
at com.android.server.am.ActivityManagerService.onTransact(ActivityManagerService.java:1545)
at android.os.Binder.execTransact(Binder.java:338)
at com.android.server.SystemServer.init1(Native Method)
at com.android.server.SystemServer.main(SystemServer.java:808)
at java.lang.reflect.Method.invokeNative(Native Method)
at java.lang.reflect.Method.invoke(Method.java:511)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:784)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:551)
at dalvik.system.NativeStart.main(Native Method)
這說明什麼？看上面的紅色部分，說明這個主線程在等待鎖一個object 0x2c1141c8 (通常就是synchronized操作，這里就是com.android.server.am.ActivityManagerService類型的一個object),但被tid=59佔住了， 再看看 tid=59的棧幀：
"Binder Thread #6" prio=5 tid=59 MONITOR
| group="main" sCount=1 dsCount=0 obj=0x2c3bd838 self=0x34c5d8
| sysTid=1120 nice=0 sched=0/0 cgrp=[fopen-error:2] handle=3460688
| schedstat=( 0 0 0 ) utm=168 stm=48 core=0
at com.android.server.am.BatteryStatsService.noteStopWakelock(BatteryStatsService.java:~114)
- waiting to lock <0x2c117d50> (a com.android.internal.os.BatteryStatsImpl) held by tid=13 (ProcessStats)
at com.android.server.PowerManagerService.noteStopWakeLocked(PowerManagerService.java:798)
at com.android.server.PowerManagerService.releaseWakeLockLocked(PowerManagerService.java:1015)
at com.android.server.PowerManagerService.releaseWakeLock(PowerManagerService.java:967)
at android.os.PowerManager$WakeLock.release(PowerManager.java:319)
at android.os.PowerManager$WakeLock.release(PowerManager.java:300)
at com.android.server.am.ActivityStack.activityIdleInternal(ActivityStack.java:3254)
at com.android.server.am.ActivityManagerService.activityIdle(ActivityManagerService.java:3953)
at android.app.ActivityManagerNative.onTransact(ActivityManagerNative.java:362)
at com.android.server.am.ActivityManagerService.onTransact(ActivityManagerService.java:1545)
at android.os.Binder.execTransact(Binder.java:338)
at dalvik.system.NativeStart.run(Native Method)
tid為何沒有釋放鎖object 0x2c1141c8呢？因為它在等到鎖 object 0x2c117d50(一個com.android.internal.os.BatteryStatsImpl類型的對象)!如果大家有較豐富的捉蟲經驗的話，看到這， 想必都清楚了，持鎖時又請求鎖，極大的可能就是死鎖了！
再看請求的鎖被tid=13持有的情況吧：
"ProcessStats" prio=5 tid=13 MONITOR
| group="main" sCount=1 dsCount=0 obj=0x2c146f58 self=0x2954f0
| sysTid=877 nice=0 sched=0/0 cgrp=[fopen-error:2] handle=2709096
| schedstat=( 0 0 0 ) utm=6 stm=4 core=0
at com.android.server.am.ActivityManagerService.broadcastIntent(ActivityManagerService.java:~12430)
- waiting to lock <0x2c1141c8> (a com.android.server.am.ActivityManagerService) held by tid=59 (Binder Thread #6)
at android.app.ContextImpl.sendBroadcast(ContextImpl.java:909)
at com.android.server.DropBoxManagerService.add(DropBoxManagerService.java:236)
at android.os.DropBoxManager.addText(DropBoxManager.java:272)
at com.android.server.am.ActivityManagerService$11.run(ActivityManagerService.java:7630)
at com.android.server.am.ActivityManagerService.addErrorToDropBox(ActivityManagerService.java:7635)
at com.android.server.am.ActivityManagerService.handleApplicationWtf(ActivityManagerService.java:7448)
at com.android.internal.os.RuntimeInit.wtf(RuntimeInit.java:345)
at android.util.Log$1.onTerribleFailure(Log.java:103)
at android.util.Log.wtf(Log.java:278)
at com.android.internal.os.BatteryStatsImpl.(BatteryStatsImpl.java:5738)
at com.android.internal.os.BatteryStatsImpl.access$100(BatteryStatsImpl.java:76)
at com.android.internal.os.BatteryStatsImpl$Uid.(BatteryStatsImpl.java:2457)
at com.android.internal.os.BatteryStatsImpl$Uid.getTcpBytesReceived(BatteryStatsImpl.java:2446)
at com.android.internal.os.BatteryStatsImpl.writeSummaryToParcel(BatteryStatsImpl.java:5437)
at com.android.internal.os.BatteryStatsImpl.writeLocked(BatteryStatsImpl.java:4836)
at com.android.internal.os.BatteryStatsImpl.writeAsyncLocked(BatteryStatsImpl.java:4818)
at com.android.server.am.ActivityManagerService.updateCpuStatsNow(ActivityManagerService.java:1649)
at com.android.server.am.ActivityManagerService$3.run(ActivityManagerService.java:1531)
『肆』 android開發中為什麼會出現anr
原因有3：
1.用戶在進行了一種操作後5秒鍾沒有響應。
2.broadCastReceiver所進行的操作在10秒內沒有完成。
3.Service在20秒內沒返回結果。
『伍』 Android如何避免ANR
ANR：Application Not Responding，五秒在Android中，活動管理器和窗口管理器這兩個系統服務負責監視應用程序的響應。當出現下列情況時，Android就會顯示ANR對話框了： 對輸入事件(如按鍵、觸摸屏事件)的響應超過5秒 意向接受器(intentReceiver)超過10秒鍾仍未執行完畢
Android應用程序完全運行在一個獨立的線程中(例如main)。這就意味著，任何在主線程中運行的，需要消耗大量時間的操作都會引發ANR。因為此時，你的應用程序已經沒有機會去響應輸入事件和意向廣播(Intent broadcast)。 因此，任何運行在主線程中的方法，都要盡可能的只做少量的工作。特別是活動生命周期中的重要方法如onCreate()和 onResume()等更應如此。潛在的比較耗時的操作，如訪問網路和資料庫;或者是開銷很大的計算，比如改變點陣圖的大小，需要在一個單獨的子線程中完成(或者是使用非同步請求，如資料庫操作)。但這並不意味著你的主線程需要進入阻塞狀態已等待子線程結束 -- 也不需要調用Therad.wait()或者Thread.sleep()方法。取而代之的是，主線程為子線程提供一個句柄(Handler)，讓子線程在即將結束的時候調用它(xing:可以參看Snake的例子，這種方法與以前我們所接觸的有所不同)。使用這種方法涉及你的應用程序，能夠保證你的程序對輸入保持良好的響應，從而避免因為輸入事件超過5秒鍾不被處理而產生的ANR。這種實踐需要應用到所有顯示用戶界面的線程，因為他們都面臨著同樣的超時問題。
『陸』 安卓開發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();
}
}
『柒』 如何分析解決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如何連接SQLServer資料庫我的出錯！怎麼解決
看你的code 在ui線程做資料庫操作，很容易造成anr,可以用handler將資料庫操作放在後台操作，顯示的時候在ui線程。資料庫連接的操作 搜索下一大堆
『玖』 android anr多長時間
broadcast超時時間為10秒
按鍵無響應的超時時間為5秒
service ANR超時的定義在ActiveServices.java中
前台service無響應的超時時間為20秒，後台service為200秒