iOS 面试

iOS面试题答案整理-OC

Posted by Buddy on April 22, 2024

1、OC之对象

什么是内存对齐，内存对齐规则是什么样的？

内存对齐是指将数据存储在内存中时，为了提高数据访问的效率和速度，需要按照一定的规则将数据排列在规定的地址上。以下是内存对齐的规则：

  1. 数据成员对齐：
    • 数据成员的首地址相对于结构体首地址的偏移量（offset）必须是其数据类型大小的整数倍。例如，一个int类型的数据成员应该从能被4整除的地址开始存储，因为int类型的大小通常为4字节。
  2. 结构体成员对齐：
    • 结构体中的第一个数据成员的首地址与结构体的首地址相同，其后的每个数据成员的首地址需要满足其自身的对齐规则。
    • 如果结构体中包含了其他结构体成员，则该结构体成员的首地址需要是其内部最大数据成员的大小的整数倍。
  3. 结构体大小对齐：
    • 结构体的大小必须是其内部最大数据成员的大小的整数倍。如果不是，编译器会在结构体的末尾填充字节，以保证结构体的大小满足对齐要求。
  4. 对齐参数：
    • 不同的数据类型有不同的对齐参数。例如，char型数据的对齐参数为1字节，short型为2字节，int和float型为4字节，double型为8字节。对于结构体或类，其默认的对齐参数是其内部所有数据成员中对齐参数最大的那个。
  5. 自定义对齐值：
    • 在某些情况下，程序员可以通过编译器指令或属性来指定特定的对齐值，以覆盖默认的对齐规则。
  6. 硬件和性能考虑：
    • 内存对齐的主要目的是为了提高内存访问的效率。某些硬件平台在访问未对齐的内存时，可能需要进行多次读取操作并剔除多余的数据，这会降低数据访问的速度。通过内存对齐，可以确保数据以最优的方式被访问，从而提高程序的性能。

请注意，具体的对齐规则可能因编译器和硬件平台的不同而有所差异。因此，在编写跨平台代码时，需要特别注意内存对齐的问题。

总的来说，内存对齐是一种优化技术，它通过将数据存储在适当的地址上来提高内存访问的效率和速度。了解并遵循内存对齐的规则对于编写高效、稳定的程序至关重要。

内存对齐计算(x + (8-1)) & ~(8-1) 和 (x + (8-1)) » 3 « 3

内存对齐通常是为了确保数据结构（如结构体或数组的元素）的内存地址是其大小（或指定对齐值）的倍数，以提高内存访问的效率。两种常见的内存对齐计算方法包括使用位运算和直接进行除法（或右移）后取整再乘法（或左移）。

  1. (x + (8-1)) & ~(8-1)

这个表达式使用了位运算来确保数值是8的倍数。这里的步骤是：

  • (8-1): 计算出7，这是8的倍数减1。
  • (x + (8-1)): 将x加上7，这是为了确保如果x不是8的倍数，则结果会超过最接近x且大于x的8的倍数。
  • ~(8-1): 对7进行位取反操作，得到一个所有8的倍数对应的位都为1，其余位为0的掩码。例如，在32位系统上，~(8-1) 的结果是 0xFFFFFFF8。
  • & ~(8-1): 使用与运算（&）将上一步的结果与 (x + (8-1)) 进行与操作。这个操作会将 (x + (8-1)) 中不是8的倍数的部分清零，从而得到大于或等于x的最小的8的倍数。
  1. (x + (8-1)) >> 3 << 3

这个表达式使用了移位操作来达到内存对齐的目的。步骤是：

  • (x + (8-1)): 和上面一样，将x加上7。
  • >> 3: 将结果右移3位。这相当于将原数值除以8（因为2的3次方是8），并丢弃余数。这样做可以找到不大于原数值的最大的8的倍数。
  • << 3: 然后将上一步的结果左移3位，即乘以8。由于之前已经通过右移丢弃了余数，因此这个左移操作实际上是将上一步找到的8的倍数还原到它原本应该在的位置（但已经是8的倍数了）。

这两种方法都可以实现内存对齐到8字节边界的目的，但使用位运算通常会比使用除法（或右移）和乘法（或左移）更快，因为位运算在硬件级别上通常更高效。不过，在现代编译器和处理器中，这种性能差异可能不那么明显，因为编译器可能会自动进行某些优化。

结构体实际占用内存计算，系统给该结构体开辟空间内存大小计算，他们的区别是什么？

结构体实际占用内存和系统给结构体开辟的空间内存大小是两个相关但不同的概念。下面将分别解释这两个概念，并阐述它们之间的区别。

结构体实际占用内存计算

结构体的实际占用内存通常指的是结构体中所有成员变量所占用的内存总和。这个计算需要考虑以下几个因素：

  1. 成员变量的大小：每个成员变量都有其固定的大小，如int通常为4字节，double通常为8字节等。
  2. 内存对齐：为了提高内存访问效率，编译器会按照特定的对齐方式对结构体成员进行排列。这可能会导致在成员变量之间插入填充字节，以确保每个成员都按其对齐要求进行对齐。
  3. 结构体大小的对齐：结构体的总大小也需要是其最大成员对齐数的整数倍，如果不是，编译器会在结构体的末尾添加填充字节。

因此，结构体的实际占用内存可能大于其成员变量大小的简单总和。

系统给结构体开辟空间内存大小计算

系统给结构体开辟的空间内存大小通常与结构体的实际占用内存相同或更大。这个大小取决于以下几个因素：

  1. 结构体的实际占用内存：系统至少需要为结构体分配足够的内存以容纳其所有成员变量和必要的填充字节。
  2. 内存分配策略：系统可能会根据内存管理策略或性能考虑，为结构体分配比实际占用内存更大的空间。例如，系统可能会为了效率而分配更大的内存块，以减少内存碎片或提高缓存利用率。
  3. 对齐要求：系统可能会为了满足特定的对齐要求而分配额外的内存。例如，如果系统要求所有数据都按16字节对齐，那么即使结构体的实际占用内存小于16字节，系统也可能会分配16字节的内存块。

他们的区别

  1. 计算基础：结构体实际占用内存是基于结构体成员的大小和对齐要求计算的；而系统给结构体开辟的空间内存大小可能还考虑了系统的内存管理策略和对齐要求。
  2. 大小关系：在大多数情况下，系统给结构体开辟的空间内存大小至少等于结构体的实际占用内存。但在某些情况下，为了优化性能或满足特定要求，系统可能会分配更多的内存。
  3. 使用目的：了解结构体的实际占用内存有助于优化数据结构和减少内存占用；而了解系统给结构体开辟的空间内存大小则有助于理解系统的内存使用情况和性能特点。

综上所述，结构体实际占用内存和系统给结构体开辟的空间内存大小是两个密切相关的概念，但它们的计算方法和考虑因素可能有所不同。

class_getInstanceSize , malloc_size, sizeof 区别？

class_getInstanceSize, malloc_size, 和 sizeof 是用于获取对象或内存块大小的函数或操作符，但它们在用途、上下文和所得到的结果上有所不同。以下是这三者的主要区别：

  1. class_getInstanceSize:
    • 用途：class_getInstanceSize 是 Objective-C 运行时库中的一个函数，用于获取一个给定类的实例所需的内存大小。
    • 上下文：它通常用于 Objective-C 的动态运行时环境中，当你需要知道一个特定类的实例对象需要多少内存时。
    • 结果：返回的是类的实例所需的内存大小（以字节为单位）。
    • 示例：如果你有一个 Objective-C 类 MyClass，那么 class_getInstanceSize([MyClass class]) 会返回该类的一个实例所需的内存大小。
  2. malloc_size:
    • 用途：malloc_size 是一个特定于某些库或系统的函数（例如，在 Apple 的平台上），用于动态地查询通过 malloc、calloc、realloc 等函数分配的内存块的实际大小。
    • 上下文：它通常用于调试或优化内存使用，当你需要知道实际分配了多少内存时。
    • 结果：返回的是实际分配的内存块大小（以字节为单位），这可能包括由于内存对齐或内存管理系统的内部需求而额外分配的内存。
    • 示例：如果你使用 malloc(100) 分配了内存，并将返回的指针存储在 void* ptr 中，那么 malloc_size(ptr) 可能会返回一个大于或等于100的数，具体取决于实际的内存分配策略。
  3. sizeof:
    • 用途：sizeof 是一个C和C++语言中的操作符，用于在编译时确定一个数据类型或对象在内存中所占的字节数。
    • 上下文：它通常用于静态地了解一个类型或变量需要多少内存。
    • 结果：返回的是数据类型或对象在内存中的大小（以字节为单位）。
    • 示例：sizeof(int) 会返回 int 类型在当前系统/编译器下所占的字节数。

总的来说，这三个函数或操作符都用于获取内存大小，但它们的上下文和用途各不相同。sizeof 是编译时的操作符，用于静态地了解类型或对象的大小；malloc_size 是用于查询动态内存分配大小的运行时函数；而 class_getInstanceSize 是特定于 Objective-C 的运行时函数，用于获取类的实例大小。

instance对象，class对象，mate-class对象的区别与关系? 在内存中各自存储哪些信息

在Objective-C中，instance对象（实例对象）、class对象（类对象）和meta-class对象（元类对象）构成了类与对象的层次结构。以下是这三者之间的区别、关系以及它们在内存中存储的信息：

区别与关系：

  1. Instance对象（实例对象）：
    • 是通过类的alloc方法创建的具体对象实例。
    • 每次调用alloc都会生成一个新的instance对象。
    • 每个instance对象在内存中占据独立的空间。
  2. Class对象（类对象）：
    • 代表一个类的结构和行为。
    • 在内存中每个类只有一个对应的class对象。
    • 负责管理类的所有实例对象共有的方法和属性。
  3. Meta-Class对象（元类对象）：
    • 是Class对象的类，也就是说，它是用来描述Class对象的。
    • 每个类在内存中也只有一个meta-class对象。
    • 主要用于实现类的继承体系和动态方法解析等高级功能。

关系：

  • Instance对象的isa指针指向其对应的Class对象。
  • Class对象的isa指针指向其对应的Meta-Class对象。
  • 当调用实例方法时，通过Instance的isa指针找到Class，进而找到方法实现。
  • 当调用类方法时，通过Class的isa指针找到Meta-Class，进而找到类方法的实现。

在内存中存储的信息：

  1. Instance对象：
    • isa指针：指向该对象的Class对象。
    • 其他成员变量：存储对象的具体数据。
  2. Class对象：
    • isa指针：指向该类的Meta-Class对象。
    • superclass指针：指向父类的Class对象（如果有的话）。
    • 类的属性信息（@property）：包括属性的名称、类型和内存管理策略等。
    • 类的对象方法信息（instance method）：实例方法列表。
    • 类的协议信息（protocol）：该类遵循的协议列表。
    • 类的成员变量信息（ivar）：成员变量的类型、名称等，但不保存成员变量的具体值（这些值存储在instance对象中）。
  3. Meta-Class对象：
    • 结构与Class对象类似，但主要用于类方法的存储和动态解析。
    • 它也有自己的isa指针，通常指向一个全局的根元类。
    • 存储类方法的实现等高级信息。

总的来说，这三者在Objective-C的运行时环境中起着不同的作用，并相互关联，共同构成了Objective-C的面向对象编程基础。

-(Class)class ，+ (Class)class，object_getClass(id _Nullable obj) 的区别

在 Objective-C 中，-(Class)class，+ (Class)class 和 object_getClass(id obj) 都与获取对象的类信息有关，但它们之间有一些重要的区别。

  1. -(Class)class

-(Class)class 是一个实例方法，这意味着你需要一个类的实例（对象）来调用它。当你调用这个方法时，它会返回该实例所属的类对象。例如：

MyClass *myObject = [[MyClass alloc] init];
Class instanceClass = [myObject class]; // 使用实例方法获取类对象
  1. + (Class)class

+ (Class)class 是一个类方法，你可以直接在类上调用它，而不需要类的实例。这个方法同样返回类对象。在 Objective-C 中，你通常不需要直接调用这个方法，因为类名本身就可以作为类对象的引用。但是，在某些动态编程场景中，这个方法可能会很有用。例如：

Class classObject = [MyClass class]; // 使用类方法获取类对象

实际上，+ (Class)class 方法在大多数情况下是编译器自动添加的，以便与实例方法 -(Class)class 保持一致性。在 Objective-C 运行时中，类本身就是一个对象，因此 + (Class)class 通常就返回类自身。

  1. object_getClass(id obj)

object_getClass 是一个 Objective-C 运行时函数，它接受一个对象（id 类型）作为参数，并返回该对象的类对象。这个函数在底层实现上与 -(Class)class 方法类似，但它是一个 C 函数，而不是一个 Objective-C 方法。例如：

MyClass *myObject = [[MyClass alloc] init];
Class instanceClass = object_getClass(myObject); // 使用运行时函数获取类对象

区别总结：

  • -(Class)class 是实例方法，需要通过类的实例来调用。
  • + (Class)class 是类方法，可以直接在类上调用，返回类对象本身。
  • object_getClass(id obj) 是一个运行时函数，接受一个对象作为参数，并返回该对象的类对象。

在实际编程中，你通常会使用实例方法 -(Class)class 或运行时函数 object_getClass 来动态地获取对象的类信息。而类方法 + (Class)class 则较少直接使用，除非在某些特定的动态编程或元编程场景中。

怎么判断一个Class对象是否为meta-class？

在Objective-C中，判断一个Class对象是否为meta-class并没有直接的API。但是，可以利用Objective-C的运行时特性和类结构来间接判断。

Objective-C的类是由objc_class结构体表示的，这个结构体中有一个指向meta-class的指针（通常是ISA或者isa）。每个类都有一个与之关联的meta-class，而meta-class也有自己的isa指针，通常指向一个全局的根meta-class。

要判断一个Class对象是否为meta-class，可以检查其isa指针是否指向一个全局的根meta-class或者检查它是否满足meta-class的其他特性。然而，这种方法依赖于Objective-C运行时的内部实现细节，这些细节可能在不同版本的Objective-C或不同平台上有所不同。

一种更简单且更稳定的方法是使用Objective-C的运行时函数object_getClass。对于一个普通的类对象，当你调用object_getClass时，它会返回该类本身（因为类在Objective-C中本身也是一个对象）。但是，对于一个meta-class对象，object_getClass会返回meta-class的meta-class（也就是根meta-class或者叫做MetaClass类）。

基于这个原理，你可以使用以下方法来检查一个Class对象是否为meta-class：

BOOL isMetaClass(Class cls) {
    return object_getClass(cls) != cls;
}

这个方法基于这样一个事实：对于一个普通的类，object_getClass(cls)将返回cls本身，因为类的isa指针指向它自己。而对于meta-class，object_getClass(cls)将返回它的meta-class，即根meta-class，这不可能与cls相同。

请注意，这种方法依赖于Objective-C运行时的具体实现，并且在未来的版本中可能会有所变化。因此，在使用之前，请确保你理解了这一点，并在可能的情况下避免依赖此类实现细节。

此外，如果你只是想判断一个给定的对象是类对象还是实例对象，你可以使用class_isMetaClass函数（如果可用）：

BOOL class_isMetaClass(Class cls);

这个函数会返回一个布尔值，指示给定的Class对象是否是一个meta-class。这个函数是Objective-C运行时的一部分，但并非所有平台或版本的Objective-C都提供这个函数，因此在使用前需要检查其可用性。

isa指针和superClass指针分别是如何指向的？

在Objective-C中，每个对象（包括类对象和元类对象）都有一个isa指针，而类对象还有一个superClass指针。这两个指针在Objective-C的对象模型中起着关键作用，并且它们的指向规则如下：

  1. isa指针：

    • 对于实例对象（instance object），isa指针指向该对象的类对象（Class object）。这意味着如果你有一个实例对象，你可以通过它的isa指针找到它所属的类。

    • 对于类对象（Class object），isa指针指向该类的元类对象（Meta-Class object）。类对象是描述如何创建实例的，而元类对象是描述如何创建类对象的。

    • 对于元类对象（Meta-Class object），isa指针通常指向一个根元类（root meta-class），这是一个特殊的元类，它管理所有元类的行为。在某些实现中，根元类的isa指针可能指向它自己。

  2. superClass指针：

    • superClass指针只存在于类对象中，它指向该类继承的父类对象。如果一个类没有显示的父类（即它不是从其他类继承的），则它的superClass指针通常指向NSObject类，因为NSObject是Objective-C类层次结构中的根类。

    • 对于NSObject类本身，其superClass指针为nil，因为它没有父类。

    • 元类对象没有superClass指针，因为它们不是通过继承关系来组织的。但是，元类会隐式地继承其对应类的方法，并且元类的元类（即根元类）会继承自NSObject的元类。

这里是一个简化的示意图来说明isa和superClass指针的指向：

实例对象1 ----isa----> 类对象A ----isa----> 元类对象A ----isa----> 根元类
                  |
                  |----superClass----> 类对象B (如果有的话) ... 最终指向 NSObject 类对象

在这个示意图中，实例对象1的isa指向类对象A，类对象A的isa指向元类对象A，而元类对象A的isa指向根元类。同时，类对象A的superClass指向其父类对象B（如果存在的话），这个链最终会指向NSObject类对象，因为NSObject是Objective-C类层次结构的根。需要注意的是，不是所有的类都有父类，除了NSObject自身。

2、OC之类原理 ，iOS 类与对象原理

类对象的结构，isa，superclass，cache，bits。

在Objective-C中，类对象的结构是核心组成部分，它定义了类的行为和属性。以下是对类对象结构的详细解释，特别是isa、superclass、cache和bits这几个关键部分：

  1. isa指针：
    • 每个对象（包括类对象和元类对象）都有一个isa指针。
    • 对于实例对象，isa指针指向其类对象。
    • 对于类对象，isa指针指向其元类对象。
    • isa指针用于动态地确定对象的类型，并在运行时查找和调用方法。
  2. superclass指针：
    • superclass指针仅存在于类对象中，指向该类继承的父类对象。
    • 这建立了Objective-C中的类继承关系，使得子类可以继承父类的属性和方法。
    • 如果一个类没有显式声明的父类，则默认继承自NSObject类，而NSObject的superclass指针为nil，因为它没有父类。
  3. cache：
    • cache是用于方法调用的快速查找表。
    • 当一个方法被调用时，Objective-C运行时首先会在cache中查找该方法，以提高方法调用的效率。
    • 如果cache中没有找到对应的方法，运行时会在类的方法列表或父类的方法列表中继续查找。
  4. bits：
    • bits包含了类的元数据和其他信息，如类的属性、协议、实例变量等。
    • 在iOS的某些版本中，bits可能包含如类的版本信息、实例大小、成员变量列表、方法列表、协议列表等。
    • 这些信息对于运行时的类型检查、方法调用和反射等操作至关重要。

综上所述，Objective-C的类对象结构通过isa、superclass、cache和bits等关键组件来定义类的身份、继承关系、方法缓存和元数据，从而支持Objective-C的动态特性和面向对象编程范式。这些组件在运行时协同工作，使得Objective-C程序能够高效地执行方法调用、类型识别和对象管理等操作。

什么是联合体(共用体)，什么是位域，isa包含哪些信息，怎么获取isa指针地址

联合体(共用体)

联合体（Union），也称为共用体，是一种特殊的数据类型，它允许在相同的内存位置存储不同的数据类型。联合体定义了一个特殊的变量，该变量可以包含多种类型的数据，但一次只能使用其中一种类型的数据。联合体的特点是其成员共享同一块内存空间，因此联合体的大小至少是其最大成员的大小。通过联合体，程序员可以在同一内存块中以不同的类型来存储和访问数据，从而实现内存的高效使用。

位域

位域是把一个字节中的二进制位划分为几个不同的区域，并说明每个区域的位数。每个区域都有一个域名，允许在程序中按域名进行操作。这样就可以把几个不同的对象用一个字节的二进制位来表示，从而节省存储空间。位域通常用于需要紧凑数据表示或特定于硬件的操作，如设置硬件寄存器。

isa指针

在Objective-C中，isa指针是一个关键组成部分，它存在于每个对象和类结构中。isa指针包含以下信息：

  1. 对象的类信息：对于实例对象，isa指针指向该对象所属的类。这允许运行时系统确定对象的类型并正确地调用其方法。
  2. 类的元类信息：对于类对象，isa指针指向该类的元类。元类负责存储类方法的列表，并管理类的行为。
  3. 继承关系：通过isa指针和superClass指针的结合使用，可以追踪对象的继承关系，从而实现多态和动态绑定等面向对象特性。

