App Store的代码在iPhone 3G上运行与Xcode/设备代码不同

Question

我不确定如何解释这个问题。昨天我向商店提交了我的一个应用程序的更新。第一个屏幕截图是一个特定屏幕在我的 iPhone 3G 上运行，运行 iOS 4.2.1，从 App Store 下载的：

而下面的第二张图片是完全相同的代码，自原始提交以来没有进行任何更改，在通过 Xcode 连接的完全相同设备上运行。

该应用在我的 iPhone 4 上运行良好，运行 iOS 5，从 App Store 下载。所以总结一下：

1.从 App Store 获取的应用在 iPhone 3G 上有缺陷 2.从 App Store 获取的应用在 iPhone 4 上很好 3.通过 Xcode 连接的应用在 iPhone 3G 上很好

这些不一致之处并不仅限于图形，但它们都与自定义UITableViewCell代码有关。该代码只是将标签在每个方向上推动几个像素，并且自从第一天以来就一直正常工作。我已经向idp-dts提交了报告，并正在等待他们的回复，但由于等待列表通常需要一周或更长时间，我宁愿自己解决这个问题。

非常感谢任何帮助/提示/猜测！

iPhone 3G运行我的应用程序的App Store版本：

iPhone 3G运行Xcode的应用程序热点版本：

编辑： 这个问题听起来与这个问题非常相似：在使用LLVM和任何优化时构建应用程序会导致启动崩溃。联系我的客户正在使用第二代iPod Touch，除了iPhone 3G以外唯一使用armv6的硬件。

编辑2： 这是设置左侧颜色条边界的代码片段。 代码中似乎没有什么可疑的东西：

- (void)layoutSubviews {
    CGRect colorViewFrame = self.bounds;
    colorViewFrame.size.width = 6;
    colorViewFrame.origin.y += 3;
    colorViewFrame.origin.x -= 1;
    colorViewFrame.size.height -= 8;

    colorView.frame = colorViewFrame;
    ...
}

- Craig Otis

---

你的应用程序使用了哪个版本的 SDK 进行构建？ - BoltClock

iOS 5（GM种子）是基础SDK，而部署目标保留在iOS 4.0。 - Craig Otis

你说这是一个更新。它可能使用保存在应用程序包外的数据来计算偏移量吗？如果删除应用程序并重新下载会发生什么？ - Dolbz

删除并重新下载会让我得到损坏的版本。所有的帧都是在 [UITableViewCell layoutSubviews] 方法内动态计算的，因此没有保存任何内容。 - Craig Otis

我真的受够了...你知道吗？我决定查看应用程序的构建设置，比较调试和发布方案之间的差异。其中一个差异是LLVM编译器优化级别。在调试中设置为“无”，在发布中设置为“最快，最小”。我将其更改为调试的“最快，最小”，现在可以在模拟器中重现。这肯定是个漏洞吧？我不想提交非优化代码到App Store，但如果优化我的代码会改变它的行为呢... ?? - Craig Otis

@Bavarious，抱歉可能有些混淆。感谢您更新到Cocoa-Touch。 - Craig Otis

Answer 1

所以这是我在“构建设置”下找到的内容：

如果您修过一两门编译器优化的课程，这就说得通了。在设备上进行代码调试时，应该保留其原始状态以进行调试，而发布的代码应该经过优化以提高速度和效率。

现在来到有趣的部分。将我的调试设置更改为“最快、最小”：

在使用Xcode进行连接时，导致我的设备出现问题。

在提交Radar或做出任何草率的决定并向App Store提交非优化代码之前，是否有其他需要考虑的事情？编译器优化是否真正是布局问题的根本原因？

编辑：如果优化级别是问题所在，为什么经过优化的代码可以在我的iPhone 4上正常运行，但在我的iPhone 3G上不能正常运行？

编辑2：这个问题听起来非常类似于这个答案：使用LLVM和任何优化会导致应用程序在启动时崩溃

