手机Android平台的相关知识详述

《手机Android平台的相关知识详述》由会员分享，可在线阅读，更多相关《手机Android平台的相关知识详述（43页珍藏版）》请在装配图网上搜索。

1、Android是Google于11月05日宣布的基于Linux平台的开源手机操作系统的名称，该平台由操作系统、中间件、顾客界面和应用软件构成。它采用软件堆层（Software Stack，又名软件叠层）的架构，重要分为三部分。底层以Linux内核工作为基本，由C语言开发，只提供基本功能；中间层涉及函数库Library和虚拟机Virtual Machine，由C+开发。最上层是多种应用软件，涉及通话程序，短信程序等，应用软件则由各公司自行开发，以Java作为编写程序的一部分。不存在任何以往阻碍移动产业创新的专有权障碍，号称是首个为移动终端打造的真正开放和完整的移动软件。 S60，即Series

2、60。是诺基亚为Symbian系统开发的一种UI（顾客界面），S60不是手机系统，而是一种基于Symbian系统的顾客图形操作界面。Andy Rubin创立了两个手机操作系统公司：Danger和Android。Danger 5亿美元卖给微软，今年成为了Kin，Android4千万美元卖给Google。 Android是Google于11月05日宣布的基于Linux平台的开源移动操作系统的名称，该平台由操作系统、中间件、顾客界面和应用软件构成。它采用软件堆层（Software Stack，又名软件叠层）的架构，重要分为三部分。底层以Linux内核工作为基本， android系统效果图由C语言开发

3、，只提供基本功能；中间层涉及函数库Library和虚拟机Virtual Machine，由C+开发。最上层是多种应用软件，涉及通话程序，短信程序等，应用软件则由各公司自行开发，以Java作为编写程序的一部分。不存在任何以往阻碍移动产业创新的专有权障碍，号称是首个为移动终端打造的真正开放和完整的移动软件。 Google通过与软、硬件开发商、设备制造商、电信运营商等其她有 关各方结成深层次的合伙伙伴关系，但愿借助建立原则化、开放式的移动电话软件平台，在移动产业内形成一种开放式的生态系统。 Android 作为Google公司战略的重要构成部分，将进一步推动“随时随处为每个人提供信息”这一公司目的的

4、实现。全球为数众多的移动电话顾客正在使用多种基于 Android 的电话。google的目的是让（移动通讯）不依赖于设备甚至平台。出于这个目的，Android 将补充，而不会替代google长期以来奉行的移动发展战略：通过与全球各地的手机制造商和移动运营商结成合伙伙伴，开发既有用又有吸引力的移动服务，并推广这些产品。android系统特性应用程序框架 支持组件的重用与替代 Dalvik虚拟机 专门为移动设备做了优化 内部集成浏览器 该浏览器基于开源的WebKit 引擎 优化的图形库 涉及2D和3D图形库， android3D图形库基于OpenGL ES 1.0 （硬件加速可选） #SQLite

5、 用作构造化的数据存储 多媒体支持 涉及常用的音频、视频和静态印象文献格式 （如 MPEG4, H.264, MP3, AAC, AMR, JPG, PNG, GIF） GSM电话 （依赖于硬件） 蓝牙Bluetooth, EDGE, 3G, and WiFi （依赖于硬件） 照相机，GPS，指南针，和加速度计 （依赖于硬件） 丰富的开发环境 涉及设备模拟器，调试工具，内存及性能分析图表，和Eclipse集成开发环境插件android系统架构架构详解目前我们拿起手术刀来剖析各个部分。其实这部分SDK文档已经帮我们做得较好了，我们要做的就是拿来主义，然后再加上自己理解。下面自底向上分析各层。 a

6、ndroid1、Linux KernelAndroid基于Linux 2.6提供核心系统服务，例如：安全、内存管理、进程管理、网络堆栈、驱动模型。Linux Kernel也作为硬件和软件之间的抽象层，它隐藏具体硬件细节而为上层提供统一的服务。 如果你学过计算机网络懂得OSI/RM，就会懂得分层的好处就是使用下层提供的服务而为上层提供统一的服务，屏蔽本层及如下层的差别，当本层及如下层发生了变化不会影响到上层。也就是说各层各尽其职，各层提供固定的SAP（ServiceAccess Point），专业点可以说是高内聚、低耦合。 如果你只是做应用开发，就不需要进一步理解Linux Kernel层。 2

7、、Android RuntimeAndroid涉及一种核心库的集合，提供大部分在Java编程语言核心类库中可用的功能。每一种Android应用程序是Dalvik虚拟机中的实例，运营在她们自己的进程中。Dalvik虚拟机设计成，在一种设备可以高效地运营多种虚拟机。Dalvik虚拟机可执行文献格式是.dex，dex格式是专为Dalvik设计的一种压缩格式，适合内存和解决器速度有限的系统。 大多数虚拟机涉及JVM都是基于栈的，而Dalvik虚拟机则是基于寄存器的。两种架构各有优劣，一般而言，基于栈的机器需要更多指令，而基于寄存器的机器指令更大。dx 是一套工具，可以将 Java .class 转换成

8、 .dex 格式。一种dex文献一般会有多种.class。由于dex有时必须进行最佳化，会使文献大小增长1-4倍，以ODEX结尾。 Dalvik虚拟机依赖于Linux 内核提供基本功能，如线程和底层内存管理。 3、LibraryAndroid涉及一种C/C+库的集合，供Android系统的各个组件使用。这些功能通过Android的应用程序框架（application framework）暴露给开发者。下面列出某些核心库： 系统C库原则C系统库（libc）的BSD衍生，调节为基于嵌入式Linux设备 媒体库基于PacketVideo的OpenCORE。这些库支持播放和录制许多流行的音频和视频格式