获取isa指针地址

在Objective-C中，通常不需要直接获取isa指针的地址，因为运行时系统已经提供了访问和操作对象和类的方法。然而，如果你确实需要访问isa指针，可以通过Objective-C的运行时函数来实现。例如，使用object_getClass()函数可以获取一个对象的类，这实际上是通过查询对象的isa指针来实现的。但请注意，直接操作isa指针是低级别的操作，通常不推荐在应用程序代码中进行此类操作，除非有特定的需求和理解相关风险。

综上所述，联合体(共用体)是一种高效使用内存的数据结构，位域是字节级别数据紧凑表示的方法，而isa指针是Objective-C中用于确定对象类型和管理对象行为的关键组件。

class_rw_t，class_ro_t分别包含哪些信息，为什么这么设计

class_rw_t和class_ro_t是Objective-C运行时中两个重要的结构体，它们分别包含了类的可读写信息和只读信息。下面将分别介绍这两个结构体的内容和设计原因。

class_rw_t

class_rw_t代表类的可读写部分，主要包含以下信息：

  1. flags：标志位，用于存储类的某些特定状态或属性。
  2. version：版本信息，有助于在运行时检查类的版本兼容性。
  3. ro：一个指向class_ro_t结构体的指针，该结构体存储了类的只读信息。
  4. methods：方法列表，这是一个二维数组，包含了类的实例方法和类方法。这些方法可以在运行时动态添加、修改或删除，因此是可读写的。
  5. properties：属性列表，记录了类的所有属性。这些属性也可以在运行时进行更改，因此也是可读写的。
  6. protocols：协议列表，记录了类所遵循的所有协议。这些协议同样可以在运行时进行更改。
  7. firstSubclass 和 nextSiblingClass：用于支持类的继承层次结构和类列表的遍历。

设计原因：

  • class_rw_t的设计允许在运行时动态地修改类的行为。这对于Objective-C这种动态语言来说是非常重要的，因为它支持在运行时添加、修改或删除方法和属性等。
  • 通过将可读写的部分与只读的部分分开存储，可以提高类的灵活性和可扩展性。

class_ro_t

class_ro_t代表类的只读部分，主要包含以下信息：

  1. flags：标志位，用于标识类的特定属性或状态（与class_rw_t中的flags不同）。
  2. instanceStart、instanceSize 和 reserved：这些字段与类的实例内存布局相关。
  3. ivarLayout 和 weakIvarLayout：与实例变量的内存布局有关的信息。
  4. name：类的名称，这是一个只读属性，不能在运行时更改。
  5. baseMethodList：类的初始方法列表，这是编译时确定的，不可更改。
  6. baseProtocols：类所遵循的初始协议列表，同样是编译时确定的。
  7. ivars 和 baseProperties：分别记录了类的实例变量和初始属性列表。

设计原因：

  • class_ro_t的设计保证了类的某些核心信息在运行时不会被修改，从而确保了类的稳定性和一致性。这些信息通常在编译时就已经确定，并且不应该在运行时更改。
  • 通过将只读信息与可读写信息分开存储，可以更有效地管理类的内存布局和访问权限。
  • 这种分离的设计也简化了运行时对类的操作和管理，提高了系统的安全性和可靠性。

method_t包含哪些信息，存储在什么位置，分类添加同名方法时会执行哪个

method_t是Objective-C中用于描述方法的数据结构。以下是关于method_t的详细解答：

method_t包含的信息

method_t结构体主要包含以下信息：

  1. name (SEL): 表示方法的名称，即选择子（selector）。它是一个用于唯一标识某个方法的key。需要注意的是，即使方法的参数类型不同，只要方法名相同，它们的SEL也是相同的。
  2. types: 这个字段包含了方法的返回值类型和参数类型的信息。它是以字符串形式表示的，可以通过苹果官方文档中的Type Encodings来解读。
  3. imp (IMP): 这是一个函数指针，指向方法的实际实现。当通过消息机制调用一个方法时，最终会跳转到这个指针所指向的函数地址执行。

method_t的存储位置

method_t结构体实例通常存储在类的方法列表中。每个类都有一个方法列表，它包含了该类及其父类定义的所有方法。这个方法列表是存储在类的数据结构中的，具体来说，是存储在class_rw_t或class_ro_t结构体中的methods字段里（取决于方法的可读写性）。

分类添加同名方法时的执行

当在Objective-C的分类（Category）中添加与原有类中同名的方法时，会执行分类中的方法，而不是原有类中的方法。这是Objective-C的一个特性，允许开发者通过分类来覆盖或扩展原有类的行为。具体来说：

  1. 同名方法的覆盖：如果在分类中添加了一个与原有类中同名的方法，那么分类中的方法会“覆盖”原有类中的方法。这意味着，当调用该方法时，会执行分类中的实现，而不是原有类中的实现。
  2. 调用顺序：如果有多个分类都添加了同名的方法，那么哪个方法会被调用取决于编译器。通常情况下，会调用最后一个参与编译的分类中的方法。但这不是一个可靠的行为，因此最好避免在多个分类中添加同名方法。
  3. 注意事项：虽然分类允许我们添加新的方法和覆盖原有方法，但它们不能用于添加新的实例变量。此外，在使用分类覆盖方法时应该谨慎，因为这可能会改变原有类的行为，导致不可预见的副作用。

综上所述，method_t是Objective-C中描述方法的关键数据结构，它包含了方法的名称、类型信息和实现指针。当在分类中添加同名方法时，会执行分类中的方法实现，从而允许开发者在不修改原有类代码的情况下扩展或修改类的行为。

property 和 ivars有什么区别，为什么说分类不能添加属性

property和ivars的区别，以及为什么说分类不能添加属性，可以归纳为以下几点：

一、property和ivars的区别

  1. 定义与性质：
    • ivars（实例变量）：是在类的声明中定义的变量，用于存储对象的状态信息。它们通常是私有的，只能在类的内部访问。可以直接访问和修改，不需要使用访问器方法。
    • property（属性）：是对ivars的封装，提供了一种更加简洁和安全的方式来访问和修改对象的状态。属性可以通过使用@property关键字来声明，它是对外公开的，可以通过点语法或者setter和getter方法进行访问和修改。
  2. 访问方式：
    • ivars：可以直接访问和修改，不需要额外的访问器方法。
    • property：通常通过getter和setter方法来访问，这些方法可以提供对变量访问的额外控制，如数据验证或触发其他操作。
  3. 内存管理和线程安全性：
    • ivars：不涉及额外的内存管理或线程安全控制，需要开发者自行管理。
    • property：可以具有不同的修饰符，如nonatomic、strong、weak等，这些修饰符用于控制属性的内存管理和线程安全性。

二、为什么说分类不能添加属性

在Objective-C中，当我们尝试在分类中添加属性时，会遇到一些限制。具体来说：

  1. 编译器的限制：虽然我们可以在分类中声明属性，但编译器并不会像在原始类中那样自动生成对应的实例变量（ivars）。这意味着，尽管我们声明了属性，但并没有实际的存储空间与之关联。

  2. 运行时行为：由于缺少自动生成的实例变量，当我们在代码中尝试访问或修改这些属性时，程序会在运行时出错，因为它找不到与属性对应的实例变量来存储或检索值。

  3. 解决方案：为了在分类中添加属性，开发者通常需要使用Objective-C的运行时特性，如关联对象（Associated Objects），来手动为属性提供存储空间。这种方法相对复杂，且需要额外的内存管理考虑。

综上所述，虽然property和ivars都是用于存储对象状态的机制，但它们在定义、访问方式和内存管理方面存在显著差异。同时，由于编译器的限制和运行时行为的特点，我们通常认为在Objective-C的分类中不能直接添加属性。

isKindOfClass 和 isMemberOfClass的区别

isKindOfClass和isMemberOfClass的区别主要体现在它们判断对象类型的方式上。以下是二者的主要区别：

  1. 判断范围：
    • isKindOfClass：这个方法用于判断一个对象是否是一个已知类的实例，或者是这个类的子类的实例。也就是说，它会考虑类的继承关系，如果对象是给定类或其子类的实例，该方法会返回YES。
    • isMemberOfClass：这个方法用于判断一个对象是否直接是一个已知类的实例，而不考虑继承关系。只有当对象是给定类的直接实例时（即不是子类的实例），该方法才会返回YES。
  2. 继承关系的处理：
    • isKindOfClass：对继承关系敏感，会返回YES如果对象是给定类或其任何子类的实例。
    • isMemberOfClass：对继承关系不敏感，只关注对象是否直接属于指定的类。
  3. 使用场景：
    • isKindOfClass：当你想要检查一个对象是否属于一个更广泛的类别或继承体系中的某个类时，这个方法很有用。例如，你可能想要检查一个对象是否是UIView或其任何子类的实例。
    • isMemberOfClass：当你需要确保一个对象是特定类的直接实例，而不是其任何子类时，这个方法更为适用。

总的来说，isKindOfClass和isMemberOfClass的主要区别在于它们处理对象和类之间关系的方式不同。isKindOfClass更加宽泛，考虑了类的继承关系；而isMemberOfClass则更为严格，只关注对象是否直接属于指定的类。在选择使用哪个方法时，应根据具体需求和上下文来判断。

objc_getClass,object_getClass，objc_getMetaClass区别

objc_getClass、object_getClass和objc_getMetaClass这三个方法在Objective-C的运行时系统中扮演着重要的角色，它们之间的区别主要体现在用途和返回的对象类型上。以下是对这三个方法的详细比较和归纳：

一、objc_getClass

  • 用途：此方法用于根据提供的类名（以字符串形式）获取对应的类对象。
  • 返回值：返回与指定类名相对应的类对象。如果找不到对应的类，则行为是未定义的。
  • 示例：Class cls = objc_getClass("MyClass");

二、object_getClass

  • 用途：此方法用于获取一个Objective-C对象的类。
  • 返回值：返回参数对象的类对象。如果对象是nil，则返回nil。
  • 示例：Class cls = object_getClass(myObject);
  • 注意：这个方法与调用对象的-class方法效果相同，但它是通过运行时函数直接获取，不依赖于Objective-C的消息机制。

三、objc_getMetaClass

  • 用途：此方法用于获取一个类的元类（MetaClass）。在Objective-C中，每个类都有一个与之关联的元类，元类用于存储类的静态方法等信息。
  • 返回值：返回指定类的元类对象。
  • 示例：Class metaClass = objc_getMetaClass("MyClass");

归纳：

  1. 用途不同：objc_getClass通过类名获取类对象；object_getClass通过对象获取其类对象；objc_getMetaClass获取类的元类对象。
  2. 返回值类型：三者都返回Class类型的对象，但具体含义不同。objc_getClass返回的是与类名对应的类对象；object_getClass返回的是参数对象的类对象；objc_getMetaClass返回的是指定类的元类对象。
  3. 使用场景：在运行时动态地查询或操作类和对象时，这些方法非常有用。例如，你可能需要在不知道具体类型的情况下，动态地创建对象、调用方法或访问属性等。

请注意，在使用这些方法时要谨慎处理返回的类对象或元类对象，确保正确使用并避免引入潜在的错误或内存泄漏等问题。

方法缓存cache_t是怎么存储的，hash计算与buckets扩容实现方式

在Objective-C的运行时中，cache_t是用于缓存方法的数据结构，它的主要目的是为了加速方法的查找过程。当一个对象收到一个消息时，Objective-C的运行时会首先在cache_t中查找该方法，如果没有找到，才会去类的方法列表、父类的方法列表或者通过动态解析来查找。

关于cache_t的存储、hash计算和buckets扩容的实现方式，虽然具体的实现细节可能会因Objective-C运行时的不同版本而有所差异，但以下是一些基本的概念和实现思路：

存储方式

cache_t通常是一个哈希表（hash table），也被称为散列表。它使用键值对（key-value pair）的方式来存储数据，其中键是方法的选择子（SEL），值是对应的方法实现（IMP）。

Hash计算

哈希表的性能在很大程度上取决于哈希函数的设计。在Objective-C的运行时中，哈希函数将选择子（SEL）作为输入，并输出一个哈希值，这个哈希值用于确定选择子在哈希表中的位置。

哈希函数的设计需要满足以下几点：

  1. 均匀分布：哈希函数应该尽可能地将输入均匀地映射到输出空间，以减少冲突。
  2. 高效性：哈希函数的计算应该尽可能快。
  3. 确定性：对于相同的输入，哈希函数应该总是产生相同的输出。

具体的哈希算法可能因实现而异，但常见的做法是使用选择子的字符串表示（如方法名）进行某种形式的散列计算。

Buckets扩容

当哈希表中的元素数量增加到一定程度时，为了减少冲突和提高查找效率，可能需要对哈希表进行扩容。扩容通常涉及以下几个步骤：

  1. 分配新的内存空间：为新的、更大的哈希表分配内存空间。
  2. 重新哈希：将所有现有的键值对重新插入到新的哈希表中。这通常涉及使用哈希函数重新计算每个键的哈希值，并将其插入到新的位置。
  3. 释放旧的空间：释放原来哈希表占用的内存空间。
  4. 更新引用：将原来的哈希表引用更新为新的哈希表。

具体的扩容策略和时机可能因实现而异，但通常会在装载因子（即哈希表中元素的数量与桶（bucket）数量的比率）达到一定阈值时触发扩容。

需要注意的是，以上描述是基于一般的哈希表和Objective-C运行时可能采用的策略。实际的Objective-C运行时实现可能会有所不同，并且可能包含额外的优化和特性。如果你对某个特定版本的Objective-C运行时的实现感兴趣，建议查看其源代码或相关文档以获取更详细的信息。

new与alloc/init的区别？

在Objective-C（OC）中，new、alloc和init都是用于创建和初始化对象的方法，但它们之间存在一些关键的区别。

  1. new:
    • new是C++中的一个操作符，但在Objective-C中并不常用。在Objective-C中，如果你看到new，它可能是通过某些桥接技术（如Objective-C++）与C++代码交互时使用的。
    • 在C++中，new用于动态分配内存并调用构造函数来初始化对象。
    • 在纯Objective-C环境中，你几乎不会看到new的使用。
  2. alloc/init:
    • 这是Objective-C中创建和初始化对象的传统方式。
    • alloc：这个方法用于在堆上动态分配内存。它返回一个尚未初始化的对象。alloc只是分配了内存，但并没有对对象进行任何初始化操作。
    • init：这个方法用于初始化通过alloc分配的对象。通常，你会在调用alloc后立即调用一个init方法来设置对象的初始状态。
    • Objective-C中常见的做法是链式调用这两个方法，如：MyObject *obj = [[MyObject alloc] init];。这种方式首先使用alloc分配内存，然后立即调用init进行初始化。
  3. 便捷构造器：
    • 除了alloc和init之外，许多类还提供了便捷构造器方法，这些方法通常以类名开头，后跟With和某些描述性的词，如NSString类的stringWithFormat:。这些便捷构造器内部通常会调用alloc和init（或其变种），从而允许你以一种更简洁、更语义化的方式来创建和初始化对象。
  4. 注意事项：
    • 当你使用alloc和init（或它们的变种）时，务必确保你正确地管理了对象的生命周期。由于这些方法是动态分配内存的，因此你需要负责在不再需要对象时释放其内存（在非ARC环境中）。
    • 在使用便捷构造器时，通常不需要担心内存管理问题，因为这些方法通常会返回一个自动释放的对象（在ARC环境中）或已经正确管理了内存的对象（在非ARC环境中）。

总的来说，new在Objective-C中并不常用，而alloc和init（或其变种）以及便捷构造器是创建和初始化对象的常用方法。

3、OC分类Category原理

Category底层结构是怎么样的

Category的底层结构在Objective-C中是通过特定的数据结构来实现的。以下是关于Category底层结构的详细解释：

一、Category的数据结构

在Objective-C的运行时中，Category被表示为一个名为category_t的结构体。这个结构体包含了与Category相关的信息，如类名、实例方法列表、类方法列表、协议列表以及属性列表等。

具体来说，category_t结构体大致包含以下成员：

  1. name：表示Category的名称。
  2. cls：指向所扩展的类的指针。
  3. instance_methods：一个指向method_list_t结构体的指针，该结构体包含了Category中定义的实例方法列表。
  4. class_methods：一个指向method_list_t结构体的指针，包含了Category中定义的类方法列表。
  5. protocols：指向protocol_list_t结构体的指针，列出了Category所遵循的协议。
  6. properties：指向prop_list_t结构体的指针，包含了Category中定义的属性列表。

二、Category方法的添加

当编译器编译包含Category的代码时，它会将Category的方法添加到类的原始方法列表中。这个过程是在运行时发生的，具体步骤如下：

  1. 编译器将Category编译成上述的category_t结构体。
  2. 在程序加载时，Objective-C运行时库会处理这些category_t结构体，并将其中的方法、属性和协议合并到原始的类中。
  3. 合并过程中，Category的方法会被添加到类的方法列表的前面，这意味着如果Category中的方法与原始类中的方法重名，那么Category中的方法将优先被调用（即“覆盖”原始方法）。但请注意，这并不是真正的替换，而是方法查找顺序的结果。

三、关联属性的实现

由于Category不能直接添加实例变量（即属性），开发者通常使用Objective-C运行时的关联对象功能来为Category添加属性。这通过objc_setAssociatedObject函数实现，它允许你将一个对象与另一个对象关联起来，并可以存储额外的值。

综上所述，Category的底层结构是通过category_t结构体来表示的，它包含了Category的所有信息。在运行时，这些信息被合并到原始的类中，从而扩展了类的功能。同时，通过使用关联对象技术，我们还可以在Category中添加额外的“属性”。

为什么说不能添加属性？

Category不能添加属性的原因主要有以下几点：

  1. 编译时特性：
    • Objective-C的属性是在编译时由编译器处理的。当在类中声明一个属性时，编译器会自动生成相应的实例变量（通常在.m文件中以_为前缀）以及getter和setter方法。这个过程在编译期间完成。
    • 相比之下，Category是在运行时加载的，这意味着编译器在编译时无法为Category中的属性生成实例变量和相应的访问方法。
  2. 内存布局：
    • 类的内存布局在编译时确定，包括所有实例变量的位置和大小。这个布局是固定的，以确保在运行时能够准确地访问这些变量。
    • 如果在运行时通过Category添加属性，这将需要额外的实例变量来存储属性的值。然而，这将会破坏原有类的内存布局，因为编译器没有为这些新变量分配空间。这种破坏可能导致内存访问错误或其他不可预测的行为。
  3. 动态特性：
    • Objective-C的运行时允许动态地添加方法，因为方法的添加不会影响到对象的内存布局。方法的实现可以存储在类的外部，并通过消息派发机制动态调用。
    • 但是，属性的添加涉及到实例变量的创建，这是在运行时无法动态改变的。因此，虽然可以动态地添加方法，但不能以相同的方式动态地添加属性。

综上所述，由于编译时的限制、内存布局的固定性以及Objective-C的动态特性，Category不能被用来添加属性。开发者通常使用其他技术（如关联对象）来在Category中实现类似属性的功能。

Category加载过程？同名方法如何处理？

Category的加载过程以及同名方法的处理方式可以归纳如下：

Category的加载过程：

  1. 编译阶段：
    • 编译器会解析出Category中的实例方法列表、属性列表等信息，并将这些信息保存在一个Category对象结构体中。
    • 编译器在可执行文件中为这些Category对象保存一个数组，以便在运行时加载。
  2. 运行时加载：
    • 当Objective-C程序运行时，runtime会加载之前提到的数组中保存的Category对象。
    • Category中的实例方法、协议以及属性会被添加到原有的类上。
    • Category中的类方法和协议则会被添加到类的metaclass（元类）上。

同名方法的处理：

  • 如果Category中存在与原有类中的同名方法，Category的方法并不会替换掉类中原有的方法。
  • 相反，Category中的方法会被插入到方法列表的前面，这意味着在运行时，当调用该方法时，会首先找到并执行Category中的方法，从而“覆盖”了原有类中的同名方法。
  • 这种“覆盖”并不是真正的替换，而是由于方法查找顺序导致的。runtime在查找方法时会从前往后查找，找到第一个匹配的方法就执行，因此Category中的方法会优先被执行。

需要注意的是，如果同一个类被多个Category扩展，并且这些Category中存在同名的方法，那么后编译的Category中的方法会覆盖先编译的Category中的同名方法。这是因为后编译的Category中的方法会被添加到方法列表的更前面。

