flutter线程池,flutter 线程

做混合的话Uniapp和Flutter我应该学哪个啊？

Uniapp目前比较成熟，而且用的是Vue语法，学习成本比较低，而且行业里面用的也比较广泛，而Flutter的话，学习成本略高，因为要学习新的语言，还有就是目前生态不是特别完备，等他再发展发展吧。黑马程序员官网有成套免费视频哦，有什么不懂的可以直接过去学习。您的采纳是对我成长的鞭策

我们一直强调成都网站设计、网站制作对于企业的重要性,如果您也觉得重要,那么就需要我们慎重对待,选择一个安全靠谱的网站建设公司,企业网站我们建议是要么不做，要么就做好,让网站能真正成为企业发展过程中的有力推手。专业网站设计公司不一定是大公司,成都创新互联公司作为专业的网络公司选择我们就是放心。

Flutter 异步加载数据，UI卡顿

记录下坑

一开始我就使用Future、async、await去做异步操作，以为这样能解决问题，经过一天研究发现他们都还在同一个线程里面，也就是UI线程，导致卡顿，这明显不是我们想要的异步加载数据。

Dart真正的线程叫隔离（Isolate）

难受香菇

有点心累，记录下吧。

Flutter浪潮下的音视频研发探索

文/陈炉军

整理/LiveVideoStack

大家好，我是阿里巴巴闲鱼事业部的陈炉军，本次分享的主题是Flutter浪潮下的音视频研发探索，主要内容是针对闲鱼APP在当下流行的跨平台框架Flutter的大规模实践，介绍其在音视频领域碰到的一些困难以及解决方案。

分享内容主要分为四个方面，首先会对Flutter有一个简单介绍以及选择Flutter作为跨平台框架的原因，其次会介绍Flutter中与音视频关系非常大的外接纹理概念，以及对它做出的一些优化。之后会对闲鱼在音视频实践过程中碰到的一些Flutter问题提出了一些解决方案——TPM音视频框架。最后是闲鱼Flutter多媒体开源组件的介绍。

Flutter

Flutter是一个跨平台框架，以往的做法是将音频、视频和网络这些模块都下沉到C++层或者ARM层，在其上封装成一个音视频的SDK，供UI层的PC、iOS和Android调用。

而Flutter做为一个UI层的跨平台框架，顾名思义就是在UI层也实现了一个跨平台开发。可以预想的是未Flutter发展的好的话，会逐渐变为一个从底层到UI层的一个全链路的跨平台开发，技术人员分别负责SDK和UI层的开发。

在Flutter之前已经有很多跨平台UI解决方案，那为什么选择Flutter呢？

我们主要考虑性能和跨平台的能力。

以往的跨平台方案比如Weex，ReactNative，Cordova等等因为架构的原因无法满足性能要求，尤其是在音视频这种性能要求几乎苛刻的场景。

而诸如Xamarin等，虽然性能可以和原生App一致，但是大部分逻辑还是需要分平台实现。

我们可以看一下，为什么Flutter可以实现高性能：

原生的native组件渲染以IOS为例，苹果的UIKit通过调用平台自己的绘制框架QuaztCore来实现UI的绘制，图形绘制也是调用底层的API,比如OpenGL、Metal等。

而Flutter也是和原生API逻辑一致，也是通过调用底层的绘制框架层SKIA实现UI层。这样相当于Flutter他自己实现了一套UI框架，提供了一种性能超越原生API的跨平台可能性。

但是我们说一个框架最终性能怎样，其实取决于设计者和开发者。至于现在到底是一个什么状况：

在闲鱼的实践中，我们发现在正常的开发没有特意的去优化UI代码的情况下，在一些低端机上，Flutter界面的流畅性是比Native界面要好的。

虽然现在闲鱼某些场景下会有卡顿闪退等情况，但是这是一个新事物发展过程中的必然问题，我们相信未来性能肯定不会成为限制Flutter发展的瓶颈的。

在闲鱼实践Flutter的过程中，混合栈和音视频是其中比较难解决的两个问题，混合栈是指一个APP在Flutter过程中不可能一口气将所有业务全部重写为Flutter，所以这是一个逐步迭代的过程，这期间原生native界面与Flutter界面共存的状态就称之为混合栈。闲鱼在混合栈上也有一些比较好的输出，例如FlutterBoost。

外接纹理

在讲音视频之前需要简要介绍一下外接纹理的概念，我们将它称之为是Flutter和Frame之间的桥梁。

