android体系架构

1. 一般的android开发都用到了系统架构哪些层

一般的android开发都用到了系统架构哪些层?

1：android分为四个层，从高层到低层分别是应用程式层、应用程式框架层
开发一个程式，android系统框架是层层相扣，不能分开的。 应用程式层： 这个层主要指的就是用java语言编写的执行在虚拟机器上的程式，Google在最开始时就 在android系统中捆绑了一些核心的应用（核心应用的编写必须使用应用层序框架层的API框架.
2：android 开发框架有四个层，从高层到低层分别是应用程式层、应用程式框架层
android应用开发框架是 Application Framework. 其系统架构由5部分组成，分别是：Linux Kernel、Android Runtime、Libraries、Application Framework、Applications。

android开发一般用哪些框架

开发什么应用？
硬体还是软体？
硬体的话，看看这个：
:m2m.temolin./doc/62/m100wu-lian-mo-kuai
软体的话，看看这个：
:jb51./article/51052.htm

开发安卓APP 系统架构算是C/S架构么？

对于作业系统来言，不存在C/S,B/S一说。
java的确执行效率不如C/C++,但任何开发语言都有其各种特点，有缺点必有优点，否而只能被淘汰。
java有很多过人之处，要不然android也不会看上java作为其应用层的开发语言。
android相比IOS，的确存在距离，但我始终相信以LINUX为核心的android在几百万开发者的磨练下，将会越来越完美，“开源”永远值得人们去琢磨，精益求精！

Solaris支援哪些系统架构?

Solaris支援多种系统架构: SPARC, x86 and x64. x64即AMD64及EMT64处理器。在版本2.5.1的时候，Solaris曾经一度被移植到PowerPC架构, 但是后来又在这一版本正式释出时被删去。与Linux相比，Solaris可以更有效地支援对称多处理器、即SMP架构。Sun同时宣布将在Solaris 10的后续版本中提供Linux执行环境, 允许Linux二进位制程式直接在Solaris x86和x64系统上执行。
Solaris传统上与基于Sun SPARC处理器的硬体体系结构结合紧密, 在设计上和市场上经常捆绑在一起，整个软硬体系统的可靠性和效能也因此大大增强。然而SPARC系统的成本和价格通常要高于PC类的产品，这成为Solaris进一步普及的障碍。可喜的是，Solaris对x86体系结构的支援正得到大大加强，特别是Solaris 10已经能很好地支援x64(AMD64/EMT64)架构。Sun公司已推出自行设计的基于AMD64的工作站和服务器，并随机附带Solaris 10。

dalvik虚拟机器属于android系统架构中的哪一层

dalvik是执行的时候编译+执行，安装比较快，开启应用比较慢，应用占用空间小
ART是安装的时候就编译好了，执行的时候直接就可以执行的，安装慢，开启应用快，占用空间大
用个比喻来说就是，骑脚踏车
dalvik 是已经摺叠起来的脚踏车，每次骑都要先组装脚踏车才能骑
ART 是已经组装好的脚踏车，每次骑直接上车就能走人

系统架构键亮耐方案有哪些

系统架构属于系统设计阶段，系统架构图只是这个阶段一个产物，要正确的、合理的画系统架构图需要全面的理解使用者需求以及业务流程，当理解了这些东西后，剩下的就是如何进行表达了，一般而言，可以参照RUP的用例驱动来进行逻辑架构，开发架构等设计工作，你稿春的系统架构图可以反应在各个视图里面，我估计你所说的系统架构图是属于逻辑架构里面，比键枝如分多少层，每层分多少模组等。
至于，绘制的工具，有很多很多。可以选择微软的visio,或者EA,rose,power designer等UML建模工具，当然，你甚至可以用PPT,Word来绘制。
当然，系统架构不是一日之功，需长期努力，跟经验和技术都有很大关系。
今天兴致来了，回复了这么多，不知满意不。

android开发架构的问题

