有关android的property机制 (property_set() & property_get())
2015-11-15 20:56
1401 查看
有关android的property机制
今天跟璋儿讨论到系统配置的问题。最常见的做法是由一个进程来维护这些配置,进行读写。其它的进程如果需要set/get某一配置项,需要通过socket发送消息到管理进程。
我想到了android的property机制。其实property就是name&value对,与常见系统中的配置项没有差异。在android系统中,大量使用了property_set和property_get,用来设置和获取某一property。下面来分析一下。
property_set/property_get位于libcutils.so库。任何进程若要调用这两个函数,需要链接libcutils.so。
libcutils.so调用到了__system_property_set和__system_property_get函数,这两个函数位于bionic库中,源代码文件为bionic/libc/bionic/system_properties.c,生成的库文件为libc_common.so。
对于set和get,分别会创建socket,发送消息到服务端。服务端位于init进程中,有一个property_service进程专门负责这个。该service读取socket消息,进行set和get的处理。property_service代码位于system/core/init/property_service.c
在system_properties.c和property_service.c中都用到了共享内存(用mmap实现),这里我开始有些搞不懂:如果用socket机制的话,只需要管理进程来维护内存即可,客户端不许要访问该内存,干嘛要用共享内存呢?
原来,android这样做是为了效率考虑。在system_properties.c的get调用中,可以通过只读方式访问共享内存,直接获取配置。当然了,为了保证get的时候别人不在set,避免读写冲突,get时需要等待一个信号量。对于set,system_properties.c会通过socket发送消息到service端处理,service端增加或者更新property后会wake该信号量。service端以读写方式打开共享内存。
为什么要这样设计呢?因为系统中由大量的get调用,get可以直接访问共享内存,所以访问更快。对于set,需要交给服务端处理,这样开销比较大,因为用到了socket,但因为set调用相对较少,所以问题也不严重。另为,android系统由以ctl打头的property,这种property比较特殊,可以控制服务的运行和停止,将这些控制放在service(即init进程)也就理所当然了!
附上一个框图:
今天跟璋儿讨论到系统配置的问题。最常见的做法是由一个进程来维护这些配置,进行读写。其它的进程如果需要set/get某一配置项,需要通过socket发送消息到管理进程。
我想到了android的property机制。其实property就是name&value对,与常见系统中的配置项没有差异。在android系统中,大量使用了property_set和property_get,用来设置和获取某一property。下面来分析一下。
property_set/property_get位于libcutils.so库。任何进程若要调用这两个函数,需要链接libcutils.so。
libcutils.so调用到了__system_property_set和__system_property_get函数,这两个函数位于bionic库中,源代码文件为bionic/libc/bionic/system_properties.c,生成的库文件为libc_common.so。
对于set和get,分别会创建socket,发送消息到服务端。服务端位于init进程中,有一个property_service进程专门负责这个。该service读取socket消息,进行set和get的处理。property_service代码位于system/core/init/property_service.c
在system_properties.c和property_service.c中都用到了共享内存(用mmap实现),这里我开始有些搞不懂:如果用socket机制的话,只需要管理进程来维护内存即可,客户端不许要访问该内存,干嘛要用共享内存呢?
原来,android这样做是为了效率考虑。在system_properties.c的get调用中,可以通过只读方式访问共享内存,直接获取配置。当然了,为了保证get的时候别人不在set,避免读写冲突,get时需要等待一个信号量。对于set,system_properties.c会通过socket发送消息到service端处理,service端增加或者更新property后会wake该信号量。service端以读写方式打开共享内存。
为什么要这样设计呢?因为系统中由大量的get调用,get可以直接访问共享内存,所以访问更快。对于set,需要交给服务端处理,这样开销比较大,因为用到了socket,但因为set调用相对较少,所以问题也不严重。另为,android系统由以ctl打头的property,这种property比较特殊,可以控制服务的运行和停止,将这些控制放在service(即init进程)也就理所当然了!
附上一个框图:
相关文章推荐
- Android经典例子收藏笔记1
- Android ListView setSelection()方法的介绍
- Android Theme and style
- Android联机或者模拟器单独测试Activity的辅助Activity示例开发
- Android读书笔记----Service的用法
- 《第一行代码Android》学习日记1 4000 3
- Android中通过泛型解决findViewById需要强制类型转换的问题
- 初学Android项目:开发电子市场<第三天>
- Android 总结:Manifest文件中,application和activity标签属性详解
- Android Studio的使用(九)--设置IDE编码格式
- 理清contactsprovider
- 安卓开发之CheckedBox和RadioGroup
- Android Intent使用总结
- Android(4)——Property Animation属性动画
- Android驱动调试利器Busybox之初体验
- Gradlle 全解析(Android官方技术文档翻译)
- android(仿QQ向右滑动退出)在viewpager中onTouchEvent无法监听到ACTION_DOWN的getX的值
- 【Android】Scheme详解
- bsh for android : Socket Test
- 【Android开发—电商系列】(一):ListView,就这么美