Flutter渲染一帧屏幕数据首先要做的是，GPU发出的VC信号在Flutter的UI线程，通过AOT编译的机器码结合当前Dart Runtime，生成Layer Tree UI树，Layer Tree上每一个叶子节点都代表了当前屏幕上所需要渲染的每一个元素，包含了这些元素渲染所需要的内容。将Layer Tree抛给GPU线程，在GPU线程内调用Skia去完成整个UI的渲染过程。Layer Tree中有PictureLayer和TextureLayer两个比较重要的节点。PictureLayer主要负责屏幕图片的渲染，Flutter内部实现了一套图片解码逻辑，在IO线程将图片读取或者从网络上拉取之后，通过解码能够在IO线程上加载出纹理，交给GPU线程将图片渲染到屏幕上。但是由于音视频场景下系统API太过繁多，业务场景过于复杂。Flutter没有一套逻辑去实现跨平台的音视频组件，所以说Flutter提出了一种让第三方开发者来实现音视频组件的方式，而这些音视频组件的视频渲染出口，就是TextureLayer。

在整个Layer Tree渲染的过程中，TextureLayer的数据纹理需要由外部第三方开发者来指定，可以把视频数据和播放器数据送到TextureLayer里，由Flutter将这些数据渲染出来。

TextureLayer渲染过程：首先判断Layer是否已经初始化，如果没有就创建一个Texture，然后将Texture Attach到一个SufaceTexture上。

这个SufaceTexture是音视频的native代码可以获取到的对象，通过这个对象创建的Suface，我们可以将视频数据、摄像头数据解码放到Suface中，然后Flutter端通过监听SufaceTexture的数据更新就可以顺利把刚才创建的数据更新到它的纹理中，然后再将纹理交给SKIA渲染到屏幕上。

然而我们如果需要用Flutter实现美颜，滤镜，人脸贴图等等功能，就需要将视频数据读取出来，更新到纹理中，再将GPU纹理经过美颜滤镜处理后生成一个处理后的纹理。按Flutter提供的现有能力，必须先将纹理中的数据从GPU读出到CPU中，生成Bitmap后再写入Surface中，这样在Flutter中才能顺利的更新到视频数据，这样做对系统性能的消耗很大。

通过对Flutter渲染过程分析，我们知道Flutter底层需要渲染的数据就是GPU纹理，而我们经过美颜滤镜处理完成以后的结果也是GPU纹理，如果可以将它直接交给Flutter渲染，那就可以避免GPU-CPU-GPU这样的无用循环。这样的方法是可行的，但是需要一个条件，就是OpenGL上下文共享。

OpenGL

在说上下文之前，得提到一个和上线文息息相关的概念：线程。

Flutter引擎启动后会启动四个线程：

第一个线程是UI线程，这是Flutter自己定义的UI线程，主要负责GPU发出的VSync信号时候用当前Dart编译的机器码和当前运行环境创建出Layer Tree。

还有就是IO线程和GPU线程。和大部分OpenGL处理解决方案中一样，Flutter也采取一个线程责资源加载，一部分负责资源渲染这种思路。

两个线程之间纹理共享有两种方式。一种是EGLImage(IOS是 CVOpenGLESTextureCache)。一种是OpenGL Share Context。Flutter通过Share Context来实现纹理共享，将IO线程的Context和GPU线程的Context进行Share，放到同一个Share Group下面，这样两个线程下资源是互相可见可以共享的。

Platform线程是主线程，Flutter中有一个很奇怪的设定，GPU线程和主线程共用一个Context。并且在主线程也有很多OpenGL 操作。

这样的设计会给音视频开发带来很多问题，后面会详细说。

音视频端美颜处理完成的OpenGL纹理能够让Flutter直接使用的条件就是Flutter的上下文需要和平台音视频相关的OpenGL上下文处在一个Share Group下面。

由于Flutter主线程的Context就是GPU的Context，所以在音视频端主线程中有一些OpenGL操作的话，很有可能使Flutter整个OpenGL被破坏掉。所以需要将所有的OpenGL操作都限制在子线程中。

通过上述这两个条件的处理，我们就可以在没有增加GPU消耗的前提下实现美颜和滤镜等等功能。

TPM

在经过demo验证之后，我们将这个方案应用到闲鱼音视频组件中，但改造过程中发现了一些问题。

