网站建设功能需求表,泛微e8做网站门户,自己设计app,大型wordpress theme目录
四 Android架构探究
五 大骨架仿真
六 Android实例分析思路拓展 四 Android架构探究 首先#xff0c;Android系统所带来的好处#xff0c;就在于它本身代码的开放性#xff0c;这提供了一个学习、借鉴的平台。这对分析仿真而言#xff0c;本身就是一大利好#xf…目录
四 Android架构探究
五 大骨架仿真
六 Android实例分析思路拓展 四 Android架构探究 首先Android系统所带来的好处就在于它本身代码的开放性这提供了一个学习、借鉴的平台。这对分析仿真而言本身就是一大利好可以更深入的探究更加接近真实情况。其次从Android系统中所学的东西也可以运用于其他一些系统的设计中额外的它使用的优秀开源软件及使用方法也是值得学习运用的。最后这种公开性所开放出来的底层修改机会也使得在Android系统本身上可以有一番作为比如对系统进行优化。 Android系统的作用是支撑一个个的APP所以每一个APP都应该平等的享用系统的资源不管是硬件资源还是软件资源并且APP之间的地位也是平等的。如此一来就存在两个部分一个是系统管理部分为各个APP服务一个是APP们平等的跟管理者交互。对于Windows系统也是如此。管理者提供系统服务APP们通过管理者使用系统资源。将这种情况简化那么一般的嵌入式系统产品就是一个APP跟一些个服务交互。因为不会有人为这些个特殊的嵌入式产品编写APP所以不需要对服务和服务的使用者进行过多封装。反而从这个角度来看因为共享需求Android将系统资源封装供每个APP使用则是合理的而且也是得体的既不存在大材小用问题也不存在设计浪费问题更不存在多而无用的问题。 框架在此中充当了中间件的作用。 框架在此中也类似于C库作为一种共享库存在于每一个APP中。因此框架是一套逻辑将各个部分管理粘到一起的逻辑。就如同博主在这篇讨论框架的文章中所述软件架构及几种典型框架_龙赤子的博客-CSDN博客_软件架构通常我们看到main函数是第一个被调用的入口函数但是实际上main只是程序框架给我们的入口。我们在Android开发中不用从main开始第一行代码编写也只是因为框架帮我们实现了main该做的事情。这个过程中框架进行了二次封装。框架设计了一套逻辑共享库每一个应用集成该共享库应用不用实现main接口只需集成共享库的类接口即可。应用起来后实现在共享库中的框架逻辑会调用main接口并且会自动调用运行周期各个点上注册的函数。如此我们写的代码就跟框架融合在一起了。 最终大家共享的就是逻辑就是框架中的逻辑。框架中的全局变量不会产生影响因为应用之间是相互隔离的。框架只需处理好内部的共享即可。对于应用之间的交互框架会依赖系统服务完成。关于这些可以参考之前第三部分的说明。 再多说一些。我们可以从不同角度看框架的作用与价值。注意框架不是虚的它有承载的实体。从静态的角度来看架构是一个层既是分割层也是中间层更是粘合层。 框架提供逻辑与功能共享为所有服务和APP所共享。此时从进程角度来看框架的逻辑存在于每一个实体进程之中。大家按照框架给的统一模式来编写个性代码。如果还以房子为例的话统一的框架表示了房屋的承重、管道等大家是一样的但是每家利用这些资源装修后的房子是不一样的。再举个之前一直用的形象例子开网店。框架提供的各种资源是统一接口的比如CPU、内存、存储、网络、显示等等。每一家利用这些资源开发构建的各自网店不仅样式不一样功能更是多了去了。卖书的店铺跟卖手机的店铺关注的点肯定是不一样的。 基于上面的分析和Android系统的学习结合第三部分的思考整理了Android系统与Android内部Framework框架之间关系的一幅图如下 Android Framework图示说明 先看左上图这是Android启动的简略过程。通过这个过程我们会了解到zygote的原理。这是整个讨论的基础。 再看右上图上面部分是系统框架和应用的分层对应图。下面是应用的三种运行状态。第一种应用不需要与外部沟通只依赖框架内部逻辑。第二种应用需要通过框架跟其他服务沟通完成功能。第三种应用可用自己与系统底层沟通完成功能。正常来讲部分服务实现的也是这种方式从而将系统资源提供给大家共享。 最后看下图粗略展示了几种状态的运行关系。应用和服务依赖框架注册到服务管理模块并依赖内核提供的沟通机制实现进程间的通信。这部分是对图上半部分左右两块的另一个视角展示。 对于图中嵌入的诸多小方块其涉及应用和框架内置的代码逻辑。关于这部分说明如下 先从编译开始用户编写Java文件提供布局UI语言等其他文件和资源。Java编译为class字节文件其他图片、C/C动态库等资源直接打包运行时再按照规则处理。 对于Java编译分三种情况 第一种独立不依赖其他模块的Java代码直接编译为Java字节码即可设备中的虚拟机会解读这些字节码并执行它们。 第二种依赖第三方jar文件编译时需要导入class文件以便编译时遇到未知接口时可以查找这些依赖文件找到接口所在文件并将其关联起来从而形成一个整体。打包时需要导入安装包中。这也算是框架的一部分或者说是整个拼图的一部分。 第三种系统自身提供的jar文件比如android.jar。需要根据SDK提供的不同版本选择合适的版本使用。构成本身同样为class文件编译遇到未知接口时会查找连接这就是为什么IDE中要下载相关的SDK并形成一个整体。这部分跟第三方依赖库可能有些差异。第三方依赖库是需要打包到安装包中的因为系统不能保证内部包含特定APP依赖的特定第三方jar。但是对于系统自身提供的jar可能没必要将所有的都打包到APP中因为系统在应用环境构建时公共的部分已经加载到系统中了。这就类似我们用C、C编写程序在二进制代码中会标出来需要使用标准库但是并不实际打包到可执行程序文件中。程序实际加载运行时操作系统会帮助解决依赖的标准库问题。我想Android也是类似的。 从进程运行角度来看通过框架的分割实现了逻辑的相互隔离并减少了逻辑上的缠绕。框架存在于进程之中服务于实体之间的交互也在上图中得到了体现。总的来讲这部分既是对第三部分的进一步确认和细化也是我们做框架大骨架仿真的一个基础一个尝试。 为强化对上面内容的理解我们再举两个例子。一个是想象的例子一个是实际的例子。先看想象的例子 上面以应用显示为例子。系统中有一个处理显示合成渲染的进程所有应用要显示的内容都是告诉该进程来完成的。这个告诉过程就由框架来完成了。另外不同应用功能不同用到框架中的资源也不一样。比如一个带WIFI相关功能的应用跟一个单纯打电话的应用对框架资源使用的部分肯定是不同的但这并不影响框架发挥作用。 下面再看看实际的例子。 上面两图展示了博主做的一个IPTV应用架构该应用基于Android平台。该应用要用到浏览器并且要对浏览器进行改造因此博主将系统的浏览器复制了一份给该IPTV应用单独提供了一个特供浏览器。这个特制浏览器跟系统原生浏览器基本一致只是增加了对一些自定义JS对象的支持。 为了给自己的应用提供一个特制浏览器博主将Android浏览器从底层到上层都复制了一份。这样从静态来看应用Framework中就包含了两个浏览器核心。只不过我们专门改过的那份核心别的应用调用不到。从动态来看应用层代码逻辑复制了一份底层动态库也复制了一份所以应用进程空间中浏览器相关的代码都有两份而且浏览器中有关线程的创建也会多一份最终造成的结果就是系统默认自带的那个浏览器核心代码在IPTV应用中永远不会调到也不会参与网页的渲染。 从这个例子大家也可以感受一下框架的魅力。 五 大骨架仿真 暂略。 六 Android实例分析思路拓展 补充说明在第五部分展开之前再整理一下思路。 实例Android运行时的情景分析 以运行时内存中的各个进程为对象来研究各个类的实现。从这个角度看的话代码的实现都可以看成是逻辑的堆彻是静态的提供了设计精巧的条条通道通过这些通道彼此关联起来以便再运行时彼此交互。这种思路更加接近于逻辑控制而我们常常还停留在流程控制上。其实我们理解一个事物往往喜欢从流程入手这样更容易一些。但当我们认识到一定程度后流程的东西反而成了拖累。此时就喜欢从抽象的角度来看待问题这样能够看到更本质的东西。而那些流程上的细节已经内化于心被隐藏起来了。 另外一种运行时情景分析【进程运行时情景分析】 1 全局变量在任务之外 2 构建内存运行时情景图比如代码段数据段等 3 数据结构在内存中的样式和作用 4 深刻理解程序就是数据结构加算法这一说 5 任务也就是线程与进程的内存情景 6 从内存情景图着手分析代码的执行流程感受内存中数据结构及其附带的Buffer的变化实际了解程序执行。 图片1 外框内存田 内框进程 进程内框分任务和数据参考操作系统概念一书 图片2 内存中运行的程序进行拍照快照图 时刻1 时刻2 时刻3等等的图片通过加粗变化的地方感受2和5描述的内容 第三种情景分析角度通过进程分析Android服务。这是很多讲述Android架构的书籍所忽略的一点。使用PS命令看进程及其父子关系分析各个服务。这是从动的角度来分析逻辑的东西。 其实还可以学架构设计中的做法分不同的角度来分析比如逻辑图、框架图、物理图、进程图、开发图等等。就像矩阵的变换一样东西还是那个东西但是变化一下角度就能看到不一样的内容。这里也是如此通过不同的角度对程序的运行情景有一个完整的认识。 以上记录一些框框思路后续有时间补充具体内容。
