前提：App集成了Tencent的Bugly,一些错误很明显找到解决办法，一些没有明确思路的暂时搁置，忙完了主要工作开始做排查：
#1310 java.lang.UnsatisfiedLinkError
com.facebook.imagepipeline.memory.NativeMemoryChunk com.facebook.imagepipeline.memory.NativeMemoryChunkPool.alloc(NativeMemoryChunkPool.java:58)
显示的是这样的，以为是 fresco 出了问题，继续看，错误输出：
12-28 21:47:10.641 14558 15854 E art : dlopen("/data/data/com.app./lib-main/libimagepipeline.so", RTLD_LAZY) failed: dlopen failed: "/data/data/com.app./lib-main/libimagepipeline.so" is 64-bit instead of 32-bit
912-28 21:47:10.643 14558 15854 E SoLoader: Could not load: libimagepipeline.so
意思很明显，加载libimagepipeline.so 需要的64位的so文件给了一个32位的。
查看记录，全是arm64-v8a的架构
64位的android机上，会有32位的虚拟机和64位的虚拟机，在启动apk的时候，虚拟机会根据apk中的so的位数启动对应的虚拟机。先说解决方案：
1.全部使用32位的so.
2.把缺失的arm64-v8a的so文件补全。
64位也可以调用32位的so方法，app的build.gradle文件中修改：
defaultConfig {
ndk{
abiFilters("armeabi", "armeabi-v7a", "x86", "mips")
}
}
即只使用32位的，或者
defaultConfig {
ndk{
abiFilters "armeabi-v7a","x86"
}
packagingOptions {
exclude "lib/arm64-v8a/libimagepipeline.so"
}
}
exclude 即排除不引用。
同时可以使用 一条命令来查看 android 设备信息：
adb shell cat /system/build.prop
划线处：
ro.product.cpu.abi=arm64-v8a
ro.product.cpu.abilist=arm64-v8a,armeabi-v7a,armeabi
ro.product.cpu.abilist32=armeabi-v7a,armeabi
ro.product.cpu.abilist64=arm64-v8a
这个意思 用32位的时候 使用 armeabi-v7a,armeabi64位的时候 只能用 arm64-v8a
360 N6 的手机，在bugly上报是这样显示的：
Android不能同时加载32和64位本机库。 至少有一个依赖库使用ARM64支持编译的扩展，而另外一些依赖库仅支持ARM32，就会出现问题。参见此处https://blog.csdn.net/u013531824/article/details/53931307
该博主是ReactNative后遇到的问题，但是有一个完整的寻错 以及解决过程。
我的解决办法，这是fresco 引发的，果然在该项目github主页有人问过问题
详见：https://github.com/facebook/fresco/issues/1295 只是2016年的问题。
但是 需要注意的最常见解决问题就是升级版本，发现使用的fresco差了3个小版本，先升级之后，然后只使用32位的so 稳定性还是很重要的。
目前 2018.12 最新的为implementation 'com.facebook.fresco:fresco:1.11.0'