上图是摄像头采集数据转换为纹理的一段代码，其中有两个操作：首先是切进程，将后面的OpenGL操作都切到cameraQueue中。然后是设置一次上下文。然后这种限制条件或者说是潜规则往往在开发过程中容易被忽略的。而这个条件一旦忽略后果就是出现一些莫名其妙的诡异问题极难排查。因此我们就希望能抽象出一套框架，由框架本身实现线程的切换、上下文和模块生命周期等的管理，开发者接入框架以后只需要安心实现自己的算法，而不需要关心这些潜规则还有其他一些重复的逻辑操作。

在引入Flutter之前闲鱼的音视频架构与大部分音视频逻辑一样采用分层架构：

1：底层是一些独立模块

2：SDK层是对底层模块的封装

3：最上层是UI层。

引入Flutter之后，通过分析各个模块的使用场景，我们可以得出一个假设或者说是抽象：音视频应用在终端上可以归纳为视频帧解码之后视频数据帧在各个模块之间流动的过程，基于这种假设去做Flutter音视频框架的抽象。

咸鱼Flutter多媒体开源组件

整个Flutter音视频框架抽象分为管线和数据的抽象、模块的抽象、线程统一管理和上下文同一管理四部分。

管线，其实就是视频帧流动的管道。数据，音视频中涉及到的数据包括纹理、Bit Map以及时间戳等。结合现有的应用场景我们定义了管线流通数据以Texture为主数据，同时可以选择性的添加Bit Map等作为辅助数据。这样的数据定义方式，避免重复的创建和销毁纹理带来的性能开销以及多线程访问纹理带来的一些问题。也满足一些特殊模块对特殊数据的需求。同时也设计了纹理池来管理管线中的纹理数据。

模块：如果把管线和数据比喻成血管和血液，那框架音视频的场景就可以比喻成器官，我们根据模块所在管线的位置抽象出采集、处理和输出三个基类。这三个基类里实现了刚才说的线程切换，上下文切换，格式转换等等共同逻辑，各个功能模块通过集成自这些基类，可以避免很多重复劳动。

线程：每一个模块初始化的时候，初始化函数就会去线程管理的模块去获取自己的线程，线程管理模块可以决定给初始化函数分配新的线程或者已经分配过其他模块的线程。

这样有三个好处：

一是可以根据需要去决定一个线程可以挂载多少模块，做到线程间的负载均衡。第二，多线程并发式能够保证模块内的OpenGL操作是在当前线程内而不会跑到主线程去，彻底避免Flutter的OpenGL 环境被破坏。第三，多线程并行可以充分利用CPU多核架构，提升处理速度。

从Flutter端修改Flutter引擎将Context取出后，根据Context创建上下文的统一管理模块，每一个模块在初始化的时候会获取它的线程，获取之后会调用上下文管理模块获取自己的上下文。这样可以保证每一个模块的上下文都是与Flutter的上下文进行Share的，每个模块之间资源都是共享可见的，Flutter和音视频native之间也是互相共享可见的。

基于上述框架如果要实现一个简单的场景，比如画面实时预览和滤镜处理功能，

1：需要选择功能模块，功能模块包括摄像头模块、滤镜处理模块和Flutter画面渲染模块，

2：需要配置模块参数，比如采集分辨率、滤镜参数和前后摄像头设置等，

3：在创建视频管线后使用已配置的参数创建模块

4：最后管线搭载模块，开启管线就可以实现这样简单的功能。

上图为整个功能实现的代码和结构图。

结合上述音视频框架，闲鱼实现了Flutter多媒体开源组件。

组要包含四个基本组件分别是：

1：视频图像拍摄组件

2：播放器组件

3：视频图像编辑组件

4：相册选择组件

现在这些组件正在走内部开源流程。预计9月份，相册和播放器会实现开源。

后续展望和规划

1：实现开头所说的从底层SDK到UI的全链路的跨端开发。目前底层框架层和模块层都是各个平台各自实现，反而是Flutter的UI端进行了跨平台的统一，所以后续会将底层也按照音视频常用做法把逻辑下沉到C++层，尽可能的实现全链路跨平台。

2：第二部分内容为开源共建，闲鱼开源的内容不仅包括拍摄、编辑组件，还包括了很多底层模块，希望有开发者在基于Flutter开发音视频应用时可以充分利用闲鱼开源出的音视频模块能力，搭建APP框架，开发者只要去负责实现特殊需求模块就可以，尽可能的减少重复劳动。

