Android ViewModel与单例类的差异（不使用LiveData场景）

Hey Sagar, great questions—let’s break this down clearly so you can see exactly where ViewModel and singletons diverge, even when you’re not using LiveData.

Let’s start with the full picture of how these two approaches differ:

• Lifecycle Awareness & Automatic Cleanup
  Singletons are application-scoped—they exist as long as your app’s process is running, regardless of the lifecycle of individual UI components (Activities/Fragments). ViewModels, by contrast, are tied to the lifecycle of their host component. When an Activity is destroyed due to a configuration change (like screen rotation), the ViewModel is retained. But when the Activity is permanently destroyed (e.g., the user presses back to exit), the system automatically calls onCleared() on the ViewModel, letting you clean up resources (like canceling network calls, releasing database connections) and freeing memory. Singletons offer no built-in mechanism for this—you have to manually manage cleanup, which is error-prone and often leads to memory leaks if you forget.

• Scope Isolation
  ViewModels are component-scoped. If you launch two instances of the same Activity (e.g., opening the same screen twice in multi-window mode), each gets its own ViewModel instance, keeping their data isolated. Singletons are global—every component in your app shares the same single instance. This can lead to unintended state sharing: if one screen modifies data in the singleton, all other screens using it will see that change immediately, which might not be what you want.

• Instance Management & Ownership
  ViewModels are created and managed by the ViewModelProvider class, which handles the logic of retaining instances across configuration changes and providing the correct instance to each component. You don’t have to worry about creating or storing instances manually. Singletons rely on manual implementation (e.g., static fields, private constructors), which gives you control but also puts all the responsibility on you to avoid issues like double-instantiation or accidental reference leaks.

• Testability
  ViewModels are designed to be testable. They don’t hold direct references to UI components (like Activities or Views), and dependencies can be easily injected via constructors. This lets you write unit tests without needing to mock the entire Android framework. Singletons, being global, are much harder to test—their state persists across tests, and replacing dependencies (like a real API client with a mock) requires messy workarounds.

You’re right that singletons survive configuration changes too—but the critical, unmissable difference is lifecycle-bound cleanup and scope.

Even without LiveData:

• When your Activity is permanently destroyed, the ViewModel is cleaned up automatically. Any resources it holds are released, preventing memory leaks and unnecessary memory usage.
• A singleton will remain in memory indefinitely (until the app process is killed). If it holds onto large objects (like bitmaps, cached data, or active network connections), it’s wasting resources that could be used by other parts of the app.
• ViewModels keep data isolated to the component that needs it, while singletons force global sharing. For example, if you have a ViewModel for a checkout flow, each checkout session gets its own instance. A singleton checkout manager would mix data between simultaneous checkout attempts, leading to bugs.

In short: ViewModels give you the persistence across configuration changes you need, without the downsides of global state and unmanaged memory that come with singletons.

内容的提问来源于stack exchange，提问作者Sagar Ekbote