Android 我在安卓系统中的模型需要是一个单体模型吗？

在我看来，如果你在android中有一些状态或数据，你想从不同的活动中访问（但不想持久），你需要一个单例。这是正确的还是有其他方法来设计应用程序

---

这并不是说我有单身问题。我只是想知道，这与普通的桌面应用程序开发有很大的不同。

你所说的绝对不正确，还有其他方法可以设计Android应用程序

实际上，对于Android开发，应该避免使用单例，或者节约使用单例，而不是将单例作为第一个或唯一的解决方案。尤其不应使用它在活动之间随意共享数据或状态

如果你发现你的应用程序在所有方面都需要使用单例，那么很可能。。。你需要重新设计你的应用程序

在使用单例时，实际上有几件事需要记住：

• 它们通常存在于应用程序的整个生命周期中，直到被关闭应用程序的系统关闭

• 创建不正确的单例很容易泄漏内存

• 设计不当的单例和过度使用单例会占用大量不必要的内存

• 它们很难用于测试

总的来说，当使用单例时，你真的需要考虑是否有足够的必要让你的应用程序的这一部分成为单例

对于大多数情况，答案是否定的。在您提到的情况下，例如在活动之间访问状态或数据，答案是肯定和否定

这是肯定的，因为访问数据的需要可能保证使用单例。这是否定的，因为不应该需要访问应用程序的状态

您对“状态”一词的使用很不清楚，但活动实际上应该是自我管理的，因为一个活动的状态不应该干扰另一个活动的状态。如果是这样的话，就有更好的方法将信息发送到活动中（比如使用意图附加项），而不是创建一个任何东西都可以访问并且存在时间比它应该存在的时间更长的单例

事实上，很少有理由证明单身汉的必要性

根据我的经验，只有两个原因允许使用单例：

• 存在单个实例的真正需要
• Singleton经常被使用，不断地创建它是很昂贵的，但是将它保存在内存中不会有任何重大的副作用

例如，SQLite数据库通常用作单例，因为数据库的单个同步实例有助于防止多个活动或服务读取/写入数据库。这有助于防止出现这样的情况：一个对象写入新数据，而另一个对象在写入新数据之前读取旧数据。或者两个对象同时向同一字段写入不同数据的简单情况

此外，SQLite数据库也经常被应用程序访问，因此经常打开数据库、获取一些数据、关闭数据库、打开数据库、写入一些数据、关闭数据库并重复这些操作没有多大意义

我见过开发人员在很多情况下使用单例，其中大多数都是出于非常糟糕的原因

好人：

• 数据库
• SharedReferences（应用程序需要以比正常更频繁的方式访问首选项）
• 测井系统

坏消息：

• 我看到一个开发人员在启动他的应用程序时加载了大量的Drawable，并将其存储在一个单例中。。。只是为了让他能在任何地方都能很快地使用这些拖带
• 我看到一些开发人员使用单例来保存已创建活动的列表，这样他们就可以访问那些活动方法和视图。。。（死了）

我见过更多的坏故事，但我现在想不起来了

另外，请记住，尽管我说过像数据库这样的东西作为单例使用是一个好主意，但我只是说它需要保证使用单例。数据库不需要是单例数据库，还有其他解决方案可能更适合您的应用程序

因此，请始终考虑是否需要使用单例

在您的情况下，您需要由其他活动访问的状态/数据是否真的需要在应用程序期间保持活动状态，是否可以通过诸如SharedReferences、Intent extras、回调接口、数据库、静态类/字段/方法等解决方案来解决

---

如果你很好地考虑了你的应用程序，并且真的认为单身会让你的应用程序受益匪浅，那么就使用它吧。不要忘记使用应用程序上下文而不是活动的上下文，因为单例肯定会比您的活动寿命长，并且您不希望出现内存泄漏问题

我的状态/数据类似于：我从其他用户处收到的更新列表。看看你的建议，你会说共享引用、数据库，但你也会说这些都是有效的单例用例。这些东西来自后台运行的服务。该服务本身基本上也是一个单例服务，因为bindService是一个异步版本的getInstance。。。我理解你对单身的厌恶，这就是我问这个问题的原因。这里有三件事需要解决。首先，是您的用例。如果你的更新列表（来自其他用户的数据）在你的应用程序中经常使用，并且不断地创建和关闭该连接是没有意义的，那么考虑一个单体是有意义的。从某种意义上说，这就是为什么那些使用从本地数据库、远程数据库等获取数据的存储库模式的人通常会将存储库变成一个单实例