转自:https://blog.csdn.net/u012400885/article/details/52923765
版权声明:本文为博主原创文章,转载请注明出处。 https://blog.csdn.net/u012400885/article/details/52923765
LZ-Says:给大家推荐一个网站,有兴趣可以查阅,想为大家贡献一点自己的力量也可以投稿,老大审核通过会发表,更好的帮助有需要的人~欢迎大家踊跃投稿~地址如下:
http://www.123si.org/androidLZ是一名96年Android小生,从14年9月培训出来到现在,差不多俩年多的时间,由于一些原因,没能好好把技术提升一下,实乃不该啊。
了解起因
昨天师傅问,你知道这俩个是什么么?有什么作用么?(如下图所示)
现在还记得我那一脸蒙比的样子,诺诺的回答不晓得。师傅说这个是为了兼容一些手机,(此处省略滔滔不绝若干。。。)。听的我更加蒙比了,之前只是知道要把.so库扔进去,但是为什么扔,就不懂了,何谈我怎会知道那目录?(PS:还是自己差太多了。。。)好尴尬。。。
查询前期准备
首先按照四个部分来查询,分别如下:
一. lib和libs是否一样?
二. .so库又是什么鬼?
三. .so库又该如何存放?
四. libs下armeabi等的作用是什么?
查询ING
一. lib和libs是否一样?
放在lib中的是被reference的,放在libs中的是被include的。
放在libs中的文件会自动被Eclipse所include。所以不要把API放到libs里去。
lib的内容是不会被打包到APK中,libs中的内容是会被打包进APK中二. .so库又是什么鬼? NDK编译出来的动态链接库。
一些重要的加密算法或者核心协议一般都用c写然后给java调用。这样可以避免反编译后查看到应用的源码。三. .so库又该如何存放?
放置 .so 文件的正确姿势其实就两句话:
• 为了减小 apk 体积,只保留 armeabi 和 armeabi-v7a 两个文件夹,并保证这两个文件夹中 .so 数量一致
• 对只提供 armeabi 版本的第三方 .so,原样复制一份到 armeabi-v7a 文件夹
BUT,处理.so文件时有一条简单却并不知名的重要法则。
你应该尽可能的提供专为每个ABI优化过的.so文件,但要么全部支持,要么都不支持:你不应该混合着使用。你应该为每个ABI目录提供对应的.so文件。
四. libs下armeabi等的作用是什么?
存放.so库,主要针对不同的设备兼容,也可以说是专门针对不同Android手机下CPU架构的兼容。
下面就来扯一下安卓cpu
Android 设备的CPU类型(通常称为”ABIs”)
早期的Android系统几乎只支持ARMv5的CPU架构,你知道现在它支持多少种吗?7种!
Android系统目前支持以下七种不同的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 / mips64: 极少用于手机可以忽略
• x86 / x86_64: x86 架构的手机都会包含由 Intel 提供的称为 Houdini 的指令集动态转码工具,实现 对 arm .so 的兼容,再考虑 x86 1% 以下的市场占有率,x86 相关的两个 .so 也是可以忽略的
• armeabi: ARM v5 这是相当老旧的一个版本,缺少对浮点数计算的硬件支持,在需要大量计算时有性能瓶颈
• armeabi-v7a: ARM v7 目前主流版本
• arm64-v8a: 64位支持
所谓的ARMv8架构,就是在MIPS64架构上增加了ARMv7架构中已经拥有的的TrustZone技术、虚拟化技术及NEON advanced SIMD技术等特性,研发成的。
<span style="color:rgba(0, 0, 0, 0.75)"><span style="color:#000000"><code> 64位ARMv8架构中包含两个执行状态:AArch32(也就是我们常说的ARMv7)和AArch64(ARMv8)。AArch64执行状态针对64位处理技术,引入了一个全新指令集A64(也就是基于收购的MIPS64架构),而AArch32执行状态将支持现有的ARM指令集。所以64位的ARM处理器中同时包含着32位的ARMv7和64位的ARMv8两种架构。因此:
看到这里,你一定明白了,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在的手机上真的有用吗?我只能说,目前确实没啥用,但今后或许有。(其他地方搜罗的)
真正的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位程序摆在你眼前,也无法安装。
</code></span></span>
Android L开始才真正支持32位和64位的ART虚拟机,配合上64位处理器,名正言顺的运行64位软件。但是问题又来了,没有软件商 愿意开发64位程序。
ARMv8是一套不错的指令集,它既支持未来的64位程序,也向下兼容现有32位程序。有了ARMv8的支撑,以后的64位手机操作系统,如Android L 64bit都可以简单、高效地支持现有的32位App,你不用担心兼容性问题。
PS:在2011年11月,ARM公司发布了新一代处理器64位架构ARMv8的部分技术细节(也就是我们常说的Cortex-A57A53),代表着未来移动处理器迈入64位行列。我们得明确一点,ARM公司自己本身并没有64位芯片设计技术,他是通过了收购MIPS64处理器架构的部分技术使用权,再结合ARM的一些特性设计出来的。也就是说:MIPS、ARM、X86三大架构中,唯一没有64位技术的ARM,通过收购MIPS的形式得到了64位。
参考资源如下:
1) https://zhidao.baidu.com/question/1367175903363573459.html?skiptype=2
2) https://www.zhihu.com/question/20235319
3) http://www.voidcn.com/blog/u013278099/article/p-4944290.html
4) https://zhuanlan.zhihu.com/p/23102158
5) https://zhuanlan.zhihu.com/p/21359984