load方法和initialize的区别？

load方法和initialize方法的主要区别体现在以下几个方面：

  1. 调用时机：
    • load方法：在应用程序启动后，执行main方法前，就会执行所有类的加载，并执行每个类的load方法。也就是说，load方法在程序运行之初就被调用，非常早。
    • initialize方法：这个方法在第一次给某个类发送消息时调用（比如实例化一个对象），并且这个方法在整个应用程序生命周期内只会被调用一次。这是一种惰性调用，如果类一直没被用到，那它的initialize方法也不会被调用。
  2. 继承关系中的调用：
    • 对于load方法，在子类执行时，系统会自动执行父类的load方法。
    • 对于initialize方法，如果一个子类没有重写此方法，调用子类的initialize也会触发父类的initialize方法。但如果子类重写了该方法，则父类的方法不会被自动调用，需要显式地在子类的initialize中调用[super initialize]。
  3. 用途：
    • load方法通常用于进行方法的动态替换（Method Swizzle）。
    • initialize方法一般用于初始化全局变量或静态变量。
  4. 类别与类中的方法执行：
    • 在类别(Category)中，如果实现了load和initialize方法，那么类别和原有类中的load方法都会被执行。
    • 但对于initialize方法，只会执行类别中的方法，原有类中的initialize方法不会被执行。

综上所述，load和initialize方法虽然都是Objective-C类的特殊方法，在类加载和初始化过程中起着重要作用，但它们在调用时机、继承关系中的行为、用途以及在类别中的表现等方面存在显著差异。

怎么添加成员变量？

在Objective-C中，由于Category的底层限制，无法直接给Category添加成员变量（即实例变量）。Category主要用于向已有的类添加新的方法，而不是用于添加状态（成员变量）。

如果你需要在Category中存储额外的状态，可以使用以下几种常见的方法：

  1. 使用关联对象（Associated Objects）： Objective-C的运行时库提供了objc_setAssociatedObject和objc_getAssociatedObject函数，允许你将任意对象关联到另一个对象上。这种方法常被用来在Category中添加“属性”。

    示例代码：

    static const char kAssociatedObjectKey = 0;

- (void)setMyObject:(id)object {
    objc_setAssociatedObject(self, &kAssociatedObjectKey, object, OBJC_ASSOCIATION_RETAIN_NONATOMIC);
}

- (id)myObject {
    return objc_getAssociatedObject(self, &kAssociatedObjectKey);
}

  2. 全局变量或单例： 如果你需要在多个实例之间共享状态，可以使用全局变量或单例模式来存储和管理这些状态。

  3. 使用类的属性： 如果不能直接在Category中添加成员变量，可以考虑在原始类中添加新的属性来存储所需的状态。当然，这需要你有权限修改原始类的定义。

  4. 使用协议和组合： 你可以定义一个协议，让遵循该协议的类实现必要的方法。然后，你可以通过组合的方式，将这些类的对象作为你Category所扩展对象的属性，从而间接地添加状态。

总的来说，由于Objective-C的语言限制，Category不支持直接添加成员变量。但是，通过上述方法，你可以以其他方式在Category中“添加”和管理状态。

关联对象是如何存储的？

关联对象在Objective-C中是通过特定的机制来存储的，具体可以归纳为以下几点：

  1. 全局关联对象哈希表：关联对象并不是直接存储在目标对象本身中，而是通过一个全局的关联对象哈希表来存储。这个哈希表充当了一个中央仓库，用于保存所有的关联对象。

  2. 关键字与指针：当使用objc_setAssociatedObject函数将对象关联到另一个对象时，会使用一个唯一的关键字（key）来标识这个关联。这个关键字通常是一个静态变量的地址，以确保在多个方法之间可以共享。同时，这个函数还会保存关联对象的指针到这个全局哈希表中。

  3. 查找与访问：当使用objc_getAssociatedObject函数时，Runtime会根据提供的关键字和对象在全局哈希表中查找对应的关联对象指针，并返回它。这样，即使关联对象不是直接存储在目标对象中，也可以通过这个机制来有效地访问它们。

  4. 内存管理：关联对象的内存管理是通过Objective-C的runtime库来处理的。当设置关联对象时，可以指定内存管理策略，如OBJC_ASSOCIATION_RETAIN、OBJC_ASSOCIATION_ASSIGN等，这些策略决定了关联对象的持有方式和释放时机。

  5. 移除关联对象：如果使用objc_removeAssociatedObjects函数，Runtime会从全局哈希表中删除与目标对象相关联的所有关联对象。

综上所述，关联对象是通过一个全局的关联对象哈希表来存储和管理的，这种机制允许开发者在运行时动态地将对象关联到其他对象上，而无需修改原始类的定义。

分类和扩展的区别是什么？

分类（Category）和扩展（Extension）在Objective-C中是两种用于增加类功能和特性的机制，但它们之间存在明显的区别。以下是对这两者区别的详细分析：

一、添加的内容不同：

  • 分类（Category）：主要用于向已有的类添加新的方法。通过分类，开发者可以在不修改原始类的情况下，为其添加新的功能或方法。但需要注意的是，分类不能添加新的实例变量。
  • 扩展（Extension）：则可以同时添加新的实例变量和方法。扩展通常用于为类的私有部分提供新的属性和方法，这些新的属性和方法只在类的内部实现中使用，不对外公开。

二、使用场景不同：

  • 分类（Category）：通常用于扩展系统提供的类或其他无法修改的类，以实现自定义的功能。这对于在不改变原有类代码的情况下增强其功能非常有用。
  • 扩展（Extension）：更多地用于封装类的私有数据和行为。它允许开发者在类的实现文件中定义私有的属性和方法，从而保持类的封装性和数据的隐私性。

三、声明位置不同：

  • 分类（Category）：通常在单独的文件中声明和实现，可以与其他类文件分开。这使得分类可以独立于原始类进行开发和维护。
  • 扩展（Extension）：通常在类的实现文件(.m)中声明，紧接着在@implementation指令的上方。这样的位置安排使得扩展的内容只对类的内部实现可见，外部无法直接访问。

综上所述，分类和扩展在Objective-C中各自扮演着不同的角色。分类主要用于向已存在的类添加新方法以实现功能扩展，而扩展则更多地关注于封装类的私有数据和行为。

4、OC中Block本质

block是什么？封装了函数以及函数调用环境的OC对象

Block是一个特殊的语法结构，在Objective-C（OC）中，它封装了一个函数（或者说是一段代码）以及这个函数调用的环境。以下是关于Block的详细解释：

  1. 定义与本质：
    • Block本质上是一个OC对象，它内部包含一个isa指针，这是所有OC对象的共同特征。
    • Block是将函数及其执行上下文封装起来的对象，可以看作是一种特殊的数据结构，能够存储代码以及相关的上下文信息。
  2. 结构与特性：
    • Block可以嵌套定义，其定义方法与定义函数相似。
    • Block可以捕获外部变量，这使得它在编程中非常灵活。
    • 只有当调用Block时，才会执行其中{}内的代码。
    • Block作为对象，具有高度的代码聚合性，有助于降低代码的分散程度，提高可读性。
  3. 使用场景与优势：
    • Block常用于回调和异步操作，特别是在多线程编程、网络请求以及界面交互等场景中。
    • 使用Block作为回调函数可以简化代码结构，提高代码的灵活性和可读性。
  4. 注意事项：
    • 由于Block可以捕获外部变量，如果不当地使用全局变量或强引用对象，可能会导致循环引用和内存泄漏问题。
    • 在多线程环境下使用Block时，需要注意线程安全和资源同步的问题。

综上所述，Block是一个强大的编程工具，在Objective-C中扮演着重要的角色，它封装了函数以及函数调用环境，为开发者提供了更加灵活和高效的编程方式。

block分为哪几种类型？有什么区别

在Objective-C中，block主要分为三种类型，它们分别是：

  1. _NSConcreteGlobalBlock：
    • 类型：全局静态block。
    • 特点：不会访问任何外部变量。换句话说，这种block不依赖于其定义环境外的任何变量。
    • 示例：通常，当block内部只使用全局变量，或者根本没有使用任何外部的局部变量时，该block就会被视为_NSConcreteGlobalBlock。
  2. _NSConcreteStackBlock：
    • 类型：栈block。
    • 特点：保存在栈中，当函数返回时，这个block会被销毁。它通常包含了对外部变量的引用（捕获），这些变量在block被创建时存在于栈上。
    • 注意事项：由于它位于栈上，因此其生命周期与栈帧相关，如果不正确地使用（例如，在栈帧之外访问），可能会导致未定义的行为或程序崩溃。
  3. _NSConcreteMallocBlock：
    • 类型：堆block。
    • 特点：保存在堆中，当引用计数减少到0时，这个block会被销毁。这种类型的block通常是通过将_NSConcreteStackBlock类型的block复制到堆上创建的。
    • 使用场景：当需要将block传递到函数的外部，或者在异步操作中使用block时，通常需要将其从栈复制到堆上，以确保其生命周期的正确性。

区别归纳：

  • _NSConcreteGlobalBlock 不依赖外部变量，全局且静态。
  • _NSConcreteStackBlock 依赖于栈，函数返回时销毁，通常包含外部变量的引用。
  • _NSConcreteMallocBlock 分配在堆上，生命周期由引用计数管理，通常是通过复制栈上的block创建的。

了解这些类型及其特点有助于更安全和有效地在Objective-C程序中使用block。

block变量捕获有哪些情况？auto，static，

在Objective-C中，block捕获变量主要有以下几种情况，具体可以分为自动变量（auto）和静态变量（static）的捕获。

自动变量捕获（Auto）

  1. 局部变量捕获：
    • 当block定义在一个函数内部，并且引用了该函数内部的局部变量时，这些局部变量会被block捕获。
    • 捕获的局部变量在block内部是只读的，不能在block内部修改其值。
    • 局部变量在block被定义时捕获其值，即保存的是该变量的瞬间值。此后，即使原变量的值发生改变，block内部捕获的值也不会变化。
  2. 对象变量的捕获：
    • 如果block捕获了一个对象变量，那么可以在block内部使用该对象的任何方法，但不能直接赋值给这个对象变量。
    • 可以修改对象的属性，因为这些属性本质上是通过方法来访问和修改的。

静态变量捕获（Static）

  1. 静态局部变量捕获：
    • 如果block定义在一个函数内部，并且引用了该函数内部的静态局部变量，这些静态局部变量同样会被block捕获。
    • 与自动变量不同的是，静态局部变量在程序的整个运行期间都存在，因此不存在变量被释放的问题。
    • 在block内部，可以读取和修改静态局部变量的值，并且这些修改会影响到外部变量的值。
  2. 全局静态变量的捕获：
    • 全局静态变量在程序的整个运行期间都是可用的，因此它们不需要被block捕获。block可以直接访问和修改这些变量的值。

需要注意的是，虽然block可以捕获外部变量，但并不是所有类型的变量都能被捕获。例如，C语言数组的元素就不能被block直接捕获。此外，对于被block捕获的对象变量，需要特别注意避免循环引用和内存泄漏的问题。

总的来说，block的变量捕获机制为其提供了强大的功能性和灵活性，但同时也需要程序员对捕获的变量类型和作用域有清晰的理解，以避免潜在的问题。

ARC，MRC情况下定义block使用的属性关键字有什么区别，为什么

在Objective-C中，根据内存管理方式的不同，可以分为自动引用计数（ARC，Automatic Reference Counting）和手动引用计数（MRC，Manual Reference Counting）两种情况。这两种情况下定义block时使用的属性关键字确实存在一些区别。

ARC情况下：

  • 在ARC环境下，编译器会自动管理对象的内存。当block被赋值给强指针时，编译器会自动将block从栈上拷贝到堆上，以确保其生命周期的安全。
  • 因此，在ARC下定义block属性时，可以使用strong或copy关键字。实际上，在ARC中使用strong和copy对于block来说是等效的，因为编译器会自动处理block的内存管理。
  • 通常，为了保持一致性，许多开发者在ARC环境下也习惯性地使用copy关键字来定义block属性。

MRC情况下：

  • 在MRC环境下，内存管理需要程序员手动进行。这意味着程序员需要负责对象的创建、保留、释放等操作。
  • 当定义block属性时，在MRC中应该使用copy关键字。这是因为如果不使用copy，block将不会被拷贝到堆上，而只会存在于栈上。栈上的block在其所在的作用域结束时就会被销毁，这可能导致在之后的某个时间点访问该block时出现野指针或程序崩溃的问题。
  • 使用copy属性可以确保block被拷贝到堆上，从而延长其生命周期，使其可以在定义它的作用域之外被安全地访问和使用。

总结与归纳：

  1. ARC与MRC的主要区别：ARC自动管理内存，而MRC需要手动管理。
  2. block属性的关键字选择：
    • 在ARC下，可以使用strong或copy，但通常推荐使用copy以保持一致性。
    • 在MRC下，应该使用copy以确保block被拷贝到堆上并延长其生命周期。
  3. 原因：
    • ARC的自动内存管理机制使得strong和copy在处理block时效果相同，因为编译器会负责将block从栈拷贝到堆（如果需要的话）。
    • 在MRC中，必须使用copy来手动确保block的生命周期安全，防止其被提前销毁。

ARC环境下，哪些情况编译器会根据情况自动将栈上的block复制到堆上

在ARC（Automatic Reference Counting）环境下，编译器会根据特定情况自动将栈上的block复制到堆上，以确保block在其作用域之外仍然可用。这些情况主要包括：

  1. 当block作为函数返回值返回时：如果函数返回一个block，并且这个block在函数外部需要被使用，编译器会自动将其从栈上复制到堆上。这是因为栈上的block在函数返回后可能不再有效，而将其复制到堆上可以确保它在函数外部仍然可用。
  2. 当block赋值给对象的强指针属性或在集合类中使用时：如果将block赋值给一个对象的强指针属性，或者将block存储在集合类（如NSArray、NSDictionary等）中，编译器也会自动将其复制到堆上。这是因为这些情况下，block需要在对象的生命周期内持续存在，而栈上的block无法满足这一要求。
  3. 优化后的Release构建配置下可能不会立即复制：值得注意的是，在某些情况下，特别是当编译器进行优化时（例如在Release构建配置下），可能不会立即将block从栈上复制到堆上。编译器可能会延迟这一操作，直到确实需要在堆上保持block时才进行复制。这种行为是为了提高性能，避免不必要的堆分配。

总的来说，在ARC环境下，编译器会根据block的使用情况自动判断是否需要将其从栈上复制到堆上，以确保block在其作用域之外仍然可用。这种自动管理内存的机制大大简化了开发者的内存管理工作。

block内部为什么不能修改局部变量，__block为什么能？

block内部不能修改局部变量的原因：

  1. 值传递：在block中，局部变量是以值传递的方式被捕获的。这意味着block内部实际上获得的是局部变量值的一个拷贝，而不是直接引用原始变量。因此，对拷贝值的任何修改都不会反映到原始变量上。
  2. 作用域和生命周期：局部变量的作用域仅限于定义它的函数或代码块内，并且其生命周期通常与包含它的函数或代码块的执行时间相同。当函数返回后，局部变量可能不再存在，而block可能仍然在其他地方被调用，这时访问或修改一个不存在的变量是不安全的。

__block能修改局部变量的原因：

  1. 引用传递：使用__block修饰符可以改变局部变量的传递方式。此时，block捕获的是变量的地址而不是值的拷贝。这样，block内部就可以通过这个地址直接访问和修改原始变量。
  2. 生命周期延长：当局部变量被__block修饰后，其生命周期会被延长。即使包含该变量的函数已经返回，该变量仍然会存在，直到没有任何block引用它为止。这保证了block在后续被调用时，仍然可以安全地访问和修改这个变量。

综上所述，block内部不能修改局部变量是因为值传递和作用域限制，而__block能修改局部变量是因为它实现了引用传递并延长了变量的生命周期。

__block有什么限制？__block不能修饰全局变量、静态变量（static）

__block关键字在Objective-C中用于修饰局部变量，允许这个变量在block内部被修改。然而，__block的使用确实存在一些限制，特别是关于它不能修饰的变量类型。以下是对__block限制的详细解释：

  1. 不能修饰全局变量：
    • 全局变量在整个程序运行期间都是可用的，其生命周期与程序的执行时间相同。由于全局变量本身就可以在程序的任何位置被访问和修改，因此不需要使用__block来修饰。
    • 使用__block修饰全局变量没有意义，因为全局变量的作用域和生命周期已经满足了在block内部和外部均可访问和修改的需求。
  2. 不能修饰静态变量（static）：
    • 静态变量具有文件作用域或函数作用域，但其生命周期与程序的整个运行时间相同。静态变量在程序开始时分配内存，并在程序结束时释放内存。
    • 与全局变量类似，静态变量由于其固有的生命周期和作用域特性，已经可以在block内部直接访问和修改，无需使用__block修饰。
    • 使用__block来修饰静态变量是多余的，且可能导致编译错误或不可预见的行为。

总的来说，__block主要用于修饰局部变量，允许在block中修改这些变量的值。对于全局变量和静态变量，由于它们的生命周期和作用域已经满足在block中的访问需求，因此不需要（也不能）使用__block来修饰。这些限制确保了__block的正确和有效使用，避免了潜在的编程错误和内存管理问题。

__weak, __strong分别有什么作用

__weak和__strong是Objective-C中的两种所有权修饰符，它们在iOS5后被引入，作为ARC（自动引用计数）机制的一部分。这两种修饰符的主要作用如下：

__strong的作用：

  1. 强引用：__strong表示强引用，它意味着只要引用存在，被引用的对象就不能被销毁。当一个对象被赋值给一个__strong类型的指针时，这个对象的引用计数会增加1。
  2. 内存管理：在ARC环境下，__strong修饰符帮助编译器自动管理对象的内存。当没有强引用指向一个对象时，该对象的引用计数会减少，当引用计数为0时，对象会被自动释放。
  3. 默认属性：在Objective-C中，如果没有明确指定所有权修饰符，那么指针默认是__strong类型的。

__weak的作用：

  1. 弱引用：__weak表示弱引用，它不会增加对象的引用计数。即使一个对象被__weak指针引用，当该对象的所有强引用都被移除后，它仍然会被释放。
  2. 避免循环引用：__weak的一个主要用途是避免循环引用。在复杂的对象关系中，有时两个或多个对象会相互引用，形成循环引用。这种情况下，即使没有其他对象引用它们，由于它们之间的相互引用，它们的引用计数永远不会为0，从而导致内存泄漏。使用__weak修饰符可以打破这种循环引用。
  3. 自动置nil：当__weak引用的对象被释放时，编译器会自动将__weak指针设置为nil。这个特性使得开发者可以通过检查指针是否为nil来判断对象是否仍然有效，从而增加了代码的健壮性。

总的来说，__strong和__weak是Objective-C中非常重要的所有权修饰符，它们帮助开发者更精确地控制对象的生命周期和内存管理。正确使用这些修饰符可以避免内存泄漏和其他与内存管理相关的问题。

5、OC之KVO原理

什么是KVO？KVO 是如何实现的

KVO，全称KeyValueObserving，是Objective-C中的一种观察者设计模式。它提供了一种机制，允许一个对象监听另一个对象的特定属性变化，并在属性变化时接收到通知。这种机制是Apple提供的，用于实现对象之间的解耦通信。

关于KVO的实现，可以从以下几个方面进行解释：

  1. 注册观察者：首先，需要通过调用addObserver:forKeyPath:options:context:方法来注册观察者，指定要观察的对象、属性、观察选项和上下文信息。
  2. 属性变化通知：当被观察对象的指定属性发生变化时，KVO机制会自动通知所有注册的观察者。这是通过运行时的一些底层技术实现的，包括动态子类化和isa指针的调换等。
  3. 回调方法：观察者需要实现一个回调方法来处理属性变化通知。这个方法通常是observeValueForKeyPath:ofObject:change:context:。在这个方法中，观察者可以获取到属性变化前后的值以及相关的上下文信息。
  4. 移除观察者：当不再需要观察时，应该通过调用removeObserver:forKeyPath:context:方法来移除观察者，以避免内存泄漏和其他潜在问题。

KVO的实现原理涉及到Objective-C的运行时特性，包括动态子类化、方法交换等高级技术。简单来说，当你为一个对象添加观察者时，KVO机制可能会在运行时动态地创建一个该对象的子类，并重写被观察属性的setter方法。这样，当属性发生变化时，就可以通过重写的setter方法通知所有注册的观察者。

