·基础层
·业务层
·UI层
一般按照界面划分模块后，同属该模块的业务层和UI层都放在同一目录下（还可以有子目录）。层次不等于文件组织，也不等于模块划分。一个模块不会被层次限死，最多三层都可以跨越。
划分层次的意义是高于业务模块看待耦合问题。业务模块内部一般是MVC、MVP、MVVM式设计，可是这些设计模式没解答跨模块的可依赖性。大部分人会认可基础层可被所有代码依赖，但少有人明确UI层可依赖所有业务层代码（例如A页面可依赖B页面的model）。模块间完全解耦肯定是完美的，业界有不少消息框架、组件化框架来帮助解决。但请一定注意，这些东西会提高复杂度和开发维护成本，在代码量和团队人数还不多的时候不宜使用。
这层如果设计得好，这部分东西是不关联具体业务的，多数可以跨项目使用，由业务层做定制化后为所属项目服务。
这层可以进一步细分成3种类型。
·设置：持久化存储，key，升级时持久化数据迁移，变化通知
·颜色：换肤，渐变色
·图片：换肤，编解码
·文本：富文本处理，多语言
·调试：Log、debug辅助、宏开关
·加解密
·编解码
·数据结构
·数据算法
·网络：网络类型判断，缓存，下载，api交互
·线程/进程管理
·系统信息：版本判断、屏幕分辨率、内存、磁盘容量、修改系统设置
·文件管理：路径、备份
·字符串：格式化（日期、时间、钱币、小数），转码，正则，特殊数字检测（电话号码）
·常量值，一般是业务用的
·消息框架
·页面路由
·组件化框架
·插件化框架
它们都可视为component:
·初始化：被其他程序调用
·升级：首次安装与覆盖安装的判断
·用户信息：第三方登录
·广告
·统计埋点
·推送
·崩溃：注册crash handler
·二维码
·分享
·支付
·LBS
·相册
·相机
·指纹
·xml：需要通过系统API获取实际的值，原生支持多语言
·统一放在一个定义常量的目录中：可直接引用常量；多语言方案要自己再实现
·分散在使用的代码中：所见即所得，无法换语言
没有哪种方式绝对地优越。在无高级需求的情况下，越方便的方式越好。
网络模块可分4层：
·基础层：可以是4种东西
系统网络框架
封装了系统框架的第三方库
第三方库
自己实现的网络框架
·通用层：简化接口，定义通用回调，统一加入必须的参数
·API层：与接口对应的函数集，函数内再调用通用层的接口
·封装层：方便其它模块调用。例如需要同时调用3个API且全部返回数据后合并回调，可以把这个逻辑做成1个函数
（层次是功能意义逻辑的划分，不代表每层都有一个类来封装上一层，有时候同一个类内的函数集就是一层）
·准确的“设置”是指值在运行时初始化且是可改变的。
·其次是配置，其值确定后是不变的。值来源于配置文件或服务器下发。
·再有是个人资料和偏好，都有跟某个用户绑定的意思，是用户的偏好，每个用户可以不一样。
他们又可分成是否需要持久化保存，所以会有RuntimeSetting和ArchivedSetting两个类。RuntimeSetting一般是个单例，数据只保存在内存中，没必要用key-value来访问，直接由成员变量表示即可。
组件化最原始目的是跨模块复用，现在发展成解耦的手段之一了。
·有些模块不应该依赖那么多东西
·来自第三方的代码都不要改，做成pod或library，可以随时覆盖式升级。
·应在其基础上做扩展，不行就再封装一层。
·初始化流程可以有专门的东西来负责，简化app入口函数的内容。
·一个自定义view(例如弹窗)应该与业务无关，所有的展示内容和设置都应该由外部传入。
·应该让设计师做好规范化，颜色定义是一套风格，所以颜色值不会很多。
·同一模块内的类，根据是否可跨项目重用，应区分文件保存。