9、，以及静态图像文献，涉及MPEG4、 H.264、 MP3、 AAC、 AMR、JPG、 PNG 界面管理管理访问显示子系统和无缝组合多种应用程序的二维和三维图形层 LibWebCore新式的Web浏览器引擎,驱动Android 浏览器和内嵌的web视图 SGL基本的2D图形引擎 3D库基于OpenGL ES 1.0 APIs的实现。库使用硬件3D加速或涉及高度优化的3D软件光栅 FreeType 位图和矢量字体渲染 SQLite 所有应用程序都可以使用的强大而轻量级的关系数据库引擎 4、Application Framework通过提供开放的开发平台，Android使开发者可以编制极其丰富和

10、新颖的应用程序。开发者可以自由地运用设备硬件优势、访问位置信息、运营后台服务、设立闹钟、向状态栏添加告知等等，诸多诸多。 开发者可以完全使用核心应用程序所使用的框架APIs。应用程序的体系构造旨在简化组件的重用，任何应用程序都能发布她的功能且任何其她应用程序可以使用这些功能（需要服从框架执行的安全限制）。这一机制容许顾客替代组件。 所有的应用程序其实是一组服务和系统，涉及： 视图（View）丰富的、可扩展的视图集合，可用于构建一种应用程序。涉及涉及列表、网格、文本框、按钮，甚至是内嵌的网页浏览器 内容提供者（Content Providers）使应用程序能访问其她应用程序（如通讯录）的数据，或

11、共享自己的数据 资源管理器（Resource Manager）提供访问非代码资源，如本地化字符串、图形和布局文献 告知管理器（Notification Manager）使所有的应用程序可以在状态栏显示自定义警告 活动管理器（Activity Manager）管理应用程序生命周期,提供通用的导航回退功能 5、ApplicationAndroid装配一种核心应用程序集合，涉及电子邮件客户端、SMS程序、日历、地图、浏览器、联系人和其她设立。所有应用程序都是用Java编程语言写的。更加丰富的应用程序有待我们去开发！ 从上面我们懂得Android的架构是分层的，非常清晰，分工很明确。Android自身

12、是一套软件堆叠(Software Stack)，或称为软件叠层架构，叠层重要提成三层：操作系统、中间件、应用程序。从上面我们也看到了开源的力量，一种个熟悉的开源软件在这里奉献了自己的一份力量。 进一步Android【一】 序及开篇对于Android，我也算是老人了，所谓，有文有真想。正由于这段玩票经历，使得我在毕业后，鬼使神差的成为移动平台的一名码工，再次有机会放肆的拥抱Android。开年，手上忽然有了一把闲散时间，有机会进一步总结和学习Android。于是想再一次为Android写一系列的东西，这些东西来自于某些开发经验，对源码的学习和对Android的肤浅结识，也算是鞭笞自己学习的一种手

13、段。其下所有内容，估计有十数篇，抑或更多。基本和技术有关，也许会配有某些其她有关比较闲淡的话题。也许会有某些具象实例，但更多的也许是自己的某些理解和认知。所有一切，源自于妄自挖掘，难免有疏漏或误解，观者淡定。以此为序，有心者，望共勉。Android简史人生若只初识，何事秋风悲画扇。 - 木兰辞要说当今移动平台的当红辣子鸡，Android说它是第二，也许没有别家敢认这个第一（好吧，iPhone，故意见就说.）。理解Android开发平台的过去和现状，除了往下看，另有便捷的方式就是在WikiPedia中键入Android，在这里，特此鸣谢GFW友谊放生。诞生早在7月，Google舞动着手中的美刀，

14、收下了由Andy Rubin（传说中的Android之父.）等人创立的一家小公司，她们当时做的就是基于Linux内核的手机操作系统，也就是小时候的Android。通过Google近年打磨，Android在末，正二八经的粉墨登场开门接客。自打一出生，Android便被钉板在富二代的角色上，不仅是由于老爹有钱的令人发指，也是由于其后有一帮金光闪耀的叔伯们保驾护航。这个叔伯群，便是响当当的开放手机联盟OHA（Open Handset Alliance）。这个联盟涵盖了中国移动、T-Mobile、Sprint这样的移动运营商，也涉及HTC、Motolora、三星这些的手机制造商，同步尚有以Google

15、为代表的手机软件商，以Inter、Nvidia为标志的底层硬件厂商和Astonishing Tribe这样的商业运作公司（这公司是啥我也不晓得.）。作为后援团，她们理论上的任务，是各尽其长，全力捧红Android，事实上的任务是齐心合力，借Android东风赚一种盆钵满响。固然，Android自因此被万众瞩目一炮走红，不仅仅是丫实在太有背景，同步，它也有这太多的新鲜的概念。Android是一种开源的平台（恩，真正的全面开源，是在发布后好久后来了.），它给那些捂着自家平台源码当宝的竞争对手们一记当头棒喝。Android自行研发了一套Java虚拟机，当时仅提供Java API的支持（NDK是更久后

16、来的事情了.），号称为专为高品位智能设计。Android开发环境支持所有主流操作系统平台，涉及Windows，Linux，Mac，即便到今天，在手机开发中也是极其罕见的。Android的带头人Google，自身是做网络起家，Android内嵌大量Google网络应用，听上去就显得很酷。这所有的一切，共同造就了Android那鹤立鸡群，不染风尘的少侠形象。造势推出伊始，Google尚有一种很震撼的推广举动，就是举办所谓的Android程序挑战赛（Android Developer Challenge, ADC）。整个比赛提成两场，第一场（ADC1）比赛，在没有任何真机问世，SDK还是个雏形的状况