那些 40 岁的程序员都去哪了？

前些时候北京市政府做了一个关于 996 的调研，第一时间我参与了调研，同时发到所有读者群，让大家一起发声。

不少朋友开始热烈的讨论起来，有人很乐观认为这是改变的开始，也有人觉得这就是走一个形式。 不管怎么说，也算看到政府针对这个问题开始有行动了。

其实 996 最残酷的一点是：年纪大的人很容易被无情淘汰。中国互联网的 35 岁危机是和 996 盛行分不开的。

996 对于打工人来说，绝不可能常态化！

为什么不能常态化？ 从生理规律上看，脑力劳动者如果不以进 ICU 为目标，那么每天能够认真投入的时间，八小时也就到极限了。 人毕竟不是机器，是血肉之躯！

但中国老板普遍希望程序们 996，别激动别骂，这是残酷的现实。

同时中国老板们偏爱年轻人，为什么？很简单，老了之后，你舔活速度显然没有年轻人来的卖力，来的凶猛！长年累月的辛苦劳作，已经让你这颗螺丝钉生锈甚至发霉了！如果你是老板，这个时候你还要支付比年轻人多 2 倍的薪资，你怎么选？

更别提，年纪这么大的你，还有各种猝死风险 ，拿最近的 pdd 猝死事件来说，在超级大小周（996+997）的压力下，这么年轻的女孩都猝死了，更何况 40 岁的一线码农？那猝死率该得多高了？企业的商誉还要不要了？

显然，资本家一定会作出最商业最正确的选择：年轻人，甚至是刚毕业的大学生，这些最新鲜的韭菜才是他们的最爱。

所以，对于打工人尤其程序员而言，996 本身反而不是最大问题，最大问题是我们如何跨越大龄危机。

相比等待环境发生改变，不如主动思考清楚这个问题。

想起去年写过的一篇旧文，再次分享给大家，讲的是我身边五个大龄程序员的故事，绝对真实的经历分享，有洋哥的同学、朋友、下属，他们都成功的跨越了 35 岁危机，希望他们的经历对大家有一点点启发：

1.沉迷是一种力量

第一次见 A 君是 10 年前参加人人网的面试，他是面试官，那个时候 A 君 35 岁，担任后端 leader。入职后，我发现，他用于做管理的时间不多，90% 时间在疯狂编码。

A 君基本没有社交，上班就是撸代码，下班就是回家带孩子。他对优秀的工程师容忍度极高，对差一点的完全没耐心。

偶尔能听见他训斥下属的吵闹声：“这个类写成这样，你没看代码规范吗？”、“这个线程池不能这么用，给你说多少次了！”、“是你没听清楚还是我没讲清楚？不能这么干！”。

一次下班，和他一起回家，一路上给我讲各种编程技巧和方法论，我听的津津有味。聊了差不多半小时，心想可以换个话题了，于是我问：“您周末 娱乐 都干些什么呢？”，他是这样回答的：“我会去看些开源代码，自己改着玩很有趣”。那一刻，空气都凝固了，这话我实在没法接下去了。

后来有一天，A 君上班拍桌子，暴怒之后冲了出去。大家一脸懵逼，后来才知道，原来是大 Boss 批评他不懂管理，只知道埋头写代码。

几年前，和他在微信聊了一次。他去了一家创业公司做技术负责人，我很好奇，很想知道这次他是怎么做管理的。

我问他：“您现在是怎么带团队的”，这一问不要紧，聊了半小时。从 Flutter 的优越性到微服务的落地，再到 Google 出了什么新技术，顺带鄙视了一些还在用落后技术的公司。一顿硬核技术科普下来，收获挺大，但是管理这两个字？嗯，不存在的。

我现在理解了，他压根就不关心管理，聚集一帮极客跟他一起成长战斗才是最开心的事情。

A 君今年快 50 了，前不久和其他人聊起他，大家都感叹，这老哥战斗力太强了，真是那种一顶十的程序员。

有时候，沉迷是一种力量，焦虑？不存在的.....

想起 A 君给我说的那句：“我要开心 coding 到 80！”。我真心相信他能做到。

2.不服就是干

这次说说我的好朋友 B 君，今年 40 岁，曾经鹅场的高级工程师，7 年前，晋升失败一怒之下开启了创业之路。

