关于架构理解 - APP架构的基础

软件架构是一个系统的草图。软件架构描述的对象是直接构成系统的抽象组件。各个组件之间的连接则明确和相对细致地描述组件之间的通讯。在实现阶段，这些抽象组件被细化为实际的组件，比如具体某个类或者对象。在面向对象领域中，组件之间的连接通常用接口来实现。

　　软件体系结构是构建计算机软件实践的基础。与建筑师设定建筑项目的设计原则和目标，作为绘图员画图的基础一样，一个软件架构师或者系统架构师陈述软件构架以作为满足不同客户需求的实际系统设计方案的基础。

正如同软件本身有其要达到的目标一样，架构设计要达到的目标是什么呢？一般而言，软件架构设计要达到如下的目标：

• 可靠性（Reliable）。软件系统对于用户的商业经营和管理来说极为重要，因此软件系统必须非常可靠。
• 安全性（Secure）。软件系统所承担的交易的商业价值极高，系统的安全性非常重要。
• 可伸缩性（SCAlable）。软件必须能够在用户的使用率、用户的数目增加很快的情况下，保持合理的性能。只有这样，才能适应用户的市场扩展得可能性。
• 可定制化（CuSTomizable）。同样的一套软件，可以根据客户群的不同和市场需求的变化进行调整。
• 可扩展性（Extensible）。在新技术出现的时候，一个软件系统应当允许导入新技术，从而对现有系统进行功能和性能的扩展。
• 可维护性（MAIntainable）。软件系统的维护包括两方面，一是排除现有的错误，二是将新的软件需求反映到现有系统中去。一个易于维护的系统可以有效地降低技术支持的花费。
• 客户体验（Customer Experience）。软件系统必须易于使用。
• 市场时机（Time to Market）。软件用户要面临同业竞争，软件提供商也要面临同业竞争。以最快的速度争夺市场先机非常重要。

以上摘自： http://wiki.mbalib.com/wiki/%E8%BD%AF%E4%BB%B6%E6%9E%B6%E6%9E%84

软件框架

什么是框架

框架（Framework）是整个或部分系统的可重用设计，表现为一组抽象构件及构件实例间交互的方法;另一种定义认为，框架是可被应用开发者定制的应用骨架。前者是从应用方面而后者是从目的方面给出的定义。

可以说，一个框架是一个可复用的设计构件，它规定了应用的体系结构，阐明了整个设计、协作构件之间的依赖关系、责任分配和控制流程，表现为一组抽象类以及其实例之间协作的方法，它为构件复用提供了上下文(Context)关系。因此构件库的大规模重用也需要框架。

构件领域框架方法在很大程度上借鉴了硬件技术发展的成就，它是构件技术、软件体系结构研究和应用软件开发三者发展结合的产物。在很多情况下，框架通常以构件库的形式出现，但构件库只是框架的一个重要部分。框架的关键还在于框架内对象间的交互模式和控制流模式。

框架比构件可定制性强。在某种程度上，将构件和框架看成两个不同但彼此协作的技术或许更好。框架为构件提供重用的环境，为构件处理错误、交换数据及激活操作提供了标准的方法。

应用框架的概念也很简单。它并不是包含构件应用程序的小片程序，而是实现了某应用领域通用完备功能（除去特殊应用的部分）的底层服务。使用这种框架的编程人员可以在一个通用功能已经实现的基础上开始具体的系统开发。框架提供了所有应用期望的默认行为的类集合。具体的应用通过重写子类(该子类属于框架的默认行为)或组装对象来支持应用专用的行为。

为什么要用框架

因为软件系统发展到今天已经很复杂了，特别是服务器端软件，涉及到的知识，内容，问题太多。在某些方面使用别人成熟的框架，就相当于让别人帮你完成一些基础工作，你只需要集中精力完成系统的业务逻辑设计。而且框架一般是成熟，稳健的，他可以处理系统很多细节问题，比如，事务处理，安全性，数据流控制等问题。还有框架一般都经过很多人使用，所以结构很好，所以扩展性也很好，而且它是不断升级的，你可以直接享受别人升级代码带来的好处。

框架一般处在低层应用平台（如J2EE）和高层业务逻辑之间的中间层。

软件为什么要分层？ 为了实现“高内聚、低耦合”。把问题划分开来各个解决，易于控制，易于延展，易于分配资源…总之好处很多啦。

框架开发

框架的最大好处就是重用。面向对象系统获得的最大的复用方式就是框架，一个大的应用系统往往可能由多层互相协作的框架组成。

由于框架能重用代码，因此从一已有构件库中建立应用变得非常容易，因为构件都采用框架统一定义的接口，从而使构件间的通信简单。

框架能重用设计。它提供可重用的抽象算法及高层设计，并能将大系统分解成更小的构件，而且能描述构件间的内部接口。这些标准接口使在已有的构件基础上通过组装建立各种各样的系统成为可能。只要符合接口定义，新的构件就能插入框架中，构件设计者就能重用构架的设计。

框架还能重用分析。所有的人员若按照框架的思想来分析事务，那么就能将它划分为同样的构件，采用相似的解决方法，从而使采用同一框架的分析人员之间能进行沟通。

以上摘自https://baike.baidu.com/item/%E6%A1%86%E6%9E%B6/1212667?fr=aladdin

如果你细细的读，你就会发现，框架是一种实现，某个方面的具象实现。而架构更是一个全局的结构，包含各个部分的连接交互作用，这些部分可以是框架，可以是单个功能点。

如果架构是一个蓝图，框架就是某一个实现的支撑。

