当项目功能实现了,我们就要开始考虑优化的问题了,这里主要讲性能优化和内存优化
性能优化(摘自http://www.jianshu.com/p/afc54b7e90cb)
可以去看这个人写的文章https://juejin.im/user/5852a52d8d6d81006593c533
界面优化太多重叠的背景(overdraw)这个问题其实最容易解决,建议就是检查你在布局和代码中设置的背景,有些背景是隐藏在底下的,它永远不可能显示出来,这种没必要的背景一定要移除,因为它很可能会严重影响到app的性能。如果采用的是selector的背景,将normal状态的color设置为”@android:color/transparent”,也同样可以解决问题。
太多重叠的View第一个建议是 :使用ViewStub来加载一些不常用的布局,它是一个轻量级且默认是不可见的视图,可以动态的加载一个布局,只要你用到这个重叠着的View的时候才加载,推迟加载的时间。
第二个建议是:如果使用了类似Viewpager+Fragment这样的组合或者有多个Fragment在一个界面上,需要控制Fragment的显示和隐藏,尽量使用动态的Inflation view,它的性能要比SetVisibility好。
复杂的Layout层级这里的建议比较多一些,首先推荐使用Android提供的布局工具Hierarchy Viewer来检查和优化布局。
第一个建议是:如果嵌套的线性布局加深了布局层次,可以使用相对布局来取代。
第二个建议是:用标签来合并布局。
第三个建议是:用标签来重用布局,抽取通用的布局可以让布局的逻辑更清晰明了。
记住,这些建议的最终目的都是使得你的Layout在Hierarchy Viewer里变得宽而浅,而不是窄而深。总结:
- 可以考虑多使用merge和include,ViewStub。
- 尽量使布局浅平,根布局尽量少使用RelactivityLayout,因为RelactivityLayout每次需要测量2次。
- 内存优化核心思想:减少内存使用,能不new的不new,能少分配的少分配。因为分配更多的内存就意味着发生更多的GC,每次触发GC都会占用CPU时间,影响性能。
- 集合优化:Android提供了一系列优化过后的数据集合工具类,如SparseArray、SparseBooleanArray、LongSparseArray,使用这些API可以让我们的程序更加高效。
- HashMap工具类会相对比较低效,因为它需要为每一个键值对都提供一个对象入口,而SparseArray就避免掉了基本数据类型转换成对象数据类型的时间。
- Bitmap优化:读取一个Bitmap图片的时候,千万不要去加载不需要的分辨率。可以压缩图片等操作。
- 尽量避免使用依赖注入框架。
- 避免创作不必要的对象:字符串拼接使用StringBuffer,StringBuilder。
- onDraw方法里面不要执行对象的创建.重写onTrimMemory,根据传入的参数,进行内存释放。
- 使用static final 优化成员变量。
- 移动端获取网络数据优化的几个点连接复用:
节省连接建立时间,如开启 keep-alive。对于Android来说默认情况下HttpURLConnection和HttpClient都开启了keep-alive。只是2.2之前HttpURLConnection存在影响连接池的Bug,具体可见:Android HttpURLConnection及HttpClient选择请求合并:即将多个请求合并为一个进行请求,比较常见的就是网页中的CSS Image Sprites。如果某个页面内请求过多,也可以考虑做一定的请求合并。- 减少请求数据的大小:对于post请求,body可以做gzip压缩的,header也可以做数据压缩(不过只支持http 2.0)。返回数据的body也可以做gzip压缩,body数据体积可以缩小到原来的30%左右。(也可以考虑压缩返回的json数据的key数据的体积,尤其是针对返回数据格式变化不大的情况,支付宝聊天返回的数据用到了)根据用户的当前的网络质量来判断下载什么质量的图片(电商用的比较多).
引起内存泄漏的情况
对于使用了BraodcastReceiver,ContentObserver,File,游标 Cursor,Stream,Bitmap等资源的使用,应该在Activity销毁时及时关闭或者注销。
静态内部类持有外部成员变量(或context):可以使用弱引用或使用ApplicationContext。
内部类持有外部类引用,异步任务中,持有外部成员变量。
集合中没用的对象没有及时remove。不用的对象及时释放,如使用完Bitmap后掉用recycle(),再赋null。
handler引起的内存泄漏,MessageQueue里的消息如果在activity销毁时没有处理完,就会引起内存的泄漏,可以使用弱引用解决。
设置过的监听不用时,及时移除。如在Destroy时及时remove。尤其以addListener开头的,在Destroy中都需要remove。
activity泄漏可以使用LeakCanary。
Android 内存溢出解决方案(OOM) 整理总结
在内存引用上做些处理,常用的有软引用、弱引用 在内存中加载图片时直接在内存中作处理,如:边界压缩 动态回收内存 优化Dalvik虚拟机的堆内存分配 自定义堆内存大小。
如果图片很大,比如他们的占用内存算下来就直接OOM了,那么我们肯定不能直接加载它。解决主法还是有很多的,系统也给我们提供了一个类BitmapRegionDecoder,可以用来分块加载图片。