使用XIB并以编程方式进行视图的利与弊

        您应该能够做到这两者-有时以编程方式构建视图会更好/更轻松，而使用.xib有时会更好/更轻松。即使您只以一种方式进行操作，您也会遇到用另一种方式进行操作的代码，并且您将需要能够处理这种情况。 如果您不知道如何使用IB，那么用代码构建视图肯定会更容易。这就是为什么您应该学习使用IB的原因。一旦了解了IB，便可以更快，更快速地组合应用程序可能需要的大多数基于视图的UI。 IB可以帮助您排列事物，使对象居中，对齐基线，将控件连接到其目标和动作等。我可以肯定地说，使用IB的每个人都可以有效地获得“使用笔尖时的真实速度提升”。 ”     

        您应该知道如何同时使用两者。两者之间的性能差异可以忽略不计，并且不应成为您选择其中一项的原因。 许多不熟悉iOS开发的人都会误以为，nib（.xib文件）不如以编程方式创建UI，如果您使用IB，则您不是一个好的iOS开发人员。该观点是100％错误的。 IB由Apple创建，Apple的开发人员正在使用IB创建自己的Mac OS X和iOS应用。如果IB（作为工具）足够好，可以被世界上一些最好的开发人员使用，那么对我们大多数人来说，它可能就足够了。 在实践中，我发现将两者结合通常很合适。 在我自己的应用程序中，我发现.xibs非常适合快速布局视图的基础知识，它们使您可以非常快速地进行迭代，同时可以预览视图的外观。在.xib文件中使用自动布局也要容易得多。 然后，当您需要做更高级的事情时，例如添加精美的动画或移动视图，这就是IBOutlets的目的。您放入笔尖的任何内容都可以通过IBOutlet引用。这样一来，您就可以通过编程方式使视图栩栩如生。 最后，您应该完全了解笔尖（.xib）为您自动完成的工作。您应该了解解冻.xib \对象时会发生什么。互联网上有许多资源可以更好地了解.xib文件。 另外，学习如何以封装的方式使用.xibs。例如，.xib对于诸如原型单元之类的东西非常有用，它们使您可以保持代码库模块化（比情节提要板更重要）。同样，您将在视图控制器中需要更少的UI代码。 最后，我总是说人们应该把IB / .xibs当作jQuery。这将为您节省大量时间，但是最好的开发人员仍然会根据需要知道如何使用javascript做所有事情。 祝好运并玩得开心点！ TL; DR版本 在决定是否使用.xibs时，不考虑性能。 使用.xibs是因为它们为您提供了正在创建的视图的预览，并且使您可以快速迭代 实际上，大多数应用程序将两者结合使用。您将以编程方式添加动画或四处移动视图，但是.xibs将是一个起点 完全了解.xib中的对象未冻结时会发生什么 您将提高工作效率，但是请确保您完全了解幕后发生的事情。     

        除非有理由，否则我将始终使用XIB文件。这样一来，您的视图就可以在将来轻松维护。 以编程方式创建视图的一些原因可能是： 控件需要调整大小， 重新定位或以其他方式更改 取决于其他 控制项 需要添加或删除 动态地 可能还有更多原因，但原因并不太多。 如果您在不需要时以编程方式创建视图，则其他开发人员将很难弄清楚视图的外观并进行更改，这会变得更加困难。     

如果以编程方式构建视图，则可以控制元素的加载。例如您可以使用延迟加载，然后在更重要的元素之后几分之一秒内加载辅助按钮，子视图等，从而可以更快地显示UI的关键部分。您甚至可以为某些元素设置动画。 如果使用IB，则会获得有关适当的元素间距和位置的指南，但是如果您不经常更改设计，则始终可以将IB中的坐标复制到代码中。 对于简单的UI元素，如果以编程方式创建它们，最终将需要维护更多的代码行。     

        IB和NIB在优化视图的加载/卸载方面做了大量工作，但其主要目的是最大程度地减少内存使用率和用户感知的速度。例如，延迟加载（如果有的话）可能会使应用程序UI稍慢一些，但它应该使内存使用率降低。反过来，这可以使大型应用程序的整体应用程序性能更好，并且受到很大的鼓励，但是很难以狭窄的方式定义“性能”。很难说出何时应该使用IB还是不应该使用IB-在某些情况下，最好在代码中使用IB。 IB的一个经常被忽视的因素就是开发速度，特别是如果您有多个开发人员的话。在更大的团队/项目中，您可能会有一些开发人员专门研究应用程序的基础结构，业务逻辑等，以及一些开发人员专门研究UI。在这种情况下，使用IB将使他们更容易独立工作，这将使整体开发更有效率。 我认为IB是iOS开发平台的核心部分。这不是在每种情况下的正确解决方案，但不知道如何使用IB将是一个真正的限制因素。