片段的onActivityCreated()活动中的onDestroy()后调用 [英] Fragment's onActivityCreated() is called after onDestroy() of Activity

查看:161
本文介绍了片段的onActivityCreated()活动中的onDestroy()后调用的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

今天,我发现一个奇怪的行为,在我的应用程序。

Today I noticed a strange behavior in my application.

这发生在我使用的设备从Eclipse中查看阻止我的申请。有人能解释一下吗?

It happens when I stop my application using Devices view from Eclipse. Can someone explain it?

为什么 onActivityCreated() 片段堪称即使活动已被破坏? MyHomeActivity 包含两个片段和两个产生类似的日志。

Why is onActivityCreated() of Fragment called even when Activity is already destroyed? MyHomeActivity contains two Fragments and similar log is generated for both.

下面我粘贴日志一片段 NullPointerException异常是一个次要问题。

Here I am pasting logs for one Fragment. NullPointerException is a secondary problem.

我觉得很奇怪,为什么 onActivityCreated()当调用堆栈是从的onDestroy()的启动被称为 MyHomeActivity

I am surprised why onActivityCreated() is called when the call stack was initiated from onDestroy() of MyHomeActivity?

03-05 12:31:21.414: W/System.err(5638): java.lang.NullPointerException
03-05 12:31:21.421: W/System.err(5638):     at **MyListViewFrag.onActivityCreated**(BuddyListViewFrag.java:85)
03-05 12:31:21.421: W/System.err(5638):     at android.support.v4.app.Fragment.performActivityCreated(Fragment.java:1468)
03-05 12:31:21.421: W/System.err(5638):     at android.support.v4.app.FragmentManagerImpl.moveToState(FragmentManager.java:931)
03-05 12:31:21.421: W/System.err(5638):     at android.support.v4.app.FragmentManagerImpl.moveToState(FragmentManager.java:1088)
03-05 12:31:21.421: W/System.err(5638):     at android.support.v4.app.FragmentManagerImpl.moveToState(FragmentManager.java:1070)
03-05 12:31:21.421: W/System.err(5638):     at android.support.v4.app.FragmentManagerImpl.dispatchReallyStop(FragmentManager.java:1888)
03-05 12:31:21.421: W/System.err(5638):     at android.support.v4.app.FragmentActivity.onReallyStop(FragmentActivity.java:787)
03-05 12:31:21.421: W/System.err(5638):     at android.support.v4.app.FragmentActivity.doReallyStop(FragmentActivity.java:764)
03-05 12:31:21.421: W/System.err(5638):     at android.support.v4.app.FragmentActivity.onDestroy(FragmentActivity.java:322)
03-05 12:31:21.421: W/System.err(5638):     at MyFragmentActivity.onDestroy(RbrFragmentActivity.java:57)
03-05 12:31:21.421: W/System.err(5638):     at **MyHomeActivity.onDestroy**(MyHomeActivity.java:254)
03-05 12:31:21.421: W/System.err(5638):     at android.app.ActivityThread.performDestroyActivity(ActivityThread.java:2663)
03-05 12:31:21.421: W/System.err(5638):     at android.app.ActivityThread.handleDestroyActivity(ActivityThread.java:2694)
03-05 12:31:21.421: W/System.err(5638):     at android.app.ActivityThread.access$2100(ActivityThread.java:117)
03-05 12:31:21.421: W/System.err(5638):     at android.app.ActivityThread$H.handleMessage(ActivityThread.java:968)
03-05 12:31:21.421: W/System.err(5638):     at android.os.Handler.dispatchMessage(Handler.java:99)
03-05 12:31:21.421: W/System.err(5638):     at android.os.Looper.loop(Looper.java:130)
03-05 12:31:21.421: W/System.err(5638):     at android.app.ActivityThread.main(ActivityThread.java:3687)
03-05 12:31:21.429: W/System.err(5638):     at java.lang.reflect.Method.invokeNative(Native Method)
03-05 12:31:21.429: W/System.err(5638):     at java.lang.reflect.Method.invoke(Method.java:507)
03-05 12:31:21.429: W/System.err(5638):     at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:867)
03-05 12:31:21.429: W/System.err(5638):     at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:625)
03-05 12:31:21.429: W/System.err(5638):     at dalvik.system.NativeStart.main(Native Method)

我使用支持库提供片段 s至pre-蜂窝设备,如果让任何区别。

I am using support library for providing Fragments to pre-HoneyComb devices, if that makes any difference.

推荐答案

在一些测试和审查<一href="http://www.grep$c$c.com/file/repository.grep$c$c.com/java/ext/com.google.android/android/4.2.2_r1/android/support/v4/app/FragmentManager.java?av=f">FragmentManager.moveToState,我相信,当片段正由 FragmentPagerAdapter ,这是不可避免的处理,一个片段这是previously合并成savedState(如停止应用程序的过程中,你杀了从Eclipse的DDMS选项卡中的过程之前),首先必须创造(在术语对 FragmentManager ),然后才能被破坏。

After some testing and reviewing FragmentManager.moveToState, I believe that when the Fragment is being handled by a FragmentPagerAdapter, it is unavoidable that a Fragment which was previously coalesced into savedState (as part of the process of stopping the app before you kill the process from the DDMS tab in eclipse), must first be "created" (in the terminology of FragmentManager) before it can be destroyed.

这实际上可能是从已保存的状态重建片段的过程中的意外后果。当 FragmentActivity 在执行的onCreate 完成()是所谓的,其用意是, FragmentActivity 停止设置并退出。视觉经验是,发生这种情况,但似乎像 FragmentManager 需要它itsself继续生命周期为previously现有的片段 S,albiet一些捷径。这个过程似乎执行生命周期方法达到 onActivityCreated 键,然后执行的onDestroy onDetach ,跳过那些之间。

This may actually be an unintended consequence of the process of rebuilding the fragments from saved state. When the FragmentActivity is executing onCreate and finish() is called, the intention is that the FragmentActivity stops setting up and exits. The visual experience is that this occurs, but it seems like the FragmentManager takes it on itsself to continue the lifecycle for previously existing Fragments, albiet with some short cuts. This process seems to execute the lifecycle methods up to onActivityCreated and then execute onDestroy and onDetach, skipping those in between.

要处理这一问题的最佳方法似乎是解决次要问题(在这种情况下,你的NPE)引起的该启动。好像会有空间来优化该出片段的生命周期,但与R12支持库,情况似乎是设计的结果。

The best way to handle this appears to be to address the secondary issues (in this case, your NPE) caused by this startup. It seems like there would be room to optimize this out of the Fragment lifecycle, but with the r12 support library, the situation appears to be a consequence of the design.

这篇关于片段的onActivityCreated()活动中的onDestroy()后调用的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