so文件和ndk

最新推荐文章于 2022-12-22 17:12:32 发布

葫芦娃你好我是皮卡丘

最新推荐文章于 2022-12-22 17:12:32 发布

阅读量2.1k

点赞数 1

分类专栏： bug 文章标签： ndk so文件

bug 专栏收录该内容

11 篇文章 0 订阅

订阅专栏

背景是在集成腾讯云的sdk的时候遇到了问题

 java.lang.UnsatisfiedLinkError: Native method not found: com.tencent.liteav.basic.log.TXCLog.nativeLogSetLevel:(I)V

这里写图片描述

原因是因为我的so文件写在了jniLibs下，

这里写图片描述
但是却在build.gradle中配置了这两段属性导致的错误

解决办法：
因为写在了jniLibs下所以要注释掉sourceSets
又因为只有"armeabi", "armeabi-v7a"这两种abi，所以要把不支持so文件的对应设备的文件夹去掉。

//    sourceSets {
//        main {
//            jniLibs.srcDirs = ['libs']
//        }
//    }


  ndk {
   //设置支持的SO库架构（开发者可以根据需要，选择一个或多个平台的so）
            abiFilters "armeabi", "armeabi-v7a"
        }

明白这段代码的意思
这些都是闭包，groovy脚本的基本概念

sourceSets {
        main {
            jniLibs.srcDirs = ['src/main/libs'] //这一句是设置目标的so存放路径，也就是组装到apk中的so路径
            jni.srcDirs = []  //这一句是禁用gradle默认的ndk-build，防止AS自己生成android.mk编译jni工程

        }
    }

查阅资料理解so文件和ndk
一、NDK
1、什么是NDK
NDK即Native Development Kit，众所周知，Android程序运行在Dalvik虚拟机中，NDK允许用户使用类似C / C++之类的原生代码语言执行部分程序。

NDK是一系列工具的集合。它提供了一系列的工具，帮助开发者快速开发C（或C++）的动态库，并能自动将so和java应用一起打包成apk(AndroidPackage的缩写，Android安装包)。这些工具对开发者的帮助是巨大的。它集成了交叉编译器，并提供了相应的mk文件隔离CPU、平台、ABI等差异，开发人员只需要简单修改mk文件（指出“哪些文件需要编译”、“编译特性要求”等），就可以创建出so。它可以自动地将so和Java应用一起打包，极大地减轻了开发人员的打包工作

NDK提供了一份稳定、功能有限的API头文件声明，Google明确声明该API是稳定的，在后续所有版本中都稳定支持当前发布的API。从该版本的NDK中看出，这些API支持的功能非常有限，包含有：C标准库（libc）、标准数学库（libm）、压缩库（libz）、Log库（liblog）。

2、为什么使用NDK
(1) 代码的保护。由于apk的java层代码很容易被反编译，而C/C++库反汇难度较大。
(2) 可以方便地使用现存的开源库。大部分现存的开源库都是用C/C++代码编写的。
(3) 提高程序的执行效率。将要求高性能的应用逻辑使用C开发，从而提高应用程序的执行效率。
(4)便于移植。用C/C++写得库可以方便在其他的嵌入式平台上再次使用。

二、so文件
1、什么是so文件
so文件是第三方应用开发者使用JNI完成了自己的C动态链接库（so）开发
NDK编译C/C++源代码文件生成动态链接库so，android系统编译生成的so文件放在\out\target\product\prj\system\lib目录下。

2、为什么使用so文件
如果只是使用Java语言进行编码，可能就不需要关注.so文件了，因为Java是跨平台的。但事实上，即使你在项目中只是使用Java语言，很多情况下，你可能并没有意识到项目中依赖的函数库或者引擎库里面已经嵌入了.so文件，并依赖于不同的ABI

