前言 对于移动开发者来说，“将耗时的任务放到子线程去执行，以保证UI线程的流畅性”是线程编程的第一金科玉律，但这条铁则往往也是UI线程不怎么流畅的主因。我们在督促自己更多的使用
前言
对于移动开发者来说，“将耗时的任务放到子线程去执行，以保证UI线程的流畅性”是线程编程的第一金科玉律，但这条铁则往往也是UI线程不怎么流畅的主因。我们在督促自己更多的使用线程的同时，还需要时刻提醒自己怎么避免线程失控。
多线程编程之所以复杂原因之一在于其并行的特性，人脑的工作方式更符合单线程串行的特点。一个接着一个的处理任务是大脑最舒服的状态，频繁的在任务之间切换会产生“头痛”这类系统异常。人脑的多任务和计算机的多任务性能差异太大导致我们在设计并行的业务逻辑之时，很容易犯错。
另一个复杂点在于线程所带来的副作用，这些副作用包括但不限于：多线程数据安全，死锁，内存消耗，对象的生命周期管理，UI的卡顿等。每一个新开的线程就像扔进湖面的石子，在你忽视的远处产生涟漪。
把抽象的东西具像化是我们认知世界的主要方式。线程作为操作系统世界的“公民”之一，是如何被调度获取到CPU和内存资源的，又怎么样去和其他“公民”互通有无进而实现效益最大化？把这些实体和行为具像到大脑，像操作系统一样开“上帝视角”，才能正确掌控线程这头强大的野兽。
进程优先级（Process Priority）
线程寄宿在进程当中，线程的生命周期直接被进程所影响，而进程的存活又和其优先级直接相关。在处理进程优先级的时候，大部分人靠直觉都能知道前台进程（Foreground Process）优先级要高于后台进程（Background Process）。但这种粗糙的划分无法满足操作系统高精度调度的需求。无论Android还是iOS，系统对于Foreground，Background进程有进一步的细化。
Foreground Process
Foreground一般意味着用户双眼可见，可见却不一定是
activeinputactiveDialogDialogactiveactivityinactivevisibleactiveBackground Process
后台进程同样有更细的划分。所谓的Background可以理解为不可见（invisible）。对于不可见的任务，Android也有重要性的区分。重要的后台任务定义为
ServiceServiceService在ioS的世界里，
MemoryClean MemoryDirty MemoryClean Memorystack, heap, text, datasegment，Dirty MemoryClean Memory同理Android世界当中的Empty Process还保存有App相关的
Clean Memory综上所述，我们可以把Android世界的Process按优先级分为如下几类：
进程的优先级从高到低依次分为五类，越往下，在内存紧张的时候越有可能被系统杀掉。简而言之，越是容易被用户感知到的进程，其优先级必定更高。
线程调度（Thread Scheduling）
Android系统基于精简过后的linux内核，其线程的调度受时间片轮转和优先级控制等诸多因素影响。不少初学者会认为某个线程分配到的time slice多少是按照其优先级与其它线程优先级对比所决定的，这并不完全正确。
Linux系统的调度器在分配
time sliceCFS（completely fair scheduler）time slicetime slicecgroupscgroupstime sliceAndroid将线程分为多个
groupgroupdefault groupbackground group。background grouptime slicedefault group
有不少人吐槽Android系统之所以不如iOS流畅，是因为UI线程的优先级和普通工作线程一致导致的。这其实是个误会，Android的设计者实际上提供了
background groupbackground group
new Thread(new Runnable() {
@Override
public void run() {
Process.setThreadPriority(Process.THREAD_PRIORITY_BACKGROUND);
}
}).start();所以在我们决定新启一个线程执行任务的时候，首先要问自己这个任务在完成时间上是否重要到要和UI线程争夺CPU资源。如果不是，降低线程优先级将其归于
background group虽说Android系统在任务调度上是以线程为基础单位，设置单个
threadcontrol groupsCPU time slicebackground groupforeground
$ adb shell ps -P当你的App重新被用户切换到前台的时候，进程当中所属的线程又会回归的原来的
groupthreadtime slice是否真的需要新线程？
开线程并不是提升App性能，解决UI卡顿的万金油。每一个新启的线程会消耗至少64KB的内存，系统在不同的线程之间
switch context移动端App新启线程一般都是为了保证UI的流畅性，增加App用户操作的响应度。但是否需要将任务放入工作线程需要先了解任务的瓶颈在哪，是i/o，gpu还是cpu？UI出现卡顿并不一定是UI线程出现了费时的计算，有可能是其它原因，比如layout层级太深。
尽量重用已有的工作线程（使用线程池）可以避免出现大量同时活跃的线程，比如对Http请求设置最大并发数。或者将任务放入某个串行的队列（HandlerThread）按顺序执行，工作线程任务队列适合处理大量耗时较短的任务，避免出现单个任务阻塞整个队列的情况。
用什么姿势开线程？
new Thread()这是Android系统里开线程最简单的方式，也只能应用于最简单的场景，简单的好处却伴随不少的隐患。
new Thread(new Runnable() {
@Override
public void run() {
}
}).start();这种方式仅仅是起动了一个新的线程，没有任务的概念，不能做状态的管理。start之后，run当中的代码就一定会执行到底，无法中途取消。
Runnable作为匿名内部类还持有了外部类的引用，在线程退出之前，该引用会一直存在，阻碍外部类对象被GC回收，在一段时间内造成内存泄漏。
没有线程切换的接口，要传递处理结果到UI线程的话，需要写额外的线程切换代码。
如果从UI线程启动，则该线程优先级默认为
Defaultdefault cgroup
Process.setThreadPriority(Process.THREAD_PRIORITY_BACKGROUND);虽说处于
background groupbackground groupAsyncTask
一个典型的AsyncTask实现如下：
public class MyAsyncTask extends AsyncTask {
@Override
protected Object doInBackground(Object[] params) {
return null;
}
@Override
protected void onPreExecute() {
super.onPreExecute();
}
@Override
protected void onPostExecute(Object o) {
super.onPostExecute(o);
}
}和使用
Thread()ImageViewAsyncTask的几处回调都给了我们机会去中断任务，在任务状态的管理上较之
Thread()cancel()cancelAsyncTask也有隐式的持有外部类对象引用的问题，需要特别注意防止出现意外的内存泄漏。
AsyncTask由于在不同的系统版本上串行与并行的执行行为不一致，被不少开发者所诟病，这确实是硬伤，绝大部分的多线程场景都需要明确任务是串行还是并行。
线程优先级为
backgroundHandlerThread
在需要对多任务做更精细控制，线程切换更频繁的场景之下，
Thread()AsyncTaskHandlerThread将
HandlerThreadLooperMessageQueuemessagerunnablehandler postLooperMessageQueuepostMessageQueueHandlerThread背后只有一个线程，所以任务是串行执行的。串行相对于并行来说更安全，各任务之间不会存在多线程安全问题。
HandlerThread所产生的线程会一直存活，Looper会在该线程中持续的检查
MessageQueueThread()，AsyncTaskHandlerThreadThread()，AsyncTaskThreadPoolExecutor
Thread(),AsyncTask
public static Executor THREAD_POOL_EXECUTOR
= new ThreadPoolExecutor(CORE_POOL_SIZE, MAXIMUM_POOL_SIZE, KEEP_ALIVE,
TimeUnit.SECONDS, sPoolWorkQueue, sThreadFactory);线程池可以避免线程的频繁创建和销毁，显然性能更好，但线程池并发的特性往往也是疑难杂症的源头，是代码降级和失控的开始。多线程并行导致的bug往往是偶现的，不方便调试，一旦出现就会耗掉大量的开发精力。
ThreadPool较之HandlerThread在处理多任务上有更高的灵活性，但也带来了更大的复杂度和不确定性。
IntentService
不得不说Android在API设计上粒度很细，同一样工作可以通过各种不同的类来完成。
IntentServiceserviceAsyncTaskMessage QueueonCreate
@Override
public void onCreate() {
// TODO: It would be nice to have an option to hold a partial wakelock
// during processing, and to have a static startService(Context, Intent)
// method that would launch the service & hand off a wakelock.
super.onCreate();
HandlerThread thread = new HandlerThread("IntentService[" + mName + "]");
thread.start();
mServiceLooper = thread.getLooper();
mServiceHandler = new ServiceHandler(mServiceLooper);
}只不过在所有的
MessageIntentServiceServiceHandlerThread总结
Android开线程的方式虽然五花八门，但归根到底最后还是映射到linux下的pthread，业务的设计还是脱不了和线程相关的基础概念范畴：线程的执行顺序，调度策略，生命周期，串行还是并行，同步还是异步等等。摸清楚各类API下线程的行为特点，在设计具体业务的线程模型的时候自然轻车熟路了，线程模型的设计要有整个app视角的广度，切忌各业务模块各玩各的。以上就是本文的全部内容，希望对大家开发Android能有所帮助，如果有疑问欢迎大家留言讨论。
您可能感兴趣的文章:全面总结Android中线程的异步处理方式Android 中三种启用线程的方法总结
--结束END--
本文标题: 如何正确使用Android线程详解
本文链接: https://lsjlt.com/news/24313.html(转载时请注明来源链接)
有问题或投稿请发送至: 邮箱/279061341@qq.com QQ/279061341
2024-01-21
2023-10-28
2023-10-28
2023-10-27
2023-10-27
2023-10-27
2023-10-27
回答
回答
回答
回答
回答
回答
回答
回答
回答
回答
官方手机版
微信公众号
商务合作
0