我不是高人，也谈不上指点，我只是一个很普通的程式码工人发表一下自己的看法哈~~
一个activity上多个surfaceview切换的做法是做游戏开发的，现在市面上大多数游戏都是采用的这种做法，并没有什么不妥，surfaceview使得画面更自由，拿到canvas后就不局限于安桌提供的控制元件了，纯自由发挥，各种游戏特效表现得更精彩。只是切换surfaceview时稍微麻烦点，需要写程式码来手动判断游戏状态和控制切换。
如果你只是做普通的应用，安桌提供的控制元件能满足你的需求，你就用普通的activity呗。用surfaceview多麻烦啊。把切换丢给系统来管理，省去不少事儿。如果你愿意麻烦，使用surfaceview来相互手动切换，也没什么问题的，放心去做吧。毕竟记忆体管理机制用的是JАVΑ的那一套，自动回收，用哪种架构都差别不大。
个人拙见，手动拼音打字，非ctrl+c/ctrl+v之流。望诸位看官别笑话俺哈~~

系统架构师 要学什么?哪些学习提供培训系统架构师?

一个好的IT架构师,眼光不会仅仅停留在写程式码的层次上,在做开发的时间里，他们会积极学习各种知识，经验，培养自己的商业头脑，包括扩充套件自己各方面的资源，这些积累会为他们未来成为管理者或创业打下牢固的基础。
对于学习来说我们都是希望可以全面综合的掌握技术，这样才有助于你今后的整体发展。目前企业需要的不再是理论型人才了，而是实用技能型人才。
首先我们需要全面掌握专业实用的技术，其次加强个人整体素质的提升，这样才能符合目前企业的用人需求。如果我们选择了单科学习无疑是在起跑线上局限了我们的个人发展，或许短期内你觉得只是需要某项单独的技术，但是你有没有想过今后你不可能一直从事底层的程式设计师，看着和你同意时间进入公司的同事虽然技术和你不相上下，但是由于掌握的比较全面而被提升为专案主管、专案经理，或许到那个时候你又要为此再一次走进培训机构，这样也是耽误你个人的时间和精力，我相信你也希望自己今后可以步入管理层工作，有一个更好的发展。最好 是 掌握全面的技术,资料库,JAVA.NET.客户端技术。

对于Java系统，大家现在都用什么系统架构

就我接触到的说一下，我第一家公司专案比较小型是 springmvc + spring + hibernate （也有mabatis的） ，第二家公司，专案是大型的，所以好多是分散式的框架，spring、spring integration、bbo、zookeeper、redis、mybatis等都有用到

“系统架构”是什么意思？都有哪些架构？

JDE属于分散式架构,人和系统恕我孤陋寡闻,没听过阿

2. NFC开发（一）——HCE基于主机的卡模拟简述

许多提供NFC功能的基于Android的设备已经支持NFC卡模拟。在大多数情况下，该卡由设备中的单独芯片模拟，称为 安全元件(Secure Element) 。无线运营商提供的许多SIM卡还包含安全元件(Secure Element)。

Android 4.4引入了另一种卡模拟方法，它不涉及SE，称为 基于主机的租芹卡模拟 。这允许任何Android应用程序模拟卡并直接与NFC读卡器通话。本文档描述了基于主机的卡肢型裂仿真（HCE）如何在Android上工作，以及如何使用此技术开发模拟NFC卡的应用程序。

当使用安全元件(Secure Element)提供NFC卡模拟时，将通过Android应用程序将要模拟的卡提供到设备上的安全元件(Secure Element)中。然后，当用户通过NFC终端握住设备时，设备中的NFC控制器将来自读卡器(NFC Reader)的所有数据直接路由到安全元件(Secure Element)。图1说明了这个概念。

安全元件(Secure Element)本身执行与NFC终端的通信，并且完全不涉及Android应用。交易完成后，Android应用程序可以直接查询SE的交易状态并通知用户。

当使用基于主机的卡仿真来仿真NFC卡时，数据将被路由到直接运行Android应用程序的主机CPU，而不是将NFC协议帧路由到SE。图2展示了基于主机的卡仿真如何工作。

NFC标准提供对许多不同协议的支持，并且可以模拟不同类型的卡。

Android 4.4支持当今市场上常见的几种协议。许多现有的非接触式卡已经基于这些协议，例如非接触式支付卡。这些协议也得到了当今市场上众多NFC读卡器的支持，其中包括Android NFC设备可以自己作为读卡器（请参见 IsoDep 课程）。这使您可以仅使用基于Android的设备在HCE周围构建和部署端到端NFC解决方案。