比如在实际前端开发中，我们选用了一套组件，这套组件包含我们所需要的组件，如图表分页、路由和国际化等，这是一套框架，框架中包含了前端架构需要的元素，国际化，路由，统一组件样式，但是框架只是一个部分，业务实现如何使用组件，组件间通信转接的方式，这就是架构上需要考虑的事情。

web开发的前端，但就页面和数据交互这部分，在react， angular，vue还不热门的时候，基本是jquery的天下， 基于jquery的框架层出不穷，如Ext， jquery easyUI，甚至各个公司为了不受制约，也开始自己研发基于jquery的框架。

当使用react native开始来做APP时（react native本身还没有1.0的版本），基本上处于一个无框架的状态，当然市面上已经提供很多库用来开发某一个块功能，如redux（flux），react—navigation（路由）, react-native-svg（图表）. react-native-animatable（动画）。但是却没有一个诸如antD这样的库来支撑APP开发， antD的针对性太强，适用于管理系统，对于APP来说太难界定框架的目的性，所以我们在实际开发中，就需要一些框架知识来设计APP。

我认为的框架需要包含的点如下：

• 开发统一规范
  • 命名格式规范，现在有eslint, tslint来帮助约束项目中一些基本问题，借助这些工具非常方便
• 通用函数：
  • 公共的函数，防止重复性声明
  • 用于处理该项目特有的通用的formatter，比如时间格式，金钱表示格式，百分比表示格式
    • 统一这些格式的好处在，当我们需要切换项目格式时，我们不需要每个地方都去修改
• 公用组件：
  • 项目中需要定制的组件开发
  • 组件对应定制的主题
    • 在公司长期产品开发，或是项目转产品的开发中，组件如果重复率高，可复用性强，可建立内部的组件库，或是针对性质的组件库，比如APP的一般组件库，APP的图形组件库。不要嫌麻烦，这对项目或是产品的长期运维来说是一个非常好的基础。
• 国际化语言
  • 一般中型大型项目中，都会设置国际化语言的标准，这不仅利于项目的多个地区的适配，也利于维护项目中各个功能的描述文字变化。
    • 切换其他国家语言方便
    • 如”确定“的文字描述，在有些弹出框描述为“是的”， 有些弹出框的按钮上描述为“OK”，OK是错误示范咯，但这对用户来说，会觉得该项目规范并不统一。除了UX从UI上的约束外，我们这里如果使用统一个文字Key，只需一个常量，全局统一。
• 日志系统：
  • 在做前端APP开发中，如果遇上错误导致APP崩溃，又很难查错，这时候日志系统就非常有用。一个框架中日志系统是必不可少的，在大型应用中，如果出现崩溃或是错误，可以建议用户直接提交错误信息到运维，这利于一个项目长期发展。
• 安全权限限制
  • 这对任何一个应用来说，都是非常重要的，在做一个应用，绝不能犯明知的错误，比如明文密码交互，不做跨域攻击的防护，不做脚本攻击的检测，这些错误都是相当于你把你的银行卡密码摆在一个公共的地方，总会被有心人利用。
• 异常机制
  • 对于APP的各个页面，还是网页的各个页面，创建了就像长满了树叶的树，当我们在根的地方，是看不到那片树叶有问题的，异常机制就是用来搜集所有的异常的，异常机制就是树干中的某一个脉络，用于传输信息到根结点异常处理中心，哪片树叶有问题，快记录下来，并看有没有对应处理措施，医好或者直接吹走，这样不会导致整个树瓦特掉，其他部分仍然能正常工作。
• 单元测试
  • 单元测试作为开发人元自己写的白盒测试，在任何一次更改和维护中，方便统一完成最初的功能设计，这对于项目长期发展，是一个能带来持续收益的机制，当然这也取决与开发人员的单元测试的功能覆盖率，如果真的设计的不好，相反就会有些鸡肋。
• 自动化测试工具
  • java中有selenium帮助做网页的自动化测试，平常web开发中，可以单独建立一个测试模块用于自动化测试，自动化测试建立在一个完整功能的全部开发完成并且相对稳定的状态，项目迭代到一个版本的交互时之前，自动化测试可以完成当前版本的功能覆盖，这利于小版本发布的时候里面功能的验证，以免破坏现有功能。
  • API的自动化测试工具，load runner， jmeter，我自己用过不多，对于测试人员来说，借助自动化测试工具会减少很多重复工作量，是福音哟，我是很不喜欢做重复的工作的，所以现在制作锅碗瓢盆都是模具，是个好事儿^_^
  • APP开发我目前还没发现可做自动化测试的工具，如果谁知道，可以推荐给我哈
• 构建工具
  • jenkins了解一下，很强大的构建工具
• 性能
  • 这个我也不知道算不算压轴项目，在项目开发中，确实是非常重要的，但是用于前端使用是分散在各个终端的，所以经常会觉得前端可优化的功能不多，但是实际不是。性能不仅体现在交互上面，在数据调用层次，渲染组件上面，程序的设计会带来很大的影响。
    • 比如我们完成一个功能，需要请求三个API，这三个API不互相依赖，那么我们有两种设计：三个API用promise.all统统请求回来一次交给用户去渲染，又或者，三个API分别发出去，每返回一次就渲染一次组件（这在react中可能影响并不是很大，因为react 是数据变化组件才会重新渲染，但是如果数据有交叉的话，就又不一样了）。所以在平常开发中一定要考虑性能问题

我们的目标是写出漂亮功能完整的代码，因为我相信一个好的程序猿，多多少少都有点强迫症，哼哼，我是有强迫症。

最后

以上就是暴躁缘分为你收集整理的关于架构理解 - APP架构的基础的全部内容，希望文章能够帮你解决关于架构理解 - APP架构的基础所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错，欢迎将靠谱客网站推荐给程序员好友。