合肥APP开发的小编从事APP开发行业也有五年之久了，对于APP开发架构，也总结了一些自己的心得体会。下面合肥APP开发的小编为大家分享下APP开发架构心得。
1．代码规范
一份代码如果没有遵循任何规范，那么我相信它的可维护性是很差的，就算是你一个人做出来的，估计过了几个月去修改的时候也会冒出一句“这是什么鬼”。
2．框架稳定性
本来想说AOP的，但是个人觉得很多专业性的名词也比不上一些通俗的形容，毕竟本文主要的目的是让人理解，不是提出理论。封装这个在Android中是经常使用的，简单来说就是把一些常用的、通用的东西进行一个封装，通过统一入口进行调用，这样出问题就只需要修改一个地方，就能全部修改过来。同时封装也要注意一些常见的坑，比如我曾经就踩过的context坑，当时封装了一个UIUtils（主要是针对UI相关的工具类），因为很多方法都要使用context,所以直接application传进去，保存了，所有方法都不用传context,但是这样却出了一个bug,那就是有些操作用application的context是有问题的。当然这种还比较好处理，但是如果因为封装导致内存泄露，这就难以查找了，比如你传入了一个activity的context,但是activity已经关闭了，但是因为你封装的方法里面还在继续使用这个context,所以activity的内存也是不会释放的，所以封装的时候也一定要注意，不要给自己挖坑
很多时候很多开源框架刚出来的时候，也许功能十分强大，但是毕竟刚出来，没有经过充分的测试，所以还是会或多或少存在一个不稳定因子，所以建议在选择框架时尽量选择成熟稳定的框架，哪怕功能和性能的确比不上刚出来的框架。当然这也不是说完全不用刚出来的框架，毕竟都不用，那么它也永远成熟不了，至于到底用不用和怎么用，本文的框架选择和使用篇也会详细分析说明
3．封装
本来想说AOP的，但是个人觉得很多专业性的名词也比不上一些通俗的形容，毕竟本文主要的目的是让人理解，不是提出理论。封装这个在Android中是经常使用的，简单来说就是把一些常用的、通用的东西进行一个封装，通过统一入口进行调用，这样出问题就只需要修改一个地方，就能全部修改过来。同时封装也要注意一些常见的坑，比如我曾经就踩过的context坑，当时封装了一个UIUtils（主要是针对UI相关的工具类），因为很多方法都要使用context,所以直接application传进去，保存了，所有方法都不用传context,但是这样却出了一个bug,那就是有些操作用application的context是有问题的。当然这种还比较好处理，但是如果因为封装导致内存泄露，这就难以查找了，比如你传入了一个activity的context,但是activity已经关闭了，但是因为你封装的方法里面还在继续使用这个context,所以activity的内存也是不会释放的，所以封装的时候也一定要注意，不要给自己挖坑
4．耦合
针对耦合这个东西相信很多文章都说过了，如何解耦合，不过个人感觉解耦合这个东西也要适度，不要因为解决一点耦合，花了大量的代码，浪费了大量的性能，所以解耦合这个东西就一定要把握这个度，过度设计是有问题的设计，这点我是赞同的。同时很多时候封装会导致一些耦合的问题，比如我曾经一个项目中就有个这个一个情况：
因为项目中使用了滑动选取身高的WheelView,因为当时是弹Dialog出来选择的，所以当时想也没想就直接封装了一个Dialog,后面又出来了一个选取年龄的，然后又封装了一个Dialog,以至于到后面封装的Dialog有7,8个了，但是有些界面因为选中后的处理有些不一样，导致Dialog里面的代码混乱，所以后面就直接简单的封装了一个Dialog,传入需要选中的数据集合和选中监听，这样就用了一个Dialog就能处理多种数据的选择，还能根据不同界面分别处理，当然这样也不是万金油，毕竟这样每个界面都需要自己实现监听，所以很多时候有利就有弊，至于具体怎么取舍，就看利是否大于弊
扩展性
扩展性简单来说就是当程序需要新的功能时，能否对其进行扩展以及扩展的难度来判断，如何提高扩展性，我觉得有以下几点
（1）抽象接口
这点相信大家都经常遇到，比如Android的点击事件，你想要实现什么样的点击效果，自己实现一个点击监听，然后设置给控件就可以了
（2）元素重用
很多时候，很多功能模块可能使用到相同或者类似的元素，如Android中的一些布局，这些如果抽取出公共部分在进行扩展的时候方便对其快速扩展，当然这个是项目一开始并不能预见的，所以需要在开发中不断的去重构
（3）单一职责
这个其实就是面向对象的单一职责，比如前面提到的Dialog,一开始只有选择身高的功能，看起来是单一职责，但是其实相关处理也包含在其中，所以那个Dialog类本身职责已经不单纯，当然如果一直只有这一个，这样做没有任何问题，也能看做单一职责，但是如果有多个选择和处理的时候，就必须对其重构了
（4）替换性
替换性包含里氏代换但是也不仅仅是里氏代换，比如常见的Android布局不同，但是其显示内容大致相同，这样写布局的时候就可以对相同内容的控件指定相同的id,这样就算替换布局，也不用重写ViewHolder,当然对于Adapter也仅仅只需要替换相应的布局就ok
（5）耦合
这个和维护的耦合相同，毕竟很多地方本来就存在交叉，所以就没有必要再说了。
以上就是合肥APP开发小编为大家带来的关于APP开发架构的信息，希望能为您带来帮助。更多资讯请访问：http:/
以上就是合肥网站建设的小编分享的内容，希望能为您带来帮助。更多详情请关注：
谈谈APP开发架构心得
发布时间：2016-11-25 15:00:43 | 发布者：海拔网络 | 浏览次数：4531 | 返回列表 | 返回首页合肥APP开发的小编从事APP开发行业也有五年之久了，对于APP开发架构，也总结了一些自己的心得体会。下面合肥APP开发的小编为大家分享下APP开发架构心得。
相关资讯
- 你知道app开发时有哪些常犯的错误需要避免吗[01-19]
- 微信平台搭建分析微店APP开发运营的设计...[07-29]
- 海拔网络说说餐饮app给我们生活带来的变化[07-28]
- 微信平台搭建带你了解母婴app应用的功能[07-27]
- 你知道如何制作一款用户体验佳的旅游APP...[07-26]
- 微信平台搭建给你分析app应用程序的发展趋势[07-25]
热门资讯
- 你知道app开发时有哪些常犯的错误需要避免吗[01-19]
- 微信平台搭建分析微店APP开发运营的设计...[07-29]
- 微信平台搭建带你了解母婴app应用的功能[07-27]
- 海拔网络说说餐饮app给我们生活带来的变化[07-28]
- 热烈祝贺海拔网络乔迁新址[10-24]
- 合肥网站建设的客户需要提供哪些资料？[10-24]
