app架构设计从0到1_app框架设计

文章目录：

• 1、如何进行软件架构设计？
• 2、手机软件开发从0到1需要经过哪些步骤
• 3、如何从零开始设计一款漂亮的移动APP
• 4、创业公司设计师怎样从0到1设计一款APP（Low-fi输出）？
• 5、如何设计app的架构

如何进行软件架构设计？

软件架构设计的几个步骤 1、分析需求和理解业务模型（或领域建模），并选定关键Use case。 软件的需求，可以分为从用户视角和开发人员视角来看，从用户的角度看，又可以分为功能性和非功能性需求，我们必须从不同的视角和级别去全面的认识需求并分析需求，理解业务模型。实践表明，常常被我们忽视的非功能性需求常常会导致整个项目失败。 理解业务需求最好的方式莫过于进行领域建模，领域建模与需求分析往往是交替穿叉进行的，领域建模主要有以下三个方面的作用： ◆探索复杂问题，弄清领域知识。Martin Fowler曾经说过，他采用面向对象方法最大的好处就是它有助于解决更为复杂的问题。领域建模本身作为辅助思维的工具，帮助我们将注意力始终保持在最为重要的业务概念及其关系上，使我们能够不断深入地，系统的对需求进行分析和认识。领域建模往往是一个从模糊到清晰，从零散到系统的过程。 ◆决定功能范围，影响可扩展性。任何模型都是对现实世界某种程序的抽象，这种抽象就会忽略某一些东西，例如忽略对象的属性和对象间的关系，而这些忽略往往都是带有一定的目的性的，这种忽略就决定了功能的范围。模型揭示了各种功能背后的结构，如果说定义功能相当于“拍照片”的话，那么领域建模就相当于“做透视”，更加关注问题领域的内在结构，相当于对问题领域进行了一定的抽象，良好的领域模型不仅能很好的支持现有的功能，而且还可以在一定程度上支持未来可能出现的新需求，体现良好的可扩展性。 ◆提供交流基础，促进有效沟通。领域建模通常会使用UML图作为呈现的方式，这样为我们的沟通提供了方便。当然，有时候文字在描述某些特定领域的问题时可能更适合，可以灵活运用。 在我们公司的实际软件开发流程中，往往领域建模缺少这一环节，这可能是在以后的工作中需要进一步提高之处。 虽然我们总是期望架构设计师能全面掌握需求，但由于时间和精力的限制，摆在我们面前的现实就是架构设计师没有时间对所有需求进行深入分析，所以我们的策略就是“把好钢用在刀刃上”，即把大部分时间和精力花在对决定架构最重要的关键需求上。在选择关键需求时要注意：高优先级的需求往往是从用户的角度来看的，可能并不是真正的关键需求。在《RUP实践者指南》一书中向我们讲述了如何确定关键功能需求？A.作为应用程序的核心或实现了系统的主要接口的功能，B.必须被实现的功能，即如果这些功能不被实现，则开发出来的软件就失去了价值，C.覆盖了系统架构的一些方面，但没有被其他重要的Use case覆盖到的功能。 2、分别从各个视角来考虑软件架构的方方面面。 软件的架构设计必须考虑到各方面，根据前期工作确立的领域模型，关键需求，系统约束等进行设计，必须从系统用户，开发人员，系统管理员，部署管理员，数据管理员等人员的角度去分析并解决问题。比如说，如果我们的运行架构采用Cluster方式时，就必须小心Cache和Session等的使用；如果我们的业务逻辑要求我们要操作多个数据库时，就要考虑采用支持二阶段事务提交的方式。 只有将这些方方面面的问题都考虑到了，这样的架构设计才是完整的。至于每一个视图中，我们应该设计到什么细节这一问题，实际上与整个项目的过程定义有关。例如，如果我们有专门安排数据库概要设计的活动，那我们在架构设计的过程中就可以只需要关注更高层次的数据库特性及数据库之间的关系，而每一张表的数据字典可以在后续的相关活动中进行设计，但如果没有这样的活动，那我们就要细化到每一张表的每一个栏位，以及表之间的关系。 3、解决技术面的重点问题和难题 在软件架构设计的过程中，我们往往会需要攻克一些技术面的重点问题和难题，这完全是一项极其需要扎实的理论知识和丰富的实践经验支撑的工作。例如，我们如何提高整个系统的性能？如何能很好的导出极其复杂的“中国式报表”（一般比西方国家产出的报表要复杂很多，而且很多开源的BI类的框架并不能完全解决问题）？ 当遇到确实是很困难的问题，可以去百度一下或Google一下，也可以去请教公司的资深技术人员或专家，或者召开小范围的技术专题讨论会议，采用脑力激荡的方法试着找找答案，这样才能提高工作的效率。 4、召开架构设计评审会议进行同行评审。 架构设计评审是极其重要的一环，我曾将其形容为“七种武器”中的离别钩，就是因为在会议上，同行们可能会提很多问题或意见，而且很多意见很尖锐，所以一定要虚心接受，并做好记录，正所谓“良药苦口利于病，忠言逆耳利于行”。 在评审会议之前，我们要完成很多准备工作，最好是能准备一份简明扼要的电子简报，把最重要的问题列出来，这样在进行评审会议时，就不会漫无目的，在会议前就将这些资料发给与会人员，请他们抽空先了解一下，在会议进行时，要学会控制会议的进度，提高会议的效率。 5、针对关键Use case在设计的架构上实现功能来验证架构。 对于架构设计的验证也是一项十分重要的工作，其验证技术有很多种，在我们公司通常会采用Sample的形式，即XP中所说的迭代0，RUP中所说的切片。这样做的好处是既可以从实际的产品角度出发来有效的验证架构是否满足要求，又可以比抛弃型原型验证技术节省成本。 这个Sample绝不是我们在解决架构设计中的问题时拿来做实验的一些代码的拼凑，而是完整的实现某一关键Use case的符合架构设计和一系列规范的可交付的代码及相关文档。同时，这个Sample可以作为你在给大家讲解或培训架构时的教材，也可以作为开发人员使用此架构进行开发的蓝本，甚至是只需要复制粘贴，加上简单的修改即可。 6、交付给客户Review。 这一环节，在很多公司可能并不存在，因为他们的软件架构并不一定需要客户Review，但像我们这种做服务的公司，最重要的就是客尊，落实到软件架构设计这一活动，就是让客户理解并接受你的架构设计方案，同时，客户也会起到帮你验证架构的作用。通常，我们的架构得到客户的认可后，便可进入大规模的开发。 在交付给客户Review时，通常

