在这种情况下如何管理 Activity 实例的恢复？
我对 Android 比较陌生，我正在尝试从 iOS 移植一个应用程序，这有点不寻常。
我的应用程序有一个用于表示 GUI 的内部 xml 语言（类似于 iOS 中我们自己的 nib/xib 或 android 中的 res/layout/whatever.xml，相信我，我们别无选择），以及一个膨胀此 xml 的膨胀机制并构建视图控制器和视图实例。
因此，在 iOS 中，我的应用程序有多个同一类的实时 UIViewController 实例（根据需要从导航堆栈中添加和删除），这些实例全部膨胀一次（来自不同的 XML），并且只要应用程序存在，它们就保持活动状态。
现在，我有点不确定在 Android 中执行此操作的正确方法。理想情况下，我希望能够创建 Activity 类的实例，每个实例的视图都是从我们的 xml 语言中扩充的，并在它们之间进行导航。然而，据我了解，这在 Android 中是不可能的（因为活动是由意图启动并由类创建的）。
- 我是否真的无法让活动保持活动状态，同时不在堆栈上（即“后退”总是杀死活动）？
- 如果是这样，这是否意味着每次我“向前”导航（严重的性能问题）时，我都需要从 xml 中夸大活动及其所有视图，还是有其他选择？
- 至少将解析后的xml结构保存在Application子类中是否合理，这样膨胀会更快？
- 仅发送（在创建时）和保存（为了持久性）活动标识符到新活动实例，并将其转到我的应用程序子类，并通过标识符自行膨胀/获取其状态是否有意义？
一般来说，假设必须从 XML 扩充 GUI，并且我想最大程度地减少重新扩充 GUI 的需要，您建议什么作为最干净的解决方案？
任何其他提示将不胜感激......谢谢！
I'm relatively new to Android, and I'm trying to port an app from iOS, which does something slightly unconventional.
My app has an in-house xml language for representing GUI (kind of our own nib/xib in iOS or res/layout/whatever.xml in android, believe me, we had no choice), and an inflation mechanism that inflates this xml and builds a view controller and view instances.
As a result, in iOS, my app had several live UIViewController instances of the same class (added and removed from the navigation stack as necessary) which were all inflated once (from different XMLs) and remained alive as long as the app was.
Now, I'm a bit unsure about the correct way to do this in Android. Ideally, I would like to be able to create instances of an Activity class, each with its views inflated from our xml language, and do the navigation between then. However, to my understanding this is not possible in Android (since activities are started by intents, and created by class).
- Is it true that I would not be able to keep activities alive and at the same time - not on stack (i.e. "back" always kills activities)?
- If so, does this mean I need to inflate the activities and all their views from xml, every time I navigate "forward" (serious performance issue), or is there an alternative?
- Is it reasonable to at least save the parsed xml structure in an Application subclass, so the inflation will be faster?
- Would it make sense to only send (on creation) and save (for persistency) an activity identifier to the new activity instance, and have it go to my Application subclass, and inflate itself / get its state by identifier?
In general, assuming having the GUI inflated from XML is a must, and I would like to minimize the need to re-inflate the GUI, what would you suggest as the cleanest solution?
Any other tips will be greatly appreciated… Thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我不能 100% 确定我理解您的情况 - 我认为您所说的是您已经拥有定义布局和控制器的自定义 XML。我会根据这个来回答，如有错误请指正。
首先，你的问题表明了你对沿着当前道路前进时所面临的问题的理解。我不会单独回答它们，因为我认为有更好的解决方案 - 通过 使用 Fragments兼容包。
片段的工作方式是，您有一个活动，然后是其中定义 UI 的一系列片段。对于手机来说，这最终看起来与基于活动的应用程序相同。但就您而言，它将提供一些好处：
可以在代码中动态创建片段。
片段可以从堆栈中弹出，但保留在内存中，以便您以后可以重新添加它们。
您可以将所有预解析的 XML 存储在保留的、不可见的 Fragment 实例中（而不是全局 Application 子类）。
这并不是说片段没有问题 - 那里也可能存在限制（我最近才开始使用它们）。但我会让他们看看是否可以解决您的问题。
另一种选择是在内部 XML 和 Android 的 XML 之间编写转换（预处理）。 Android 的 XML 视图创建速度相当快，因为它已针对它进行了优化。
I am not 100% sure I understand your situation - I think what you are saying is that you've got custom XML that defines your layouts and controllers. I am going to answer based on that, correct me if I'm wrong.
First, your questions show an understanding of the problems you face if you go down your current path. I'm not going to answer them individually because I think there's a better solution - use Fragments via the compatibility package.
The way Fragments work is that you have a single Activity, then a series of Fragments inside of it that define the UI. For phones, this ends up looking the same as an Activity-based application. But in your case, it will provide a few bonuses:
Fragments can be created dynamically in code.
Fragments can be popped off the stack, but kept in memory so you can re-add them later.
You can store all of your pre-parsed XML in a retained, invisible Fragment instance (instead of the global Application subclass).
This isn't to say there are no problems with Fragments - there may be limitations there as well (I've only recently started working with them). But I would give them a look to see if they might solve your problem.
Another alternative would be to write a transformation (pre-processed) between your in-house XML and Android's XML. Android's XML View creation is pretty fast because it's optimized for it.