apache与apr、apr-util的关系
2016-04-22 14:07:55 
阿炯
APR(Apache portable Run-time libraries)，Apache可移植运行库)的目的如其名称一样，主要为上层的应用程序提供一个可以跨越多操作系统平台使用的底层支持接口库。随着Apache的进一步开发，Apache组织决定将这些通用的函数独立出来并发展成为一个新的项目。这样APR的开发就从Apache中独立出来，Apache仅仅是使用APR而已。目前APR主要还是由Apache使用，不过由于APR的较好的移植性，因此一些需要进行移植的C程序也开始使用APR。
APR使得平台细节的处理进行下移。对于应用程序而言，它们根本就不需要考虑具体的平台，不管是Unix、Linux还是Window，应用程序执行的接口基本都是统一一致的。因此对于APR而言，可移植性和统一的上层接口是其考虑的一个重点。而APR最早的目的并不是如此，它最早只是希望将Apache中用到的所有代码合并为一个通用的代码库，然而这不是一个正确的策略，因此后来APR改变了其目标。有的时候使用公共代码并不是一件好事，比如如何将一个请求映射到线程或者进程是平台相关的，因此仅仅一个公共的代码库并不能完成这种区分。APR的目标则是希望安全合并所有的能够合并的代码而不需要牺牲性能。
APR的最早的一个目标就是为所有的平台(不是部分)提供一个公共的统一操作函数接口，这是一个非常了不起的目的，当然也是不现实的一个目标。我们不可能支持所有平台的所有特征，所以APR现只能为大多数平台提供所有的APR特性支持，包括Win32、OS/2、BSD、Linux等等。为了能够实现这个目标，APR开发者必须为那些不能运行于所有平台的特性创建了一系列的特征宏(FEATURE MACROS)以在各个平台之间区分这些特征。这些特征宏定义非常简单，通常如下： APR_HAS_FEATURE 如果某个平台具有这个特性，则该宏必须设置为true，比如Linux和window都具有内存映射文件，同时APR提供了内存映射文件的操作接口，因此在这两个平台上，APR_HAS_MMAP宏必须设置，同时ap_mmap_*函数应该将磁盘文件映射为内存并返回适当的状态码。如果你的操作系统并不支持内存映射，那么APR_HAS_MMAP必须设置为0，而且所有的ap_mmap_*函数也可以不需要定义。第二步就是对于那些在程序中使用了不支持的函数必须提出警告。
APR中支持的基本类型
名称 文件夹 描述
atomic /srclib/apr/atomic 原子操作
dso /srclib/apr/dso 动态加载共享库
fileio /srclib/apr/file_io 文件IO处理
mmap /srclib/apr/mmap 内存映射文件
locks /srclib/apr/locks 进程和线程互斥锁
memory /srclib/apr/memory 内存池操作
network_io /srclib/apr/network_io 网络IO处理
poll /srclib/apr/poll 轮询IO
table /srclib/apr/tables Apache数组(堆栈)和表格以及哈希表
process /srclib/apr/threadproc 进程和线程操作
user /srclib/apr/user 用户和用户组操作
time /srclib/apr/time 时间操作
string /srclib/apr/strings 字符串操作
password /srclib/apr/passwd 终端密码处理
misc /srclib/apr/misc 大杂烩，不属于其余类的任何apr类型都可以放在里面
shmem /srclib/apr/shmem 共享内存
random /srclib/apr/random 随机数生成库
一般情况下，APR开发包很容易理解为仅仅是一个开发包，不过事实上并不是。目前完整的APR实际上包含了三个开发包：apr、apr-util以及apr-iconv，每一个开发包分别独立开发，并拥有自己的版本。
apr中包含了一些通用的开发组件，包括mmap，DSO等等。
apr-util该目录中也是包含了一些常用的开发组件。这些组件与apr目录下的相比，它们与apache的关系更加密切一些。比如存储段和存储段组，加密等等。
apr-iconv包中的文件主要用于实现iconv编码。目前的大部分编码转换过程都是与本地编码相关的，在进行转换之前必须能够正确地设置本地编码。因此假如两个非本地编码A和B需要转换，则转换过程大致为A->Local以及Local->B或者B->Local以及Local->A。
参考来源：
Apache APR可移植运行库简介1-4