17、下，便鸣金开锣了。比赛套路是无差别的群殴，基本概念是无论你来自何方（还是要满足美国法律规定和避嫌规定的），无论你想做些什么，也不管你是光杆司令还是流氓团伙，只要提交一种能在模拟器上跑起来的程序，就可参赛。而比赛只是对你作品进行参观评比，作品的所有权仍然放在开发者的口袋中。固然，这还不算什么创新，NB的是无比丰厚的奖金，整个ADC的奖金高达1千万美刀，每场各半，基本上首轮入围奖（前50）已经超越了那时候一般程序比赛的头名奖金，这对诸多小公司和个人而言，无疑是具有很强吸引力的。于是，各路打酱油好手蜂拥而至，各论坛、博客、网站也七嘴八舌的讨论开来，一时间，满城风雨。ADC1我也很厚颜无耻的参与了，成

18、果固然可以预想，一毛钱都没摸上。回忆整个过程，差距最大的并不是在技术上，而是认知上，我们玩的产品是人家几年前玩剩余的，说创新只是一抹笑谈。当时觉着，Google太NB了，ADC这种车马未动粮草先行的招太华丽了，就这动静，不管比出来个啥成果，这1千万刀也掏值了。但时过境迁，目前回头来想，也许一切并不是看上去那么美。由于没有扎夯实实的真机摆出来，人们普遍抱着一种玩票的心理，真的敢不顾一切舍下身家性命押宝在Android上的尽在少数，这就锻造了Android平台很长一段时间的只见雷不见雨的局面。而等喧嚣过后，诸多人热情消退，Google真端出Android真机的时候，还需要重新热场再来一次，也许，真

19、的有些得不偿失。困境所有的东西目前来说，都是事后诸葛亮，只能听个响不能当个真。而真实的状况是ADC1不久进入囧境，由于架构设计上的种种因素，Google花了比预想多的多的时间做Android的优化工作，ADC1比赛被迫不断延期，彻底沦为懒婆娘的裹脚布。各路曾热捧Android的媒体，也不失时机的倒戈，亲手在自己画上的感慨号背面，重重画上了个大大的问号。祸不单行，同样是由于Android的性能问题，虽然各路高手把Android移植到了不同的手机平台上，但传说中的GPhone始终难产中，使得人们不免有了胎死腹中的猜想。与此同步，其她对手可一点也没闲着。iPhone不久宣布开放SDK，以此来勾引纯情

20、的开发人员。Symbian被Nokia彻底收购，成为Nokia的自留地，开源筹划也不久浮出水面。所有景象，对Android而言都犹如梦魇。破茧所有一切困境，都在G1发布后，徐徐消散了。10月，第一款搭配Android平台的真机，搭载着无限光荣与梦想的HTC Dream正式发售，这就是注定要载入史册的G1。虽然比之当时绝代风华的iPhone，粗陋的G1犹如村姑遇上公主一般，但无论如何，G1让人们真真切切的看到了Android。这就犹如你家买的跳票N久的期房，终于见着了个毛胚房，那种感觉，除了踏实，找不到更适合的词汇了。好事固然也会成双，G1它不是一种人在战斗。ADC1总算是落下帷幕，Androi

21、d Market的也顺理成章的破茧而出，初期的应用，大都来自于ADC1的奉献。Android也结束了伪开源的历史路程，正式开发SDK的源码实现，搭配的是Apache的License，这种坦诚相见的感觉看上去很不错。忠心耿耿的HTC，更是再接再励，在G1后，陆续发布了Magic（G2）和Hero（G3）。特别是Hero的现身，惹得一阵小惊艳，HTC为Hero搭配的是基于Android改造UI的Sense系统，以华丽的界面风格赚足了眼球，也创了改造Android的先河。在HTC高歌猛进的同步，猫在螳螂后的一群黄雀，也敌在动我也动了。摩托罗拉，三星，LG，华为，戴尔，联想等一干手机厂商纷纷跟进，各式

22、各样的Android蜂拥而至。与此同步，其她嵌入式厂商也推陈出新，爱可视（Archos）发布了基于Android的平板设备，明基的Android上网本也是箭在弦上，而基于Android的手持电子书阅读设备也不断的被推出，庞大的Android联盟初现峥嵘。为了避免同质化，各个厂商纷纷对Android进行的改造，摩托罗拉推出了Cliq，打得是SNS整合牌，三星的新系统也是被广泛期待，而中移动的OMS丑媳妇也要见婆娘了，打着整合移动服务牌_的OMS，以丑陋的外貌、低下的SDK版本和雷死人不偿命的宣传文案（绝口不提Android，只说自己做了大量很NB的工作，其实.，哎，咋就那么小家子气呢.）也算是招

23、来大量眼球。而还是没能耐住寂寞的Google，联手HTC，一同推出了至今只为止最重量级的Android手机：Nexus One。江湖有云：天下武功，无快不破。搭载了全新的Android 2.1，1G的CPU，史上最清晰的手机屏幕的Nexus One，快的是一塌糊涂迅雷不掩耳盗铃小叮当，在单机层面，第一次使得Android手机与iPhone掰手腕的能力（之前与iPhone的比较，都需要依托集团力量，三英战吕布.）。在各家厂商努力的同步，Android自身也没有闲着，版本从1.1，一步步进阶到了2.1，SDK的升级，随着着大量性能、接口的改善，和功能的丰富，Android变得越来越快，越来越省电，

