当前位置:网站首页 > 开发资讯

十五年核心团队 · 值得信赖

APP定制开发咨询热线:15543288809 /

当前位置:网站首页 > APP开发常见问题

长春APP开发模块化设计

来源:长春网联科技有限公司 发布时间:2019-01-29浏览

三层架构

·基础层

·业务层

·UI层

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

划分层次的意义是高于业务模块看待耦合问题。业务模块内部一般是MVC、MVP、MVVM式设计,可是这些设计模式没解答跨模块的可依赖性。大部分人会认可基础层可被所有代码依赖,但少有人明确UI层可依赖所有业务层代码(例如A页面可依赖B页面的model)。模块间完全解耦肯定是完美的,业界有不少消息框架、组件化框架来帮助解决。但请一定注意,这些东西会提高复杂度和开发维护成本,在代码量和团队人数还不多的时候不宜使用。

基础层

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

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

数据IO

·设置:持久化存储,key,升级时持久化数据迁移,变化通知

·颜色:换肤,渐变色

·图片:换肤,编解码

·文本:富文本处理,多语言

·调试:Log、debug辅助、宏开关

·加解密

·编解码

·数据结构

·数据算法

·网络:网络类型判断,缓存,下载,api交互

·线程/进程管理

·系统信息:版本判断、屏幕分辨率、内存、磁盘容量、修改系统设置

·文件管理:路径、备份

·字符串:格式化(日期、时间、钱币、小数),转码,正则,特殊数字检测(电话号码)

·常量值,一般是业务用的

程序骨架

·消息框架

·页面路由
·组件化框架

·插件化框架

功能逻辑

它们都可视为component:

·初始化:被其他程序调用

·升级:首次安装与覆盖安装的判断

·用户信息:第三方登录

·广告

·统计埋点

·推送

·崩溃:注册crash handler

·二维码

·分享

·支付

·LBS

·相册

·相机

·指纹

字符串常量

·xml:需要通过系统API获取实际的值,原生支持多语言

·统一放在一个定义常量的目录中:可直接引用常量;多语言方案要自己再实现

·分散在使用的代码中:所见即所得,无法换语言

没有哪种方式绝对地优越。在无高级需求的情况下,越方便的方式越好。

网络模块

网络模块可分4层:

·基础层:可以是4种东西

系统网络框架

封装了系统框架的第三方库

第三方库
自己实现的网络框架

·通用层:简化接口,定义通用回调,统一加入必须的参数

·API层:与接口对应的函数集,函数内再调用通用层的接口

·封装层:方便其它模块调用。例如需要同时调用3个API且全部返回数据后合并回调,可以把这个逻辑做成1个函数

(层次是功能意义逻辑的划分,不代表每层都有一个类来封装上一层,有时候同一个类内的函数集就是一层)

设置模块

·准确的“设置”是指值在运行时初始化且是可改变的。

·其次是配置,其值确定后是不变的。值来源于配置文件或服务器下发。

·再有是个人资料和偏好,都有跟某个用户绑定的意思,是用户的偏好,每个用户可以不一样。

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

View层组件

组件化最原始目的是跨模块复用,现在发展成解耦的手段之一了。

其它

·有些模块不应该依赖那么多东西

·来自第三方的代码都不要改,做成pod或library,可以随时覆盖式升级。

·应在其基础上做扩展,不行就再封装一层。

·初始化流程可以有专门的东西来负责,简化app入口函数的内容。

·一个自定义view(例如弹窗)应该与业务无关,所有的展示内容和设置都应该由外部传入。

·应该让设计师做好规范化,颜色定义是一套风格,所以颜色值不会很多。

·同一模块内的类,根据是否可跨项目重用,应区分文件保存。