我们是在 CSDN 论坛上认识的，他帮我解决了一个底层操作系统级的防劫持问题。后来经常问他一些排查线上故障的方法论、微服务怎么拆分、如何做出能抗更高并发的架构，他都非常耐心的指导我，他还有句口头禅：不服就是干！

B 君出来创业没拿融资，自己投了 100 万。团队 5 个人，挤在一个很小的民房。创业期间找他喝酒，他告诉我：“我一定要改变世界，否则我会被世界改变”。

一年后，再次去找他喝酒，这次他脸色灰暗，人也非常低迷。原来前期 100 万烧完，又投入了 50 万积蓄，项目还是没有做成。酒过半巡，他突然抱着我哭了起来，我这才得知因为积蓄全部烧完，他女朋友已经和他分手了。

再后来，他回到大厂当程序员，级别薪资跟创业前相差无几。谈起创业经历，我为他惋惜，而他并不后悔。

两年前，他开始炒比特币，炒着炒着嫌这些交易平台做得都不够好，于是空余时间动手做了一个交易平台。

去年，B 君告诉我，他的交易平台融资 500 万，再次出来创业。第二次创业，他已平和很多，没有豪言壮语，让公司活下去是最大目标。

今年听说 B 君的公司已经快 30 人了，为他祝福，相信他一定能改变世界。

有时候，我们需要点不服就是干的精神！

3.反焦虑

这次上场的是 C 君，硕士师兄，40 岁。C 君是一名大厂总监，他花了四年时间跳了三次才来到当下的这家大厂扎根下来，带 100 人团队，每个月安安稳稳拿高薪，不用担心公司倒闭的风险。

以 C 君的专业技能和学历背景、工作经历，其实完全不需要担心没工作。可他总是莫名担忧，害怕自己没有创造更多价值。

100 人的团队不是那么好带，除了技术之外还需要精通业务产品、精通组织流程、掌握良好的沟通推动技巧、在大厂还需要明争暗斗。

一次和 C 君聊天，他感叹到：“还是写代码有安全感，做管理不仅心累还觉得自己没创造价值”，可不是，这种焦虑几年前我也感同深受。

大厂的高 P 看起来风光无比，其实要跳槽也不容易，毕竟中小公司能接得住大厂高 P 薪资期权总包的，并不多。

有时候，不是现在取得了成就就会开心，决定因素是你未来会不会更好，如果答案是否定的，不仅不会开心还有可能带来焦虑。

C 君就陷入这种焦虑当中，总是担心未来的上升空间和 40 岁以后的收入。特别是大厂还有年龄线的要求，到一定年龄不能晋升就有可能被淘汰。

有一段时间，公司领导层波动，他面临被连带的危险，甚至需要依靠抗抑郁的药物。但最终他依靠持续有规律的运动和学习新领域克服过来。

C 君给我提的最多的话： “反焦虑很重要”， 是啊，真的重要，从 C 君身上我真正学到了一点：无论你是否能成功，首先要反焦虑。

4.舍命狂奔

这次要说的是清华 MBA 同学 D 君，39 岁。他在通讯行业干了 10 多年，超级专家那种，带十人团队。

问起他读 MBA 的原因，他很坚定的说：“我对投资非常感兴趣，就是为了转行投资才这么大年纪了还选择读书”。

清华 MBA 课程安排的很紧张，我们都是六日班，也就周六半天周日全天，而他公司的工作非常忙，几乎 996，但从没见过他迟到过一次。

三年时光，D 君在跟时间赛跑，小组讨论、企业访谈、课程作业，他都完成的堪称完美。有一次我问他，你为什么这么拼？他说，当你笃定一件事，确定一个目标，那剩下的只有舍命狂奔。

毕业后，D 君如愿以偿加入一家投行，当上了投资人。有一次很好奇的问他投资人的收入，他告诉我刚入行薪资很低，只有之前做架构师带团队的 1/3。但他说这话的时候，一脸幸福感。

去年 D 君已经晋升为所在机构的合伙人级别，为他感到开心。

5.接受现实

最后上场的是老同事 E 君，41 岁。他是那种职场老黄牛。属于领导让做什么就做什么的人，任劳任怨勤勤恳恳，但个人成长一直比较缓慢。

前几年开始 E 君就不太顺了，因为编码能力一直没有达到高级或者架构师水平。他其实一直在跟年轻人拼体力，而随着年龄增大，是真拼不过了。我和他经常讨论的话题是颈椎病如何康复。