24、越来越丰富，越来越多Google服务被嵌入_。由于Android SDK是基于Java的，即便虚拟机做的很是NB，在某些状况下，性能也是无法与原生的C+代码相提并论，于是，从1.5版起，除了SDK，Android还拥有了NDK（Native Develop Kit），它提供了某些C+的库和编译环境（库是真的很少.），开发人员可以基于C+写底层库，用Java写上层逻辑，通过混编的方式，兼得鱼和熊掌。Android Market的发展也甚为迅猛，虽然和其鼻祖App Store相比，应用的规模和赚钱能力还显得比较幼齿，但其涨势凶猛，发展趋势远胜于前辈。国内某些比较出名的手机软件，也纷纷拥有了Andr

25、oid版本的小弟，例如网易有道的出品的有道词典Android版（好吧，这是在插播广告，欢迎人们进行围观并提珍贵意见.）。起飞种种迹象表白，也许就是姗姗来迟的Android元年。三星，moto，LG，HTC等多家手机制造厂商，都为将推出的半数以上的手机搭配了Android。在国内，移动的OPhone，丑媳妇要正式揭开盖头了，惨烈是惨烈了一点，但聊胜于无，除了水货，毕竟至少多了条购买Android手机的道路。软件开发方面，人们也从抱着双臂冷眼旁观的状态，进入到了一种伺机而动的战略准备阶段。前不久召开的moto开发者大会，惊现国内各领域的公司，试水开始，可见一斑。国内各个山寨的Market的，也越来

26、越货源充足，下载量稳步上升，升温，就在当下。而随着G2为首的Android水机价格火速下调，身边路边地铁边，可以看到越来越多的人，把玩着各式各样的Android手机，状况尤为喜人。因此，如果你有心，就做好准备吧。【二】 架构和学习虽贵为富二代，但Android要是没任何可圈点的地方，开但是70迈，在玲琅满目的手机平台竞争中，充其量也就做几种俯卧撑打一桶酱油，然后被落的远远的。说究竟，出来混，靠的还是技术。架构从SDK文档中，偷来一幅Android平台的架构图，如上。在整个架构最底层红彤彤的部分，是Linux Kernel在移动平台的一种移植，它隐藏了硬件、网络等有关的细节，为上层提供了一种相对

27、纯洁的统一接口。除非要做的是Android到不同设备的移植工作，否则对于大部分一般开发者而言，基本上是远观而不必亵玩的。Google始终强调，Android的底层实现异常NB，可移植性超强，暂没有功夫研读，实属遗憾。靠上一层，是某些核心的和扩展的类库，它们都是原生的C+实现。在这一层，你可以看到诸多熟悉的面孔，一如SQLite、WebKit、OpenGL，开源的力量与奉献由此可见。如果，该层类库需要被上层函数调用，就必须要通过JNI的导出相应的接口函数，否则就只能在层次内部自个把玩。也是在这一层次上，尚有为上层Java程序服务的运营时。Dalvik虚拟机，是Android的Java虚拟机，之因

28、此不采用J2ME的虚拟机，一方面是由于J2ME的设计是为了低端机器而优化，而Dalvik则是为了高品位某些的机器进行优化，提供更好的性能。另一方面，从商业角度来看，必须绕开J2ME虚拟机，Android才干彻底解放，想怎么开源就怎么开源，不再需要考虑License的问题。再往上，终于有Java出没了。一方面是框架层，这里涉及所有开发所用的SDK类库，此外尚有某些未公开接口的类库和实现，它们是整个Android平台核心机制的体现。而在最上面，就是应用层了，系统的某些应用和第三方开发的所有应用都是位于这个层次上，也许要纠结两者的差别，就是系统应用会用某些隐藏的类，而第三方的应用，总是基于SDK提供

29、的东西来搞。一般来说，Android开发，就是在SDK的基本上，吭哧吭哧用Java写应用。但自从有了NDK，一切有了写小变化。NDK的浮现意味着，最上面应用层的内容，可以穿越Java部署的框架层，直接和底层暴露出来的，或者自行开发的C+库直接对话，固然在这些库中需要涉及JNI的接口。人说，这就不是Android也可以用C+开发应用么，但其实，这样的说法不够确切，纯C+应用，是无法被接受的。由于在Android中，大量的核心机制部署在框架层，它们都是用Java实现的，例如控件库，Activity的调度之类的。因此，没了界面，没了调度，还是只用C+做类库比较合适，否则一切都乱了套了。特性基于这样的

30、架构，Android有诸多的设计显得很故意思。纵览整个SDK和核心机制的设计，工整美丽，是Android给人的第一感觉。为了阐明这一点，找一种背面教材是很有必要的，Symbian同窗毫无悬念的担当这个伟岸的角色。写Symbian程序，感觉就像是在玩一种猜谜游戏。哪怕你是一种Symbian老手，当需要用到Symbian中某块陌生功能的时候，你也许仍然束手无策。你往往需要猜并反复找寻，在这里我需要使用哪一种奇巧淫技呢，是该臆想某些事件，还是应当用一种神秘的UID寻找某个特定应用，诸如此类。而做Android应用的时候，就像是做高考模拟试题，题看上去不同样，解答模式摸清晰，就一通百通，一了百了。监听

31、某个系统事件，查一下SDK就好；访问某个应用的数据，看看它有无提供Content Provider就可以。所有的一切，都是按套路出牌，只要你理解了套路，再陌生的牌也可以看得懂，出的顺。人说武林高手，都应当是无招胜有招，而一种好的应用框架，也应当做到举重若轻，可触类旁通。而Android框架最文采飞扬的一点，就是引入了Mash-Up的思想。所谓Mash-Up，就是把写应用搞成搭积木，要出效果的时候，东家一块西家一块现场拼起来就好。这里面核心有两点，一种是模块化，另一种就是动态性。所谓模块化，就是一种应用的功能要明确的被封成一种个边界清晰的功能点，每一种功能点都像是一种黑盒，由预先定义的规则描述出

