BUG fix 记一次翻车事故 SQLiteException: no such table: xxx(code 1): , while compiling: SELECT

 如上所示: 真是惨痛的BUG  我找了很久. 寻找过程如下:

1 由于机器是刷机开机之后,报了这个错误,报错之后,再次进入原来报错界面就不会报错了. 所以不是很好测试.  同事建议我说,可以把数据库导出来看看是否存在对应的数据库(十分感谢同事!!)  在经过临时ROOT机器之后,一层一层的通过命令行去改变文件权限并进入到对应的包名数据库下面,pull出了数据库,然后发现数据库里面的数据都是存在的,包名也存在. 那为什么BUG显示不存在包名呢?

2 经过分析,也就是说在即使是报了异常,数据库依然会创建成功,真是坚强啊!  这个时候没辙了感觉. 于是去具体的分析存在的log信息, 刚开始我是过滤了log信息,只去显示loge, 所以不能完全显示所有的log信息. 所以在同事的催促下,我再次重现BUG,并抓取了所有的log信息, 发现了一条系统error ,我心想系统错误应该跟我没关系,然后就过滤掉了,去查看其他信息,去查找报错的源头,查找未果,于是换了一个方向,去看了那条系统error的具体信息,发现了一个空指针异常的报错,从此也发现了自己的一个盲区

3 我找到了对应的报错位置, 是在数据库的DataBaseHelper里面,报错空指针异常, 在此处我引用了一个context,这个context 是在我自定义的application的oncreate里面初始化成功,然后通过设置静态的方式提供出去的

    private static Context mContext;

   @Override
    public void onCreate() {
        // TODO Auto-generated method stub
        super.onCreate();

        mContext = this.getApplicationContext();

   public static Context getContext() {
        return mContext;
    }

然后,我觉得application初始化那么早,怎么可能会出现空指针呢?  于是我万能才同事提出了一个设想就是, contentProvider的context 要比 application 的oncreate先初始化,所以导致空指针. 后来经过写demo测试发现,确实存在这个问题.

就先在Application，Activity和ContentProvider三个类的onCreate函数中打印了log，发现它们的启动顺序为：

Application->attachBaseContext =====>ContentProvider->onCreate =====>Application->onCreate =====>Activity->onCreate
--------------------- 
原文链接：https://blog.csdn.net/beyond702/article/details/49666809

原来他们的启动顺序不一致导致我盲目的去写代码, 基础知识还是太欠缺了,基础不牢地动山摇啊!!!! ,而且发现ContentProvider里面的context和Application的onCreate里面获取到的context是同一个context

后来也是向同事表达了谢意,然后提交了代码!  花了一下午的时间解决了这个问题,发现了自己的知识盲点,也是蛮开心的,希望以后还是多打好基础

我原来以为application里面初始化的context可以在任何地方去调用的,想不到这次翻了车,阿西吧!

在查找的过程中涉及到的知识包括:

linux和adb命令行: 改变文件和文件夹的权限,如何临时root

数据库:android数据库在机器中的具体位置,如何进入数据库界面,如何导出数据库,如何打开数据库(涉及到的工具)

android基础知识点:Application和ContentProvider的启动顺序