Storyboard相较于代码布局，是否会影响应用运行时性能？

核心结论 #

总体来说，Storyboard在运行时的性能差异可以忽略不计，绝大多数场景下用户感知不到区别。但在极端情况或特定场景下，两者存在细微差异：

启动阶段的差异 #

• Storyboard在App启动时需要解析XML格式的布局文件，将其转换为对应的UIKit/AppKit对象。这个解析过程会占用少量CPU和内存，但通常只在首次加载该Storyboard时发生一次。
• 代码布局是直接通过代码初始化UI对象，省去了解析XML的步骤，理论上启动速度会快一点点，但除非你的Storyboard包含极其复杂的界面（比如上百个控件嵌套），否则这点差异用户根本感觉不到。

界面加载与渲染 #

• 无论是Storyboard还是代码布局，最终生成的UI对象都是一样的，渲染阶段的性能完全由UIKit/AppKit的渲染管道决定，和布局方式无关。
• 如果Storyboard中使用了大量自动布局约束，和代码里写的约束在运行时的计算性能是一致的——约束的解析和计算逻辑是框架层面的，和定义方式无关。

极端场景下的例外 #

• 当你在Storyboard中嵌套了多层复杂的容器视图（比如嵌套多个UINavigationController、UITabBarController），首次加载时的解析开销会稍微明显一点，但这种情况在实际开发中很少见，而且可以通过懒加载或者分模块加载Storyboard来缓解。
• 代码布局的优势在于可以更精细地控制对象的初始化时机（比如延迟加载非关键UI控件），而Storyboard默认是一次性加载所有视图，如果你没做优化，可能会在复杂界面加载时出现短暂卡顿，但这属于优化问题，不是布局方式本身的性能缺陷。

总结 #

除非你的App有极其严格的性能要求（比如启动时间精确到毫秒级），否则不需要为了运行时性能放弃Storyboard。编译时间的增加是Storyboard的主要代价，但运行时的性能差异几乎可以忽略。选择哪种布局方式更多取决于团队协作效率、开发速度和项目需求。

内容的提问来源于stack exchange，提问作者user17084171