两个项目同时集成拍摄短视频的RecordVideoDemo
- 在小米4上都能正常运行
- 在小米Note Pro上一个能正常用，一个用起来崩溃。报如下日志：
W/art: Failed to open zip archive '/system/framework/extendedmediaextractor.jar': I/O Error
[ 07-28 16:20:20.965 8980: 8980 W/ ]
Unable to open '/system/framework/extendedmediaextractor.jar': No such file or directory
W/art: Failed to open zip archive '/system/framework/extendedmediaextractor.jar': I/O Error
I/art: Rejecting re-init on previously-failed class java.lang.Class<org.bytedeco.javacpp.avutil>
E/AndroidRuntime: FATAL EXCEPTION: main
Process: com.hbbohan.growmemory.teacher, PID: 8980
java.lang.UnsatisfiedLinkError: org.bytedeco.javacpp.avutil
at java.lang.Class.classForName(Native Method)
at java.lang.Class.forName(Class.java:309)
at org.bytedeco.javacpp.Loader.load(Loader.java:390)
at org.bytedeco.javacpp.Loader.load(Loader.java:358)
at org.bytedeco.javacpp.avcodec$AVPacket.<clinit>(avcodec.java:1407)
at org.bytedeco.javacv.FFmpegFrameRecorder.<init>(FFmpegFrameRecorder.java:251)
at sz.itguy.wxlikevideo.recorder.WXLikeVideoRecorder.initRecorder(WXLikeVideoRecorder.java:166)
at sz.itguy.wxlikevideo.recorder.WXLikeVideoRecorder.startRecording(WXLikeVideoRecorder.java:255)
at com.hbbohan.growmemory.teacher.album.control.RecordFragmentHolder.startRecord(RecordFragmentHolder.java:156)
at com.hbbohan.growmemory.teacher.album.control.RecordFragmentHolder$1.onLongListener(RecordFragmentHolder.java:79)
at sz.itguy.wxlikevideo.views.CircleBackgroundTextView$1.run(CircleBackgroundTextView.java:90)
at android.os.Handler.handleCallback(Handler.java:739)
at android.os.Handler.dispatchMessage(Handler.java:95)
at android.os.Looper.loop(Looper.java:135)
at android.app.ActivityThread.main(ActivityThread.java:5298)
at java.lang.reflect.Method.invoke(Native Method)
at java.lang.reflect.Method.invoke(Method.java:372)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:910)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:705)
问题很明确，UnsatisfiedLinkError，因为着有一个库找不到，所以rg.bytedeco.javacpp.avutil这个类的实现代码无法链接成功。
同事排查了几天，跟我说搞不定，我看了下他的思路，基本沿着怎么编译在这个平台上可用库的方式走，这个需要对javacv编译很熟悉才行，从网上找的各种方案都不怎么靠谱。
由于是不同手机上的表现不同，而这个bug又跟so有关，所以猜测和手机CPU架构有关，以前碰到过类似问题：只要集成好JPush，环信就崩溃（细节参考：《[32→100] 找不到集成进来的库文件，为什么？》），所以比较了一下项目的jnilib目录，果然没有问题的工程里面只有armeabi和x86两个目录，有问题的工程里面则一大推，包括arm64-v8a、armeabi-v7a、mips、mips64、x86_64，又是集成JPush带来的，把它们全部删除了，问题就好了。
解决方式简单粗暴。里面的原理也很简单，
- 集成JPush之前，系统发现armeabi是最匹配的，所以在这个里面发现了环信的库，正常使用。
- 集成JPush之后，系统发现armeabi-v7a是最匹配的，在这里找到JPush的库，但是没有RecordVideoDemo的库，所以产生异常，抛出崩溃。
但这里有两个问题：
- 为什么JPush要做这种吃力不讨好的事情呢？
- 以后遇到这种情况怎么处理？
一、首先要了解CPU有多少种型号？
早期的Android系统几乎只支持ARMv5的CPU架构，你知道现在它支持多少种吗？7种！
Android系统目前支持以下七种不同的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。
二、这么多型号价值何在？
更好的性能。归功于最近的架构更新， 例如硬件fpu，更多的寄存器，更好的向量化等。
三、当前手机怎么知道用apk中的那种ABI呢？
可以通过Build.SUPPORTED_ABIS得到根据偏好排序的设备支持的ABI列表。但你不应该从你的应用程序中读取它，因为 Android包管理器安装APK时，会自动选择APK包中为对应系统ABI预编译好的.so文件，如果在对应的lib／ABI目录中存在.so文件的话。
在实际项目中遇到的瓶颈是，你JPush全架构支持，别人不支持啊，你性能提上去了，别人直接就崩溃了。所以从项目全局的考虑，只能舍弃性能了。
因此在项目开发中，最好只保留armeabi下的so，其余全部删掉。考虑开发阶段会用到PC模拟器genymotion等，这些模拟器为了追求速度，大都基于x86的架构，可以多保留一个x86的目录
参考
Panda
2016-07-28
