1.1. 引言

移动操作系统为开发者提供了功能丰富的日志组件，比如说Android Studio 中的Logcat窗口会显示系统消息，例如在进行垃圾回收时显示的消息，以及使用Log类添加到应用的消息， 能够辅助开发者进行高效的开发工作。然而在生产环境中，当用户(或者老板)反馈一些问题，又比较冷僻难以复现的时候(不是Crash)，常常就会陷入一筹莫展的境地。此时，借助线上异常数据实时上报，我们只能是祈祷用户网络环境通畅，能够及时把异常数据第一时间上报上来，然而这种做法并不能保证我们永远那么幸运。

于是，我们需要研制一款性能较高的移动日志系统来解决我们当下的难题，该系统能具备日志信息完整、性能损耗低、轻量级(体积)、精确回捞的特点。 接下来介绍一下移动日志系统的研发历程。

1.2. 设计方案

移动日志系统使用了Linux系统中提供的mmap作为日志文件的载体，目前业内流行的XLOG日志组件、MMKV、美团Logan均采用了此方案，其最大的优势就是高效I/O、低损耗、跨进程 等优势，接下来引入下mmap的基本介绍。

1.2.1. 什么是mmap?

操作系统分为内核态和用户态两种运行模式：

• 内核态(Kernel MODE)能够运行操作系统程序 用户态(User MODE)能够运行用户程序
• 用户态(即应用程序)是不能直接对物理设备进行操作的(Ps:对物理设备进行操作，即对设备的物理地址写数据)。如果想读取硬盘上的某一段数据通常都需要经过 硬盘->内核->用户，即数据需要经历两次拷贝，效率十分低下。 为了解决这样的问题，内存映射的概念出现了：内核映射即mmap,mmap将设备的物理地址映射到进程的虚拟地址，则用户操作虚拟内存时就相当于对物理设备进行操作了，减少了内核到用户的一次数据拷贝，从而提高数据的吞吐率。

在Linux中可以使用mmap用来在进程虚拟内存地址空间中分配地址空间，创建和物理内存的映射关系 ：

当使用mmap映射文件到进程后，就可以直接操作这段虚拟地址进行文件的读写等操作，不必再调用read，write等系统调用。但需注意，直接对该段内存写时不会写入超过当前文件大小的内容。

总之，mmap区别于以往的文件读写，具备以下几个优点：

• 减少了数据的拷贝次数，用内存读写取代I/O读写，提高了文件读取效率
• 实现了用户空间和内核空间的高效交互方式。两空间的各自修改操作可以直接反映在映射的区域内，从而被对方空间及时捕捉
• 提供进程间共享内存及相互通信的方式。不管是父子进程还是无亲缘关系的进程，都可以将自身用户空间映射到同一个文件或匿名映射到同一片区域。从而通过各自对映射区域的改动，达到进程间通信和进程间共享的目的
• 同时，如果进程A和进程B都映射了区域C，当A第一次读取C时通过缺页从磁盘复制文件页到内存中;但当B再读C的相同页面时，虽然也会产生缺页异常，但是不再需要从磁盘中复制文件过来，而可直接使用已经保存在内存中的文件数据
• 可用于实现高效的大规模数据传输。内存空间不足，是制约大数据操作的一个方面，解决方案往往是借助硬盘空间协助操作，补充内存的不足。但是进一步会造成大量的文件I/O操作，极大影响效率。这个问题可以通过mmap映射很好的解决。换句话说，但凡是需要用磁盘空间代替内存的时候，mmap都可以发挥其功效

1.2.2. mmap的使用

对于移动端日志采集SDK来说，主要进行的工作就是将用户写入的数据保存到文件中，在这个过程中涉及到在native层调用mmap函数实现在进程虚拟内存地址空间中分配地址空间，创建和物理内存的映射关系。

接下来介绍一下Linux系统中mmap机制的使用流程：

mmap函数

• 函数声明

 
 

  
  
void* mmap(void* __addr, size_t __size, int __prot, int __flags, int __fd, off_t __offset); 
 
 

• 返回值说明

成功执行时，mmap()返回被映射区的指针。失败时，mmap()返回MAP_FAILED[其值为(void *)-1],error被设为以下的某个值：

1. EACCES：访问出错
2. EAGAIN：文件已被锁定，或者太多的内存已被锁定
3. EBADF：fd不是有效的文件描述词
4. EINVAL：一个或者多个参数无效
5. ENFILE：已达到系统对打开文件的限制
6. ENODEV：指定文件所在的文件系统不支持内存映射
7. ENOMEM：内存不足，或者进程已超出最大内存映射数量
8. EPERM：权能不足，操作不允许
9. ETXTBSY：已写的方式打开文件，同时指定MAP_DENYWRITE标志
10. SIGSEGV：试着向只读区写入
11. SIGBUS：试着访问不属于进程的内存区

• 参数说明

mmap在移动端代码中的使用

 
 

  
  
//用于写入文件的缓存Buffer 
  
  
static unsigned char *_buffer = NULL; 
  
  
// mmap缓存文件的大小 
  
  
static int mmap_cache_file = 100*1024; 
  
  
 
  
  
void init() { 
  
  
  //第一步: 根据设置的缓存位置生成用于映射的文件 
  
  
  makedir_mmapfile(cache_path); 
  
  
  //第二步：打开缓存文件 
  
  
  int fd = open(cache_path, O_RDWR | O_CREAT, S_IRUSR | S_IWUSR | S_IRGRP | S_IWGRP); 
  
  
  //mmap映射的文件的判断 
  
  
  if(fd != -1) { 
  
  
     ...... 
  
  
    //第三步：mmap映射文件到buffer内存中 
  
  
    _buffer = (unsigned char *) mmap(0, size, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0); 
  
  
  } 
  
  
  //第四步：关闭文件句柄 
  
  
   close(fd); 
  
  
} 
  
  
 
  
  
