直接编译libjpeg-turbo库总是失败
直接下载个写好的吧
https://github.com/honjane/android-libjpeg
这个本身是可以直接运行的
参考文章：https://blog.csdn.net/qfanmingyiq/article/details/77587220#%E5%AE%9A%E9%95%BF%E7%BC%96%E7%A0%81
问题1：
用的三星手机
原图
压缩后
图片产生了旋转，旋转了90度，目前只发现三星手机有这个问题
我们看下原图与压缩后的图片的详细信息：
可以看到原图本身是90度的，压缩后生成的新图是0度。
这个本身也可以利用代码得到图片是否旋转，旋转了多少度
/**
* 读取图片属性：旋转的角度
*
* @param path 图片绝对路径
* @return degree旋转的角度
*/
public static int readPictureDegree(String path) {
int degree = 0;
try {
ExifInterface exifInterface = new ExifInterface(path);
int orientation = exifInterface.getAttributeInt(
ExifInterface.TAG_ORIENTATION,
ExifInterface.ORIENTATION_NORMAL);
switch (orientation) {
case ExifInterface.ORIENTATION_ROTATE_90:
degree = 90;
break;
case ExifInterface.ORIENTATION_ROTATE_180:
degree = 180;
break;
case ExifInterface.ORIENTATION_ROTATE_270:
degree = 270;
break;
}
} catch (IOException e) {
e.printStackTrace();
}
return degree;
}
现在要达到这种效果
只能在压缩图片完成后，判断一下，如果原图是有旋转角度的，那么就在显示的时候把压缩后的图片也旋转对应的角度
/**
* 图片旋转
*/
protected Bitmap bitmapRotate(float degrees) {
Bitmap bitmap = BitmapFactory.decodeFile(mFilePath);
// 创建一个和原图一样大小的图片
Matrix matrix = new Matrix();
// 根据原图的中心位置旋转
matrix.setRotate(degrees, bitmap.getWidth() / 2,
bitmap.getHeight() / 2);
Bitmap afterBitmap = Bitmap.createBitmap(bitmap,0,0,bitmap.getWidth(),
bitmap.getHeight(),matrix,true);
return afterBitmap;
}
问题2
在三星s6上可以正常运行，但是在华为meta8上运行错误，提示找不到so
转载：http://blog.csdn.net/u011688880/article/details/46984547
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文件到项目中对应的文件夹下即可。
虽然项目中只提供了armeabi-v7a
但是按理说在meta8（x86）上应该也是可以的，但实际上压缩失败了
解决办法：
在build.gradle中加入
sourceSets {
main {
jniLibs.srcDirs = ['libs']
}
}
externalNativeBuild {
cmake {
cppFlags "-frtti -fexceptions"
abiFilters 'armeabi-v7a'
}
}
