Fragments作为静态内部类与独立公共类背后的设计逻辑是什么？

Question

我无法理解我刚开始使用的Android软件设计的一个重要方面，据我所知Fragment设计已被采用以解耦代码，其中直觉是Activity保持原样，Fragment可以重复使用其他地方，甚至可能在不同的活动中，或者可能与其他片段一起，在主/细节流或风景UI。

好的所以我已经看到了很多关于SO的问题，询问为什么Fragments被放置为Activity中的静态内部类，而答案是如果我们不将它们设为静态，Fragment可能包含对活动的引用，屏幕旋转或重新绘制等内容可能会泄露活动或其他内容。

这让我回到原点，我有一个问题，那就是，如果采用Fragment设计来解耦代码，那么我们为什么要将Fragment与{{1}结合将放在活动类中，而不是将它们作为独立的公共类放置？这与片段的存在完全不矛盾吗？

拥有项目结构的缺点是什么？每个Activity是一个独立的类？鉴于我的片段代码可以增长到1000行，特别是在尝试做动画时，我发现这更加整洁，分离并且可以在除了预期的父活动之外的活动中重复使用。

• 我们是否仍然遇到上述内存泄漏问题？
• 我是否遗漏了有关设计逻辑的内容？请教育我。
• 有没有一种方法可以将片段保留为内部类并仍在其他地方使用？我也可能在这里遗漏一些东西......所以请告诉我。

任何其他项目设计方法，概念，对我的直觉的更正都非常受欢迎，因为我刚开始在这里，我很想知道我的所有选择。

谢谢：）

Answer 1

  

这让我回到原点，我有一个问题，那就是，如果为了解耦代码而采用了Fragment设计，那么为什么我们将Fragment与Activity放在一起，将它放在Activity类中而不是把它们作为独立的公共课程？这与片段的存在完全不矛盾吗？

片段的主要驱动因素不是解耦而是组合：可重用的用户界面片段，可以在不同的配置中轻松组合在一起。从可组合性来看，模块化和它之间的脱钩是这样的，脱钩是存在的，但它不是主要关注点。

继续阅读fragment design philosophy。

模块化硬币有另一面：如果两个东西属于一起，例如活动和仅与该活动一起使用的片段，它们最好保持在一起，而不是遍布整个代码库，因此它们更容易一起发展。像你的问题中的项目结构，活动和片段在不同的包中并不真正遵循这个原则。

将片段保存在单独的类中但接近相关活动的一种常见方法是使用命名前缀，以便它们在同一个包中的字母列表中排序：例如与FooDetailsFragment的FooActivity。

对于没有那么多代码且片段仅用于一个活动的简单片段，将它们作为该活动中的静态内部类完全没问题。

尝试保持一致，以便其他阅读代码的人可以轻松地在代码库中找到解决方法，并且WTF /分钟代码指标保持较低。

  

我们是否仍然遇到上述内存泄漏问题？

不，泄漏仅适用于持有外部类引用的非静态内部类。包级别的类没有任何外部类来保存对它的引用。

由于片段共享托管活动的生命周期，因此泄露外​​部对象并不是片段的关注点。只是框架需要能够在没有任何外部类对象的情况下实例化片段，static是必需的。

  

有没有一种方法可以将片段保留为内部类并仍在其他地方使用？我可能也会在这里遗漏一些东西......所以请告诉我。

您可以在代码中使用点符号Outer.Inner或使用反射Outer$Inner引用公共内部类（例如XML文件）。

虽然这在技术上是可行的，但这样做表示你依赖于一个类的内部，这是一种设计气味。我实际上是在外部类代码中引用内部类。

Answer 2

我想更好地了解反对你的想法的逻辑;我一直在他们自己的班级制作片段，我的应用程序在重新定位时像摇滚一样运行。我确实使用一个接口来管理Activity，使用适配器来管理片段，并执行基本的记帐以确保我不会从重新加载中启动多个后台线程。

所以我查看http://developer.android.com/guide/components/fragments.html 这总是值得重新阅读，并且whaddya知道，底部的例子正是你的建议，我每天都使用：独立类中的两个公共片段附加到活动上。

如果有人真的建议你说什么，我怀疑他们正在采取行动“片段必须始终嵌入到一个活动中，片段的生命周期直接受到主机活动生命周期的影响。”方式，方式太字面;它们意味着嵌入在运行时中。

gl hf！