//第五步：操作mmap内存读写 
  
  
void write(....) { 
  
  
  // 将要写入的数据封装，压缩和加密 
  
  
  data_zlib_compress(); 
  
  
 
  
  
  //将mmap的缓存写入到文件中 
  
  
  fwrite(_buffer, sizeof(char), _buffer.length, dest_file); 
  
  
  fflush(dest_file); 
  
  
 
  
  
  // 文件大小变化等相关操作 
  
  
  update(); 
  
  
} 
 
 

日志写入的流程

1.2.3. 移动日志系统架构介绍

客户端日志SDK为开发者提供日志的打印，主要是将在线上运行期间产生的日志写入文件中，根据开发者的需要捞取指定的日志，为开发者解决线上问题提供助力。我们设计了满足基本功能的系统，架构如下图所示：

1.2.4. 客户端日志SDK介绍

日志SDK的架构如图展示，可以分为如下三层，每一层解决了不同的业务场景。

日志SDK在底层使用了流式压缩加密操作，在接收到写入的日志数据，先将数据进行压缩操作，然后再进行加密操作，整个过程中都是流式操作，避免了CPU峰值，减少对CPU性能负担。在具体的实现中引入了MMAP机制解决了日志丢失问题，使用AES进行日志加密确保日志安全性。

日志SDK通过服务端下发的策略进行本地日志的动态上报，这里我们可以通过定时的拉取最新的策略，或者通过push通道更新本地的策略，再或者提供上报接口，在用户的反馈中，让用户将日志数据上报上来。当前在下发的策略中我们进行了大量的自定义，对文件的大小，缓存时长，日志的写入等级等相关的设置进行下发操作，实现应用初始化后，筛选过滤，只将我们需要的日志写入到文件中，为开发者使用。

日志SDK根据策略将指定的日志文件上传到指定的服务器上，这个服务器将对上传的日志进行解压和解码操作，将日志文件还原成原始的输入数据，具体的流程可以参考下面的业务流程。

日志SDK业务流程

日志SDK在的业务流程如下图所示，根据服务端配置的策略，采集指定的日志并进行数据的压缩加密等操作，然后主动将本地日志文件上传到中转服务，将上传结果等相关信息同步到信息展示的服务端。

日志SDK性能

上述设计中以及使用中，为了减少对CPU以及内存的消耗，我们通过使用mmap技术，将流式压缩加密缓存等操作转移到native层，那么这样做相对于Java层的日志库我们对于内存以及CPU的使用率降低了多少，接下来我们将使用一个Java层的日志库与使用mmap实现的native库进行对比。

测试条件

性能测试中采用了在同一台小米Note3 Android 9系统版本手机，分别测试了已有的Java日志库、当前日志库、美团Logan、腾讯XLog日志库的写入性能。通过写入速度、GC频率、CPU占用率几个维度来衡量日志库的写入性能，测试的结果只限于衡量当前测试环境，并不代表Android平台整体平均水准。

测试数据量：

测试结果

1. 内存的GC测试结果

Java日志库:

native日志库:

从上边的内存性能图片中可以看到，Java日志库在大量写日志的时候回造成频繁的GC，虽然native日志库不会出现这样频繁的GC，从图中可以看到Java日志库的GC频率大约是1s/次，native日志库的GC频率大约是7.5s/次。

2. CPU使用率测试结果

Java日志库:

native日志库:

从上边CPU性能图片中可以看到，Java日志库在频繁写入日志的时候CPU的平均使用率大约为13%，native日志库在频繁写入日志的时候CPU的平均使用率大约为5%。

从上述内存以及CPU占用率的对比中，我们可以看出native日志库相较于Java日志库来说，性能上有了很大的提示，对于内存的占用较小，在频繁的I/O操作以及加密压缩操作的情况下cpu的使用率仍保持在较低值。

日志库性能的对比

上边我们与Java日志进行了对比，接下来我们将于其他使用mmap实现的日志库进行下对比：

1.3. 实践案例

在app的线上环境我们可能遇到各种问题，我们希望将出现问题当天的日志获取到用于问题的分析，协助解决问题。这样的业务场景几乎覆盖了大部分的业务场景，对于自助收银机这样的设备使用场景，运行时期的日志对于问题的排查尤为重要。

数科自助收银设备主要服务于各大超市卖场的自如结账，缓解多条人工收银通道仍无法抵消的收银压力。当出现问题的时候，我们不可能对使用者进行回访，所以运行时候的日志对于问题排查尤为重要。

在未使用移动日志系统之前，遇到问题后，由于缺少运营工具，对于问题的排查，需要占用较多的研发资源，在接入移动日志系统后，运营就可以独自处理大部分的问题。这样极大的提高了解决问题的效率，减少了研发侧参与排查运营问题的时间。

1.4. 写到最后

当前的sdk使用场景是定时拉取服务端的策略，根据下发的最新策略进行日志文件的上报，有一定的时间延后性，后期我们将开放主动上报日志的通道以及结合push推送消息，提高日志回捞的及时性以及成功率。

当前的sdk暂时只支持移动端(Android以及iOS)，在后续我们将进行多端支持，将在RN，Flutter，小程序以及H5等各种应用场景中统一使用当前日志库进行日志的采集和存储。