app架构app架构（app架构师是做什么的）

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

本文目录一览：

• 1、app架构思考
• 2、架构之路 （二） —— APP架构分析（一）
• 3、【产品】移动端APP常见架构与设计
• 4、移动APP开发框架盘点2：Web移动前端框架大全
• 5、手机APP软件，属于C/S架构么？

app架构思考

整个APP架构上从上到下分为三层app架构app架构，独立于APPapp架构app架构的 通用层，通用业务层，业务层 。业务层用来处理上层业务，业务层可以依赖通用业务层和独立于APP的通用层，而且这种依赖是单向的，由上到下的，不能下层依赖上层。

1.首先客户端整体架构的最底层有一个独立于APP的通用层，在这一层里有崩溃的统计，网络的第三方，分享的第三方库等。也就是说这一层的框架或者说架构放在任何一个APP当中，都可以起到一个底层的支撑作用，它是独立于APP之上的。

2.在独立于APP的通用层之上，有一个通用的业务层。比如说针对当下公司，他有一些通用的基础组件，比如说第三方库的二次封装，toast，刷新控件等，这些往往是和当下公司的业务相关的。但是对于APP来说，各个业务线，对于这些通用控件都有需求，那么我们可以将这些内容沉降到通用的业务层。

3.最上层就是我们的业务模块了，业务层的模块应该按照模块化的设计思想，尽量做到高度的“高内聚，低耦合”。
这么做的好处是为以后可能的组件化做准备，目前APP业务规模较小，等以后APP业务规模增大，需要进行重构做组件化的时候，在业务层加入中间层，进行业务模块之间的解耦，将会方便很多。

目标app架构app架构：单独拎出一个业务，不用做过多修改，然后就能生成一个新的APP。这个就是我们做整体的一个客户端的架构的目的或者说它的意义。

所有模块的开发，包括独立于APP的通用层，通用业务层，业务层，都应该遵循模块化的思想，做到高度的“高内聚，低耦合”。

实现模块化需要注意的点：

关于设计模式的选择，借鉴MVVM设计模式，将业务模块划分为 Controller+View+Model+ViewModel+Service+Constant 六个部分。

架构之路 （二） —— APP架构分析（一）

上一篇主要讲述了苹果原生iOS框架的架构，这一篇我们就说一下如果自己要完成一个APP，需要如何去设计架构。

我们说APP的架构设计，但是架构设计需要我们怎么在结构上进行划分呢？可以按照下面进行划分。

其实也可以有三层分层架构：展现层、业务层、数据层。

前面根据需求对框架的架构分类，可以分为三层结构甚至四层结构，这里就说一下架构模式，可以说架构模式是架构实现的方式。常见的有MVC、MVVM和VOPER等。好的架构模式可以让模块功能更清晰，维护起来也很方便。

下面就一起看一下这几种架构模式：

这里MVC就不多说了，相信大家对它是最先接触也是最熟悉的了。

1. iOS应用架构谈 开篇
2. 我们常见的分层架构，有三层架构的：展现层、业务层、数据层。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

移动APP开发框架盘点2：Web移动前端框架大全

开源项目其实有一个成熟周期，这个周期大概是三年左右，自React框架在2013年发布并引爆了前端框架的大潮，这个属于前端的周期就此开始了。

之后在2015年5月开源的React Native又开启了属于Web移动前端的周期，15-16年，18-19年，21-22年正好就是属于移动前端的三个爆发点。

三年前，在第一个成熟收获期，我盘点了移动开发框架。在这第二个成熟收获期，理所当然要来盘点一波。

不过，当我点开github项目的code-frequency时，还是被这个准到吓人的周期猜想惊呆了，先给你们看一波，剩下的自行验证。

1、https://github.com/youzan/vant/graphs/code-frequency

2、https://github.com/quasarframework/quasar/graphs/code-frequency

再来说第二个比较有意思的发现，停止维护的项目绝大多数是Vue框架项目。

盘点开始的时候我还觉得React框架处于绝对劣势，到完成时我发现React无论在选择面还是成熟度上都超过了Vue。

原因我这里就不分析了，反正大家都有自己的看法。

网页类框架就是前端组件框架，这一次虽然有大量项目停止维护，但是也有很多项目坚持了下来，而且还涌现出了一批新项目。

大厂占了主导，因为这些年大厂在移动开发上的需求，远高于其它方面。个人项目要坚持确实不易。

本来是想要做一个验证项目，把所有框架都试用一遍并给出推荐度的。由于进度太慢，还是下一次再发吧。

这次的重点是渐进类框架，就是所谓多端同构框架（小程序框架）。这几年国内的重点的各种小程序平台，所以多端框架的需求很是旺盛。

不过大多数先行者都没挺过来还是让我很意外，只有Taro成功了，想想还是有很多让人唏嘘的东西。

在这里还是先预测一波吧，因为这一类框架最变化最大，最终还是有很多框架要出局的。

渐进类框架是一个过渡性的产品，最终会变成桥接类框架的一部分，所以，与桥接类框架协同才是框架的出路。

这个赛道基本全是大厂了。

腾讯新一代跨端开发框架Hippy

Hippy一看就是淘宝Weex的对标项目，Kpi功能全面压制。所以官方支持 React 和 Vue 两种主流前端框架。在Weex2019年实质停更后发布，要不要这么卷？

Hippy 2.x 架构主要分成三层，UI(JS) 层 Hippy-React 和 Hippy-Vue 负责驱动 UI 指令生成；中间层 C++ HippyCore 负责抹平平台差异性和提供高性能模块；渲染层 Android 和 iOS 负责提供终端底层模块、组件，并与布局引擎通信。

