iOS底层 - 类的加载分析

1.本文概述

本文旨在通过分析分类的加载流程，类和分类分别在懒加载和非懒加载时的表现，完善所有类的加载流程。

---

2.分类相关探索

2.1 分类初探

上一篇文章类的加载分析分析了map_images的主要流程，此流程中最后为分类的加载部分，现在回头来解析下。

第二节 弱引用和静态库代码冲突

1、弱引用的使用

弱引用：当APP运行时如果没有找到所需的库文件会将它自动置为nil。
为了使用弱引用需要配置：-weak_framework

//  LGAPP使用XCFramework文件需要以下四步：
 （1）-I ：头文件
    HEADER_SEARCH_PATHS = $(inherited) ${SRCROOT}/SYTimer.framework/Headers
 （2）-F: frmaework 所在的目录
    FRAMEWORK_SEARCH_PATHS = $(inherited) ${SRCROOT}
 （3）要链接的库文件名称
    OTHER_LDFLAGS = $(inherited) -Xlinker -weak_framework -Xlinker "SYTimer"
 （4）配置rpath路径
    LD_RUNPATH_SEARCH_PATHS = $(inherited)

配置完后可以查看编译过后的可执行文件中含有 weak 信息的 loadcommand

LC_LOAD_WEAK_DYLIB.png

2、静态库代码冲突

LGAPP工程中导入两个只是名称不同的AFNetworking。
 //-I 引入AFNetworking头文件
 HEADER_SEARCH_PATHS = $(inherited) "${SRCROOT}/AFNetworking" "${SRCROOT}/AFNetworking2"
 //-L 引入AFNetworking的所在路径
 LIBRARY_SEARCH_PATHS = $(inherited) "${SRCROOT}/AFNetworking" "${SRCROOT}/AFNetworking2"
 //-l 引入AFNetworking名称
 OTHER_LDFLAGS = $(inherited) -l"AFNetworking" -l"AFNetworking2" -Xlinker -force_load -Xlinker "${SRCROOT}/AFNetworking/libAFNetworking.a"

• 编译时在OTHER_LDFLAGS中配置了"AFNetworking"和"AFNetworking2"两个相同的静态库，但是在编译时没有产生报错，这是应为系统默认使用了-noall_load，这样就会进行代码剥离，当找到第一个静态库加载后，在找到第二个静态库后会自动跳过。

• 如果使用-all_load、-ObjC就立即会报错："出现重复定义符号的错误"，这两个会将所有库的代码链接进去。

  
  使用-all_load、-ObjC都会静态库冲突.png
• 为了既不出现冲突又不全部剥离，所以使用-force_load，加载指定静态库内容。

---