android死鎖
㈠ android 死鎖的概念，怎麼避免死鎖
比如有兩個線程執行，線程t1， 線程t2 t1 需要獲取方法A的鎖標志，同時方法A調用了方法B，t1獲取了A的鎖標志，並獲取了B的鎖標志，才能完成執行 同時t2也在執行，t2獲取方法B的鎖標志，方法B調用了方法A,t2也需要獲取兩個方法A,B的鎖標志才能執行完成 當t1 獲取了A方法的鎖標志，同時t2獲取了B方法的鎖標志 那麼t1會等待t2釋放方法B的鎖標志，t2也在等待t1釋放方法A的鎖標志，這樣就形成了死鎖，都在等待....
㈡ 安卓開發軟體android studio 出現這個問題怎麼辦
文件死鎖的問題，我曾在使用SVN時候遇到過，找到對應文件，右鍵中尋找unlock試試。
㈢ android手機系統死機後怎麼處理
原因及解決方法如下：
rom中存在大量的bug,導致手機頻繁死機。此時，可以選擇升級ROM。
運行程序導致CPU溫度過高或是各種數據運算時出現錯誤導致。有兩種和解決方法：使用完一個程序之後就要將其關閉，不要在後台運行過多的程序；不要長時間運行比較大型的游戲，注意手機後蓋上的溫度，有異常是及時結束掉相應的進程，避免死機。
SD卡讀取錯導致手機死機。刪除內存卡中沒用的文件，或是直接對內存卡進行格式化處理；更換內存卡。
軟體造成手機死機。直接將軟體拆卸即可，到官方或是一些其他的軟體市場重新下載。
病毒導致手機死機。方法：恢復出廠設置；進入Recover進行兩清；SD升級，對系統進行徹底的還原。
㈣ 如何分析android bugreport
一、ChkBugReport介紹
ChkBugReport是一個開源工具，它可以把你得到的bugreprot解析成適合閱讀的html文件。導出的html文件包含了根據bugreport數據得出的圖表和分析結論。
它的源碼中用到了以下開源類庫： jQuery ，jsTree jquery plugin ， tablednd jQuery plugin ， tablesorter jQuery plugin ，js-hotkeys， jquery-cookie 。學習輸出報告文檔型html可以參考源碼。
目前ChkBugReport可以從bugreport數據中抽取出如下信息：
1、Stacktraces ChkBugReport可以從bugreport中解析出輸出bugreport的最後時刻、導致ANR時刻甚至更多時刻的堆棧信息。在例子中你可以看到進程的優先順序和策略都已標示出來，堆棧中耗時的部分顏色是黑紅，一些違反Strict Mode的部分（比如主線程中使用資料庫）顏色標記為亮紅。如果這個線程死鎖，在報告的Errors將會出現。
2、Logs 這部分是對system、main和kernel日誌的分析，在這里你可以看到每個進程內存使用圖、那個程序產生的log最多、Activity的啟動耗時、資料庫操作耗時統計、對象被鎖定時間、AIDL調用時間、Activity和Service的生命周期及其在內存中使用頻率等等，詳見
3、Packages ChkBugReport解析bugreport中存儲的packages.xml並展示一系列的packages、user ids和 permissions。參見
4、Processes 操作app過程中產生的系統事件日誌、內存使用信息等等，參見
5、Battery statistics 電池使用統計信息，參見
6、CPU Frequency statistics CPU頻率統計信息，參見
7、Raw data 被分割成小段的原始數據
同時ChkBugReport也可以檢測到（潛在的）錯誤，這些錯誤在輸出的報告Errors部分中可以找到。你也可以在輸出報告的stacktrace中找到死鎖或一些違反Strict Mode的行為。
二、ChkBugReport使用
使用很簡單：1 java -jar $HOME/Downloads/chkbugreport.jar $HOME/tmp/bugreport.txt
你也可以把chkbugreport.jar加到path下，然後這樣使用1 chkbugreport thebugreport.txt
該工具將根據你的bugreport數據輸出一個分析結果目錄bugreport_out。
你可以使用如下命令取得bugreport：1 adb shell bugreport > bugreport.txt
當然你可以使用ChkBugReport分析bugreport的部分數據比如/data/anr/traces.txt1 chkbugreport -sl:the_system_log.txt -sa:traces.txt mmy
這將輸出分析結果到mmy_out。
你甚至可以使用ChkBugReport分析traceview生成的數據1 chkbugreport -t something.prof
Prof數據生成方法可以參考以下方法：
1、可以使用eclipse插件traceview生成
2、也可以按如下步驟：
a.用adb shell ps列出所有進程並找出你想要trace的進程的PID
b.執行adb shell am profile PID start /data/profile.dat，開始分析
c.操作你的app
d.執行adb shell am profile PID stop ，停止分析
e.導出數據並清除臨時文件：adb pull /data/profile.dat adb shell rm /data/profile.dat
f.使用ChkBugReport進行分析 chkbugreport -t profile.dat
㈤ Android 如何解決資料庫多線程鎖的問題
多線程是很容易造成死鎖，一般情況下死鎖都是因為並發操作引起的。我不懂JAVA,但死鎖這個問題每種開發工具和資料庫都會碰到.解決辦法是：
1、程序方面優化演算法（如有序資源分配法、銀行演算法等），在一個程序里，能不用多線程更新同一張資料庫表 盡量不要用，如果要用，其避免死鎖的演算法就很復雜。
2、資料庫方面設置等待超時時間
3、發生死鎖後直接KILL掉資料庫進程
㈥ Android bind通信對性能影響
您好，您是想問Android bind通信對性能有什麼影響事嗎？
為什麼要使用Binder性能。主要影響的因素是拷貝次數：管道、消息隊列、Socket的拷貝次書都是兩次，性能不是很好；共享內存不需要拷貝，性能最好；Binder拷貝1次，性能僅次於共享內存；Linux 下傳統的進程間通信原理與不足。內核程序在內核空間分配內存並開辟一塊內核緩存區，發送進程通過_from_user函數將數據拷貝到到內核空間的緩沖區中。同樣的，接收進程在接收數據時在自己的用戶空間開辟一塊內存緩存區，然後內核程序調用 _to_user() 函數將數據從內核緩存區拷貝到接收進程。這樣數據發送進程和數據接收進程完成了一次數據傳輸，也就是一次進程間通信；其有兩點不足之處：一次數據傳遞需要經歷：用戶空間 _> 內核緩存區 _> 用戶空間，需要2次數據拷貝，效率不高。接收數據的緩存區由數據接收進程提供，但是接收進程並不知道需要多大的空間來存放將要傳遞過來的數據，因此只能開辟盡可能大的內存空間或者先調用API接收消息頭來獲取消息體的大小，浪費了空間或者時間。
Binder更加穩定和安全。Binder是基於C/S架構的，技術上已經很成熟，穩定；共享內存沒有分層，難以控制，並發同步訪問臨界資源時，可能還會產生死鎖；從穩定性的角度講，Binder是優於共享內存的。Android是一個開源的系統，並且擁有開放性的平台，市場上應用來源很廣，因此安全性對於Android 平台而言極其重要。 傳統的IPC接收方無法獲得對方可靠的進程用戶ID/進程ID（UID/PID），無法鑒別對方身份。Android 為每個安裝好的APP分配了自己的UID， 通過進程的UID來鑒別進程身份。另外，Android系統中的Server端會判斷UID/PID是否滿足訪問許可權，而對外只暴露Client端，加強了系統的安全性。
㈦ android系統中出現的nativecrash反映的是系統哪一層的問題呀是framework層的問題嗎
Android平台程序崩潰的類型及原因列舉
ANR（可見ANR）：
發生場景：應用發生ANR。
崩潰症狀：系統彈出窗口詢問用戶選擇「Force Close」或者「Wait」。
"Force Close"將殺掉發生ANR的應用進程。"Wait"將會等待系統擇機恢復此應用進程。
發生原因：（1）應用主線程卡住，對其他請求響應超時。（2）死鎖。（3）系統反應遲鈍。（4）CPU負載過重。
Force Close：
發生場景：應用進程崩潰。
崩潰症狀：系統彈出窗口提示用戶某進程崩潰。
發生原因：空指向異常或者未捕捉的異常。
Tombstones：
發生場景：Native層崩潰
崩潰症狀：如果發生崩潰的native層和UI有關聯（比如Browser），我們可以在UI上發現這個崩潰。
如果發生崩潰的native層是在後台並且和UI沒有直接聯系，那麼對於用戶來說是不可見的，如果是debug版本可能會有Log列印出當時的底層現場。
發生原因：各種各樣，需要具體情況具體分析。
系統服務崩潰（System Server Crash）：
發生場景：系統服務是Android核心進程，此服務進程發生崩潰。
崩潰症狀：手機重啟到Android啟動界面
發生原因：（1）系統服務看門狗發現異常。（2）系統服務發生未捕獲異常。（3）OOM。（4）系統服務Native發生Tombstone。
Kernel Panics：
發生場景：Linux內核發生嚴重錯誤
崩潰症狀：手機從bootloader開始完全重啟
發生原因：（1）Linux內核內存空間發生內存崩潰。（2）內核看門狗發現異常。（3）空指針操作內核。
㈧ 請教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)