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)