第一时间获取 IT 技术干货！
阅读文本大概需要 5 分钟。
1
有 哪 些 CPU 架 构
我们在日常开发中接触比较多的就两类：X86、arm
如上图所示，armabi的库可以运行在x86、x86-64以及armabi-v7a和armabi-v8a的CPU架构上，从下往上的方向上，下方架构的so库可以兼容的运行在更上方的CPU架构中，只是可能会出现性能问题。比如PC端跑模拟器的时候，就比较卡顿。
当我们在我们项目中的libs中新建不同的CPU架构的目录文件时一定要注意一点就是在同一架构目录中一定要提供全部的so库。这是因为加载so的策略所决定的，假设你当前在arm64-v8a的机器上，然后你需要加载两个so库：liba.so、libb.so。
那么显然会优先去寻找与其CPU架构匹配的目录下寻找so包，如图：
那如果我们将该arm64-v8a下面的libb.so删除掉会怎么样呢？
其实这时候会出问题的，因为只是删除了一个文件，而arm64i-v8a的文件目录还存在，当需要加载libb.so时，还是会去arm64-v8a目录下去寻找，显然是找不到的。但如果我们将整个目录删除了，反而能正常：
没错，只有在arm64-v8a目录不存在的时候才会去兼容包里加载。到这里作为初级工程师一般都会了解。
2
SO 混 用
一般情况下，我们不太可能完完全全提供所有CPU架构的so库的，那样会让你的APK大小变的很恐怖。所以，我们一般会提供一套兼容的比如只使用armabi（兼容性最好）的so。但是如果都是只使用armabi的必然会引起许多的性能问题，针对这一点呢，有人就采用混用的方式（包括微信），如下图所示：
例如你使用v7a架构的手机，对一些性能要求比较高的so，可以将其对应的v7a的so包放到armabi目录中，在代码中根据判断当前手机的cpu架构来选择加载更适合的so库，但是前提是cpu位数要相同，你不能将arm64-v8a（64位）的so放到armabi（32位）中。为什么？因为如果我们的机器是64位的，我们将64位的so混在armabi（32位）中，当机器检测到只有armabi的目录，会以32位的模式去加载so。 到这里作为一名中级工程师是都需要了解的。
3
优 化
因为添加so库，必然会造成apk包体的增大，所以在一些非启动就必须加载的so库，完全可以去动态加载，在使用的时候再去加载它。
对于必须要加载的我们可以考虑如何去减小so的体积，当然我们可以从下面几个方面去优化它：
1、隐藏所有的符号，只公开必要的：-fvisibility=hidden 2、禁用 C Exception 和 RTTI： -fno-exception -fno-rtti 3、不使用iostream，使用Android Log 4、使用 gc-sections去除无用代码
除了上面所讲的，还可以从另外的手段去做优化，比如构建时分包，根据CPU的架构打不同的包，目前很多商店是支持按CPU架构分发安装包的。
另外，如果你是一名SDK开发者，这里有几点注意值得你关注一下：
1、尽量不在Native层开发，降低SDK的维护成本 2、尽量优化Native库的体积，降低接入开发者的使用成本 3、必须提供完整的CPU架构依赖库供开发者使用
到这里为止呢，基本具有高工的潜质了。
