iphone - 适用于大型应用程序的模块化架构，具有最佳实践以及 Storyboard 和 XIB 的使用

Question

我们是一个团队，为 iPad 创建一个非常大的应用程序，作为弱势 child 的电子阅读器。该应用程序已经构建了一半，我认为我们应该退后一步并审查应用程序的整个设计。我们正在构建的应用程序应该非常非常符合 iOS 当前的软件开发架构实践。我有以下解释和问题:

应用程序现在大约有 50 个 View (并且还在不断增加)，大多数顶级 View 都在 Storyboard(即单个 Storyboard)中，其他 View 则在 XIB 中(对于 subview ，可重用)项目渲染器等)。

这个方法可以吗？

现代 iOS 应用程序是否应该完全省略 XIB？

Storyboard应该保持原样还是应该分解为子 Storyboard？如果应该的话，分解 Storyboard的具体过程应该如何完成？模块如何确定？

如果您有一些以正确方式管理应用程序的技巧或一些有助于简化和模块化应用程序的经验法则，请在评论中提及。

很抱歉上面的文字太长，感谢您的阅读。

Answer 1

这有点主观，但在我看来，将 Xibs 与 Storyboard一起使用仍然有效且可取。 Storyboard的想法很好，但在当前的实现中，它们肯定缺乏一些功能，其中最明显的是 View 重用。我最近参与了几个大型项目， Storyboard总是一开始就很好，但迟早你会发现自己复制并粘贴表格单元格，然后是 Controller ，然后你必须在每次更新时在多个地方更改内容，这就是完全无法维护。所以，是的，一定要坚持使用 Xib 文件以获得可重用的 View 。

然而，我不太热衷于多个 Storyboard的想法。虽然这在技术上很容易实现，但对我来说，它完全使 Storyboard的目的失效。它们的唯一用途是作为应用程序中 Controller 流程的(相对)清晰概述。它们添加了一些小便利，但总的来说，我发现它们经常创建比保存的代码更多的代码，并创建一些奇怪的代码模式(例如 prepareForSegue:，当您想要继续执行时必须临时存储 ivars代码中需要属性设置的 Controller )。正如您所说，如何将 Storyboard分成子 Storyboard？我只能认为，您选择的任何分区方案都有些随意，并且在以后应用程序结构发生变化时可能会发生变化，这根本没有乐趣。也许如果您的应用程序具有不同的操作模式，那么拆分 Storyboard是有意义的，但我认为这不适用于大多数应用程序。

所以，IMO，单一 Storyboard，但使用 Xibs 来实现可重用的 View 。