架构设计之APP研发录学习笔记

一、APP研发录总结
1、重构的忧伤
如果版本发行后很短的时间内，就需要对其进行重构，除了小部分其他原因外，最重要的只能说是代码写的烂，架构设计不够灵活，导致耦合度很高。
要是非得要做重构，必须充分考虑现有资源，在非极端情况下，可与产品经理商量减功能，来弥补。在开发过程中，要本着以需求为第一要务，然后考虑抽出人手进行重构。
那么既然做重构，计划必须事先给出，且不要超过两周的时间。重构时，在发布版的上，新建一个分支，避免不必要的麻烦。

2、开工
在软件开发过程中，主要包括市场调研、正式立项、需求分析、项目策划、概要设计、详细设计、编码、测试、试运行、产品发布、用户培训、产品复制、销售、实施、系统维护、版本升级。
在软件定义阶段就需要搭建一套简单实用的应用框架AndroidLib，它将封装业务无关的逻辑，实行模块化拆分和插件化编程。
AndroidLib包括哪些业务无关逻辑（结构划分）：
（1）activity 包中存放的是与业务无关的 Activity 基类，Activity 基类要分两层， AndroidLib 下的基类 BaseActivity 封装的是业务无关的公用逻辑，主项目中的AppBaseActivity 基类封装的是业务相关的公用逻辑；
（2）net 包里面存放的是网络底层封装；
（3）cache 包里面存放的是缓存数据和图片的相关处理；
（4）ui包中存放的是自定义控件；
（5）utils 包中存放的是各种与业务无关的公用方法。
主项目的结构划分：
（1）activity：我们按照模块继续拆分，将不同模块的 Activity 划分到不同的包下（尽量少使用内部类）；
（2）adapter：所有适配器都放在一起；
（3）entity：将所有的实体都放在一起；
（4）db：SQLLite 相关逻辑的封装；
（5）engine：将业务相关的类都放在一起；
（6）ui（widget）：将自定义控件都放在这个包中；
（7）utils：将所有的公用方法都放在这里；
（8）interfaces：真正意义上的接口，命名以 I 作为开头；
（9）listener：基于 Listener 的接口，命名以 On 作为开头。

  在AndroidLib的BaseActivity中，重写onCreate方法，并定义abstract方法（初始化变量，初始化控件，数据加载），然后主项目继承BaseActivity，实现abstract方法。

  在点击事件这件事情上，可以选择onClick方法，也可以直接在控件初始化下面使用setOnClick方法，但两者都应该将其事件抽出作为私有方法。

3、业务逻辑到底怎样理解
大家都清楚经典三层架构：表示层、业务逻辑层、数据访问层
而在软件产品中其实是这样的，界面与交互为表示层，业务逻辑包含业务逻辑层和数据访问层，在通常清楚下，我们将业务逻辑层与数据访问层看作是并列关系，其实数据访问层算是业务逻辑层的衍生物：（界面和交互–>表示层）（业务逻辑 –>业务逻辑层 –>数据访问层）

  业务逻辑的组成部分：

领域实体
业务规则（不同于需求，要求无二义性）
完整性约束
业务流程及工作流

  业务逻辑的职责（业务指功能？与需求紧密联系）：

数据格式化
数据合法性与完整性验证
CRUD
存储过程（在非必要情况下不建议使用）
参考网址：http://www.uml.org.cn/zjjs/201008021.asp

4、不要使用JSONObject或JSONArray来承载数据
因为它们不能被序列化，而序列化的好处就是方便存储与传输。我们使用fastJson或GSON这样的优秀库。要是使用了JSONObject，那么只能将对象封装到全局变量中，而在手机内存不够，很可能导致内存泄漏问题。在页面的跳转中，也需要使用实体。

5、adapter
在使用adapter时，可以写一个BaseAdapter，此外Adapter中使用ViewHolder效果更佳。

6、关于判空的问题必须严肃
可以使用TextUtils进行判断，关于数据的分级，对于普通数据，没有数据就不显示，但是涉及到金额这类的，就必须给用户一个友好的提示，并停止接下来的操作。

公众号：