关于android framework相关的一些看法之--再封装
2013-02-13 10:23
288 查看
看到不少人在创建android工程之后,又在上面做了不少功夫,封装之后再封装。或许是为了实现他们永远无法抛弃的"MVC"模式,又或者是离不开所谓的“内裤(类库)”王子的梦想,抑或是抱着创新搏人眼球。总之,这伙兄弟无所不用奇迹。
回过头来,我们试想一下,framework的核心作用什么呢--避免重复制造轮子。假设当初这些套件不是用“JAVA+大量的设计模式”,而是采用C/C++,现在的android应该是另外一番风景了。既然,谷歌的兄弟们,已经给我们造好了轮子了,如果我们所做再封装仅仅是为了封装而封装,而不能去避免再造轮子或者是提高工作的效率,真的是有点画蛇添足了。
本来framework里面大量的类为了实现可扩展性和灵活性,已经进行了多层的封装,执行效率应该就会打折扣,如果我们还要在上面做封装,特别是在UI层的渲染,更是会受到影响。
我个人在开发中不会试图再去制造轮子,而是总结一些有用的Tools类或者方法,我其实很反对有些兄弟去为了个人的理想去开发一些类库来修改目前android的开发模式,因为他的初衷是为了满足自己的理想 。所谓的快速开发,只是他的心猿意马。可能很多人并不喜欢。而且没有经过专业的论证和测试的框架可靠性本身就值得怀疑 。谷歌给我们提供了太多的有用工具,在这些工具的帮助下我们的每一步的开发,都显得有根有据和理直气壮。
我是一个喜欢简洁和自由的人。我可以轻松在现在的开发模式中以更高和可靠的效率去实现我要实现的需求。
回过头来,我们试想一下,framework的核心作用什么呢--避免重复制造轮子。假设当初这些套件不是用“JAVA+大量的设计模式”,而是采用C/C++,现在的android应该是另外一番风景了。既然,谷歌的兄弟们,已经给我们造好了轮子了,如果我们所做再封装仅仅是为了封装而封装,而不能去避免再造轮子或者是提高工作的效率,真的是有点画蛇添足了。
本来framework里面大量的类为了实现可扩展性和灵活性,已经进行了多层的封装,执行效率应该就会打折扣,如果我们还要在上面做封装,特别是在UI层的渲染,更是会受到影响。
我个人在开发中不会试图再去制造轮子,而是总结一些有用的Tools类或者方法,我其实很反对有些兄弟去为了个人的理想去开发一些类库来修改目前android的开发模式,因为他的初衷是为了满足自己的理想 。所谓的快速开发,只是他的心猿意马。可能很多人并不喜欢。而且没有经过专业的论证和测试的框架可靠性本身就值得怀疑 。谷歌给我们提供了太多的有用工具,在这些工具的帮助下我们的每一步的开发,都显得有根有据和理直气壮。
我是一个喜欢简洁和自由的人。我可以轻松在现在的开发模式中以更高和可靠的效率去实现我要实现的需求。
相关文章推荐
- 关于将SDL及其扩展库移植到Android平台的一些看法
- android 中vector的用法 ,坑 ,怎么替代,关于这几方面的一些看法
- 关于在android中,如何一步到位,全局替换控件样式的一些看法
- 关于为android的ViewGroup加上适配器的一些看法..
- 关于选择移动开发平台(android,ios,wp7)的一些看法
- 关于android中矢量图如何用,有坑,爬坑,如何替代的另一些看法
- 关于android中位运算的一些看法
- 关于android中ListView的Adapter如何设计能通用的一些看法
- 关于选择移动开发平台(android,ios,wp7)的一些看法
- 关于Android23 及以上模拟器处理应用闪退的一些问题(权限相关)
- 关于android中listview的adapter如何通用的一些看法
- 关于Android x86的启动参数设置相关探讨
- 关于Android下的JNI编程、SO库以及NDK的一些问题
- 关于Android achartEngine TimeChartView 的一些设置
- 关于java、Android中Math的一些用法
- 【Android】关于Android控件架构的一些总结
- 关于css中的伪类first-child的一些相关知识点
- 【Android 网络】关于android 网络连接状态的一些代码
- android 关于ContentProvider的一些知识