标签：
androidsystempropertyit |
分类： programming |
Android为了储存关于全局系统设置的信息，使用了一个系统属性公共缓冲区，这个缓冲区的内容是（属性，值）对的列表，对外提供get和set服务。可以说，属性区域相当于一般应用的配置文件。本文不说有哪些具体属性，而是描述一下这个属性系统的实现。
属性系统首先得有个固定地址空间，这是初始化的任务，初始化工作的最佳位置是在init进程。在init进程里，init_property_area函数调用init_workspace完成属性空间的分配：
fd = ashmem_create_region ("system_properties", size);
data = mmap(NULL, size, PROT_READ | PROT_WRITE, MAP_SHARED , fd, 0);
随后，
pa = pa_workspace.data;
__system_property_area__ = pa;
最后一句的__system_property_area__就是属性空间的入口地址。
属性的服务函数（get和set）是由bionic下system_properties.c文件提供的，即它是android的libc库的一部分。以get操作为例：
init使用的property_get是个包装函数，其实现是调用__system_property_find函数，后者是要找到所找属性的入口。
这得遍历属性缓冲区的结构。这个缓冲区包括两个部分：目录和内容。目录项目的结构是：
struct prop_area {
unsigned volatile count;
unsigned volatile serial;
unsigned magic;
unsigned version;
unsigned reserved[4];
unsigned toc[1];
};
具体属性的结构是：
struct prop_info {
char name[PROP_NAME_MAX];
unsigned volatile serial;
char value[PROP_VALUE_MAX];
};
find函数的主要内容：
prop_area *pa = __system_property_area__;
unsigned count = pa->count;
unsigned *toc = pa->toc;
unsigned len = strlen(name);
while(count--) {
unsigned entry = *toc++;
if(TOC_NAME_LEN(entry) != len) continue;
pi = TOC_TO_INFO(pa, entry);
if(memcmp(name, pi->name, len)) continue;
return pi;
}
count是总共的属性数目，toc是属性目录的入口地址。以上循环中，entry是属性的偏移量，是个32位的整数，其高位字节存储的是属性名的长度，后24位存储的是属性在缓冲区里的偏移量。TOC_NAME_LEN就是取得目录项的高8位，而TOC_TO_INFO则是取得后24位，然后再加上属性缓冲区的入口地址，就得到具体属性的入口地址，然后再把类型转换为prop_info的指针，然后返回这个值。
还有个问题：系统属性的客户是如何获知__system_property_area__的位置呢？这些客户通过连接C库而能调用系统属性的各个API，但并不能自动获知系统属性缓冲区的地址，这个地址在每个客户进程装载时，都初始化为0。进程之间可以共享代码，但并不自动共享数据，除非程序做些特殊的处理，比如使用共享内存。此处利用了二进制文件（可执行文件或者库）的init段，即把一些必须的初始化代码，比如C++对象的构造函数，放在这个init段里，每次动态连接或装载二进制文件时，就首先执行这个初始化段。
gcc提供了constructor属性来指示把代码放在init段里。system_properties的缓冲区地址，是在bionic libC库的init段里被确定的。文件libc_init_dynamic.c的__libc_prenit函数调用了__libc_init_common，后者又调用了__system_properties_init，最后这个函数确定__system_property_area__的地址。而函数__libc_prenit被给予属性constructor：
void __attribute__((constructor)) __libc_prenit(void);
这样在bionic libc动态库被装载时，系统属性缓冲区地址就被确定了，后续的API调用就能找对位置了。
属性系统首先得有个固定地址空间，这是初始化的任务，初始化工作的最佳位置是在init进程。在init进程里，init_property_area函数调用init_workspace完成属性空间的分配：
fd = ashmem_create_region ("system_properties", size);
data = mmap(NULL, size, PROT_READ | PROT_WRITE, MAP_SHARED , fd, 0);
随后，
pa = pa_workspace.data;
__system_property_area__ = pa;
最后一句的__system_property_area__就是属性空间的入口地址。
属性的服务函数（get和set）是由bionic下system_properties.c文件提供的，即它是android的libc库的一部分。以get操作为例：
init使用的property_get是个包装函数，其实现是调用__system_property_find函数，后者是要找到所找属性的入口。
这得遍历属性缓冲区的结构。这个缓冲区包括两个部分：目录和内容。目录项目的结构是：
struct prop_area {
unsigned volatile count;
unsigned volatile serial;
unsigned magic;
unsigned version;
unsigned reserved[4];
unsigned toc[1];
};
具体属性的结构是：
struct prop_info {
char name[PROP_NAME_MAX];
unsigned volatile serial;
char value[PROP_VALUE_MAX];
};
find函数的主要内容：
prop_area *pa = __system_property_area__;
unsigned count = pa->count;
unsigned *toc = pa->toc;
unsigned len = strlen(name);
while(count--) {
unsigned entry = *toc++;
if(TOC_NAME_LEN(entry) != len) continue;
pi = TOC_TO_INFO(pa, entry);
if(memcmp(name, pi->name, len)) continue;
return pi;
}
count是总共的属性数目，toc是属性目录的入口地址。以上循环中，entry是属性的偏移量，是个32位的整数，其高位字节存储的是属性名的长度，后24位存储的是属性在缓冲区里的偏移量。TOC_NAME_LEN就是取得目录项的高8位，而TOC_TO_INFO则是取得后24位，然后再加上属性缓冲区的入口地址，就得到具体属性的入口地址，然后再把类型转换为prop_info的指针，然后返回这个值。
还有个问题：系统属性的客户是如何获知__system_property_area__的位置呢？这些客户通过连接C库而能调用系统属性的各个API，但并不能自动获知系统属性缓冲区的地址，这个地址在每个客户进程装载时，都初始化为0。进程之间可以共享代码，但并不自动共享数据，除非程序做些特殊的处理，比如使用共享内存。此处利用了二进制文件（可执行文件或者库）的init段，即把一些必须的初始化代码，比如C++对象的构造函数，放在这个init段里，每次动态连接或装载二进制文件时，就首先执行这个初始化段。
gcc提供了constructor属性来指示把代码放在init段里。system_properties的缓冲区地址，是在bionic libC库的init段里被确定的。文件libc_init_dynamic.c的__libc_prenit函数调用了__libc_init_common，后者又调用了__system_properties_init，最后这个函数确定__system_property_area__的地址。而函数__libc_prenit被给予属性constructor：
void __attribute__((constructor)) __libc_prenit(void);
这样在bionic libc动态库被装载时，系统属性缓冲区地址就被确定了，后续的API调用就能找对位置了。
注：结合源代码看了这部分，看了还是不理解，先放在这里，说不定再回头看，就能理解了