对Weex惨遭遗弃，我上次就说过：「ReactNative提供工具，Weex提供框架，将平台差异化屏蔽（Write Once, Run Everywhere）。所以Weex则注定功能相对弱小，并且坑比较多。」Weex最终下马也是必然的，淘宝又发布升级版北海，为了实现（Write Once, Run Everywhere），它采用自绘，而且是基于Flutter自绘。

所以Hippy3.x就一如既往的Kpi功能层层加码，很有腾讯风格。在未来的 3.x 中业务与渲染层中的具体实现可根据用户实际场景进行切换：业务层上不再局限于 JS 驱动，还可选择（如：DSL/Dart/WASM 等）其它语言进行驱动；在渲染层中，渲染引擎除了支持现有原生（Native）渲染之外，还可以选择其他渲染 Renderer，如 Flutter(Voltron) 渲染。

「Kraken 北海」是一款高性能Web渲染引擎。底层基于 Flutter 进行渲染。

Kraken 不限制上层开发者使用的框架，无论你是使用 Vue 、Rax 还是 React 都可以开发 Kraken 应用。

Kraken 的 runtime 通过 JS Engine Binding 的方式提供了一系列 Web 标准的 API 接口，调用相应 API 会执行相关逻辑并创建一系列需要发送给 Dart 层处理的指令。

Kraken 其实就是一个小程序平台，而且追求全平台完全一致。我虽然认为各平台不一致是很自然的事情，但是也表示理解，毕竟别人吹牛有当真的传统（KFC表示认同）。

Kraken 现在也是一个小号浏览器，所以它的主要工作就是抠标准，毕竟它是一款基于 W3C 标准的高性能渲染引擎。

最后，我劝淘宝领导定Kpi要理智些，毕竟Hippy4我还蛮期待的。

滴滴出品的超轻量级动态化跨端开发框架，主打轻量和实用。

Hummer 以 JS 引擎为基石，目前已支持 JavaScriptCore、Hermers、QuickJS 等业内知名 JS 引擎（这里本来还有个V8的，我删除了，源码里面没有，Kpi需要）。再配合经过调优的 Yoga 布局引擎，抹平了两端视图布局差异（性能更佳的自研布局引擎开发中）。顺便提一下，Hippy采用V8（功能更强）自研布局引擎（性能更佳）。

Hummer 的特点是抛弃了业界其他动态化跨端框架普遍使用的DSL层和VDOM层，因此原生 Hummer 不具备前端开发常用的响应式编程的能力，但同时换来的是接近原生开发的体验和性能。再以原生 Hummer 为基础，在此之上开发了一套基于MVVM架构的开发框架 —— Tenon ，通过 Tenon，可以把使用 Vue/React 编写的代码，转换成原生 Hummer 的代码。

Hummer也是一个小程序平台，而且超轻量。如果想要无限提升自己APP的能力，可以考虑嵌入Hummer。

Web移动前端框架正在迎来第三个高速发展期，各类框架得到极大繁荣。

个人在具体项目的贡献已经微乎其微了，创新、架构创新是唯一制胜的手段，这也是我看好React的根本原因。

最后，还是想做点微不足道的 探索 ，现在前端组件库层出不穷，更换组件库带来的代价有点大。想创建一个框架，来实现上次说的组件公约数和公倍数，无缝切换组件库。理论上支持所有组件库 ，也能为后来者提供弯道超车的机会。我想大厂可能没有需求，也不会愿意发布这种框架，毕竟都是平台部门说了算。

这个库就是useMobile，当然分为useMobileReact和useMobileVue。下次先发布useMobileReact。等我发布后，再来填上面表中缺的推荐度。

原文地址： https://www.cnblogs.com/windfic/p/16019457.html

手机APP软件，属于C/S架构么？

不全属于C/S架构，手机APP软件除了C/S架构，还有单机版APP，B/S架构等类型的APP。

在C/S结构中，应用程序分为两部分:服务器部分和客户机部分。服务器部分是多个用户共享的信息与功能，执行后台服务。典型的如一些聊天APP，视频APP等就是作为本地客户机，与服务器端进行信息交流、请求等，属于典型的C/S结构。

B/S架构中，客户机上只要安装一个浏览器，如NetscapeNavigator或InternetExplorer，服务器安装SQLServer、Oracle、MYSQL等数据库。浏览器通过WebServer同数据库进行数据交互。手机中就有许多浏览器应用，是属于B/S架构的。当然手机中还有一些单机版游戏等应用。

扩展资料：

C/S和B/S的比较：

1、硬件环境的比较：

CS建立在局域网的基础上，局域网之间再通过专门服务器提供连接和数据交换服务。在CS结构中，客户机和服务器都需要处理数据任务，这就对客户机的硬件提出了较高的要求。BS结构建立在广域网之上，不必配备专门的网络硬件环境。

2、系统维护、升级的比较

CS结构中的每一个客户机都必须安装和配置相关软件，如操作系统、客户端软件等。BS结构中每一个客户端只需通过浏览器便可进行各种信息的处理，而不需要安装客户端软件，维护、升级等几乎所有的工作都在服务器端进行，如果系统需要升级，只需要将升级程序安装在服务器端即可。

参考资料来源：百度百科-B/S架构

参考资料来源：百度百科-C/S架构

关于app架构app架构和app架构师是做什么的的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。 app架构app架构的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于app架构师是做什么的、app架构app架构的信息别忘了在本站进行查找喔。

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