编辑3：从苹果Radar得到回复，这是一个已知的问题。将在未来版本的Xcode中修复。感谢大家的帮助！

- Craig Otis

---

听起来像是一个变量初始化问题 - 就像在某些情况下为您初始化的值，在其他时候则没有。 - paulmelnikow

听起来像是一个优化问题，但你应该在你的机器上本地测试调试和发布版本。 发布你进行单元格缩进的代码，也许有人可以帮助。 - EricLeaf

似乎这是一个优化问题。我会养成在两个设备上测试调试和发布版本的习惯。我之前一直在iPhone 4上测试了两个版本，并在iPhone 3G上测试了调试版本，但我没有预料到在单一硬件和特定编译方案下会出现问题。我想这教训已经吸取了，但它仍然表明存在一个优化级别的错误，对吧？我会在原始问题中更新代码。 - Craig Otis

如果不清楚的话，我并不是持反对意见。我在提出这是哪种优化问题的建议。 - paulmelnikow

是的，我认为你是对的。优化问题肯定会影响[self bounds]返回值，因此初始化肯定是一个因素。感谢迄今为止的帮助。 - Craig Otis

Answer 2

我遇到了同样的问题，并找到了解决方法。

经过在优化和未优化代码上进行一些 NSLog 的测试后，我发现在第一次访问高度参数后，CGSize 会变得损坏。

因此，在我的 UITableViewCell 子类 layoutSubviews 中有以下代码：

  NSLog(@"size.height %f", size.height);
  NSLog(@"2nd access size.height %f", size.height);
  _titleLabel.frame = CGRectMake(kLeftSpacer, kSpacerHeight, kTitleWidth ,size.height);
  NSLog(@"after setFrame size.height %f", size.height);

在日志中给出了以下内容：

size.height 19.000000

第二次访问 size.height 56.00000

设置后的 size.height 56.00000

因此，我的解决方法是使用一个中间高度标识符：

CGFloat height = size.height; 
NSLog(@"size.height %f", size.height);
_titleLabel.frame = CGRectMake(kLeftSpacer, kSpacerHeight, kTitleWidth ,height);
NSLog(@"after setFrame size.height %f", size.height);

一切都很好...

我猜不如关闭优化安全，但我的应用程序的其余部分似乎很好...最好使用发布版本进行测试！

- Nick Hingston

---

我在iOS 4.2.1上使用LLVM 3和编译器优化时，几乎遇到了与CGPoint完全相同的问题。 - Ian1971

Answer 3

答案是在armv6编译中添加编译器标志-mno-thumb，而在armv7编译中不要添加它。

如何操作可参考：Xcode 4中是否有一种编译ARM而不是Thumb的方法？

- Carl D'Halluin

---

该页面上最佳答案还提到：“此外，LLVM编译器3.0中存在一个错误，它随Xcode 4.2一起发布（据我所知，已在4.2.1中修复），其中在ARMv6的Thumb下编译浮点计算错误。如果您正在使用该特定版本的Xcode，则需要执行此操作以获得旧设备的正确行为。”因此，我认为与其添加编译器标志，升级到Xcode 4.2.1更容易些。 - Craig Otis

当然，克雷格，但这需要你升级到Lion版本。 - Carl D'Halluin

Answer 4

如果您正在向表视图单元格添加和布局视图，则应将它们添加到单元格的contentView中，并在所有布局代码中使用self.contentView.bounds而不是self.bounds。

您还必须调用[super layoutSubviews]，否则会发生许多奇怪的事情。

- Mike Weller

---

感谢您的contentView注意事项，我一定会进行更改。（尽管我无法想象这是问题的根本原因，因为更改编译器优化级别可以解决它。）我在代码片段后面调用[super layoutSubviews]。 - Craig Otis

好的，你需要在重写的方法中作为第一行调用 [super layoutSubviews]。我不是说你错了，但我认为编译器优化错误很可能不是这种行为的根本原因。它可能只是暴露了潜在问题。 - Mike Weller