32、其交互方式；而动态性，就是这些独立的模块可以在运营的时候，按照需求描述，连接在一起，共同完毕某项更大的功能。在这两点上，Android都做得非常杰出。站在可Mash-Up构造应用这一点去看其她的某些Android中的核心功能设计，就显得很有章可循了。例如为什么要把文献私有化，为什么要让进程被托管，等等（固然也可以站在别的角度看出不同的效果，视角不同，视野自然不同.）。在UI机制方面，Android也有很不错的体现。它采用xml格式的资源文献，描述所有界面有关的内容。资源文献不是什么新东西了，xml格式也是老调重弹，但可贵的是Android做的更为的丰富和彻底，基本把界面有关的逻辑，所有从代码中

33、剥离到了资源文献中，和Symbian那四不像的资源文献相比，真是强大了不知多少倍了。Android学习入门不积跬步，无以至千里。 - 劝学说，万事开头难。想开始Android的开发，最重要的应当是先把马步扎稳，套路摸清晰，背面的事情就顺当多了。打开怀抱，拥抱Android，也许可以先做下面这些事。开发环境辣手摧花成性的GFW，无情的把Android开发者官网关在了墙外。但是没关系，猛击这里，同样可以殊途同归（Shit，始终在用代理，刚试了下，发现居然也被盾了，如果不行，那就只能翻墙了.）。如果旅途顺利，你可以在途径sdk/index.html下找到安装阐明，成功配备好Android的开发环境（

34、【注】：在后来，如果要给开发者页面上的链接，都会给一种像sdk/index.html这样的相对途径，你可以在前面加上官网地址，或者本地SDK的doc地址拼凑成完整的途径，在一种盾牌横行的朝代，只能用这样委屈求全的措施保证能更好的使用.）。在2.0之前，每一次版本更新，你都要自己去下个全新的SDK，然后按照阐明，小心翼翼的一步步修改eclipse的设立，甚是麻烦。在2.0后，这个模式有所改善，你会先下到一种类似于下载器的插件，通过它可以来管理和升级SDK，不仅简化了整个升级模式，还使得你可以更好的在各个不同的SDK版本间游走，利国利民。Eclipse + ADT（Android Developm

35、ent Tool），是正牌的Android开发环境。你可以在Windows，Linux，Mac下做开发，甚为自由。比之Symbian的开发环境，ADT显得尤为强大，它对SDK提供的一堆优秀的命令行工具进行了UI上的封装，提供了图形界面（命令行控固然同样幸福，具体参见：guide/developing/tools/index.html）。通过ADT，你可以用运营和管理模拟器，使用调试器进行调试，过滤和查看Log，浏览模拟器上的文献信息，模拟拨号、短信等手机才有的事件，等等。文档我懂得，有诸多人在学习一种新平台开发的时候，都习惯去买某些xxx 21天精通之类的书籍。但其实，最佳的入门学习资料，就是

36、SDK文档。由于只有做平台的自己，才干最理解平台中的各个玄机，各方面的轻重缓急，从而可以更好的对症下药药到病除。在Android的SDK中，guide/index.html是由浅入深的教学文档，reference/packages.html是原则的API文档。对于教学文档，我的意见是，一字不拉的通读一遍甚至多遍，至少做到能对Android摸着头脑，并且遇到问题的时候，可以迅速想起在哪里可以找到，回来深刻阅读。而API文档方面，Android做的算是还不错了。基本上每个类，每个接口，均有原则而详尽的阐明，在某些尤为重要的类中，还具有大量的学习性的内容，不和Symbian似的，有太多的太监类，只有

37、光秃秃的一种函数，一行文档阐明都没有。整个文档构造是按照Java包来组织的，自身Java包命名的构造性和可读性很强，找起来也颇为以便。诸多人对SDK文档有抵触情绪，我想，有两方面的因素。一则是SDK文档普遍缺少文学性，麻木不仁的八股文，难如下咽。Android在这方面做得算是乏善可陈，虽然算不上文采华丽，但还是挺适合阅读的。另一则，就会是语言方面的因素了。SDK文档多为英语，偶尔像MSDN这样有中文的，也停留在机器翻译的水平上，阅读起来颇为难受。特地在网上搜了下，找到某些翻译SDK的中文文档，例如这里。虽然是基于1.5 r1版本SDK所著，稍显过时，但翻译的还是有小用心的，作为辅助，也不失为一

38、份好资料，特代表广大看官向这些为人民福利着想的同志致敬。Tutorials光说不练假把式，除了读，在入门阶段，写也是一项不能少的运动。同样是在SDK中，Android提供了一组Tutorials和某些列的Samples，详见：resources/index.html。Tutorials很简朴，Hello World只是在教你如何在eclipse中，在ADT的协助下，创立一种Android项目。相比之下，Hello Views复杂了些，它集中展示了几种原则的Android Layout 样式是如何构建的，诸多时候，你都是在这些样式下扩展所需的UI。Hello Localization，是教你如何

39、使用资源的，做完这个，就可以理解Android的资源有多杀。最后收官的是一种更为完整的Notepad Tutorial，它展示了诸多Android的核心机制，例如基于Intent的Activity整合，Activity的生命周期等。迈过这个Tutorial，欢迎你，进入Android的大门。固然，做完Tutorials，对于Android而言，只是管中窥豹略见一斑。在SDK中，还提供了一系列的Samples。可以根据自己的需求，挑选合适的Sample编译运营和学习。但其中，有一种是不管你做什么，都需要必看必读必熟悉的，就是API Demos。在这个Sample中，集中展示了Android重点功