1、so机制让开发者最大化利用已有的C和C++代码，达到重用的效果，利用软件世界积累了几十年的优秀代码；
2、so是二进制，没有解释编译的开消，用so实现的功能比纯java实现的功能要快
3、o内存分配不受Dalivik/ART的单个应用限制，减少OOM；
4、相对于java代码，二进制代码的反编译难度更大，一些核心代码可以考虑放在so中。

二、什么是ABI
Android 上有7种 CPU 架构。
1.armeabi
2.armeabi-v7a
3.arm64-v8a
4.x86
5.x86_64
6.MIPS
7.MIPS64
从厂家上来分是有三种，arm，x86，MIPS，arm 系列是绝大多数手机上使用的，x86 主要是运用在平板上，而 MIPS 基本上就没见过。
从类型来分，有32位和64位，名字中没有64的就是32位的了

正常的.armeabi-v7a 可以差不多适配所有的机型，但对于支持arm64-v8a 的手机来说，性能上就不如使用对应 CPU 架构的快了，毕竟是32位和64位的区别。

其实arm系列本身是没有64位的， intel 的x86_64先出现的，之后 arm 收购了 MIPS64，基于 MIPS64 改良出 arm64-v8a，所以也能理解为什么 MIPS 几乎没有。

arm64-v8a 的 CPU 架构上能运行 armeabi-v7a，不是因为64位的能运行32位的，是因为 arm64-v8a 上本身搭载了 armeabi-v7a。
如果项目中有多个so文件，要注意，如果一个so同时支持了 armeabi-v7a 和arm64-v8a，但是另一个so 只支持了一种，那可能会运行有问题，这时要么另一个 so 也支持两种，要么把第一个 so 删掉对应目录，只支持相同的一种。

在提供支持多个 CPU 架构的 SDK 时，可以同时提供多个目录的 so，虽然此时 SDK 相对较大，但是被编译的 so 还是以你在 gradle 里设置的支持的 ndk 为准：
如果不做任何设置，Android 的构建系统会把这些来自不同开发者的 SO 库都合并在一起，打进 APK 压缩包中。

ndk { 
abiFilters ‘armeabi-v7a’ // , ‘arm64-v8a’, ‘x86’, ‘x86_64’ 
}

以上这七种的每一种 CPU 构架，都定义了一种 ABI（Application Binary Interface），ABI 决定了二进制文件如何与系统进行交互

这里写图片描述
三、项目中的so文件
1、默认情况下，NDK只会为armeabi生成.so文件
为了能得到更好的性能表现，我们应该尽可能的直接提供所对应的so文件。比如，我们可以为x86手机直接提供x86的so文件，而不是仅提供arm的so让系统通过houdini去动态转换arm指令，避免转换过程中的性能损耗。
2、x86手机对arm的支持：
原本x86架构的CPU是不支持运行arm架构的native代码的，但Intel和Google合作在x86机子的系统内核层之上加入了一个名为houdini的Binary Translator（二进制转换中间层），这个中间层会在运行期间动态的读取arm指令并将之转换为x86指令去执行。
3、Android系统的ABI支持

Android可以在运行期间确定当前系统所支持的ABI，这是由系统编译时的具体参数指

primary ABI（主ABI）：对应当前系统中使用的机器码类型 secondary
ABI（副ABI）：表示当前系统支持的其他ABI类型机支持不止

一个ABI，比如，一个基于ARMv7的设备会将armeabi-v7a定义为primary ABI，armeabi作为secondary ABI，意味着这台机器同时支持armeabi-v7a和armeabi。
许多基于x86的设备也可以运行armeabi-v7a和armeabi的so，对于这些机器，primary ABI是x86，secondary ABI则是armeabi-v7a.

但是，为了能得到更好的性能表现，我们应该尽可能的直接提供primary ABI所对应的so文件。比如，我们可以为x86手机直接提供x86的so文件，而不是仅提供arm的so让系统通过houdini去动态转换arm指令，避免转换过程中的性能损耗。

