如果两种活动都是您的，请使用体面的数据模型。Android不鼓励设计精良的应用程序。或换种说法，它允许快速开发应用程序，而不会促进很多好的软件应用程序原理。
@ Jean-Philippe Roy（québec？）的解决方案很有趣，但单身人士在涉及更复杂的事物（即全状态模型或serviceS）时，是一种反模式。
最好的选择是使用应用程序类。这个类是您的单例，自然是在android中。所以，
- 在清单中定义应用程序类
- 提供静态方法来访问应用程序类的唯一实例（始终为单例）。
- 给它一种方法来接收和保存您的数据，从您的第一个活动中调用它
- 第二个让他们重新参加第二个活动
-–在@straya的回答和18个月以上的Android编程后更新：)
在构建Android应用程序时，始终会想到在应用程序，活动，视图，片段之间共享数据结构或流程的问题。重要的是要知道并考虑到应用程序范围是保存共享结构的正确位置，但是就以下方面而言，使用应用程序类本身在该范围中放置数据结构是不可行的：
- 代码质量，如果应用程序了解所有共享数据结构和过程，它将很快因所有这些实体的访问器而变得肿。
- 全球只有一个整体的实体共享池，它的粒度不够，可能导致难以检测耦合实体的方式
我现在倾向于使用依赖注入管理的单例。Dagger或RoboGuice都允许创建给定类的单个实例并将其注入其他类。这项技术以及DI通常为良好的Android设计提供了巨大的可能性：
- 不会降低代码质量，甚至可以缩短很多时间。使用@Inject注入依赖项，它们将被注入。
- 不要给单例类提供2个责任：它将不处理单例实例的创建，框架会做到这一点。
- 从单例传递到普通实例更容易
- 当这些单例成为带有简单注释的普通类时，它们不再包含静态方法，因此可以非常轻松地模拟它们。这很重要。
- 当然，当一个类依赖于另一个类时，DI注释也可以很清楚地帮助自己编写代码。
