iOS – header map加快编译速度（一）

本文介绍: h map – header m a p 描述头文件映射关系.m 文件 -&g t; 最终app 的简单过程主要是两部分这两个阶段都需要时间，要考虑如何加快编译速度，首先得选择在以上哪个阶段处理，选择的标准就是看哪个阶段的耗时更长，处理才变得更有意义编译消耗时间编译阶段消耗时长与链接消耗时间时间差一个数量级，所以处理编译阶段时间优化更有效如果头文件目录很多，意味着耗时进一步增加针对于编译.o 优化的几种方式组件二进制化提前编译二进制库文件(打包静态库 dylibs framework)…

h m a p – header m a p 描述头文件映射关系

.m文件 -&g t; 最终app 的简单过程主要是两部分

.m -&g t; .o 编译生成.o文件，静态库在此阶段生成
.o -&g t; app 链接生成 app (link)

这两个阶段都需要时间，要考虑如何加快编译速度，首先得选择在以上哪个阶段处理，选择的标准就是看哪个阶段的耗时更长，处理才变得更有意义

编译消耗时间 167毫秒，链接消耗时间

时间差一个数量级，所以处理编译阶段时间优化更有效

如果头文件目录很多，意味着耗时进一步增加

针对于编译.o 优化的几种方式
- 组件二进制化提前编译二进制库文件(打包静态库 dylibs framework)
  
  这种方式可以参考另一篇博文 iOS解耦合-你做到了吗？了解
- header 映射
  
  在理解header映射之前，可以试想一下，你有没有遇到过项目里包含很多资源文件的情况，我曾经的一个项目里需要用到的音频文件有超过一万个，而编译单索引这些资源文件就相当耗时，单单这些资源文件的编译当时至少4分钟
  
  header 可以理解为一种资源文件，我们能处理的就是搜索资源过程做优化

header编译？

header是否参与编译

简单设想一下，在.h中定义个函数，在.m中调用定义的函数，是否执行，若执行的话，如果.h不编译，函数又从何而来呢

根据矛盾反向分析，.h肯定是参与编译的

如果有研究过oc 底层源码的话, .h中有很多定义, 可以看下 obj c_class .h中定义

.h如何编译进来（组件二进制 = 二进制 + .h）

.h存在于何处如何查找

xcode – header search path s -&g t; 查找目录
import xxx.h

最终目录/xxx.h 找到头文件

framework的头文件引入 方式 <xxx xFramework/xxx x.h>, 也就是module/头文件

framework -> module -> 映射头文件

比如 pod 安装 Ma s on ry, Ma s on ry.framework 包内容，存在 Modules/module.module m a p 这样一个文件

framework module Masonry {
  umbrella header "Masonry-umbrella.h"

  export *
  module * { export * }
}

umbrella 指向一个头文件 Mason ry-umbrella.h

umbrella header Mason ry-umbrella.h 就是 module的伞柄

系统通过伞柄去映射到每个伞骨代表的头文件

.a 头文件引入 – 目录/xxx.h

看下pod 生成的静态库

注释掉 Pod file use_frameworks!

重新 pod install

co coap ods 生成 x c config

既然配置了header 查找目录

比如配置了 ${PODS_ROOT}/Headers/Publi c

就可以通过 Public目录下 AFNetwork ing/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, Reserve d 等信息
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) &amp;&amp; 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 初始化了: %inn", NumBuckets);
//    printf("长字符串：%snn", 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 &amp;&amp; bucket->Prefix == 0 &amp;&amp; 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: %inn", key, bucket->Key, prefix, bucket->Prefix, suffix, bucket->Suffix);
    }
    
    printf("buckets 初始化了%i个，实际使用了%i个nn", 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 AFNetwork ing.h

…/Headers/Public/AFNetworking 这种配置目录会跟 AFNetworking.h拼接
#import <AFNetworking/AFNetworking.h>

…/Headers/Public 这种配置目录会跟 AFNetworking/AFNetworking.h 拼接