hmap - header map 描述头文件映射关系
.m文件 -> 最终app 的简单过程主要是两部分
.m -> .o 编译生成.o文件，静态库在此阶段生成.o -> app 链接生成app (link)
这两个阶段都需要时间，要考虑如何加快编译速度，首先得选择在以上哪个阶段处理，选择的标准就是看哪个阶段的耗时更长，处理才变得更有意义
编译消耗时间 167毫秒，链接消耗时间
时间差一个数量级，所以处理编译阶段时间优化更有效
如果头文件目录很多，意味着耗时进一步增加
针对于编译.o 优化的几种方式
组件二进制化 提前编译二进制库文件(打包静态库 dylibs framework) 这种方式可以参考另一篇博文 iOS解耦合-你做到了吗？ 了解 header 映射 在理解header映射之前，可以试想一下，你有没有遇到过项目里包含很多资源文件的情况，我曾经的一个项目里需要用到的音频文件有超过一万个，而编译单索引这些资源文件就相当耗时，单单这些资源文件的编译当时至少4分钟 header可以理解为一种资源文件，我们能处理的就是搜索资源过程做优化
header编译？
header是否参与编译
简单设想一下，在.h中定义个函数，在.m中调用定义的函数，是否执行，若执行的话，如果.h不编译，函数又从何而来呢
根据矛盾反向分析，.h肯定是参与编译的
如果有研究过oc底层源码的话, .h中有很多定义, 可以看下 objc_class .h中定义
.h如何编译进来 （组件二进制 = 二进制 + .h）
.h存在于何处 如何查找
xcode - header search paths -> 查找目录import xxx.h
最终 目录/xxx.h 找到头文件
framework的头文件引入方式
framework -> module -> 映射头文件
比如 pod安装 Masonry, Masonry.framework 包内容，存在 Modules/module.modulemap 这样一个文件
framework module Masonry {
umbrella header "Masonry-umbrella.h"
export *
module * { export * }
}
umbrella 指向一个头文件 Masonry-umbrella.h
umbrella header Masonry-umbrella.h 就是 module的伞柄
系统通过伞柄 去映射到 每个伞骨代表的头文件
.a 头文件引入 - 目录/xxx.h
看下pod生成的静态库
注释掉 Podfile use_frameworks!
重新 pod install
cocoapods 生成xcconfig
既然配置了header 查找目录
比如配置了 ${PODS_ROOT}/Headers/Public
就可以通过 Public目录下 AFNetworking/xxx.h的方式查找头文件了
以下就是头文件编译之后的二进制形式了
再次编译的时候，直接读取.h编译的二进制文件，节省了目录搜索的过程，效率会高一些
如何找到 这些 二进制文件呢?
引出hmap
首次编译之后，xcode会生成.hmap文件
再次编译时，就是通过这些 hmap文件 找到对应的 .h编译的二进制文件
可以看到好几个.hmap文件，其实是不同类别的文件
清理一次工程，这些.hmap也会消失，编译又会变慢
hmap 字面理解就是 header映射，里面至少是 key - value这样的映射结构
简单看下，xcode在编译 一个.m文件时，-I 引入了.hmap文件
cat命令查看下 主工程项目的hmap文件 - IFLTestSymbol-project-headers.hmap
图中能看到大概信息包含3个.h文件，一个静态库.a头文件，两个主工程中的.h文件
hmap数据结构
llvm源码中查看hmap数据结构
仔细理解下HMapHeader 结构体最后的两句注释
HMapHeader 包含头部信息，就是 Magic, Version, Reserved 等信息HMapBucket数组区域, 数量：NumBuckets个一长串字符串
其中 HMapBucket结构中的 Key，Prefix，Suffix并不是字符串，而是各自代表的字符串在 长字符串中的偏移量
可以这样理解，hmap 的关键信息 key:目录前缀/头文件
读取到key的偏移，上 字符串中 根据key的偏移取出 key字符串
读取到前缀偏移，上 字符串中 根据前缀的偏移取出 前缀字符串
读取到后缀偏移，上 字符串中 根据后缀的偏移取出 后缀字符串
根据 key字符串，拿出 目录前缀/头文件
c++读hmap
稍微调整下HMapHeader结构
void read_hmap(void) {
// test_hmap/Test111-all-non-framework-target-headers.hmap
// test_hmap/Test111-all-target-headers.hmap
// test_hmap/Test111-own-target-headers.hmap
// test_hmap/Test111-project-headers.hmap
// test_hmap/IFLTestSymbol-all-target-headers.hmap
// test_hmap/IFLTestSymbol-generated-files.hmap
// test_hmap/IFLTestSymbol-own-target-headers.hmap
// test_hmap/IFLTestSymbol-project-headers.hmap
// char *path = "/Users/erlich/Developer/workspace/ios/test/test_symbol/Test111/HMap/Test111.build/Debug-macosx/Test111.build/Test111-project-headers.hmap";
char *path = "/Users/erlich/Developer/workspace/ios/test/test_symbol/Test111/Test111/test_hmap/Test111-project-headers.hmap";
int file = open(path, O_RDONLY|O_CLOEXEC);
if (file < 0) {
printf("cannot open file %s", path);
return;
}
struct HMapHeader *header = malloc(100 * sizeof(struct HMapHeader));
ssize_t headerRead = read(file, header, 100 * sizeof(struct HMapHeader));
if (headerRead < 0 || (size_t)headerRead < sizeof(struct HMapHeader)) {
printf("read %s fail", path);
close(file);
return;
}
close(file);
// Sniff it to see if it's a headermap by checking the magic number and version.
bool needsByteSwap = false;
if (header->Magic == ByteSwap_32(HMAP_HeaderMagicNumber) && header->Version == ByteSwap_32(HMAP_HeaderVersion)) {
// 高低位变换
needsByteSwap = true;
}
uint32_t NumBuckets = needsByteSwap ? ByteSwap_32(header->NumBuckets) : header->NumBuckets;
uint32_t StringsOffset = needsByteSwap ? ByteSwap_32(header->StringsOffset) : header->StringsOffset;
const void *raw = (const void *)header;
// HMapBucket 数组
const void *buckets = raw + 24;
// 长字符串
const void *string_table = raw + 24 + 8 + header->StringsOffset;
printf("buckets 初始化了: %i\n\n", NumBuckets);
// printf("长字符串：%s\n\n", string_table);
int mBucketsCount = 0;
for (uint32_t i = 0; i < NumBuckets; i++) {
struct HMapBucket *bucket = (struct HMapBucket *)(buckets + i * sizeof(struct HMapBucket));
bucket->Key = needsByteSwap ? ByteSwap_32(bucket->Key) : bucket->Key;
bucket->Prefix = needsByteSwap ? ByteSwap_32(bucket->Prefix) : bucket->Prefix;
bucket->Suffix = needsByteSwap ? ByteSwap_32(bucket->Suffix) : bucket->Suffix;
if (bucket->Key == 0 && bucket->Prefix == 0 && bucket->Suffix == 0) {
continue;
}
mBucketsCount++;
const char *key = string_table + bucket->Key;
const char *prefix = string_table + bucket->Prefix;
const char *suffix = string_table + bucket->Suffix;
printf("key: %s, offset: %i \nprefix: %s, offset: %i, \nsuffix: %s, offset: %i\n\n", key, bucket->Key, prefix, bucket->Prefix, suffix, bucket->Suffix);
}
printf("buckets 初始化了%i个，实际使用了%i个\n\n", NumBuckets, mBucketsCount);
free(header);
}
由于读取hmap内容的c++代码并没有 内存偏移处理，所以做了取巧处理
将HMapBucket数组作为 HMapHeader的成员长字符串具体长度目前未知，读取hmap缓冲大小设定了一定的冗余空间header结构体内容 参考llvm源码中的逻辑，需要做高低位反转判断长字符串部分初始需要做偏移 - header->StringsOffset
获取到的key prefix suffix 与预期的有一定的偏差
读取环节有纰漏，大概可以推断出错的缘由在于字符串偏移上，明显是偏移过多了，也就是偏移起始出错了
修正，原来 HMapHeader结构中的 StringsOffset 指的是 从结构体起始位置偏移，非buckets开始的偏移
读取hmap内容就显示正常了
hmap理解
理解pod xcconfig header search path
有两种头文件引入方式
#import AFNetworking.h …/Headers/Public/AFNetworking 这种配置 目录 会跟 AFNetworking.h拼接 #import
剩下的就是hmap配置了
当前配置是根据 header search paths 最终找到 前缀目录+后缀头文件.h
现在换成 不查找目录，直接查找hmap中的 key，拿到 prefix + suffix拼接的结果
具体配置及插件，下一篇博文会更新此内容
测试demo工程
精彩文章
您阅读本篇文章共花了：
发表评论