去年 E 君所在公司效益不太好，领导决定裁员，他进入了优化名单。被优化后，他休息整顿了好久，将原来 90kg 的体重减到现在的 75kg，颈椎病也恢复不少。再开始找工作，大概花了几个月时间，他终于找到了一个不那么满意的 Offer。

听到他找到下家的消息，我还挺为他开心的，因为这个过程我也帮他各种投简历，但大佬朋友们一听说 41 岁还是中级水平，都不太愿意给面试机会。

没想到过了半年，我和他吃饭，他对我说：“洋哥，我没有入职这家公司，我想明白了，继续做程序员对我来说没意义。我拿积蓄开了个小店”，刚听到消息，我非常惋惜，编码十多年最后却去做小生意，在我眼里就是逃兵。

直到最近去他小店玩，我才发现，这也是另一种好的生活。他开的是一个小型亲子游乐园，带上小孩，一边陪小孩一边工作，月收入也不差，养家完全没问题。这一瞬间，我产生了一种羡慕的情绪。

有时候，接受现实然后重新出发，未尝不是一个更好的选择。

最后的话

程序员不是一个「银发职业」，但也绝不是如某些贩卖焦虑的自媒体宣传的那样：35 岁危机，40 岁失业。

40 岁的程序员有的做了大厂中高管、有的成了小公司联创、有的成了连续创业者、还有的转行投资金融、也有人继续坚持写代码战斗在一线。

不可否认，有一部分人会被行业淘汰出局，但互联网的老年人在其他行业恐怕还是年轻人，接受现实，人生再起航完全没问题。

最重要的是，我们不能因为年纪的增长而焦虑，因为焦虑本身除了干扰我们成长，没有任何意义。

尽最大努力，做最好打算，但接受最坏的结果。在这个复杂多变的 社会 ，反焦虑、不断提升认知，不断充实自己的专业技能将永远重要。

Android中的线程状态 - AsyncTask详解

在操作系统中，线程是操作系统调度的最小单元，同时线程又是一种受限的系统资源，即线程不可能无限制地产生，并且 线程的创建和销毁都会有相应的开销。 当系统中存在大量的线程时，系统会通过会时间片轮转的方式调度每个线程，因此线程不可能做到绝对的并行。

如果在一个进程中频繁地创建和销毁线程，显然不是高效的做法。正确的做法是采用线程池，一个线程池中会缓存一定数量的线程，通过线程池就可以避免因为频繁创建和销毁线程所带来的系统开销。

AsyncTask是一个抽象类，它是由Android封装的一个轻量级异步类（轻量体现在使用方便、代码简洁），它可以在线程池中执行后台任务，然后把执行的进度和最终结果传递给主线程并在主线程中更新UI。

AsyncTask的内部封装了 两个线程池 (SerialExecutor和THREAD_POOL_EXECUTOR)和 一个Handler (InternalHandler)。

其中 SerialExecutor线程池用于任务的排队，让需要执行的多个耗时任务，按顺序排列 ， THREAD_POOL_EXECUTOR线程池才真正地执行任务 ， InternalHandler用于从工作线程切换到主线程 。

1.AsyncTask的泛型参数

AsyncTask是一个抽象泛型类。

其中，三个泛型类型参数的含义如下：

Params： 开始异步任务执行时传入的参数类型；

Progress： 异步任务执行过程中，返回下载进度值的类型；

Result： 异步任务执行完成后，返回的结果类型；

如果AsyncTask确定不需要传递具体参数，那么这三个泛型参数可以用Void来代替。

有了这三个参数类型之后，也就控制了这个AsyncTask子类各个阶段的返回类型，如果有不同业务，我们就需要再另写一个AsyncTask的子类进行处理。

2.AsyncTask的核心方法

onPreExecute()

这个方法会在 后台任务开始执行之间调用，在主线程执行。 用于进行一些界面上的初始化操作，比如显示一个进度条对话框等。

doInBackground(Params...)

这个方法中的所有代码都会 在子线程中运行，我们应该在这里去处理所有的耗时任务。

任务一旦完成就可以通过return语句来将任务的执行结果进行返回，如果AsyncTask的第三个泛型参数指定的是Void，就可以不返回任务执行结果。 注意，在这个方法中是不可以进行UI操作的，如果需要更新UI元素，比如说反馈当前任务的执行进度，可以调用publishProgress(Progress...)方法来完成。

onProgressUpdate(Progress...)

