由于应用程序和小部件之间的死锁而导致的ANR? [英] ANR due to deadlock between app and widget?
问题描述
我有一个Android应用程序，其中a)在线程中执行updateData()函数(从互联网查询内容提供商和来自互联网的HTTP请求)，b)具有执行相同updateData()函数的主屏幕小部件每30分钟一次(不在线程中).
I have an android app that a) performs an updateData() function (querying content providers and HTTP requests from internet among other things) in a thread, and b) has a home screen widget that performs the same updateData() function every 30mins (not in a thread).
a)看起来像这样:
public class MoodMain extends Activity{
public void onCreate(...)
{
Thread t = new Thread()
{
public void run()
{
updateData(this);
}
};
t.start();
}
b)看起来像这样:
public class MoodAppWidgetProvider extends AppWidgetProvider {
public void onUpdate(Context context, ...)
{
updateData(context);
} }
现在人们正在报告ANR，其中线程在updateData(context)中的同一位置停止，一个线程用于a)，一个线程用于b).堆栈跟踪如下所示:
Now people are reporting ANRs where threads are stopped at same place in updateData(context), one thread for a) and one for b). Stack traces look like the following:
第一个示例:
"main" prio = 5 tid = 1 NATIVE | group ="main" sCount = 1 dsCount = 0 s = N obj = 0x40025ad8 self = 0xcd80 | sysTid = 23053 nice = 0 sched = 0/0 cgrp =默认句柄= -1345017808 | schedstat =(5672943129 29267974835 13299)，位于android.os.BinderProxy.transact(本机方法)， android.content.ContentProviderProxy.bulkQueryInternal(ContentProviderNative.java:370) 在 android.content.ContentProviderProxy.query(ContentProviderNative.java:408) ...
"main" prio=5 tid=1 NATIVE | group="main" sCount=1 dsCount=0 s=N obj=0x40025ad8 self=0xcd80 | sysTid=23053 nice=0 sched=0/0 cgrp=default handle=-1345017808 | schedstat=( 5672943129 29267974835 13299 ) at android.os.BinderProxy.transact(Native Method) at android.content.ContentProviderProxy.bulkQueryInternal(ContentProviderNative.java:370) at android.content.ContentProviderProxy.query(ContentProviderNative.java:408) ...
"Thread-10" prio = 5 tid = 9 NATIVE | group ="main" sCount = 1 dsCount = 0 s = N obj = 0x4629ba88 self = 0x2d1750 | sysTid = 23062 nice = 0 sched = 0/0 cgrp =默认句柄= 2955408 | schedstat =(53100602 8822875969 600) 在android.os.BinderProxy.transact(本机方法)处 android.content.ContentProviderProxy.bulkQueryInternal(ContentProviderNative.java:370) 在 android.content.ContentProviderProxy.query(ContentProviderNative.java:408) 在android.content.ContentResolver.query(ContentResolver.java:245)...
"Thread-10" prio=5 tid=9 NATIVE | group="main" sCount=1 dsCount=0 s=N obj=0x4629ba88 self=0x2d1750 | sysTid=23062 nice=0 sched=0/0 cgrp=default handle=2955408 | schedstat=( 53100602 8822875969 600 ) at android.os.BinderProxy.transact(Native Method) at android.content.ContentProviderProxy.bulkQueryInternal(ContentProviderNative.java:370) at android.content.ContentProviderProxy.query(ContentProviderNative.java:408) at android.content.ContentResolver.query(ContentResolver.java:245) ...
第二个示例:
"main" prio = 5 tid = 1 NATIVE | group ="main" sCount = 1 dsCount = 0 s = N obj = 0x40020a30 self = 0xcd88 | sysTid = 19319 nice = 0预定== 0/0 cgrp =默认句柄= -1345026000 at java.net.InetAddress.getaddrinfo(本机方法)位于 java.net.InetAddress.lookupHostByName(InetAddress.java:508)在 java.net.InetAddress.getAllByNameImpl(InetAddress.java:280)在 java.net.InetAddress.getByName(InetAddress.java:310)在 java.net.InetSocketAddress.(InetSocketAddress.java:110)...
"main" prio=5 tid=1 NATIVE | group="main" sCount=1 dsCount=0 s=N obj=0x40020a30 self=0xcd88 | sysTid=19319 nice=0 sched=0/0 cgrp=default handle=-1345026000 at java.net.InetAddress.getaddrinfo(Native Method) at java.net.InetAddress.lookupHostByName(InetAddress.java:508) at java.net.InetAddress.getAllByNameImpl(InetAddress.java:280) at java.net.InetAddress.getByName(InetAddress.java:310) at java.net.InetSocketAddress.(InetSocketAddress.java:110) ...
"Thread-10" prio = 5 tid = 9 NATIVE | group ="main" sCount = 1 dsCount = 0 s = N obj = 0x458842e8 self = 0x245cc0 | sysTid = 20153 nice = 0 sched = 0/0 cgrp =默认句柄= 2388904，位于 java.net.InetAddress.getaddrinfo(本机方法)位于 java.net.InetAddress.lookupHostByName(InetAddress.java:508)...
"Thread-10" prio=5 tid=9 NATIVE | group="main" sCount=1 dsCount=0 s=N obj=0x458842e8 self=0x245cc0 | sysTid=20153 nice=0 sched=0/0 cgrp=default handle=2388904 at java.net.InetAddress.getaddrinfo(Native Method) at java.net.InetAddress.lookupHostByName(InetAddress.java:508) ...
"Thread-8" prio = 5 tid = 7 NATIVE | group ="main" sCount = 1 dsCount = 0 s = N obj = 0x45867030 self = 0x22c528 | sysTid = 20151 nice = 0 sched = 0/0 cgrp =默认句柄= 2277944，位于 java.net.InetAddress.getaddrinfo(本机方法)位于 java.net.InetAddress.lookupHostByName(InetAddress.java:508)...在 com.admob.android.ads.i.d(AdMobURLConnector.java:153)在 com.admob.android.ads.b.a(AdRequester.java:206)位于 com.admob.android.ads.AdView $ b.run(AdView.java:655)
"Thread-8" prio=5 tid=7 NATIVE | group="main" sCount=1 dsCount=0 s=N obj=0x45867030 self=0x22c528 | sysTid=20151 nice=0 sched=0/0 cgrp=default handle=2277944 at java.net.InetAddress.getaddrinfo(Native Method) at java.net.InetAddress.lookupHostByName(InetAddress.java:508) ... at com.admob.android.ads.i.d(AdMobURLConnector.java:153) at com.admob.android.ads.b.a(AdRequester.java:206) at com.admob.android.ads.AdView$b.run(AdView.java:655)
看起来像某种任务死锁.有什么想法可以解决这个问题吗?
Looks like some kind of task deadlock. Any ideas how to solve this anyone please?
推荐答案
我认为问题是我在widgetProvider的onUpdate()函数中进行了很长的处理.我修改了代码以产生一个线程来执行增强功能，到目前为止，没有再有用户报告冻结.
I believe the issue is the fact I am doing a long process in the onUpdate() function of the widgetProvider. I modified my code to spawn a thread to perform the intensive functionality, and so far, no more freezes have been reported from users.
这篇关于由于应用程序和小部件之间的死锁而导致的ANR?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