手机软件开发从0到1需要经过哪些步骤

手机软件开发需要的人员：app开发人员、UI设计师、产品策划团队

开发过程：

前期：

确定软件的开发目标及其可行性，具体的规划，包括需求、市场、后期的推广等整体策划。

中期：

根据需求分析的结果，对整个软件系统进行设计，如系统框架设计、数据库设计等。软件设计一般分为总体设计和详细设计。

后期：

程序开发，安卓、ios、后台同步开发，相互配合，整理测试，在项目开发过程中进行单元测试、发现问题及早解决，开发完成后，编写测试用例进行全面的功能测试和性能测试，确保项目上线没有问题。

完成之后要进行严密的测试，一发现软件在整个软件设计过程中存在的问题并加以纠正，需要服务人员及时完善的引导和问题反馈。

如何从零开始设计一款漂亮的移动APP

我13岁时开始学习平面设计。我从网上课程学会了设计网站，并习惯于全天使用Photoshop和Affinity Designer进行设计。那些经历教会了我如何像设计师那样思考。

我设计和开发应用程序将近有一年时间了。我参加了麻省理工学院的一个项目，与一个团队合作开发Universeaty。 两个月前，我开始研究一个新的应用程序-Crypto Price Tracker，这款APP我会在1月28日发布。

在这篇文章中，我将配合实例说明我在从事应用程序设计时的一步一步的过程。这应该对任何想学习或改进数字设计技能的人有所帮助。设计并不是全部了解如何使用设计软件，这篇文章也不会教你如何使用软件。网络上有数以百计的优质教程资源可以教你学习如何使用设计软件。想做好设计，你需要理解你的产品，熟知它的特点和功能，以及在设计时始终将终端用户放在心里。这就是这篇文章的意义所在。

设计过程：

1.为每个页面创建一个用户流程图。

2.创建/绘制线框图。

3.选择设计图案和调色板。

4.创建模型。

5.创建一个动画应用程序原型，并要求人们对其进行测试并提供反馈。

6.给出最后调整确定的模型，并交由开发按原型编写代码。

我们正式开始吧!

用户流程图

第一步是想出在你的应用程序中想实现的功能。一旦你有了你的想法，设计一个用户流程图。用户流程图是用户通过app/网站进行访问的一个非常高级的表示。

通常，用户流程图由三种形状组成。

矩形用于表示页面。

方块用于表示决策(例如，点击登录按钮，向左滑动，缩放)。

箭头将页面和决策连接在一起。

用户流程图是非常有用的，因为它们给出了应用程序如何运作的良好逻辑思路。

下面是我在开始设计应用程序时绘制的用户流程图。

主界面的用户流程图。

线框图

一旦你完成了每个页面的用户流程图并设计了用户路线，你就可以开始为所有页面做线框图了。线框图在本质上是以低保真度形式表示你的应用程序外观。基本上是图像，标签，按钮，和其它元素的一个草图或一个轮廓，这些元素都会在页面上做好布局和定位。你的应用程序的草图会体现它是如何使用的。

我使用UI模板打印的模板来绘制线框图。 它既可以节省时间，而且给为我提供了一个很好的画布来绘图和做笔记。

下面是我绘制的一个线框图例子。

主界面的线框图。

绘制好线框图后，你可以使用一款名为Pop的应用程序，并使用该应用程序将草图拍照存档，再通过「连结」(link to)的功能，将一张张草图串联起来，就能直接在手机屏幕上展示原型实际运作的样子。

设计图案和颜色调色板

