HandyJSON源码分析

本文不涉及如何使用，仅对齐实现原理作一个记录。

前置条件

Swift中，一个类实例的内存布局是有规律的：

32位机器上，类前面有4+8个字节存储meta信息，64位机器上，有8+8个字节；
内存中，字段从前往后有序排列；
如果该类继承自某一个类，那么父类的字段在前；
Optional会增加一个字节来存储.None/.Some信息；
每个字段需要考虑内存对齐；

这方面尚未从官方的资料找到参考，上述规律一些是从网上其他大神的总结中收集，一些从Clang的一些说明文档中挖掘，加上自己的反复验证得到

具体步骤：

获取它的起始指针，移动到有效起点；
通过Mirror获取每一个字段的字段名和字段类型；
根据字段名在JSON中取值，转换为和字段一样的类型，通过指针写入；
根据本字段类型的占位大小和下一个字段类型计算下一个字段的对齐起点；
移动指针，继续处理；

步骤图

流程总结

HandyJSON（5.0）主要流程记录.png

HandyJSON 是强依赖 metadata 结构的，如果 metadata 有大规模的改动可能直接导致这个库完全不能用。随着Swift语言的版本升级。metadata的结构也有多次变动。

Swift 4.2 以前(不包含4.2)

![](https://user-gold-cdn.xitu.io/2019/2/26/16929595b0015018?w=490&h=734&f=png&s=61393)
struct _NominalTypeDescriptor {
    var mangledName: Int32
    var numberOfFields: Int32
    var fieldOffsetVector: Int32
    var fieldNames: Int32
    var fieldTypesAccessor: Int32
}

Swift 4.2

Swift 4.2 对 nominal type descriptor 做了调整，struct 和 class 结构变得有所不同，乍看没有少什么东西，其实对 fieldTypesAccessor 这个函数做了修改，不再符合 c 的 calling convention，因此不可以再从 nominal type descriptor 获取类型信息。

struct _StructContextDescriptor: _ContextDescriptorProtocol {
    var flags: Int32
    var parent: Int32
    var mangledName: Int32
    var fieldTypesAccessor: Int32
    var numberOfFields: Int32
    var fieldOffsetVector: Int32
}

struct _ClassContextDescriptor: _ContextDescriptorProtocol {
    var flags: Int32
    var parent: Int32
    var mangledName: Int32
    var fieldTypesAccessor: Int32
    var superClsRef: Int32
    var reservedWord1: Int32
    var reservedWord2: Int32
    var numImmediateMembers: Int32
    var numberOfFields: Int32
    var fieldOffsetVector: Int32
}

尽管苹果希望我们用 Mirror 来做反射，但是其实 Mirror 至今为止都不包含属性的类型的信息，因此苹果留了一个临时接口 swift_getFieldAt 来帮助我们获取类型信息：

@_silgen_name("swift_getFieldAt")
func _getFieldAt(
    _ type: Any.Type,
    _ index: Int,
    _ callback: @convention(c) (UnsafePointer<CChar>, UnsafeRawPointer, UnsafeMutableRawPointer) -> Void,
    _ ctx: UnsafeMutableRawPointer
)

为什么说是临时的呢，因为 Swift 5 的时候就发现这个接口没了。。。。

Swift 5.0

到了 Swift 5.0 的时候，前面已经说过了获取类型的那个接口没了，那么我们只好翻出 Swift 的源码来找找思路了，
找到 TypeContextDescriptorBuilderBase 类的 layout() 方法：

void layout() {
  asImpl().computeIdentity();

  super::layout();
  asImpl().addName();
  asImpl().addAccessFunction();
  asImpl().addReflectionFieldDescriptor();
  asImpl().addLayoutInfo();
  asImpl().addGenericSignature();
  asImpl().maybeAddResilientSuperclass();
  asImpl().maybeAddMetadataInitialization();
}

按源码写出 nominal type descriptor 的结构如下：

struct _StructContextDescriptor: _ContextDescriptorProtocol {
    var flags: Int32
    var parent: Int32
    var mangledNameOffset: Int32
    var fieldTypesAccessor: Int32
    var reflectionFieldDescriptor: Int32
    var numberOfFields: Int32
    var fieldOffsetVector: Int32
}

struct _ClassContextDescriptor: _ContextDescriptorProtocol {
    var flags: Int32
    var parent: Int32
    var mangledNameOffset: Int32
    var fieldTypesAccessor: Int32
    var reflectionFieldDescriptor: Int32
    var superClsRef: Int32
    var metadataNegativeSizeInWords: Int32
    var metadataPositiveSizeInWords: Int32
    var numImmediateMembers: Int32
    var numberOfFields: Int32
    var fieldOffsetVector: Int32
}

虽然 fieldTypesAccessor 还是无法调用，但是我们发现这里多了一个 reflectionFieldDescriptor 指针，直觉告诉我办法应该在这个东西里面，所以先看下这个东西是什么结构：

void addReflectionFieldDescriptor() {
  ....
    
  B.addRelativeAddress(IGM.getAddrOfReflectionFieldDescriptor(
    getType()->getDeclaredType()->getCanonicalType()));
}

逻辑基本就是拿到 ReflectionFieldDescriptor 的地址，然后把地址放到相应的内存里，需要注意的是这里放的是一个相对的地址，RelativePointer 的注释中写道：

// A reference can be absolute or relative: // // - An absolute reference is a pointer to the object. // // - A relative reference is a (signed) offset from the address of the // reference to the address of its direct referent.

相对引用指的是相对当前引用指针地址的偏移量，于是我们有了获取 ReflectionFieldDescriptor 地址的方法：

var reflectionFieldDescriptor: FieldDescriptor? {
    guard let contextDescriptor = self.contextDescriptor else {
        return nil
    }
    let pointer = UnsafePointer<Int>(self.pointer)
    let base = pointer.advanced(by: contextDescriptorOffsetLocation)
    let offset = contextDescriptor.reflectionFieldDescriptor
    let address = base.pointee + 4 * 4 // (4 properties in front) * (sizeof Int32)
    guard let fieldDescriptorPtr = UnsafePointer<_FieldDescriptor>(bitPattern: address + offset) else {
        return nil
    }
    return FieldDescriptor(pointer: fieldDescriptorPtr)
}

拿到了地址，我们还需要知道 FieldDescriptor 这个结构是什么样子的，我们找到 FieldDescriptor 这个类：

// Field descriptors contain a collection of field records for a single
// class, struct or enum declaration.
class FieldDescriptor {
  const FieldRecord *getFieldRecordBuffer() const {
    return reinterpret_cast<const FieldRecord *>(this + 1);
  }

  const RelativeDirectPointer<const char> MangledTypeName;
  const RelativeDirectPointer<const char> Superclass;

public:
  FieldDescriptor() = delete;

  const FieldDescriptorKind Kind;
  const uint16_t FieldRecordSize;
  const uint32_t NumFields;

  using const_iterator = FieldRecordIterator;
  
  ....
}

FieldDescriptor 的结构里有一个 FieldRecord 的数组，从名字看里面应该保存了类型信息，我们再翻出 FieldRecord 的源码：

class FieldRecord {
  const FieldRecordFlags Flags;
  const RelativeDirectPointer<const char> MangledTypeName;
  const RelativeDirectPointer<const char> FieldName;
  ....
}

很遗憾 FieldRecord 并没有直接保存类型信息，只有一个 MangledTypeName ，问题不大，我们还有一个叫 swift_getTypeByMangledNameInContext 的函数，这个函数背后调用的 swift_getTypeByMangledName 函数与之前的 getFieldAt 内部调用的是同一个函数，返回是 Any.Type：

@_silgen_name("swift_getTypeByMangledNameInContext")
public func _getTypeByMangledNameInContext(
    _ name: UnsafePointer<UInt8>,
    _ nameLength: Int,
    genericContext: UnsafeRawPointer?,
    genericArguments: UnsafeRawPointer?)
    -> Any.Type?

参考：

Swift 5 Type Metadata 详解

Metadata官方文档

深度解析HandyJSON

swift之内存布局
 Swift内存赋值探索二：指针在Swift中的使用