困境:何时使用碎片与活动:

专家会告诉你:"当我看到用户界面时,我会知道是否要使用Activity或者Fragment".在一开始这没有任何意义,但是到时候,你实际上能够分辨出你是否需要Fragment.

有一种很好的做法,我发现对我很有帮助.当我试图向女儿解释一些事情时,我突然想到了.

即,想象一个代表屏幕的框.你可以在这个盒子里加载另一个屏幕吗？如果您使用新的盒子,是否需要从第一个盒子中复制多个项目？如果答案是肯定的,那么您应该使用Fragments,因为根Activity可以容纳所有重复的元素以节省您创建它们的时间,并且您可以简单地替换框的部分.

但不要忘记,你总是需要一个盒子容器(Activity)或你的零件将被分散.所以一个盒子内有零件.

小心不要误用盒子.Android UX专家建议(你可以在YouTube上找到它们)我们应该明确加载另一个Activity,而不是使用a Fragment(就像我们处理具有类别的导航抽屉时).一旦您感到满意Fragments,您就可以观看他们的所有视频.更多它们是强制性材料.

你现在可以看看你的UI并弄清楚你是否需要一个Activity或一个Fragment？你有新观点吗？我想你做到了.

从Jetpack开始，单一活动应用程序是首选的体系结构。尤其对导航体系结构组件有用。

资源

我的理念是这样的:

只有在绝对绝对需要时才创建活动.由于后端堆栈可用于提交一堆片段事务,我尝试在我的应用程序中创建尽可能少的活动.此外,各种片段之间的通信比在活动之间来回发送数据容易得多.

活动过渡很昂贵,对吧？至少我是这么认为的 - 因为旧活动必须被销毁/暂停/停止,被推入堆栈,然后必须创建/启动/恢复新活动.

这是我的哲学,因为片段被引入.

为什么我喜欢碎片而不是所有情况下的活动.

活动很昂贵.在Fragment中,视图和属性状态是分开的 - 每当片段进入时backstack,其视图将被销毁.因此,您可以堆叠比活动更多的碎片.

Backstack操纵.有了FragmentManager,很容易清除所有碎片,插入比碎片等更多.但对于Activity来说,操纵这些东西将是一场噩梦.

一个可预测的生命周期.只要主机Activity不被回收.背板中的碎片不会被回收.因此可以用来FragmentManager::getFragments()查找特定的片段(不鼓励).

在我看来,这并不是真的相关.要考虑的关键因素是

您多久会重复使用部分UI(例如菜单),

是平板电脑的应用程序？

片段的主要用途是构建多窗格活动,这使其成为平板电脑/手机响应式应用的理想选择.

我做了:尽可能使用更少的片段.不幸的是,几乎可以.所以,我最终得到了很多片段和一些活动.我意识到的一些缺点:

ActionBar&菜单:当2个片段有不同的标题,菜单时,
很难处理.例如:添加新片段时,您可以更改操作栏标题,但从弹出它时backstack无法恢复旧标题.在这种情况下,您可能需要在每个片段中使用工具栏,但请相信我,这将花费您更多时间.

当我们需要时startForResult,活动有,但片段没有.

默认情况下没有过渡动画

我的解决方案是使用Activity 将片段包装在里面.所以我们有单独的动作栏,菜单startActivityForResult,动画......

除此之外,还有更多内容,你必须记住,发起的活动不会隐含地破坏调用活动.当然,您可以进行设置,以便用户单击按钮转到页面,启动该页面的活动并销毁当前页面.这会导致很多开销.我能给你的最佳指南是:

**只有在主要活动和同一个活动同时打开时才开始新的活动(想想多个窗口).

Google云端硬盘是一个很好的例子,说明何时进行多项活动是有意义的.主要活动提供了一个文件浏览器.打开文件时,将启动一个新活动以查看该文件.您可以按最近的应用程序按钮,这将允许您返回浏览器而不关闭打开的文档,然后甚至可能打开与第一个文档并行的另一个文档.

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

但是,我认为在某些情况下它会变得太复杂,因为托管片段的活动需要在它们之间导航/通信.

我想你应该自己决定什么对你最好.将活动转换为片段通常并不难,反之亦然.

我创建了一个关于这个dillema后在这里,如果你想进一步阅读一些.

不要忘记一个活动是应用程序的块/组件,可以通过Intent共享和启动!因此,应用程序中的每个活动都应该只解决一种任务.如果您的应用程序中只有一个任务,那么我认为您只需要一个活动和许多片段.当然,您可以在将来的活动中重用碎片来解决其他任务.这种方法将明确和逻辑分离任务.并且您不需要为不同的片段集维护具有不同意图过滤器参数的一个活动.您可以根据需求在开发过程的设计阶段定义任务.