4、apk安装过程中对so的选择：
在Android上安装应用程序时，Package Manager会扫描整个apk文件，寻找符合下面文件路径格式的动态连接库：

lib/<primary-abi>/lib<name>.so

在这里，primary-abi是上面表中的abi的值，name对应的是我们在Android.mk中定义的LOCAL_MODULE的值，
如果在apk内并没有找到适合当前机器primary-abi的so，Package Manager会尝试寻找适合secondary-abi的so文件：

lib/<secondary-abi>/lib<name>.so

即安装应用时，系统会根据当前CPU架构选择最优ABI适配，如果找到了合适的so文件，包管理器会将该ABI文件夹下所有so库全部拷贝至应用的data目录下：data/data/<package_name>/lib/

注意：apk安装过程对so选择是基于整个ABI文件夹的，而非以单个so文件为粒度，也就是说把lib/armeabi 、lib/armeabi-v7a、lib/x86等等文件夹的其中一个文件夹内所有.so复制到应用的data目录下。

如果我们在代码中调用了某个so的功能，而最终拷贝的ABI文件夹下并没有提供这个文件，apk的安装过程中并不会报错，但是运行时会遇到java.lang.UnsatisfiedLinkError。

四、通过精简so来减小包大小
现在的apk动辄几十M或者更大，apk包大小的精简成为了开发过程中的重要一环。通过上面的介绍，我们知道x86、x86_64、armeabi-v7a、arm64-v8a设备都支持armeabi架构的so，因此，通过移除不必要的so来减小包大小是一个不错的选择
按照ABI分别单独打包APK

我们可以选择在Google Play上传指定ABI版本的APK，生成不同ABI版本的APK可以在build.gradle中进行如下配置：

android {
    // Some other configuration here...
    splits {
        abi {
            enable true
            reset()
            include 'x86', 'armeabi', 'armeabi-v7a', 'mips' //select ABIs to build APKs for
            universalApk false // generate an additional APK that contains all the ABIs
        }
    }
}

只提供armabi的so

上面的方法需要应用市场提供用户设备CPU类型更识别的支持，在国内并不是一个十分适用的方案。常用的处理方式是利用gradle中的abiFilters配置。
首先配置修改主工程build.gradle下的abiFilters：

android {
    // Some other configuration here...
    defaultConfig {
        ndk {
            abiFilters 'armeabi'
        }
    }
}

abiFilters后面的ABI类型即为要打包进apk的ABI类型，除此以外都不打包进apk里。
然后在项目的根目录下的gradle.properties（没有的话新建一个）中加入下面这行：

android.useDeprecatedNdk=true

五、需要注意的问题

1、不要把so放错地方

首先要注意的是不要把另一个ABI下的so文件放在另一个ABI文件夹下（每个ABI文件夹下的so文件名是相同的，有可能会搞错）。
将.so文件放在错误的地方

我们往往很容易对.so文件应该放在或者生成到哪里感到困惑，下面是一个总结：

Android Studio工程放在jniLibs/ABI目录中（当然也可以通过在build.gradle文件中的设置jniLibs.srcDir属性自己指定）
Eclipse工程放在libs/ABI目录中（这也是ndk-build命令默认生成.so文件的目录）
AAR压缩包中位于jni/ABI目录中（.so文件会自动包含到引用AAR压缩包的APK中）
最终APK文件中的lib/ABI目录中
通过PackageManager安装后，在小于Android 5.0的系统中，.so文件位于app的nativeLibraryPath目录中；在大于等于Android 5.0的系统中，.so文件位于app的nativeLibraryRootDir/CPU_ARCH目录中。

作者：博麟Android
链接：http://www.jianshu.com/p/b758e36ae9b5
來源：简书
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

2、尽可能为所有ABI提供so

