架构设计的演变历程

1、无框架结构,直接调用底层API
以往是底层平台(操作系统)提供API让上层APP去调用。
这样的软件控制权在APP上。举例 APP调用了平台的函数 Fun1,那么平台要对Fun1进行维护不敢随意改变这个函数,系统的更新成本大,上层APP越多,维护成本越大,导致到平台被局限。

2、单层框架结构
为了让系统开发者取得控制权,后来架构师们建造了一种框架结构。
APP开发者在这个框架的结构基础上开发自己的APP。
单层结构的模型是下图所示:

除了一部分平台的API仍然是由APP所调用外,更多是由框架反向调用APP来驱动整个APP的运行,框架定义出接口与基类,APP基础基类写出具象类,框架通过调用接口来实现对APP的反向调用,这也是IoC原理的核心。

3、复合型框架
为了满足更多元化的软件业务需求的开发,从单层框架基础上延伸除了复合型框架,
大框架和平台是系统开发者来开发,小框架可以系统开发者或者第三方厂商开发,比如游戏引擎,小框架是可以根据不同业务来选型,APP在这种大小框架结合的情境下开发大大的降低了开发难度,加快了开发速度。

4、双层框架
为了进一步完善框架,即平衡APP的开发速度也要提高APP的运行速度。
那么结合Java和C++两种语言的特性来构建这个框架,Java是应用层级与APP开发者最亲近,它是负责简化APP开发来设计的,从语言特性来说Java是更简单,容易被APP开发者所使用,C++是更运行性能高效,是负责性能担当,它与平台更亲近。
两者结合,使得APP的开发速度快,且运行速度快。

5、Android的框架
Android的框架就是采用上面的双层复合型框架的方式来构建的。其实现在很多框架都采用这种方式来构建。

举例个例子来了解下Android的底层框架原理。
1、Android的四大组件,Activity、service、BroadcastReceiver、ContentProvider。

他们的作为基类是由框架所定义的,APP的开发者想要用组件的功能只能是写子类来继承使用。如定义 myActivity,由框架所调用 new myActivity 创建出对象并被调用 onCreate方法来创建窗体页面。
模拟一下框架的实现:
Activity object = new myActivity();
object.onCreate();
哪有人会疑惑,框架的代码是在这个APP开发之前就有了,那么框架代码怎么会有myActivity这个类,myActivity这个类明明是APP开发者来写的,这个名称系统开发者不可能提前知道。
这就归功于 AndroidManifest.xml文档,Mani文档里面要求开发者把自己定义的Activity的名称写上。
在APP执行阶段(run-time)Android框架就会读取开发者所写的Mani的内容,从而得知到开发者所写子类的名称,就能创建出这些应用子类的对象。
如下图所示:

2、组件与组件之间的沟通:
从上面大家知道组件的子类虽然由APP开发者所写,但却由框架所创建,
同样,组件中的通信也是由框架所负责,框架是组件间沟通的桥梁。而沟通的介质是intent,中文翻译过来是意图,实际是跟信封一个道理。
你给远在他方的女朋友寄一封信,你只要按照邮局规定的格式来写这封信,比如写好寄信人信息,收信人信息,和信的内容,最后投递到邮局,最终通过邮局来把这一封信寄到你女朋友手里。
同样APP开发者只需要按照格式写好Intent交给框架,而至于框架怎么把Intent交给对方你就不需要关注。

如下图所示:

时间: 2024-12-19 12:28:23

架构设计的演变历程的相关文章

架构设计的演变

架构设计的演变 1.无框架结构,直接调用底层API以往是底层平台(操作系统)提供API让上层APP去调用.这样的软件控制权在APP上.举例 APP调用了平台的函数 Fun1,那么平台要对Fun1进行维护不敢随意改变这个函数,系统的更新成本大,上层APP越多,维护成本越大,导致到平台被局限. 2.单层框架结构为了让系统开发者取得控制权,后来架构师们建造了一种框架结构.APP开发者在这个框架的结构基础上开发自己的APP.单层结构的模型是下图所示: 除了一部分平台的API仍然是由APP所调用外,更多是

微信序列号生成器架构设计及演变

微信序列号生成器架构设计及演变

整个网站架构的经典演变

