ZhaoKaiQiang

not work for me too, with the following exception info ``` 20:51:24 EmptyThrowable: Null child action in group Project View Popup Menu () of class class com.intellij.openapi.actionSystem.DefaultActionGroup, id=ComposeAction ```

And my Android Studio Version is 1.5

App里面有一个存在了半年多的BUG，偶尔发生，后来在解决其他BUG的时候不小心解决掉了，是因为重写了onSaveInstanceState造成的，少保存了一个数据。PS：这个BUG是前一个员工写出来的，我接手的

我觉得，如果你回到Activity程序Crash了，肯定是你的代码有问题，要不就是在Application存储了数据，被回收之后恢复现场出现了错误，要不就是你自己做了内容备份，但是备份的方式不对，造成不能正常恢复现场。如果你没有前面这两种情况，再次回来重启Activity的时候，会重新加载数据，而不应该是崩溃。所以崩溃一定是你的代码有问题

#谈谈你对Application类的理解 其实说对什么的理解，就是考察你对这个东西会不会用，重点是有没有什么坑！ --- 首先，Application在一个Dalvik虚拟机里面只会存在一个实例，所以你不要傻傻的去弄什么单例模式，来静态获取Application了，你把Application构造函数设置成privete都不可能实现(我年轻的时候就这么傻傻的试过，想着如果可以通过`Singleton.getInstance()`就能获取到Application对象，多爽呀~)。 那么为什么强调说是一个Dalvik虚拟机，而不是说一个App呢？ 因为一个App有可能有多个Dalvik虚拟机，也就是传说中的多进程模式。在这种模式下，每一个Dalvik都会存在一个Application实例，他们之间没有关系，在A进程Application里面保存的数据不能在B进程的Application获取，因为他们根本不是一个对象，而且被隔离在了两个进程里面，所以这里强调是一个Dalvik虚拟机，而不是一个App。 --- 其次，Application的实质是一个Context，它继承自ContextWrapper。 ``` android.content.Context ↳ android.content.ContextWrapper ↳ android.app.Application ``` ContextWrapper是什么玩意？就是对Context的一个包装而已。 Application有两个子类，一个是MultiDexApplication，如果你遇到了"65535"问题，可以选择继承自他，完成多Dex打包配置的相关工作。 另外一个是在TDD(测试用例驱动)开发模式中使用Moke进行测试的时候用到的，可以来代替Application的Moke类MockApplication。 --- 在应用启动的时候，会首先调用`Application.attach()`，当然，这个方法是隐藏的，开发者能接触到的第一个被调用的方法其实是`Application.onCreate()`，我们通常会在这个方法里面完成各种初始化，比如图片加载库、Http请求库的默认配置初始化操作等等。但是最好别在这个方法里面进行太多耗时操作，因为这会影响App的启动速度，所以对于不必要的操作可以使用异步操作、懒加载、延时加载等策略来减少对UI线程的影响。 --- 除此之外，由于在Context中可以通过getApplicationContext()获取到Application对象，或者是通过`Activity.getApplication()`、`Service.getApplication()`获取到Application，所以可以在Application保存全局的数据，供所有的Activity或者是Service使用。 PS：使用上面的三种方法获取到的都是同一个Application对象，getApplicationContext()是在Context的实现类ContextImpl中具体实现的，而getApplication()则是在Activity和Service中单独实现的，所以他们的作用域不同，但是获取到的都是同一个Application对象，因为一个Dalvik虚拟机只有一个Application对象。 但是这里存在着一个坑，那就是在低内存情况下，Application有可能被销毁，从而导致保存在Application里面的数据信息丢失，最后程序错乱，甚至是Crash。 所以当你想在Application保存数据的时候，请做好为空判断，或者是选择其他方式保存你的数据信息。 --- 另外，在Application中存在着几个有用的方法，比如onLowMemory()和onTrimMemory()，在这两个方法里面，我们可以实现自己的内存回收逻辑，比如关闭数据库连接、移除图片内存缓存等操作来降低内存消耗，从而降低被系统回收的风险。 --- 最后，就是要注意Application的生命周期，他和Dalvik虚拟机生命周期一样长，所以在进行单例或者是静态变量的初始化操作时，一定要用Application作为Context进行初始化，否则会造成内存泄露的发生。使用Dialog的时候一般使用Activity作为Context，但是也可以使用Application作为上下文，前提是你必须设置Window类型为TYPE_SYSTEM_DIALOG，并且申请相关权限。这个时候弹出的Dialog是属于整个Application的，弹出这个Dialog的Activity销毁时也不会回收Dialog，只有在Application销毁时，这个Dialog才会自动消失。 #更多参考资料...

恩恩，是的，多Dex打包可以重写这个方法

@08carmelo 覆巢之下无完卵，进程都被杀死了，并不是只有Application被销毁，而是包括Application在内的所有进程内对象都会被销毁

This not your wrong ,the library's owner not make it easy to use

这确实是一个问题，我之前想在onComplate()里面处理，即onNext()中显示结果之后再保存数据库，但是这样做的话，不能指定onComplate()的线程，只能和onNext()在同一个线程，但是这样做又会可能阻塞UI，所以暂时也没有好办法，我请教过朱凯，他也没有更好的解决方案，如果你知道更好的做法的话，可以继续交流^_^

我又想了下，这样做好像没有什么问题，因为在doOnNext()中会另外开启线程来处理，并不会缓存保存完才显示，而是开启线程之后，onNext()就执行了，你可以在doOnNext()中Sleep一下，就可以看出结果了，这样做应该是没问题的