理想状况下，应该尽可能为所有ABI都提供对应的so，这一点的好处我们已经在上面讨论过了：在可以发挥更好性能的同时，还能减少由于兼容带来的某些crash问题。当然，这一点要结合实际情况（如SDK提供的so不全、芯片市场占有率、apk包大小等）去考量，如果使用的so本身就很小，我们大可为尽可能多的ABI都提供so。
若是局限于包大小等因素，可以结合通过精简so来减小包大小一节中提供的第三个方案来调整so的使用策略。

3、所有ABI文件夹提供的so要保持一致

这是一个十分容易出现的错误。
如果我们的应用选择了支持多个ABI，要十分注意：对于每个ABI下的so，但要么全部支持，要么都不支持。不应该混合着使用，而应该为每个ABI目录提供对应的.so文件。
先举个例子，Bugtags的so支持所有的ABI：

libs
|
├── arm64-v8a
│   └── libBugtags.so
├── armeabi
│   └── libBugtags.so
├── armeabi-v7a
│   └── libBugtags.so
├── mips
│   └── libBugtags.so
├── mips64
│   └── libBugtags.so
├── x86
│   └── libBugtags.so
└── x86_64
    └── libBugtags.so

但不是所有开发者提供的so都支持所有ABI：

lib
|
├── armeabi
│   └── libImages.so
└── armeabi-v7a
    └── libImages.so

如果不做任何设置，最终打出来的apk的lib目录会是这样的：

lib
|
├── arm64-v8a
│   └── libBugtags.so
├── armeabi
│   ├── libBugtags.so
│   └── libImages.so
├── armeabi-v7a
│   ├── libBugtags.so
│   └── libImages.so
├── mips
│   └── libBugtags.so
├── mips64
│   └── libBugtags.so
├── x86
│   └── libBugtags.so
└── x86_64
    └── libBugtags.so

参考上面apk安装过程中对so的选择一节，假设当前设备是x86机器，包管理器会先去lib/x86下寻找，发现该文件夹是存在的，所以最终只有lib/x86下的so–即只有libBugtags.so会被安装。当尝试在运行期间加载libImages.so时，就会遇上下面常见的UnsatisfiedLinkError错误：

E/xxx   (10674): java.lang.UnsatisfiedLinkError: dalvik.system.PathClassLoader[DexPathList[[zip file "/data/app/xxx-2/base.apk"],nativeLibraryDirectories=[/data/app/xxx-2/lib/x86, /vendor/lib, /system/lib]]] couldn't find "libImages.so"
E/xxx   (10674):     at java.lang.Runtime.loadLibrary(Runtime.java:366)

以，我们需要遵循这样的准则：

对于so开发者：支持所有的平台，否则将会搞砸你的用户。
对于so使用者：要么支持所有平台，要么都不支持。
然而，因为种种原因（遗留so、芯片市场占有率、apk包大小等），并不是所有人都遵循这样的原则。

一种可行的处理方案是：取你所有的so库所支持的ABI的交集，移除其他（可以通过上面介绍的abiFilters来实现）。
如上面的例子，最终生成的apk可以是:

lib
|
├── armeabi
│   ├── libBugtags.so
│   └── libImages.so
└── armeabi-v7a
    ├── libBugtags.so
    └── libImages.so

转载来源：
http://allenfeng.com/2016/11/06/what-you-should-know-about-android-abi-and-so/
http://blog.csdn.net/kester_/article/details/71055901
http://blog.csdn.net/loongembedded/article/details/39718577

葫芦娃你好我是皮卡丘

关注

1
点赞
踩
1

收藏

觉得还不错? 一键收藏
0
评论
so文件和ndk

背景是在集成腾讯云的sdk的时候遇到了问题 java.lang.UnsatisfiedLinkError: Native method not found: com.tencent.liteav.basic.log.TXCLog.nativeLogSetLevel:(I)V原因是因为我的so文件写在了jniLibs下，但是却在build.gradle中配置了这两段属性导致的错误解决办法：
复制链接

扫一扫