移动App模块化设计

三层架构

1. 基础层：构建程序骨架，处理原始数据的IO
2. 业务层：控制数据流并进行加工
3. UI层

层次不等于文件组织，也不等于模块划分。一般按照界面划分模块后，同属该模块的业务层和UI层都放在同一目录下（还可以有子目录）。一个模块不会被层次限死，最多三层都可以跨越。

这层的目录命名有叫 base 或 foundation 的，如果设计得好，这部分东西是不关联具体业务的，多数可以跨项目使用，由业务层做定制化后为所属项目服务。

这层可以进一步细分成3种类型。

• 设置：持久化存储，key，升级时持久化数据迁移，变化通知
• 颜色：换肤，渐变色
• 图片：换肤，编解码
• 文本：富文本处理，多语言
• 调试：Log、debug辅助、宏开关
• 加解密：AES、DES、RSA……
• 编解码：base64，URLEncode/Decode，zip
• 数据结构：JSON，XML
• 数据算法：MD5，SHA1
• 网络：网络类型判断，缓存，下载，后端api交互
• 线程/进程管理：worker线程，线程消息，锁
• 系统信息：版本判断、屏幕分辨率、内存容量、磁盘容量、修改系统设置
• 文件管理：路径、备份
• 字符串：格式化（日期、时间、钱币、小数），转码（unicode），正则表达式，特殊数字检测（电话号码）
• 常量值，一般是业务用的，例如url地址

程序骨架

• 消息框架
• 页面路由
• 组件化框架
• 插件化框架

功能逻辑

它们都可视为component:

• 初始化：被其他程序调用，（android）创建快捷方式
• 升级：首次安装与覆盖安装的判断
• 用户信息：第三方登录
• 广告
• 统计埋点
• 推送
• 崩溃：注册crash handler
• 二维码
• 分享
• 支付
• LBS

字符串常量

有3种放置方式：

Localizable.strings

没有哪种方式绝对地优越，在没必要的情况下，越方便的方式越好。

网络模块

网络模块可分4层：

1. 基础层：可以是4种东西
   • 系统网络框架
   • 封装了系统框架的第三方库
   • 在socket层重新实现的第三方库
   • 自己实现的网络框架
2. 通用层：简化接口，定义通用回调，统一加入必须的参数
3. API层：与后端接口对应的函数集，函数内再调用通用层的接口
4. 封装层：方便其它模块调用。例如需要同时调用3个API且全部返回数据后合并回调，可以把这个逻辑做成1个函数

设置模块

“设置”有几种含义：

• 准确的“设置”是指Setting，值在运行时初始化且是可改变的。
• 配置是Configuration，其值确定后是不变的。值来源于配置文件或服务器下发。
• profile和preference都有跟某个用户绑定的意思，是用户的偏好，每个用户可以不一样。

他们又可分成是否需要持久化保存，所以会有RuntimeSetting和ArchivedSetting两个类。RuntimeSetting一般是个单例，数据只保存在内存中，没必要用key-value来访问，直接由成员变量表示即可。

View层组件

组件化的最原始目的是可复用，现在也被视为解耦的手段之一了。这些组件是可跨项目使用的：

• Toast
• Alert、多选框等多种弹窗
• 通知栏
• WebView，做好了通用设置和样式，包括加载进度和出错展示等

不可重用的例子：

• 启动闪屏
• 新手教育、更新说明

其它思路

• iOS预编译头文件（.pch）尽量不用，有些模块不应该依赖那么多东西
• 来自第三方的代码都不要改，做成pod（iOS）或library（android），可以随时覆盖式升级。应在其基础上做扩展，不行就再封装一层
• 初始化流程可以有专门的controller来负责，简化app入口函数的内容
• 一个自定义view(例如弹窗)应该与业务无关，所有的展示内容和设置都应该由外部传入。
• 应该让设计师做好规范化，颜色定义是一套风格，所以颜色值不会很多
• 同一模块内的类，根据是否可跨项目重用，应区分文件保存。例如SettingModel是可重用的，但SettingKeys是具体到业务的，应分放到两个文件