app系统架构图（app的架构设计）

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

本文目录一览：

• 1、安卓app的开发架构图该怎么画
• 2、如何设计app的架构
• 3、app架构思考
• 4、【产品】移动端APP常见架构与设计
• 5、iOS APP启动原理及视图~详解

安卓app的开发架构图该怎么画

android应用开发框架是ApplicationFramework.其系统架构由5部分组成，分别是：LinuxKernel、AndroidRuntime、Libraries、ApplicationFramework、Applications。第二部分将详细介绍这5个部分。下面自底向上分析各层。Android架构1、LinuxKernelAndroid基于Linux2.6提供核心系统服务，例如：安全、内存管理、进程管理、网络堆栈、驱动模型。LinuxKernel也作为硬件和软件之间的抽象层，它隐藏具体硬件细节而为上层提供统一的服务。如果你学过计算机网络知道OSI/RM，就会知道分层的好处就是使用下层提供的服务而为上层提供统一的服务，屏蔽本层及以下层的差异，当本层及以下层发生了变化不会影响到上层。也就是说各层各尽其职，各层提供固定的SAP（ServiceAccessPoint），专业点可以说是高内聚、低耦合。如果你只是做应用开发，就不需要深入了解LinuxKernel层。2、AndroidRuntimeAndroid包含一个核心库的集合，提供大部分在Java编程语言核心类库中可用的功能。每一个Android应用程序是Dalvik虚拟机中的实例，运行在他们自己的进程中。Dalvik虚拟机设计成，在一个设备可以高效地运行多个虚拟机。Dalvik虚拟机可执行文件格式是.dex，dex格式是专为Dalvik设计的一种压缩格式，适合内存和处理器速度有限的系统。大多数虚拟机包括JVM都是基于栈的，而Dalvik虚拟机则是基于寄存器的。两种架构各有优劣，一般而言，基于栈的机器需要指令，而基于寄存器的机器指令更大。dx是一套工具，可以将Java.class转换成.dex格式。一个dex文件通常会有多个.class。由于dex有时必须进行最佳化，会使文件大小增加1-4倍，以ODEX结尾。Dalvik虚拟机依赖于Linux内核提供基本功能，如线程和底层内存管理。3、LibrariesAndroid包含一个C/C++库的集合，供Android系统的各个组件使用。这些功能通过Android的应用程序框架（applicationframework）暴露给开发者。下面列出一些核心库：系统C库--标准C系统库（libc）的BSD衍生，调整为基于嵌入式Linux设备媒体库--基于PacketVideo的OpenCORE。这些库支持播放和录制许多流行的音频和视频格式，以及静态图像文件，包括MPEG4、H.264、MP3、AAC、AMR、JPG、PNG界面管理--管理访问显示子系统和无缝组合多个应用程序的二维和三维图形层LibWebCore--新式的Web浏览器引擎,驱动Android浏览器和内嵌的web视图SGL--基本的2D图形引擎3D库--基于OpenGLES1.0APIs的实现。库使用硬件3D加速或包含高度优化的3D软件光栅FreeType--位图和矢量字体渲染SQLite--所有应用程序都可以使用的强大而轻量级的关系数据库引擎4、ApplicationFramework通过提供开放的开发平台，Android使开发者能够编制极其丰富和新颖的应用程序。开发者可以自由地利用设备硬件优势、访问位置信息、运行后台服务、设置闹钟、向状态栏添加通知等等，很多很多。开发者可以完全使用核心应用程序所使用的框架APIs。应用程序的体系结构旨在简化组件的重用，任何应用程序都能发布他的功能且任何其他应用程序可以使用这些功能（需要服从框架执行的安全限制）。这一机制允许用户替换组件。所有的应用程序其实是一组服务和系统，包括：视图（View）--丰富的、可扩展的视图集合，可用于构建一个应用程序。包括包括列表、网格、文本框、按钮，甚至是内嵌的网页浏览器内容提供者（ContentProviders）--使应用程序能访问其他应用程序（如通讯录）的数据，或共享自己的数据资源管理器（ResourceManager）--提供访问非代码资源，如本地化字符串、图形和布局文件通知管理器（NotificationManager）--使所有的应用程序能够在状态栏显示自定义警告活动管理器（ActivityManager）--管理应用程序生命周期,提供通用的导航回退功能5、ApplicationsAndroid装配一个核心应用程序集合，包括电子邮件客户端、SMS程序、日历、地图、浏览器、联系人和其他设置。所有应用程序都是用Java编程语言写的。更加丰富的应用程序有待app系统架构图我们去开发app系统架构图！从上面我们知道Android的架构是分层的，非常清晰，分工很明确。Android本身是一套软件堆迭(SoftwareStack)，或称为「软件迭层架构」，迭层主要分成三层：操作系统、中间件、应用程序。从上面我们也看到了开源的力量，一个个熟悉的开源软件在这里贡献了自己的一份力量。

如何设计app的架构

想要设计App的整体框架，首先要清楚我们做的是什么

一般我们与网络交互数据的方式有两种：主动请求(http)，长连接推送

结合网络交互数据的方式来说一下我们开发的App的类型和特点：

数据展示类型的App：特点是页面多，需要频繁调用后端接口进行数据交互，以http请求为主；推送模块，IM类型App的IM核心功能以长连接为主，比较看重电量、流量消耗。

手机助手类App：主要着眼于系统API的调用，达到辅助管理系统的目的，网络调用的方式以http为主。

游戏：一般分为游戏引擎和业务逻辑，业务脚本化编写，网络以长连接为主，http为辅。

一般我们做的App都是类型1，简要来说这类app的主要工作就是

把服务端的数据拉下来给用户展示

把用户在客户端修改的数据上传给服务端处理

所以这类App的网络调用相当频繁，而且需要考虑到网络差，没网络等情况下，App的运行，成熟的商业应用的网络调用一般是如下流程：

UI发起请求 - 检查缓存 - 调用网络模块 - 解析返回JSON / 统一处理异常 - JSON对象映射为Java对象 - 缓存 - UI获取数据并展示

这之中可以看到很明显职责划分，即：数据获取；数据管理；数据展示

确定了职责，就可以进入正题了

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架构思考

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

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

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

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

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

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

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

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

【产品】移动端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好友分组列表，相信大家都不陌生了。

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

iOS APP启动原理及视图~详解

一 、IOS开发APP启动原理

二、iOS系统架构

三、静态链接库与动态链接库

-(IBAction)useBundleLoad:(id)sender

}

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

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