0

我是一个业余爱好者，过去几周一直在做一个琐事游戏。从用户的角度来看，游戏的第一个版本运行良好，但代码非常混乱，我正在从头开始编写游戏的第二个版本。我还对游戏在页面之间移动的方式进行了重大更改，从视图翻转转换为使用片段。根据我目前的研究，我认为新设计更符合最佳实践，但我不确定我是否完全理解支持和反对使用片段的论点如何适用于这款游戏。

设计#1。旧的设计依赖于三个活动文件：MainActivity 用作启动页面，允许用户选择适当的难度级别，GameActivity 在 ViewFlipper 的帮助下提供琐事问题和答案，ScoreActivity 报告用户的分数，同时也使确保highestScoreAchieved 记录在PREFERENCES 中。

设计#2。新设计将依赖于一个带有单个片段容器和四个片段的活动文件。StartFragment 是启动页面，QuestionFragment 是问题页面，AnswerFragment 是答案页面，ScoreFragment 报告最终游戏得分。

我认为基于片段的设计#2 更符合最佳实践。BIG NERD RANCH 关于 Android 编程的书宣扬 AUF（“始终使用片段”），理由是事后返回并添加片段总是更困难，但也必须有其他支持片段的论据。

我在 StackOverflow 上对此进行了研究，大多数示例涉及不同的情况（例如拆分视图和可重用视图）。

因此，我的问题是：在上述游戏的背景下，支持片段而不是视图翻转的论点是什么？对于这个愚蠢的小琐事游戏，基于片段的设计是否有很好的论据？

亚伦

4

1 回答 1

1

简而言之，Fragments 就像 mini 一样Activity，允许您将应用程序逻辑分解为执行特定操作的更小的有组织的单元。这允许您将您的应用程序功能分解为更集中、可重用的组件，这些组件可以更好地适应不同的设备。

这是一个更好的选择，而不是让大Activitys 做很多事情，变得臃肿且难以维护，并且难以在不同的屏幕尺寸和方向上工作（想想横向/平板电脑）。

Fragment推荐使用 s，因为它们预先提供了灵活性和代码组织，因此随着应用程序的发展并添加对更多设备配置和功能的支持，它将更容易维护和更灵活。我写了一篇关于使用s 支持任何方向的任何设备的深入博客Fragment，其中涵盖了Fragment与开源示例项目一起添加 s 的原因。

在上述游戏的背景下，支持片段而不是视图翻转的论点是什么？

视图翻转需要 s 使用所有逻辑和内存Activity，即使一次只有其中一部分处于活动状态，而Fragments 可以在适当的时间加载。

对于这个愚蠢的小琐事游戏，基于片段的设计是否有很好的论据？

您可能会争辩说Fragments 确实为非常简单的事情增加了一些架构开销。但是，随着您的功能和代码的增加，Fragments 和良好的设计将为您省去很多麻烦，并且性能更好。如果您打算向公众发布此游戏，我建议您使用Fragments（必要时）。

于 2013-07-23T20:48:44.423 回答