理解抽象,封装变化
目前Android平台上绝大部分开发都是用着Java,而跟Java这样一门面向对象的语言打交道,不免要触碰到抽象和封装的概念。我身边接触过的一些开发者,有一部分还对这些概念停留在写一个抽象类、接口、或者一个方法。至于为什么,我不大清楚是他们表达不出来,还是不理解。下面我也不高谈阔论,直接举例子来解释我所理解的抽象。
//Activity 间使用 Intent 传递数据的两种写法 下面均是伪代码形式,请忽略一些细节
//写法一
//SrcActivity 传递数据给 DestActivity
Intent intent = new Intent(this,DestActivity.class);
intent.putExtra("param", "clock");
SrcActivity.startActivity(intent);
//DestActivity 获取 SrcActivity 传递过来的数据
String param = getIntent.getStringExtra("param");
//写法二
//SrcActivity 传递数据给 DestActivity
Intent intent = new Intent(this,DestActivity.class);
intent.putExtra(DestActivity.EXTRA_PARAM, "clock");
SrcActivity.startActivity(intent);
//DestActivity 获取 SrcActivity 传递过来的数据
public final static String EXTRA_PARAM = "param";
String param = getIntent.getStringExtra(EXTRA_PARAM);
写法存在的问题是,如果SrcActivity和DestActivity哪个把“param”打错成“para”或者“paran”,传递的数据都无法成功接收到。而写法二则不会出现此类问题,因为两个Activity之间传递数据只需要知道EXTRA_PARAM变量即可,至于EXTRA_PARAM变量到底是“param”、“para”、“paran”这一点并不需要关心,这就是一种对可能发生变化的地方进行抽象封装的体现,它所带来的好处就是降低手抖出错的概率,同时方便我们进行修改。
基于抽象和封装,Java本身很多API在设计上就有这样的体现,如Collections中的很多排序方法:这些方法都是基于List这个抽象的列表接口进行排序,至于这是一个用什么样的数据结构实现List,排序方法本身并不关心。看,是不是体现了JDK的设计人员的一种抽象编程的思维,因为List的具体实现可能有千万种,如果每一类List都要写一套排序方法,估计要哭瞎了。
小结:把容易出现变化的部分进行抽象,就是对变化的一种封装。
选好"车轮"
一个项目的开发,我们不可能一切从0做起,如果真是这样,那同样要哭瞎。善于借用已经做好的“车轮”非常重要,如:
网络访问框架:okhttp、retrofit、android-async-http、volley片加载框架:Android-Universal-Image-Loader、Glide、Fresco、Picasso缓存框架:DiskLruCache、RobospiceJson解析框架:Gson、Fastjson、Jackson事件总线:EventBus、OttoORM框架:GreenDAO、Litepal
还有其他各种各样开源的自定义控件、动画等。除了以上提到的开源框架,也包括一些不开源的SDK
数据统计:友盟统计,百度统计…奔溃搜集:腾讯bugly、bugtags…云存储:七牛…即使通讯:环信、融云、阿里百川…推送:小米推送、腾讯推送、百度推送…安全加固:360加固宝、爱加密…
一般情况下,我在选择是否引入一些开源框架主要基于以下几个因素:
针对不开源SDK的选择,也主要基于以下几点去考虑:
小结:选好“车轮”,事半功倍
抽象依赖第三方框架
为什么要抽象依赖于第三方框架呢?这里和第1点是互相照应的,就是降低我们对具体某个框架的依赖性,从而方便我们快速切换到不同的框架去。说到这里,你可能觉得很抽象,那我直接举一个加载片的例子好了。
假设你当前为项目引入一个加载片的框架——Android-Universal-Image-Loader,最简单的做法就是加入相应的依赖包后,在任何需要加载片的地方写上下面这样的代码段。
ImageLoader imageLoader = ImageLoader.getInstance(); // Get singleton instance
// Load image, decode it to Bitmap and display Bitmap in ImageView (or any other view
// which implements ImageAware interface)
imageLoader.displayImage(imageUri, imageView);
// Load image, decode it to Bitmap and return Bitmap to callback
imageLoader.loadImage(imageUri, new SimpleImageLoadingListener() {
@Override
public void onLoadingComplete(String imageUri, View view, Bitmap loadedImage) {
// Do whatever you want with Bitmap
}
});
这种做法最简单粗暴,但是带来的问题也最严重的。如果我有几十上百个地方都这么写,而在某一天,我听说Facebook出了个神器Fresco,想要换掉Android-Universal-Image-Loader,你就会发现你需要丧心病狂的去改动几十上百个地方的代码,不仅工作量大,而且还容易出错。造成这样的原因,就在于项目和加载片的框架之间形成了强耦合,而实际上,项目本身不应该知道我具体用了哪个加载片的框架。
正确的方式,应该是对框架做一个抽象的封装,以应对未来发生的变化,我直接举自己的开源项目AndroidAlbum中的一种封装做法好了。大致代码如下:
这样一来,切换框架所带来的代价就会变得很小,这就是不直接依赖于框架所带来的好处。以上只是我比较简单的封装,你也可以进行更加细致的处理。
小结:预留变更,不强耦合于第三方框架
从MVC到MVP
说实话,在没接触MVP的架构之前,一直都是使用MVC的模式进行开发。而随着项目越来越大,Activity或者Fragment里面代码越来越臃肿,看的时候想吐,改的时候想屎…这里撇开其他各种各样的架构不谈,只对比MVC和MVP。
View:布局的xml文件Controller:Activity、Fragment、Dialog等Model:相关的业务操作处理数据
你会发现,如果View层只包含了xml文件,那我们Android项目中对View层可做操作的程度并不大,顶多就是用include复用一下布局。而Activity等简直就是一个奇葩,它虽然归属于Controller层,但实际上也干着View层的活。就是这种既是View又是Controller的结构,违背了单一责任原则,也使得Activity等出现了上述的臃肿问题。
View:Activity、Fragment、Dialog、Adapter等,该层不包含任何业务逻辑Presenter:中介,View与Model不发生联系,都通过Presenter传递Model:相关的业务操作处理数据
相比MVC,MVP在层次划分上更加清晰了,不会出现一人身兼二职的情况。在此处你可以看到View和Model之间是互不知道对方存在的,这样应对变更的好处更大,很多时候都是View层的变化,而Model层发生的变化会相对较少,遵循MVP的结构开发后,改起来代码来也没那么蛋疼。这里也有地方需要注意,因为大量的交互操作集中在Presenter层中,所以需要把握好Presenter的粒度,一个Activity可以持有多个View和Presenter,这样也就可以避开一个硕大的View和Presenter的问题了。
小结:去加以实践的理解MVP吧
归档代码
把一些常用的工具类或业务流程代码进行归类整理,加入自己的代码库。如加解密、拍照、裁剪片、获取系统所有片的路径、自定义的控件或动画以及其其他他一些常用的工具类等。归档有助于提高你的开发效率,在遇到新项目的时候随手即可引入使用。如果你想要更好的维护自己的代码库,不妨在不泄露公司机密的前提下,把这个私人代码库加上详细文档给开源出去。这样能够吸引更多开发者来使用这些代码,也可以获得相应的bug反馈,以便于着手定位修复问题,增强这个仓库代码的稳定性。
小结:合理归档代码,可以的话,加以开源维护
性能优化
不要过早的做性能优化,app先求能用再求好用。在需求都还没完成的时候把大量时间花在优化上是本末倒置的;优化要用实际数据说话,借助测试工具进行检测。毕竟老板问你比以前耗电降低多少,总不能回答降低了一些吧???任何不以减低性能损耗来做保活的手段,都是耍流氓。
小结:合理优化,数据量化
实践新技术
Rxjava、ReactNative、Kotlin…开始兴起后,身边有很多开发者会跟风直上。学习新技术的精神是非常值得鼓励的,但没有经过一段时间实践观察,就擅自把新技术引入到商业项目中,则有失妥当。对于大公司的团队来说,会有专门团队或项目去研究这些新兴技术,以确定是否在自己的产品线开发中引入。但作为小公司,是不是就意味着没有实践尝试新技术的机会呢?并不是!个人有以下几点建议:
借助搜索引擎。看此项技术坑多不多,口碑不错但是坑多的话,则说明当前技术不成熟,可以耐心等待更新;考虑学习成本。学习成本太大且不容易招到懂这方面的开发者的情况下,建议不要引入该技术;高仿一个项目并开源。如果你想引入ReactNative做商业开发,最好先高仿实现一个应用然后将其开源。这样一些对RN感兴趣的开发者会运行你的代码并反馈bug给你,有助于你知道一些新技术的坑,并寻找相应的解决方案,最终确定是否引入该技术;降低入门门槛。实践新技术的过程尽量加以详细的文档记录,这会有助于降低项目组其他同事对新技术的入门门槛,可以的话,也将学习文档开源,获得更多开发者对此份文档的反馈,也可纠正一些文档中的错误;结合实际业务。所有新技术的引入都要考虑是否符合当下的业务需求,我听过有些程序猿想引入新技术的原因是因为觉得这种技术很酷,网上说很好用,很啥啥啥…自己完全没弄过就人云亦云。有时候好无语,感觉在会用一些技术就像在炫技一样;
小结:空谈误国,实干兴邦
UML,驯服代码和了解项目结构的利器,本人也在学习和体验其好处的路途上。不管遇到大小项目,有了它,可以更好的理清一些脉络结构。对付旧的庞大项目代码,或者有志阅读某些开源项目代码的开发者,绝对是居家必备。
小结:工欲善其事,必先利其器
自造"车轮"
前面2提到,项目不可能从0开始,是需要引入很多第三方框架的。这里并不与2互相违背,而是建议有想提高技术逼格的开发者,可以在空暇时间去编码实现一个框架。如果你对网络访问、片加载方面很有研究见解,不妨把这些脑海里的思想落实成具体的代码。也许你会发现,你动手去实践的时候,考虑的东西会多得多,自己最终得到的也会更多。
小结:不要停留在api调用的层面
扩大技术圈
有空又经济能力承受得起的时候,不妨去参加一些自己感兴趣的技术交流会。很多都有大牛上台演讲,听听人家的解决方案,拓宽一下自己看问题的思路,也可以多参加一些含金量高的线上活动。我有挺多开发者朋友,就是参加活动的时候认识的,有时候遇到一些技术问题,还会互相探讨交换一下解决思路。挺赞的!
小结:拓宽技术视野
1写博客总结
这个可能没什么好说的,大家看了标题就懂了。它最大的好处在于:
系统化记录自己的解决方案;方便日后自己回顾;有问题也会有读者评论反馈,促进技术交流;增强自己书面表达能力;
小结:认真总结,不断完善
文章为作者独立观点,不代表 股票程序化软件自动交易接口观点