Objective c NSData writeToFile读取时未完全写入文件

我正在编写一个iPhone应用程序，允许您在一个视图中浏览图像，并在另一个视图中创建它们

创建图像的视图将使用以下代码将图像写入文档文件夹（点击按钮关闭视图时）：

浏览器视图将使用以下方式加载图像：

UIImage *image = [UIImage imageWithContentsOfFile:path];

现在，这10次中有9次是完美的。十分之一的图像在我加载之前没有完全写入，因此图像的下半部分将为黑色。最终一切都将被写入-如果我在浏览器中重新加载图像，将显示完整图像。我认为这些东西在一个线程中总是一致的

我能做些什么来防止这种行为吗

---

现在，我正在考虑将新创建的图像传递回浏览器，但这似乎是一种攻击，因为浏览器也会显示您以前创建的所有图像。

对于UI未及时完成的进程，标准解决方案是将其分解为一个新线程。也许您应该创建一个单独的线程来保存图像，然后通过委托方法通知UI进行自我更新

如果您确定映像正在使用

writeToFile:atomically:

保存在主（UI）线程上，并且映像随后也被加载到主线程上，那么该方法在维护其契约以在调用返回时完成操作时似乎有问题。iOS有时确实有漏洞，也许你发现了

但是，我还要注意，我看到出现类似问题的一种可能方式是在离开一个视图以显示另一个视图时调用

视图将出现

，

视图消失

，等等。因此，我还要确保图像没有保存在这些方法中

---

既然你说问题显示的是一个半可见的图像，我猜情况并非如此，但我为其他有类似操作顺序问题的人提供了警告。

这没有帮助，因为现在它是在主线程上执行的，因此操作保证在显示新视图之前完成。@rasmus，如果涉及到大量的工作（如果您没有看到及时可靠地编写的文件，则必须进行），那么您应该在后台线程上执行这些工作（保存）。您不应该在UI线程上执行所有操作，试图强制顺序执行。用户不喜欢冻结的UI。@可能不喜欢，但延迟不是我的问题，所以这也不是我问题的解决方案。请把问题再读一遍。此外，在这种情况下，延迟并不显著。问题不在于性能/延迟，而在于正确性。新线程无法解决此问题。@rasmus新线程将解决您的问题。您希望图像立即显示。如果不是100%写的，你只能看到一部分。用户界面收到通知（可能很快）并自行更新-现在您可以看到完整的图像。如果要避免这种影响，必须让UI在显示图片的任何部分之前等待代理通知。在这种情况下，您可能还需要显示活动指示器或类似的内容。@Mundi您没有抓住要点。再等一段时间只是另一种恶作剧。writeToFile完成后，文件应完全写入。新线程也会这样想。您能否显示哪个方法正在调用

writeToFile:atomically:

？是按钮单击处理程序，还是

视图将消失：

，还是其他原因？您是否检查了

writeToFile:

的返回值？您是否可以尝试另一种

writeToFile:

变体，它允许您传入

n错误

？单击按钮后，图像将被保存，然后关闭视图。图像将加载到viewDidLoad浏览器视图中。实际上，它很难复制，我认为它更像是1/100或1/1000。我昨天看了三四遍。恐怕已经够烦人的了。现在，当我来回翻动时，这种情况似乎不会发生。此外，我在多台设备（4S、3GS、iPad）上看到过这种情况。这里有一个类似的未回答问题：。也许在运行循环中存在未记录的依赖关系？啊，我并不孤单。我发现了同样的问题：（仍然没有解决办法）。

UIImage *image = [UIImage imageWithContentsOfFile:path];