KVO的优点在于它提供了一种简单且高效的方式来观察对象属性的变化，而无需修改被观察对象的内部代码。同时，由于KVO是Apple提供的官方机制，因此它与iOS和macOS系统的其他部分能够很好地集成。然而，KVO也有其局限性，例如它只能观察遵循KVC（键值编码）的属性变化，并且对于某些复杂的数据结构可能不够灵活。

总的来说，KVO是Objective-C中一个非常强大的功能，它允许开发者以解耦的方式监听和处理对象属性的变化。

不调用set的情况下如何触发KVO，直接用_ivar修改属性值是否触发KVO？

关于不调用set方法如何触发KVO，以及直接使用_ivar修改属性值是否会触发KVO的问题，可以从以下几个方面进行回答：

  1. 不调用set方法触发KVO：
    • 通常情况下，KVO是依赖于属性的setter方法来触发通知的。但是，如果不通过setter方法修改属性值，而是直接修改实例变量的值，KVO默认是不会被触发的。
    • 不过，有一种方法可以间接触发KVO，即使不通过setter方法。那就是在修改属性值后，手动调用willChangeValueForKey:和didChangeValueForKey:这两个方法。这两个方法分别用于在属性值改变前和改变后通知观察者，从而模拟KVO的触发。
  2. 直接使用_ivar修改属性值是否触发KVO：
    • 直接使用实例变量（_ivar）修改属性值不会触发KVO。因为KVO是基于Objective-C的运行时特性实现的，它主要通过重写属性的setter方法来工作。当你直接使用实例变量赋值时，绕过了setter方法，因此不会触发KVO的通知机制。
    • 如果你需要在直接修改实例变量后仍然能够触发KVO，你可以使用前面提到的方法，即手动调用willChangeValueForKey:和didChangeValueForKey:来通知观察者。

综上所述，不调用set方法而直接修改_ivar的值是不会自动触发KVO的，但可以通过手动调用相关方法来模拟KVO的触发。这种方法在某些特定场景下可能是有用的，但需要谨慎使用，以避免破坏KVO的完整性和一致性。

重复添加观察者，重复移除观察者会发生什么现象？

重复添加观察者和重复移除观察者时，会出现以下现象：

一、重复添加观察者

  1. 多余的内存消耗：每次添加观察者都会在系统中占用一定的资源。如果重复添加相同的观察者，将会导致不必要的内存消耗。

  2. 多次通知：当一个事件发生时，重复添加的观察者会收到多次通知，这可能导致处理逻辑被不必要地重复执行。

  3. 性能下降：由于系统中存在重复的观察者记录，当事件触发时，系统需要遍历并通知更多的观察者，这会增加处理时间，从而导致性能下降。

二、重复移除观察者

  1. 无效操作：如果尝试移除一个已经不存在的观察者，这通常是一个无效的操作。在某些实现中，这可能会引发错误或警告，但在许多系统中，这样的操作可能只是被默默地忽略。

  2. 资源浪费：虽然移除一个已经不存在的观察者可能不会产生直接的负面影响，但这样的操作本身是无效的，且可能表明代码中存在逻辑错误或冗余的调用，这代表了一种资源浪费。

  3. 潜在的逻辑错误：如果一个观察者被意外地多次移除，这可能表明代码中存在逻辑错误或管理不当。这可能导致难以追踪的问题，比如某些观察者未能正确响应事件。

为了避免上述问题，建议在添加或移除观察者时进行必要的检查，以确保每个观察者只被添加一次，且在不再需要时只被移除一次。同时，维护良好的观察者管理逻辑也是至关重要的，以确保系统的稳定性和性能。

此外，对于使用KVO（键值观察）的特定情况，还需要注意：

  • 当对一个对象添加和移除观察者时，应该保持一一对应的关系。如果移除了不存在的观察者，或者在对象销毁时没有进行适当的移除操作，都可能导致应用崩溃。
  • 从iOS 9开始，即使不移除观察者，程序也不会出现异常，但如果观察者被销毁后不移除，仍会尝试执行对应的selector，这可能会引起难以预料的崩溃。

综上所述，正确地管理观察者对于避免资源浪费、保持系统性能和稳定性至关重要。

automaticallyNotifiesObserversForKey: 和 keyPathsForValuesAffectingValueForKey:分别有什么作用

automaticallyNotifiesObserversForKey: 和 keyPathsForValuesAffectingValueForKey: 是 Objective-C KVO (Key-Value Observing) 机制中的两个重要方法，它们在 KVO 中扮演着不同的角色。

automaticallyNotifiesObserversForKey:

这个方法用于指定当某个属性的值发生变化时，是否自动通知观察者。它返回一个布尔值，表示当对应 key 的属性值变化时，是否应该自动发送 KVO 通知。

  1. 自定义通知行为：通过重写这个方法，开发者可以控制哪些属性的变化会触发 KVO 通知。默认情况下，如果一个属性的值发生变化，系统会自动发送 KVO 通知，但重写此方法可以改变这一默认行为。
  2. 性能优化：在某些情况下，为了性能考虑，开发者可能不希望每个属性变化都触发通知。通过这个方法，可以选择性地关闭某些属性的自动通知功能。
  3. 灵活性：提供了更大的灵活性，允许开发者根据应用的具体需求定制 KVO 的行为。

keyPathsForValuesAffectingValueForKey:

这个方法返回一个集合，其中包含了当某个 key 的值发生变化时，也会受到影响的其他 key 的路径。这允许开发者定义属性之间的依赖关系。

  1. 定义依赖关系：当某个属性的值依赖于其他一个或多个属性时，这个方法非常有用。例如，在一个自定义的视图中，可能有一个“需要重绘”的属性，这个属性可能在视图的大小、颜色或其他属性改变时需要被更新。通过 keyPathsForValuesAffectingValueForKey:，你可以指定这些依赖关系。
  2. 优化观察逻辑：通过明确指定哪些属性的变化会影响其他属性，开发者可以更有效地设置 KVO 观察，只在真正需要的时候接收通知。
  3. 减少冗余通知：如果没有正确设置这个方法，可能会导致大量的冗余通知，从而降低应用的性能。通过正确设置依赖关系，可以确保只在必要时接收通知。

总的来说，automaticallyNotifiesObserversForKey: 和 keyPathsForValuesAffectingValueForKey: 这两个方法共同为开发者提供了更精细的控制 KVO 通知的能力，从而优化应用的性能和响应逻辑。

AFURLRequestSerialization为什么要用automaticallyNotifiesObserversForKey关闭一些方法的自动KVO

AFURLRequestSerialization使用automaticallyNotifiesObserversForKey来关闭一些方法的自动KVO，主要基于以下几个原因：

  1. 性能优化：KVO通知涉及到一定的性能开销，因为每次属性值变化时，系统都需要发送通知给所有注册的观察者。通过关闭某些不必要或不希望被频繁触发的属性的KVO通知，AFURLRequestSerialization可以减少不必要的性能损耗。

  2. 避免不必要的回调：在某些情况下，AFURLRequestSerialization内部的状态变化并不需要外部观察者知晓。通过关闭这些属性的KVO通知，可以避免产生不必要的回调，使代码更加清晰和高效。

  3. 精确控制：通过automaticallyNotifiesObserversForKey方法，AFURLRequestSerialization可以精确控制哪些属性的变化会触发KVO通知。这有助于开发者更加精确地管理状态变化和相应的处理逻辑。

  4. 防止数据竞争和状态不一致：在多线程环境中，自动的KVO通知可能会导致数据竞争或状态不一致的问题。通过关闭某些属性的自动通知，AFURLRequestSerialization可以减少这类问题的风险。

综上所述，AFURLRequestSerialization使用automaticallyNotifiesObserversForKey关闭一些方法的自动KVO，主要是出于性能优化、避免不必要的回调、精确控制以及防止数据竞争和状态不一致的考虑。这些措施有助于提高代码的效率和稳定性，确保AFURLRequestSerialization能够在各种场景下可靠地工作。

6、OC之KVC原理

什么是KVC，常见的API有哪些

KVC，全称Key-Value Coding，即键值编码，是一种在Objective-C中通过字符串名称（即键）来间接访问对象属性的机制。它允许开发者通过键值对的方式来读取或设置对象的属性值，而无需调用特定的getter和setter方法。这种机制提供了灵活的数据访问方式，并且是实现一些高级功能如KVO（Key-Value Observing，键值观察）的基础。

关于KVC的常见API，主要包括以下几类：

  1. 访问对象属性的API：
    • valueForKey:：通过属性的名称（以字符串形式给出）来获取该属性的值。
    • valueForKeyPath:：可以用来获取嵌套对象的属性值，通过点操作符隔开的字符串序列来指定路径。
    • setValue:forKey:：设置指定属性的值。
    • setValue:forKeyPath:：设置嵌套对象属性的值。
  2. 批量赋值和取值的API：
    • dictionaryWithValuesForKeys:：用于从对象中获取多个属性的值，并以字典形式返回。
    • setValuesForKeysWithDictionary:：使用字典中的键值对来批量设置对象的属性值。

这些API提供了灵活的方式来操作对象的属性，特别是在处理动态属性或需要在运行时决定访问哪个属性时非常有用。同时，KVC也是许多Cocoa绑定和KVO等高级功能的基础。

需要注意的是，虽然KVC提供了很大的灵活性，但也要谨慎使用，以避免可能的错误和性能问题。例如，如果尝试访问一个不存在的属性，KVC会抛出异常。此外，由于KVC是基于运行时特性实现的，过度使用可能会影响性能。

setValue:forKey:方法查找顺序是什么样的

setValue:forKey:方法的查找顺序在Objective-C的KVC（Key-Value Coding）机制中是非常关键的。以下是该方法在查找属性时的顺序：

  1. 首先查找setter方法：
    • KVC会首先尝试使用名为set<Key>的setter方法来设置属性值。这里的<Key>是传入的键（key）的首字母大写的形式。例如，如果键是firstName，那么KVC会查找名为setFirstName:的方法。
  2. 查找实例变量：
    • 如果找不到对应的setter方法，KVC会继续查找与键匹配的实例变量。这个查找过程有一定的顺序：
      • 首先查找名为_<key>的实例变量（例如_firstName）。
      • 如果没有找到，接着会查找名为_is<Key>、<key>、is<Key>的实例变量。
    • 这个查找顺序是特定的，并且遵循一定的命名约定。
  3. 调用setValue:forUndefinedKey:方法：
    • 如果KVC既找不到对应的setter方法，也找不到匹配的实例变量，那么它会调用对象的setValue:forUndefinedKey:方法来处理这个未定义的键。这通常意味着开发者可以重写这个方法来处理特殊情况，或者至少能捕获到这个错误并进行适当的处理。

总的来说，setValue:forKey:方法的查找顺序是先查找setter方法，然后查找匹配的实例变量，最后如果都找不到，则调用setValue:forUndefinedKey:方法。这个顺序体现了KVC在处理属性设置时的灵活性和健壮性，允许开发者在多个层次上进行干预和处理。

valueForKey:方法的查找顺序是什么样的

valueForKey:方法的查找顺序在Objective-C的KVC（Key-Value Coding）机制中遵循一定的规则。以下是该方法在查找属性时的详细顺序：

  1. 首先查找getter方法：
    • KVC会首先尝试调用名为get<Key>、<key>或is<Key>的getter方法来获取属性值。这里的<Key>是传入的键（key）的首字母大写的形式。例如，对于键firstName，会依次查找getFirstName、firstName、isFirstName这样的方法。
  2. 查找实例变量：
    • 如果未找到匹配的getter方法，KVC会继续在对象内部查找与键匹配的实例变量。查找的顺序如下：
      • 首先查找名为_<key>的实例变量，例如_firstName。
      • 接着会查找名为_is<Key>、<key>、is<Key>的实例变量。
    • 这个顺序反映了KVC如何按照一定的命名约定来定位实例变量。
  3. 特殊处理：
    • 如果属性是集合类型（如NSArray或NSSet），KVC会查找特定的方法来获取这些集合的内容，例如countOf<Key>、objectIn<Key>AtIndex:或enumeratorOf<Key>等。
  4. 调用valueForUndefinedKey:方法：
    • 如果KVC既找不到对应的getter方法，也找不到匹配的实例变量，并且也没有集合类型的相关方法，那么它会调用对象的valueForUndefinedKey:方法来处理这个未定义的键。这提供了一个机会让开发者自定义处理逻辑或返回一个默认值。
  5. 考虑类的accessInstanceVariablesDirectly方法：
    • 在某些情况下，如果类实现了+ (BOOL)accessInstanceVariablesDirectly类方法并返回NO，则KVC不会直接访问实例变量，而是会依赖于正式的getter和setter方法。这提供了一种方式来限制对实例变量的直接访问。
  6. 自动封装和解封装：
    • 对于基本的C数据类型（如int、float等），KVC会自动进行封装和解封装操作。例如，当使用valueForKey:获取一个int类型的属性时，KVC会自动将其封装在一个NSNumber对象中返回。

总的来说，valueForKey:方法的查找顺序体现了KVC机制的灵活性和健壮性，它允许开发者通过多种方式来暴露和访问对象的属性。

accessInstanceVariablesDirectly方法有什么作用

accessInstanceVariablesDirectly是一个类方法，在Objective-C的KVC（Key-Value Coding）和KVO（Key-Value Observing）机制中起着重要作用。其作用主要体现在以下几个方面：

  1. 控制实例变量的直接访问： accessInstanceVariablesDirectly方法决定了是否允许KVC直接访问对象的实例变量。如果这个方法返回YES，则KVC在查找getter和setter方法失败后，会直接访问与键匹配的实例变量。反之，如果返回NO，KVC将不会直接访问实例变量，而是依赖于对象的getter和setter方法。

  2. 安全性和封装性的控制： 通过调整accessInstanceVariablesDirectly的返回值，开发者可以控制对对象内部状态的访问权限，从而增强代码的安全性和封装性。例如，在某些情况下，开发者可能不希望外部代码能够直接访问或修改对象的某些内部状态，此时可以通过将此方法设置为返回NO来实现。

  3. 性能考虑： 直接访问实例变量通常比调用方法更快，因为方法调用涉及到消息传递和方法的查找等开销。因此，在性能敏感的代码中，允许直接访问实例变量可能有助于提高性能。然而，这需要在代码的可读性和可维护性与性能之间做出权衡。

  4. 框架和库的设计： 对于框架或库的设计者来说，accessInstanceVariablesDirectly方法提供了一种机制来控制外部代码对其内部实现的访问。通过限制对实例变量的直接访问，框架或库可以更好地隐藏其内部实现细节，从而提供更稳定的API。

  5. 调试和测试： 在开发和调试过程中，允许直接访问实例变量可能有助于更方便地观察和修改对象的状态。然而，在生产环境中，为了代码的安全性和稳定性考虑，通常会限制这种直接访问。

综上所述，accessInstanceVariablesDirectly方法在Objective-C中提供了对实例变量访问的精细控制，开发者可以根据具体需求和上下文来合理设置此方法，以平衡代码的安全性、封装性、性能和可维护性。

7、OC内存管理

OC中内存分区从低到高是怎么样的？保留区，代码段，数据段，堆，栈，内核区

在 Objective-C (或更广泛地说，在基于 Unix 的系统中，如 macOS 或 iOS)，进程的内存布局通常遵循一种相似的结构。虽然具体的内存布局可能因操作系统和体系结构的不同而略有差异，但一般来说，一个进程的内存从低到高可以大致分为以下几个区域：

  1. 保留区（Reserved Area）：
    • 这部分内存通常保留给操作系统使用，应用程序无法直接访问。它可能包含特定的系统信息或用于特定的系统目的。
  2. 文本段（Text Segment）或代码段（Code Segment）：
    • 这是程序的二进制代码存放的地方，包括程序的指令和常量。这部分内存是只读的，以防止程序意外地修改其指令。
  3. 初始化数据段（Initialized Data Segment）：
    • 这部分包含程序中明确初始化的全局变量和静态变量。这些变量在程序启动时就具有确定的值。
  4. 未初始化数据段（Uninitialized Data Segment）：
    • 也称为 BSS（Block Started by Symbol）段，包含未初始化的全局变量和静态变量。这些变量在程序启动时被初始化为零。
  5. 堆（Heap）：
    • 堆是用于动态内存分配的区域。在 Objective-C 中，使用 malloc、calloc、realloc 或 NSMutableData 等方式分配的内存都来自堆。堆的大小在程序运行时可以动态增长。
  6. 栈（Stack）：
    • 栈用于存储局部变量、函数调用的返回地址以及执行线程的上下文。每个线程都有自己的栈。栈内存的管理是自动的，当函数调用发生时，相关数据被压入栈中，函数调用结束时，这些数据被弹出。
  7. 命令行参数和环境变量（Command Line Arguments and Environment）：
    • 这部分内存存储了程序启动时传递给它的命令行参数和环境变量。
  8. 内核区（Kernel Space）：
    • 这部分内存是操作系统内核使用的区域，对于用户空间的程序来说是不可访问的。内核负责管理硬件、提供系统服务以及执行其他底层任务。

需要注意的是，这里的“从低到高”指的是虚拟内存地址空间中的布局，而不是物理内存的布局。在现代操作系统中，虚拟内存提供了一种抽象，使得每个进程都认为自己拥有整个内存空间，而实际上操作系统和硬件会负责将这些虚拟地址映射到物理内存或磁盘上的交换空间。

另外，“内核区”并不严格位于用户空间内存的“高端”，而是在一个完全不同的地址空间中。在大多数现代操作系统中，用户空间和内核空间是隔离的，以防止用户程序破坏操作系统或访问敏感数据。

各个分区分别存储哪些内容？

在Objective-C（以及更广泛的C语言家族环境）中，内存分区主要分为保留区、代码段、数据段、堆、栈和内核区。每个分区有其特定的用途和存储内容。以下是对每个分区的详细解释：

  1. 保留区：
    • 这部分内存是保留给系统使用的，通常应用程序无法直接访问。它可能用于特定的系统操作或存储关键的系统信息。
  2. 代码段：
    • 存储程序的二进制代码和指令，这是CPU执行程序时需要读取的部分。
    • 也包含程序中使用到的常量，例如字符串常量。
    • 此区域是只读的，以防止程序意外修改其执行指令。
  3. 数据段：
    • 初始化数据段：存储已初始化的全局变量和静态变量。这些变量在编译时就已经被赋予了初值。
    • 未初始化数据段（也称为BSS段）：存储未初始化的全局变量和静态变量。这些变量在程序加载时会被系统自动初始化为0。
  4. 堆：
    • 用于动态分配内存的区域。程序员可以在运行时申请或释放堆内存，用于存储程序运行时创建的对象和数据结构。
    • 在Objective-C中，使用如alloc、init等方法分配的内存来自堆区。
  5. 栈：
    • 存储局部变量、函数调用的返回地址以及执行线程的上下文信息。
    • 每个线程都有一个独立的栈，用于跟踪该线程的函数调用和执行状态。
    • 栈内存的管理是自动的，当函数被调用时，相关数据被压入栈，函数调用结束后，这些数据被自动弹出。
  6. 内核区：
    • 这部分内存是操作系统内核专有的，用于管理硬件、提供系统服务以及执行底层任务。
    • 用户空间的程序无法直接访问内核区的内存。

总的来说，这些内存分区为程序提供了结构化的内存管理，使得程序能够高效、安全地运行。每个分区都有其特定的用途和访问规则，确保了程序的稳定性和安全性。

OC内存管理方案有哪些？ARC，MRC的区别，Tagged Pointer是什么?自动释放池又是什么

OC（Objective-C）内存管理方案主要有两种：ARC（Automatic Reference Counting，自动引用计数）和MRC（Manual Reference Counting，手动引用计数）。

ARC和MRC的区别：

  1. ARC（Automatic Reference Counting）：
    • 概念：ARC是一种编译器特性，用于自动管理Objective-C对象的内存。
    • 工作原理：通过在编译时插入retain、release和autorelease等方法调用来跟踪对象的引用计数，并在适当的时候自动插入内存管理代码。
    • 优势：简化了内存管理，减少了手动管理内存的错误和内存泄漏的可能性，提高了开发效率。
    • 应用场景：适用于大多数Objective-C项目，特别是新项目和需要快速迭代的项目。
  2. MRC（Manual Reference Counting）：
    • 概念：MRC是一种需要手动管理Objective-C对象内存的机制。
    • 工作原理：开发者需要手动调用retain、release和autorelease等方法来管理对象的引用计数。
    • 优势：提供了更细粒度的内存控制，可以手动管理对象的生命周期。
    • 应用场景：适用于老旧项目、需要与非Objective-C代码交互的项目、对内存管理有严格要求的项目。

