Android 优化总结( 八 ) _Android

9.6 去除重复依赖库优化
我相信你看到了这里会有疑问，网上有许多博客作了这方面说明。但是我在这里想说，如何查找自己项目的所有依赖关系树
gradlew app:dependencies注意要点：其中app就是项目mudule名字。正常情况下就是app！关于依赖关系树的结构图如下所示，此处省略很多代码
| | | | | | --- android.arch.core:common:1.1.1 (*)| | | | --- com.android.support:support-annotations:26.1.0 -> 28.0.0| +--- com.journeyapps:zxing-android-embedded:3.6.0| | +--- com.google.zxing:core:3.3.2| | --- com.android.support:support-v4:25.3.1| | +--- com.android.support:support-compat:25.3.1 -> 28.0.0 (*)| | +--- com.android.support:support-media-compat:25.3.1| | | +--- com.android.support:support-annotations:25.3.1 -> 28.0.0| | | --- com.android.support:support-compat:25.3.1 -> 28.0.0 (*)| | +--- com.android.support:support-core-utils:25.3.1 -> 28.0.0 (*)| | +--- com.android.support:support-core-ui:25.3.1 -> 28.0.0 (*)| | --- com.android.support:support-fragment:25.3.1 -> 28.0.0 (*)--- com.android.support:multidex:1.0.2 -> 1.0.3然后查看哪些重复jar[图片上传失败...(image-b9d450-1563928824510)]
<figcaption></figcaption>然后修改gradle配置代码
api (rootProject.ext.dependencies["zxing"]){ exclude module: 'support-v4' exclude module: 'appcompat-v7'}9.7 四种引用优化
软引用使用场景通过软引用的get()方法，取得bitmap对象实例的强引用，发现对象被未回收。在GC在内存充足的情况下，不会回收软引用对象。此时view的背景显示实际情况中,我们会获取很多图片.然后可能给很多个view展示, 这种情况下很容易内存吃紧导致oom,内存吃紧，系统开始会GC 。这次GC后， bitmapSoftReference.get()不再返回bitmap对象，而是返回null ，这时屏幕上背景图不显示，说明在系统内存紧张的情况下，软引用被回收。使用软引用以后，在OutOfMemory异常发生之前，这些缓存的图片资源的内存空间可以被释放掉的，从而避免内存达到上限，避免Crash发生。代码如下所示正常是用来处理大图片这种占用内存大的情况
Bitmap bitmap = bitmaps.get(position);//正常是用来处理图片这种占用内存大的情况bitmapSoftReference = new SoftReference<>(bitmap);if(bitmapSoftReference.get() != null) { viewHolder.imageView.setImageBitmap(bitmapSoftReference.get());}//其实看glide底层源码可知，也做了相关软引用的操作

这样使用软引用好处弱引用使用场景

private MyHandler handler = new MyHandler(this);private static class MyHandler extends Handler{ WeakReference<FirstActivity> weakReference; MyHandler(FirstActivity activity) { weakReference = new WeakReference<>(activity); } @Override public void handleMessage(Message msg) { super.handleMessage(msg); switch (msg.what){ } }}弱引用–>随时可能会被垃圾回收器回收，不一定要等到虚拟机内存不足时才强制回收。对于使用频次少的对象，希望尽快回收，使用弱引用可以保证内存被虚拟机回收。比如handler ，如果希望使用完后尽快回收，看下面代码到底什么时候使用软引用，什么时候使用弱引用呢？个人认为，如果只是想避免OutOfMemory异常的发生，则可以使用软引用。如果对于应用的性能更在意，想尽快回收一些占用内存比较大的对象，则可以使用弱引用。还有就是可以根据对象是否经常使用来判断。如果该对象可能会经常使用的，就尽量用软引用。如果该对象不被使用的可能性更大些，就可以用弱引用。
9.8 加载loading优化
一般实际开发中会至少有两种loading第一种是从A页面进入B页面时的加载loading ，这个时候特点是显示loading的时候，页面是纯白色的，加载完数据后才显示内容页面。第二种是在某个页面操作某种逻辑，比如某些耗时操作，这个时候是局部loading[一般用个帧动画或者补间动画] ，由于使用频繁，因为建议在销毁弹窗时，添加销毁动画的操作。
9.9 对象池Pools优化
对象池Pools优化频繁创建和销毁对象使用对象池，可以防止频繁创建和销毁对象而出现内存抖动在某些时候，我们需要频繁使用一些临时对象，如果每次使用的时候都申请新的资源，很有可能会引发频繁的 gc 而影响应用的流畅性。这个时候如果对象有明确的生命周期，那么就可以通过定义一个对象池来高效的完成复用对象。