Quantcast
Channel: CodeSection,代码区,网络安全 - CodeSec
Viewing all articles
Browse latest Browse all 12749

移动App模块化设计

0
0
三层架构 基础层:构建程序骨架,处理原始数据的IO 业务层:控制数据流并进行加工 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层:

基础层:可以是4种东西 系统网络框架 封装了系统框架的第三方库 在socket层重新实现的第三方库 自己实现的网络框架 通用层:简化接口,定义通用回调,统一加入必须的参数 API层:与后端接口对应的函数集,函数内再调用通用层的接口 封装层:方便其它模块调用。例如需要同时调用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是具体到业务的,应分放到两个文件

Viewing all articles
Browse latest Browse all 12749