布局在某些设备上使用ANR崩溃应用程序

Question

我一直在努力解决这个问题几天。我们的应用程序可以在多个设备上运行，但在某些设备上加载时会崩溃（ANR崩溃）。下面的一个例子：

<?xml version="1.0" encoding="utf-8"?> 
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android" 
    android:layout_width="match_parent" 
    android:layout_height="match_parent" 
    android:background="@drawable/view_background" 
    android:orientation="vertical" 
    android:paddingLeft="0dp" 
    android:paddingRight="0dp" 
    android:paddingTop="0dp" > 

    <FrameLayout 
     android:layout_width="match_parent" 
     android:layout_height="wrap_content" 
     android:background="@drawable/back_searchbar" 
     android:paddingLeft="10dp" 
     android:paddingRight="10dp" 
     android:paddingTop="2dp" > 

     <EditText 
      android:id="@+id/filterEdit" 
      android:layout_width="match_parent" 
      android:layout_height="wrap_content" 
      android:layout_gravity="center_vertical" 
      android:background="@drawable/rounded_edittext" 
      android:drawablePadding="8dp" 
      android:hint="@string/search" 
      android:paddingLeft="30dp" 
      android:paddingRight="10dp" 
      android:singleLine="true" /> 

     <Button 
      android:id="@+id/searchBtn" 
      android:layout_width="wrap_content" 
      android:layout_height="wrap_content" 
      android:layout_gravity="left|center_vertical" 
      android:layout_margin="10dp" 
      android:background="@drawable/icon_magnify" /> 
    </FrameLayout> 

    <ListView 
     android:id="@+id/listView" 
     style="@style/mmListView" 
     android:layout_width="match_parent" 
     android:layout_height="match_parent" 
     android:background="@drawable/view_background" 
     android:cacheColorHint="#00000000" 
     android:divider="@drawable/list_divider" 
     android:dividerHeight="8dp" 
     android:footerDividersEnabled="true" 
     android:headerDividersEnabled="true" 
     android:listSelector="@android:color/transparent" > 

    </ListView> 

</LinearLayout> 

例如，应用程序崩溃在Galaxy S运行Android 2.3.3（ANR崩溃）。我们知道其他具有相同问题的模型。令我们感兴趣的是，如果我们从布局中移除FrameLayout部件，它将被正确加载。此外，相同的应用程序在其他设备上运行没有任何问题。

我们使用BugSense，但这种崩溃不会导致报告。

这里是logcat的最后几行：