Tagged Pointer是什么？

  • Tagged Pointer是一个指针，它具有与其关联的附加数据，如引用计数等。这些数据通常是“折叠”在指针中，利用内存寻址的某些属性存储在表示内存地址的数据中。这种技术可以优化某些情况下的内存使用和性能。

自动释放池是什么？

  • 自动释放池是Objective-C的一种内存自动回收机制。当对象调用autorelease方法时，该对象就会被放入到自动释放池中。当自动释放池被回收时（通常是在一个事件循环或函数调用结束后），池中的所有对象都会收到一次release操作，从而自动管理对象的内存释放。这种机制有助于减少内存泄漏和简化内存管理过程。在iOS开发中，自动释放池常用于管理那些被声明为autorelease的对象，确保它们在不再需要时能够被正确释放。

Tagged Pointer能够存储哪些类型，怎么区分iOS平台还是Mac平台

Tagged Pointer能够存储的类型主要包括值类型的小内存对象，如NSNumber、NSDate和NSString等。这些类型通常占用内存较小，且频繁创建和销毁，使用Tagged Pointer可以优化它们的存储和访问效率。

至于区分iOS平台和Mac平台，可以从以下几个方面进行：

  1. 设备适用性：iOS是苹果公司为其移动设备（如iPhone和iPad）开发的操作系统，而Mac OS是为其台式机和笔记本电脑（如MacBook和iMac）开发的操作系统。因此，通过判断设备类型可以区分两个平台。
  2. 应用程序兼容性：iOS和Mac OS有不同的应用程序生态系统。iOS应用程序通常通过App Store分发，并且只能在iOS设备上运行。而Mac OS应用程序通常通过App Store或者其他渠道分发，并且只能在Mac OS设备上运行。通过观察应用程序的分发渠道和运行环境也可以区分两个平台。
  3. 系统特性：iOS和Mac OS在系统特性上也有所不同。例如，iOS具有触摸屏操作、多任务处理、通知中心等特性，而Mac OS则具有多窗口操作、文件系统访问、更强大的多任务处理等特性。通过识别这些系统特性也可以辅助区分两个平台。

然而，需要注意的是，以上方法主要适用于用户或开发者在设备使用或应用开发过程中进行平台区分。如果是从代码层面进行判断，可能需要利用特定的API或库来检测当前运行环境是iOS还是Mac OS。

另外，虽然Tagged Pointer本身并不直接提供区分iOS平台和Mac平台的功能，但了解它在不同平台上的表现和行为有助于更好地理解和使用这一技术。例如，在64位系统中，Tagged Pointer的实现可能会有所不同，从而影响到存储和性能等方面。因此，在跨平台开发时需要注意这些差异。

引用计数存储在什么位置？

在Objective-C中，引用计数通常存储在对象的内部结构中。具体来说，引用计数的存储位置可以分为以下几种情况：

  1. isa指针中：从arm64(iPhone 5S)架构开始，对象的引用计数直接存储在对象的isa指针中。这意味着每个Objective-C对象的isa指针不仅指示了对象的类信息，还同时包含了引用计数的信息。

  2. SideTable结构中：除了直接存储在isa指针中，引用计数也可能存储在SideTable的数据结构中。这个结构包含了散列表RefcountMap，它以当前对象的地址作为key，引用计数作为value。这种方式用于存储那些无法直接通过isa指针存储的引用计数信息，或者是为了优化性能而采取的额外存储机制。

综上所述，引用计数的具体存储位置可能因Objective-C运行时的实现和平台架构的不同而有所差异。但通常情况下，它们会被存储在对象的isa指针中或者SideTable结构中。这些设计都是为了更有效地管理对象的生命周期和内存分配。

请注意，以上信息可能因苹果公司的实现细节变化而有所不同，但基本概念和原理是相对稳定的。在实际开发中，开发者通常不需要直接操作或访问引用计数，而是由Objective-C的运行时系统自动处理。

delloc方法会进行哪些操作？

dealloc方法是Objective-C中用于释放对象所占用的内存的方法。当一个对象的引用计数减少到0时，Objective-C的运行时会调用该对象的dealloc方法来进行内存清理。以下是dealloc方法通常会进行的操作：

  1. 释放对象所拥有的其他资源：
    • 如果对象拥有对其他对象的引用（如其他Objective-C对象或CoreFoundation对象等），它需要在dealloc中释放这些引用，以避免内存泄漏。
    • 如果对象使用了文件描述符、套接字或其他系统资源，也需要在dealloc中释放这些资源。
  2. 解除监听和通知：
    • 如果对象注册了任何监听器或观察者，如KVO（Key-Value Observing）观察或NSNotification通知，它需要在dealloc中移除这些监听器和通知，以避免在对象被释放后仍然接收通知，这可能会导致程序崩溃。
  3. 调用父类的dealloc方法：
    • 在释放完对象所拥有的资源后，通常需要调用[super dealloc]来确保父类中定义的资源也被正确释放。这是Objective-C继承机制的一部分，确保父类中定义的任何清理工作也能被执行。
  4. 不进行其他操作：
    • dealloc方法主要用于释放资源，不应该进行其他可能引发问题的操作，如调用可能产生异常的方法或进行耗时的操作。
  5. 避免在dealloc中调用其他方法：
    • 通常不推荐在dealloc中调用其他对象的方法，因为这些方法可能会引用已经被释放的对象，导致未定义行为或程序崩溃。
  6. 不要进行异步操作：
    • dealloc方法应该是同步的，并且不应该启动任何异步操作。因为当dealloc返回后，对象所占用的内存可能会被立即回收，任何后续的异步操作都可能导致对已经释放的内存的引用。

请注意，自iOS 5.0和Xcode 4.2起，Apple引入了自动引用计数（ARC），在ARC环境下，编译器会自动插入适当的内存管理代码，包括retain、release和autorelease等。在ARC环境下，开发者通常不需要（也不应该）直接调用dealloc来释放内存，但了解dealloc的工作原理对于理解和调试内存管理问题仍然很重要。

另外，从iOS 6开始，dealloc方法不再需要显式调用[super dealloc]，因为在ARC下这是自动处理的。然而，在MRC（手动引用计数）环境中，仍然需要显式调用[super dealloc]来确保正确的清理顺序。

SideTable是什么，能够存储哪些数据，数据结构是怎么样的？

SideTable是Objective-C中用于管理对象的引用计数和弱引用关系的一种数据结构。以下是关于SideTable的详细解释：

一、SideTable的定义和作用

SideTable是一个结构体，在Objective-C的运行时环境中起着重要作用。它的主要功能是存储和管理Objective-C对象的引用计数和弱引用信息。通过SideTable，Objective-C能够有效地跟踪每个对象的引用情况，并确保在适当的时候释放不再被引用的对象，从而防止内存泄漏。

二、SideTable能够存储的数据

SideTable主要存储以下两类数据：

  1. 对象的引用计数：每个Objective-C对象都有一个与之关联的引用计数，用于记录当前有多少强引用指向该对象。当引用计数减少到0时，对象将被释放。SideTable中的RefcountMap用于存储这些引用计数信息，其中key是对象的地址，value是对应的引用计数。
  2. 对象的弱引用信息：弱引用是一种不会增加对象引用计数的引用方式，当对象被释放时，弱引用会自动变为nil。SideTable中的weak_table用于存储对象的弱引用信息。具体来说，它存储了指向对象的弱引用指针的地址，以便在对象被释放时能够将这些弱引用设置为nil。

三、SideTable的数据结构

SideTable的数据结构主要包含以下部分：

  1. 自旋锁（spinlock_t slock）：用于保护SideTable的并发访问，确保在多线程环境下对SideTable的操作是线程安全的。
  2. 引用计数哈希表（RefcountMap refcnts）：这是一个以对象地址为key、引用计数为value的哈希表。它记录了每个对象的当前引用计数。
  3. 弱引用哈希表（weak_table_t weak_table）：这是一个存储弱引用信息的哈希表。其key为对象的地址，value为指向该对象的所有弱引用指针的地址的数组。当对象被释放时，Objective-C运行时会遍历这个数组，并将每个弱引用设置为nil。

综上所述，SideTable是Objective-C中用于管理对象引用计数和弱引用关系的重要数据结构。它通过自旋锁确保线程安全，并通过两个哈希表分别存储对象的引用计数和弱引用信息。

自动释放池的底层结构是什么样的，怎么实现的？

自动释放池（Autorelease Pool）是 Objective-C 中内存管理的一个重要机制，它允许开发者延迟对象的释放，直到池被销毁时才自动释放其中的对象。这在处理大量临时对象时特别有用，比如在一个事件循环或绘图循环中。

在底层，自动释放池的实现依赖于以下几个关键组件：

  1. AutoreleasePoolPage 结构体：
    • 这是一个关键的数据结构，用于管理自动释放池中的对象。
    • 每个 AutoreleasePoolPage 都有一个指向下一个 AutoreleasePoolPage 的指针，形成一个链表结构。
    • 每个页面包含多个槽位（slots），用于存放需要自动释放的对象的指针。
    • 当页面满了之后，会创建一个新的 AutoreleasePoolPage 并链接到之前的页面。
  2. 线程局部存储（Thread-Local Storage, TLS）：
    • 每个线程都有一个与之关联的 AutoreleasePoolPage 链表，这是通过线程局部存储实现的。
    • 线程局部存储允许每个线程存储和访问自己的数据，而不会与其他线程的数据混淆。
  3. Push 和 Pop 操作：
    • 当创建一个新的自动释放池时（例如，使用 @autoreleasepool 块），会执行一个 “push” 操作，这通常涉及到将一个新的 AutoreleasePoolPage 压入线程的 TLS 链表。
    • 当自动释放池销毁时（例如，@autoreleasepool 块结束时），会执行一个 “pop” 操作，这涉及到释放当前 AutoreleasePoolPage 中所有对象的内存，并可能从链表中移除该页面。
  4. 内存释放：
    • 在 “pop” 操作期间，自动释放池会遍历当前页面的槽位，并对每个槽位中的对象发送 release 消息。
    • 如果对象的引用计数减少到 0，对象将被销毁，并释放其占用的内存。
  5. 优化和性能考虑：
    • 为了提高效率，自动释放池的实现通常会包含一些优化措施，例如延迟创建新的 AutoreleasePoolPage 直到需要时，以及尽可能地重用旧的页面。
    • 在某些情况下，如低内存警告时，系统可能会提前触发自动释放池的清理操作以释放内存。

总的来说，自动释放池的底层结构是一个基于线程局部存储的 AutoreleasePoolPage 链表，每个页面包含多个用于存放对象指针的槽位。通过 push 和 pop 操作来管理这些页面和其中的对象，从而实现对象的自动释放机制。这种机制允许开发者在不需要立即释放对象的情况下，仍然能够保持内存的有效管理。

Runloop和自动释放池的关系？

RunLoop和自动释放池的关系可以从以下几个方面进行阐述：

  1. 创建与销毁：
    • RunLoop：每个线程都有其对应的RunLoop，主线程的RunLoop在程序启动时自动创建，而子线程的RunLoop需要手动创建。RunLoop在第一次获取时创建，并在线程结束时销毁。
    • 自动释放池：自动释放池会在RunLoop启动时创建，并在RunLoop退出时释放。此外，当RunLoop即将进入休眠时会销毁之前的释放池，并重新创建一个新的。
  2. 作用与关联：
    • RunLoop：主要负责监听所有的事件（如触摸、时钟、网络事件等），并在有任务时进行处理，无任务时使线程进入睡眠状态以节省CPU资源。它还在一次循环中负责渲染UI。
    • 自动释放池：主要用于管理OC对象的内存，通过延迟释放对象来优化内存使用。它允许开发者将不再需要的对象放入池中，等待RunLoop的特定时机进行统一释放。
    • 关联：RunLoop和自动释放池相互配合，使得在RunLoop的每个循环中，都能够有效地管理内存。当RunLoop开始一个新的循环时，它会创建一个新的自动释放池，并在循环结束时释放该池中的所有对象。
  3. 内存管理与性能：
    • 通过在RunLoop的每个循环中创建和销毁自动释放池，Objective-C能够有效地管理内存，避免内存泄漏和过早释放对象的问题。
    • 这种机制还有助于提高应用程序的性能，因为它允许开发者在不需要立即释放对象的情况下继续使用这些对象，同时确保在适当的时候释放它们以回收内存。

综上所述，RunLoop和自动释放池在Objective-C中起着至关重要的作用，它们相互配合以优化内存使用和提高应用程序的性能。

Copy 和 mutableCopy的区别是什么？

Copy和mutableCopy的区别主要体现在以下四个方面：

  1. 产生的对象类型：
    • Copy通常产生的是不可变类型的副本对象。例如，如果源对象是NSString、NSArray或NSDictionary等不可变类型，使用copy操作会得到一个相同类型的不可变对象。
    • MutableCopy则产生的是可变类型的副本对象。即使源对象是不可变的，如NSString，使用mutableCopy操作也会得到一个可变类型的对象，如NSMutableString。
  2. 内存管理：
    • 当使用copy操作时，如果源对象是不可变的，那么副本对象实际上可能只是源对象的一个浅拷贝，即两者可能指向相同的内存地址，没有产生新的对象。这相当于执行了一次retain操作。
    • 而mutableCopy无论源对象是可变还是不可变，都会创建一个新的对象，即进行深拷贝，分配新的内存地址，并复制源对象的内容到新对象中。
  3. 对源对象的修改影响：
    • 由于copy可能产生浅拷贝，因此对副本对象的修改可能不会影响源对象（如果副本实际上是源对象的一个新的retain引用）。但是，如果修改了mutableCopy产生的副本对象，这绝对不会影响源对象，因为它们是完全独立的两个对象。
  4. 使用场景与安全性：
    • Copy操作更为安全，因为它不会改变原有数据的结构或内容，适用于需要保护原始数据不被修改的场景。
    • MutableCopy提供了更多的灵活性，允许用户对数据进行修改，但同时也需要用户更加小心操作，以避免不必要的数据损坏或错误。

总的来说，copy和mutableCopy的主要区别在于它们产生的对象类型（可变或不可变）、内存管理方式（浅拷贝或深拷贝）、对源对象的修改影响以及使用场景与安全性。在实际编程中，应根据具体需求和上下文来选择合适的方法。

属性关键字有哪些？什么情况下用copy？

在Objective-C中，属性关键字用于定义类的属性，并指定这些属性的行为。以下是一些常见的属性关键字：

  1. atomic：表示属性是线程安全的，但通常会影响性能。由于性能开销较大，开发者大多选择使用nonatomic。
  2. nonatomic：与atomic相反，表示属性不是线程安全的。这是大多数情况下的选择，因为它提供了更高的性能。开发者可以通过自己的代码来控制线程安全。
  3. strong：表示对对象的强引用，会增加对象的引用计数。当属性被赋值时，之前的对象会被释放，新的对象会被持有。
  4. weak：表示对对象的弱引用，不会增加对象的引用计数。当对象被销毁时，weak引用的指针会自动设为nil，有助于防止野指针。
  5. copy：用于对象的浅拷贝。当源对象的内容发生变化时，不会影响到已经使用copy修饰的属性。这通常用于不可变对象，如NSString、NSArray等。
  6. assign：用于基本数据类型和C指针，执行简单的赋值操作，不改变引用计数。也可以用于对象，但需要注意野指针的问题。
  7. retain：与strong类似，但更老旧，现在更推荐使用strong。
  8. readwrite和readonly：分别表示属性可以被读写或只读。

关于copy的使用情况：

  • 保护不可变数据：当你有一个不可变的字符串、数组或其他对象，并希望确保它不会被外部修改时，可以使用copy。这样，即使源对象被修改，你的属性仍然保持不变。
  • 防止外部修改：使用copy可以确保你的属性不会被外部对象所修改，从而保持数据的完整性和一致性。
  • 避免深拷贝开销：与mutableCopy不同，copy通常执行浅拷贝，这意味着它不会复制对象的所有内容，而是复制指向对象的指针或引用。这可以提高性能，特别是在处理大量数据或复杂对象时。

总的来说，属性关键字提供了对类属性的精细控制，帮助开发者定义属性的行为和内存管理方式。而copy关键字在保护不可变数据和防止外部修改方面非常有用。

Block，NSTimer循环引用区别与解决方案？

Block 和 NSTimer 都可能导致循环引用，但它们导致循环引用的方式和解决方案有所不同。

Block 循环引用

当 Block 内部引用了外部变量，并且这个变量是一个对象（比如 self）时，如果这个对象又持有了这个 Block，就可能形成循环引用。因为 Block 会对其引用的外部变量进行 capture（捕获），形成一个强引用。

解决方案：

  1. 使用 __weak 修饰符：在 Block 内部使用 __weak 修饰符来声明对外部对象的引用，这样可以避免 Block 对该对象形成强引用。
__weak typeof(self) weakSelf = self;
dispatch_block_t block = ^{
    [weakSelf doSomething];
};
  1. 在适当的时候移除 Block 的强引用：如果你确定在某个时间点之后不再需要这个 Block，可以在那个时间点手动将 Block 置为 nil，从而打破循环引用。

NSTimer 循环引用

NSTimer 可能导致循环引用的场景通常是这样的：一个对象（比如 UIViewController）创建了一个定时器，并且这个定时器每隔一段时间就调用该对象的一个方法。如果这个对象在定时器的回调中被强引用了，而定时器又被这个对象持有，就可能形成循环引用。

解决方案：

  1. 使用弱引用：和 Block 类似，可以在定时器的回调中使用弱引用来避免对对象的强引用。
  2. 在适当的时候使定时器失效：当你确定不再需要定时器时，应该调用 [timer invalidate] 来使定时器失效，并置为 nil，从而打破循环引用。
  3. 使用中间对象：可以创建一个中间对象来持有定时器，并确保这个中间对象不会被主对象（如 UIViewController）强引用。这样，即使定时器在回调中强引用了主对象，也不会形成循环引用。
  4. 使用 GCD 的定时器：dispatch_source_t 是一个基于 GCD 的定时器，它可以替代 NSTimer，并且更容易管理内存和避免循环引用。

总的来说，解决 Block 和 NSTimer 导致的循环引用问题的关键是确保没有强引用环的形成。这通常意味着在适当的地方使用弱引用，并在不再需要时及时移除强引用。

weakTable 弱引用表是怎么实现的

在 Objective-C 和 Swift 运行时环境中，weak 关键字用于创建对对象的弱引用，这意味着当没有强引用指向该对象时，对象可以被销毁，并且所有指向它的 weak 引用会自动变为 nil。为了实现这一功能，Objective-C 运行时维护了一个叫做 weakTable 的结构来跟踪所有的 weak 引用。

weakTable 的实现是高度优化的，并且涉及到一些底层的数据结构和算法。不过，我们可以从概念上理解其大致的工作原理：

  1. 弱引用表的创建与维护：
    • 当一个对象首次被赋予一个 weak 引用时，Objective-C 运行时会在内部为这个对象的类创建一个弱引用表（如果尚未存在）。
    • 这个表用于跟踪所有对该类的实例的 weak 引用。
  2. 弱引用的注册与注销：
    • 当一个新的 weak 引用被创建时，它会被注册到对应类的 weakTable 中。
    • 当 weak 引用被销毁或重新赋值时，它会从 weakTable 中注销或更新。
  3. 对象销毁时的处理：
    • 当一个对象被销毁（即其引用计数减少到 0）时，Objective-C 运行时会查找该对象的类的 weakTable。
    • 对于表中的每一个 weak 引用，运行时将其值设置为 nil，从而确保没有悬挂指针（dangling pointer）的问题。
  4. 内存管理和性能优化：
    • weakTable 的实现必须非常高效，因为它涉及到核心的内存管理功能。
    • 运行时可能会使用各种数据结构（如哈希表）来优化查找和更新操作。
    • 为了减少锁的竞争和提高性能，weakTable 的操作可能是无锁的或使用了细粒度的锁策略。
  5. 与垃圾收集机制的交互：
    • 在早期的 Objective-C 运行时中，使用了一种基于引用的垃圾收集机制。在这种情况下，weakTable 还需要与垃圾收集器进行交互，以确保被弱引用的对象不会被错误地回收。
    • 然而，在 iOS 5 和 macOS 10.7 之后，Objective-C 采用了自动引用计数（ARC），这改变了内存管理的行为，并影响了 weakTable 的实现细节。

