我知道Activities被设计为代表我的应用程序的单个屏幕,而Fragments被设计为可重用的UI布局,其中嵌入了逻辑。

直到不久前,我开发了一个应用程序,因为它说应该开发它们。我创建了一个“活动”来表示我的应用程序的屏幕,并将碎片用于ViewPager或谷歌地图。我很少创建可以多次重用的ListFragment或其他UI。

最近,我偶然发现一个项目只包含两个活动,一个是SettingsActivity,另一个是MainActivity。MainActivity的布局中填充了许多隐藏的全屏UI片段,仅显示一个。在“活动”逻辑中,应用程序的不同屏幕之间有许多FragmentTransition。

我喜欢这种方法的地方是,因为应用程序使用了ActionBar,所以它保持不变,不会随着屏幕切换动画而移动,这就是“活动切换”所发生的情况。这使屏幕转换更加流畅。

所以我想我要问的是分享你当前关于这个主题的开发方式,我知道这看起来可能是一个基于观点的问题,但我将其视为一个Android设计和架构问题。。。并不是一个真正基于观点的人。

更新(2014年5月1日):以下是来自Square的Eric Burke的演示(我不得不说,这是一个很棒的演示,为android开发人员提供了很多有用的工具。我与Square没有任何关系)

http://www.infoq.com/presentations/Android-Design/

根据过去几个月的个人经验,我发现构建应用程序的最佳方法是创建一组片段,这些片段代表应用程序中的一个流,并在一个活动中呈现所有这些片段。因此,基本上,应用程序中的活动数与流数相同。这样,动作栏在所有流的屏幕上保持不变,但在更改流时会重新创建,这非常有意义。正如埃里克·伯克(Eric Burke)所说,正如我所认识到的那样,使用尽可能少的活动的哲学并不适用于所有情况,因为它在他所谓的“上帝”活动中造成了混乱。


当前回答

这比你意识到的要多,你必须记住,启动的活动不会隐式地破坏调用活动。当然,您可以将其设置为用户单击某个按钮转到某个页面,然后启动该页面的活动并销毁当前页面。这会导致大量开销。我能给你最好的指导是:

**只有当主活动和此活动同时打开(考虑多个窗口)才有意义时,才能开始新活动。

Google Drive就是一个很好的例子,它说明了多个活动是有意义的。主要活动提供文件资源管理器。打开文件后,将启动一个新活动来查看该文件。您可以按下最近的应用程序按钮,这将允许您在不关闭打开的文档的情况下返回浏览器,然后甚至可以打开与第一个文档并行的另一个文档。

其他回答

为什么我在所有情况下都喜欢片段而不是活动。

活动费用高昂。在Fragment中,视图和属性状态是分开的——每当片段处于后台时,其视图都将被销毁。因此,您可以堆叠比“活动”多得多的碎片。回钉操作。使用FragmentManager,可以很容易地清除所有碎片,插入更多的碎片等。但对于Activity来说,操纵这些东西将是一场噩梦。可预测的生命周期。只要不回收主机“活动”。背景中的碎片不会被回收。因此,可以使用FragmentManager::getFragments()查找特定的Fragment(不鼓励)。

好吧,根据谷歌的讲座(也许在这里,我不记得了),你应该考虑尽可能使用碎片,因为它使你的代码更容易维护和控制。

然而,我认为在某些情况下,它可能变得过于复杂,因为承载片段的活动需要在它们之间导航/通信。

我认为你应该自己决定什么最适合你。将活动转换为片段通常并不难,反之亦然。

如果你想进一步阅读,我已经在这里创建了一篇关于这个dillema的帖子。

我使用碎片来获得更好的用户体验。例如,如果您有一个按钮,并且希望在单击它时运行Web服务,我会将一个片段附加到父Activity。

if (id == R.id.forecast) {

    ForecastFragment forecastFragment = new ForecastFragment();
    FragmentManager fm = getSupportFragmentManager();
    FragmentTransaction ft = fm.beginTransaction();
    ft.replace(R.id.main_content, forecastFragment);
    ft.addToBackStack("backstack");
    forecastFragment.setArguments(b);
    ft.commit();
}

这样,用户就不必在其他活动中移动。

其次,我更喜欢碎片,因为你可以在旋转过程中轻松处理它们。

一些错误的想法:

始终在应用程序中放置一个活动,并使用片段处理不同的屏幕。直接在活动中编写UI代码。通过片段处理屏幕之间的导航(我不是指选项卡,我是指例如全屏视图)。活动可以被碎片替换。

事情是这样的!

片段旨在实现UI的可重用部分,并在应用程序的任何需要的部分中使用它们。它们不是为替代活动而设计的。

我们什么时候必须使用它们?

当我们有一个独立的屏幕,其中有一些不同的UI部分(选项卡、可扩展屏幕、部分屏幕等)时,我们应该使用带有一些片段的活动在同一屏幕中分别实现和处理不同的UI部件。应用程序的每个独立部分实际上是一个概念上不同于其他部分的组件,它需要有一个独立的活动。例如,登录部分可能包含一些不同的场景,如使用用户名密码或使用指纹。每个场景都可以由一个片段实现,所有与登录相关的片段都应该由LoginActivity处理。但例如,应用程序中的订单部分与登录没有概念关系,因此它必须具有不同的活动,当然,它可能包含一些片段,如OrdersFragment、SubmitNewOrderFragment等,所有这些片段都必须由OrdersActivity管理。不要在活动中直接实现UI。始终在片段中实现UI,并在活动中添加这些片段,即使该活动中只有一个片段。它可以帮助您拥有更多可重用的代码,并更容易地更改UI。不要使用片段在应用程序中无限导航,即使您强制用户在后堆栈中有有限数量的片段。事实上,当您将一个新片段添加到后堆栈中并将其移除时,除非父活动被破坏并且它只是不可见,否则它不会从内存中移除。因此,当您使用片段管理器后堆栈时,通过在同一活动中的片段之间多次导航(尤其是在每次导航中创建一个新片段并将其放入后堆栈的情况下),您将在应用程序中获得OutOfMemoryException。

我希望这会有所帮助。

这个问题需要重新评估,因为Jetpack Compose已经达到稳定。

Jetpack Compose是Android推荐的用于构建本机UI。从…起https://developer.android.com/jetpack/compose

典型的喷气背包组合结构是:单个活动,多个可组合,通过喷气背包导航粘合在一起。注意,不再需要碎片了。

有关示例,请参见Android中的Now。