07-16 14:34:16.113: D/dalvikvm(17786): GC_EXTERNAL_ALLOC freed 415K, 43% free 5210K/9095K, external 5930K/6095K, paused 39ms 
07-16 14:34:20.312: I/dalvikvm(17786): threadid=4: reacting to signal 3 
07-16 14:34:21.316: W/dalvikvm(17786): threadid=4: spin on suspend #1 threadid=37 (pcf=0) 
07-16 14:34:22.066: W/dalvikvm(17786): threadid=4: spin on suspend #2 threadid=37 (pcf=0) 
07-16 14:34:22.066: I/dalvikvm(17786): "Signal Catcher" daemon prio=5 tid=4 RUNNABLE 
07-16 14:34:22.066: I/dalvikvm(17786): | group="system" sCount=0 dsCount=0 obj=0x4050fbd8 self=0x114e90 
07-16 14:34:22.066: I/dalvikvm(17786): | sysTid=17789 nice=0 sched=0/0 cgrp=default handle=1134160 
07-16 14:34:22.066: I/dalvikvm(17786): at dalvik.system.NativeStart.run(Native Method) 
07-16 14:34:22.066: I/dalvikvm(17786): "(null)" prio=0 tid=37 RUNNABLE 
07-16 14:34:22.066: I/dalvikvm(17786): | group="(null; initializing?)" sCount=1 dsCount=0 obj=0x408192d8 self=0x3c9708 
07-16 14:34:22.066: I/dalvikvm(17786): | sysTid=17933 nice=0 sched=0/0 cgrp=default handle=3954088 
07-16 14:34:22.066: I/dalvikvm(17786): at java.lang.Thread.<init>(Thread.java:~386) 
07-16 14:34:22.066: I/dalvikvm(17786): at dalvik.system.NativeStart.run(Native Method) 
07-16 14:34:22.816: W/dalvikvm(17786): threadid=4: spin on suspend #3 threadid=37 (pcf=0) 
07-16 14:34:22.816: I/dalvikvm(17786): "Signal Catcher" daemon prio=5 tid=4 RUNNABLE 
07-16 14:34:22.816: I/dalvikvm(17786): | group="system" sCount=0 dsCount=0 obj=0x4050fbd8 self=0x114e90 
07-16 14:34:22.816: I/dalvikvm(17786): | sysTid=17789 nice=0 sched=0/0 cgrp=default handle=1134160 
07-16 14:34:22.816: I/dalvikvm(17786): at dalvik.system.NativeStart.run(Native Method) 
07-16 14:34:22.816: I/dalvikvm(17786): "(null)" prio=0 tid=37 RUNNABLE 
07-16 14:34:22.816: I/dalvikvm(17786): | group="(null; initializing?)" sCount=1 dsCount=0 obj=0x408192d8 self=0x3c9708 
07-16 14:34:22.816: I/dalvikvm(17786): | sysTid=17933 nice=0 sched=0/0 cgrp=default handle=3954088 
07-16 14:34:23.019: I/dalvikvm(17786): at java.lang.Thread.<init>(Thread.java:~386) 
07-16 14:34:23.019: I/dalvikvm(17786): at dalvik.system.NativeStart.run(Native Method) 
07-16 14:34:23.769: W/dalvikvm(17786): threadid=4: spin on suspend #4 threadid=37 (pcf=0) 
07-16 14:34:23.769: I/dalvikvm(17786): "Signal Catcher" daemon prio=5 tid=4 RUNNABLE 
07-16 14:34:23.769: I/dalvikvm(17786): | group="system" sCount=0 dsCount=0 obj=0x4050fbd8 self=0x114e90 
07-16 14:34:23.769: I/dalvikvm(17786): | sysTid=17789 nice=0 sched=0/0 cgrp=default handle=1134160 
07-16 14:34:23.769: I/dalvikvm(17786): at dalvik.system.NativeStart.run(Native Method) 
07-16 14:34:23.769: I/dalvikvm(17786): "(null)" prio=0 tid=37 RUNNABLE 
07-16 14:34:23.769: I/dalvikvm(17786): | group="(null; initializing?)" sCount=1 dsCount=0 obj=0x408192d8 self=0x3c9708 
07-16 14:34:23.769: I/dalvikvm(17786): | sysTid=17933 nice=0 sched=0/0 cgrp=default handle=3954088 
07-16 14:34:23.851: I/dalvikvm(17786): at java.lang.Thread.<init>(Thread.java:~386) 
07-16 14:34:23.851: I/dalvikvm(17786): at dalvik.system.NativeStart.run(Native Method) 
07-16 14:34:24.601: W/dalvikvm(17786): threadid=4: spin on suspend #5 threadid=37 (pcf=0) 
07-16 14:34:24.601: I/dalvikvm(17786): "Signal Catcher" daemon prio=5 tid=4 RUNNABLE 
07-16 14:34:24.601: I/dalvikvm(17786): | group="system" sCount=0 dsCount=0 obj=0x4050fbd8 self=0x114e90 
07-16 14:34:24.601: I/dalvikvm(17786): | sysTid=17789 nice=0 sched=0/0 cgrp=default handle=1134160 
07-16 14:34:24.601: I/dalvikvm(17786): at dalvik.system.NativeStart.run(Native Method) 
07-16 14:34:24.601: I/dalvikvm(17786): "(null)" prio=0 tid=37 RUNNABLE 
07-16 14:34:24.601: I/dalvikvm(17786): | group="(null; initializing?)" sCount=1 dsCount=0 obj=0x408192d8 self=0x3c9708 
07-16 14:34:24.601: I/dalvikvm(17786): | sysTid=17933 nice=0 sched=0/0 cgrp=default handle=3954088 
07-16 14:34:24.601: I/dalvikvm(17786): at java.lang.Thread.<init>(Thread.java:~386) 
07-16 14:34:24.601: I/dalvikvm(17786): at dalvik.system.NativeStart.run(Native Method) 
07-16 14:34:25.351: W/dalvikvm(17786): threadid=4: spin on suspend #6 threadid=37 (pcf=0) 
07-16 14:34:25.351: I/dalvikvm(17786): "Signal Catcher" daemon prio=5 tid=4 RUNNABLE 
07-16 14:34:25.351: I/dalvikvm(17786): | group="system" sCount=0 dsCount=0 obj=0x4050fbd8 self=0x114e90 
07-16 14:34:25.351: I/dalvikvm(17786): | sysTid=17789 nice=0 sched=0/0 cgrp=default handle=1134160 
07-16 14:34:25.355: I/dalvikvm(17786): at dalvik.system.NativeStart.run(Native Method) 
07-16 14:34:25.355: I/dalvikvm(17786): "(null)" prio=0 tid=37 RUNNABLE 
07-16 14:34:25.355: I/dalvikvm(17786): | group="(null; initializing?)" sCount=1 dsCount=0 obj=0x408192d8 self=0x3c9708 
07-16 14:34:25.355: I/dalvikvm(17786): | sysTid=17933 nice=0 sched=0/0 cgrp=default handle=3954088 
07-16 14:34:25.359: I/dalvikvm(17786): at java.lang.Thread.<init>(Thread.java:~386) 
07-16 14:34:25.359: I/dalvikvm(17786): at dalvik.system.NativeStart.run(Native Method) 

什么回事任何想法？或者我们如何避免这样的问题？

Answer 1

我发现了这个问题。 “@ drawable/back_searchbar”使用JPG图像（渐变背景）。我们不知道原因，但用渐变填充的图形替换图像解决了应用程序一致崩溃的模型中的问题。