需要注意的是，weakTable 的具体实现细节可能因不同的 Objective-C 运行时版本和平台而有所不同。上述描述提供了一个高级的概念性理解，但实际的底层实现可能更加复杂和优化。

如果你对 weakTable 的内部实现细节感兴趣，并希望深入研究，你可能需要查看 Objective-C 运行时的源代码，这通常可以在 Apple 的开源项目中找到，或者查看相关的技术文档和资料。

8、OC中Runtime原理与使用

什么是Runtime，有什么作用？常用在什么地方

iOS中的Runtime是指Objective-C语言的运行时系统，它是Objective-C语言的核心特性之一。以下是关于Runtime的详细解释：

一、Runtime的定义

Runtime，即运行时，是指程序在运行时的动态行为和特性。在Objective-C中，Runtime允许程序在运行时确定数据的类型、消息的具体响应等，这种动态性将许多在编译和链接时期确定的事情推迟到了运行时处理。

二、Runtime的作用

Runtime提供了一套底层的C语言API，使得开发者可以在程序运行时动态地操作类和对象。具体来说，它的作用包括：

  1. 动态创建类、添加成员变量、调用方法、交换方法实现等功能。
  2. 实现各种动态性的功能，如消息发送与转发、方法的动态添加与替换、属性的动态合成等。

三、Runtime的常用场景

  1. 在分类（Category）中添加属性：由于Objective-C的分类不允许直接添加实例变量，但可以通过Runtime关联对象的方式为分类添加属性。
  2. 方法交换（Method Swizzling）：可以在运行时替换已有的方法实现，常用于实现AOP（面向切面编程）功能，例如为原有的方法添加日志输出、性能监控等。
  3. 动态添加方法：可以在运行时为类动态添加新的方法。
  4. 消息转发：当调用一个对象不存在的方法时，可以通过Runtime的消息转发机制来尝试调用其他对象的方法或进行其他处理。
  5. KVO（Key-Value Observing）实现原理：Runtime也是KVO实现的关键技术之一，通过Runtime可以动态地观察对象的属性变化。

总的来说，Runtime是Objective-C语言中非常强大且灵活的一个特性，它允许开发者在程序运行时进行各种动态操作，从而实现更灵活、更动态的编程方式。

OC方法查找机制是怎么样的？有什么缺点？

OC（Objective-C）方法查找机制主要涉及objc_msgSend函数，它是Objective-C中发送消息的关键函数。以下是OC方法查找机制的基本步骤和特点，以及其存在的缺点：

OC方法查找机制：

  1. 获取对象的类：首先，运行时系统会获取调用方法的对象所属的类。
  2. 查找方法缓存表：Objective-C为了提高方法调用的效率，会为每个类维护一个方法缓存表（也称为方法快速查找表或者IMP缓存）。这个缓存表将选择子和函数指针（IMP）对应起来。当需要调用一个方法时，系统会首先在这个缓存表中查找对应的选择子。
  3. 在类的方法列表中查找：如果在缓存表中没有找到对应的方法，系统会在类的方法列表中查找。这个方法列表包含了类中定义的所有方法。
  4. 沿继承链向上查找：如果在当前类中没有找到对应的方法，系统会沿着类的继承链向上查找，直到找到对应的方法或者到达继承链的顶端（通常是NSObject类）。
  5. 消息转发机制：如果最终都没有找到对应的方法，Objective-C的运行时会触发消息转发机制，允许开发者自定义对未知消息的处理方式。

缺点：

  1. 动态性带来的效率问题：虽然Objective-C的动态性提供了很大的灵活性，但这种动态性也带来了效率上的损失。因为方法的查找是在运行时进行的，相比于静态绑定的语言，这种动态查找会增加一定的开销。
  2. 缓存依赖：为了提高查找效率，Objective-C使用了方法缓存表。然而，这也意味着如果类的结构发生变化（例如动态添加或删除方法），缓存可能需要被更新或失效，这可能会带来额外的性能开销。
  3. 错误隐藏：Objective-C的动态特性有时也可能隐藏一些编程错误。例如，如果一个方法名拼写错误，但由于动态查找机制的存在，程序可能不会在编译时报错，而是在运行时才出现问题，这增加了调试的难度。
  4. 不适合高性能需求场景：对于需要高性能的场景（如游戏、实时渲染等），Objective-C的方法查找机制可能不是最优选择。在这些场景下，更直接和静态的绑定方式可能会提供更高的执行效率。

总的来说，Objective-C的方法查找机制在提供灵活性的同时也带来了一些性能上的开销和潜在的调试难度。在选择使用Objective-C进行开发时，需要权衡这些优缺点。

objc_msgSend分为哪几个阶段？每个阶段具体做了些什么？

objc_msgSend的执行过程可以分为三个阶段：消息发送、动态方法解析和消息转发。

  1. 消息发送阶段：
    • 首先，检查消息接收者（receiver）是否为nil。如果是nil，则直接退出，不执行任何操作。
    • 如果接收者不为nil，通过其isa指针找到它的类对象（如果接收者本身就是一个类对象，则找到的是它的元类对象）。
    • 在类对象的缓存（cache）中查找对应的方法。如果找到了，就直接调用该方法，并结束查找。
    • 如果在缓存中没有找到方法，就到类对象的方法列表（通常是class_rw_t结构中的methods数组）中去查找。如果找到了，就调用该方法，并将此方法缓存到类对象的缓存中，以便下次快速查找。然后结束查找。
    • 如果在本类中找不到方法，就通过superclass指针向上查找父类，重复上述在缓存和方法列表中的查找步骤。
    • 如果一直找到最顶层的类（如NSObject）仍然没有找到方法，就会进入下一个阶段：动态方法解析。
  2. 动态方法解析阶段：
    • 在此阶段，开发者有机会动态地添加一个方法。这通常涉及到resolveInstanceMethod:或resolveClassMethod:的调用。
    • 如果开发者成功地动态添加了一个方法，那么这个方法就会被添加到当前类（或元类）的class_rw_t表中的methods数组里，并且调用之后会被缓存到cache表中。
    • 如果动态方法解析未能添加所需的方法，或者没有实现相关的解析方法，那么就会进入下一个阶段：消息转发。
  3. 消息转发阶段：
    • 在此阶段，运行时系统会尝试将消息转发给另一个对象来处理。这通常涉及到forwardingTargetForSelector:或forwardInvocation:方法的重写。
    • 如果消息被成功转发并处理，那么整个消息发送过程就此结束。
    • 如果消息转发也失败了，那么最终会抛出一个异常，表明“无法识别的选择器（unrecognized selector）已发送到实例”。

这就是objc_msgSend的整个执行流程和每个阶段的具体操作。

方法cache是怎么做的？有什么好处

OC（Objective-C）消息转发中的方法缓存是通过在类结构中维护一个缓存表来实现的。这个缓存表用于存储类的方法的选择子（selector）与对应的函数指针（IMP）之间的映射关系。当调用一个方法时，Objective-C运行时首先会在这个缓存表中查找对应的选择子，如果找到了就直接调用对应的函数，从而避免了在类的方法列表中进行线性查找的开销。

方法缓存的好处主要体现在以下几个方面：

  1. 提高方法调用的效率：方法缓存可以显著减少方法调用的时间开销。因为缓存表通常使用哈希表等数据结构实现，查找效率远高于在方法列表中线性查找。当程序多次调用同一个方法时，通过缓存表可以直接定位到方法的实现，避免了重复的查找过程。

  2. 优化程序性能：通过减少方法查找的时间，方法缓存有助于提升程序的总体性能。特别是在那些需要频繁调用方法的场景中，如用户界面更新、事件处理等，缓存可以显著减少响应延迟，提升用户体验。

  3. 减少内存占用：虽然缓存表本身会占用一定的内存空间，但由于它减少了重复查找方法所需的内存访问次数，因此在某些情况下，这反而有助于降低总体的内存占用。此外，Objective-C运行时会对缓存进行优化，只缓存那些经常被调用的方法，从而进一步平衡性能和内存占用的关系。

  4. 支持动态性：Objective-C是一种动态语言，允许在运行时添加、替换或删除方法。方法缓存机制能够在这种动态环境中保持高效的方法调用。当类的方法发生变化时，缓存表会被相应地更新，以确保后续的方法调用仍然能够快速定位到正确的实现。

总的来说，方法缓存是Objective-C中一项重要的性能优化技术，它通过减少方法查找的开销来提升程序的执行效率。

OC与Swift在方法调用上有什么区别？

OC（Objective-C）与Swift在方法调用上的区别主要体现在以下几个方面：

  1. 动态性与静态性：
    • Objective-C的方法调用是基于动态绑定的，即方法的确定是在运行时。它使用objc_msgSend函数进行动态方法分发，允许在运行时改变方法的实现，具有更高的灵活性。
    • Swift则可以根据上下文选择使用静态调用（Static Dispatch）或动态调用（Dynamic Dispatch）。对于值类型（如结构体和枚举），Swift主要使用静态调用，这有助于提高执行效率。而对于引用类型（如类），Swift支持动态调用，包括V-Table Dispatch等机制，同时也兼容Objective-C的运行时特性。
  2. 方法查找与缓存：
    • Objective-C通过方法缓存来提高方法调用的效率。当一个方法首次被调用时，它会在类的缓存中进行查找，如果未找到，则会在类的方法列表中进行查找，并最终沿继承链向上查找。一旦找到方法，它会被添加到缓存中以加速后续调用。
    • Swift在编译时就已经确定了大部分方法的调用地址，因此不需要像Objective-C那样进行动态方法查找。这有助于Swift在某些情况下实现更高的执行效率。
  3. 调用语法与表达：
    • Objective-C的方法调用通常使用[object methodName]的语法形式，其中object是调用方法的对象，methodName是调用的方法名。此外，Objective-C的方法名通常包含参数和返回类型的描述，使得方法签名相对较长。
    • Swift的方法调用语法更加简洁和直观，采用点语法（object.methodName()）或者如果方法没有参数可以省略括号。Swift还支持操作符重载和自定义操作符，使得方法调用可以更加灵活和富有表现力。
  4. 类型安全与错误处理：
    • Swift是一个类型安全的语言，它在编译时会检查类型匹配，减少了运行时类型错误的可能性。同时，Swift具有强大的错误处理机制，使用do-catch语句来处理可能抛出的错误。
    • Objective-C在类型安全和错误处理方面相对较弱，需要开发者更多地依赖约定和手动检查来确保代码的正确性。

综上所述，OC与Swift在方法调用上的区别主要体现在动态性与静态性、方法查找与缓存、调用语法与表达以及类型安全与错误处理等方面。这些区别使得两种语言在各自擅长的领域发挥着不同的作用。

动态方法解析过程中关键方法是哪个？

动态方法解析过程中的关键方法是resolveInstanceMethod:或resolveClassMethod:。这两个方法是NSObject类中的类方法，分别用于动态解析实例方法和类方法。

  1. resolveInstanceMethod:：当调用一个实例方法时，如果该方法在类中未实现，Objective-C运行时会调用这个方法来给予开发者动态提供方法实现的机会。开发者可以在这个方法中为指定的选择子动态地提供一个实现。

  2. resolveClassMethod:：与resolveInstanceMethod:类似，但是用于类方法的动态解析。当一个类方法被调用且类中未实现时，Objective-C运行时会调用这个方法来允许动态地添加类方法的实现。

这两个方法都是在消息转发机制启动前的中间时刻被调用的，给予开发者一个机会去动态地提供一个方法的实现，从而避免消息转发。如果开发者实现了这些方法并成功地为一个选择器提供了实现，那么该实现将会被添加到类的方法列表中，并且后续对该方法的调用将直接使用该实现，而不再经过动态方法解析或消息转发。

消息转发过程关键方法有哪几个？

消息转发过程中的关键方法主要有以下几个：

  1. 动态方法解析：
    • + (BOOL)resolveInstanceMethod:(SEL)sel：当实例方法未找到时，Objective-C 运行时首先会调用这个方法，尝试动态地添加一个方法到类中。如果开发者在这个方法中成功地添加了对应的方法实现，则消息得到响应，转发流程结束。
    • + (BOOL)resolveClassMethod:(SEL)sel：与 resolveInstanceMethod: 类似，但是用于类方法。当类方法未找到时，Objective-C 运行时会调用这个方法来尝试动态添加类方法。
  2. 备援接收者：
    • - (id)forwardingTargetForSelector:(SEL)aSelector：如果动态方法解析未能解决问题，Objective-C 运行时会调用这个方法。在这个方法中，开发者可以返回一个能够响应该消息的对象，从而将消息转发给另一个对象。
  3. 完整消息转发：
    • - (NSMethodSignature *)methodSignatureForSelector:(SEL)aSelector：当备援接收者也无法处理消息时，Objective-C 运行时会继续调用此方法。开发者需要在这个方法中返回一个方法签名，即参数的类型和返回值的类型信息，用于描述该消息。
    • - (void)forwardInvocation:(NSInvocation *)anInvocation：在获取到方法签名后，Objective-C 运行时会调用此方法，并将消息以 NSInvocation 对象的形式传入。开发者可以在这个方法中自定义处理 NSInvocation 对象，或将消息转发给其他对象。

如果以上三个步骤都无法处理消息，那么程序会抛出 “unrecognized selector sent to instance” 异常。因此，开发者可以通过实现上述的一个或多个方法来实现对消息的动态处理和转发。

@dynamic的作用是什么？

@dynamic在Objective-C中的主要作用是告诉编译器，被@dynamic修饰的属性的setter和getter方法会在程序运行时动态实现，而不是由编译器自动生成。具体地说，其作用可以归纳为以下几点：

  1. 动态绑定：使用@dynamic指令的属性，其setter和getter方法会在程序运行时动态绑定。这意味着，这些方法的具体实现不是在编译时确定的，而是在运行时由开发者提供或者通过其他机制（如Core Data）动态生成。

  2. 开发者控制：@dynamic给予了开发者更大的灵活性，允许开发者自行提供属性的访问器方法。对于只读属性，开发者需要提供setter方法；对于读写属性，则需要提供setter和getter方法。这样，开发者可以根据实际需求来定制属性的行为。

  3. 与Core Data等框架的集成：@dynamic在处理如Core Data等框架生成的属性时特别有用。这些框架通常会在运行时为属性生成相应的setter和getter方法。通过使用@dynamic，开发者可以指示编译器不要自动生成这些方法，从而避免与框架生成的方法发生冲突。

  4. 错误检查：如果在运行时没有为@dynamic修饰的属性提供必要的setter或getter方法，程序会在运行时出错。这有助于开发者及时发现并修复代码中的问题。

总的来说，@dynamic提供了一种机制，使得属性的setter和getter方法可以在运行时动态确定，而不是在编译时由编译器自动生成。这增加了代码的灵活性和可扩展性，同时也要求开发者对属性的实现有更深入的了解和控制。

[super xxxx]中super有什么作用？

在Objective-C中，[super xxxx] 的语法是用于调用父类（或称为超类，superclass）中的方法。super 是一个特殊的关键字，它代表当前类的父类。当你使用 [super xxxx] 时，你实际上是在调用父类中定义的 xxxx 方法，而不是当前类中可能重写的版本。

这种语法有几个主要的用途：

  1. 继承和方法重写：当你在子类中重写父类的方法时，有时你可能还想调用父类的原始实现。使用 [super xxxx] 可以让你在重写的方法中保留父类的行为，并在此基础上添加或修改功能。
- (void)someMethod {
    [super someMethod]; // 调用父类的someMethod实现
    // 添加或修改的功能代码
}
  1. 初始化：在初始化方法中，尤其是当使用指定初始化方法（如 initWithCoder: 或 init 方法）时，通常需要先调用父类的相应初始化方法来确保正确的初始化。
- (instancetype)initWithCoder:(NSCoder *)coder {
    self = [super initWithCoder:coder]; // 调用父类的初始化方法
    if (self) {
        // 自定义的初始化代码
    }
    return self;
}
  1. 遵循设计模式：在某些设计模式中，如模板方法模式，super 的调用是模式实现的关键部分。
  2. 确保一致性：在某些情况下，你可能不希望完全重写父类的方法，而是想在其基础上添加一些功能。通过调用 [super xxxx]，你可以确保父类的行为被保留，同时添加你需要的额外功能。

总的来说，[super xxxx] 允许你在子类中引用并调用父类的方法，这是面向对象编程中实现继承和方法重写的重要机制之一。

Runtime的API有哪些？

Runtime的API在Objective-C中扮演着重要角色，它们允许开发者在运行时动态地查询和操作类和对象。以下是一些主要的Runtime API：

  1. objc_系列函数：
    • objc_getClass：根据类名获取类对象。
    • objc_getClassList：获取已注册的所有类。
    • objc_lookUpClass：查找并返回类对象，如果类不存在则返回nil。
    • objc_allocateClassPair：创建一个新的类，这个新类继承自指定的超类，并且添加了额外的变量和函数到类定义中。
  2. class_系列函数：
    • class_getName：获取类的名称。
    • class_getSuperclass：获取类的超类。
    • class_addMethod：为类添加新方法。
    • class_replaceMethod：替换类中的现有方法。
    • class_getMethodImplementation 和 class_setMethodImplementation：获取或设置方法的实现。
    • class_copyMethodList：获取类中所有方法的列表。
  3. object_系列函数：
    • object_getClass：获取对象的类。
    • object_setInstanceVariable 和 object_getInstanceVariable：设置或获取对象的实例变量值。
  4. method_系列函数：
    • method_getName：获取方法的名称。
    • method_getImplementation：获取方法的实现地址。
    • method_getTypeEncoding：获取方法的类型编码字符串。
    • method_setImplementation：设置方法的实现。
    • method_exchangeImplementations：交换两个方法的实现。
  5. property_系列函数：
    • class_addProperty：为类添加属性。
    • property_getName：获取属性的名称。
    • property_getAttributes：获取属性的属性列表。
  6. protocol_系列函数：
    • class_addProtocol：为类添加协议。
    • class_conformsToProtocol：检查类是否遵循特定协议。
    • protocol_getName：获取协议的名称。
    • protocol_getMethodDescription：获取协议中指定方法的描述。
  7. ivar_系列函数：
    • class_addIvar：为类添加实例变量。
    • class_copyIvarList：获取类中所有实例变量的列表。
    • ivar_getName：获取实例变量的名称。
    • ivar_getTypeEncoding：获取实例变量的类型编码字符串。
  8. sel_系列函数：
    • sel_getName：根据给定的选择器获取其名称。
    • sel_getUid：根据给定的字符串获取选择器。
    • sel_isEqual：比较两个选择器是否相等。
  9. imp_系列函数：
    • 这些函数允许你直接操作方法的实现，例如imp_implementationWithBlock可以从一个block创建一个方法实现。

请注意，虽然Runtime API提供了强大的动态能力，但也需要谨慎使用以避免引入难以调试的问题或安全隐患。同时，随着Swift的流行，许多开发者可能更倾向于使用Swift的静态类型系统和编译时检查，而不是依赖Objective-C的Runtime特性。

9、OC中Runloop原理与使用

什么是Runloop？有什么作用？常用来做什么？

RunLoop是一个运行循环，它是处理线程事件的一种机制。以下是关于RunLoop的详细解释：

一、RunLoop的定义

RunLoop，即运行循环，是操作系统中用于处理线程事件的一个机制。它可以保持程序持续运行，并处理应用程序中的各种事件，如触摸事件、定时器事件等。

二、RunLoop的作用

  1. 保持程序持续运行：RunLoop会接收并处理各种输入源的事件，从而保持程序的持续运行状态，防止程序退出。
  2. 处理App中的各种事件：包括触摸事件、定时器事件、Selector事件等。这些事件是应用程序与用户交互的重要方式。
  3. 节省CPU资源，提高程序性能：当没有事件需要处理时，RunLoop会让线程进入休眠状态，从而释放CPU资源去做其他的事情。当有事件需要处理时，RunLoop会立即唤醒线程去处理事件。

三、RunLoop的常用场景

  1. 定时器（Timer）：RunLoop可以用于实现定时器功能，定时触发特定的任务。
  2. PerformSelector：可以在指定的RunLoop上执行某个方法。
  3. 界面刷新和网络请求：RunLoop常用于处理界面刷新事件和网络请求事件，确保用户界面的流畅性和网络数据的及时处理。
  4. 手势识别和事件详情处理：RunLoop可以接收并处理手势识别事件和其他用户交互事件。
  5. AutoreleasePool：RunLoop也与内存管理相关，特别是在使用自动释放池（AutoreleasePool）时，RunLoop会在每次迭代结束时释放池中的对象，从而帮助管理内存。

