Java 作为静态内部类和独立公共类，片段背后的设计逻辑是什么？

我无法理解Android软件设计的一个重要方面，我刚刚开始，据我所知，

Fragment

设计是为了解耦代码，直觉是

活动保持原样，
Fragment
可以在其他地方重用，甚至可能在不同的活动中，或者可能在其他片段中，在主/细节流或景观UI中

好的，我已经看到了很多关于so的问题，问到为什么
片段
被作为一个
活动
中的静态内部类放置，答案是如果我们不使它们成为静态的，
片段
可能包含对活动的引用，屏幕旋转或重新绘制之类的内容可能会泄漏活动或其他内容

这让我回到了第一步，我的问题是，如果片段设计是为了解耦代码而采用的，那么为什么我们要将
片段
与
活动
结合起来，将其放在活动类中，而不是将其作为独立的公共类？这难道不完全与碎片的存在相矛盾吗

拥有这样一个项目结构的不利方面是什么？每个
片段
是一个独立的类吗？考虑到我的片段代码可以增长到1000行，特别是在尝试制作动画时，我认为这在活动中比预期的父活动更加整洁、解耦和可重用


我们是否仍然受到上述内存泄漏问题的困扰
我是否遗漏了一些设计逻辑？请教育我
有没有办法让片段作为一个内部类保留下来，并在其他地方使用？我可能也错过了一些东西。。。所以一定要告诉我


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

谢谢：）
我想更好地了解与你的想法相反的逻辑；我一直在自己的类中制作片段，我的应用程序在重新定向时运行得像块石头。我确实使用了一个接口来与管理活动对话，使用适配器来管理片段，并执行基本的记帐，以确保我不会因为重新加载而启动几个后台线程

所以我查一下
这总是值得重读的，你知道吗，下面的例子正是你所建议的，我每天都在使用：独立类中的两个公共片段，它们被附加到一个活动或由一个活动附加

如果有人真的在建议你说的话，我怀疑他们是在说“一个片段必须始终嵌入到一个活动中，并且片段的生命周期直接受到宿主活动生命周期的影响”；它们意味着嵌入到运行时中

gl hf

这让我回到了第一步，我的问题是，如果片段设计是为了解耦代码而采用的，那么为什么我们要将片段与活动结合起来，将其放在活动类中，而不是将其作为独立的公共类？这难道不完全与碎片的存在相矛盾吗

片段的主要驱动因素不是解耦，而是组合：用户界面的可重用部分，可以在不同的配置中轻松组合在一起。可组合性遵循模块化，从模块化中解耦是的，解耦是存在的，但它不是主要关注点

继续读下去

模块化硬币还有另一面：如果两个东西属于一起，比如一个活动和一个只与该活动一起使用的片段，那么它们最好保持在一起，而不是分散在整个代码库中，这样它们就更容易一起进化。像您问题中的项目结构，其中活动和片段位于单独的包中，不会真正遵循此原则

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

对于没有那么多代码且片段只在一个活动中使用的简单片段，在该活动中将它们作为静态内部类使用是非常好的

只要试着保持一致，这样其他阅读代码的人就可以很容易地在代码库中找到自己的方法，WTFs/分钟代码度量保持较低

我们是否仍然受到上述内存泄漏问题的困扰

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

由于片段共享宿主活动的生命周期，因此泄漏外部对象并不是片段真正的问题。只是框架需要能够在没有任何外部类对象的情况下实例化片段，而
static
是这方面的要求

有没有办法让片段作为一个内部类保留下来，并在其他地方使用？我可能也错过了一些东西。。。所以一定要告诉我

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

虽然这在技术上是可能的，但这样做表示您依赖于类的内部结构，这就是设计的味道。我真的想在外部类代码中引用内部类。
请您添加一个链接，指向支持将片段作为活动的静态内部类的答案之一。这听起来像是一件荒谬的事。我总是从活动中分离片段，并让它们独立