设计与app技术框架学习（app开发的三大技术框架）

如何设计app的架构

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

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

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

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

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

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

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

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

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

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

UI发起请求 - 检查缓存 - 调用 *** 模块 - 解析返回 *** ON / 统一处理异常 - *** ON对象映射为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-ons *** 简单教程

握必要的App技术框架原理，能更有效地帮助我们预判哪些方案可行和实现效果较好，来让设计方案更接地气，让我们一起来了解一下App技术框架都有哪些。

一、App技术框架的类型

图1 三种App技术框架之间的关系

目前App的技术框架基本分为三种(图1)：

1）Native App：

一种基于智能移动设备本地操作系统(如iOS、Android、WP操作系统)，并使用对应系统所适用的程序语言编写运行的第三方应用程序，由于它是直接与操作系统对接，代码和界面都是针对所运行的平台开发和设计的，能很好地发挥出设备的性能，所以交互体验会更流畅。

2）Web App：

一种采用Html语言编写的，存在于智能移动设备浏览器中的应用程序，不需要下载安装，可以说是触屏版的网页应用，由于它不依赖于操作系统，因此开发了一款Web App后，基本能应用于各种系统平台。

3）Hybrid App：

一种用Native技术来搭建App的外壳，壳里的内容由Web技术来提供的移动应用，兼具“Native App良好交互体验的优势”和“Web App跨平台开发的优势”。

二、App技术框架的选择

对于设计师而言，我们往往是被告知这个项目采用的是哪种技术框架，然后就开始设计了，其实，我们也可以根据产品特点、框架特点和项目时间(图2)来与产品和开发同学协商，合理地为App中不同的部分选择对应技术框架，然后才在对应的技术框架下思考设计方案。

图2 产品特点、框架特点和项目时间的考虑

三、Hybrid App技术框架的设计特点

由于Hybrid App是融合了Native App和Web App的技术特点，通过分析Hybrid App的技术框架成分，能让我们更好地掌握App框架的基本开发知识，有助于我们更好地去做设计。

Hybrid App的大部分内容都是在Native框架中加载Web网页内容，能在保证用户体验的前提下，让App的内容更具有扩展性，即使接入再多的内容和业务功能，也不会使得整个App的安装包过大，典型Hybrid App的代表就是我们的手机 *** 客户端。Hybrid App在设计时，要注意以下五个要点(图3)。

图3 Hybrid App的五个设计要点

1）图像渲染

Native技术部分由于能直接调用系统的渲染引擎，所以能实现流畅的复杂图像渲染，而不影响设备的性能。

Web内容部分由于是基于内置浏览器，在图像渲染的时候要通过浏览器访问系统的渲染引擎或调用基于浏览器的第三方渲染引擎，中间需要在多个层级进行渲染请求，所以渲染的时效性和性能会下降不少，导致较复杂的图像渲染或动态渲染时，会出现机器卡顿。

如图4所示，由于标题栏采用了Native技术框架，可采用复杂的毛玻璃效果，让标题栏更通透，而内容区采用了基于Html5的Web技术，因此不适合动态变换背景图的渲染方案(当图片轮播时，背景图会随着图片内容而动态变换出模糊的背景)。

图4 动态的图像渲染

2）动效体验

由于Hybrid App的内容区大部分采用基于Html5的Web技术，对动效的解释和操作需要消耗大量的CPU性能，在设计时，要注意以下三个方面：

a. 不同的动效类型对CPU性能的消耗不同(图5):对CPU性能要求低的动效类型能运行得更流畅，但如果当你的设计方案是非系统自带的动效类型时(图6)，就需要提前跟开发沟通可行性和对CPU性能的消耗问题。

b. 机型的性能差异：不同的手机机型的CPU性能相差较大，需要了解不同机型在你的App中的占比(图7)，因为即在iPhone6上能完美运行的动效或交互动作，在iPhone6以下的手机上可能就会卡住不动了，所以不太适合用于CPU性能消耗较大的频繁渲染。

c. *** 的影响：如果你的动效在运动时，还需要加载内容，就要考虑 *** 较慢时，内容加载对动效流畅度的影响，这时可考虑先加载完内容，再开始动效或简化、压缩加载的内容量。

app开发主要有什么课程？

一、编程语言，语言是APP开发 *** 的基础。

如果我们看计算机语言的类型，数量将非常复杂，因此我们通常将计算机语言分为机器语言、汇编语言和高级语言。其中，汇编语言和高级语言是两种最常用的语言。

无论是开发iOS还是Android应用程序，您都需要学习编程语言。当然，这是一个大范围的普遍情况。毕竟，每个方向的主要语言是不同的。根据自己的情况选择更好的语言，但是语言是编程的基础。

二、绘图、设计,在APP开发之前，要明确APP的定位、APP最重要的功能、逻辑框架。

除了了解自己的方向之外，它还模拟打开APP后的用户体验。只有给用户一种良好的体验感，我们才能在APP的明确定位下，坚定地打开市场。

好的APP会有很好的用户体验，因为逻辑清晰，了解APP的核心功能和辅助功能，APP的风格和风格也清晰。因此，需要熟练的绘图和设计能力，这样无论是产品架构还是用户UI界面，都可以很容易地解决。