ndk文件操做问题及小结

      最近在作文件传输，发如今android下用f系列的C库函数去读取文件文件大小会受到2G大小的约束，查阅了好久，最后只能去看google的libc源码，发现了如下几个问题：

     一、bionic的libc是谷歌基于bsd开发的，大约200k左右，比gnu的libc小一半左右，也比uClibc小，谷歌应该不仅是为了规避LGPL的静态连接约束才单独开发的，多是为了效率问题；

     二、gnu的ftello等系列函数通常能够用宏-D_FILE_OFFSET_BITS 64指定off_t的类型来控制函数是否支持2G以上的文件，也能够用_LARGEFILE_SOURCE来支持ftello64位之类的函数。但这些宏在ndk里失效，彻底不可用。ftello64在bionic里是没有声明和定义的，有兴趣能够去看ftell.c的源码，因此_LARGEFILE_SOURCE失效。那么第一个宏为什么也会失效呢？先看下其声明：

off_t ftello(FILE *fp)

　　而后追踪off_t的定义：

#ifndef _OFF_T_DEFINED_
#define _OFF_T_DEFINED_
typedef __kernel_off_t       off_t;
#endif

　　继续追踪__kernel_off_t，看其是否受宏-D_FILE_OFFSET_BITS的影响：

typedef long __kernel_off_t;

　　到这里就明了了，可能等谷歌出了64位的android系统才会支持ftello之类的64位c库函数吧。

      既然存在以上的问题，那么如何读取2G以上的文件呢？其实能够绕开libc，用系统库函数，固然因为没有缓冲区，效率固然就低一些。谷歌提供了lseek64，配合read和write，就能够操做4G以上的文件了。看下lseek64的声明：

extern off64_t lseek64(int, off64_t, int);

　　本身有兴趣能够追踪off64_t，其实就是long long。

      虽然解决问题了，但我仍是想拓展一下，bionic对部分posix风格支持的也不太好，如C++ exceptions和wide chars。其实ios也同样，都只是尽可能支持，但不彻底，因此我之前写了一个mmap跨平台程序在ios7如下版本正常，但在ios7直接崩溃，你们当心点就好。为了效率，还能够看看mmap如何操做大文件及效率对比。