1.so文件
一种CPU架构 = 一种对应的ABI参数 = 一种对应类型的SO库
早期的Android系统几乎只支持ARM的CPU架构，不过现在至少支持以下七种不同的CPU架构：ARMv5，ARMv7，x86，MIPS，ARMv8，MIPS64和x86_64。每一种CPU类型都对应一种ABI（Application Binary Interface），这7种CPU类型对应的SO库的文件夹名是：armeabi，armeabi-v7a，x86，mips，arm64-v8a，mips64，x86_64。
不同类型的移动设备在运行APP时，需要加载自己支持的类型的SO库，一般情况下，不需要开发者自己去判断ABI，Android系统在安装APK的时候，不会安装APK里面全部的SO库文件，而是会根据当前CPU类型支持的ABI，从APK里面拷贝最合适的SO库，并保存在APP的内部存储路径的libs下面。（这里说一般情况，是因为有例外的情况存在，比如我们动态加载外部的SO库的时候，就需要自己判断ABI类型了。
Android apk的安装过程
Apk文件其实只是一个归档zip压缩包，最终会被分解各个文件。
1.复制apk到/data/app 或者/system/app
2. /data/data/包名 -------自动生成存储数据的文件，so文件也是存储在这里的（系统目录下的app不会自动生成so文件，而是直接读取/system/lib 文件夹）。
2.,data/dalvik-cache-------存储.dex文件,但为了提高运行性能,android系统并不会直接执行.dex,而是会在安装过程中执行dexopt操作来优化.dex文件,最终android系统执行的时优化后的'odex'文件(注意:这个odex文件的后缀也是.dex,其路径在data/dalvik-cache)。对于dalvik虚拟机,dexopt就是优化操作,而对于art虚拟机,dexopt执行的则是dex2oat操作,既将.dex文件翻译成oat文件。
2.动态加载的基本思路和优点
基本思路
1.判断本地的cpu类型
2.通过网络下载指定的so文件
3.复制到指定目录进行loadLibrary
动态加载的优点
1.灵活，so 文件可以动态加载，不是绑定死的，修改方便，so 库有问题，我们可以动态更新。
2.so 库文件很大的话，采用动态加载可以减少 apk 的包，变小。
3.具体实现逻辑
1.判断本地类型的显示方式
a.通过获取android.os.Build.CPU_ABI，android.os.Build.CPU_ABI2
b.通过读取/proc/cpuinfo文件，然后判断CPU架构
具体代码：
输出日志：
04-01 17:47:35.779: E/tag(1457): CPU：armeabi-v7a,--armeabi
04-01 17:47:35.779: E/tag(1457): line：Processor : ARMv7 Processor rev 1 (v7l)
2.通过网络下载so文件
3.放到指定目录
调用System.loadLibrary()会自动读取
a./data/data/包名/lib
b./data/app-lib/包名
c./system/lib
d./vendor/lib
所以，目录可以选择这几个，也可以自行选择其他目录。调用其他目录的时候需要写路径全称
两种调用方式示例
a.System.loadLibrary("dbapi")
b.System.loadLibrary("/data/user/0/包名/lib/libdbapi.so")
4.可能遇见的问题
1.加载时间的调用
动态加载虽然有很多优点，但是有延迟性，如果一些效果在刚启动就要调用，就必须打包到apk里面。
2.逻辑需要处理
必须处理在没有加载成功的情况下，代码逻辑不引起异常奔溃。
参考
