iOS大厂面试查漏补缺_ios if (layoutcache && currentclass) {

一、UI方面

1. UI卡顿问题

1. 原因
   • 屏幕垂直信号之间是一帧率，16.7ms
   • CPU计算，GPU渲染，这两步要在一帧的时间完成。
   • 如果没完成，就会出现卡顿，掉帧情况
2. 优化方案
   • CPU层面：
   • 尽量用更加轻量级的对象，比如不需要处理事件的视图，可以用CALayer代替UIView
   • 图片的解码，可以在子线程用CGBitmapContext绘制，然后从Bitmap中创建图片
   • 尽量不要对UIView频繁调用属性修改，frame,bounds,transform等修改
   • 尽量提前计算好布局，在有需要的时候一次性调整对应的属性
   • Autolayout会比直接设置frame消耗更多的CPU资源，所以尽量直接设置frame
   • 图片的size最好刚好跟UIImageView的size保持一致
   • 控制线程的最大并发数量
   • 对象创建、及时销毁
   • 文本等预排版（boudingRectWithSize && drawWithRect 这两个方法）
   • GPU层面：
   • 避免离屏渲染（避免设置圆角带来离屏渲染：贝塞尔曲线绘制）
   • 减少视图层级（Texture/ASDK 就是通过pre-composing技术，提前把多个sub-layer合成渲染为一张图片，减少视图层级，大大提高渲染效率）

2. 聊聊WebView？

• 使用
• 1. 设置uiDelegate和navigationDelegate
• 2. 设置config
  • 其中config里面，设置userContentController的时候，注意添加JS脚本监听的时候，防止循环引用
  • 通过创建中间类弱引用，让WKScripMessageHandler类设置为弱类型。
• 3. 实现代理事件
  • uiDelegate: 处理JS脚本，确认框，警告等
  • navigationDelegate: 处理跳转，加载页面等
  • decisionHandler方法一定要实现，否则点击跳转链接就会崩溃

3. 事件响应链是如何传递的？

事件传递 & 事件响应

• 事件传递： 从UIApplication到UIWindow，再顺着子视图往下找，根据两个方法
  • pointInSide: withEvent
  • hitTest: withEvent
• 事件响应
  - 从传递最后确认的视图开始，验证是否能处理响应事件，如果不能就顺着视图往上找父视图，如果可以处理，就处理了，和事件传递大致相反，根据判断方法
  • touchesBegan: withEvent
  • touchesMoved: withEvent

4. layoutsubviews是在什么时机调用的？

• init初始化是不会触发
• addSubview会触发
• 设置frame且前后值发生变化，frame为zero且不添加到指定视图，不会触发
• 旋转screen会触发父视图的layoutSubviews
• 滚动UIScrollView引起View重新布局时候会触发layoutSubviews

5. sizeThatFits 和 sizeToFit的区别

• UIView如果设置过autolayout约束，则该sizeToFit方法失效
• 调用sizeToFit会自动调用sizeThatFits
• 自定义View的时候，不应该重写sizeToFit方法，应该重写sizeThatFits，在合适的地方只需要调用sizeToFit方法，就会自动触发sizeThatFits方法
• sizeToFit可以改变UIView的frame，sizeThatFit不会改变UIView的frame
• 它们都没有递归，不管subviews，只管自己
• 参考链接

二、网络方面

1. 网络请求缓存问题？
   • 空间：URLCache是苹果提供的网络请求缓存类，主要用于GET方法，请求资源用的。默认内存是512K，磁盘10M,也可以自己修改
   • 策略：6种，使用缓存，不使用缓存，实现，不实现等等。
   • 更新缓存内容：
   • Last-Modified：服务器会在资源后面有个标记Last-Modified,表示最后修改时间。第一次请求会缓存这个时间，后面请求时候，发送一个If-Modified-Since报头。如果返回304就不会传输资源数据，用本地缓存的即可。否则会传输资源。
   • Etag：服务器对资源实体用Etag来标记，就是对实体进行散列计算，得到唯一值。第二次请求，对这个值进行比较。如果返回304就数据为空，和上述情况一样。

三、安全方面

1. Mach-O

1. • Mach Object的缩写，是mac及iOS上可执行文件的格式，不一定是可执行，只是一种文件格式。
   • 包含类型：
   • 1. OBJECT：.o 或 .a 文件（目标文件）
   • 2. EXECUTE：指的是IPA拆包后的文件（可执行文件）
   • 3. DYLIB：指的是.dylib 或 .framework （动态库文件）
   • 4. DYLINKER：指的是动态连接器（动态库连接器文件）
   • 5. DSYM：（符号表），指的是有保存符号信息用于分析闪退信息的文件（符号表文件）
   • 加载过程
   • 1. 把可执行文件加载到内存中
   • 2. 从可执行文件中分析dyld的路径
   • 3. 把dyld 加载到内存中
   • 4. dyld 递归加载所有的动态连接库dylib

2. ldid重签名

2. • 1. 用ldid -e 命令导出可执行文件的签名文件entitlements
   • 2. 用越狱了的手机，导出SpringBoard的签名文件entitlements
   • 3. 把SpringBoard的签名文件覆盖自己的APP的签名文件entitlements

3. 怎么防止应用crash?不用bugly记录crash?

四、底层原理

1. OC为什么要设计Metaclass？

1. • 这个是要从面向对象设计的哲学去考虑这个问题
   • 第一：提取出某一种群体的特性，对这类群体进行划分，从而有基本的属性成员信息、方法信息
     第二：可以复用消息传递，在OC的消息传递过程中，只要是这个群体的实体，就不需要关心自身的类型是什么，只需要关心这个接口。在传递消息的时候就可以复用了。
     第三：对于描述这个类的类，即元类，对于类的类方法而言，就类似实例的实例方法，也需要这么一个复用消息传递机制，所以也就产生了针对类的元类，本质上来说，我认为也是消息传递的复用工具

2. 类可以调用对象方法吗？

1. • 可以，因为基类的super-class指针，指向的是类。

3. isa的指针指向？

1. • 1. 实例对象的isa指向类对象，类对象的isa指向元类
   • 2. isa指向，在不同平台（arm64 或 x86）通过掩码计算，来得到真实的地址值。

4. KVO? 键值监听

1. • 1. 使用：
        [self.person addObserver:self forKeyPath:@"age" options:options context:nil];
   • 2. 本质：
        第一：NSKVONotifying_Person 继承 Person 类
        第二：在set方法里，增加了willChange和didChange方法
        第三：联想到在swift 里，我们可以写属性监听器
        第四：从runtime的角度也可以验证，通过调用methodForSelector方法，查看实际上调用的方法是什么
        第五：从runtime调用class_copyMethodList方法，也可以获取添加监听后的类的所有的方法列表，打印就会发现与添加之前不一样了。
        第六：从runtime调用object_getClass获取类名，打印也会发现与添加之前不一样
   • 3. 手动触发KVO?
        第一：只需要手动在合适的地方添加willChange和didChange方法
        第二：通过-> 方式赋值，不会调用set方法，不会触发KVO

5. KVC 键值编码

1. • 1. 使用
        [self.person setValue:@10 forKey:@"age"];
[self.person setValue:@20 forKeyPath:@"cat.weight"];
   • 2. 原理
        第一：赋值
        setKey
        _setKey
        _key
        _isKey
        key
        isKey
        第二：取值
        getKey
        Key
        isKey
        _key
   • 3. 所以，KVC是可以触发KVO的，因为会调用set方法

6. Category的理解？

1. 分类的使用场景：一般业务比较复杂，需要将一部分功能或业务逻辑分模块出来，就可以用分类

2. Category的本质

   • 通过runtime加载某个类的所有Category数据
   • 把所有的Category的方法、属性、协议，的数据，合并到一个大数组中
     • 后编译的Category数据，会在数组的前面，所以后编译的Category会被先调用
     • 如果分类中含有和原类的类方法同名的，就会先调用分类的方法
     • 通过runtime关联属性
       • objc_setAssociatedObject
       • objc_getAssociatedObject
       • 关联对象并不是存储在被关联的对象中，而是存储在全局统一的AssociationsManager中
       • 设置关联对象为nil，就是相当于移除关联对象

3. Category和Extension的区别（OC里）

• 区别一
  • extension在编译期决议，它是类的一部分，在编译期和头文件里的@interface以及实现文件里的@implement一起形成一个完整的类，它伴随类的产生而产生，亦随之一起消亡。
  • extension一般用来隐藏类的私有信息，你必须有一个类的源码才能为一个类添加extension，所以你无法为系统的类比如NSString添加extension。
• 区别二
  • 但是category则完全不一样，它是在运行期决议的。 就category和extension的区别来看，我们可以推导出一个明显的事实，extension可以添加实例变量，而category是无法添加实例变量的（因为在运行期，对象的内存布局已经确定，如果添加实例变量就会破坏类的内部布局，这对编译型语言来说是灾难性的）。
• 区别三
  • 会在APP冷启动第二阶段调用，category附加到类的工作会先于+load方法的执行。

4. Runtime给Category动态添加方法、属性

• 关联对象都由AssociationsManager管理。AssociationsManager里面是由一个静态AssociationsHashMap来存储所有的关联对象的。
• 而map的的key是这个对象的指针地址（任意两个不同对象的指针地址一定是不同的），而这个map的value又是另外一个AssociationsHashMap，里面保存了关联对象的kv对。
• runtime的销毁对象函数objc_destructInstance里面会判断这个对象有没有关联对象，如果有，会调用_object_remove_assocations做关联对象的清理工作

4. 调用被覆盖的方法？

• 通过class_copyMethodList，把所有的方法列表获取到。
• 然后for循环，把最后一个方法的名字进行匹配。

Class currentClass = [TestClass class];
TestClass *my = [[TestClass alloc] init];

if (currentClass) {
    unsigned int methodCount;
    Method *methodList = class_copyMethodList(currentClass, &methodCount);
    IMP lastImp = NULL;
    SEL lastSel = NULL;
    for (NSInteger i = 0; i < methodCount; i++) {
        Method method = methodList[i];
        NSString *methodName = [NSString stringWithCString:sel_getName(method_getName(method)) 
                                        encoding:NSUTF8StringEncoding];
        if ([@"printName" isEqualToString:methodName]) {
            lastImp = method_getImplementation(method);
            lastSel = method_getName(method);
        }
    }
    typedef void (*fn)(id,SEL);

    if (lastImp != NULL) {
        fn f = (fn)lastImp;
        f(my, lastSel);
    }
    free(methodList);
}   

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

5. class的结构

在oc中打开objc.h

typedef struct objc_class *Class;     //Class是指向结构体objc_class的指针

struct objc_class {
    Class _Nonnull isa  OBJC_ISA_AVAILABILITY; //isa，代表的是该类类对象

#if !__OBJC2__
    Class _Nullable super_class                              OBJC2_UNAVAILABLE; //父类
    const char * _Nonnull name                               OBJC2_UNAVAILABLE; //类名
    long version                                             OBJC2_UNAVAILABLE; 
    long info                                                OBJC2_UNAVAILABLE;
    long instance_size                                       OBJC2_UNAVAILABLE; //对象大小
    struct objc_ivar_list * _Nullable ivars                  OBJC2_UNAVAILABLE; //成员变量列表
    struct objc_method_list * _Nullable * _Nullable methodLists                    OBJC2_UNAVAILABLE; //实例方法列表
    struct objc_cache * _Nonnull cache                       OBJC2_UNAVAILABLE; //方法缓存列表（是个hash表），用来消息发送时候，快速查找方法
    struct objc_protocol_list * _Nullable protocols          OBJC2_UNAVAILABLE; //类实现协议列表
#endif

} OBJC2_UNAVAILABLE;
/* Use `Class` instead of `struct objc_class *` */

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

7. load、initialize方法

1. • 调用顺序
   • load
     • 先调用类的load（先编译的先调用），再调用分类的load（也是先编译的先调用）。
     • 先调用父类，再调用子类。
   • initialize
     • 先看父类有没有实现，再调用子类。
     • +initialize 方法的调用与普通方法的调用是一样的，走的都是消息发送的流程。
     • 如果子类没有实现 +initialize 方法，那么继承自父类的实现会被调用；
     • 如果一个类的分类实现了 +initialize 方法，那么就会对这个类中的实现造成覆盖。
   • 调用方式
     • load是在系统加载的时候，根据函数地址直接调用的
     • initialize是通过消息发送调用
   • 调用时间
     • load是runtime加载类、分类的时候调用，只会调用一次（在APP冷启动的第二阶段就会调用）
     • initialize是类在第一次接收到消息的时候调用，每个类只会initialize一次。但是父类的initialize方法可能会被调用多次。

	// JHPerson 和 JHTeacher 都是 Person 的子类，并且只有Person这个父类实现了+initialize方法
- (void)testInit {
   NSLog(@"--------");
    [JHPerson alloc];
    [JHPerson alloc];
    [JHTeacher alloc];
    [JHTeacher alloc];
}

	// 伪代码逻辑
    if (JHPerson没有初始化) {
 	if (JHPerson的父类Person没有初始化) {
			objc_msgSend([Person class], @selector(initialize)); // 第一次调用父类
		}
		objc_msgSend([JHPerson class],@selector(initialize)); // 调用子类，子类没实现，去找到父类调用，第二次调用父类
    }
 	
    if (JHTeacher没有初始化) {
 	if (JHTeacher的父类Person没有初始化) { // 父类已经初始化了，不会进来
		   objc_msgSend([Person class], @selector(initialize));
		}
		objc_msgSend([JHTeacher class],@selector(initialize)); // 调用子类，子类没实现，去找到父类调用，第三次调用父类
     }
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

8. 聊聊block

• 1. block的本质是一个OC对象
     NSGloabalBlock --> NSBlock --> NSObject
• 2. block类型问题
  • GloabalBlock – 没有访问auto变量 – 程序的数据区域
  • NSStackBlock – 访问了auto变量 – 栈里面
  • NSMallocBlock – NSStackBlock复制 – 堆里面
  • NSMallockBlock复制，引用计数+1
    
• 3. 变量捕获
  • 1. 局部变量会被捕获，全局变量不会被捕获
  • 2. static修饰的或者是__block修饰的，是指针传递
  • 3. 默认没有修饰，（即auto）是值传递
• 4. 下划线_block修饰后的对象，是一个结构体

  struct __Block_byref_age_0 {
  	void *__isa;
  	__Block_byref_age_0 *__forwarding; // 这个指针指向自己
  	int __flags;
  	int __size;
  	int age;
  };
  1
  2
  3
  4
  5
  6
  7

  • forwarding为什么指向自己？如图，保证当从栈复制到堆时候，也能正确指向属性的指针地址
    
• 5. 循环引用
  • 1. ARC下
    • 用__weak一般是最佳方案，因为安全，对象销毁指针指向nil
    • 用_unsafe_unretain，不安全，对象销毁，指针地址不变
    • __block 方案，个人取个名字叫过河拆桥法，方便记忆。
    • 1. 首先__block修饰后，变为一个结构体。
    • 2. 结构体里面有强指针指向实例对象，__block对实例对象产生了强引用
    • 3. 实例对象调用block对象，实例对象对block产生了强引用
    • 4. block再访问了__block对象的内容，block对__block产生了强引用，如图：

// 1. __block修饰的那部分:__block Person *person = [[Person alloc] init];
    struct __Block_byref_person_0 {
  	void *__isa;
		__Block_byref_person_0 *__forwarding;
 	int __flags;
 	int __size;
 	void (*__Block_byref_id_object_copy)(void*, void*);
		void (*__Block_byref_id_object_dispose)(void*);
 	Person *__strong person; // 后面使用的person指针，都是这个指针
	};
1
2
3
4
5
6
7
8
9
10

- 5. 现在我要过河拆桥，我调用block的时候，通过__block访问到了我想要访问的实例对象的属性（比如，这里我的目的就是访问person.age），那么我的目的已经完成了，所以，我不再需要让__block对象再去强引用实例对象了。

// 1. __block修饰的那部分:__block Person *person = [[Person alloc] init];
    struct __Block_byref_person_0 {
  	void *__isa;
		__Block_byref_person_0 *__forwarding;
 	int __flags;
 	int __size;
 	void (*__Block_byref_id_object_copy)(void*, void*);
		void (*__Block_byref_id_object_dispose)(void*);
 	Person *__strong person = nil; // 在这里来过河拆桥，把它变为nil
 	
	};
1
2
3
4
5
6
7
8
9
10
11

• 2. MRC
  • 1.因为MRC不支持弱引用的情况，所以可以使用__unsafe_unretained
  • 2.使用__block解决
    因为__block不会对对象产生强引用
• 3. weak实现原理
  • 1. 博客1
  • 2. 博客2

9. 聊聊Runloop

runloop链接

10. 聊聊Runtime

runtime链接

11. 聊聊锁

0. 自旋锁、互斥锁比较

• 简单总结：
  • 单核的、复杂的操作，用互斥锁
  • 多核的、简单的操作，用自旋锁
• 自旋锁：
  • 是一种用于保护多线程共享资源的锁，与一般互斥锁（mutex）不同之处在于当自旋锁尝试获取锁时以忙等待（busy waiting）的形式不断地循环检查锁是否可用。当上一个线程的任务没有执行完毕的时候（被锁住），那么下一个线程会一直等待（不会睡眠），当上一个线程的任务执行完毕，下一个线程会立即执行。
    在多 CPU 的环境中，对持有锁较短的进程来说，使用自旋锁代替一般的互斥锁往往能够提高进程的性能。
• 互斥锁：
  • 当上一个线程的任务没有执行完毕的时候（被锁住），那么下一个线程会进入睡眠状态等待任务执行完毕，当上一个线程的任务执行完毕，下一个线程会自动唤醒然后执行任务。

2. @synchronized 的原理

• 第一步

@synchronized(obj) {
    // do work
}
转化成这样的东东：
@try {
    objc_sync_enter(obj);
    // do work
} @finally {
    objc_sync_exit(obj);    
}
1
2
3
4
5
6
7
8
9
10

• 第二步：objc_sync_enter 和 objc_sync_exit 是什么鬼？它们是如何实现的？

// Begin synchronizing on 'obj'. 
// Allocates recursive mutex associated with 'obj' if needed.
// Returns OBJC_SYNC_SUCCESS once lock is acquired.  
// 开始在obj上执行同步操作, 懒加载生成一个递归锁关联obj, 返回OBJC_SYNC_SUCCESS
int objc_sync_enter(id obj)
{
    int result = OBJC_SYNC_SUCCESS;
 
    if (obj) {
        // 查找这个obj是否已经生成SyncData,如果没有生成一个
        SyncData* data = id2data(obj, ACQUIRE); 
        assert(data);
        data->mutex.lock(); // 调用SyncData的递归锁加锁
    } else {
        // @synchronized(nil) does nothing
        // 如果传入nil, 打印了一个log,然后什么都不做
        if (DebugNilSync) {
            _objc_inform("NIL SYNC DEBUG: @synchronized(nil); set a breakpoint on objc_sync_nil to debug");
        }
        objc_sync_nil();
    }
 
    return result;
}
 
 
// End synchronizing on 'obj'. 
// Returns OBJC_SYNC_SUCCESS or OBJC_SYNC_NOT_OWNING_THREAD_ERROR
// 结束在obj上的同步操作, 
int objc_sync_exit(id obj)
{
    int result = OBJC_SYNC_SUCCESS;
    
    if (obj) {
        //还是找到这个对象所在的结构体SyncData
        SyncData* data = id2data(obj, RELEASE); 
        if (!data) {
            // 如果这个结构体在block执行过程中找不到了,会返回error
            result = OBJC_SYNC_NOT_OWNING_THREAD_ERROR;
        } else {
            // 尝试解锁,解锁失败也会返回error
            bool okay = data->mutex.tryUnlock();
            if (!okay) {
                result = OBJC_SYNC_NOT_OWNING_THREAD_ERROR;
            }
        }
    } else {
        
        // @synchronized(nil) does nothing
        // 如果这个对象在block执行过程中变成nil了,会什么都不做
    }
	
 
    return result;
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55

3. 第三步：data->mutex.lock(); // 调用SyncData的递归锁加锁 怎么调？

typedef struct SyncData {
    id object;
    recursive_mutex_t mutex;
    struct SyncData* nextData;
    int threadCount;
} SyncData;
 
typedef struct SyncList {
    SyncData *data;
    spinlock_t lock;
} SyncList;
 
// Use multiple parallel lists to decrease contention among unrelated objects.
#define COUNT 16
#define HASH(obj) ((((uintptr_t)(obj)) >> 5) & (COUNT - 1))
#define LOCK_FOR_OBJ(obj) sDataLists[HASH(obj)].lock
#define LIST_FOR_OBJ(obj) sDataLists[HASH(obj)].data
static SyncList sDataLists[COUNT];
 
 
----------
SyncData中的recursive_mutex_t最终是recursive_mutex_tt类型,
recursive_mutex_tt内部有个pthread_mutex_t的锁,
这个锁初始化为一个递归锁 PTHREAD_RECURSIVE_MUTEX_INITIALIZER
----------
 
class recursive_mutex_tt : nocopy_t {
    pthread_mutex_t mLock;
 
  public:
    recursive_mutex_tt() : mLock(PTHREAD_RECURSIVE_MUTEX_INITIALIZER) {
        lockdebug_remember_recursive_mutex(this);
    }
 
    recursive_mutex_tt(const fork_unsafe_lock_t unsafe)
        : mLock(PTHREAD_RECURSIVE_MUTEX_INITIALIZER)
    { }
 
    void lock()
    {
        lockdebug_recursive_mutex_lock(this);
 
        int err = pthread_mutex_lock(&mLock);
        if (err) _objc_fatal("pthread_mutex_lock failed (%d)", err);
    }
 
    void unlock()
    {
        lockdebug_recursive_mutex_unlock(this);
 
        int err = pthread_mutex_unlock(&mLock);
        if (err) _objc_fatal("pthread_mutex_unlock failed (%d)", err);
    }
    ..... 其他方法
};
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55

4. 其他问题

• 锁是如何与你传入 @synchronized 的对象关联上的？
  • 你调用 sychronized 的每个对象，Objective-C runtime 都会为其分配一个递归锁并存储在哈希表中。
• @synchronized会保持（retain，增加引用计数）被锁住的对象么？
  • ARC下会引用计数+1，MRC下不会
• 如果传入@synchronized 的对象值为 nil 将会怎么样？
  • @synchronized(nil)不会有任何作用,hash计算为空,加锁失败,代码块不是线程安全的。你可以通过在 objc_sync_nil 上加断点来查看是否发生了这样的事情。
• 假如传入 @synchronized 的对象在 @synchronized 的 block 里面被释放或者被赋值为 nil 将会怎么样？
  • 如果在 sychronized 内部对象被释放或被设为 nil 看起来都 OK。不过这没在文档中说明，所以我不会再生产代码中依赖这条。

12. 聊聊多线程

多线程链接

五、聊聊数据持久化

• 本地存储的几种方式
• 数据库（sqlite、coredate、FMDB、WCDB）

六、聊聊路由

组件化链接

• Beehive
• CTMeditor

七、聊聊Swift和OC的区别？

7.1 struct & class

• struct是值引用，更轻量，存放于栈，不可继承
• class是指针引用（或称类型引用），存放于堆区，可以继承

7.2 swift的派发机制

• 直接派发
  • 是在struct、enum中，速度快，但是不能继承
• 函数表派发
  • swift里函数表叫Witness Table ，类会有一个数组存储里面的函数指针。
  • 一个对象的内存地址前8位存储类的类型信息，类型信息就包括了函数指针。
  • 后8位信息是引用计数
• 消息机制派发
  • 消息派发是在运行时，可以改变函数的行为，KVO和CoreData都是对这种机制的运用。OC默认使用消息派发，C语言使用的是直接派发。
    • 当一个消息被派发，程序运行时就会按照继承关系向上查找被调用的函数，但是效率不高，所以会通过缓存来提高效率，性能和函数表派发差不多。
• 场景：
  • 直接派发：
    • 值类型
    • final
    • @inline
    • class和协议的extension
  • 函数表派发:
    • class和协议的初始化声明
  • 消息机制派发:
    • class和@objc extension
    • dynamic：可以让类里面的函数使用消息机制派发，可以重载extension里的函数
    • @nonobjc: 来禁止消息机制派发这个函数

7.3 对协议的理解？

• 解决面向对象菱形继承问题