40、能的API使用，把这个Sample用熟悉，需要做什么的时候过去找一下就可以不久的入手了。源码到这里，诸多看官一定很不屑，前面所谓的学习入门简介，只但是是围着SDK打转。其实，事实也是如此，SDK中涉及的内容是真的非常重要，我只是盼望通过某些简短的简介，激起某些初学者的注重，如是而已。固然，SDK每一种平台均有，没什么稀罕的。但Android有另一种非常稀罕而值钱的看家法宝，就是源代码。从Android Source的主站上：对于大部分开发者均有学习价值的源码，重要在源码的frameworks和packages目录下。前者涉及的是平台核心的某些实现，例如你需要自定义一种控件，也许你就可以翻到一种

41、系统控件的实现中去，看看它是怎么来做的。后者涉及某些系统的应用实现，例如你想做个播放器，也许你可以先去参照参照系统自带的是具体怎么做的。这样的实现，即便不算是最华美，至少也是最原则，其价值不容小视。此外，你也可以把它当个代码库来使，不会使用某个类，grep一把，也许就能获得一份最美丽的Sample。固然，如果你有时候对某些系统机制表达费解，抑或有某些bug不懂得源头在哪，都可以跟着源码顺藤摸瓜的弄清晰。这样的好东西，可不是每个平台都可以享用的。其她论坛，其实对于开发和学习都是很重要的资源。毕竟，所有的资料都是死的，只有人是活得，可以最大限度的因地制宜解决问题。只但是，原则的官方论坛，放在Goo

42、gle Group上，已经惆怅的被盾了。中文论坛方面，没有特别优秀和活跃的，这一方面是由于Android的发呈现状还不算很磅礴，另一方面是由于Android的开发相对于Symbian而言，奇技淫巧少了诸多，没有那么多好问的。也许你可以去去csdn这样的老式论坛，或者eoe这样专门的论坛。有的时候，还是多少能获得某些协助的。书籍方面，真没有什么推荐，豆瓣上搜索一下，你可以看到，目前的书籍，基本上还是集中在SDK使用层面上，很少有解析的很透彻，做的很进一步的。而SDK的使用，看SDK的文档就足够了，如果实在对e文不感冒，买一两本评价不太差的中文书籍，放着翻翻也还是挺好。更进一步，也许可以读读某些经

43、验性的文档，去Google Code上搜索某些代码回来看看。例如，SDK文档中，有个经验性文档的集合：resources/articles/index.html，就可以翻看一下。最后，更多的一切还需要自己在工程和思考中，慢慢总结。相信，好的代码，会垂青一种勤于动手和思考的人。【三】 组件入门组件（Component），在谈及所谓架构和重用的时候，是一种重要的事情。诸多时候都会说基于组件的软件架构，指的是盼望把程序做乐高似的，有一堆接口原则封装完整的组件放在哪里，想用的时候取上几种一搭配，整个程序就构建完毕了。在开篇的时候就在说，Android是一种为组件化而搭建的平台，它引入所谓Mash-Up

44、的概念，这使得你在应用的最上层，想做的不组件化都是很困难的一件事情（底层逻辑，好吧，管不了.）。具体说来，Android有四大组件四喜丸子：Activity、Service、Broadcast Receiver、Content Provider。Activity做一种完整的Android程序，不想用到Activity，真的是比较困难的一件事情，除非是想做绿叶想疯了。由于Activity是Android程序与顾客交互的窗口，在我看来，从这个层面的视角来看，Android的Activity特像网站的页面。一方面，一种网站，如果一张页面都没有，那.，真是一颗奇葩。而一张页面往往均有个独立的主题和功能

45、点，例如登录页面，注册页面，管理页面，如是。在每个页面里面，会放某些链接，已实现功能点的串联，有的链接点了，刷，跑到同一站点的另一种页面去了；有的链接点了，啾，也许跳到其她网站的页面去；尚有的链接点了，恩.，这次没跑，但目前页面的样子也许有所变化了。这些模式，和Activity给人的感觉很像，只但是实现方略不同罢了，毕竟Android这套架构的核心思想，自身就来自源于Web的Mash-Up概念，视为页面的客户端化，也未尝不可。Activity，在四大组件中，无疑是最复杂的，这年头，同样东西和界面挂上了勾，都简化不了，想一想，独立做一种应用有多少时间沦落在了界面上，就能揣摩清晰了。从视觉效果来看

46、，一种Activity占据目前的窗口，响应所有窗口事件，具有有控件，菜单等界面元素。从内部逻辑来看，Activity需要为了保持各个界面状态，需要做诸多持久化的事情，还需要妥善管理生命周期，和某些转跳逻辑。对于开发者而言，就需要派生一种Activity的子类，然后埋头苦干上述事情。对于Activity的更多细节，先可以参见：reference/android/app/Activity.html。后续，会献上更为详尽的剖析。Service服务，从最直白的视角来看，就是剥离了界面的Activity，它们在诸多Android的概念方面比较接近，都是封装有一种完整的功能逻辑实现，只但是Service不

47、抛头露脸，只是默默无声的做坚实的后盾。但其实，换个角度来看，Android中的服务，和我们一般说的Windows服务，Web的后台服务又有某些相近，它们一般都是后台长时间运营，接受上层指令，完毕有关事务的模块。用运营模式来看，Activity是跳，从一种跳到一种，呃.，这有点像模态对话框（或者还像web页面好了.），给一种输入（抑或没有.），然后不管不顾的让它运营，离开时返回输出（同抑或没有.）。而Service不是，它是等，等着上层连接上它，然后产生一段持久而缠绵的通信，这就像一种用了Ajax页面，看着没啥变化，偷偷摸摸的和Service不知眉来眼去多少回了。但和一般的Service还是有所

