当我想到ARC时，没有发布的开销。但是一旦遇到这些Core Foundation变量，它们也需要在ARC中发布。
虽然ARC规则是两个不同的NS..和CF..，是有不支持任何具体的原因CF..在ARC？
当我想到ARC时，没有发布的开销。
我认为您的意思是“我不必担心释放”。尽管编译器有时可以对其进行优化，但通常会存在一些性能开销。
尽管NS ..和CF ..的ARC规则都不同，但是是否有任何特定原因不支持ARC中的CF ..？
许多核心基础对象是由ARC管理，以及它们的数量不断增加。您可以通过在标头中查找来判断特定功能是否支持ARC CF_IMPLICIT_BRIDGING_ENABLED。如果看到，函数将返回ARC兼容CF对象。例如，在iOS 8中，许多核心图形功能已添加到列表中。（我不想夸大这一点；我并不是说今天您今天还不需要CFRelease这些。我是说它们是由ARC管理的，它们是由Swift中的ARC管理的，最终可能会直接在ObjC中直接处理，而无需CFRelease。）
默认情况下不管理CF对象的原因是，必须有人检查并验证（审核）每个函数均符合“创建规则”命名约定，或为它们的异常正确注解。这项工作相当繁琐，Apple已将其扩展到多个版本中。但是随着时间的推移，您会发现这种情况越来越好。
Kazuki是正确的，您不能将ARC管理的对象放在结构或联合中，但这通常不会影响Core Foundation。
顺便说一句，CF_IMPLICIT_BRIDGING_ENABLED它只是arc_cf_code_auditedclang编译指示的包装。ARC文档7.8.1对C可保留指针接口进行审核中对此进行了说明。
本文收集自互联网，转载请注明来源。
如有侵权，请联系[email protected] 删除。
我来说两句