http://blog.csdn.net/hhh901119/article/details/71175609
用readelf -SW libxxx.so可以看到动态库里的信息; 发现有需要.debug信息段。
用命令arm-linux-androideabi-strip --strip-debug libxxx.so; 对动态库中的含.debug_xxx的section进行裁剪
用命令arm-linux-androideabi-strip --strip-all libxxx.so; 对动态库中的名为.symtab和.strtab的section进行裁剪
http://blog.csdn.net/Zaratustra/article/details/77837531
- gc-sections参数
LOCAL_CPPFLAGS += -ffunction-sections -fdata-sections
LOCAL_CFLAGS += -ffunction-sections -fdata-sections
LOCAL_LDFLAGS += -Wl,--gc-sections这个参数可以说是意外之喜了，居然能缩减大约200k(20%)左右的提示，因此简单研究了一下这个参数设置的原理。
GCC链接操作是以section作为最小的处理单元的，只要一个section中有某个符号被引用，该section就会被加入。如果没有加入-ffunctipn-sections和-fdata-sections所有的function和data都会放到同一个section中生成.o文件。使用了两个参数后，编译生成的.o文件将会拆分成许多个section，每个section只包含一个function，并且该section的名字为function的名字。因为插入了很多个section声明，所以自然加入两个参数后，生成的.o文件都会比较大，但是在后面的链接阶段，这样的拆分就会很有很大的作用。
在链接阶段，由于上述的拆分操作，链接过程中可以很方便的标记出哪些function被使用到，哪些function没有被使用到，这样就可以将没有使用到的function剔除出最后生成的so库中，由于生成的so不会将section的拆分保留，所以上面因为section产生的体积增加就会消失，并且无用的function会被删除，这样整个so的体积就会大大减小了。其实整个过程有点类似于java proguard的optimize过程，但是Java会有反射，动态加载等过程，所以optimize用得会比较少。C++貌似没有类似机制（由于不是很精通C/C++所以不太肯定），否则也会有坑。
使用CMake设置strip
set(CMAKE_STRIP "/usr/local/arm/linux_arm_2416eabi/bin/arm-s3c2416-linux-gnueabi-strip")
ADD_CUSTOM_COMMAND(TARGET ${LIB_NAME}
POST_BUILD
COMMAND ${CMAKE_STRIP} *.so )