使用.xib文件提供iPhone应用程序的GUI会导致性能下降吗?

jan*_*mon 12 iphone performance objective-c xib nib

我想知道使用.xib文件进行GUI设计和以编程方式执行此操作之间是否存在差异.

因为它是一个编译器,我认为没有相关的时间丢失.

我错了吗?

Ror*_*yth 26

(注意:在我的手机上点击这个,所以我提前为任何奇怪的格式或语法道歉 - 如果有问题,我会在我回到笔记本电脑时修复它们.)

我做了一些快速,肮脏,非常非正式的测试来自己检查这个,这就是我发现的(注意我为测试构建的应用程序只是划痕而不一定代表"真正的"应用程序):

  • 当初始屏幕是笔尖时,启动时间更快

  • 对于所有后续屏幕,在手动编写UI时性能会提高

一开始很奇怪,但是当你想到它时,也许并不是那么奇怪.

启动问题混淆了我,但我以为这是因为苹果,是苹果和沉迷于启动时间(在一个很好的方法,当然),只是优化了手机的取档以这样的方式,从存档(NIB)加载可以是比手工编码更快.

也就是说,大多数人编写的应用程序不会受到任何差异的显着影响.我的(再次:快速和肮脏)测试表明,从冷启动开始(你还没有运行应用程序或者一段时间),基于笔尖的应用程序始终加载其初始屏幕的速度是手动编码速度的两倍版.虽然这听起来很重要,但我们只谈了几毫秒.这种差异对于用户来说是难以察觉的.为了热烈的开始(你已经打开并关闭了应用程序),启动时间的差异要小得多.

出于这个原因,我喜欢使用笔尖来布置应用程序的基础:任何顶级导航(选项卡控制器,导航控制器等),然后手动编写其余UI.

另外,因为iPhone UI特别适合iPhone(令人惊讶!),手工编写UI并不像编写桌面应用程序那样困难.您一遍又一遍地使用相同的UI组件 - 一旦您完成了这一点,就可以轻松地在代码中添加UI.您没有80亿个小部件可供选择,就像开发Windows/OS X /任何应用程序一样.iPhone的一致性使其成为我在手工编码UI方面多年来开发的最简单的平台.

我还发现,当我手动编写UI时,NSCoding(我用于在应用程序运行中保持状态)更容易使用.我遇到了由于UIImage实例导致基于nib的屏幕无法正确存档的问题.UIImage(至少我最后一次检查)不符合NSCoding,因此归档过程就会消失(而且这是一种相当不愉快的死亡).我在这里使用UIImage作为例子,但是归档程序试图存储的任何不符合NSCoding的东西都会破坏这个过程,所以这是需要考虑的事情.

另外,当我使用动态表时,我总是手动编写UI.如果我正在创建一个静态表 - 一个基本上永远不会改变的单元 - nib就可以了.对于任何其他类型的表,特别是那些具有缩略图和其他资源密集型位的表,我手工编码时获得的控件可以获得基于nib的表格单元格无法获得的性能.对于这一点,你必须跳过CocoaTouch并直接与CoreGraphics中工作,但性能的提升可以使是每一个代码最后一行你写的价值.有关我工作过的项目表性能的示例,请参阅Barnes and Noble Store(不是电子书阅读器)和Style.com.我们为那些(和其他)应用程序构建了一个框架,平滑表滚动的秘诀是我们从未使用过从nib加载的单元格(它比这更复杂,但跳过笔尖是获得性能的第一步'将在那些应用程序中看到).

一般来说,使用nib时可能需要考虑的最重要的事情是你需要跨文件中断UI.也就是说,不要将应用程序的整个UI粘贴到一个笔尖中.当一个nib正在加载时,它就是整个东西 - 在你的用户很少会看到这些内容时,你的用户很可能会看到一个视图,并且这些视图就像其他所有内容一样被加载,无缘无故地吸收资源.如果您不为每个应用程序的屏幕使用单独的笔尖,则很容易遇到内存和性能问题.

进一步澄清:如果你有一个带有五个视图控制器的应用程序,请将每个控制器粘贴在自己的笔尖中.你不想在需要之前加载任何东西.这有例外,但这就是编码的方式 - 给定足够的时间,你会找到一个"错误的方式"做某事的理由,但每个屏幕的a-nib方法就是你应该的方式除非你有充分的理由不这样做.

我会把它留在那里 - 我希望它有点帮助.

只记得:

  • 我的非正式捣乱表明,使用笔尖启动速度更快(只要你保持笔尖尽可能简单,保留你需要的笔尖).

  • 启动后,手动编码的UI的性能似乎有所改善.

  • 如果操作正确,如果您不是在编写游戏或其他东西,那么笔尖不应该导致可察觉的性能问题.

  • 根据我的经验,表格是不同的 - 它们是我很少使用笔尖的地方.

  • 如果您使用NSCoding来保持应用程序状态,那么nib可能会有问题,并且任何解决方法可能都不值得花费,因为手动编写iPhone UI相对容易.

  • 保持你的笔尖尽可能简单 - 我不能说这个.尽可能为应用的每个屏幕创建一个笔尖,而不是将整个应用程序的UI填充到一个笔尖中.

好.这次停下来真实.

希望这可以帮助 :)


mah*_*udz 16

很少.有一些例外.例如,如果您使用xib加载进入UITableViewCell的图像,那么这可能是一个问题,因为具有许多单元格的UITableViews对加载时间敏感.但是,出于所有意图和目的,应该没有明显的性能影响.

xib中的信息必须在运行时解码并加载到内存中,这不像以编程方式直接创建UI元素那么快.

  • 如果你重复使用像你一样的单元格,那么只会创建适合屏幕的单元格,所以开销不是那么多(你可以在IB中设置重用标识符). (3认同)

NSR*_*der 7

注意过早优化,特别是当它涉及编写比你需要的更多代码时.

  • 没错,但是当涉及iPhone及其有限的资源时,我通常认为是疯狂的优化可以产生实际的差异.Wil Shipley对此有一些有趣的评论:http://www.vimeo.com/4421498 (4认同)