48、不同，Android的Service和所有四大组件同样，其进程模型都是可以配备的，调用方和发布方都可以有权利来选择是把这个组件运营在同一种进程下，还是不同的进程下。这句话，可以拿把指甲刀刻进脑海中去，它凸显了Android的运营特性。如果一种Service，是有盼望运营在于调用方不同进程的时候，就需要运用Android提供的RPC机制，为其部署一套进程间通信的方略。Android的RPC实现，如上图所示（好吧，也是从SDK中拿来主义的.），无甚稀奇，基于代理模式的一种实现，在调用端和服务端都去生成一种代理类，做某些序列化和反序列化的事情，使得调用端和服务器端都可以像调用一种本地接口同样使用RP

49、C接口。Android中用来做数据序列化的类是Parcel，参见：/reference/android/os/Parcel.html，封装了序列化的细节，向外提供了足够对象化的访问接口，Android号称实现非常高效。尚有就是AIDL (Android Interface Definition Language) ，一种接口定义的语言，服务的RPC接口，可以用AIDL来描述，这样，ADT就可以协助你自动生成一整套的代理模式需要用到的类，都是想起来很乏力写起来很苦力的那种。更多内容，可以再看看：guide/developing/tools/aidl.html，如果有兴致，可以找些其她PRC实现的

50、资料lou几眼。有关Service的实现，还强推参看API Demos这个Sample里面的RemoteService实现。它完整的展示了实现一种Service需要做的事情：那就是定义好需要接受的Intent，提供同步或异步的接口，在上层绑定了它后，通过这些接口（诸多时候都是RPC的.）进行通信。在RPC接口中使用的数据、回调接口对象，如果不是原则的系统实现（系统可序列化的），则需要自定义aidl，所有一切，在这个Sample里均有体现，强荐。Service从实现角度看，最特别的就是这些RPC的实现了，其她内容，都会接近于Activity的某些实现，也许不再会详述了。Broadcast Rec

51、eiver在实际应用中，我们常需要等，等待系统抑或其她应用发出一道指令，为自己的应用擦亮明灯指明方向。而这种等待，在诸多的平台上，都会需要付出不小的代价。例如，在Symbian中，你要等待一种来电消息，显示归属地之类的，必须让自己的应用忍辱负重偷偷摸摸的开机启动，消隐图标隐藏任务项，潜伏在后台，监控着有关事件，等待转瞬即逝的出手机会。这是一件很发指的事情，不仅白白耗费了系统资源，还留了个流氓软件的骂名，这真是卖力不讨好的正面典型。在Android中，充足考虑了广泛的此类需求，于是就有了Broadcast Receiver这样的一种组件。每个Broadcast Receiver都可以接受一种或若

52、干种Intent作为触发事件（有不懂得Intent的么，背面会懂得了.），当发生这样事件的时候，系统会负责唤醒或传递消息到该Broadcast Receiver，任其处置。在此之前和这后来，Broadcast Receiver与否在运营都变得不重要了，及其绿色环保。这个实现机制，显然是基于一种注册方式的，Broadcast Receiver将其特性描述并注册在系统中，根据注册时机，可以分为两类，被我冠名为冷热插拔。所谓冷插拔，就是Broadcast Receiver的有关信息写在配备文献中（求配备文献详情？稍安，后续奉上.），系统会负责在有关事件发生的时候及时告知到该Broadcast Rec

53、eiver，这种模式适合于这样的场景。某事件方式 - 告知Broadcast - 启动有关解决应用。例如，监听来电、邮件、短信之类的，都从属于这种模式。而热插拔，顾名思义，插拔这样的事情，都是由应用自己来解决的，一般是在OnResume事件中通过registerReceiver进行注册，在OnPause等事件中反注册，通过这种方式使其可以在运营期间保持对有关事件的关注。例如，一款优秀的词典软件（例如，有道词典.），也许会有在运营期间关注网络状况变化的需求，使其可以在有便宜网络的时候优先使用网络查询词汇，在其她状况下，一方面通过本地词库来查词，从而兼顾腰包和体验，一举两得一石二鸟一箭双雕（注，真

54、实在有道词典中有这样的能力，但不是通过Broadcast Receiver实现的，仅觉得例.）。而这样的监听，只需要在其工作状态下保持就好，不运营的时候，管你是天大的网路变化，与我何干。其模式可以归结为：启动应用 - 监听事件 - 发生时进行解决。除了接受消息的一方有多种模式，发送者也有很重要的选择权。一般，发送这有两类，一种就是系统自身，我们称之为系统Broadcast消息，在reference/android/content/Intent.html的Standard Broadcast Actions，可以求到有关消息的详情。除了系统，自定义的应用可以放出Broadcast消息，通过的接口

55、可以是Context.sendBroadcast，抑或是Context.sendOrderedBroadcast。前者发出的称为Normal broadcast，所有关注该消息的Receiver，均有机会获得并进行解决；后者放出的称作Ordered broadcasts，顾名思义，接受者需要按资排辈，排在背面的只能吃前面吃剩余的，前面的心情不好私吞了，背面的只能喝西北风了。当Broadcast Receiver接受到有关的消息，它们一般做某些简朴的解决，然后转化称为一条Notification，一次振铃，一次震动，抑或是启动一种Activity进行进一步的交互和解决。因此，虽然Broadcas

