实在汗颜，之前写过一篇文章记录了新版高德地图使用过程中在不同版本的手机上有崩溃的现象，崩溃原因在于某些平台的机子上找不到底层JNI库导致的，还写了解决方式，后来发现只是治标不治本，一直没有时间去更改，今天抽空修改一下最终的解决方案。
其实高德地图SDK中已经兼容了平台问题，只是我们不知道怎么弄而已。先来介绍一下各个平台。
下面这篇文章是从网上找来的，介绍的十分充分：
armeabi-v7a，armeabi，arm64-v8a
armeabi就是针对普通的或旧的arm v5 cpu，armeabi-v7a是针对有浮点运算或高级扩展功能的arm v7 cpu。
armeabi-v7a（32位ARM设备），arm64-v8a（64位ARM设备）
在2011年11月，ARM公司发布了新一代处理器64位架构ARMv8的部分技术细节（也就是我们常说的Cortex-A57A53），代表着未来移动处理器迈入64位行列。我们得明确一点，ARM公司自己本身并没有64位芯片设计技术，他是通过了收购MIPS64处理器架构的部分技术使用权，再结合ARM的一些特性设计出来的。也就是说：MIPS、ARM、X86三大架构中，唯一没有64位技术的ARM，通过收购MIPS的形式得到了64位。
所谓的ARMv8架构，就是在MIPS64架构上增加了ARMv7架构中已经拥有的的TrustZone技术、虚拟化技术及NEON advanced SIMD技术等特性，研发成的。
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位程序摆在你眼前，也无法安装。
Android L开始才真正支持32位和64位的ART虚拟机，配合上64位处理器，名正言顺的运行64位软件。但是问题又来了，没有软件商愿意开发64位程序。我有几个搞安卓开发的朋友，都明确表示永远不涉足64位安卓程序开发，这又是为什么呢？
ARMv8是一套不错的指令集，它既支持未来的64位程序，也向下兼容现有32位程序。有了ARMv8的支撑，以后的64位手机操作系统，如Android L 64bit都可以简单、高效地支持现有的32位App，你不用担心兼容性问题。
在明白了这些区别之后，剩下的就很好做了，下载高德官方最新的SDK，解压发现里面，有两个文件
- arm64-v8a
- armeabi
这就是官方为我们提供的，其实足够了。可为什么还会崩溃呢，那是因为我们的项目中或不仅仅只有高德地图，或许还有极光推送，有盟平台等SDK，每个里面都有自己的平台库，在某些机型上直接去它自己的文件夹中搜寻库，结果发现没有，就出错了。 -
解决方案：
我们在项目的libs下在创建x86文件夹，以及arm64-v7a文件夹，然后把高德地图中armeabi中的库文件，拷贝到新创建的目录中即可。
下面还有一篇文章介绍的不错，也一起分享一下：
-
Android项目针对libs(armeabi,armeabi-v7a,x86)进行平台兼容
1.Android设备如何加载.so文件？
不同CPU架构的Android手机加载时会在libs下找自己对应的目录，从对应的目录下寻找需要的.so文件；如果没有对应的目录，就会去armeabi下去寻找，如果已经有对应的目录，但是如果没有找到对应的.so文件，也不会去armeabi下去寻找了。
以x86设备为例，x86设备会在项目中的 libs文件夹寻找是否含有x86文件夹，如果含有x86文件夹，则默认为该项目有x86对应的so可运行文件，只有x86文件夹而文件夹下没有so，程序运行也是会出现find library returned null的错误的；如果工程本身不含有x86文件夹，则会寻找armeabi或者armeabi-v7a文件夹，兼容运行。以armeabi-v7a设备为例，该Android设备当然优先寻找libs目录下的armeabi-v7a文件夹，同样，如果只有armeabi-v7a文件夹而没有 so也是会报错的；如果找不到armeabi-v7a文件夹，则寻找armeabi文件夹，兼容运行该文件夹下的so，但是不能兼容运行x86的so。所以项目中如果只含有x86的so，在armeabi和armeabi-v7a也是无法运行的。以上就是不同CPU架构运行时加载so的策略。2.对于不同的平台，我们应该怎么去进行适配？
目前主流的Android设备肯定是armeabi-v7a架构的，然后就是x86和armeabi了。如果同时包含了 armeabi， armeabi-v7a和x86，所有设备都可以运行，程序在运行的时候去加载不同平台对应的so，这是较为完美的一种解决方案，但是同时也会导致包变大。
armeabi-v7a是可以兼容armeabi的，而v7a的CPU支持硬件浮点运算，目前绝大对数设备已经是armeabi-v7a了，所以为了性能上的更优，就不要为了兼容放到armeabi下了。x86也是可以兼容armeabi平台运行的，另外需要指出的是，打出包的x86的so，总会比armeabi平台的体积更小，对于性能有洁癖的童鞋们，还是建议在打包so的时候支持x86。
3.如果第三方没有提供对应平台的.so文件怎么办？
有一些第三方的类库只提供了armeabi下的.so文件，如果我们项目里适配了armeabi-v7a和x86，如果不在对应的文件下放对应的.so文件，就可能导致某些Android设备会出一些问题，我们可以复制armeabi下得.so文件到不同的文件夹下。如果第三方提供了不同平台的.so文件，则复制不同平台的.so文件到项目中对应的文件夹下即可。
