第一篇: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
第二篇: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键或其它键盘设置。同样的,一些设备可 能有触摸屏,但一些也会没有。当创建你的应用程序的时候,记住这一点。不要假定特定的键盘布局——除非你真的想限定你的应用程序只运行在某些设备上。
如 果移动设备经常插在墙上,那么,它也就不是很“移动”。移动设备是电池供电的,如果我们能让每次充电的电池使用得更持久一些,那么每个人都会更加开心—— 尤其是用户。
其中两大耗电硬件是处理器和无线;这也就是我们为什么要写尽可能少做工作、尽可能少去使用网络的应用程序的重要原因。
如 何让你的应用程序最小化的占用处理器,归根结底还是要写高效代码。为了减少无线的电量消耗,确保对错误条件进行正确的处理,并只获取你要的东西。例如,如 果某一个网络操作失败了,不要不断地进行重试。如果失败了一次,有可能是用户不受欢迎,因此,如果你再以正确的方式操作,有可能还会失败;所有你做的都是 在浪费电池。
用户是相当聪明的:如果你的程序高耗电,他们是一定会发现的。到那个时点,你唯一可以确定的是,你的程序将很快被卸载掉。
第三篇:Android开发分享讲稿(修改)
讲清楚,do better Android开发入门分享
今天要给大家分享的是Android开发入门,小青青_Lo是我的微博昵称,如果觉得我讲得好,求互粉(*^__^*)嘻嘻~~
讲解大纲
这个是今天讲解的大纲,首先通过著名Hello world程序对Android开发有一个感性的认识,之后上升到理性认识,了解android开发的重要组成部分和基本开发流程。Android开发主要包括App组件,App资源和App的配置文件。App组件主要负责和用户交互,处理用户请求;而App Res主要负责用户界面的视图;App Manifest文件主要用来声明App运行所需环境,比如App包含哪些功能模块,API最低最高版本要求,比如Android操作系统版本要求运行设备的性能要求,比如屏幕分辨率,内存空间大小等,用户是否有权限访问一些系统应用程序和系统数据,比如通讯录,GPS位置信息,本地通知服务等。
在讲解Android开发的重要组成部分的过程中会涉及一些简单的实例现场演示来讲述Android开发的基本流程。
欢迎提问
因为我本身是一个Android开发的新手,在加上本身写代码写得少,所以难免会有一些错误和讲得不清楚得地方,欢迎大家提出疑问,提问有奖。如果我答不出来,记下来分享后查资料给大家回答。
先做加法讲清楚,之后做减法,言简意赅,严格控制时间
讲清楚,do better
为什么要学习Android开发?(此段可以精简下)
Android操作系统目前占移动操作系统78%的市场份额,这个充分说明了android开发市场大需求广。现在大家都知道移动互联网是大势所趋,每天坐公交地铁,一眼望去大家都在忙于刷手机ipad就已经充分说明这点,随着移动互联网的兴起,App开发自然是大势所趋。Android操作系统之所以发展如此迅速,和其开源有着密不可分的关系,开源意味着便于扩展和学习,以及使用。
之后我们简单介绍下Android系统架构,一共分为四层,最下层的是linux内核,负责内存管理,进程调度,网络协议以及各种设备驱动等,再上面是各种系统运行库,其主要是应用框架层和linux内核的重要纽带,而我们下载的android SDK处于应用框架层,主要负责给android应用开发提供各种基础服务,我们平时使用的微博,微信等app应用程序就处于应用层。简要介绍了android系统,我们现在开始anroid开发之旅。部署Android开发环境
Android开发第一步就是部署android开发环境,部署android开发环境有两种方式:方法一是JDK+android studio, 方法二是JDK+SDK+Eclipse。我们现在比较下这两种的特性,首先从部署便捷性来看AndroidStudio要比安装SDK步骤少,更方便简单。之前小超分享框架的时候说应用性和性能一般成反比,Android Studio的IDE好用,这同样意味着其性能比SDK的要低,所以其编译运行速度Eclipse显然比Android Studio快,内存消耗低。运行Android Studio一般将我可怜本本拖垮。如果从开发效率来看,方法一显然要高于方法先做加法讲清楚,之后做减法,言简意赅,严格控制时间
讲清楚,do better 二,从代码架构来看,AS的Java/resoure/Manifest三个文件夹就一一映射了Android开发的三个重要组成部分,而Eclipse的代码架构相比之下稍显混乱。而且Android Studio的UI可视化也比Eclipse的更为强大好用。对于运行机器要求,显然Android Studio比JDK的要求高。
综上所述,AS作为google的官方开发工具,再者从大家最关心的开发效率来看,AS是Android开发的IDE最佳之选
AS是基于IDEA的,好好看看AS好在哪!
http://java.dzone.com/articles/why-idea-better-eclipse
首先创建工程(1)建立一个工程
FileNewAndroid Application Project
运行程序,选中app,右键点击菜单选择run asAndroid Application.注意此时需要将Android手机通过usb接口连接到电脑上,而且选择允许调试,即可在手机上安装运行的app,从而看到运行效果。
先做加法讲清楚,之后做减法,言简意赅,严格控制时间
讲清楚,do better
(2)分析代码架构(src/res/Manifest File)
src: java code, 主要负责实现App的组件(Activity,Broadcast,ContentProvider,Service etc)和数据存储(文件存储,db存储,shared Preference),完成用户界面内的相关交互。
res: layout,values,drawable etc, 主要负责UI布局,都是xml格式的文件。Manifest File:主要是配置App的运行环境。Api的版本需求,App的访问权限,App所包含的组件,设备特征的相关权限等(3)建立并运行一个activity 先做加法讲清楚,之后做减法,言简意赅,严格控制时间
讲清楚,do better PS:首先注意到此处有一个黄色感叹号,说明此程序有警告,如果是一把红叉叉,就是程序包含错误,需要修复。此处有警告,是因为使用了低版本的类ActionBarActivity,所以类名上面有横线,在此处我们修改为Activity类,然后按快捷键ctrl+shift+O,自动import该类的命名空间。此时发现import android.app.Activity;并且黄色的感叹号消失了。
Android开发重要组成部分
接下来我们进一步了解Android开发,Android开发的重要组成部分。Android组件主要包括活动,广播,服务和内容提供器。这四大组件是组成App的基础功能模块,而intent和intent-filters是用来衔接各个功能模块组件,负责组件之间的交互和通信。
如果是组件是负责逻辑控制,那么App Res主要负责用户界面视图,在此会介绍构成视图的资源类型,以及各个资源的组成方式;之后还会介绍如何在代码中访问资源。由于运行app的设备分辨率不同,语言不同,操作系统版本不同等原因,需要考虑到资源如何对各种不同设备的硬软件兼容。
最后我们简单介绍下配置文件的作用。Manifest文件主要是用来声明App运行环境要求,支持什么版本的api,app包含哪些组件,需要哪些用户权限等。Activity的定义
首先我们来看四大组件中最常见的Activity, 在SDK的官方文档是这样定义Activity的,其主要是提供一个可以让用户进行交互完成某些请求的用户界面。比如说用户在拨打电话,拍照,发送邮件,看地图的时候都需要一个用户界面,通过这个界面用户可以和app进行对话,发出请求,app响应请求。同样在刷先做加法讲清楚,之后做减法,言简意赅,严格控制时间
讲清楚,do better 微博的时候我们也可以处处看到Activity,微博feed流,点击消息进入消息箱。简而言之,Acivity是承载某个功能的UI和交互的一个容器,在app中看到的是一个用户交互界面。Activity状态和生命周期
Activity一共有三种状态,当Activity处于前端的时候,也就是获取用户焦点的时候,其状态为Resumed,此时处于前端生命周期,而当其失去用户焦点,但是还是部分可见的时候,其状态为paused,此时不属于前端生命周期,而属于可见生命周期范围内,而当其失去用户焦点,又不可见的时候,此时就是stoped。从创建到stop整个过程为完整生命周期。
我们可以看一个例子。
主界面获取用户焦点
主界面不可见失去
先做加法讲清楚,之后做减法,言简意赅,严格控制时间
讲清楚,do better
对于组件的用法主要分为三步:(1)实现组件类
(2)在Manifest或者代码中注册组件(3)在活动中启动或者触发组件
如何使用Activity(见demo)
(1)创建UI—second.xml(2)创建SecondActivity(3)启动一个activity
前面我讲到要从主界面而跳转到第二个界面,也就是从第一个活动跳转到第二个活动,这个时候需要intent来衔接各个组件,完成组件之间的交互。
先做加法讲清楚,之后做减法,言简意赅,严格控制时间
讲清楚,do better 首先我们来看下官方sdk上对intent的定义,intent是指向其他app发出动作请求,四大组件中的活动,服务和广播都是由intent来启动(此处没有讲清楚呀!)也因此intent有广泛的应用,比如
– 从微博feed流跳转到消息箱 – 启动本地通知服务,闹钟备忘录服务 – 发微博晒照片跳转照相机程序
– 密码变更的时候,发送强制下线的广播…
Intent的类型
Intent包含两种类型,显式intent和隐式intent,显式intent是指通过组件类名来启动组件。然后隐式的intent是通过声明组件要执行的动作,android系统根据要执行的动作找到相应的组件启动之。
什么也不多说,我们看看代码。从代码中也可以看出显示intent和隐式intent的区别。一个是从主界面跳转到第二个页面,一个是先在Manifest声明跳转的动作,系统找到符合条件的活动进行启动。隐式intent活动启动的原理
我们通过一个图来看看隐式intent启动活动的原理,如图所示:
[1] Activity A 通过一个Action的描述创建Intent,并将其传给startActivity.[2] 安卓系统搜索所有activity的intent filters,看是否这个intent中的action [3] 如果ActivityB 符合,则将启动Activity B
运行一个intent 先做加法讲清楚,之后做减法,言简意赅,严格控制时间
讲清楚,do better 如果要build一个intent,要么采用显式的intent通过组件类名进行启动。要么描述组件要执行的动作或者种类信息,系统找到满足条件的组件进行相关的启动,可能执行某些动作的时候还需要携带一些数据。
Intent的用法
Intent可以用来启动一个活动,也可以用于启动一个服务,或者将其余服务进行相关的绑定,或者发送广播,或者在这个过程中传递或者返回数据。具体会在后续进行相关的讲述。
Pendingintent的定义和应用
PendingIntent是指在intent对象外包了一层。Pendingintent最初的目的是用于授权外部程序可以使用内部的intent,就好像这个intent是内部调用,然后在内部进程内执行的。
其主要应用场景有:
一个是用于声明本地通知服务时所需的intent代码 另一个是用于声明定时任务触发的intent 最后是声明与控件交互的intent
Broadcast的定义和应用
广播接收器是指可以用来接收系统范围内的广播通知的组件。广播的应用有:
先做加法讲清楚,之后做减法,言简意赅,严格控制时间
讲清楚,do better 一些是来自系统的广播,比如说提示app电量过低,提示网络中断,不能再正常刷微信微博,开机时通知某些app自动启动。
有一些是应用程序广播或者本地广播,所谓本地广播是指程序内部的广播。比如当通知所有的活动强制下线等。
Broadcast的运行流程
Broadcast的运行流程包括发送广播,注册广播接收器和接收广播。发送广播主要是通过intent来进行广播的发送,注册广播接收器有两种方法,一种是在manifest中静态注册的方法,在manifest中声明接收器的类名以及相关动作。一种是在代码中动态注册的方法,在代码中创建intent-filter,并创建广播接收器对象,用这两个参数注册广播接收器;最后接收广播,就需要实现广播接收器的类,其中最重要是重载onReceive函数,里面是处理当接收到广播的时候如何处理。
ContentProvider的定义和应用
ContentProvider主要是提供访问外部数据的标准接口。
ContentProvider主要适应于当需要将一些复杂的数据或文件提供外部程序使用时,出于安全的考虑,提供contentprovider作为外部程序访问内部数据的接口。当只是在内部完成一些数据的读写,此时是不需要provider的。
ContentProvider的运行过程:
先做加法讲清楚,之后做减法,言简意赅,严格控制时间
讲清楚,do better
1.App0 给其他app提供了一些数据。
2.App1和App2都想访问App0内部的数据,但App1因为没权限而无权访问,App2在manifest中声明了其访问权限。
3.为了App0内部数据安全,App0给外部程序提供了访问内部数据的标准接口即ContentProvider。
4.App2通过getContentResolver转化content URI中的provider authority和path,并与已知的providers匹配,从而找到所需要的provider,从而成功访问App0的内部数据。ContentProvider的用法:
首先设计相关的数据结构——文件或者结构化数据。
之后就是设计内容的URI,实现provider的类,之后就是定义provider的属性,并且在manifest文件中注册相关的provider。
最后使用getContentResolver来找到正确的provider,我们可以通过一个通讯录的例子来进行相关的了解。
Service的定义和应用
服务主要指在后台长期运行的程序。
先做加法讲清楚,之后做减法,言简意赅,严格控制时间
讲清楚,do better 服务的应用有本地通知服务,定时任务服务和后台应用程序等。
Service的生命周期以及服务的相关用法
服务的生命周期分为完整生命周期和活跃生命周期,完整生命周期是指从服务创建到服务销毁。如果某个服务在某个活动启动,即使是活动被销毁了,这个服务也依然存在,比如push服务,即使没有停留在app前端,push服务也是在后台运行的。
而活跃生命周期是指从服务绑定到服务解绑的整个过程。
Service的相关用法:
实现服务类,在manifest中注册服务组件,并且在活动中启动或者绑定某项服务。
你会发现所有的组件的使用,基本都是实现具体组件类,然后再manifest中注册或者在代码中注册,之后在活动中通过intent启动相关的组件。
资源Resources Res用于构建我们看到的用户界面视图,我们将从以下三个方面来讲述:资源类型,设备兼容性,以及如何在代码中使用Resource,我们对照右图,可以看出资源有布局,有字符串,有调色板等,除了资源的种类,资源还会考虑设备的兼容性,比如说根据屏幕分辨率——分为hdpi的调色版,ldpi的调色板等,根据系统语言,字符串的分为英语,中文,日语的等,而由于不同设备上安装的是不同版本的android操作系统,自然资源要适配各种不同版本的api,比如先做加法讲清楚,之后做减法,言简意赅,严格控制时间
讲清楚,do better values-v11,values-v14等
为了更好的用户交互,有时候我们要获取资源,比如实现点击登录按钮跳转到微博主页,我们必须获取登录按钮,针对这个按钮先点击事件。那如何获取到登录按钮呢?也就是如何获取到按钮资源呢?在Android开发中会生成一份R文件,为每一个资源都分配了一个id,我们可以根据这个id进行访问。那如何获取到这个id呢,主要是根据我们在资源xml文件中定义的id,比如R.id.btn_login,类似于html中我们用到的id,也可以是类型+资源名来获取到这个id,比如R.string.hello_world。
布局的树形结构
一个用户界面整体是一个树形结构,有一个根的layout,之后layout可以相互嵌套。在android中资源分为两类:viewGroup和view,而viewGroup继承与view,viewGroup主要指布局,而view主要指控件,如按钮,文本,列表框等 Layout 讲到布局,必须提到布局的几种类型,最常用的是线性布局,其次是相对布局,之后是绝对布局和帧布局,线性布局分为垂直和水平,默认是水平的方式。相对布局主要是相对屏幕或者某个控件,某个内嵌布局的相对位置。Manifest的相关作用
Manifest主要是用来声明App的运行环境,比如运行设备的硬软件特征,对屏幕分辨率,内存空间大小的要求,对Android操作系统版本的要求,App包含哪些组件,需要哪些用户权限等。这些都需要在Manifest中进行相关的声明
先做加法讲清楚,之后做减法,言简意赅,严格控制时间
讲清楚,do better
小小测试---初步理解认识UI和交互
最后是做些小小测试,检验下大家今天的收获成果,比如在Android开发最重要的就是UI和交互,通过之前的几个小实验,现在大家思考下,这些稍微复杂一点的界面UI如何实现呢?如何构造布局,选择何种控件?
可以看到左边的这个,有一个标题栏,下面是聊天界面,最下面是输入框和发送按钮,可以做一个垂直线性的布局。上面的标题栏可以做一个横向线性的布局,中间的是一个listview的列表框,下面也可以做一个横向的线性布局(手绘一下基本的一个构造)
中间是一个通讯录的页面,这个通讯录的好友页面较之我们之前要复杂的多 也可以做一个垂直的线性布局,上面是一个标题栏,下面是一个listview,标题栏做一个横向的线性布局。而listview对其每一个list又定义一个横向的线性布局,一个ImageView图像控件和一个文本控件 右边的就相对要简单。标题栏加一个图像对象
看完UI之后,我们来分析下交互,左边的是输入文本框的内容,在点击按钮的时候获取文本框的内容添加到消息对象中,listview的消息列表中添加这条发送的消息。
中间就是我们刚刚获取了通讯录的用户名和电话号码的基础上之后,我们还需要获取联系人的头像。将这些元素在自定义列表布局中进行显示。
右边是添加一个感知器对象,感知手机晃动加速度,当加速度达到一定程度,随机弹出一个餐厅的名字。
先做加法讲清楚,之后做减法,言简意赅,严格控制时间
讲清楚,do better 这三个界面可以做三个活动,在活动中显示UI,并且在活动中完成按钮以及列表框的触发事件。最后通过intent在各个界面之间进行跳转。
最后我们分析下微博的构造来理解四大组件。
微博有哪些主要的功能模块,这些功能模块之间如何交互。
从最下面的导航栏可以看出主要有微博主页,消息箱,微博发布器,发现和我的profile五大功能模块。他们之间可以通过点击按钮实现跳转到相应的活动页面,如果再进入更加深入一级别,就通过点击返回键,返回到上一界面。
首先所有的活动都会接收系统状态参数的一些广播,比如电量,比如网络状态,而且所有的活动都会接收push SDK的push通知服务等,所有活动也会接收当密码变更强制下线的广播。比如通讯录访问手机联系人的时候会用到通讯录数据。我们主要分析下微博feed流和消息箱,这些一般都是分为几个模块,feed流和消息箱都是相应的listview,并且对list定制布局。
后记
本次分享旨在让大家对android开发有一个初步的认识,了解android开发的重要组成部分和基本开发流程,当接到android开发的需求的时候,有一个开发的方向感和清晰的开发思路。希望大家能动一动手,一起见证奇迹app诞生时刻。
先做加法讲清楚,之后做减法,言简意赅,严格控制时间
讲清楚,do better
先做加法讲清楚,之后做减法,言简意赅,严格控制时间
第四篇:Android 嵌入式开发心得体会
Android 嵌入式开发心得体会
刚开始接触Android感觉到它很有意思,在界面开发上和web也可以形成了相通的架构,更加方便,视觉上也是非常的酷,在前期我通过的大量的Android SDK开发范例大全中的例子以及Android提供的APIDEMOS进行学习,尽管例子之间的连接比较零散,不过通过这些例子的学习我可以学习到了很多和以前java上相通的思想,因为Android在现在也是全新的技术和框架,在其中我也学到了如何用单例模式、工厂模式等常用的设计模式进行学习,通过API进行开发客户端,对Request发送,Response处理中通过比较方便的JSON对象传输,以及对XML、JSON、图片、业务等下载处理,对API接口调用等问题处理,学习Android心得体会。首先在界面上,我们同样可以通过不同布局进行设计非常酷的界面,这些界面可以通过include进行引入,和jsp、html也有相通的地方,同样在android上可以用到自定义的样式这和css也有比较相通的地方,我们可以通过一些公用的方法写个BaseActivity这个基类,通过继承方式比较不错的实现了Activity的界面,因为这样你可以Header(头部)和Footer(尾部)进行处理一些触发事件或者特效等,布局模式以相对模式为主,线线布局模式可以在比较简单的include进行完成,最重要的一点就是:我们可以自己通过重写方法或者通过实现View或者Layout等类进行扩充项目需要的布局(或者控件),在学习界面中,我发现Android为我们提供了很好的类似反射机制,通过Layout文件夹下的配置文件,可以快速的形成界面,在配置文件可以设置属性或者样式都是很快捷方便。对比较特殊的界面也可以通过处理嵌入到指定的界面,同样你可以通过java代码直接创建View进行添加,不过这种方式比较复杂。对一些点击、选中、按键等处理的事件,界面之间的跳转Intent管理,通过Bundle对数据在界面之间进行传输。其次在手机交互式通信服务中,学习了Android手机之间进行短信发送、广播、对广播的监听、服务等,在Service类中没有context,可以通过Handler来每秒反复运行,自动送出系统广播信息,同时在这里我们也知道可以设计一个常用的变量类,设计一个当前的CurrentActivity这个变量进行控制,进行处理。
总而言之,Android设计还是比较自由开阔的,只要有想法,自己动手便能实现。
第五篇:Android项目开发总结
项目开发总结报告
1引言
1.1编写目的
总结开发经验与学习中的不足
1.2背景
以方便用户记录日常学习心得,生活体会为目的,进行主题为“随心笔记”的应用开发
2实际开发结果
2.1产品
2.2主要功能和性能
能够查看笔记的目录,记录笔记完成时间。能够改变主题颜色,目录排版方式,拥有简洁的主题。对于涂鸦功能,插入图片,密码锁等功能未能实现。
3开发工作评价
3.1对产品质量的评价
本应用拥有简单实用的功能,能够满足一般用户的需要
3.3对技术方法的评价
开发中使用了软件工程中的增量开发模型,黑盒测试等技术,使开发逐步向前发展
3.4出错原因的分析
对于部分Android版本支持性不好,不能正常使用安装等
4经验与教训
通过这次开发,我们体验了开发不易,需要很多人员的合作。开发过程中,必须明确整体目标,不能东一榔头,西一棒槌。另外由于学习时间短,对很多东西都不太了解,还好通过CSDN等一些网站能够找到有益的帮助,感谢那些博客,论坛。