android开发经常碰到的crash（下）

结合拜读包建强前辈著作的《App研发录》，与自己开发过程中遇到的问题，继续上篇对android开发经常碰到的crash探讨。上篇已经对空指针、数组越界、数据类型转换、fragment引用资源出错、dialog关闭报错、adapter数据改变与列表更新不同步、试图调用空对象的方法、列表滚动与刷新冲突报错、栈的无限递归引起栈溢出、多dex分包造成无法找到类定义、手机的CPU架构不同造成无法加载so文件等问题作了介绍。接下来对xml布局文件、系统资源碎片化控件使用、资源加载、数据库操作、内存溢出等常见crash进行分析。

1、InflateException:Binary XML file（加载出错：二进制XML文件）

此类问题是由于XML文件引用自定义控件或者本身书写不符合规范引起的。在报错地方有指出明确的出错行数，很容易定位并且修复。

2、NoSuchMethodError（没有该方法错误）

比如由于不同android版本提供方法的参数不同引发报错：java.lang.NoSuchMethodError:android.os.Bundle.getString。这是因为SharePreference提供的getString有两种版本参数：getString(String key) 与 getString(String key, int defaultValue)。第一种是android2.3以前的版本，而android2.3以后增加defaultValue这个参数。因此，系统碎片化引发的异常告诫我们多关注不同android版本的差异。

3、Unable to find app for caller android.app.ApplicationThreadProxy when stopping service Intent(Intent传值太大报错)

Intent里面传递一般数据不会报此类错误，但如果换成Bitmap那么就成为可能了。因为通常情况下，bundle携带超过1M数据，就会抛出该异常，而Bitmap往往会超过1M。因此，在使用Intent传递数据时，需要估计数据量大小，注意不要超过1M。

4、IllegalArgumentException:Receiver not registerd(非法参数异常：接受者没有注册)

在Activity中使用ViewFlipper控件，进行横竖屏切换操作时就会发生此异常。一般原因是onDetachedFromWindow()在onAttachedToWindow()之前被调用引起的，因为还没有关联到对应窗体，就从窗体解除关联。我在做垂直滚动公告时，使用ViewFlipper控件就碰到该问题。后来自定义一个控件继承ViewFlipper重写onDetachedFromWindow()方法，里面加上try-catch。

protected void onDetachedFromWindow(){   try{     super.onDetachedFromWindow();   }catch(IllegalArgumentException e){    stopFlipping();   }}

5、Package manager has died(包管理器已经不存在)

出现此类异常说明PackageManager所在的进程已经不存在了，或者App本身处于崩溃状态。解决方法是，每次获取PackageManager时使用try-catch捕获异常。

6、IllegalStateException:Can not perform this action after onSaveInstanceState（不合法状态异常）

commit方法在Activity的onSaveInstanceState（）之后被调用就会报错。因为onSaveInstanceState方法是在Activity即将被销毁前调用，以保存Activity数据。其中一种情况是，如果在保存完状态后再给它添加Fragment就会报错。对应解决方法是将commit替换成commitAllowingStateLoss()。

7、SQLException:cannot commit-no transaction is active（数据库异常：无法提交—事务不处于活动状态）

在事务中，逐条循环插入（for + insert）大量数据时会导致此类 崩溃。因为android在SQLite插入数据时默认一条语句就是一个事务。解决方法是采用sql语句加上事务机制，操作完毕设置事务成功，把数据同步给数据库。

    private void insertToDB(SQLiteDatabase db, List<String> sqlList) {        db.beginTransaction(); // 开始事务        try {            for(String sql:sqlList) {//自定义sql语句集合遍历               db.execSQL(sql);            }            db.setTransactionSuccessful();//设置事务成功标志        } catch (Exception e) {            e.printStackTrace();        } finally {            db.endTransaction();//结束事务        }    }

8、CursorWindowAllocationException:cursor window allocation of 2048KB failed(游标窗体分配异常)

这个异常是因为使用数据库查询时，忘记关闭游标导致的，内存泄露得多了，就导致崩溃。对应解决方法是手动关闭cursor。

if(cursor != null && !cursor.isClosed())   cursor.close();

9、SQLiteDatabaseLockedException:database is locked(数据库被锁异常)

当我们试图在不同线程中创建多个数据库连接时，就会抛出此异常。对应的解决方法是将数据库设置为单例模式。如果是多进程，应该考虑使用Contentprovider。下面介绍下数据库的单例模式写法：

    private static ContactDBManager mInstance = new ContactDBManager(ContactApplication.getInstance());    public static ContactDBManager getInstance() {        return mInstance;    }

10、SQLiteDiskIOException:disk I/O error(数据库磁盘IO操作异常)

有一种情况是webView中使用到数据库作为缓存，读写缓存异常引发崩溃。webView有两种缓存：网页数据缓存和HTML5缓存。而且缓存模式有5种：

模式

介绍

LOAD_CACHE_ONLY只读本地缓存数据LOAD_DEFAULT根据cache-control决定是否从网络读取LOAD_CACHE_NORMAL从API 11开始作用通LOAD_DEFAULT模式LOAD_NO_CACHE不使用缓存，只从网络获取数据LOAD_CACHE_ELSE_NETWORK只要本地有，无论是否过期，都是用缓存数据根据以上5种模式，建议缓存策略为：判断如果有网络，使用LOAD_DEFAULT模式，否则使用模式LOAD_CACHE_ELSE_NETWORK。

11、SQLiteDiskIOException:disk I/O error（多线程操作数据库引发磁盘读写错误）

考虑到多线程同时操作数据库，建议在操作数据库的方法加上syncronized关键字。

12、OutOfMemoryException（内存溢出）

android系统预先给每个app分配内存，比如80M。在AndroidManifest.xml文件加上这个语句：<application  android:largeHeap =  true>，这样可以获得更大内存分配额度。但是不可能是无限制无上限。我在一个项目中通讯录一次性加载20000条数据，就抛出此异常。性能好的手机抛出该异常的时间会延后一点，性能差的手机则会相对快一点。后来是采用分页加载分页显示，才解决此问题。另外，建议大家尽量避免内存泄露，因为内存泄露多了最终会引发内存溢出；不要频繁创建对象（能够复用就复用）；涉及多线程编程，使用线程池管理（任玉刚前辈在《android开发艺术探索》书中推荐）。

13、JSONException:no value for XXX(json解析溢出)

如果在使用getString("name")而不是optString("name")，并且name这个key值在json字符串中不存在，前者会抛出异常，后者则会返回空值。类似地，还有getJSONArray方法，建议使用optJSONArray。

14、IllegalArgumentException:parameter must be a descendant of this view

这个崩溃是通过ViewGroup的offRectBetweenParentAndChild方法抛出的。该方法用来计算父子的重叠区域。它是通过所给的descendant这个view逐级向上寻找Parent View，同时将Rect转换为同级坐标系来计算。如果在UI发生改变后，就会改变当前界面所拥有焦点的控件，就会引发此问题。解决方法是，每次都重新设置焦点，保证当前View始终获得焦点。与此同时，还要清空其他控件抢占的焦点。

在国庆节期间花了一个下午，来补充android开发常见的crash，自己印象更加深刻，以此告诫自己不要犯类似错误。希望也可以帮助到读者解决这些crash或者避免它们发生。