iOS15.6.1及以上版本NSKeyedArchiver偶现崩溃求助

核心问题定位 #

崩溃日志中的__NSCFType是Foundation框架的私有通用类型，出现这类报错通常意味着实际调用方法的对象并非你预期的自定义类实例——要么是对象内存被释放后被复用为其他类型，要么是归档/解档流程中混入了未正确实现编码逻辑的对象。iOS 15.6.1+的系统内存管理或归档API校验逻辑更严格，导致原本偶现的隐性问题被触发。

可能原因及对应解决方案 #

1. 野指针/内存释放问题 #

• 原因：待归档的对象已被提前释放，内存被系统复用为其他Foundation对象（如NSString、NSDictionary等），此时调用归档方法会触发未识别的selector。
• 解决：
  • 开启Xcode的Zombie Objects诊断功能，复现崩溃后可直接查看对象原本的类型，定位哪个对象出现内存异常。
  • 检查归档对象的持有关系，确保归档操作执行时对象处于存活状态（避免用弱引用对象直接归档，必要时转为强引用临时持有）。

2. 嵌套对象未正确实现归档逻辑 #

• 原因：主对象虽实现了encodeWithCoder:和initWithCoder:，但内部嵌套的子对象（如属性中的自定义类、数组/字典内的元素）未实现归档方法，或子对象在某些场景下变为未预期类型（如弱引用对象释放后指向随机内存）。
• 解决：
  • 遍历主对象所有需要归档的属性，确保每个子对象都正确实现了归档协议方法，包括容器类中的元素。
  • 对弱引用属性做判空处理，归档前确认对象非nil，避免归档无效内存地址。

3. 旧版归档API的隐性行为变化 #

• 原因：iOS 15后苹果对NSKeyedArchiver/Unarchiver的底层逻辑做了调整，旧版无类型校验的API（如archiveRootObject:toFile:）在高版本会暴露原本被忽略的不规范实现。
• 解决：
  • 替换为iOS 12+推荐的新版API，这类API提供明确错误信息且类型校验更严格：

    // 归档
    NSError *archiveError;
    NSData *archiveData = [NSKeyedArchiver archivedDataWithRootObject:targetObject 
                                                  requiringSecureCoding:NO 
                                                                  error:&archiveError];
    if (archiveData && !archiveError) {
        [archiveData writeToFile:filePath atomically:YES];
    }
    
    // 解档
    NSData *unarchiveData = [NSData dataWithContentsOfFile:filePath];
    NSError *unarchiveError;
    id resultObject = [NSKeyedUnarchiver unarchivedObjectOfClass:[YourCustomClass class] 
                                                        fromData:unarchiveData 
                                                             error:&unarchiveError];
    

  • 解档时添加类型校验，避免错误类型对象进入业务逻辑：

    id object = [NSKeyedUnarchiver unarchiveObjectWithFile:fileName];
    if (![object isKindOfClass:[YourCustomClass class]]) {
        // 处理异常：返回默认对象或删除无效归档文件
        return nil;
    }
    

内容的提问来源于stack exchange，提问作者jacklee