56、t整个逻辑不复杂，却是足够有用和好用，它统一了Android的事件广播模型，让诸多平台都相形见绌了。更多Broadcast Receiver有关内容，参见：/reference/android/content/BroadcastReceiver.html。Content ProviderContent Provider，听着就和数据有关，没错，这就是Android提供的第三方应用数据的访问方案。在Android中，对数据的保护是很严密的，除了放在SD卡中的数据，一种应用所持有的数据库、文献、等等内容，都是不容许其她直接访问的，但有时候，沟通是必要的，不仅对第三方很重要，相应用自己也很重要。例如

57、，一种联系人管理的应用。如果不容许第三方的应用对其联系人数据库进行增删该查，整个应用就失去了可扩展力，必将被其她应用抛弃，然后另立门户，自个玩自个的去了。Andorid固然不会真的把每个应用都做成一座孤岛，它为所有应用都准备了一扇窗，这就是Content Provider。应用想对外提供的数据，可以通过派生ContentProvider类，封装成一枚Content Provider，每个Content Provider都用一种uri作为独立的标记，形如：content:/com.xxxxx。所有东西看着像REST的样子，但事实上，它比REST更为灵活。和REST类似，uri也可以有两种类型，一

58、种是带id的，另一种是列表的，但实现者不需要按照这个模式来做，给你id的uri你也可以返回列表类型的数据，只要调用者明白，就无妨，不用苛求所谓的REST。此外，Content Provider不和REST同样只有uri可用，还可以接受Projection，Selection，OrderBy等参数，这样，就可以像数据库那样进行投影，选择和排序。查询到的成果，以Cursor（参见：reference/android/database/Cursor.html ）的形式进行返回，调用者可以移动Cursor来访问各列的数据。Content Provider屏蔽了内部数据的存储细节，向外提供了上述统一的接

59、口模型，这样的抽象层次，大大简化了上层应用的书写，也对数据的整合提供了更以便的途径。Content Provider内部，常用数据库来实现，Android提供了强大的Sqlite支持，但诸多时候，你也可以封装文献或其她混合的数据。在Android中，ContentResolver是用来发起Content Provider的定位和访问的。但是它仅提供了同步访问的Content Provider的接口。但一般，Content Provider需要访问的也许是数据库等大数据源，效率上局限性够快，会导致调用线程的拥塞。因此Android提供了一种AsyncQueryHandler（参见：referen

60、ce/android/content/AsyncQueryHandler.html），协助进行异步访问Content Provider。在各大组件中，Service和Content Provider都是那种需要持续访问的。Service如果是一种耗时的场景，往往会提供异步访问的接口，而Content Provider不管效率如何，都提供的是商定的同步访问接口。我想这遵循的就是场景导向设计的原则，由于Content Provider仅是提供数据访问的，它不能确信具体的使用场景如何，会如何使用它的数据；而相比之下，Service涉及的逻辑更复杂更完整，可以抉择大部分时候使用某接口的场景，从而拟定最

61、贴切的接口是同步还是异步，简化了上层调用的逻辑。配备四大组件说完了，四大组件幕后的英雄也该出场了，那就是每个应用都会有一份的配备文献，名称是AndroidManifest.xml，在工程的根目录下。在这个配备文献中，不仅会描述某些应用有关的信息，很重要的，会涉及一种应用中所有组件的信息。如果你派生Activity或者Service实现了一种有关的类，这只是把它组件化的第一步，你需要把这个类的有关信息写到配备文献中，它才会作为一种组件被应用到，否则只能默默无闻的黯淡度过余生。摆了一幅图出来，这次不是偷来的，是敝帚自珍原创，因此没故意外的画的很丑，但基本还是可以体现出某些意思。在In Others

62、的部分，这里是一般平台应用之间通信和交互的模型，每个应用均有很强烈的应用边界（往往体现为进程边界.），App 1的还是App 2的，分得很是清晰。每个应用内部，均有自己的逻辑去切分功能组件，这样的切分一般没有什么原则，率性而为。应用间的交互逻辑也比较零散，App 1与App 2交互，往往需要明确懂得对方应用的具体信息，例如进程ID，进程名称之类的，这样使得应用和应用之间的联系，变得很生硬。而上层应用和系统应用的通信，往往有诸多特定的模式，这种模式，很也许是无法直接应用在一般应用之间的，换而言之，系统应用是有一定特殊性的。重点，在图的下半部，描述的是Android的应用情形。在Android中，

63、应用的边界，在组件这个层面，是极度模糊，什么进程、什么应用，都可以不必感知到。举个例子，App 1，实现了A和B两个组件，App 2，实现了C这个组件。A和C，都想使用B这个组件，那么它们的使用方式是完全一致的，都需要通过系统核心的组件辨认和通信机制，找到和使用组件B。A，虽说和B是一种娘胎里蹦出来的，很不好意思，没有任何特殊的背面和捷径，还是要跑规矩的途径才干用到，一片和谐社会的景象油然而生。在Android中，所有组件的辨认和消息传递逻辑都必须依赖底层核心来进行（通信可以没有底层核心的参与，例如一旦Service找到了，就可以和它产生持久的通信.），没有底层核心的牵线搭桥，任何两个组件都无

64、法产生联系。例如一种Activity，跳到另一种Activity，必须要向底层核心发起一种Intent，有底层解析并承认后，会找到另一种Activity，把有关消息和数据传给它。一种Activity想使用Content Provider中的数据，必须通过底层核心解析有关的uri，定位到这个Content Provider，把参数传递给它，然后返回Activity需要的Cursor。这样的设计，保证了底层核心对所有组件的绝对掌控权和认知权，使得搭积木似的开发变成也许。为了，使得核心系统可以完整的掌握每个组件的信息，这就需要配备文献了。配备文献，就是将组件插究竟层核心上的这个插头。只有通过这个插头插在底层核心的插座上（不要乱想，非十八禁.