这是我最喜欢的部分。这就像逛街一样。有大量的设计图案和调色板可供选择。我可以去选择我喜欢的，并感受它们给我带来的视觉效果。

寻找设计图案的最佳平台是Mobile Patterns和Pttrns。想要找到好的调色板，你可以去“ Color Hunt”平台。

创建模型

这是当你最终使用设计软件的时候了。设计意义上的模型是以高保真的形式来表示你的应用程序。这就像你将来实际使用时进入这个应用程序，然后你从这里面做一些截图。它看起来应该很现实，非常像真实的东西。

有一些用于创建模型的设计软件和工具。我使用Affinity designer来创建模型。iOS设计中最常用的工具是Sketch。

下面是我早期设计APP中的一些实例。

我使用了各种各样的调色板来进行设计。

我给我的朋友分享了最初的模型，以获得他们的反馈。很多人似乎更喜欢黄金渐变和黑色背景。

我愿意接受更多的反馈并尝试新的建议!想获得更好的用户体验的方法是多与终端用户交流。当你与终端用户交谈时，你会发现用户有很多奇妙的想法，而不是去疯狂地翻阅Dribbble或Behance。

所以我重新设计了模型并删除了背景图，因为生成它们在技术上是一个耗时的过程，除此之外，它们还降低了可读性。下面就是我重新设计模型后的样子。

黄金渐变和黑色背景看起来非常不错!

我对这套颜色方案、标签栏上的图标和整体布局都非常满意。我继续按照相同的设计指南设计了其余的页面。这是一个漫长而有趣的过程!

一旦我的页面准备就绪，我就在Adobe XD上制作了一个原型，并请几个朋友进行使用并给出反馈。

经过最终的润色，下面是我确定的设计界面。

创业公司设计师怎样从0到1设计一款APP（Low-fi输出）？

Low-fi，即低保真原型图，整个APP设计阶段，设计师真正开始上手的环节。待PM制作好PRD文档和逻辑流程图之后，交互设计师开始依据已有的结论，画出Low-fi。

Low-fi的作用

1.方便团队进行方案的讨论和统一。就像使用场景Scenario和用户画像Personas，团队每个成员脑海中所理解的都会有所不同，但通过PRD，咱们可以进行至少是大体上的统一。而在这基础上，APP的具体画面和流程，每个人都有自己想象的视觉效果。Low-fi就在此时起了相同的作用。

当然统一的进一步促进效果是，进行后面核心功能的深入探讨，将概念落实到实施方案，并验证逻辑上是否能跑通，以及主页面元素的确定。

2.方便开发人员进行整体架构的布置，开始着手一些基础元素的部署。

3.做出demo进行内部尝试、小范围的用户调查，一般会有一些更改，不会影响项目主方向，大多是功能上的调整。

Low-fi的处理工具与文件要求

作为交互设计师，在low-fi阶段多使用的是sketch，PS更侧重于用来做图片的处理。出发点还是更多的从效率上进行考虑，sketch运行速度非常快，文档小，测量距离方便，可复用的图层组（symbol），做好图之后导出多倍图也十分方便。所以在此阶段做草图，sketch是不二之选。

然而，对low-fi的文件处理也有一些要求，主要分为视觉效果和文件名整理。

视觉效果上倾向于使用黑白灰无色彩感的设计方案，目的是为了降低视觉上的干扰，让设计师和团队其他成员，将精力重点放到APP本身的功能完善和逻辑完整上面。

而文件名的整理主要表现在图层命名需要规范。统一的控件用symbol进行管理，symbol的命名建议使用驼峰式，即每个单词间没有空格，每个单词首字母大写（这里说的是大驼峰式，即第一个单词的首字母也大写了）。

Symbol的分类主要有这几类，StatusBar、Keyboard、Header、Button、Cards、TabBar、Control、ListItem、Popup等，如果想细分也可以再进行一些细分，比如Popup可以再分出一个细枝为Toast等。

Icon类的只能用小写且不能以数字开头，不能包含空格。对于 icon，建议对通用模块再分子类（例如：icons/topnav/; icons/tabbar/; icons/general/...），原则是分类非常符合常识，到了后期icon类的symbol会非常多，这样方便快速从一堆 icon 中找到它。

对于Sketch的group管理，建议按照功能模块进行分类与命名。比方说，video中有VideoPlayer和SingleVideo不同种类，game有GameScore和GameReport等，按照不同的用途进行重组。

这样的目的是为了，在接下来用一些动态原型工具，比如Flinto或者Origami等等时，方便查找，以及合成图层组。绝大部分动态原型工具，都是靠渲染图片来进行展示原型的，图层越少，电脑效率越高使用越流畅。

文件在low-fi阶段整理地越清晰，设计师头脑越清晰，high-fi阶段越省力。

总的来说，在Low-fi阶段是定主体功能和APP雏形的阶段，在这一阶段，设计师需要帮助团队统一APP的整体架构，页面的大体功能模块分类和跳转关系，让APP从大家脑海中的形象落实到真实的视觉效果中~

Sophia的tips：

虽然只是low-fi，却也需要吃毛求疵般的职业态度~

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