Android 概念区分
Android编译相关
1. sourceCompatibility 与 targetCompatibility
- sourceCompatibility，是“编译Java源代码时使用的Java版本兼容性”。
- targetCompatibility，是“用于生成类的Java版本”。生成针对指定版本的VM的类文件。类文件将运行在指定的目标和更高版本上，但不在VM的早期版本上运行。
2.minSdkVersion与 targetsdkversion
- android:minSdkVersion，应用程序可以运行的最早版本的Android SDK。通常这是因为早期的API存在问题，缺少功能或其他行为问题。
- android:targetsdkversion，应用程序的目标运行版本，主要是为了表明您的应用程序在市场上的使用情况等。
3.compileSdkVersion与 buildToolsVersion
- compileSdkVersion，是编译的Android的API版本。
- buildToolsVersion，是要使用的编译器（aapt，dx，renderscript编译器等）的版本。对于每个API级别（从18开始），都有一个匹配的.0.0版本。
Android support v4、v7、v13
1. support目的
- 如果在低版本Android平台上开发一个应用程序，而应用程序又想使用高版本才拥有的功能，就需要使用Support 。
2. v4、v7、v13区别
- Android Supportv4: 这个包是为了照顾1.6及更高版本而设计的。（例如：Fragment，NotificationCompat，LoadBroadcastManager，ViewPager，PageTabAtrip，Loader，FileProvider 等）
- AndroidSupport v7: 这个包是为了考虑照顾2.1及以上版本而设计的，v7是要依赖v4这个包的，即两个得同时被包含。
- AndroidSupport v13 :这个包的设计是为了android3.2及更高版本的，一般我们都不常用，平板开发中能用到。
Android中arm64-v8a、armeabi-v7a、armeabi、x86
1. so库介绍
- so库是NDK编译出来的动态链接库，一些重要的加密算法或者核心协议一般都用c写然后给java调用，这样可以避免反编译后查看到应用的源码。
- 为了减小 apk 体积，只保留 armeabi 和 armeabi-v7a 两个文件夹，并保证这两个文件夹中 .so 数量一致。对只提供 armeabi 版本的第三方 .so，原样复制一份到 armeabi-v7a 文件夹。
- 存放法则：尽可能的为每个ABI提供优化过的.so文件，但要么全部支持，要么都不支持，不应该混合着使用。
2. Eclipse中lib目录与libs目录
- 放在lib中的是被reference的，放在libs中的是被include的。lib的内容是不会被打包到APK中，libs中的内容是会被打包进APK中。
3. 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 / mips64 | 极少用于手机可以忽略 |
| x86 / x86_64 | x86 架构的手机都会包含由 Intel 提供的称为 Houdini 的指令集动态转码工具，实现 对 arm .so 的兼容，再考虑 x86 1% 以下的市场占有率，x86 相关的两个 .so 也是可以忽略的 |
| mips / mips64 | 极少用于手机可以忽略 |
| armeabi | ARM v5 这是相当老旧的一个版本，缺少对浮点数计算的硬件支持，在需要大量计算时有性能瓶颈 |
| armeabi-v7a | ARM v7 目前主流版本 |
| arm64-v8a | 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位了，这话不假，从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位程序。
提高内存带宽
内存带宽的计算方法并不复杂，大家可以遵循如下的计算公式：带宽=总线宽度×总线频率×一个时钟周期内交换的数据包个数。很明显，在这些乘数因子中，每个都会对最终的内存带宽产生极大的影响。然而，如今在频率上已经没有太大文章可作，毕竟这受到制作工艺的限制，不可能在短时间内成倍提高。而总线宽度和数据包个数就大不相同了，简单的改变会令内存带宽突飞猛进。DDR技术就使感受到提高数据包个数的好处，它令内存带宽疯狂地提升一倍。 当然，提高数据包个数的方法不仅仅局限于在内存上做文章，通过多个内存控制器并行工作同样可以起到效果，这也就是如今热门的双通道DDR芯片组
（如nForce2、I875/865等）。事实上，双通道DDR内存控制器并不能算是新发明，因为早在RAMBUS时代，RDRAM就已经使用了类似技术，只不过当时RDRAM的总线宽度只有16Bit，无法与DDR的64Bit相提并论。内存技术发展到如今这一阶段，四通道内存控制器的出现也只是时间问题，VIA的QBM技术以及SiS支持四通道RDRAM的芯片组
，这些都是未来的发展方向。至于显卡方面，对其显存带宽更加敏感，这甚至也是很多厂商用来区分高低端产品的重要方面。同样是使用DDR显存的产品，128Bit宽度的产品会表现出远远胜过64Bit宽度的产品。当然提高显存频率也是一种解决方案，不过其效果并不明显，而且会大幅度提高成本。值得注意的是，部分高端显卡甚至动用了DDRII技术，这项技术还为时过早。
