app系统架构(app系统架构设计)

网友投稿 1968 2023-03-17

本篇文章给大家谈谈APP系统架构,以及app系统架构设计对应的知识点,希望对各位有所帮助,不要忘了收藏本站喔。 今天给各位分享app系统架构的知识,其中也会对app系统架构设计进行解释,如果能碰巧解决你现在面临的问题,别忘了关注本站,现在开始吧!

本文目录一览:

app架构思考

整个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 六个部分。

如何设计app的架构

想要设计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传递数据,绝不进行网络请求和缓存读写。

【产品】移动端APP常见架构与设计

通过点击底部Tab标签切换不同页面,可以说是如今众多APP的标配了。

典型的如:微信,微信底部4个Tab分别是微信、通讯录、发现、app系统架构我,更新迭代这么多年,一直很稳定,即使增加了很多功能,但微信的整体架构依然很简洁、稳定,佩服龙哥。

一般底部Tab标签为2-5个,超过5个通常会折叠。个人感觉过多的Tab标签会影响用户对APP主要功能模块的认知。

有些Tab标签对应的页面有不同类型的内容,此时可在页面上方同时设置顶部文字标签,使该Tab标签下的内容能够更清晰、有条理的分类。

如:抖音首页底部Tab标签上方有关注、推荐两个文字标签。

底部Tab的形式适用于APP有多个主要功能模块,每个模块可单独成页。

而有些APP核心功能很突出,且各个功能模块均依附于该核心功能app系统架构;或是核心功能非常重要,其他功能相对弱一些。这样可能不太适合以底部Tab形式设计APP。

对于核心功能很突出、且各个功能模块均依附于该核心功能的情况,可以考虑用卡片形式,如:faceU,它的核心功能是打开摄像头拍照,主要功能有贴纸、滤镜等,这些主要功能是依附于拍照这个核心功能的,因此比较适合卡片形式的架构。

对于核心功能非常重要、其他功能相对弱一些的情况,可以考虑打开APP后,开门见山直接显示核心功能,其他功能隐藏在次级页面,如:滴滴,打开APP后直接进入打车页面,凸显核心功能,其他功能如:订单、客服、消息等,均折叠隐藏在次级页面。

列表布局即通过一行行列表的形式展示每项内容。这种方式扩展性好,可上下滑动展示更多内容,适用于并列、平行内容的展示。

常见的如设置页面:以列表形式展现每项可设置功能,右侧显示“”,表示有更多操作;或者右侧直接显示开关按钮、默认选项等。常见的列表布局还有对话列表、歌曲播放列表等等。

同时如果展示内容有分类,则可以通过增加行间距的方式,将不同类别的内容聚合在一起。

宫格布局即以宫格平铺的方式呈现各个功能入口,这种方式使用户能够直观、清晰看到各个功能入口,比较适合提供服务/功能较多,且各服务/功能相对独立的APP。

每个宫格区域一般是以图标+标题的方式展示,标题不易过长。

如:支付宝以宫格展示各项应用入口,微信以宫格展示可提供的第三方服务入口。

以瀑布流方式展示图文内容,所展示内容错落有致,可通过滑动的方式查看更多内容,沉浸感、流畅感好。

常见的如:旅游类APP,图文信息比较多且更新频繁的APP。

抽屉式菜单,即点击导航按钮,将二级菜单像拉抽屉一样拉出来。

这种形式能极大程度保持页面简洁,节省空间,但由于功能隐藏在子菜单中,比较适合不太重要的功能。

常见的如:个人中心、设置等,会比较多的隐藏于抽屉式二级菜单中。

手风琴菜单表现形式为,通过点击一级菜单按钮,能够实现在子菜单展示与收回之间的来回切换。

常见的如:QQ好友分组列表,相信大家都不陌生了。

这种形式的菜单能够在保持界面简洁的情况下,实现信息扩展,比较适用于两级结构的分组信息展示。

iOS开发 如何介绍一个APP的技术架构?

app开发一般从技术架构上都会包括后台的管理端,在PC端操作,也就是管理我们整体系统后台。包括用户、权限、订单,还有一些管理的功能。另外就是APP的前端包括iOS和Android,这是一个APP的整体系统架构。那开发商的系统一般通用的技术方案,都是前后台分离的。前端用iOS开发语言和Android的开发语言来进行开发,那和后端应用层之间是通过接口的方式进行调用,后台负责后台管理端的开发。那技术架构上常用的技术方案无非现在比较流行的是PHP、JAVA,当然还有.NET技术。不过目前APP开发成本已经越来越高,可以选择小程序的定制开发是非常的不错的。第1种是卖模板为主的网络公司。优点是:价格低,几千块钱到万元之间就能搞定,方便,能够快速上线,微尘小程序就可以实现。缺点是:修改功能麻烦,这里需要避免低价陷阱,不要到最后才发现模板性的修改功能所花的钱比买模板还贵。而且不是独立的,一个模本卖给很多商家用,模板不是永久使用的,一般每年都要交年费。第2种是主流的方式,定制开发为主的网络公司。优点是:独一无二的,专为你的企业或者店面定制的,功能你来定,要求你来定,后期修改BUG方便,改东西也很方便,最重要的是永久使用权!!缺点是:相对价格比较高!!!
定制版的基本费用在上万元到十几万不等!不过贵也有贵的道理吧,毕竟功能做的更全面一点。最后总结,至于找什么样的小程序开发公司?花多少钱来开发?还是需要看贵公司准备的预算这块!希望对大家有用! 关于app系统架构和app系统架构设计的介绍到此就结束了,不知道你从中找到你需要的信息了吗 ?如果你还想了解更多这方面的信息,记得收藏关注本站。 app系统架构的介绍就聊到这里吧,感谢你花时间阅读本站内容,更多关于app系统架构设计、app系统架构的信息别忘了在本站进行查找喔。

版权声明:本文内容由网络用户投稿,版权归原作者所有,本站不拥有其著作权,亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容,请联系我们jiasou666@gmail.com 处理,核实后本网站将在24小时内删除侵权内容。

上一篇:小程序纸牌插件怎么用的(微信小程序纸牌游戏叫什么)
下一篇:钉钉电脑版打开小程序闪退(钉钉pc端闪退)
相关文章

 发表评论

暂时没有评论,来抢沙发吧~