具体而言，Android 4.4支持基于NFC-Forum ISO-DEP规范（基于ISO / IEC 14443-4）的仿真卡，并处理ISO / IEC 7816-4规范中定义的应用协议数据历闭单元（APDU）。Android只强制在Nfc-A（ISO / IEC 14443-3 Type A）技术之上模拟ISO-DEP。支持Nfc-B（ISO / IEC 14443-4 Type B）技术是可选的。所有这些规格的分层如图3所示。

Android中的HCE体系结构基于Android Service 组件（称为“HCE服务”）。服务的一个关键优势是它可以在没有任何用户界面的情况下在后台运行。这对于许多HCE应用程序来说非常合适，例如会员卡或公交卡，用户不需要启动应用程序即可使用它。相反，通过NFC读卡器轻敲设备将启动正确的服务（如果尚未运行）并在后台执行该事务。当然，如果有意义的话，您可以自由地从您的服务中启动额外的UI（例如用户通知）。

当用户将设备连接到NFC读取器时，Android系统需要知道NFC读取器实际想要与哪个HCE服务通话。这就是ISO / IEC 7816-4规范的出处：它定义了一种选择应用程序的方式，以应用程序ID（AID）为中心。一个AID最多由16个字节组成。如果您正在模拟现有NFC读卡器基础架构的卡片，那么这些读卡器所寻找的AID通常是众所周知的并且是公开注册的（例如Visa和MasterCard等支付网络的AID）。

如果您想为自己的应用程序部署新的读卡器基础结构，则需要注册您自己的AID。AID的注册程序在ISO / IEC 7816-5规范中定义。如果您要为Android部署HCE应用程序，Google建议按照7816-5注册AID，因为它可以避免与其他应用程序发生冲突。

在某些情况下，HCE服务可能需要注册多个AID才能实现某个应用程序，并且需要确保它是所有这些AID的默认处理程序（而不是组中的某些AID转到其他服务） 。

一个AID组是应该被OS视为一起归属的AID列表。对于AID组中的所有AID，Android会保证以下其中一项：

换句话说，没有中间状态，组中的一些AID可以路由到一个HCE服务，另一些AID可路由到另一个。

每个AID组都可以与一个类别关联。这允许Android按类别将HCE服务组合在一起，并且反过来又允许用户在类别的级别而不是AID级别设置默认值。通常，避免在应用程序的任何面向用户的部分提及AID：它们对普通用户没有任何意义。

Android 4.4支持两种类别: CATEGORY_PAYMENT （涵盖行业标准支付应用程序）和 CATEGORY_OTHER （对于所有其他HCE应用程序）。

要使用基于主机的卡仿真来模拟NFC卡，您需要创建一个 Service 处理NFC事务的组件。

您的应用程序可以通过检查 FEATURE_NFC_HOST_CARD_EMULATION 功能来检查设备是否支持HCE 。您应该 <uses-feature> 在应用程序清单中使用该标记来声明您的应用程序使用HCE功能，以及该应用程序是否需要运行。

Android 4.4带有一个便利的 Service 类，可以作为实现HCE服务的基础： HostApService 类。

因此，第一步要扩大 HostApService 。

HostApService 声明了两个需要重写和实现的抽象方法。

processCommandAp() 只要NFC读卡器将应用协议数据单元（APDU）发送到您的服务，就会调用它。APDU也在ISO / IEC 7816-4规范中定义。APDU是在NFC读卡器和您的HCE服务之间交换的应用级数据包。该应用级协议是半双工的：NFC读卡器会向您发送命令APDU，并等待您发送响应APDU作为回报。

如前所述，Android使用AID来确定读者想要与哪个HCE服务交谈。通常，NFC读卡器向您的设备发送的第一个APDU是“SELECT AID”APDU; 这个APDU包含读卡器想与之交谈的AID。Android从APDU中提取AID，将其解析为HCE服务，然后将该APDU转发给已解析的服务。