总的来说，RunLoop是iOS和macOS开发中非常重要的一个概念，它确保了程序的持续运行和事件的及时处理，同时也有助于提高程序的性能和响应速度。

Runloop与线程之间的关系？

RunLoop与线程之间的关系可以归纳为以下几点：

  1. 一一对应关系：每个线程，包括程序的主线程，都有与之相应的RunLoop对象。这种关系是一一对应的，即一条线程对应一个RunLoop对象。RunLoop对象在第一次获取时创建，并在线程结束时销毁。

  2. 互操作性：我们只能在当前线程中操作当前线程的RunLoop，而不能去操作其他线程的RunLoop。这是因为RunLoop是与线程紧密绑定的，并且它们的操作是线程安全的。

  3. 主线程与子线程的差异：主线程的RunLoop默认是启动的，而子线程的RunLoop默认是不开启的，需要我们自己手动开启循环。这是因为主线程通常负责处理用户界面和交互事件，因此需要持续运行；而子线程则可能用于执行后台任务，不需要持续运行。

如果子线程不需要持续运行或者只执行一些短暂的、一次性的任务，那么通常不需要启动RunLoop。RunLoop的主要目的是使线程在没有任务执行时保持等待状态，以便随时准备处理新的事件或任务。对于不需要长时间运行的子线程，启动RunLoop可能没有必要，甚至会增加不必要的资源消耗。

然而，在某些情况下，即使在子线程中，启动RunLoop也可能是有益的。例如：

  • 如果你需要在子线程中处理异步事件，如网络响应或定时器事件。
  • 如果子线程需要等待某些条件成立才能继续执行，而这些条件可能由其他线程或外部事件触发。

在这些情况下，启动RunLoop可以让子线程在等待时保持休眠状态，从而降低CPU使用率，并在条件满足时立即被唤醒以继续执行任务。 是否启动子线程的RunLoop取决于你的具体需求。如果子线程只是执行简单的、一次性的任务，并且不需要处理异步事件或等待外部触发条件，那么不启动RunLoop是合适的。如果需要处理异步事件或等待外部条件，则启动RunLoop可能是一个好选择。

  1. RunLoop对线程的影响：如果没有RunLoop，线程执行完任务后就会退出。特别是，对于主线程来说，如果没有RunLoop或者RunLoop没有启动，那么主线程在执行完main()函数后就会退出，这将导致应用程序无法保持运行状态。

  2. 资源管理与性能优化：RunLoop通过节省CPU资源和提高程序性能来优化线程的运行。当线程中没有任务需要处理时，RunLoop可以让线程进入休眠状态，从而释放CPU资源去做其他的事情。当有任务需要处理时，RunLoop会立即唤醒线程去执行任务。

综上所述，RunLoop与线程之间存在着紧密的关系。它们相互依赖、相互影响，共同确保程序的持续运行和高效性能。

Runloop在内存中如何存储？

RunLoop在内存中的存储方式主要涉及以下几个关键方面：

  1. 与线程的关联存储：
    • 每条线程都有一个与之唯一对应的RunLoop对象。这种对应关系确保了线程和RunLoop之间的紧密绑定。
    • RunLoop对象实际上是在第一次被线程获取时创建的，并且会在线程结束时被销毁。这种动态创建和销毁的机制有助于节省系统资源。
  2. 全局Dictionary中的存储：
    • RunLoop对象保存在一个全局的Dictionary（字典）里，其中线程作为key（键），RunLoop作为value（值）。这种键值对的存储方式便于根据线程快速查找其对应的RunLoop。
  3. RunLoop的结构体：
    • RunLoop的底层实际上是一个结构体（如CFRunLoopRef在Core Foundation框架中表示）。这个结构体中包含了多个关键成员，这些成员用于存储和管理RunLoop的状态和行为。
    • 结构体内通常包含指向当前运行模式的指针、RunLoop所有模式的集合、以及一些与RunLoop运行密切相关的其他信息（如commonModes和commonModeItems等）。
  4. 模式与事件源、定时器、观察者的关联：
    • RunLoop中包含了若干个运行模式（RunLoopMode），每个模式下又管理着若干个事件源（Source）、定时器（Timer）和观察者（Observer）。
    • 这些元素在RunLoop中被有序地组织和管理，以便在RunLoop运行时能够高效地处理各种事件和消息。

综上所述，RunLoop在内存中的存储是通过与线程的紧密关联、全局字典的键值对映射、以及内部结构体的精细组织来实现的。这种存储方式确保了RunLoop能够高效地处理线程中的事件和消息，从而维护程序的持续运行和响应性。

Runloop相关的类有哪些？

RunLoop相关的类主要包括以下几个：

  1. NSRunLoop：
    • 这是Objective-C中对RunLoop的封装类，提供了与RunLoop交互的接口。通过NSRunLoop类，我们可以添加和移除事件源、定时器和观察者，也可以控制RunLoop的运行和停止。
  2. CFRunLoopRef：
    • 在Core Foundation框架中，RunLoop被表示为CFRunLoopRef类型。这是RunLoop的C语言接口，提供了与Objective-C中NSRunLoop类似的功能，但使用C语言的API进行交互。
  3. RunLoopMode：
    • RunLoopMode表示RunLoop的运行模式。一个RunLoop可以有多个模式，每个模式下可以关联不同的事件源、定时器和观察者。常见的RunLoopMode有kCFRunLoopDefaultMode（默认模式）和kCFRunLoopCommonModes（公共模式）等。
  4. RunLoopSource：
    • RunLoopSource是RunLoop的事件源类。事件源负责生成事件并发送给RunLoop处理。根据处理方式的不同，事件源可以分为两类：基于端口的源（Port-Based Sources）和自定义的源（Custom Input Sources）。其中，基于端口的源通常与内核或其他进程进行通信，而自定义的源则用于处理应用程序内部的事件。
  5. RunLoopTimer：
    • RunLoopTimer是RunLoop的定时器类。定时器可以在指定的时间间隔后触发回调函数，用于执行定时任务或周期性任务。
  6. RunLoopObserver：
    • RunLoopObserver是RunLoop的观察者类。观察者可以在RunLoop的特定阶段被触发，用于监控RunLoop的状态和行为。例如，可以在RunLoop开始、结束、进入休眠等关键时刻触发观察者的回调函数。

这些类共同构成了RunLoop的核心结构和功能，使得RunLoop能够高效地处理线程中的事件和消息，从而维护程序的持续运行和响应性。

CFRunLoopModeRef是什么？有哪几种mode?

CFRunLoopModeRef是一个代表RunLoop运行模式的标识符。在RunLoop中，模式是指RunLoop运行的一种特定状态配置，它决定了哪些事件源、定时器和观察者会被RunLoop处理。

关于CFRunLoopModeRef的具体模式，主要包括以下几种：

  1. kCFRunLoopDefaultMode：
    • 这是App的默认模式，通常主线程是在这个模式下运行。它处理大多数用户界面的更新事件和一些标准的系统事件。
  2. UITrackingRunLoopMode：
    • 界面跟踪模式，用于ScrollView追踪触摸滑动等界面交互事件。这个模式确保了在用户滑动界面时，不受其他模式的影响，提供流畅的滑动体验。
  3. UIInitializationRunLoopMode：
    • 应用程序刚启动时进入的第一个模式。在App完成初始化后，此模式就不再使用，它是为了完成App启动初期的设置工作。
  4. GSEventReceiveRunLoopMode：
    • 这是一个接受系统事件的内部模式，通常开发者不需要直接使用这个模式，它主要用于系统内部处理事件。
  5. kCFRunLoopCommonModes：
    • 这是一个特殊的标记模式，并不是一个真正的运行模式。它用于标记一组通用的模式，让你可以将事件源、定时器和观察者同时添加到多个模式中，而不需要分别为每个模式添加。通常，kCFRunLoopDefaultMode和UITrackingRunLoopMode都会被添加到这个common modes集合中。

这些模式使得RunLoop能够灵活地处理不同类型的事件和任务，同时保持高效和响应性。通过合理选择和配置这些模式，开发者可以优化应用程序的性能和用户体验。

Source0/Source1/Timer/Observer是什么，与mode有什么关系？

Source0、Source1、Timer、Observer是RunLoop中的关键元素，它们与RunLoop中的mode有密切关系。下面将分别解释这些元素，并阐述它们与mode的关系：

1. Source0：

  • 定义：Source0是RunLoop的一种事件源，它处理的是非基于Port的事件。这些事件通常来自应用程序内部，比如用户交互或自定义的事件。
  • 与mode的关系：在RunLoop的某个特定mode下，Source0可以被注册并监听特定的事件。当这些事件发生时，RunLoop会在当前mode下捕获并处理它们。

2. Source1：

  • 定义：Source1是另一种RunLoop的事件源，它基于mach port接收事件。这些事件通常来自系统内核或其他进程。
  • 与mode的关系：与Source0类似，Source1也是在RunLoop的某个mode下注册并工作的。当系统事件或其他进程发送消息到mach port时，RunLoop会在当前mode下接收并处理这些事件。

3. Timer：

  • 定义：Timer是RunLoop中的定时器，用于在指定时间或周期性地触发回调函数。
  • 与mode的关系：Timer可以在RunLoop的某个mode下注册，并在该mode下运行。当定时器到达设定的触发时间时，RunLoop会在当前mode下调用相应的回调函数。

4. Observer：

  • 定义：Observer是RunLoop的观察者，用于监听RunLoop的状态改变或其他特定事件。
  • 与mode的关系：Observer可以在RunLoop的某个mode下注册，以便在该mode下监听特定的事件或状态改变。例如，可以监听RunLoop的启动、停止、进入休眠等关键时刻。

总的来说，Source0、Source1、Timer和Observer都是RunLoop的重要组成部分，并且它们与RunLoop的mode密切相关。这些元素在特定的mode下注册并工作，使得RunLoop能够灵活地处理各种事件和任务。通过合理地配置这些元素和mode，开发者可以实现高效且响应迅速的应用程序。

CFRunLoopObserverRef包含哪几种状态？

CFRunLoopObserverRef包含的状态主要有以下几种：

  1. kCFRunLoopEntry：此状态表示即将进入RunLoop。这是RunLoop启动或准备开始处理事件的状态。

  2. kCFRunLoopBeforeTimers：此状态表示RunLoop即将处理定时器事件。在RunLoop的这个阶段，它会检查所有注册的定时器，看是否有任何定时器到期需要触发。

  3. kCFRunLoopBeforeSources：此状态意味着RunLoop即将处理输入源事件。输入源可以是自定义的或者是系统定义的，比如用户交互事件或其他信号。

  4. kCFRunLoopBeforeWaiting：在这个状态下，RunLoop准备进入休眠，等待新的事件或消息到来。如果没有任何事件源或定时器需要处理，RunLoop会在此状态下停留，以减少CPU的占用。

  5. kCFRunLoopAfterWaiting：当RunLoop从休眠中唤醒时，会达到这个状态。这通常意味着有新的事件或消息需要处理。

  6. kCFRunLoopExit：此状态表示RunLoop即将退出或结束其当前循环。这通常发生在RunLoop处理完所有待处理的事件后，或者明确被停止。

  7. kCFRunLoopAllActivities：这是一个特殊的标记，用于监听RunLoop的所有状态改变。当使用此标记时，Observer会在上述任何一个状态改变时被触发。

这些状态提供了对RunLoop运行过程的细致观察，允许开发者在RunLoop的不同阶段执行特定的操作或响应特定的事件。

如何监听RunLoop的所有状态？

监听RunLoop的所有状态可以通过创建一个CFRunLoopObserverRef并设置其活动为kCFRunLoopAllActivities来实现。以下是具体的步骤：

  1. 创建RunLoop观察者：
    • 使用CFRunLoopObserverCreate函数来创建一个RunLoop观察者。这个函数需要指定要监听的活动类型，为了监听所有状态，应使用kCFRunLoopAllActivities作为参数。
  2. 设置观察者的回调函数：
    • 在创建观察者时，需要提供一个回调函数。这个函数会在RunLoop状态改变时被调用。
    • 回调函数通常具有固定的函数签名，并接收有关RunLoop和当前状态的信息作为参数。
  3. 将观察者添加到RunLoop中：
    • 使用CFRunLoopAddObserver函数将创建的观察者添加到RunLoop中。
    • 可以选择将其添加到特定的RunLoop模式中，或者添加到所有模式中，以监听所有模式下的状态改变。
  4. 实现回调函数以处理状态改变：
    • 在回调函数中，根据传入的RunLoop活动类型，可以判断出RunLoop当前的状态。
    • 根据状态的不同，执行相应的操作或记录。
  5. 管理和移除观察者：
    • 当不再需要监听RunLoop状态时，应使用CFRunLoopRemoveObserver函数从RunLoop中移除观察者。
    • 注意在适当的时机释放观察者的内存，以避免内存泄漏。
  6. 测试和调试：
    • 在实际应用中，添加监听器后，应进行充分的测试以确保其正常工作。
    • 可以使用日志、断点或其他调试工具来验证状态改变的监听是否正确实现。

通过以上步骤，就可以成功地监听RunLoop的所有状态改变，并在回调函数中根据需要进行相应的处理。

Runloop具体流程？

RunLoop的具体流程可以归纳为以下几个步骤：

  1. 启动RunLoop：
    • 当线程启动RunLoop时，RunLoop会进入持续运行状态，准备接收并处理事件。
  2. 接收并处理事件：
    • RunLoop接收来自各种事件源（如用户交互、定时器触发、网络请求等）的事件。
    • 这些事件会被加入到RunLoop的事件队列中等待处理。
  3. 事件循环：
    • RunLoop进入一个循环，不断地从事件队列中取出事件进行处理。
    • 事件的处理包括调用相应的回调函数或方法，执行与事件相关的操作。
  4. 进入休眠与唤醒：
    • 当事件队列为空时，RunLoop会进入休眠状态，等待新的事件到来。
    • 一旦有新事件加入队列，RunLoop会被唤醒并继续处理事件。
  5. 处理定时器事件：
    • 如果RunLoop中有定时器，它会在指定的时间间隔后触发定时器事件。
    • 定时器事件的处理方式与其他事件类似，通过调用相应的回调函数或方法来完成。
  6. 处理输入源事件：
    • 输入源可以是自定义的或是系统提供的，如用户交互事件、文件描述符事件等。
    • 当输入源有事件发生时，RunLoop会捕获并处理这些事件。
  7. 观察者监听：
    • RunLoop的状态改变可以被观察者（Observer）监听。
    • 观察者可以在RunLoop的不同阶段触发回调函数，以便在特定状态下执行自定义的操作。
  8. 结束RunLoop：
    • 当RunLoop没有更多事件需要处理，或者显式地停止RunLoop时，循环会结束。
    • 在RunLoop结束后，线程可以继续执行其他任务或退出。

此外，RunLoop还涉及不同的模式（Mode），每个模式下可以注册特定的事件源、定时器和观察者。这样，RunLoop可以在不同的模式下处理不同类型的事件，提供了更大的灵活性。

总的来说，RunLoop是一个高效的事件处理机制，它能够让线程在没有事件处理时休眠以节省CPU资源，并在有事件发生时及时唤醒并处理事件。

用户态和内核态是什么？

RunLoop的用户态和内核态是操作系统中两种重要的运行状态，它们在RunLoop的运行过程中起着关键作用。以下是关于这两种状态的详细解释：

用户态：

  • 当一个进程执行用户自己的代码时，它处于用户态。
  • 在用户态下，进程执行的是应用程序的代码，进行的是用户级别的操作，如处理用户输入、绘制图形界面等。
  • 用户态下执行的代码通常特权级别较低，受到限制，不能直接访问系统硬件资源和数据，需要通过系统调用来实现与内核态的交互。
  • 在RunLoop中，用户态是处理事件和消息的主要状态，RunLoop通过接收和分发事件来驱动应用程序的运行。

内核态：

  • 当进程需要执行系统调用或发生中断时，它会进入内核态。
  • 在内核态下，进程可以访问操作系统的核心数据结构和硬件资源，具有更高的特权级别。
  • 内核态下执行的代码通常是操作系统的一部分，负责管理系统进程、内存、设备驱动程序等核心资源。
  • 在RunLoop中，当需要处理底层系统事件或进行进程间通信时，RunLoop会进入内核态进行操作。

总的来说，用户态和内核态在RunLoop中相互配合，使得应用程序能够高效地处理各种事件和消息。用户态负责处理应用程序级别的操作，而内核态则提供底层系统支持和资源管理。这种分离的设计使得操作系统能够更好地保护核心资源，同时提供灵活的应用程序开发环境。

线程保活怎么做？

iOS线程保活通常是通过RunLoop机制来实现的。RunLoop是iOS中的一个事件循环，它可以持续等待和处理用户交互、UI渲染等事件。以下是实现iOS线程保活的一些关键步骤：

  1. 创建并启动子线程：
    • 在iOS中，主线程的RunLoop是默认开启的，但子线程的RunLoop需要手动添加和启动。
    • 可以使用NSThread或者GCD来创建一个新的子线程。
  2. 添加RunLoop到子线程：
    • 在子线程中，需要手动添加一个RunLoop。这可以通过调用[NSRunLoop currentRunLoop]来获取当前线程的RunLoop实例。
  3. 配置RunLoop：
    • 为了使RunLoop保持运行，需要向RunLoop中添加至少一个输入源（Source）、定时器（Timer）或者观察者（Observer）。
    • 最常用的方法是通过调用[runLoop addPort:[NSPort alloc] init] forMode:NSDefaultRunLoopMode]将端口作为输入源添加到RunLoop的指定模式。这可以确保RunLoop在没有任务时休眠，有任务时则立即唤醒处理。
  4. 启动RunLoop：
    • 调用RunLoop的run或runMode:beforeDate:方法来启动RunLoop。通常使用runMode:beforeDate:方法，因为它允许RunLoop在没有任务时休眠，从而节省CPU资源。
    • 注意，runUntilDate:和run方法运行的RunLoop不建议使用，因为它们可能导致RunLoop无法停止。
  5. 线程保活的停止：
    • 当不再需要保持线程活跃时，应该通过适当的方式来停止RunLoop和线程。这通常涉及到从RunLoop中移除所有的输入源、定时器和观察者，并调用RunLoop的stop方法来停止它。
    • 随后，可以安全地结束线程的执行。
  6. 注意事项：
    • 线程保活应该谨慎使用，因为它会占用系统资源。只有在确实需要长时间运行后台任务，且这些任务的执行间隔不确定时，才考虑使用线程保活。
    • 在实际应用中，应根据具体情况来减少线程的创建和销毁次数，以提高性能。

通过遵循以上步骤，你可以在iOS中实现线程保活，从而提高应用程序的性能和响应能力。

10、OC中多线程实现与线程安全

iOS多线程方案有哪些？如何选择？有什么区别？

iOS多线程方案主要有以下几种：

  1. pthread：
    • pthread是一套纯C语言的通用API，适用于多种操作系统，可移植性强。
    • 它的线程生命周期需要程序员自己管理，使用难度较大，因此在iOS开发中的实际应用较少。
  2. NSThread：
    • NSThread是基于Objective-C语言的API，相对简单易用，且面向对象。
    • 线程的声明周期需要程序员自己管理，因此在iOS开发中偶尔会被使用，但并非首选方案。
  3. GCD（Grand Central Dispatch）：
    • GCD是基于C语言的API，充分利用设备的多核，旨在替换如NSThread等传统的线程技术。
    • 线程的生命周期由系统自动管理，无需开发者介入，大大降低了多线程编程的复杂性，是iOS开发中经常使用的多线程方案。
  4. NSOperation和NSOperationQueue：
    • NSOperation是基于Objective-C的API，底层实际上是建立在GCD之上，但提供了更加面向对象的使用方法。
    • 通过NSOperationQueue来管理NSOperation对象，可以很方便地控制并发线程的数量和执行顺序。
    • 线程生命周期同样由系统自动管理，是iOS开发中另一种常用的多线程方案。

如何选择：

  • 如果你的项目对底层控制有较高要求，或者你正在开发一个跨平台的库，pthread可能是一个合适的选择，但请注意其复杂性。
  • NSThread由于需要手动管理线程的生命周期，通常不推荐在大型项目中使用，除非你有特定的需求或理由。
  • GCD是Apple推荐的多线程方案，它高效、简洁且易于使用。对于大多数iOS开发者来说，GCD是首选的多线程实现方式。
  • NSOperation和NSOperationQueue在需要更高级别的线程控制时使用，比如你想轻松地取消、暂停或恢复某个操作，或者需要更精细地控制并发数。

