Activity Return 转换 - 共享元素 - 已杀死 Activity
Activity Return Transitions - Shared Elements - Killed Activity
使用的库：appcompat-v7:22.2.1,design:22.2.1
使用的主题：
Devices/Android 版本转载于：Nexus 6
问题：Return activity 快速 redraws/appears 然后淡入所需的行为，只有 "Don't keep activities alive".
我想知道这是错误还是预期行为。我有一个非常简单的设置。 Activity A 包含包裹在 AppbarLayout 和 CoorindinatorLayout 中的工具栏。工具栏包含一个 Cardview 和一个 TextView。单击 TextView，Activity A 启动 Activity B。我正在使用共享元素并通过 ActivityCompat.StartActivity(bundle, options);
作为选项传递它们
即使在设备旋转之后，我的共享元素也能完美运行。在阅读了我如何 PostPoneEnterTransition 并将其与 PreDrawListeners 结合起来之后，即使在旋转后我也能够成功实现所需的过渡。我的实际 activity 包含一个 Viewpager / TabLayout 和 2+ 个片段，但为了简单起见，我在视频中将其剥离并查看是否有其他原因导致此问题.
在处理回车转换回 Activity A 的旋转和推迟时，我决定打开开发者选项并检查 "Don't keep activities alive"。 video 描述了启用该选项的应用程序 运行。如果你仔细观察，你会看到 return 到 Activity A，它很快就被完全绘制和隐藏，然后出现淡入以及共享元素过渡。
我还在动画中排除了导航栏和状态栏，这样我就不会看到那些闪烁（冗余重绘）。
我的问题是：
这是一个错误，还是我错过了一个步骤来防止这种情况发生。
为什么 app/transitions 与 "Don't keep activities alive" 和普通旧设备旋转 (destroy/recreate) 的行为不同。
我在玩一些 google 应用程序时注意到，这种行为不会发生，或者至少我能找到。有没有办法具体检查我正在 return 的 activity 是否也是 "completely destroyed" 以便我可以取消动画？或者做一些不同的事情？
如果需要，我可以包含细节和代码示例，但我的设置非常简单，并反映了 Android 文档/Stack-overflow 中的一堆样板示例。
抱歉，我本来打算早点对此做出回应。我最终做的是尽我所能按照代码示例和教程在一个全新的项目中重新创建示例。首先让它与单个图像视图一起工作，然后当然添加我的自定义布局，这是一个浮动搜索栏。一切都按预期进行。我回去查看了我的实际项目源代码（其中充斥着不同的尝试，并在尝试调试此问题时注释掉了代码）并清理了它。我不能肯定地说，但我相信这归结为两个可能的问题：
"Unless you do something unusual..." - 很可能我 "was" 在我创建这个问题时做了一些不寻常的事情，因为我的调试工作和缺乏对共享元素转换框架和生命周期的完全理解。
我认为发生的事情是共享元素转换未能对未正确映射的视图执行操作。我在 XML 中定义的转换中排除了 statusBarBackground。我的 statusBarBackground 被设置为透明的，这样我就可以为扩展的抽屉布局提供很好的叠加效果。我发现在尝试通过代码将 statusbarbackground 添加为共享元素时，视图实际上为空，导致崩溃 (NPE)。以及我为我的抽屉布局设置了背景颜色（而不是透明的）。我不能肯定地说，但这些错误的组合会导致奇怪的行为。
总而言之，我想说这个问题应该关闭，一切都按预期进行。如果能更深入地了解如何将透明状态栏作为共享元素处理，那就太好了。
这是一个错误，还是我错过了一个步骤来防止这种情况？
No. Everything is working as intended.
为什么 app/transitions 与 "Don't keep activities alive" 与普通旧设备旋转 (destroy/recreate) 的行为不同？
It doesn't. When everything is setup proper and your timing and mapping of shared elements is correct, "Don't keep activities alive" is a concrete way to test your transitions against configuration changes.
我在玩一些 google 应用程序时注意到，这种行为不会发生，或者至少我能找到。有没有办法具体检查我返回的 activity 是否也是 "completely destroyed" 以便我可以取消动画？或者做一些不同的事情？
This is because the Google dev's did it right :)
对于那些在共享元素上苦苦挣扎的人，这里有一些建议。
从小做起。首先使用单一视图并确认您在所有情况下都获得正确的行为，即使在轮换和配置更改之后，您也可以增加复杂性。
使用 SharedElementCallback 调试您的转换。您可以检查哪些视图已映射，哪些视图失败等。
使用的库：appcompat-v7:22.2.1,design:22.2.1
使用的主题：
Devices/Android 版本转载于：Nexus 6
问题：Return activity 快速 redraws/appears 然后淡入所需的行为，只有 "Don't keep activities alive".
我想知道这是错误还是预期行为。我有一个非常简单的设置。 Activity A 包含包裹在 AppbarLayout 和 CoorindinatorLayout 中的工具栏。工具栏包含一个 Cardview 和一个 TextView。单击 TextView，Activity A 启动 Activity B。我正在使用共享元素并通过 ActivityCompat.StartActivity(bundle, options);
即使在设备旋转之后，我的共享元素也能完美运行。在阅读了我如何 PostPoneEnterTransition 并将其与 PreDrawListeners 结合起来之后，即使在旋转后我也能够成功实现所需的过渡。我的实际 activity 包含一个 Viewpager / TabLayout 和 2+ 个片段，但为了简单起见，我在视频中将其剥离并查看是否有其他原因导致此问题.
在处理回车转换回 Activity A 的旋转和推迟时，我决定打开开发者选项并检查 "Don't keep activities alive"。 video 描述了启用该选项的应用程序 运行。如果你仔细观察，你会看到 return 到 Activity A，它很快就被完全绘制和隐藏，然后出现淡入以及共享元素过渡。
我还在动画中排除了导航栏和状态栏，这样我就不会看到那些闪烁（冗余重绘）。
我的问题是：
这是一个错误，还是我错过了一个步骤来防止这种情况发生。
为什么 app/transitions 与
"Don't keep activities alive"和普通旧设备旋转 (destroy/recreate) 的行为不同。我在玩一些 google 应用程序时注意到，这种行为不会发生，或者至少我能找到。有没有办法具体检查我正在 return 的 activity 是否也是 "completely destroyed" 以便我可以取消动画？或者做一些不同的事情？
如果需要，我可以包含细节和代码示例，但我的设置非常简单，并反映了 Android 文档/Stack-overflow 中的一堆样板示例。
抱歉，我本来打算早点对此做出回应。我最终做的是尽我所能按照代码示例和教程在一个全新的项目中重新创建示例。首先让它与单个图像视图一起工作，然后当然添加我的自定义布局，这是一个浮动搜索栏。一切都按预期进行。我回去查看了我的实际项目源代码（其中充斥着不同的尝试，并在尝试调试此问题时注释掉了代码）并清理了它。我不能肯定地说，但我相信这归结为两个可能的问题：
"Unless you do something unusual..." - 很可能我 "was" 在我创建这个问题时做了一些不寻常的事情，因为我的调试工作和缺乏对共享元素转换框架和生命周期的完全理解。
我认为发生的事情是共享元素转换未能对未正确映射的视图执行操作。我在 XML 中定义的转换中排除了 statusBarBackground。我的 statusBarBackground 被设置为透明的，这样我就可以为扩展的抽屉布局提供很好的叠加效果。我发现在尝试通过代码将 statusbarbackground 添加为共享元素时，视图实际上为空，导致崩溃 (NPE)。以及我为我的抽屉布局设置了背景颜色（而不是透明的）。我不能肯定地说，但这些错误的组合会导致奇怪的行为。
总而言之，我想说这个问题应该关闭，一切都按预期进行。如果能更深入地了解如何将透明状态栏作为共享元素处理，那就太好了。
这是一个错误，还是我错过了一个步骤来防止这种情况？
No. Everything is working as intended.为什么 app/transitions 与 "Don't keep activities alive" 与普通旧设备旋转 (destroy/recreate) 的行为不同？
It doesn't. When everything is setup proper and your timing and mapping of shared elements is correct, "Don't keep activities alive" is a concrete way to test your transitions against configuration changes.我在玩一些 google 应用程序时注意到，这种行为不会发生，或者至少我能找到。有没有办法具体检查我返回的 activity 是否也是 "completely destroyed" 以便我可以取消动画？或者做一些不同的事情？
This is because the Google dev's did it right :)
对于那些在共享元素上苦苦挣扎的人，这里有一些建议。
从小做起。首先使用单一视图并确认您在所有情况下都获得正确的行为，即使在轮换和配置更改之后，您也可以增加复杂性。
使用 SharedElementCallback 调试您的转换。您可以检查哪些视图已映射，哪些视图失败等。