关于在项目中使用三方框架见解（volley和fresco）

以前的工程里网络请求用android-async-http，图片加载用universal-image-loader，很成熟的框架，而且也一直在更新。在新产品里同事坚持用新的框架，也就是吹的比较火的volley和facebook的fresco图片加载库，现在说一下这段时间使用的体验或者说是牢骚。

先说一下fresco。刚开始用的eclipse开发，本地工程关联了五个它工程而且lib库还要放到它的工程里去，不知道别人关联这么多工程的时候有什么感受，反正我是不能忍。仅仅作为一个图片加载库来说这种对工程结构的影响不值得。但是同事一直坚持用，我也只能跟着来。

在使用的时候控件竟然也要使用它规定的图片控件！日了狗了！虽然能在它基础上做自定义开发，但是我特么仅仅只是想要它的图片加载功能！它的特色功能是3级缓存渐进式程序画面。多级缓存带来的是占用更多的存储空间和更复杂存储管理，在它的缓存目录下可以看到它会创建N多个文件，里面放着不同图片文件，具体的我也没深入研究。至于占位图更是图片开源框架的基础功能。这些使用时的问题都可以通过对框架的理解来解决，但是我觉得花这么多的时间在学习使用一个三方框架上不可取。

然后就是发包了，发包的时候我们已经转用android studio了。此时我已经不能容忍它了，彻底触及我的底限，但是时间又很紧，只能下个版本干掉它了。首先打完包后突然发现安装包大了将近5M！！！5m是什么概念，你到应用市场上看看应用类的app，除了那些特别出名的产品，多1M就是少一大批用户！让一个新产品多出来5M简直是个致命的问题！

然后还有更致命的问题，兼容性问题！！！偶尔发现在一台arm64-v8a机器上崩溃，错误原因是

"nativeLibraryDirectories=[/data/app/com.lukouapp-1/lib/arm64, /vendor/lib64, /system/lib64]]] couldn't find "libxxxx.so"

也就是找不到依赖的动态库。在安卓系统里系统找动态库都是在system/lib和自己app目录下的lib文件夹里找。app目录下lib文件里根据cpu类型不同有大约有7种动态库的文件夹，常用的就是'x86', 'x86_64', 'arm64-v8a', 'armeabi-v7a', 'armeabi'这五个文件夹，而在这里面x86_64cpu是可以使用x86的库，arm64-v8a和v7都可以使用比自己低级armeabi库。我平时工程只创建x86、armeabi、armeabi-v7a的文件夹，基本能兼容市面上99%的机型了。系统找库的机制是有和自己cpu匹配的高级lib文件夹就不找低级的，这样如果高级库文件夹里少某个库即使低级文件夹里有系统也不会去找，然后就是程序崩溃。每多一个文件夹安装包都要大不少！而且基本没什么意义！而freso的框架会直接创建上面提到的五个文件夹！这样也就是你必须在这五个文件把你要用到的其它库也添加一遍相同类型的库！而且不能自己控制freso创建文件夹，不说兼容性，光是大小就多将近5M,坑爹啊！有什么图片加载框架值得你多出来这5M？而且它的节省内存在瀑布流刷图也只节省不到十兆内存！十兆在现在的机器根本不算什么!但是这十兆付出的代价会让你损失很多下载量！我现在想到的办法有三个，一个是把fresco下载到本地，修改它的工程导入本地工程；二是干掉它；三是在打包apk后把apk的arm64-v8a和x86_64文件夹删掉(虽然这里现在没发现什么问题，但是不保证会不会出问题)。我现在时间紧使用第三种方法，下个版本我就会干掉它！

再说一下volley，适合频繁的网络请求。我不信有几个app的网络请求能频繁到android-async-http做不到的程度。功能上基本就是实现个网络请求，不支持文件上传，具体的成功失败进度都得自己实现，然后到这里就想说要你有毛用！对于大部分公司来说要的就是拿过来就能用的，快速开发实现功能的东西，没有那么多精力让你再去研究围绕一个三方开发完善功能！还有就是它不支持cookies，也需要自己实现。造成我们在调试手机验证码的时候怎么都调试不成功，因为后台的验证码需要从cookies里拿出来验证，如果不自己实现话拿不到。这也是个小坑，其它还有多少暂时还不清楚。

结尾提醒大家：开发的时候稳定和效率是第一位，不是秀代码，赶潮流！用开源框架的时候一定要了解透彻充分测试再考虑用到工程里！使用的三方一定要完全可控，出问题可以自己修改问题！