当在后台任务中调用了publishProgress(Progress...)方法后，这个方法就很快会被调用，方法中携带的参数就是在后台任务中传递过来的。 在这个方法中可以对UI进行操作，在主线程中进行，利用参数中的数值就可以对界面元素进行相应的更新。

onPostExecute(Result)

当doInBackground(Params...)执行完毕并通过return语句进行返回时，这个方法就很快会被调用。返回的数据会作为参数传递到此方法中， 可以利用返回的数据来进行一些UI操作，在主线程中进行，比如说提醒任务执行的结果，以及关闭掉进度条对话框等。

上面几个方法的调用顺序：

onPreExecute() -- doInBackground() -- publishProgress() -- onProgressUpdate() -- onPostExecute()

如果不需要执行更新进度则为onPreExecute() -- doInBackground() -- onPostExecute(),

除了上面四个方法，AsyncTask还提供了onCancelled()方法， 它同样在主线程中执行，当异步任务取消时，onCancelled()会被调用，这个时候onPostExecute()则不会被调用 ，但是要注意的是， AsyncTask中的cancel()方法并不是真正去取消任务，只是设置这个任务为取消状态，我们需要在doInBackground()判断终止任务。就好比想要终止一个线程，调用interrupt()方法，只是进行标记为中断，需要在线程内部进行标记判断然后中断线程。

3.AsyncTask的简单使用

这里我们模拟了一个下载任务，在doInBackground()方法中去执行具体的下载逻辑，在onProgressUpdate()方法中显示当前的下载进度，在onPostExecute()方法中来提示任务的执行结果。如果想要启动这个任务，只需要简单地调用以下代码即可：

4.使用AsyncTask的注意事项

①异步任务的实例必须在UI线程中创建，即AsyncTask对象必须在UI线程中创建。

②execute(Params... params)方法必须在UI线程中调用。

③不要手动调用onPreExecute()，doInBackground(Params... params)，onProgressUpdate(Progress... values)，onPostExecute(Result result)这几个方法。

④不能在doInBackground(Params... params)中更改UI组件的信息。

⑤一个任务实例只能执行一次，如果执行第二次将会抛出异常。

先从初始化一个AsyncTask时，调用的构造函数开始分析。

这段代码虽然看起来有点长，但实际上并没有任何具体的逻辑会得到执行，只是初始化了两个变量，mWorker和mFuture，并在初始化mFuture的时候将mWorker作为参数传入。mWorker是一个Callable对象，mFuture是一个FutureTask对象，这两个变量会暂时保存在内存中，稍后才会用到它们。 FutureTask实现了Runnable接口，关于这部分内容可以看这篇文章。

mWorker中的call()方法执行了耗时操作，即result = doInBackground(mParams);,然后把执行得到的结果通过postResult(result);,传递给内部的Handler跳转到主线程中。在这里这是实例化了两个变量，并没有开启执行任务。

那么mFuture对象是怎么加载到线程池中，进行执行的呢？

接着如果想要启动某一个任务，就需要调用该任务的execute()方法，因此现在我们来看一看execute()方法的源码，如下所示：

调用了executeOnExecutor()方法,具体执行逻辑在这个方法里面：

可以 看出，先执行了onPreExecute()方法，然后具体执行耗时任务是在exec.execute(mFuture)，把构造函数中实例化的mFuture传递进去了。

exec具体是什么？

从上面可以看出具体是sDefaultExecutor，再追溯看到是SerialExecutor类，具体源码如下：

终于追溯到了调用了SerialExecutor 类的execute方法。SerialExecutor 是个静态内部类，是所有实例化的AsyncTask对象公有的，SerialExecutor 内部维持了一个队列，通过锁使得该队列保证AsyncTask中的任务是串行执行的，即多个任务需要一个个加到该队列中，然后执行完队列头部的再执行下一个，以此类推。

在这个方法中，有两个主要步骤。

①向队列中加入一个新的任务，即之前实例化后的mFuture对象。

②调用 scheduleNext()方法，调用THREAD_POOL_EXECUTOR执行队列头部的任务。

由此可见SerialExecutor 类仅仅为了保持任务执行是串行的，实际执行交给了THREAD_POOL_EXECUTOR。

THREAD_POOL_EXECUTOR又是什么？

实际是个线程池，开启了一定数量的核心线程和工作线程。然后调用线程池的execute()方法。执行具体的耗时任务，即开头构造函数中mWorker中call()方法的内容。先执行完doInBackground()方法，又执行postResult()方法，下面看该方法的具体内容：

