推荐第1篇：Android开发工程师学习路线
Android开发工程师学习路线：手机产品开发要从基础开发知识做起
Android开发工程师学习路线图：想要做好手机产品开发要先从基础开发知识做起，要学好基础语言开发，即java语言开发，然后逐步提升自身的产品路线，将制作产品的每一步都进行完整的规划，并且将每一步要实现的功能做好设计。掌握基础开发知识，能够很好地掌握java语言的内涵，然后通过这一语言来实现程序框架中每一步的功能，并且将程序框架中的每一步都进行完善的规划，避免出现这样或那样的问题，在设计程序过程中也要掌握各种各样的算法。
千锋教育是Android培训行业领导者，千锋教育的Android开发基础班是从java开始指导学员学起，掌握了java语言，然后进行整体的产品规划。通过程序来实现产品设计中的每一步作用。很多Android开发人才都在后续工作上引入UI设计思想，把UI理念融入到产品设计中去，并且提升自身的学习模式，通过程序整体实现产品的性能。决定一个好的产品，程序员的学习质量非常重要，只有提升学习质量，把在开发过程中遇到的问题进行解决才是最根本的。千锋教育Android培训课程模块化，指导学员学习完阶段性课程，指导学员完成自己的产品，让学员在开发过程中遇到的问题进行解决。
Android开发学习过程中要掌握好基础知识，特别是java语言的应用，然后逐步提升学员在学习过程中遇到的一些细致化的问题，把一些难点进行解决，在开发过程中把容易出现的一些难点进行合理化控制，避免在程序生成产品后出现问题，从而导致崩溃，这是非常重要的一点。
推荐第2篇：Android工程师相关职位要求
Android软件开发工程师
职位描述：
Android手机应用软件设计；
Android手机应用软件开发；
Android手机软件功能测试与验证；
任职要求：
掌握Android平台应用软件开发技术；
熟悉Adodb AIR编程技术者优先考虑；
熟悉c++/Java编程技术；
掌握Android系统网络编程能力；
Android系统软件开发一年以上工作经验者优先考虑;
工作积极、认真、刻苦，具有良好的团队合作精神。
Android开发工程师
岗位职责：
1、Android智能手机平台应用软件的分析、设计、编码和测试
2、智能手机应用相关的技术研究
3、从事与商品化相关的技术支持
任职资格：
1、计算机、通信、电子等相关专业本科以上学历，一年以上工作经验
2、熟悉Linux操作系统
3、具有J2ME或Java开发经验，熟悉ANDROID手机软件架构，熟悉Android平台MMI软件开发
4、了解基本软件开发流程，了解Clear Case/Clear Quest/UML等开发工具
5、具有良好的英文文档编写能力
符合以下条件者优先：
- 有智能手机开发经验者优先
- 有Linux手机平台开发经验者优先
1、计算机相关专业毕业。
2、两年以上嵌入式系统开发经验，一年以上的ANDROID手机平台经验。
3、要求熟悉ANDROID手机软件架构，精通ANDROID平台MMI软件开发，能独立进行应用程序开发和移植。
4、要求熟悉基本无线协议（如：GSM/GPRS/CDMA和SDL）。
5、喜欢挑战高难度项目。
6、有较好的学习能力、沟通能力，能承受一定的工作压力。
7、具备良好合作态度及团队精神，并富有工作激情、创新力和责任感。
Android手机游戏开发工程师
主要职责： 1.对游戏有高度热忱，工作态度积极，重视团队合作与沟通。
2.系统学习过软件开发，熟悉J2ME/J2SE程序设计，Java编程基础扎实
3.对数据结构、图形学、游戏算法有一定心得
4.对C / C++有良好的教育背景和了解
5.精通基于Android SDK的应用程序开发，能独立进行各种应用程序开发和移植。
6.有一年以上手机游戏开发经验。
6.思维敏捷，逻辑清楚，学习能力强
7.本科计算机软件相关专业优先考虑；有完整手机游戏开发经历者优先考虑；有Android游戏移植经验者优先
Android测试工程师(联想研究院手机&平板电脑移动设备测试) 岗位职责：
1、能制定，编写测试计划，用例，执行测试并根据测试结果撰写测试报告
2、熟练使用缺陷管理工具bugzilla提交并跟踪管理bug
3、搭建测试环境，能设计各种业务场景并做测试分析
4、能在测试过程中不断改进测试方法，提高测试质量
岗位要求：
1、专科以上学历，计算机相关专业，大学英语4级及以上者可优先考虑
2、1年以上软件测试经验, 有Android测试经验优先考虑
3、熟悉脚本语言、C语言开发、linux操作系统
4、熟悉Android下应用程序开发
5、熟悉软件工程及测试理论，熟练掌握软件测试各项技术。
6、了解智能手机(或类似嵌入式设备)的测试方法、能根据测试规范对bug有较为准确的定义
7、有较强的逻辑思维能力，具备良好的分析总结问题能力和沟通能力
8、工作认真负责、耐心细致，积极肯干，能吃苦，具有团队意识
学好英语！
1) Android Framework Engineer
Responsibilities:
Candidates are part of the Android Application and Framework team responsible for the software development and testing of Android Smartphone framework.Candidates are expected to have in depth understanding of Android Application Framework development using Java and/or Android Native Layer development using C/C++ (system libraries with JNI)
Design and development on Android middleware framework
Work closely with application developers to ensure that the frameworks/libraries created are robust and completeIntegrate and optimize third party software modules on Android framework
Tailor and port the Android platform to designated hardware
Qualifications:
Bachelor’s degree or above in Computer Science, Information Engineering or equivalentHighly proficient with C/C++ or Java programming skills
Strong capability in OOA/OOD, UML and Design Patterns
Be familiar with with Android middleware frameworks (“libraries”) development or with Android UI Layout, Database, Multi-Thread, Activity, Service, JNI, etc.
Solid knowledge on one Mobile Phone Platform (Linux/NXP/MTK/Symbian/WinCE/Android, etc)Experience on Embedded Linux programming
Quick learner and good team player
Proactive to take responsibilities and initiatives
Self-motivated and result driven with strong problem solving skills
Good Communication skills in English and Mandarin
2) Android Application Developer
Responsibilities:
Analyze and fix iues reported by verification team or operators and job title
Develop new features in Android application layer
Requirements:
More than 1 year Embedded SW experience, especially Telephony related application development using Java or
C++ language.
Experiences on Android application SW level debugging skills are highly preferred.Strong English communication skills are highly preferred.
Open, Honest and Proactive.Paionate to succe.Like to share experiences and knowledge.Like challenges, can work under high preure.
At least Bachelor degree.
推荐第3篇：产品包装开发工程师岗位职责
1.开发和设计产品的包装，保障产品能够按期上市。2.根据生产的实际需要，为产品生产提供技术支援服务，解决生产中出现的技术问题。3.完成产品包装材料的环保改良项目，以降低包装材料的采购成本。
推荐第4篇：微码开发工程师岗位职责
1.根据系统设计方案，进行网络处理器微码开发。2.负责微码的编程、单元测试及集成测试。3.参与相关设计方案和代码的评审。4.负责微码的维护、完善及升级。
推荐第5篇：开发设计工程师岗位职责
1.负责电动车整车造型设计。2.负责车架建模。3.负责电动车结构设计。4.负责为制造生产环节提供完备的设计图。
推荐第6篇：PHP开发工程师岗位职责
1.负责PHP相关产品模块开发工作。2.负责公司业务系统开发、单元测试、系统对接工作。3.负责公司已有网络管理系统的二次开发。4.负责相关系统的设计与编码工作。5.负责研发产品技术文稍的编写工作。
推荐第7篇：资料开发工程师岗位职责
通过参与产品研发的全过程如设计、开发、测试、开局等熟悉产品，基于IPD、CMM开发流程，采用国际信息开发的最新标准和工具，开发产品的安装、操作、维护手册等各类面向客户的技术资料和联机帮助。
推荐第8篇：逻辑开发工程师岗位职责
1.从事逻辑代码编写、方案设计与测试。2.从事逻辑设计验证、验证语言工具开发与应用。3.从事逻辑技术的研究分析、开发与应用。
推荐第9篇：模具开发工程师岗位职责
负责跟踪整个项目的进程，确保整个项目中的模具能够及时、合格地移交生产部。1.确保模具部门得到正确的客户信息。2.负责项目前期的产品失效分析和组织各加工部门进行评估、确认。3.负责解决模具加工中出现的紧急情况，及时准确地制定修模方案并确保完成。确保整个项目按照项目进度计划按时完成工作。4.负责产品的ECN全程跟踪，确保及时有效地完成。5.确保模具在计划时间内顺利转模、关模到工厂。6.协助生产工厂共同解决生产中的模具问题，确保生产顺利。7.确保与项目相关的机密信息得到有效的管控。8.确保客户及上级经理及时得到项目相关状态的报告。9.遵守本公司的环境文件和规定，维持工作环境的整洁。
推荐第10篇：产品开发工程师岗位职责
1.负责按国家、行业规范要求开发新产品，按公司交给的开发任务安排工作进度。2.负责按规定要求编制计划投产的配方及生产工艺，生产工艺编写控制点明确，表述清楚，符合大生产条件。3.负责由自己开发配方的试生产，直到稳定正常生产，协助完成成品生产工艺文件编制。4.负责处理生产中有关产品的异常情况，负责与配方有关的原料检验中出现不合格的最终确认。5.负责及时提供配方相关的采购技术资料、原料检验标准、检验方法、产品内控标准。6.负责在试生产过程中对配料工人的技术培训。
第11篇：安全产品开发工程师岗位职责
1.负责安全服务产品的开发、包装等工作。2.负责根据市场需求情况和网通自身的优势，研究、开发、组织包装相关的安全产品和服务。3.负责制定相应产品的技术规范和产品说明书、相关流程和管理制度。4.负责产品和服务方面的技术支持、行业推广、销售培训等工作。
第12篇：微码开发工程师岗位职责
1.根据系统设计方案，进行网络处理器微码开发。2.负责微码的编程、单元测试及集成测试。3.参与相关设计方案和代码的评审。4.负责微码的维护、完善及升级。
第13篇：android 开发心得
即 使你的应用程序是快速且响应灵敏的，但一些设计仍然会给用户造成问题——与其它应用程序或对话框未事先计划的交互，意外的数据丢失，意料之外的阻塞等等。 避免这些问题，有助于理解应用程序运行的上下文和系统的交互过程，而这些又正影响着你的应用程序。简而言之，你应该竭尽全力去开发一个与系统和其它应用程 序流畅交互的应用程序。
一 个常见的流畅问题是，一个应用程序的后台处理——例如，一个 Service或者
BroadcastReceiver——弹出一个对话框来响应一些事件。这可能看起来没啥大碍，尤其是你在模拟器上单独地构建和测试你 的应用程序的时候。然而，当你的应用程序运行在真机上时，有可能你的应用程序在没有获得用户焦点时后台处理显示了一个对话框。因此，可能会出现在活跃的应 用程序后方显示了你的应用程序的对话框，或者从当前应用程序夺取焦点显示了一个对话框，而不管当前用户正在做什么（例如，正在打电话）。那种行为，对应用 程序或用户来说，就不应该出现。
为了避免这些问题，你的应用程序应该使用合适的系统资源来通知用户——Notification类。使用Notification，你的应用程序可以在状态栏显示一个 icon来通知用户已经发生的事情，而不是夺取焦点和打断用户。
另 一个流畅问题的例子是未能正确实现Activity的 onPause()和其它生命周期方法而造成意外丢失了状态或用户数据。又或者，如果你的应用程序想暴露数据给其它应用程序使用，你应该通过 ContentProvider来暴露，而不是（举例）通过一个可读的原始文件或数据库来实现。
这 些例子的共同点是它们都应该与系统和其它应用程序协作好。Android系统设计时，就把应用程序看作是一堆松散耦合的组件，而不是一堆黑盒代码。作为开 发者来说，允许我们把整个系统看作是更大的组件集合。这有益于我们可以与其它应用程序进行清晰无缝的集成，因此，作为回报，我们应该更好的设计我们的代 码。
下面将讨论常见的流畅问题以及如何避免它们：
一 定要记住Android是一个移动平台。可以显而易见地说，其它Activity（例如，“Incoming Phone Call”应用程序）可能会在任何时候弹出来遮盖你的Activity，记住这个事实很重要。因为这个过程将触发 onSaveInstanceState()和 onPause()方法，并可能导致你的应用程序
被杀死。
如 果用户在你的应用程序中正在编辑数据时，其它 Activity出现了，这时，你的应用程序被杀死时可能丢失那些数据。当然了，除非你事先保存了正在进行的工作。“Android方式”是这样做的：能 接收和编辑用户输入的 Android应用程序应该重写 onSaveInstanceState()方法，并以恰当的方式保存它们的状态。当用户重新访问应用程序时，她能得到她的数据。进行这种处理方式最经典的例子是 mail应用程序。如果用户正在输入 email，这时其它 Activity启动了，mail应用程序应该把正在编辑的email以草稿的方式保存起来。
如果你不想穿着内衣在大街上溜达的话，你的数据也不应该这样。尽管可能存在暴露应用程序的某种形式给其它应用程序，但这通常不是最好的主意。暴露原始数据，要求其它应用程序能够理解你的数据的格式；如果你变更了格式，那么，你将破坏那些没有进行同步更新的应用程序。
“Android 方式”是创建一个 ContentProvider，以一种清晰的、深思熟虑的和可维护的API方式暴露你的数据给其它应用程序。使用 ContentProvider，就好像是插入Java接口来分离和组装两片高耦合的代码。这意味着你可以修改数据的内部格式，而不用修改由 ContentProvider暴露的接口，这样，也不会影响其它应用程序。
如果用户正在运行一个应用程序（例如，Phone程序），断定对用户操作的目的才是安全的。这也就是为什么必须避免创建Activity，而是直接在当前的 Activity中响应用户的输入。那 就是说，不要在 BroadcastReceiver或在后台运行的 Service中调用 callActivity()。这么做会中断当前运行的应用程序，并导致用户恼怒。也许更糟糕的是，你的 Activity可能成为“按键强盗”，窃取了用户要提供给前一个 Activity的输入。视乎你的应用程序所做的事情，这可能是个坏消息。
不 选择在后台直接创建 Activity UI，取而代之的是，应该使用NotificationManager来设置 Notification。它们会出现在状态栏，并且用户可以在他空闲的时候点击它们，来查看你
的应用程序向他显示了什么。（注意，如果你的 Activity已经在前台了，以上将不适用：这时，对于用户的输入，用户期望的是看到下一个 Activity来响应）
如果你的应用程序需要执行一些昂贵或耗时的计算的话，你应该尽可能地将它挪到线程里。这将阻止向用户显示可怕的“Application Not Responding”对话框，如果不这样做，最终的结果会导致你的应用程序完全终止。
一 般情况下，Activity中的所有代码，包括它的 View，都运行在相同的线程里。在这个线程里，还需要处理UI事件。例如，当用户按下一个按键，一个 key-down事件就会添加到 Activity的主线程队列里。事件处理系统需要很快让这个事件出列并得到处理；如果没有，系统数秒后会认为应用程序已经挂起并为用户提供杀死应用程序 的机会。
如果有耗时的代码，内联在Activity上运行也就是运行在事件处理线程里，这在很大程度上阻塞了事件处理。这会延迟输入处理，并导致ANR对话框。为了避免这个，把你的计算移到线程里。
任 何值得使用的应用程序都可能有几个不同的屏幕。当设计UI屏幕时，请一定要使用多个Activity对象实例。 依赖于你的开发背景，你可能理解 Activity类似于 Java Applet，它是你应用程序的入口点。然而，那并不精确：Applet子类是一个 Java Applet的单一入口点，而一个Activity应该看作是你的应用程序多个潜在入口点之一。你的“main”Activity和其它之间的唯一不同点 是“main”Activity正巧是在AndroidManifest.xml文件中唯一对“android.intent.action.MAIN”动作感兴趣的Activity。 因此，当设计你的应用程序的时候，把你的应用程序看作是Activity对象的 集合。从长远来看，这会使得你的代码更加方便维护。
当 谈到 UI观感时，巧妙地交融非常重要。用户在使用与自己期望相反的 UI的应用程序时，会产生不愉快的感觉。当设计你的 UI时，你应该尽量避免太多自己的主题。相反的，使用同一个主题。你可以重写或扩展你需要的主题部分，但至少在与其它应用程序相同的 UI基础上开始。
不 同的 Android设备可能支持不同的屏幕分辨率。甚至一些可以自己变更分辨率，例如，切换到风景模式。确保你的布局和图片能足够灵活地在不同的设备屏幕上正 常显示。幸运的是，这很容易做到。简而言之，你需要做的是为主要分辨率提供不同版本的作品，然后为不同的尺寸设计你的布局。（例如，避免使用硬编码位置而 使用相对布局。）如果那样做的话，系统会处理剩下的部分，而且你的应用程序在任何设备上都看起来很棒。
Android设备会有多种网络连接选项。所有的都提供数据访问，但之间肯定有更快的。其中，速度最慢的是GPRS，GSM网络的非 3G数据服务。即使具备 3G能力的设备在非3G的网络上也会花费很多的时间，所以，网络很慢仍然是一个长期存在的事实。
这 就是为什么你应该按照最小化的网络访问和带宽来编写你的代码。你不能假设网络是快速的，所以，你应该总是计划它是慢的。如果你的用户碰巧在一个快速的网络 上，那很好——他们的用户体验会提升。你要避免相反的情形：在不同的地点和不同时间，应用程序有时可用，有时慢得令人抓狂，这样的程序可能不会受欢迎。
还 有一个潜在的地方是，如果你正在使用模拟器，那么你很容易受它迷糊，因为模拟器使用电脑的网络连接。这比手机网络快很多，所以，你需要修改模拟器设定来模 拟较低的网络速度。你可以在 Eclipse中做到这点，在启动选项的模拟器设置页里设置或者在启动模拟器时通过命令行选项设置。
Android 可以支持多种外观形状。也就是说，一些Android设备拥有全“QWERTY”键盘，而其它可能会有40键、12键或其它键盘设置。同样的，一些设备可 能有触摸屏，但一些也会没有。当创建你的应用程序的时候，记住这一点。不要假定特定的键盘布局——除非你真的想限定你的应用程序只运行在某些设备上。
如 果移动设备经常插在墙上，那么，它也就不是很“移动”。移动设备是电池供电的，如果我们能让每次充电的电池使用得更持久一些，那么每个人都会更加开心—— 尤其是用户。
其中两大耗电硬件是处理器和无线；这也就是我们为什么要写尽可能少做工作、尽可能少去使用网络的应用程序的重要原因。
如 何让你的应用程序最小化的占用处理器，归根结底还是要写高效代码。为了减少无线的电量消耗，确保对错误条件进行正确的处理，并只获取你要的东西。例如，如 果某一个网络操作失败了，不要不断地进行重试。如果失败了一次，有可能是用户不受欢迎，因此，如果你再以正确的方式操作，有可能还会失败；所有你做的都是 在浪费电池。
用户是相当聪明的：如果你的程序高耗电，他们是一定会发现的。到那个时点，你唯一可以确定的是，你的程序将很快被卸载掉。
第14篇：软件开发工程师(嵌入式开发)岗位职责
1.设计芯片驱动程序，编写软件概要和详细设计说明书。2.编写驱动代码,并进行单元测试和系统测试。3.配合硬件工程师调试硬件电路。4.单板软件需求分析、设计、编码与测试。
第15篇：项目产品开发工程师岗位职责
1.负责项目报价阶段的技术方案的制定。2.协助销售人员与顾客进行必要的技术沟通。3.负责雨刮器系统设计。4.按照法雷奥项目管理体系和ISO/TS16949的要求，负责相关文件的编制和更新。5.按照项目进度进行产品的开发和验证。6.负责产品开发过程中与客户的沟通。7.负责解决产品开发过程中的质量问题。
第16篇：市场开发、销售工程师岗位职责
1.执行公司的销售策略并独立完成各项销售指标。2.负责公司未来的在各个省市的3G建网投标工作。3.针对需求和市场策略，推广公司的整体技术解决方案和相关技术。4.与技术支持工程师协调，为客户提供专业的解决方案、售后服务和技术支持。5.遵守公司的信贷制度，与客户协调货款回收，负责客户关系开拓、维护和沟通。6.负责开发和维护相关客户，独立开拓解决方案和通信设备产品的行业销售工作。
第17篇：Android 嵌入式开发心得体会
Android 嵌入式开发心得体会
刚开始接触Android感觉到它很有意思，在界面开发上和web也可以形成了相通的架构，更加方便，视觉上也是非常的酷，在前期我通过的大量的Android SDK开发范例大全中的例子以及Android提供的APIDEMOS进行学习，尽管例子之间的连接比较零散，不过通过这些例子的学习我可以学习到了很多和以前java上相通的思想，因为Android在现在也是全新的技术和框架，在其中我也学到了如何用单例模式、工厂模式等常用的设计模式进行学习，通过API进行开发客户端，对Request发送，Response处理中通过比较方便的JSON对象传输，以及对XML、JSON、图片、业务等下载处理，对API接口调用等问题处理，学习Android心得体会。首先在界面上，我们同样可以通过不同布局进行设计非常酷的界面，这些界面可以通过include进行引入，和jsp、html也有相通的地方，同样在android上可以用到自定义的样式这和c也有比较相通的地方，我们可以通过一些公用的方法写个BaseActivity这个基类，通过继承方式比较不错的实现了Activity的界面，因为这样你可以Header(头部)和Footer(尾部)进行处理一些触发事件或者特效等，布局模式以相对模式为主，线线布局模式可以在比较简单的include进行完成，最重要的一点就是：我们可以自己通过重写方法或者通过实现View或者Layout等类进行扩充项目需要的布局(或者控件),在学习界面中，我发现Android为我们提供了很好的类似反射机制，通过Layout文件夹下的配置文件，可以快速的形成界面，在配置文件可以设置属性或者样式都是很快捷方便。对比较特殊的界面也可以通过处理嵌入到指定的界面，同样你可以通过java代码直接创建View进行添加，不过这种方式比较复杂。对一些点击、选中、按键等处理的事件，界面之间的跳转Intent管理，通过Bundle对数据在界面之间进行传输。其次在手机交互式通信服务中，学习了Android手机之间进行短信发送、广播、对广播的监听、服务等，在Service类中没有context，可以通过Handler来每秒反复运行，自动送出系统广播信息，同时在这里我们也知道可以设计一个常用的变量类，设计一个当前的CurrentActivity这个变量进行控制，进行处理。
总而言之，Android设计还是比较自由开阔的，只要有想法，自己动手便能实现。
第18篇：Android项目开发总结
项目开发总结报告
1引言
1.1编写目的
总结开发经验与学习中的不足
1.2背景
以方便用户记录日常学习心得，生活体会为目的，进行主题为“随心笔记”的应用开发
2实际开发结果
2.1产品
2.2主要功能和性能
能够查看笔记的目录，记录笔记完成时间。能够改变主题颜色，目录排版方式，拥有简洁的主题。对于涂鸦功能，插入图片，密码锁等功能未能实现。
3开发工作评价
3.1对产品质量的评价
本应用拥有简单实用的功能，能够满足一般用户的需要
3.3对技术方法的评价
开发中使用了软件工程中的增量开发模型，黑盒测试等技术，使开发逐步向前发展
3.4出错原因的分析
对于部分Android版本支持性不好，不能正常使用安装等
2 4经验与教训
通过这次开发，我们体验了开发不易，需要很多人员的合作。开发过程中，必须明确整体目标，不能东一榔头，西一棒槌。另外由于学习时间短，对很多东西都不太了解，还好通过CSDN等一些网站能够找到有益的帮助，感谢那些博客，论坛。
第19篇：Android开发知识点总结
由麦可网整理，转载请注明出处
Android开发知识点总结
1.如何让你的应用优先安装到SD卡上?
从Android 2.2 SDK开始多出了一个属性在AndroidManifest.xml中，在manifest节点加入android:installLocation=\"preferExternal\"即可，当然要想让你的应用真正的安装到SD卡上，用户最终的固件为2.2，同时用户选择安装时在SD卡上。一般只有大型游戏或非重要的系统级应用选择安装在SD卡上，SD卡的读写要慢于ROM且更费电，所以重要的应用，比如闹铃提醒是不能设置安装到SD卡的。
2.如何防止Service被系统回收?
对于Service被系统回收，一般做法是通过提高优先级可以解决，在AndroidManifest.xml文件中对于intent-filter可以通过android:priority = \"1000\"这个属性设置最高优先级，1000是最高值，如果数字越小则优先级越低，同时实用于广播，而Android123推荐大家如果你的应用很重要，可以考虑通过系统常用intent action来触发。
3.Android NDK本地应用效率提升方法
对于C/C++的应用，这里Android开发网提示按照C++的习惯，简单反复调用的函数可以声明为inline，尽量少用虚函数，C++ STL的Stream效率不是很高，vector的内存管理要考虑仅分配不释放问题，如果需要涉及和Java通讯，则JNI的执行开销比较大，同时IPC通讯方法在本地端使用IBinder比较高效，当然如果你的技术不是很过关，Socket也是可以的，也更规范些吧。
第20篇：Android开发—四大组件
Android四大组件
Activity、Service、Broadcast Receiver、Content Provider
Activity
做一个完整的Android程序，不想用到Activity，真的是比较困难的一件事情，除非是想做绿叶想疯了。因为Activity是Android程序与用户交互的窗口，在我看来，从这个层面的视角来看，Android的Activity特像网站的页面。
Activity，在四大组件中，无疑是最复杂的，这年头，一样东西和界面挂上了勾，都简化不了，想一想，独立做一个应用有多少时间沦落在了界面上，就能琢磨清楚了。从视觉效果来看，一个Activity占据当前的窗口，响应所有窗口事件，具备有控件，菜单等界面元素。从内部逻辑来看，Activity需要为了保持各个界面状态，需要做很多持久化的事情，还需要妥善管理生命周期，和一些转跳逻辑。对于开发者而言，就需要派生一个Activity的子类，然后埋头苦干上述事情。对于Activity的更多细节，先可以参见：reference/android/app/Activity.html。后续，会献上更为详尽的剖析。
Service
服务，从最直白的视角来看，就是剥离了界面的Activity，它们在很多Android的概念方面比较接近，都是封装有一个完整的功能逻辑实现，只不过Service不抛头露脸，只是默默无声的做坚实的后盾。但其实，换个角度来看，Android中的服务，和我们通常说的Windows服务，Web的后台服务又有一些相近，它们通常都是后台长时间运行，接受上层指令，完成相关事务的模块。用运行模式来看，Activity是跳，从一个跳到一个，呃...，这有点像模态对话框（或者还像web页面好了...），给一个输入（抑或没有...），然后不管不顾的让它运行，离开时返回输出（同抑或没有...）。而Service不是，它是等，等着上层连接上它，然后产生一段持久而缠绵的通信，这就像一个用了Ajax页面，看着没啥变化，偷偷摸摸的和Service不知眉来眼去多少回了。但和一般的Service还是有所不同，Android的Service和所有四大组件一样，其进程模型都是可以配置的，调用方和发布方都可以有权利来选择是把这个组件运行在同一个进程下，还是不同的进程下。这句话，可以拿把指甲刀刻进脑海中去，它凸显了Android的运行特征。如果一个 Service，是有期望运行在于调用方不同进程的时候，就需要利用Android提供的RPC机制，为其部署一套进程间通信的策略。
Android的RPC实现，如上图所示（好吧，也是从SDK中拿来主义的...），无甚稀奇，基于代理模式的一个实现，在调用端和服务端都去生成一个代理类，做一些序列化和反序列化的事情，使得调用端和服务器端都可以像调用一个本地接口一样使用RPC接口。
Android中用来做数据序列化的类是Parcel，参见：/reference/android/os/Parcel.html，封装了序列化的细节，向外提供了足够对象化的访问接口，Android号称实现非常高效。还有就是AIDL (Android Interface Definition Language) ，一种接口定义的语言，服务的RPC接口，可以用AIDL来描述，这样，ADT就可以帮助你自动生成一整套的代理模式需要用到的类，都是想起来很乏力写起来很苦力的那种。更多内容，可以再看看：guide/developing/tools/aidl.html，如果有兴致，可以找些其他PRC实现的资料lou几眼。关于Service的实现，还强推参看API Demos这个Sample里面的RemoteService实现。它完整的展示了实现一个Service需要做的事情：那就是定义好需要接受的Intent，提供同步或异步的接口，在上层绑定了它后，通过这些接口（很多时候都是RPC的...）进行通信。在RPC接口中使用的数据、回调接口对象，如果不是标准的系统实现（系统可序列化的），则需要自定义aidl，所有一切，在这个Sample里都有表达，强荐。Service从实现角度看，最特别的就是这些RPC的实现了，其他内容，都会接近于Activity的一些实现，也许不再会详述了。
Broadcast Receiver
在实际应用中，我们常需要等，等待系统抑或其他应用发出一道指令，为自己的应用擦亮明灯指明方向。而这种等待，在很多的平台上，都会需要付出不小的代价。比如，在Symbian中，你要等待一个来电消息，显示归属地之类的，必须让自己的应用忍辱负重偷偷摸摸的开机启动，消隐图标隐藏仸务项，潜伏在后台，监控着相关事件，等待转瞬即逝的出手机会。这是一件很发指的事情，不但白白耗费了系统资源，还留了个流氓软件的骂名，这真是卖力不讨好的正面典型。
在Android中，充分考虑了广泛的这类需求，于是就有了Broadcast Receiver这样的一个组件。每个Broadcast Receiver都可以接收一种或若干种Intent作为触发事件（有不知道Intent的么，后面会知道了...），当发生这样事件的时候，系统会负责唤醒或传递消息到该Broadcast Receiver，仸其处置。在此之前和这以后，Broadcast Receiver是否在运行都变得不重要了，及其绿色环保。这个实现机制，显然是基于一种注册方式的，Broadcast Receiver将其特征描述并注册在系统中，根据注册时机，可以分为两类，被我冠名为冷热插拔。所谓冷插拔，就是Broadcast Receiver的相关信息写在配置文件中（求配置文件详情？稍安，后续奉上...），系统会负责在相关事件发生的时候及时通知到该Broadcast Receiver，这种模式适吅于这样的场景。某事件方式 ->通知Broadcast ->启动相关处理应用。比如，监听来电、邮件、短信之类的，都隶属于这种模式。而热插拔，顾名思义，插拔这样的事情，都是由应用自己来处理的，通常是在 OnResume事件中通过registerReceiver进行注册，在OnPause等事件中反注册，通过这种方式使其能够在运行期间保持对相关事件的关注。比如，一款优秀的词典软件（比如，有道词典...），可能会有在运行期间关注网络状况变化的需求，使其可以在有廉价网络的时候优先使用网络查询词汇，在其他情况下，首先通过本地词库来查词，从而兹顾腰包和体验，一举两得一石二鸟一箭双雕（注，真实在有道词典中有这样的
能力，但不是通过 Broadcast Receiver实现的，仅以为例...）。而这样的监听，只需要在其工作状态下保持就好，不运行的时候，管你是天大的网路变化，与我何干。其模式可以归结为：启动应用 ->监听事件 ->发生时进行处理。除了接受消息的一方有多种模式，发送者也有很重要的选择权。通常，发送这有两类，一个就是系统本身，我们称之为系统Broadcast消息，在reference/android/content/Intent.html 的Standard Broadcast Actions，可以求到相关消息的详情。除了系统，自定义的应用可以放出Broadcast消息，通过的接口可以是 Context.sendBroadcast，抑或是Context.sendOrderedBroadcast。前者发出的称为Normal broadcast，所有关注该消息的Receiver，都有机会获得并进行处理；后者放出的称作Ordered broadcasts，顾名思义，接受者需要按资排辈，排在后面的只能吃前面吃剩下的，前面的心情不好私吞了，后面的只能喝西北风了。当Broadcast Receiver接收到相关的消息，它们通常做一些简单的处理，然后转化称为一条Notification，一次振铃，一次震动，抑或是启动一个 Activity进行进一步的交互和处理。所以，虽然Broadcast整个逻辑不复杂，却是足够有用和好用，它统一了Android的事件广播模型，让很多平台都相形见绌了。更多Broadcast Receiver相关内容，参见：/reference/android/content/BroadcastReceiver.html。
Content Provider
Content Provider，听着就和数据相关，没错，这就是Android提供的第三方应用数据的访问方案。在Android中，对数据的保护是很严密的，除了放在SD卡中的数据，一个应用所持有的数据库、文件、等等内容，都是不允许其他直接访问的，但有时候，沟通是必要的，不仅对第三方很重要，对应用自己也很重要。比如，一个联系人管理的应用。如果不允许第三方的应用对其联系人数据库进行增删该查，整个应用就失去了可扩展力，必将被其他应用抛弃，然后另立门户，自个玩自个的去了。Andorid当然不会真的把每个应用都做成一座孤岛，它为所有应用都准备了一扇窗，这就是Content Provider。应用想对外提供的数据，可以通过派生ContentProvider类， 封装成一枚Content Provider，每个Content Provider都用一个uri作为独立的标识，形如：content://com.xxxxx。所有东西看着像REST的样子，但实际上，它比REST 更为灵活。和REST类似，uri也可以有两种类型，一种是带id的，另一种是列表的，但实现者不需要按照这个模式来做，给你id的uri你也可以返回列表类型的数据，只要调用者明白，就无妨，不用苛求所谓的REST。另外，Content Provider不和REST一样只有uri可用，还可以接受Projection，Selection，OrderBy等参数，这样，就可以像数据库那样进行投影，选择和排序。查询到的结果，以Cursor（参见：reference/android/database/Cursor.html ）的形式进行返回，调用者可以移动Cursor来访问各列的数据。
Content Provider屏蔽了内部数据的存储细节，向外提供了上述统一的接口模型，这样的抽象层次，大大简化了上层应用的书写，也对数据的整吅提供了更方便的途径。Content Provider内部，常用数据库来实现，Android提供了强大的Sqlite支持，但很多时候，你也可以封装文件或其他混吅的数据。在Android中，ContentResolver是用来发起Content
Provider的定位和访问的。不过它仅提供了同步访问的Content Provider的接口。但通常，Content Provider需要访问的可能是数据库等大数据源，效率上不足够快，会导致调用线程的拥塞。因此
Provider。
在各大组件中，Service和Content Provider都是那种需要持续访问的。Service如果是一个耗时的场景，往往会提供异步访问的接口，而Content Provider不论效率如何，都提供的是约定的同步访问接口。我想这遵循的就是场景导向设计的原则，因为Content Provider仅是提供数据访问的，它不能确信具体的使用场景如何，会怎样使用它的数据；而相比之下，Service包含的逻辑更复杂更完整，可以抉择大部分时候使用某接口的场景，从而确定最贴切的接口是同步还是异步，简化了上层调用的逻辑。 Android提供了一个AsyncQueryHandler（参见：reference/android/content/AsyncQueryHandler.html），帮助进行异步访问Content