您可以通过返回响应APDU的字节来发送响应APDU [processCommandAp()]( https://developer.android.com/reference/android/nfc/cardemulation/HostApService.html#processCommandAp(byte[] , android.os.Bundle))。请注意，此方法将在应用程序的主线程中调用，该线程不应被阻止。所以如果你不能立即计算并返回一个响应APDU，那么返回null。然后，您可以在另一个线程上完成必要的工作，并 sendResponseAp() 在完成后使用 HostApService 该类中定义的方法发送响应。

Android会继续将新的APDU从读取器转发到您的服务，直到：

在这两种情况下，你的类的 onDeactivated() 实现都是通过一个参数来调用的，这个参数指出了两者中的哪一个发生了。

如果您正在使用现有的读卡器基础架构，则需要实现读卡器在您的HCE服务中期望的现有应用程序级协议。

如果您正在部署您控制的新读卡器基础架构，则可以定义自己的协议和APDU序列。通常，尝试限制APDU数量和需要交换的数据大小：这样可以确保用户只需将设备通过NFC读取器持续一段时间即可。合理的上限约为1KB的数据，通常可以在 300ms 内交换。

您的服务必须像往常一样在清单中声明，但还必须在服务声明中添加一些附加件。

首先，为了告诉平台它是一个实现 HostApService 接口的HCE服务 ，你的服务声明必须包含一个 SERVICE_INTERFACE 动作的 Intent Filter 。

另外，为了告知平台哪个AIDs组被这个服务请求，一个 SERVICE_META_DATA <meta-data> 标签必须包含在服务的声明中，指向一个XML资源和关于HCE服务的附加信息。

最后，您必须将该 android:exported 属性设置为true，并且 "android.permission.BIND_NFC_SERVICE" 在服务声明中要求权限。前者确保服务可以被外部应用程序绑定。后者然后强制只有拥有该 "android.permission.BIND_NFC_SERVICE" 权限的外部应用程序 才能绑定到您的服务。既然 "android.permission.BIND_NFC_SERVICE" 是一个系统权限，这有效地强制只有Android OS可以绑定到你的服务。

这是一个 HostApService 清单声明的例子：

这个元数据标签指向一个 apservice.xml 文件。下面显示了具有包含两个专有AID的单个AID组声明的此类文件的示例：

该 <host-ap-service> 标签需要包含一个 <android:description> 属性，该属性包含可能在UI中显示的用户友好的服务描述。该 requireDeviceUnlock 属性可用于指定在调用此服务来处理APDU之前必须先解锁设备。

在 <host-ap-service> 必须包含一个或多个 <aid-group> 标签。每个 <aid-group> 标签都需要：

最后，您的应用程序还需要拥有 NFC 可以注册为HCE服务的 权限。

多个 HostApService 组件可以安装在单个设备上，并且可以由多个服务注册相同的AID。Android平台根据AID属于哪个类别来解决AID冲突。每个类别可能有不同的冲突解决策略。

例如，对于某些类别（如付款），用户可能能够在Android设置UI中选择默认服务。对于其他类别，策略可能总是要求用户在冲突情况下调用哪个服务。要查询特定类别的冲突解决策略，请参阅 getSelectionModeForCategory() 。

应用程序可以使用[isDefaultServiceForCategory(ComponentName, String)]( https://developer.android.com/reference/android/nfc/cardemulation/CardEmulation.html#isDefaultServiceForCategory(android.content.ComponentName , java.lang.String))API 检查其HCE服务是否是某个类别的默认服务。

如果您的服务不是默认设置，则可以请求将其设置为默认设置。看 ACTION_CHANGE_DEFAULT 。

Android会将AID组为“payment”的类别，声明的HCE服务视为支付应用程序。Android 4.4版本包含一个名为“tap＆pay”的top-level设置菜单条目，它列举了所有这些支付应用程序。在此设置菜单中，用户可以选择在点按付款终端时将调用的默认支付应用程序。

为了提供更具视觉吸引力的用户体验，HCE支付应用程序需要为其服务提供额外的resource：所谓的服务标记。

这个asset的大小应该是260x96 dp，并且可以在元数据(meta-data)XML文件中通过添加指向drawable resource android:apServiceBanner 的 <host-ap-service> 标签的属性来指定 。一个例子如下所示：

当设备的屏幕关闭时，当前的Android实施将NFC控制器和应用程序处理器完全关闭。因此，当屏幕关闭时，HCE服务将无法工作。

然而，HCE服务可以从锁定屏幕中起作用：这由HCE服务标记中的 android:requireDeviceUnlock 属性控制 <host-ap-service> 。默认情况下，不需要设备解锁，即使设备被锁定，您的服务也会被调用。

如果您将 android:requireDeviceUnlock HCE服务的属性设置为“true”，Android会提示用户在您靠近NFC读卡器时解锁设备，NFC读卡器会选择已解析为您的服务的AID。解锁后，Android会显示一个对话框，提示用户再次点击以完成交易。这是必要的，因为用户可能已经将设备从NFC读卡器移开以便解锁它。

本部分对于已经部署依赖SE进行卡模拟的应用程序的开发人员很感兴趣。Android的HCE实现旨在与其他实现卡仿真的方法并行工作，包括使用SE。

这种共存基于一种称为“AID路由”的原则：NFC控制器保留一个由（有限）路由规则列表组成的路由表。每个路由规则都包含一个AID和一个目的地。目标可以是主机CPU（Android应用程序正在运行的地方），也可以是连接的SE。

当NFC读卡器发送具有“SELECT AID”的APDU时，NFC控制器解析它并检查AID是否与其路由表中的任何AID匹配。如果匹配，那么APDU和其后的所有APDU将被发送到与AID相关联的目的地，直到收到另一个“SELECT AID” APDU或NFC链路断开。

图4说明了这种架构。

NFC控制器通常还包含APDU的默认路由。在路由表中找不到AID时，将使用默认路由。尽管此设置可能因设备而异，但Android设备需要确保您的应用注册的AID已正确路由到主机。

实现HCE服务或使用SE的Android应用程序不必担心配置路由表 - 这是由Android自动处理的。Android只需要知道哪些AID可以由HCE服务处理，哪些可以由SE处理。基于哪些服务已安装，以及哪些用户已配置为首选服务，路由表会自动配置。

我们已经介绍了如何声明HCE服务的AID。以下部分说明如何为使用SE进行卡模拟的应用程序声明AID。

使用SE进行卡模拟的应用程序可以在其清单中声明所谓的“关闭主机服务”。这种服务的声明几乎与宣布HCE服务相同。以下情况例外：

相应 apservice.xml 文件注册两个AID 的示例：

该 android:requireDeviceUnlock 属性不适用于脱离主机服务，因为主机CPU不参与事务，因此无法阻止SE在设备锁定时执行事务。

该 android:apServiceBanner 属性必须用于作为支付应用程序的关闭主机服务，以便作为默认支付应用程序进行选择。

Android本身永远不会启动或绑定到声明为“脱离主机”的服务。这是因为实际交易由SE执行，而不是由Android服务本身执行。服务声明仅允许应用程序注册安全元件(Secure Element)上存在的AID。

HCE体系结构本身提供了一个核心安全性：因为您的服务受到 BIND_NFC_SERVICE 系统权限的保护，所以只有操作系统可以绑定到您的服务并与之通信。这可以确保您收到的任何APDU实际上都是OS从NFC控制器接收到的APDU，并且您发回的任何APDU只会发送到操作系统，而操作系统会直接将APDU转发给NFC控制器。

剩下的核心部分就是您获取应用程序发送给NFC读卡器的数据的位置。这在HCE设计中有意解耦：它不关心数据来自何处，它只是确保将其安全地传送到NFC控制器并传送到NFC读取器。

为了安全地存储和检索您希望从HCE服务发送的数据，例如，您可以依靠Android应用程序沙箱，将应用程序的数据与其他应用程序隔离。有关Android安全性的更多详细信息，请阅读 安全提示 。

这部分内容对于希望了解HCE设备在NFC协议的防冲突和激活阶段使用何种协议参数的开发人员很感兴趣。这允许构建与Android HCE设备兼容的读卡器基础结构。

作为Nfc-A协议激活的一部分，交换多个帧。

在交换的第一部分，HCE设备将呈现其UID; HCE设备应该被假定为具有随机的UID。这意味着在每个抽头中，呈现给读卡器的UID将是随机生成的UID。因此，NFC读卡器不应依赖HCE设备的UID作为身份验证或身份验证的一种形式。

NFC读取器可以随后通过发送SEL_REQ命令来选择HCE设备。HCE设备的SEL_RES响应将至少设置第6位（0x20），表示设备支持ISO-DEP。注意，SEL_RES中的其他位也可以被设置，表示例如对NFC-DEP（p2p）协议的支持。由于可以设置其他位，所以想要与HCE设备交互的读者应该明确检查第6位，并且<stront style="box-sizing: inherit;">不要将完整的SEL_RES与值0x20进行比较。</stront>

Nfc-A协议激活后，NFC读取器启动ISO-DEP协议激活。它发送一个“RATS”（请求选择应答）命令。RATS响应（ATS）完全由NFC控制器生成，不能由HCE服务配置。然而，HCE实现需要满足NFC论坛对ATS响应的要求，因此NFC读卡器可以根据NFC论坛对任何HCE设备的要求设置这些参数。

以下部分提供了有关NFC控制器在HCE设备上提供的ATS响应的各个字节的更多详细信息：

请注意，许多HCE设备可能符合EMVCo联合的支付网络在其“非接触式通信协议”规范中指定的协议要求。尤其是：

如前所述，HCE实现仅支持单个逻辑通道。尝试在不同的逻辑通道上选择应用程序将不适用于HCE设备。

本文 翻译自 谷歌开发者文档，已由本人仔细校对。如有错误，请联系我，以便修改。

3. 什么是android系统，android的发展以及android的平台架构和特性

Android平台采用了整合的策略思想，包括底层Linux操作系统、中间层的中间件和上层的Java应用程序。下面我把Android的特性及其架构体系结构总结一下。

一、Android的平台特性

Android平台有如下特性：

1. 应用程序框架支持组件的重用与替换。

这样我们可以把系统中不喜欢的应用程序删除，安装我们喜欢的应用程序。

2. Dalvik虚拟机专门为移动设备进行了优化。

Android应用程序将由Java编写、编译的类文件通过DX工具转换成一种后缀名为.dex的文件来执行。Dalvik虚拟机是基于寄存器的，相对于Java虚拟机速度要快很多。

3. 内部集成浏览器基于开源的WebKit引擎。

有了内置的浏览器，这将意味着WAP应用的时代即将结束，真正的移动互联网时代已经来临，手机就是一台“小电脑”，可以在网上随意遨游。

4. 优化的图形库包括2D和3D图形库，3D图形库基于OpenGL ES 1.0。

强大的图形库给游戏开发带来福音。在3G最为重要的的应用莫过于手机上网和手机游戏。

5. SQLite用作结构化的数据存储。

6. 多媒体支持包括常见的音频、视频和静态印象文件格式

如MPEG4、H.264、MP3、AAC、AMR、JGP、PNG、GIF。

7. GSM电话（依赖于硬件）。

8. 蓝牙（Bluetooth）、EDGE、3G、WiFi（依赖于硬件）。

9. 照相机、GPS、指南针和加速度计（依赖于硬件）。

10. 丰富的开发环境包括设备模拟器、调试工具、内存及性能分析图表和Eclipse集成的开发环境插件。

Google提供了Android开发包SDK，其中包含了大量的类库和开发工具，并且针对Eclipse的可视化开发插件ADT。

二、Android平台架构

从上图我们可以看出，Android操作系统的体系结构可分为4层，由上到下依次是应用程序、应用程序框架、核心类库和Linux内核，其中第三层还包括Android运行时的环境。下面分别来讲解各个部分。

1. 程序应用

Android
连同一个核心应用程序包一起发布，该应用程序包包括E-mail客户端、SMS短消息程序、日历、地图、浏览器、联系人管理程序等。所有的应用程序都是用Java编写的。

2. 应用程序框架

开发者完全可以访问核心应用程序所使用的API框架。该应用程序框架架构用来简化组件软件的重用，任何一个应用程序都可以发布它的功能块并且任何其他的应用程序都可以使用其所发布的功能块（不过得遵循框架的安全性限制）。该应用程序重用机制使得组件可以被用户替换。

以下所有的应用程序都由一系列的服务和系统组成，包括：

1）一个可扩展的视图（Views）可以用来创建应用程序，包括列表（lists）、网络（grids）、文本框（text
boxes）、按钮（buttons），甚至是一个可嵌入的Web浏览器。

2）内容管理器（Content Providers）使得应用程序可以访问另一个应用程序的数据（如联系人数据库），或者共享它们自己的数据。

3）一个资源管理器（Resource Manager）提供非代码资源的访问，如本地字符串、图形和分层文件（layout files）。

4）一个通知管理器（Notification Manager）使得应用程序可以在状态栏中显示客户通知信息。

5）一个活动类管理器（Activity Manager）用来管理应用程序生命周期并提供常用的导航回退功能。

3. Android程序库

Android包括一个被Android系统中各种不同组件所使用的C/C++集库。该库通过Android应用程序框架为开发者提供服务。

以下是一些主要的核心库：

1）系统C库：一个从BSD继承来的标准C系统函数库（libc），专门为基于Embedded Linux的设备定制。

2）媒体库：基于PacketVideo
OpenCORE；该库支持录放，并且可以录制许多流行的音频视频格式，还有静态映像文件包括MPEG4、H.264、MP3、AAC、JPG、PNG。

3）Surface Manager：对显示子系统的管理，并且为多个应用程序提供2D和3D图层的无缝融合。

4）LibWebCore：一个最新的Web浏览器引擎，用来支持Android浏览器和一个可嵌入的Web视图。

5）SGL：一个内置的2D图形引擎。

6）3D libraries：基于OpenGL ES 1.0 APIs实现；该库可以使用硬件3D加速(如果可用）或者使用高度优化的3D软加速。

7）FreeType：位图（bitmap）和向量（vector）字体显示。

8）SQLite：一个对于所以应用程序可用、功能强劲的轻型关系型数据库引擎。

4. Android运行库

Android包括了一个核心库，该核心库提供了Java编程语言核心库的大多数功能。

每一个Android应用程序都在它自己的进程中运行，都拥有一个独立的Dalvik虚拟机实例。Dalvik是针对同时高效地运行多个VMs实现的。Dalvik虚拟机执行.dex的Dalvik可执行文件，该格式文件针对最小内存使用做了优化。该虚拟机是基于寄存器的，所有的类都是经由Java汇编器编译，然后通过SDK中的DX工具转化成.dex格式由虚拟机执行。

Dalvik虚拟机依赖于Linux的一些功能，比如线程机制和底层内存管理机制。

5. Linux内核

Android的核心系统服务依赖于Linux内核，如安全性、内存管理、进程管理、网络协议栈和驱动模型。Linux内核也同时作为硬件和软件栈之间的硬件抽象层。

4. android系统 主要有哪几部分

android系统分为四部分，从高到低分别是：

1、Android应用层

2、Android应用框架层

3、Android系统运行层

4、Linux内核层

Android系统构架主要应用于ARM平台，但不仅限于ARM，通过编译控制，在X86、MAC等体系结构的机器上同样可以运行。

(4)android体系架构扩展阅读：

Android运行库

Android包括了一个核心库，该核心库提供了JAVA编程语言核心库的大多数功能。

每一个Android都拥有一个独立的Dalvik虚拟机实例。Dalvik被设计成一个设备可以同时高效地运行多个虚拟系统。Dalvik虚拟机执行(.dex)的Dalvik可执行文件，该格式文件针对小内存使用做了优化。

同时虚拟机是基于寄存器的，所有的类都经由JAVA编译器编译，然后通过SDK中的“dx”工具转化成.dex格式由虚拟机执行。

5. 安卓架构中最底层是哪个

Android系统构架是安卓系统的体系结构，android的系统架构和其操作系统一样，采用了分层的架构，共分为四层，从高到低分别是Android应用层，Android应用框架层，Android系统运行库层和Linux内核层。
Android系统构架主要应用于ARM平台，但不仅限于ARM，通过编译控制，在X86、MAC等体系结构的机器上同样可以运行。
中文名
安卓系统构架
外文名
Android systematic framework
Android系统架构分为四层架构，从高到低分别是应用层，应用框架层，系统运行层和Linux内核层。
Android系统体系结构
1.应用层
Android会同一系列核心应用程序包一起发布，该应用程序包包括email客户端，SMS短消息程序，日历，地图，浏览器，联系人管理程序等。它们一般都是使用Java进行编写。
2.应用框架层
开发人员也可以完全访问核心应用程序所使用的API框架。该应用程序的架构设计简化了组件的重用;任何一个应用程序都可以发布它的功能块并且任何其它的应用程序都可以使用其所发布的功能块(不过得遵循框架的安全性限制)。同样，该应用程序重用机制也使用户可以方便的替换程序组件。

6. 简述android应用程序结构是哪些

android应用开发框架是ApplicationFramework.其系统架构由5部分组成，分别是：LinuxKernel、AndroidRuntime、Libraries、ApplicationFramework、Applications。第二部分将详细介绍这5个部分。下面自底向上分析各层。Android架构1、LinuxKernelAndroid基于Linux2.6提供核心系统服务，例如：安全、内存管理、进程管理、网络堆栈、驱动模型。LinuxKernel也作为硬件和软件之间的抽象层，它隐藏具体硬件细节而为上层提供统一的服务。如果你学过计算机网络知道OSI/RM，就会知道分层的好处就是使用下层提供的服务而为上层提供统一的服务，屏蔽本层及以下层的差异，当本层及以下层发生了变化不会影响到上层。也就是说各层各尽其职，各层提供固定的SAP（ServiceAccessPoint），专业点可以说是高内聚、低耦合。如果你只是做应用开发，就不需要深入了解LinuxKernel层。2、AndroidRuntimeAndroid包含一个核心库的集合，提供大部分在Java编程语言核心类库中可用的功能。每一个Android应用程序是Dalvik虚拟机中的实例，运行在他们自己的进程中。Dalvik虚拟机设计成，在一个设备可以高效地运行多个虚拟机。Dalvik虚拟机可执行文件格式是.dex，dex格式是专为Dalvik设计的一种压缩格式，适合内存和处理器速度有限的系统。大多数虚拟机包括JVM都是基于栈的，而Dalvik虚拟机则是基于寄存器的。两种架构各有优劣，一般而言，基于栈的机器需要指令，而基于寄存器的机器指令更大。dx是一套工具，可以将Java.class转换成.dex格式。一个dex文件通常会有多个.class。由于dex有时必须进行最佳化，会使文件大小增加1-4倍，以ODEX结尾。Dalvik虚拟机依赖于Linux内核提供基本功能，如线程和底层内存管理。3、LibrariesAndroid包含一个C/C++库的集合，供Android系统的各个组件使用。这些功能通过Android的应用程序框架（applicationframework）暴露给开发者。下面列出一些核心库：系统C库--标准C系统库（libc）的BSD衍生，调整为基于嵌入式Linux设备媒体库--基于PacketVideo的OpenCORE。这些库支持播放和录制许多流行的音频和视频格式，以及静态图像文件，包括MPEG4、H.264、MP3、AAC、AMR、JPG、PNG界面管理--管理访问显示子系统和无缝组合多个应用程序的二维和三维图形层LibWebCore--新式的Web浏览器引擎,驱动Android浏览器和内嵌的web视图SGL--基本的2D图形引擎3D库--基于OpenGLES1.0APIs的实现。库使用硬件3D加速或包含高度优化的3D软件光栅FreeType--位图和矢量字体渲染SQLite--所有应用程序都可以使用的强大而轻量级的关系数据库引擎4、ApplicationFramework通过提供开放的开发平台，Android使开发者能够编制极其丰富和新颖的应用程序。开发者可以自由地利用设备硬件优势、访问位置信息、运行后台服务、设置闹钟、向状态栏添加通知等等，很多很多。开发者可以完全使用核心应用程序所使用的框架APIs。应用程序的体系结构旨在简化组件的重用，任何应用程序都能发布他的功能且任何其他应用程序可以使用这些功能（需要服从框架执行的安全限制）。这一机制允许用户替换组件。所有的应用程序其实是一组服务和系统，包括：视图（View）--丰富的、可扩展的视图集合，可用于构建一个应用程序。包括包括列表、网格、文本框、按钮，甚至是内嵌的网页浏览器内容提供者（ContentProviders）--使应用程序能访问其他应用程序（如通讯录）的数据，或共享自己的数据资源管理器（ResourceManager）--提供访问非代码资源，如本地化字符串、图形和布局文件通知管理器（NotificationManager）--使所有的应用程序能够在状态栏显示自定义警告活动管理器（ActivityManager）--管理应用程序生命周期,提供通用的导航回退功能5、ApplicationsAndroid装配一个核心应用程序集合，包括电子邮件客户端、SMS程序、日历、地图、浏览器、联系人和其他设置。所有应用程序都是用Java编程语言写的。更加丰富的应用程序有待我们去开发！从上面我们知道Android的架构是分层的，非常清晰，分工很明确。Android本身是一套软件堆迭(SoftwareStack)，或称为“软件迭层架构”，迭层主要分成三层：操作系统、中间件、应用程序。从上面我们也看到了开源的力量，一个个熟悉的开源软件在这里贡献了自己的一份力量。