一个application相关的bug。。。

起因

由于一个先上bug,后台一致有人反馈应用老是停止运行,也不是crash,就是老是出现弹窗显示奔溃。

日志:

一个application相关的bug。。。_第1张图片
Paste_Image.png

![Uploading Paste_Image_319635.png . . .]

很明显空指针引起的 ,定位到代码

Paste_Image.png

就是一个DP转PX的方法,这里能空也就getDisplayMetrics()这个方法相关的了....也就只有getContext()的时候拿到null导致nullpoint了

再看看MovieApplication.getContext()

一个application相关的bug。。。_第2张图片
Paste_Image.png

很简单就是返回一个静态变量

一个application相关的bug。。。_第3张图片
Paste_Image.png

这是sContext被赋值的地方,也就是只有在主进程才会被赋值

上面的crash日志还有一部分指到的是

一个application相关的bug。。。_第4张图片
Paste_Image.png
private void clearImageMemoryCache() {
    Injector injector = RoboGuice.getInjector(this);
    ImageLoader imageLoader = injector.getInstance(ImageLoader.class);
    imageLoader.clearMemoryCache();
}

使用注入去调用ImageLoader的clearMemoryCache()方法,其实就是在内存吃紧的情况下会清除图片缓存。

ImageLoader的注入又依赖了三个实例Picasso ImageConst


一个application相关的bug。。。_第5张图片
Paste_Image.png

ImageConsts就是一些常用尺寸的封装类


一个application相关的bug。。。_第6张图片
Paste_Image.png

可以看到有一些静态变量调用了DimenUtils.dp2px 也就是空指针的那个方法。。。然后捋一捋。。。bug原因也就定位了。

子进程(push或其他)进程也调用了ontrimmemory的方法
导致初始化了imageConsts的实例,但是我们只是在主进程对context进行了赋值,所以后台进程就会奔溃。。。(每个子进程都会初始化一个application的实例,也就是我们有4个进程,就会有四个application的实例,oncreate方法在启动的时候就会调用四次)

最简单的解决方案当然就是吧context的赋值放出来就行了,但是为了避免后人也遇到类似的问题,就把application进行了拆分——>application拆分

你可能感兴趣的:(一个application相关的bug。。。)