Android架构 armeabi、armeabi |
您所在的位置:网站首页 › 华为p30系统崩溃刷机管用么 › Android架构 armeabi、armeabi |
最近在用flutter打包的时候,遇到了包打不出来的情况,后面查了半天原因,发现是没有配置arm导致的,配了之后就打出来了,乘着这个契机,重头来学习了一下abi 开始之前开始之前先需要知道lib、libs等知识 一. lib和libs放在lib中的是被reference的,放在libs中的是被include的。 放在libs中的文件会自动被编辑器所include。所以不要把API放到libs里去。 lib的内容是不会被打包到APK中,libs中的内容是会被打包进APK中 二. .so库NDK编译出来的动态链接库。 一些重要的加密算法或者核心协议一般都用c写然后给java调用。这样可以避免反编译后查看到应用的源码。 三. .so库该如何存放放置 .so 文件的正确姿势其实就两句话: • 为了减小 apk 体积,只保留 armeabi 和 armeabi-v7a 两个文件夹,并保证这两个文件夹中 .so 数量一致 • 对只提供 armeabi 版本的第三方 .so,原样复制一份到 armeabi-v7a 文件夹 存放so的规则: 你应该尽可能的提供专为每个ABI优化过的.so文件,但要么全部支持,要么都不支持:你不应该混合着使用。你应该为每个ABI目录提供对应的.so文件。 关于存放的问题,可以详细看看这篇 四. libs下armeabi等的作用是什么存放.so库,主要针对不同的设备兼容,也可以说是专门针对不同Android手机下CPU架构的兼容。 下面就来扯一下安卓cpu Android 设备的CPU类型(通常称为”ABIs”) 架构介绍早期的Android系统几乎只支持ARMv5的CPU架构,后面发展到支持七种不同的CPU架构:ARMv5,ARMv7 (从2010年起),x86 (从2011年起),MIPS (从2012年起),ARMv8,MIPS64和x86_64 (从2014年起),每一种都关联着一个相应的ABI。 应用程序二进制接口(Application Binary Interface)定义了二进制文件(尤其是.so文件)如何运行在相应的系统平台上,从使用的指令集,内存对齐到可用的系统函数库。在Android 系统上,每一个CPU架构对应一个ABI:armeabi,armeabi-v7a,x86,mips,arm64- v8a,mips64,x86_64。 但是最新的谷歌官方文档已经把mips和armv5移除了,如图所示: 无图无真相: 2020.06更新, 看到一篇很好的文章搬过来了,感谢原作者(https://juejin.im/post/5eae6f86e51d454ddb0b3dc6) 官方文档解释如下: Android 系统在运行时知道它支持哪些 ABI,因为版本特定的系统属性会指示: 设备的主要 ABI,与系统映像本身使用的机器代码对应。(可选)与系统映像也支持的其他 ABI 对应的辅助 ABI。 此机制确保系统在安装时从软件包提取最佳机器代码。为实现最佳性能,应直接针对主要 ABI 进行编译。例如,基于 ARMv5TE 的典型设备只会定义主 ABI:armeabi。相反,基于 ARMv7 的典型设备将主 ABI 定义为 armeabi-v7a,并将辅助 ABI 定义为 armeabi,因为它可以运行为每个 ABI 生成的应用原生二进制文件。 64 位设备也支持其 32 位变体。以 arm64-v8a 设备为例,该设备也可以运行 armeabi 和 armeabi-v7a 代码。但请注意,如果应用以 arm64-v8a 为目标,而非依赖于运行 armeabi-v7a 版应用的设备,则应用在 64 位设备上的性能要好得多。 许多基于 x86 的设备也可运行 armeabi-v7a 和 armeabi NDK 二进制文件。对于这些设备,主 ABI 将是 x86,辅助 ABI 是 armeabi-v7a。 总的来说,就是一个Android设备可以支持多种ABI,设备主ABI和辅助ABI,以arm64-v8a为主ABI的设备,辅助ABI为armeabi-v7a和armeabi,以armeabi-v7a为主ABI的设备,辅助ABI为armeabi。 另外,x86 架构的手机都会包含由 Intel 提供的称为 Houdini 的指令集动态转码工具,实现对 arm .so 的兼容,也就是说有适配armeabi平台的APP是可以跑在x86手机上的。 ABI具体适配流程
Q1: 只适配了armeabi-v7a,那如果APP装在其他架构的手机上,如arm64-v8a上,会蹦吗? A: 不会,但是反过来会。 因为armeabi-v7a和arm64-v8a会向下兼容: 只适配armeabi的APP可以跑在armeabi,x86,x86_64,armeabi-v7a,arm64-v8上只适配armeabi-v7a可以运行在armeabi-v7a和arm64-v8a只适配arm64-v8a 可以运行在arm64-v8a上那我们该如何适配呢?给出如下几个方案: 方案一:只适配armeabi 优点:基本上适配了全部CPU架构(除了淘汰的mips和mips_64) 缺点:性能低,相当于在绝大多数手机上都是需要辅助ABI或动态转码来兼容 方案二:只适配 armeabi-v7a 同理方案一,只是又筛掉了一部分老旧设备,在性能和兼容二者中比较平衡 方案三: 只适配 arm64-v8 优点: 性能最佳 缺点: 只能运行在arm64-v8上,要放弃部分老旧设备用户 这三种方案都是可以的,现在的大厂APP适配中,这三种都有,大部分是前2种方案。具体选哪一种就看自己的考量了,以性能换兼容就arm64-v8,以兼容换性能armeabi,二者稍微平衡一点的就armeabi-v7a。 对于64位手机跟64位处理器ARM64位处理器和电脑的64位处理器是两个截然不容的概念,他并不是64位就能原生向下兼容32位程序,而是通过64位处理器中集成的32位架构来运行32位程序。说得通俗点,它不是以64位形态来运行32位程序,却是以32位的形态运行32位程序的。 由于目前新出的64位处理器包含两个架构,而且制程技术没有提升(28nm),同时在手机与平板上,芯片面积有着严格的限定,不能过分增加,这导致64位ARM处理器平均分配到每个架构的晶体管数量锐减,也就是说从64位处理器中的32位架构方面,对于同规格的32位处理器而言,不但没有提高,性能反而是一定规模下降的。但处理器厂家又必须给消费者一个交代,以更好的推广64位,所以厂家就必须在其他方面提升性能,以弥补CPU的晶体管数量减少带来的损失。比如:更换性能更强的GPU、提升内存带宽、多核心虚拟单颗核心提升单核性能、联合跑分软件商修改跑分权重(提升GPU分数,降低CPU分数的权重)等等。这样,扬长避短,最终到达消费者手里,用跑分软件一跑,确实有提升,用户开心,厂家腰包也鼓了。 综上所述,ARM64位处理器从严格意义来说,叫它ARM32+64更加贴切,他相对于ARM32位处理器,有倒退的地方,也有进步的余地,但正因为倒退激起了ARM进取的决心,让它大刀阔斧的向前变革,不得不说也算一种进步。但ARM64在的手机上真的有用吗?我只能说,目前确实没啥用,但今后或许有。(其他地方搜罗的) 综上所述,ARM64位处理器从严格意义来说,叫它ARM32+64更加贴切,他相对于ARM32位处理器,有倒退的地方,也有进步的余地,但正因为倒退激起了ARM进取的决心,让它大刀阔斧的向前变革,不得不说也算一种进步。但ARM64在的手机上真的有用吗?我只能说,目前确实没啥用,但今后或许有。(其他地方搜罗的) 真正的64位手机并不止单纯停留在处理器上,如果只因为它的处理器是64位,就称其为64位手机的话,我们可以毫不犹疑的说这可能是虚假宣传,好在联想很聪明,在发布A678t和A805e宣传的时候,只说64位处理器手机。 “64位处理器手机”与“64位手机”是两种天壤之别的概念:只要是处理器包含64架构位的,就可以称“64位处理器手机”,这种手机也许还运行不了64位程序,只是用来抢占市场,和32位手机比起来优势并不明显。 “64位手机”就不同了:它包含着64位处理器、64位标准系统、64位安卓虚拟机、以及64位程序,这才是真正意义上的64位手机! 谷歌官方曾说,安卓很早前就支持64位了,这话不假,从Android4.0到Android4.4,安卓系统都支持64位的硬件,但是这仅仅表示底层驱动支持64位,能运行在64位的硬件之上,仅此而已。然而,上层运行软件的,无论是Dalvik的虚拟机,还是ART虚拟机都是32位的。也就是说,只要你的手机系统是Android4.0—4.4,即便你的处理器是64位,也只能在32位虚拟机下运行32位程序,就算真的64位程序摆在你眼前,也无法安装。。 但是谷歌官方2019年初就已经发布强制需要64位架构: 因此,项目之前强制只使用armeabi一种架构的方式已经不行了。 那这里说的 64 位版本支持,到底是什么? 如果你的应用,完全是使用 Java 或者 Kotlin 编写代码,不包含任何原生(Native)的支持,那么就表示这个应用已经支持 64 位。 但是应用内使用了任何原生(Native)的支持(so 库),就需要针对这些 so 文件,针对不同的 CPU 架构提供不同的版本的 so 支持。 需要注意的是,有些时候,在我们自身的代码中,确实没有用到原生的支持,但是在 App 中使用的一些第三方库中却包含了。 此时最稳妥的方式,就是针对最终打包生成的 APK 文件进行分析,来判断是否需要提供 64 位架构的支持。 打包配置split分包 这个命令可以按照各种规则去分包,比如按照abi,屏幕密度(即ldpi,hdpi等)分包 splits { abi { enable true reset() include 'x86','armabi' exclude 'armeabi', 'armeabi-v7a', "arm64-v8a" universalApk true } }include就是包括,exclude就是不包括。包括的配置每一个项都会生成一个apk包。 但是这样配置,会生成两个包,一个只包含x86的so库,一个只包含armabi的so库。,显然不符合需求 ndk{abiFilters:}过滤 这个指令可以配置只打包你配置的so库,没有配置的就不打包,很灵活。 第三方aar文件,如果这个sdk对abi的支持比较全,可能会包含armeabi、armeabi-v7a、x86、arm64-v8a、x86_64五种abi,而你应用的其它so只支持armeabi、armeabi-v7a、x86三种,直接引用sdk的aar,会自动编译出支持5种abi的包。但是应用的其它so缺少对其它两种abi的支持,那么如果应用运行于arm64-v8a、x86_64为首选abi的设备上时,就会crash了,所以我们需要在我们的app中配置 abiFilter 配置,来避免一些未知的错误 //过滤x86的so库 ndk { abiFilters 'armeabi', 'armeabi-v7a', 'arm64-v8a' }这样配置会将armeabi,armeabi-v71,arm64-v8a这3个包下的so库都打包到一个apk,而不像splits会每一个包打一个apk. 参考: 对于android cpu架构 ARM 和x86的区别 按照cpu架构分别打包Apk Android 中arm64-v8a、armeabi-v7a、armeabi、x86简介~ https://juejin.im/post/5eae6f86e51d454ddb0b3dc6 |
今日新闻 |
推荐新闻 |
CopyRight 2018-2019 办公设备维修网 版权所有 豫ICP备15022753号-3 |