像风一样扫过Android吧!
binder的实现看来比较复杂(jsaid),需要看kernel 比较多的binder.c代码,但其最终实现机制与ashmem差不多,都依赖于mmap与文件映射相关,,,阿米老婆 ,这我就放心了
今天咱们配合着启动过程,看看libc之类的库吧---->前半程计划
与glibc相比，Bionic Libc有如下一些特点：
- 采用BSD License，而不是glibc的GPL License；
- 大小只有大约200k，比glibc差不多小一半，且比glibc更快；
- 实现了一个更小、更快的pthread；
- 提供了一些Android所需要的重要函数，如”getprop”, “LOGI”等；
- 不完全支持POSIX标准，比如C++ exceptions，wide chars等；
- 不提供libthread_db 和 libm的实现
另外，Android中所用的其他一些二进制工具也比较特殊：
- 加载动态库时使用的是/system/bin/linker而不是常用的/lib/ld.so;
- prelink工具不是常用的prelink而是apriori，其源代码位于” /build/tools/apriori”
- strip工具也没有采用常用的strip，即“/prebuilt/linux-x86/toolchain/arm-eabi-4.2.1/bin”目录下的arm-eabi-strip，而是位于/out/host/linux-x86/bin/的soslim工具。
注意到一段话 要小心理解
目前Google的策略是不会加入Native C++这样的本地语言开发，除了安全性考虑似乎这样可以有效的保证平台的控制权限，很多性能敏感的程序只有通过和Google合作加入到系统底层才可以，用户最终只能在Dalvik层做开发。虽然完全开源，但最终的APK文件必需经过签名才可以安装到Android手机上，这样可以有效的排挤竞争对手，目前很多浏览器厂商已经发现这个严重的问题，比如Firefox、Opera已经无法在Android平台上发展了，无论Java代码优化、算法再精炼只能在Dalvik VM上运行，而Android自带的浏览器Chrome Lite使用的webkit内核是C++编写的库文件，提供Java接口上层调用，所以最终这个平台的限制还是很大的
阅读(765) | 评论(0) | 转发(0) |