BlueDavy之技术Blog 理论不懂就实践,实践不会就学理论! 大型网站架构演变和知识体系 之前也有一些介绍大型网站架构演变的文章,例如LiveJournal的.ebay的,都是非常值得参考的,不过感觉他们讲的更多的是每次演变的结果,而没有很详细的讲为什么需要做这样的演变,再加上近来感觉有不少同学都很难明白为什么一个网站需要那么复杂的技术,于是有了写这篇文章的想法,在这篇文章中 将阐述一个普通的网站发展成大型网站过程中的一种较为典型的架构演变历程和所需掌握的知识体系,希望能给想从事互联网行业

IM系统架构设计之浅见

背景:除去大名鼎鼎的QQ这款即时聊天工具,还有许多细分行业的IM,比如淘宝阿里旺旺.网易泡泡.YY语音.......恰巧公司产品也要开发一款基于我们自己行业的类IM系统,很有幸我担当了这个产品的架构师,核心代码编写.实现者.下面我近年来从技术上我对IM系统(即时消息的传输,不包括语音,视频,文件的传输)的理解和设计分享出来,浅薄之见,望大家别见笑,欢迎给出批评意见. 一.网络传输协议的选择 目前我知晓的所有IM系统传输即时消息无外乎使用UDP.TCP.基于TCP的http这几种协议中的一种或几种

以属性为核心驱动的 全领域通用架构设计原理 (简称:属性架构原理)

以属性为核心驱动的全领域通用架构设计原理 (简称:属性架构原理) 联系方式:13547930387 Email:[email protected] 一.个人声明 我,参加工作也有5年多了,是一名普通的不能在普通的程序员,一直在使用公司自己的产品进行开发,因此技术比较菜,此设计完全是按照自己天真的想法而设计的,如果有不合理或很搞笑的地方,请轻拍,由衷的希望大家能提出宝贵的意见: 根据此设计原理我也做了一个简单的(demo)架构来支撑和验证此理论的可行性,由于技术功底不太好,有不合理之处请大家谅解,

[转]专访企业QQ SaaS团队,谈企业级LNMP架构设计

FROM : http://www.csdn.net/article/2014-08-20/2821302-interview-tencent-b-qq-shuai-wang 对比IaaS和PaaS,SaaS得到的关注显然要少一些.究其根本,不仅因为SaaS关注的是功能方面的探索,更偏向于某个领域或层面的实际应用,还归结于相较前两者,软件的云化已基本趋于成熟,些许突破并不能带来产业上的变革.然而,较少的关注并不意味着缺乏明星产品:放眼国外,企业级SaaS服务已成为许多公司的一项重要收益来源,比如

.NET应用架构设计—重新认识分层架构(现代企业级应用分层架构核心设计要素)

阅读目录: 1.背景介绍 2.简要回顾下传统三层架构 3.企业级应用分层架构(现代分层架构的基本演变过程) 3.1.服务层中应用契约式设计来解决动态条件不匹配错误(通过契约式设计模式来将问题在线下暴露出来) 3.2.应用层中的应用控制器模式(通过控制器模式对象化应用层的职责) 3.3.业务层中的命令模式(事务脚本模式的设计模式运用,很好的隔离静态数据) 4.服务层作为SOA契约公布后DTO与业务层的DomainModel共用基本的原子类型 5.两种独立业务层职责设计方法(可以根据具体业务要求来搭

MySQL性能调优与架构设计——第1章 MySQL 基本介绍

MySQL性能调优与架构设计——第1章 MySQL 基本介绍 前言:作为最为流行的开源数据库软件之一, MySQL 数据库软件已经是广为人知了. 但是为了照顾对MySQL还不熟悉的读者,这章我们将对 MySQL 做一个简单的介绍.主要内容包括MySQL 各功能模块组成,各模块协同工作原理, Query 处理的流程等. 1.1 MySQLServer 简介 1.1.1 什么是 MySQLMySQL 是由MySQL AB公司(目前已经被SUN公司收归麾下,SUN已经被Oracle收购)自主研发的,目

谈谈UI架构设计的演化

谈谈UI架构设计的演化 经典MVC 在1979年,经典MVC模式被提出. 在当时,人们一直试图将纯粹描述思维中的对象与跟计算机环境打交道的代码隔离开来,而Trygve Reenskaug在跟一些人的讨论中,逐渐剥离出一系列的概念,最初是Thing.Model.View.Editor.后来经过讨论定为Model.View和Controller.作者自言“最难搞的就是给这些架构组件起名字”. 因为当时的软件环境跟现在有很大不同,所以经典MVC中的概念很难被现在的工程师理解.比如经典MVC中说:“vi