轻松实现动态获取Android手机CPU架构类型

1、什么是动态库(.so文件)？
  .so文件是unix的动态连接库，是二进制文件，作用相当于windows下的.dll文件。
  他使用了C/C++代码编写的可以操作硬件比java更高级的
  底层代码，执行速度和效率比其他语言要高。
  在Android中调用动态库文件(*.so)都是通过jni的方式。

  Android中加载so文件的提供的API：
  void System.load(String pathName);

  说明：pathName：文件名+文件路径；
  void  System.loadLibrary("libraryName");

  说明：libraryName：动态库的名字，是原始动态库去掉前面的lib和.so后的名字，如：
  “libnative-lib.so”库，要加载是应写成“native-lib”，
  即System.loadLibrary("native-lib")，
  而不能是System.loadLibrary("libnative-lib.so")；

2、为什么需要动态库？
  有时候原生的Java代码编写的程序不能满足需求时，如计算量很大，性能要求高，
  常见于游戏开发，我们就需要考虑使用C/C++开发程序，然后通过JNI的方式
  来调用。

3、加载动态库能做什么？
    1）、能直接操作硬件，如摄像头，音视频编码和解码；
    2）、更安全，so库是二进制的文件，不容易破解，人无法看懂，代码安全度更高。
    3）、执行效率高，运算速度快，C/C++编写的程序可以直接操作内存。
    4）、Android中提供的好多java接口调用的API底层都是通过JNI的方式来调用，
    如bitmap的压缩。

 5、Android开发为什么需要NDK开发，什么是CPU架构类型？
  有时候我们需要动态获取Android手机的cpu型号，这种需求不常见；
  Android系统中做app开发很多时候我们会集成三方的sdk，少不了因为适配而提供给不
  同架构cpu的动态库(.so文件)，比方说分型类，即时通信类， Android系统在加载app
  中的动态库的时候，会检查对应的cpu架构的型号，然后在到对应的lib目录下加载对应
  的库，这是为什么，应为Android底层是用C/C++实现的，生成不同架构的cpu可以加载
  的库时使用的指令不一样（体现在ndk编译生成多个版本的.so文件），如：
-------------------------------------------------
  arm64-v8a
  armeabi-v7a
  armeabi
  mips
  mips64
  x86
  x86_64
-------------------------------------------------
  当某个手机加载的库不是当前手机cpu对应的指令编译出来的.so文件见时，程序就会异常
  ，所以为了保证程序的稳定性，必须保证动态库编译时使用的指令和当前手机cpu可支持的
  cpu执行对应，这样才不会造成程序异常的情况。

6、为甚需要动态获取CPU架构类型；
  当我们在集成三方sdk是，由于有多个版本的.so库，如果同时导入我们的工程，那么造成
  的后过就是我们生成的app的体积瞬间会暴涨，比如环信即时通信IM的动态库，我查看了一下
  ，每个架构的cpu对应的.so动态库总大小都是12M以上,那么可想而知，如果我们导入了3个
  不同架构的动态库，瞬间app就增加了30多M，还不算我们应用自己的大小，对有些用户来说
  在应用市场上下载app第一反应都会看app的大小，至少对我自己来说是这样，如果某些应用的
  app超过30M的样子我就不想下载了，所用app包的大小直接关系到用户的体验，除了支付宝，淘
  宝，京东必须的软件为，基本都会考虑是不是放弃下载。

  为了解决三方库对本应用包的大小营销，我已我们可以考虑把不懂版本的动态库压缩放到我们的服
  务器上，让后在用户运行我们app的时候动态的获取用户手机CPU的架构类型，然后从服务器下载对
  应的动态库到SDCar上，Android也提供了加载外部的动态库的API，这样的话我们app的大小就会减
  少二分之一以上，另一个好处就是当我们把对应的库压缩有，体积还会减少到原来库大小的1/3，这
  样的话我们单从加载三库增加的大小来讲，如果原来有3个架构库，库总大小为30M，单个大小为10M，
  使用压缩的方式就会减少的单个大小的1/3，即3M多不到4M的样子,姑且按4M来算吧，而如果全部打包
  进app，总大小会在30M，即使压缩过了还是比较大，如果采用压缩的话，就会是原来的30/4四舍五入
  与等于7,即大小减少到原来的1/7的大小，这样的话就大大减少了app的大小，同时也不影响程序的运
  行。

  一下我我分装的库，使用了ndk的方式，其他方式目前我还没发发现，检测cpu的代码是从Android底层
  源码中找出来的，然后经过自己封装，通过JNI的方式来完成调用：使用很方便，如下；

  1、导入不同架构的.so库：架构包括
-----------------------------------
    arm64-v8a
    armeabi-v7a
    armeabi
    mips
    mips64
    x86
    x86_64
-----------------------------------
  每个文件夹下都有一个libnative-lib.so文件。

2、导入调用so库的jar包，并添加到lib中：
    cpu.jar

  注意：需要在gradle中的Android标签下加入：

   // 设置Jni so文件路径
      sourceSets {
          main{
              jniLibs.srcDirs = ['libs']
          }
      }


3、调用：
    通过CPUFrameworkHelper类来完成调用，如：CPUFrameworkHelper.isArmCpu(),会返回一个
    boolean值


  注意：
  可以直接集成的库地址：
  项目下载地址在：https://github.com/pgyszhh/CPUTypeHelper/tree/master/mycpu
      里边有需要的各个版本的.so库和cpu.jar的包，直接导入就可以使用。


  库源码地址：
      编译动态库和JIN的源码地址为：https://github.com/pgyszhh/CPUTypeHelper下的app目录，该
      目录下是所有的源码，




  在CPUFrameworkHelper类中提供的方法有：

      public static native boolean isArmCpu();

      public static native boolean isArm7Compatible();

      public static native boolean isMipsCpu();

      public static native boolean isX86Cpu();

      public static native boolean isArm64Cpu();

      public static native boolean isMips64Cpu();
  
      public static native boolean isX86_64Cpu();

	效果图如下：