用了ImageLoader这套框架非常久了,一直觉得熟悉方便好用,而且原本软件中使用也不存在什么问题.直到最近开发的一个项目中,我才发现为什么很多开发者都放弃ImageLoader这套用熟了的框架换用glide图片加载框架了。
1.ImageLoad特殊场景的内存泄漏;
普通activity的界面使用中,加载图片的页面销毁查看内存泄漏也没有什么问题。但是如果在fragment中replace等操作销毁的过程就出问题了。经本人实验测试，每次fragment销毁一次，就会出现0.01MB的内存泄漏，虽说这要实现软件内存泄漏奔溃就要不断的刷页面上百次以上才能把软件搞奔溃。对于普通工程师这个就跟没问题似得。毕竟谁会没事刷页面玩。
首次：
再开两次：
2.高度占用内存；
为什么说高度占用内存呢？因为也是经本人测试，当首次页面加载十张图片，在加载页面过程中就会出现卡顿，过程中内存扩充70MB左右。高度花费手机内存。但是使用glide时，测试了一下就多了几MB内存。
我当场石化。。。。。。。。
glide加载图片内存：
ImageLoad加载图片内存：
3.手机优化总结：
讲讲个人想法吧，我是不舍得ImageLoad这套框架，但是为了软件的体验性，我只能学新东西glide。毕竟页面加载动画直接因为首次加载软件而卡顿影响很大，而且由于项目都是fragment构建，导致有图片的页面都有内存泄漏，由于是平板定制化开发，还真有可能把泄漏奔溃实现，只好换了。。。。。。。。。。