区别：

  • pthread是跨平台的C语言API，可移植性强但使用复杂。
  • NSThread相对简单，但仍需手动管理线程生命周期。
  • GCD是Apple开发的用于多核编程的解决方案，自动管理线程生命周期，易于使用且高效。
  • NSOperation和NSOperationQueue在GCD的基础上提供了更高级的功能和更面向对象的使用方法。

串行队列，并行队列的区别？全局队列和主队列呢？

串行队列、并行队列、全局队列和主队列之间的区别如下：

一、串行队列与并行队列

  1. 执行方式：串行队列按照任务添加到队列的顺序，一个接一个地执行任务，每个任务必须在前一个任务完成后才能开始。而并行队列则可以同时执行多个任务，任务的执行顺序可能与添加到队列的顺序不同，因为它们是并发执行的。

  2. 线程使用：串行队列在任何时间点都只有一个线程在执行任务，确保任务按照FIFO（先进先出）的原则执行。并行队列则可以在任意时间点有多个线程同时执行任务，这使得任务的执行更加高效，但也可能导致竞态条件，需要额外的同步机制来避免。

二、全局队列与主队列

  1. 调度方式：全局队列是系统提供的并行队列，可以在整个应用程序中共享，并且能够在多个核心上并行处理任务。主队列则是串行队列，它专门负责在主线程上调度任务，确保所有任务按照它们被添加到队列的顺序串行执行。

  2. 线程使用与创建：全局队列使用多个线程来并发执行任务，而主队列只在主线程上执行任务。这意味着全局队列可以充分利用多核处理器的优势来提高性能，而主队列则确保任务在主线程上安全、有序地执行。

  3. 使用场景：全局队列适用于需要大量计算且可以并行处理的任务，如图像处理、大数据分析等。主队列则常用于更新UI或与UI相关的操作，因为UIKit的操作必须在主线程上执行。

串行队列和并行队列是GCD（Grand Central Dispatch）中的术语，用于描述任务执行的顺序和并发性。 而全局队列和主队列则是GCD提供的两种特殊类型的队列。

下面是一个使用Markdown表格格式的整理，对比了串行队列、并行队列、全局队列和主队列的特点：

队列类型 执行顺序 并发性 线程使用 特点与用途
串行队列 先进先出（FIFO） 低 单个线程 任务按照添加到队列的顺序一个接一个地执行，没有任务并发执行。适用于需要保证任务顺序执行的场景。
并行队列 先进先出（FIFO） 高 多个线程 多个任务可以同时执行，但任务的开始执行顺序仍然按照添加到队列的顺序。适用于可以并行处理的任务，以提高效率。
全局队列 先进先出（FIFO） 高 系统管理 GCD提供的并行队列，供整个应用使用，不需要手动创建。适用于后台任务的并发执行，如数据处理、网络请求等。
主队列 先进先出（FIFO） 低 主线程 专门负责在主线程上调度任务，用于更新UI或执行需要在主线程上完成的操作。所有任务都在主线程上顺序执行。

注意：

  1. 串行队列和并行队列的主要区别在于任务的并发性。串行队列中的任务是一个接一个地执行，而并行队列中的任务可以同时执行。
  2. 全局队列是GCD提供的并行队列，它允许任务并发执行，且不需要手动创建，适用于后台任务的处理。
  3. 主队列是特殊的串行队列，它专门负责在主线程上调度任务。由于UI更新必须在主线程上进行，因此主队列常用于更新UI界面。
  4. 不管是串行队列还是并行队列，任务的添加和取出都遵循先进先出的原则。但在并行队列中，任务的执行顺序可能由于多线程并发执行而有所变化。

综上所述，串行队列、并行队列、全局队列和主队列在执行方式、线程使用、调度方式以及使用场景等方面存在显著差异。正确选择和使用这些队列对于确保应用的性能和稳定性至关重要。

同步任务和异步任务的区别？

同步任务和异步任务的主要区别体现在它们的执行方式和对系统资源的影响上。以下是具体的分析：

一、执行方式

  1. 同步任务：当发出一个功能调用时，在没有得到结果之前，该调用会一直等待，不会返回或继续执行后续操作。这种任务按照顺序在主线程上执行，不会开启新的线程。因此，同步任务又被称为非耗时任务或阻塞任务。
  2. 异步任务：与同步任务相对，异步任务在发出调用后，调用者不必等待结果就可以继续执行后续操作。当这个调用完成后，通常通过状态、通知或回调来通知调用者。异步任务的执行不依赖于调用者的控制，它可以在主线程之外的其他线程上执行，因此也被称为耗时任务或非阻塞任务。

二、系统资源影响

  1. 同步任务：由于同步任务在主线程上顺序执行，如果某个任务执行时间过长，可能会阻塞主线程，导致用户界面无响应或响应缓慢。此外，同步任务对CPU和内存资源的占用也相对较高，因为它们需要一直占用主线程直到任务完成。
  2. 异步任务：异步任务可以在主线程之外的其他线程上执行，从而避免了阻塞主线程的问题。这使得用户界面可以保持响应，并提高了系统的并发性能。同时，异步任务可以根据系统的负载情况动态调整线程的使用，以更有效地利用系统资源。

综上所述，同步任务和异步任务的主要区别在于它们的执行方式和对系统资源的影响。同步任务按照顺序在主线程上执行，可能会阻塞主线程并占用较多的系统资源；而异步任务则可以在其他线程上并发执行，提高了系统的响应性能和资源利用率。

使用sync函数往当前串行队列中添加任务会发生什么现象？

在GCD（Grand Central Dispatch）中，如果你尝试使用 dispatch_sync 函数往当前已经在执行的串行队列中添加任务，这将会导致死锁（deadlock）。

dispatch_sync 函数会阻塞当前线程，直到提交到队列的任务完成执行。在一个串行队列的上下文中，如果你使用 dispatch_sync 提交一个任务到同一个队列，就会发生以下情况：

  1. 当前线程调用 dispatch_sync 并等待任务完成。
  2. GCD 尝试在当前串行队列中执行提交的任务。
  3. 由于串行队列中的任务是按顺序一个接一个执行的，而且当前线程正在等待新提交的任务完成，所以队列中的下一个任务（即我们通过 dispatch_sync 提交的任务）无法开始执行，因为它在等待当前任务完成。
  4. 这就形成了一个循环等待的条件：当前线程等待队列中的任务完成，而队列中的任务又需要等待当前线程释放才能开始执行。

因此，这种情况下会发生死锁，程序会挂起，无法响应。

为了避免这种情况，你可以：

  • 使用 dispatch_async 而不是 dispatch_sync，这样提交的任务会异步执行，不会阻塞当前线程。
  • 或者，将任务提交到不同的队列中，而不是当前正在执行的队列。

总的来说，当你使用 dispatch_sync 时，需要特别小心避免向当前正在执行的串行队列提交任务，以防止死锁发生。

异步并发执行任务1、任务2，等任务1、任务2都执行完毕后，再回到主线程执行任务3怎么实现？

在iOS中，你可以使用GCD（Grand Central Dispatch）的dispatch_group_t来实现异步并发执行任务，并在所有任务完成后回到主线程执行另一个任务。下面是一个简单的示例代码，展示了如何实现你的需求：

// 创建一个分组
let group = DispatchGroup()

// 异步并发执行任务1
group.enter()
DispatchQueue.global(qos: .userInitiated).async {
    // 执行任务1的代码
    print("执行任务1")
    group.leave() // 任务1完成后，离开分组
}

// 异步并发执行任务2
group.enter()
DispatchQueue.global(qos: .userInitiated).async {
    // 执行任务2的代码
    print("执行任务2")
    group.leave() // 任务2完成后，离开分组
}

// 使用notify方法来监听分组中的任务是否全部完成
group.notify(queue: DispatchQueue.main) {
    // 所有任务都完成后，回到主线程执行任务3
    print("回到主线程执行任务3")
}

在这个例子中，我们首先创建了一个DispatchGroup实例。然后，我们为每个异步任务调用group.enter()，表示有一个新的任务加入到了分组中。每个任务在执行完毕后调用group.leave()，表示该任务已经完成并从分组中离开。

最后，我们使用group.notify(queue:)方法来设置一个通知块，它会在分组中的所有任务都完成后被调用。在这个通知块中，我们回到主线程执行任务3。

请注意，这里使用了DispatchQueue.global(qos: .userInitiated)来异步执行任务1和任务2，这意味着这些任务将在后台线程上并发执行。你可以根据需要选择合适的QoS（Quality of Service）等级。当所有后台任务完成后，group.notify(queue:)中的闭包会在指定的队列（在这里是主队列）上执行。

Group，dispatch_barrier_async，dispatch_semaphore分别用来做什么？

在iOS多线程编程中，Group、dispatch_barrier_async和dispatch_semaphore各自扮演着不同的角色，用于管理和控制并发任务。以下是关于这三者的详细解释：

  1. Group：
    • 主要用于组织和同步多个并发任务。
    • 通过创建一个dispatch_group_t对象，可以将多个任务添加到这个组中。
    • 当组内的所有任务都完成后，可以通过dispatch_group_notify来触发一个回调，通常用于在所有任务完成后执行某些操作，如更新UI或进行后续的数据处理。
    • 适用于需要等待多个异步操作全部完成后再进行下一步处理的场景。
  2. dispatch_barrier_async：
    • 用于在并发队列中创建一个屏障。
    • 屏障之前的任务可以并发执行，但屏障之后的任务必须等待屏障之前的所有任务都完成后才能开始执行。
    • 屏障任务自身会阻塞队列，直到它之前的所有任务完成，然后执行屏障任务，之后再继续执行后续任务。
    • 这对于保护数据完整性或在多个读写操作中确保正确的执行顺序非常有用。
  3. dispatch_semaphore：
    • 是一个信号量工具，用于控制对共享资源的访问。
    • 通过dispatch_semaphore_create创建一个信号量，并设置初始值。
    • 使用dispatch_semaphore_wait可以减少信号量的值，如果信号量的值小于0，则当前线程会被阻塞，直到信号量的值变为非负。
    • 使用dispatch_semaphore_signal可以增加信号量的值，从而唤醒正在等待的线程。
    • 这对于限制对某一共享资源的并发访问数量非常有用，例如限制网络请求的并发数或保护某个关键代码段不被多个线程同时访问。

综上所述，Group、dispatch_barrier_async和dispatch_semaphore在iOS多线程编程中各自扮演着组织任务、设置执行屏障和控制资源共享的重要角色。

多线程安全问题有哪些？如何解决

多线程安全问题主要涉及数据的一致性和正确性问题，当多个线程同时访问和修改共享数据时，可能会出现数据不一致或错误的情况。这些问题通常包括：

  1. 原子性问题：多个线程同时读写同一数据，可能导致数据的不一致。例如，一个线程正在写入数据，而另一个线程同时读取该数据，可能会读取到部分写入的数据，从而导致数据错误。
  2. 可见性问题：一个线程修改了共享变量的值，但其他线程可能无法立即看到这种修改，因为它们可能缓存了该变量的旧值。
  3. 有序性问题：由于编译器优化或处理器指令重排，可能导致多线程环境下的指令执行顺序与预期不符，从而产生难以预料的结果。

为了解决这些问题，可以采取以下措施：

  1. 使用synchronized关键字或Lock接口实现同步：这可以确保同一时间只有一个线程能够执行某个代码块或方法，从而避免多个线程同时访问和修改共享数据。synchronized可以用于方法或代码块上，而Lock接口提供了更灵活的锁定机制。
  2. 使用volatile关键字：volatile可以确保变量的可见性，即当一个线程修改了volatile变量的值，其他线程会立即看到这个修改。但volatile并不能保证原子性，因此它通常与其他同步机制结合使用。
  3. 使用局部变量：局部变量是线程安全的，因为每个线程都有自己的栈空间，局部变量存储在每个线程的栈空间中，不会被其他线程访问。
  4. 不变模式：通过设计一个不可变对象，其状态在创建后就不能再改变，从而避免多线程环境下的数据竞争问题。
  5. 使用线程安全的数据结构：例如，使用ConcurrentHashMap、CopyOnWriteArrayList等线程安全的数据结构来存储共享数据。
  6. 避免共享状态：尽可能减少线程之间的数据共享，从而降低数据竞争的风险。例如，可以使用ThreadLocal来为每个线程创建独立的数据副本。
  7. 使用事务内存（Software Transactional Memory, STM）：STM提供了一种管理共享内存的方式，其中所有变更都是原子的，要么全部应用，要么全部不应用，从而避免了多线程环境下的数据竞争问题。

综上所述，多线程安全问题主要涉及原子性、可见性和有序性问题。为了解决这些问题，可以采取同步、使用volatile关键字、使用局部变量、不变模式、线程安全的数据结构、避免共享状态以及使用STM等措施。这些措施可以根据具体的应用场景和需求进行选择和组合使用。

自旋锁和互斥锁的区别？递归锁，条件锁是什么？

自旋锁和互斥锁的区别为：自旋锁在获取不到锁时会持续“自旋”等待，即循环判断锁是否可用，而互斥锁在获取不到锁时会将线程阻塞等待，直到获取到锁时被唤醒。这两种锁的实现机制不同，自旋锁相较于互斥锁更加底层。从效率上讲，自旋锁的效率通常高于互斥锁，因为避免了线程切换和调度的开销。但是，如果长时间的“自旋”等待，会使得CPU使用效率降低，所以自旋锁不适用于等待时间比较长的情况。另外，自旋锁通常用于内核代码中，而互斥锁则更常用于用户态应用程序。

递归锁（Recursive Lock）是一种特殊的锁，允许同一个线程多次获取同一个锁而不会造成死锁。这种锁对于递归函数或者需要多次进入临界区的场景非常有用。递归锁具有可重入性，即同一个线程可以多次加锁，但必须相应地多次解锁才能完全释放该锁。

条件锁（也称为条件变量）则是一种与互斥量配合使用的同步机制。它用于在某个条件未满足时使线程阻塞等待，直到条件满足时才继续执行。条件锁强调的是条件等待而不是互斥。通常，条件锁会与互斥锁一起使用，以保护共享资源并在特定条件成立时唤醒等待的线程。

总的来说：

  1. 自旋锁和互斥锁的主要区别在于等待锁的方式和效率。
  2. 递归锁允许同一线程多次获取同一把锁，适用于递归或需要重复进入临界区的场景。
  3. 条件锁则用于在满足特定条件之前阻塞线程，常与互斥锁配合使用。

atomic，noatomic的区别？

atomic和noatomic的主要区别体现在线程安全性和性能开销上。以下是详细的对比：

  1. 线程安全性：
    • atomic：原子的，提供线程安全。它能防止在写未完成时被另一个线程读取，从而造成数据错误，即阻止两个线程同时更新一个值。这是通过确保对属性的访问（特别是写操作）在任何时候都是原子的，从而避免多个线程同时修改数据所可能产生的问题。
    • noatomic：非原子的，非线程安全的。这意味着在多线程环境中，如果不采取额外的同步措施，对noatomic属性的并发访问可能会导致数据竞争和不一致的结果。
  2. 性能开销：
    • atomic：由于需要确保线程安全，atomic属性通常会带来一定的性能开销。这是因为系统需要实现额外的机制来同步对属性的访问，以防止数据竞争。
    • noatomic：由于没有线程安全的需求，noatomic属性通常具有更高的性能。系统无需实现额外的同步机制，因此可以减少不必要的开销。

在iOS开发中，开发者经常需要在atomic和noatomic之间做出选择。一般来说，如果属性只会在一个线程中被访问，或者开发者已经通过其他方式（如使用锁或其他同步机制）确保了线程安全，那么通常会选择noatomic以提高性能。然而，在需要确保多个线程安全地访问属性的情况下，atomic则是一个更好的选择。

总的来说，atomic和noatomic的选择取决于具体的应用场景和需求。在选择时，开发者需要权衡线程安全性和性能开销之间的平衡。

iOS读写安全方案有哪些？

iOS读写安全方案主要包括以下几种：

  1. 使用atomic属性：
    • atomic用于保证属性setter（写）和getter（读）的原子性操作。
    • 相当于在setter和getter方法中添加了线程同步锁，确保同一时间只有一个线程可以访问属性。
    • 但需要注意的是，atomic只能保证单个属性的读写安全，对于更复杂的多步操作或涉及多个属性的情况，atomic可能不够充分。
  2. 多读单写模式：
    • 为了保证读写安全并提升性能，一般采取“多读单写”模式。
    • 即对同一资源，同一时间，只能有一个写操作，但可以有多个读操作。
    • 读、写两种操作不能同时进行，这可以通过各种锁机制来实现。
  3. 使用锁机制：
    • iOS开发中可以使用各种锁来确保读写安全，如互斥锁（mutex）、读写锁（read-write lock）、自旋锁（spinlock）等。
    • 锁机制可以控制对共享资源的访问，确保同一时间只有一个线程能够修改数据。
  4. GCD（Grand Central Dispatch）：
    • 使用GCD的串行队列可以确保任务按照提交的顺序一个接一个地执行，从而实现读写安全。
    • 也可以通过GCD的并发队列和屏障（barrier）任务来实现更复杂的同步需求。
  5. 事务内存（Software Transactional Memory, STM）：
    • STM提供了一种管理共享内存的方式，其中所有变更都是原子的，要么全部应用，要么全部不应用。
    • 这可以避免多线程环境下的数据竞争问题，但STM在iOS开发中并不常见，更多是在其他编程环境和语言中应用。
  6. 沙盒机制：
    • 每个iOS应用程序都会为自己创建一个文件系统目录（沙盒），应用程序只能在为该应用程序创建的文件夹（沙盒）内访问文件。
    • 这虽然主要是文件系统的隔离措施，但也间接为文件读写提供了一定程度的安全性。

综上所述，iOS读写安全方案包括使用atomic属性、多读单写模式、锁机制、GCD以及沙盒机制等。这些方案可以根据具体的应用场景和需求进行选择和组合使用。在实际开发中，需要根据具体情况权衡性能、安全性和易用性等因素来选择合适的方案。

dispatch_barrier_async 如果传入的是一个串行或是一个全局的并发队列会发生什么现象？

dispatch_barrier_async 是 GCD (Grand Central Dispatch) 中的一个函数，它用于在并发队列中插入一个屏障。屏障之前的任务可以并发执行，但屏障之后的任务必须等待屏障之前的所有任务完成后再执行。屏障任务自身也会阻塞队列，直到它之前的所有任务完成，然后执行屏障任务，屏障任务执行完毕后，队列恢复并发执行后续任务。

现在，让我们来探讨一下在不同的队列类型中使用 dispatch_barrier_async 的情况：

  1. 串行队列（Serial Queue）： 在串行队列中使用 dispatch_barrier_async 实际上没有太大的意义，因为串行队列中的任务本来就是顺序执行的。当你在串行队列中提交一个屏障任务时，该任务会像其他普通任务一样按顺序执行。它不会阻塞队列，因为串行队列中的任务已经是一个接一个地执行了。所以，在串行队列中使用 dispatch_barrier_async 并不会产生屏障效果，它只是作为一个普通的异步任务执行。

  2. 全局并发队列（Global Concurrent Queue）或自定义并发队列： 在并发队列中使用 dispatch_barrier_async 时，屏障功能才会真正发挥作用。当你向并发队列提交一个屏障任务时，该任务会等待队列中所有在它之前提交的任务完成后再执行。在屏障任务执行期间，队列会被阻塞，不会开始执行任何新的任务。一旦屏障任务完成，队列将恢复并发执行状态，之前被阻塞的任务现在可以开始执行。

简而言之，在串行队列中使用 dispatch_barrier_async 并不会产生特殊的屏障效果，而在并发队列中使用时，它会创建一个阻塞点，确保屏障之前的所有任务都完成后才执行屏障任务，屏障任务完成后，后续任务才能继续执行。如果尝试在全局并发队列上使用 dispatch_barrier_async，苹果文档指出这可能会导致未定义的行为，因此通常不推荐在全局并发队列上使用屏障。相反，应该创建自定义的并发队列来使用屏障功能。

目录
分类标签
iOS Mac Jekyll Python 教程 面试 Swift 闭包 block 响应式编程 内存管理 多线程 网络 协议 加密 算法 Objective-C C 宏定义 SwiftUI git Xcode