一．任务；Task，简单的说，就是一组以栈的模式聚集在一起；会将其退栈，并让下一个将跑到栈顶的Activit；Activity：Android中最基本的应用程；应用程序：比如说qq软件就是一个应用程序，通常由；有了上面两个概念，就可以很好理解任务了；从Activity的角度来说，任务就是Activ；任务中Activity的行为方式都被启动那个Ac；inten
Task，简单的说，就是一组以栈的模式聚集在一起的Activity组件集合。它们有潜在的前后驱关联，新加入的Activity组件，位于栈顶，并仅有在栈顶的Activity，才会有机会与用户进行交互。而当栈顶的 Activity完成使命退出的时候，Task
会将其退栈，并让下一个将跑到栈顶的Activity来于用户面对面，直至栈中再无更多 Activity，Task结束。
Activity：Android中最基本的应用程序组件。一个Activity通常就是一个单独的屏幕，用于呈现数据和与用户进行交互。
应用程序：比如说qq软件就是一个应用程序，通常由多个Activity组成。
有了上面两个概念，就可以很好理解任务了。一个Android任务通常会涵盖多个Activity，而这些Activity可能分别属于不同的应用程序（application）。
从Activity的角度来说，任务就是Activity的堆栈。
任务中Activity的行为方式都被启动那个Activity的Intent对象中设置的一系列flags和Manifest文件中Activity的&Activity&元素的一系列属性之间的交互所控制:
intent flags：
FLAG_ACTIVITY_NEW_TASK
如果设置，这个Activity会成为历史stack中一个新Task的开始。一个Task（从启动它的Activity到下一个Task中的 Activity）定义了用户可以迁移的Activity原子组。Task可以移动到前台和后台；在某个特定Task中的所有Activity总是
保持相同的次序。
这个标志一般用于呈现“启动”类型的行为：它们提供用户一系列可以单独完成的事情，与启动它们的Activity完全无关。
使用这个标志，如果正在启动的Activity的Task已经在运行的话，那么，
新的Activity将不会启动；代替的，当前Task会简单的移入前台。参考
FLAG_ACTIVITY_MULTIPLE_TASK标志，可以禁用这一行为。
这个标志不能用于调用方对已经启动的Activity请求结果。
FLAG_ACTIVITY_CLEAR_TOP
如果设置，并且这个Activity已经在当前的Task中运行，因此，不再是重新启
动一个这个Activity的实例，而是在这个Activity上方的所有Activity都将关闭，然后这个Intent会作为一个新的Intent投递到老的Activity（现在位于顶端）中。
例如，假设一个Task中包含这些Activity：A，B，C，D。如果D调用了
startActivity()，并且包含一个指向Activity B的Intent，那么，C和D都将结束，然后B接收到这个Intent，因此，目前stack的状况是：A，B。
上例中正在运行的Activity B既可以在onNewIntent()中接收到这个新的
Intent，也可以把自己关闭然后重新启动来接收这个Intent。如果它的启动模式声
明为 “multiple”(默认值)，并且你没有在这个Intent中设置
FLAG_ACTIVITY_SINGLE_TOP标志，那么它将关闭然后重新创建；对于其它
的启动模式，或者在这个Intent中设置FLAG_ACTIVITY_SINGLE_TOP标志，
都将把这个Intent投递到当前这个实例的onNewIntent()中。
这个启动模式还可以与FLAG_ACTIVITY_NEW_TASK结合起来使用：用
于启动一个Task中的根Activity，它会把那个Task中任何运行的实例带入前台，
然后清除它直到根Activity。这非常有用，例如，当从Notification Manager处启
动一个Activity。
FLAG_ACTIVITY_RESET_TASK_IF_NEEDED
FLAG_ACTIVITY_SINGLE_TOP
如果设置，当这个Activity位于历史stack的顶端运行时，不再启动一个新的。
&Activity&属性：
taskAffinity
taskAffinity，是一种物以类聚的思想，它倾向于将taskAffinity属性相同的
Activity，扔进同一个Task中。不过，它的约束力，较之launchMode而言，弱
了许多。只有当&activity&中的allowTaskReparen ting设置为true，抑或是调用方
将Intent的flag添加FLAG_ACTIVITY_NEW_TASK属性时才会生效。如果有机
会用到Android的Notification机制就能够知道，每一个由notification进行触发
的Activity，都必须是一个设成FLAG_ACTIVITY_NEW_TASK的Intent来调用。
这时候，开发者很可能需要妥善配置taskAffinity属性，使得调用起来的Activity，
能够找到组织，在同一taskAffinity的Task中进行运行。
launchMode它有四种模式：&standard&, &singleTop&, &singleTask&,
&singleInstance&。
standard模式，是默认的也是标准的Task模式，在没有其他因素的影响下，使
用此模式的Activity，会构造一个Activity的实例，加入到调用者的Task栈中去，
对于使用频度一般开销一般什么都一般的Activity而言，standard模式无疑是最
合适的，因为它逻辑简单条理清晰，所以是默认的选择。
singleTop模式，基本上于standard一致，仅在请求的Activity正好位于栈顶时，
有所区别。此时，配置成singleTop的Activity，不再会构造新的实例加入到Task
栈中，而是将新来的Intent发送到栈顶Activity中，栈顶的Activity可以通过重
载onNewIntent来处理新的Intent（当然，也可以无视...）。这个模式，降低了位
于栈顶时的一些重复开销，更避免了一些奇异的行为（想象一下，如果在栈顶连
续几个都是同样的Activity，再一级级退出的时候，这是怎么样的用户体验...），
很适合一些会有更新的列表Activity展示。一个活生生的实例是，在 Android默
认提供的应用中，浏览器（Browser）的书签Activity（BrowserBookmarkPage），
就用的是singleTop。
singleTop模式，虽然破坏了原有栈的逻辑（复用了栈顶，而没有构造新元
素进栈...），但并未开辟专属的Task。
singleTask，和singleInstance，则都采取的另辟Task的蹊径。标志为singleTask
的Activity，最多仅有一个实例(activity)存在，并且，位于以它为根的Task中。
所有对该Activity的请求，都会跳到该Activity的Task中展开进行。singleTask，
很象概念中的单件模式，所有的修改都是基于一个实例，这通常用在构造成本很
大，但切换成本较小的Activity中。在Android源码提供的应用中，该模式被广
泛的采用，最典型的例子，还是浏览器应用的主Activity（名为Browser...），它
是展示当前tab，当前页面内容的窗口。它的构造成本大，但页面的切换还是较
快的，于 singleTask相配，还是挺天作之合的。
相比之下，singleInstance显得更为极端一些。在大部分时候singleInstance
与singleTask完全一致，唯一的不同在于，singleInstance的Activity，是它所在
栈中仅有的一个Activity，如果涉及到的其他Activity，都移交到其他Task中进
行。这使得singleInstance的Activity，像一座孤岛，彻底的黑盒，它不关注请求
来自何方，也不计较后续由谁执行。在Android默认的各个应用中，很少有这样
的Activity，在我个人的工程实践中，曾尝试在有道词典的快速取词Activity中
采用过，是因为我觉得快速取词入口足够方便（从notification中点选进入），并
且会在各个场合使用，应该做得完全独立。
allowTaskReparenting
clearTaskOnLaunch
alwaysRetainTaskState
finishOnTaskLaunch
1。应用程序运行的时候，Android会为其开启一个Linux进程，其中含有一个单
独的执行线程。然而你还可以将其安排进其他进程里或是在其他进程中产生
额外的线程。
2。Manifest文件控制着组件运行在哪个进程当中。、、、这四个标签都含有
“process”属性，它用来指定这个组件运行在哪个进程里。
3。process属性的功能：
（1）组件运行在各自的进程中。
（2）一些组件共享着一个进程。
（3）不同应用程序中的组件运行在相同的进程中（它们共享同一个Linux
用户ID和权限）。
（4）另外标签也有个process属性，默认时：在指定进程中应用所有组件。
4。所有的组件是在指定进程中的主线程创建，也就是说当系统调用这些组件时，
会去那个线程里面寻找。由于所有方法调用都在那主个线程中，难免会出现
的情况（复杂的循环计算），所以开发人员可以创建额外的线程以避
免这情况的发生。
5。有两种情况，Android需要强制关闭一个进程：
（1）内存不足。
（2）其他的进程需要更多的内存以响应用户需求。
6。强制关闭进程的简单原理：Android会衡量哪些进程对当前用户比较重要，以
关闭那些不重要的进程。举例来说，Android更乐意关闭掉那些不在屏幕上显
示的进程。因此，得出一个结论就是，这一行为取决于组件在那个进程中的
在大多数其他平台的开发中，每个开发人员对自己应用的进程模型都有非常
清晰的了解。比如，一个控制台程序，你可以想见它从main函数开始启动一个
进程，到 main函数结束，进程执行完成退出；在UI程序中，往往是有一个消
息循环在跑，当接受到Exit消息后，退出消息循环结束进程。在该程序运行过
程中，启动了什么进程，和第三方进程进行通信等等操作，每个开发者都是心如
明镜一本帐算得清清楚楚。进程边界，在这里，犹如国界一般，每一次穿越都会
留下深深的印迹。
在Android程序中，开发人员可以直接感知的，往往是Task而已。倍感清晰的，
是组件边界，而进程边界变得难以琢磨，甚至有了进程托管一说。Android中不
但剥夺了手工锻造内存权力，连手工处置进程的权责，也毫不犹豫的独占了。
当然，Android隐藏进程细节，并不是刻意为之，而是自然而然水到渠成的。
如果，我们把传统的应用称为面向进程的开发，那么，在Android中，我们做得
就是面向组件的开发。从前面的内容可以知道，Android组件间的跳转和通信，
都是在第三方介入的前提下进行，正由于这种介入，使得两个组件一般不会直接
发生联系（于Service的通信，是不需要第三方介入的，因此Android把它全部
假设成为穿越进程边界，统一基于RPC来通信，这样，也是为了掩盖进程细节...），
其中是否穿越进程边界也就变得不重要。因此，如果这时候，还需要开发者关注
进程，就会变得很奇怪，很费解，干脆，Android将所有的进程一并托管去了，
上层无须知道进程的生死和通信细节。
在Android的底层，进程构造了底部的一个运行池，不仅仅是Task中的各
个Activity组件，其他三大组件Service、Content Provider、Broadcast Receiver，
都是寄宿在底层某个进程中，进行运转。在这里，进程更像一个资源池（概念形如线程池，上层要用的时候取一个出来就好，而不关注具体取了哪一个...），只是为了承载各个组件的运行，而各个组件直接的逻辑关系，它们并不关心。但我们可以想象，为了保证整体性，在默认情况下，Android肯定倾向于将同一Task、同一应用的各个组件扔进同一个进程内，但是当然，出于效率考虑，Android也是允许开发者进行配置。
在Android中，整体的&application&（将影响其中各个组件...）和底下各个组件，都可以设置&process&属性，相同&process&属性的组件将扔到同一个进程中运行。最常见的使用场景，是通过配置&application&的process属性，将不同的相关应用，塞进一个进程，使得它们可以同生共死。还有就是将经常和某个Service组件进行通信的组件，放入同一个进程，因为与Service通信是个密集操作，走的是RPC，开销不小，通过配置，可以变成进程内的直接引用，消耗颇小。
除了通过&process&属性，不同的组件还有一些特殊的配置项，以Content Provider为例（通过&provider&项进行配置...）。&provider&项有一个mutiprocess的属性，默认值为false，这意味着Content Provider，仅会在提供该组件的应用所在进程构造一个实例，第三方想使用就需要经由RPC传输数据。这种模式，对于构造开销大，数据传输开销小的场合是非常适用的，并且可能提高缓存的效果。但是，如果是数据传输很大，抑或是希望在此提高传输的效率，就需要将mutiprocess设置成true，这样，Content Provider就会在每一个调用它的进程中构造一个实例，避免进程通信的开销。
既然，是Android系统帮助开发人员托管了进程，那么就需要有一整套纷繁的算法去执行回收逻辑。Android中各个进程的生死，和运行在其中的各个组件有着密切的联系，进程们依照其上组件的特点，被排入一个优先级体系，在需要回收时，从低优先级到高优先级回收。Android进程共分为五类优先级，分别是：Foreground Process, Visible Process, Service Process, Background Process, Empty Process。顾名思义不难看出，这说明，越和用户操作紧密相连的，越是正与用户交互的，优先级越高，越难被回收。具体详情，参见：
guide/topics/fundamentals.html#proclife。
有了优先级，还需要有良好的回收时机。回收太早，缓存命中概率低可能引起不断的创造进程销毁进程，池的优势荡然无存；回收的太晚，整体开销大，系统运行效率降低，好端端的法拉利可能被糟蹋成一枚QQ老爷车。Android的进程回收，最重要的是考量内存开销，以及电量等其他资源状况，此外每个进程承载的组件数量、单个应用开辟的进程数量等数量指标，也是作为衡量的一个重要标识。另外，一些运行时的时间开销，也被严格监控，启动慢的进程会很被强行kill掉。Android会定时检查上述参数，也会在一些很可能发生进程回收的时间点，比如某个组件执行完成后，来做回收的尝试。
从用户体验角度来看，Android的进程机制，会有很可喜的一面，有的程序
包含各类专业文献、幼儿教育、小学教育、文学作品欣赏、行业资料、中学教育、生活休闲娱乐、各类资格考试、应用写作文书、android的进程线程以及service远程调用47等内容。　
　android中线程与线程进程与进程之间如何通信_计算机...组件元素――&activity&、&service&、&receiver&、 ...这对 远程调用方法是正确的――如上一节讨论的 ... 　开始介绍之前,先看一下本例的界面: 1 Android 远程 Service 调用简介: 远程 Service 调用,是 Android 系统为了提供进程间通信而提供的轻量级实现方式,这 种方式... 　android 编写 Service 入门 android SDK 提供了 Service,用于类似*nix 守护进程...并不占用应用程序比如 Activity 所属线程,而是单开线程后台执行,这样用户 体验... 　Service 和其他的应用组件一样,运行在进程的主线程...不论调用了多少次 startService()方法,你只需要调用...远程服务 Remote Service 用于 android 系统内部的... 　在可用内存不足而又有一个正在为用户进行服务的进程...远程过程调用 Android 有一个轻量级的远程过程调用(...android的进程线程以及s... 8页 1下载券 android任务... 　这篇博客介绍一下 Android 下使用绑定服务进行时数据...但 它不仅用于远程调用,也可以用于进程内调用。这个...从工作线程持有一个主线程的 Handler 对象,从而向主... 　Android中进程和线程_计算机软件及应用_IT/计算机_专业...(3) 这个进程拥有一个前台运行的 Service (即 ...一 些远程调用的方法――例如 bound service。当... 　剖析Android中进程与线程调度之nice_计算机软件及应用_IT/计算机_专业资料。剖析...线程 是进程中实际执行单位,一个线程是程序执行流的最小单元。在一 个进程中... 　Android系统的进程和线程_计算机软件及应用_IT/计算机...(3) 这个进程拥有一个前台运行的 Service (即 ...一些远程调用的方法――例如 bound service。 当我们...极客学院问答精华-Android Service和Thread的区别是什么？_极客学院吧_百度贴吧
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&签到排名：今日本吧第个签到，本吧因你更精彩，明天继续来努力！
本吧签到人数：0可签7级以上的吧50个
本月漏签0次！成为超级会员，赠送8张补签卡连续签到：天&&累计签到：天超级会员单次开通12个月以上，赠送连续签到卡3张
关注：2,853贴子：
极客学院问答精华-Android Service和Thread的区别是什么？
一、Service　　Servie是系统的组件，它由系统进程托管（ServiceManager）；它们之间的通信类似于client和server，是一种轻量级的ipc通信，这种通信的载体是binder，它是在linux层交换信息的一种ipc。而Thread是由本应用程序托管。　　Service 是的一种机制，当它运行的时候如果是Local Service，那么对应的Service 是运行在主进程的 main 线程上的。如：onCreate，onStart 这些函数在被系统调用的时候都是在主进程的 main 线程上运行的。如果是Remote Service，那么对应的 Service 则是运行在独立进程的 main 线程上。　　1、服务不是单一的进程。服务没有自己的进程，应用程序可以不同，服务运行在相同的进程中。　　2、服务不是线程，但是可以在线程中工作。　　二、Thread　　Thread 是程序执行的最小单元，它是分配CPU的基本单位。可以用 Thread 来执行一些异步的操作。　　三、Service和Thread在什么情况下被使用　　1、在应用中，如果是长时间的在后台运行，而且不需要交互的情况下，使用服务。　　2、在后台运行，不需要交互的情况下，如果只是完成某个任务，之后就不需要运行，而且可能是多个任务，需需要长时间运行的情况下使用线程。　　3、如果任务占用CPU时间多，资源大的情况下，要使用线程。　　四、为什么要用Service　　因为Thread 的运行是独立于 Activity 的，也就是说当一个 Activity 被 finish 之后，如果你没有主动停止 Thread 或者 Thread 里的 run 方法没有执行完毕的话，Thread 也会一直执行。　　因此会出现一个问题：当 Activity 被 finish 之后，你不再持有该 Thread 的引用。另一方面，你没有办法在不同的 Activity 中对同一Thread 进行控制。　　这时创建并启动一个 Service ，在 Service 里面创建、运行并控制该 Thread，这样便解决了该问题。因为任何 Activity 都可以控制同一 Service，而系统也只会创建一个对应 Service 的实例。　　五、总结　　1、可以把 Service 想象成一种消息服务，可以在任何有 Context 的地方调用Context.startService、Context.stopService、Context.bindService、Context.unbindService控制Service。　　2、也可以在 Service 里注册 BroadcastReceiver，在其他地方通过发送 broadcast 来控制Service，当然这些都是 Thread 做不到的。
极客学院问答精华-Android Service和Thread的区别是什么？原址：
贴吧热议榜
使用签名档&&
保存至快速回贴Android中的进程和线程
o &nbsp,&nbsp&nbsp,&nbsp
默认地，一个app运行在一个进程和线程中。当一个app组件启动并且这个app没有任何组件在运行，android系统会启动一个新的Linux进程和一个main线程
如果一个app组件启动但是这个app已经有运行在一个进程中（因为有组件已经启动过），那么这个组件将运行在已经存在的那个进程并且使用相同的线程来执行。不过，你可以安排你的应用程序中不同的组件在单独的进程，并且你可以在任何进程中创建额外的线程。
1) 为组件安排进程
正如之前所说，默认地，一个app中的所有组件运行在同一个进程中。但是你也可以控制一个组件运行在哪个组件中
你需要做的：
在mainfest中配置activity, service, receiver, provider这四个元素都支持android:process,你可以使用这个属性来指定你一个组件运行在哪个进程中。
一般来说有三种情况：
所有的组件运行在一个进程中
同一个app中不同的组件共享一个进程
不同的app组件共享同一个进程（需要不同的app共享同一个linux user id并且用相同的证书签名）
application元素也支持此属性，指定了这个app下所有组件都运行在此进程
2) 进程会被杀死
在某些情况下，一个进程可能会被杀死。比如当内存极低的情况下，系统可能会杀死一些进程来保证正在和用户交互的进程能够正常运行
系统按照什么规则来决定哪些进程被杀死？
从用户的角度出发，越是对用户重要的越不容易被杀死。比如一个不可见活动所在的进程就比一个可见活动所在的进程容易被杀死。从系统的角度来看，这和组件的状态息息相关。
进程的生命周期：
android系统会尽可能长的维护一个app进程。但在一些极端情况下（内存不够）还是为了更重要的一些进程杀死一些不是那么重要的进程来回收内存。于是android系统就有了一个”重要性层级”（importance hierarch）。
根据这个重要性层级来决定哪些进程先被杀死哪些进程后被杀死。这个“重要性层级”基于进程中组件的运行状态
重要性层级都有哪些？
有五个，依次如下（从1-5重要性降低）：&
前台进程只有在最后时刻才会被杀死。当内存极低这些组件不能继续运行时，才会被杀死。通常在这个时 候，设备已经到达了内存分页状态。
前台进程的条件:&
进程的活动和用户正在交互（调用了onResume方法）
进程的Service绑定在一个和用户交互的活动
进程的Service运行在前台（Service调用了startForeground()方法）
进程的Service正在执行它的回掉方法(比如onCreate(),onStart(),onDestory()）
进程的BroadcastReceiver正在执行onReceive方法
服务进程没有任何前台进程的组件，但是仍然影响着用户所见。
服务进程也是很重要的，通常不会被杀死，除非系统在极端情况下需要保证前台进程正常运行
服务进程的条件：&
进程的活动不再在前台。但是用仍然可见，比如一个dialog在这个活动之上。
进程的服务绑定在一个可见活动（前台活动）上
当一个服务的进程通过startService()方法启动并且不属于之前的两个高级别。用户是不能直接看到的，但是它们所做的事情用户是关心的。比如音乐后台播放，下载东西。
当一个进程的活动不再对用户可见（onStop()被调用)。
通常有很多的后台进程。他们被杀死的规则：最近最少用。
空进程不持有任何组件。这类进程活着的唯一原因是缓存作用。系统常常杀死这些进程以平衡整个系统的资源 在进程缓存和内核底层缓存
一个进程可能有多个不同的组件，这些组件被规划到不同的“重要性层级”，这种情况下，系统会将此进程排列到相对最高的“重要性层级”。比如一个进程有一个不可见活动和一个前台活动，那么这个进程的重要性层级就是“前台进程”
如果一个后台活动开始长时间的操作，最好是为这个操作开启一个服务，而不是简单的使用工作者线程。这样可以保证此进程有一个“服务进程”的级别。
当一个app启动的时候，系统会创建一个线程，这个线程叫做 main thread。这个线程非常重要，因为它负责调度事件到合适的用户界面部件（widgets）。
Android UI toolkit 的组件（android.view,android.widget这两个包下的）也都运行在main thread，所以main thread也被称作UI thread
android系统不给组件创建单独的线程。所有的组件都运行在它们自己进程的UI线程中。系统调用的每一个组件都是从UI线程调度的，因此，响应系统回调的方法总是运行在ui thread中（比如button的onclick)
当响应用户交互时你的app执行密集的工作，单线程模式(只有main thread)是非常不合适的。
比如在ui thread中执行网络操作，数据库查询等，可能会阻塞ui响应。当ui thread阻塞超过一定时间（目前是超过5s），会提示用户“应用程序无响应” “application not responding” (ANR)
android ui toolkit不是线程安全的。所以不能使用工作者线程来操作ui。
android 单线程模式的两个规则：
1：不要阻塞ui
2：不要从外部ui线程访问android ui toolkit
举个例子：
public void onClick(View v) {
new Thread(new Runnable() {
public void run() {
Bitmap b = loadImageFromNetwork("/image.png");
mImageView.setImageBitmap(b);
}).start();
public void onClick(View v) {&&&&new Thread(new Runnable() {&&&&&&&&public void run() {&&&&&&&&&&&&Bitmap b = loadImageFromNetwork("/image.png");&&&&&&&&&&&&mImageView.setImageBitmap(b);&&&&&&&&}&&&&}).start();}
如上代码看起来似乎没什么问题。但是它违反了第二天规则。从外部线程访问了android ui toolkit（在新创建的线程中修改了ImageView）,这可能会导致意外的行为。
为了解决这个问题，android提供了一些方法来支持从外部thread访问android ui toolkit.
1)Activity.runOnUiThread(Runnable r)
2)View.Post(Runnable r)
3)View.PostDelayed(Runnable r, long l)
可以通过这三种途径来修改之前的例子
public void onClick(View v) {
new Thread(new Runnable() {
public void run() {
final Bitmap bitmap =
loadImageFromNetwork("/image.png");
mImageView.post(new Runnable() {
public void run() {
mImageView.setImageBitmap(bitmap);
}).start();
12345678910111213
public void onClick(View v) {&&&&new Thread(new Runnable() {&&&&&&&&public void run() {&&&&&&&&&&&&final Bitmap bitmap =&&&&&&&&&&&&&&&&&&&&loadImageFromNetwork("/image.png");&&&&&&&&&&&&mImageView.post(new Runnable() {&&&&&&&&&&&&&&&&public void run() {&&&&&&&&&&&&&&&&&&&&mImageView.setImageBitmap(bitmap);&&&&&&&&&&&&&&&&}&&&&&&&&&&&&});&&&&&&&&}&&&&}).start();}
现在该实现是线程安全的。网络操作是在一个单独的线程中进行，而imageview的改变在从UI thread中进行
使用AsyncTask
然而对于一些复杂的线程操作，这样做可能很难维护。你可能会想到使用Handler在work thread中处理来自ui thread的消息。也许最好的解决方案是使用AsyncTask
AsyncTask基本使用：
1）继承AsyncTask类
2）实现doInBackground()方法
3）如果要进行ui更新，实现onPostExecute(T t)方法。此方法会接受doInBackground()方法的返回结果，并且运行在UI线程中
public void onClick(View v) {
new DownloadImageTask().execute("/image.png");
private class DownloadImageTask extends AsyncTask {
//这个方法在work-thread中执行。在这个方法中图片下载
//这个方法的结果会传递给onPostExecute方法。onPostExecute方法执行在UI thread中
protected Bitmap doInBackground(String... urls) {
return loadImageFromNetwork(urls[0]);
/** The system calls this to perform work in the UI thread and delivers
* the result from doInBackground() */
protected void onPostExecute(Bitmap result) {
mImageView.setImageBitmap(result);
1234567891011121314151617
public void onClick(View v) {&&&&new DownloadImageTask().execute("/image.png");}&private class DownloadImageTask extends AsyncTask {&&&&//这个方法在work-thread中执行。在这个方法中图片下载&&&&//这个方法的结果会传递给onPostExecute方法。onPostExecute方法执行在UI thread中&&&&protected Bitmap doInBackground(String... urls) {&&&&&&&&return loadImageFromNetwork(urls[0]);&&&&}&&&&&/** The system calls this to perform work in the UI thread and delivers&&&&&&* the result from doInBackground() */&&&&protected void onPostExecute(Bitmap result) {&&&&&&&&mImageView.setImageBitmap(result);&&&&}}
关于伯乐小组
这里有好的话题，有启发的回复和值得信任的圈子。
新浪微博：
推荐微信号
（加好友请注明来意）
- 好的话题、有启发的回复、值得信赖的圈子
- 分享和发现有价值的内容与观点
- 为IT单身男女服务的征婚传播平台
- 优秀的工具资源导航
- 翻译传播优秀的外文文章
- 国内外的精选博客文章
- UI,网页，交互和用户体验
- 专注iOS技术分享
- 专注Android技术分享
- JavaScript, HTML5, CSS
- 专注Java技术分享
- 专注Python技术分享
& 2016 伯乐在线