我们都知道哈,如果一个界面的逻辑够复杂,那么你的Activity如果在不进行优化或者细分的情况下的代码量会异常的多,那么现在博客就和大家来讨论一下如何给activity减轻负担!
为什么我们的Activity中的代码会很多呢?这是因为在activity里面你既要写 显示View的逻辑、数据处理的逻辑、网络请求的逻辑、可能还有其他乱七八糟的逻辑, 那么我们知道问题的所在,为什么不主动去优化呢?
需求:假设现在我现在有一个界面,整个是一个列表,然后最上面有一个轮播图显示多张的图片 轮播图每一个图片点击会跳转到其他页面
那么我们现在就知道列表的每一个Item显示都是一样的,写一个适配器就够了 上面的轮播图,如果我们使用ListView的话,可以添加头部视图的方法可以加到列表的最上面 那么很多人就很自然的把显示轮播图的逻辑全写在Activity中,如果需求就如我所说的这么一点,那么这么写也是可以的,因为够简单就没必要优化 但是如果你的列表页面像淘宝一样复杂呢? 如果你负责实现列表的显示,另一个人负责实现轮播图的展示呢?
所以这时候你可以这样子做一个分解!添加到ListView头部的就是一个HeaderView,那么你完全可以把这部分的实现给分离出去,比如建立一个MyHeader的类,这个类可以根据显示的数据data创建出View并且返回,如下
public class MyHeader { PRivate Context mContext; public MyHeader(Context context) { mContext = context; } /** * 显示数据到View * * @param imagesPath * @return */ public View init(List<String> imagesPath) { View contentView = View.inflate(mContext, R.layout.header, null); //这里实现展示轮播图的逻辑 //比如先找到ViewPager,然后创建显示的适配器 //ViewPager vp = (ViewPager) contentView.findViewById(R.id.vp); //............... return contentView; }}真实的情况下肯定没有这么简单,比如这里面你需要对ViewPager的每一个View进行点击事件的监听,然后实现跳转的逻辑,你会发现,你的这写代码都没写在Activity中 在Activity中只要获取到轮播图的数据,调用init方法,拿到需要显示的View,添加到ListView的Header中就可以了,只要和轮播图有关的代码都被抽取到MyHeader中来实现,你的Activity中的代码能不减少么?
这种方式不仅仅用于举例的这种情况,你可以用于很多情况,只要你对你要展示的View进行一个划分就可以了 比如页面根据参数有两种展示的情况的,非常适合这么做 比如页面需要发送多个请求,每一个请求显示在一块区域中 等等。。。。。。。
上述的例子就是对列表的头部的轮播图进行了一个划分!
这个说法相信对所有的人都很熟悉,其实我们平常中可以封装的东西有很多很多,不仅可以让代码看上去更简洁,而且可以让代码量也有说减少 比如土司一个提示:封装过之后
T.show(mContext,"提示");这么做的好处还有一个就是可以统一管理,你想要关闭或者开启都会非常的方便
同样的,测试输出也是一样的
可以使用通用的一些适配器,避免每次写重复代码
然后再举例一个比较经典的例子:更换头像
相信这个功能很多人都做过,从本地选择一个图片,然后上传这个图片到服务器,图片可能是需要裁剪过的,也可能是拍照再裁剪 有很多人是这么做的: 拍照为一个入口去实现这个逻辑 选择本地图片为一个入口去实现这个逻辑
其实对于上述的需求,无非就是一句话:拿到一张图片裁剪过的路径
所以针对这句话,你可以想到的封装一个类库啊!这个类库集拍照、裁剪、预览、图片放大等等功能,这个库的输出就是多张图片的路径
这也就是为什么需要使用一些好用的第三方库来实现这样子的功能,你会发现你的代码会变的很简单简单,你根本不需要想任何事情,你只需要开启这个类库,拿到返回值(图片路径)就可以了
有些人又会想,我想要图片裁剪层指定大小还不是要我自己拿到图片再做操作,其实这都应该是图片选择框架(类库)的事情,你在开启图片选择框架(类库)的时候完全可以开启裁剪功能和指定裁剪的大小,那么这个就根本不是问题 还是回归到了最开始说的那句话:拿到一张图片裁剪过的路径
代码优化是需要你去思考的,以上都是我个人从编程以来自己一步一步总结过来的,所以如果你想写出高质量、高可读的代码,请你多思考.欢迎大家在评论去留言讨论哦
--小金子新闻热点
疑难解答