该方法向Handler对象发送了一个消息，下面具体看AsyncTask中实例化的Hanlder对象的源码：

在InternalHandler 中，如果收到的消息是MESSAGE_POST_RESULT，即执行完了doInBackground()方法并传递结果，那么就调用finish()方法。

如果任务已经取消了，回调onCancelled()方法，否则回调 onPostExecute()方法。

如果收到的消息是MESSAGE_POST_PROGRESS，回调onProgressUpdate()方法，更新进度。

InternalHandler是一个静态类，为了能够将执行环境切换到主线程，因此这个类必须在主线程中进行加载。所以变相要求AsyncTask的类必须在主线程中进行加载。

到此为止，从任务执行的开始到结束都从源码分析完了。

AsyncTask的串行和并行

从上述源码分析中分析得到，默认情况下AsyncTask的执行效果是串行的，因为有了SerialExecutor类来维持保证队列的串行。如果想使用并行执行任务，那么可以直接跳过SerialExecutor类，使用executeOnExecutor()来执行任务。

四、AsyncTask使用不当的后果

1.）生命周期

AsyncTask不与任何组件绑定生命周期，所以在Activity/或者Fragment中创建执行AsyncTask时，最好在Activity/Fragment的onDestory()调用 cancel(boolean)；

2.)内存泄漏

3.) 结果丢失

屏幕旋转或Activity在后台被系统杀掉等情况会导致Activity的重新创建，之前运行的AsyncTask（非静态的内部类）会持有一个之前Activity的引用，这个引用已经无效，这时调用onPostExecute()再去更新界面将不再生效。

自己是从事了七年开发的Android工程师，不少人私下问我，2019年Android进阶该怎么学，方法有没有？

没错，年初我花了一个多月的时间整理出来的学习资料，希望能帮助那些想进阶提升Android开发，却又不知道怎么进阶学习的朋友。【 包括高级UI、性能优化、架构师课程、NDK、Kotlin、混合式开发（ReactNative+Weex）、Flutter等架构技术资料 】，希望能帮助到您面试前的复习且找到一个好的工作，也节省大家在网上搜索资料的时间来学习。

已拿32k小米Android高级开发offer（面试题回顾）

到现在我入职也有一段时间了，这才有空梳理一下当时的面试题。简单说下我的情况：这是一次比较平常的跳槽，不是什么逆袭大厂的剧本，只是薪资有所涨幅。

个人经历不详说，面试题对大家来说可能更有参考性，本篇先整理小米的面试题，我前后也面了很多个大厂，有空把其他几个大厂的面试题也总结一下。

Java基础肯定是少不了要问的，这轮面试Kotlin相对来说是我这些面试中问得比较多的，所以说准备面试还是要面面俱到。

我有点佩服我的记忆力了。这部分涉及到更多的 源码、原理和优化 方面的问题，Android高级开发需要具备一些什么能力大家也应该有所衡量了。

最后给大家分享一份 2246页 的 Android大厂高频面试题解析大全 ，基本上把我的面试内容都涵盖到了： Android、性能优化、Java、Kotlin、网络、插件化、热修复、模块化、组件化、增量更新、Gradle、图片、Flutter等。

这份资料免费提供给大家复习，文末查看领取方式，搞定Android面试这一份肯定够了。

第一章 Android相关 （源码分析、性能优化、Framework等）

第二章 性能优化 （GC原理、布局优化、绘制优化、内存优化等）

第三章 Java相关 （四种线程池、JVM、内存管理、垃圾回收、引用等）

第四章 Kotlin相关 （延迟初始化、Reified、Extension Functions、函数等）

第五章 网络相关 （HTTP 知识体系、HttpDns 原理、TCP，UDP，HTTP，SOCKET 之间的区别等）

第六章 插件化热修复模块化组件化增量更新Gradle

第七章 图片相关 （图片库对比、LRUCache原理、图片加载原理、Glide等）

第八章 Flutter相关 （Flutter原理、Flutter Hot Reload、Flutter 动态化 探索 、Flutter Platform Channel等）

需要这份资料的朋友私信我【面试题】就可以免费领取。

希望大家都可以把握住每一次自我提升的机会，把每一步都走踏实了，涨薪升职什么的都会迎你而来。

也欢迎大家和我一起交流Android方面的事情。