问题标签 [unsafe-unretained]

我将 ARC 添加到我正在开发的应用程序中。不幸的是，它崩溃了。我发现将所有应用程序更新到 ARC 的自动脚本为所有 id<protocolName> 类型提供了 __unsafe_unretained 限定符。

1. 为什么不是弱类型？我已将该应用程序及其所有子项目部署到 iOS 5，因此我的限定符确实很弱。

2. 我的主要问题是，如果我将这些代表声明为强，我将有一个保留周期。如果我不这样做，下次我打电话给他们时，他们将成为僵尸。我检查并在我的应用程序崩溃之前，代表是 NSZombie。

这次崩溃的原因是什么，如何预防？

我记得在Xcode 5中，如果您将视图从情节提要拖到代码中，它将创建一个具有属性的weak属性。现在在Xcode 6中它unsafe_unretained用作默认值。这种变化的原因可能是什么？

takeUnretainedValue和有什么区别takeRetainedValue？根据 Apple 的文档：

这两种方法都返回对象的原始未包装类型。您可以根据所调用的 API 返回未保留对象还是保留对象来选择要使用的方法。

但是我怎么知道非托管对象是非保留对象还是保留对象呢？例如，框架中的方法ABAddressBookCreateWithOptions:返回AddressBook一个非托管对象ABAddressBook，一些教程将其视为保留对象。使用时ALAsset，该方法thumbnail返回一个非托管对象CGImage，一些教程将其视为未保留对象。

我会感谢你的帮助。

有什么方法可以检查unowned(safe)Swift 参考中的“可用性”吗？所以，我正在寻找一个假设函数，如isReferenceAccessible本例所示：

免责声明：这个问题与weak参考无关！我知道strong,unowned和weakreferences 是如何工作的。而且我不想使用weak引用（因为它可能很慢且可变）。我知道unowned(safe)即使deinited在我们尝试访问它时已经分配了引用。而且我知道编译器可以执行此检查，并且它实际上会在应用程序崩溃之前对其进行检查。

因此，我相信它可以是非常强大且性能良好的技术/范式，可以打破现代 Swift 中的引用循环。

此外，我相信它可能是一个很棒的语言功能！例如，假设我们调用了修饰符shared_ownership，并且它的工作原理与上述行为类似：

...通过这样的实现：

...具有副作用（没有weak相关的复杂性和性能损失）相当于：

哦，那太棒了！

有关、和之间差异的weakunowned(safe)unowned(unsafe)更多信息。

更新

我发现了与上面讨论的特性相关的很棒的 Swift 提案：允许使用可选绑定将 self 从弱引用升级到强引用。

我在观看F8-2016 Building iOS Tooling at Facebook Scale视频时，在 7:01 发现了一个有趣的代码部分。

Facebook 以这种方式在 Objective-C 中定义了一个静态常量：

static __unsafe_unretained NSString * const kAuthorKey = @"AUTHOR";

到目前为止，我以相同的方式声明了我的静态常量，但没有__unsafe_unretained. 如果没有这个修饰符，常量将会是strong，但由于它在应用程序运行期间始终存在，所以它是strong还是都没有关系__unsafe_unretained。

我错过了什么吗？Facebook有什么理由使用__unsafe_unretained吗？

在这种情况下避免不良访问的最佳解决方案是什么？

我将代码更改为：

但我想知道是否没有更好的解决方案

我从我正在开发的应用程序中获得了此代码。当 BLE 人离开团队时，我继承了这个代码。我不擅长低级的东西和数据的东西。我是 UI/UX 前端人员，现在我确实需要亲自动手。这段代码现在有点旧，并且使用了不推荐使用的代码。我一直试图使警告静音，但没有成功，但我一直以相同的代码或错误结束。

这是生成警告的代码。使用 withUnsafeBytes 时在返回线上

此方法用于将字节数组解码为结构。我从 BLE 服务获取数据，并将各种变量打包成一个字节数组。

如果有任何一个可以解决这个问题或更好的方法来做 id。