如何避免Activity 被杀死

  我们都知道,在android系统中,内存不足的时候,系统是可以杀死任何暂停、停止或者销毁的Activity。这就意味着基本上没有在前台的Activity都会面临被关闭的可能。

  Android系统之所以采用这个机制,而不是像ios系统一样采用墓碑式的管理方式,是因为这样可以在一定程度上加快应用的响应速度,但是由于以前的android手机的性能比较落后,手机运行内存RAM基本上处于2G以内,所以就会导致一些不在前台的Activity有可能被回收,但是现在的智能手机性能已经足够强悍,拿我现在的这部手机——一加手机3(6GRAM)来说,但是之前官方表示为了手机的续航,将内存机制进行修改,使得当用户打开的应用超过一定数量的时候,系统就会对一些Activity进行回收,所以重新打开这些Activity的时候,就会出现重新加载的情况,这在打开大型游戏的时候比较常见。

  那我们在开发的时候如何在系统资源吃紧的时候将一些必要的数据进行及时的存储保护,避免数据的丢失呢?

  我们来看官方API中给出的一个关于Activity的生命周期的图解:

如何避免Activity 被杀死

  如果Activity在onPause()后被杀掉,那么onStop()和onDestroy()方法就不会被调用,所以如果在onPause()方法内更多的释放Activity资源,就会让Activity在后台被系统杀掉的几率降低。

  但是杀死一个Activity并不会导致它从Activity堆栈中移除,相反如果Activity实现并使用了onSaveInstanceState()方法用来自定义的保存数据,那么Activity的状态就会被保存到Bundle中,这样当Activity被重新返回的时候,onCreate()方法会被再次调用,这样刚才保存有数据的Bundle对象就会被调用,将数据重新读取;但是该方法并不能保证在任何时候都能被调用。因此我们应该在onPause()方法中保存重要的数据到永久存储(即手机硬件内存中)而用onSaveInstanceState()来保存一些可以从当前屏幕快速恢复的数据(相对不重要的数据)。

BOB

好久没有更新了,接下来会勤奋些的

上一篇:HTML cellpadding与cellspacing属性


下一篇:理解和解决requireJS的报错:MODULE NAME HAS NOT BEEN LOADED YET FOR CONTEXT