智慧屏安装APP的最佳实践与跨平台小程序开发的结合
1984
2023-03-17
本文目录一览:
整个APP架构上从上到下分为三层app系统架构,独立于APPapp系统架构的 通用层,通用业务层,业务层 。业务层用来处理上层业务,业务层可以依赖通用业务层和独立于APP的通用层,而且这种依赖是单向的,由上到下的,不能下层依赖上层。
1.首先客户端整体架构的最底层有一个独立于APP的通用层,在这一层里有崩溃的统计,网络的第三方,分享的第三方库等。也就是说这一层的框架或者说架构放在任何一个APP当中,都可以起到一个底层的支撑作用,它是独立于APP之上的。
2.在独立于APP的通用层之上,有一个通用的业务层。比如说针对当下公司,他有一些通用的基础组件,比如说第三方库的二次封装,toast,刷新控件等,这些往往是和当下公司的业务相关的。但是对于APP来说,各个业务线,对于这些通用控件都有需求,那么app系统架构我们可以将这些内容沉降到通用的业务层。
3.最上层就是我们的业务模块了,业务层的模块应该按照模块化的设计思想,尽量做到高度的“高内聚,低耦合”。
这么做的好处是为以后可能的组件化做准备,目前APP业务规模较小,等以后APP业务规模增大,需要进行重构做组件化的时候,在业务层加入中间层,进行业务模块之间的解耦,将会方便很多。
目标:单独拎出一个业务,不用做过多修改,然后就能生成一个新的APP。这个就是我们做整体的一个客户端的架构的目的或者说它的意义。
所有模块的开发,包括独立于APP的通用层,通用业务层,业务层,都应该遵循模块化的思想,做到高度的“高内聚,低耦合”。
实现模块化需要注意的点:
关于设计模式的选择,借鉴MVVM设计模式,将业务模块划分为 Controller+View+Model+ViewModel+Service+Constant 六个部分。
想要设计Appapp系统架构的整体框架app系统架构,首先要清楚我们做的是什么
一般我们与网络交互数据的方式有两种:主动请求(http)app系统架构,长连接推送
结合网络交互数据的方式来说一下我们开发的App的类型和特点:
数据展示类型的App:特点是页面多app系统架构,需要频繁调用后端接口进行数据交互,以http请求为主;推送模块,IM类型App的IM核心功能以长连接为主,比较看重电量、流量消耗。
手机助手类App:主要着眼于系统API的调用,达到辅助管理系统的目的,网络调用的方式以http为主。
游戏:一般分为游戏引擎和业务逻辑,业务脚本化编写,网络以长连接为主,http为辅。
一般我们做的App都是类型1,简要来说这类app的主要工作就是
把服务端的数据拉下来给用户展示
把用户在客户端修改的数据上传给服务端处理
所以这类App的网络调用相当频繁,而且需要考虑到网络差,没网络等情况下,App的运行,成熟的商业应用的网络调用一般是如下流程:
UI发起请求 - 检查缓存 - 调用网络模块 - 解析返回JSON / 统一处理异常 - JSON对象映射为Java对象 - 缓存 - UI获取数据并展示
这之中可以看到很明显职责划分,即:数据获取;数据管理;数据展示
确定app系统架构了职责,就可以进入正题了
1. 传统的Android App架构
Android最原生也是最基础的架构,可以理解为MVC,Controller即是Activity和Fragment,但是这两者掌握了Android系统中绝大多数的资源,并且在内部直接控制View,因此传统的Android App一般是以Activity和Fragment为核心,将网络模块,数据库管理模块,文件管理模块,常用工具类等分离成若干工具类包,供Activity和Fragment使用。
这是比较基础的Android项目架构,市面上大部分App都是这种造型
优点:就是开发简单,以页面为导向;如果构建水平可以,项目就已经基本实现模块化,基于Activity,Fragment这这两个上帝般的存在,很多事情直接就妥了,不用绕。
缺点:维护难,因为是以页面为导向的,有些需要共用的业务逻辑就会很烦,don't repeat your self, 你要不要repeat ?不想repeat就要写模块,慢慢的项目就会多出一堆乱七八糟的小模块。另一方面,测试很困难,因为所有的数据处理都在Activity和Fragment,假如现在想先用假数据显示,就要直接改Activity和Fragment的数据控制逻辑。
还有个最恼火的问题,那就是业务复杂起来后Activity和Fragment的代码量激增,举一个例子,电商App的购物车,如果只是管理一下购物车中的商品,无非就是查、删、改调用,列表管理,300多行代码应该就搞定了,假如现在加了个优惠券提示呢?光优惠券不够,还有满减,还有凑单,要计算运费。还要能领取优惠券…… 噢,忘了一般来说还有一个商品推荐,好了现在有两个列表要管理了,你觉得CartActivity 2000行代码能止住么?
在上面这些缺点的描述中,可以看到一个很大的痛点在于:Activity和Fragment不应该管这么多数据处理逻辑
2. 分层架构
如果仔细看自己的项目,可以发现绝大多数数据处理的代码是不需要使用Activity和Fragment持有的资源的(比如Context),而很多时候我们需要多个页面共用一套数据和请求逻辑,很经典的例子是应用中的User对象,一般来说都是全局单例。
这些全局的数据源写多了,很容易就能想到将数据处理统一抽出来形成一层,向上层提供数据接口,而上层并不关心数据的来源(内存,缓存,网络),因为不用从Activity和Fragment拿资源而且主要工作是数据处理,所以这一层是UI无关的,大幅提升了复用性,我把这一层称为DataManager层。
这是我一个项目的包结构
Activity和Fragment剥离了数据处理的责任后,持有DataManager的引用,负责获取数据并展示,向DataManager传递数据,绝不进行网络请求和缓存读写。
版权声明:本文内容由网络用户投稿,版权归原作者所有,本站不拥有其著作权,亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容,请联系我们jiasou666@gmail.com 处理,核实后本网站将在24小时内删除侵权内容。
发表评论
暂时没有评论,来抢沙发吧~