Android性能优化系列篇（三）崩溃优化卡顿优化

　　前言汇总了一下众多大佬的性能优化文章，知识点，主要包含：
　　UI优化启动优化崩溃优化卡顿优化安全性优化弱网优化APP深度优化等等等
　　本篇是第三篇：崩溃优化卡顿优化〔非商业用途，如有侵权，请告知我，我会删除〕
　　强调一下：性能优化的开发文档跟之前的面试文档一样，需要的跟作者直接要。三、崩溃优化3。1崩溃分析
　　崩溃率是衡量一个应用质量高低的基本指标：Android崩溃分为Java崩溃和Native崩溃：Java崩溃就是在Java代码中，出现了未捕获异常，导致程序异常退出；Native崩溃又是怎么产生的呢？一般都是因为在Native代码中访问非法地址，也可能是地址对齐出现了问题，或者发生了程序主动abort，这些都会产生相应的signal信号，导致程序异常退出。Native崩溃的捕获流程
　　完整的Native崩溃从捕获到解析的流程：编译端。编译CC代码时，需要将带符号信息的文件保留下来客户端。捕获到崩溃时候，将收集到尽可能多的有用信息写入日志文件，然后选择合适的时机上传到服务器。服务端。读取客户端上报的日志文件，寻找适合的符号文件，生成可读的CC调用栈。
　　Native崩溃捕获的难点
　　上面的三个流程中，最核心的是怎么样保证客户端在各种极端情况下依然可以生成崩溃日志。因为在崩溃时，程序会处于一个不安全的状态，如果处理不当，非常容易发生二次崩溃。那么，生成崩溃日志时会有哪些比较棘手的情况呢？
　　情况一：文件句柄泄漏，导致创建日志文件失败，怎么办？应对方式：我们需要提前申请文件句柄fd预留，防止出现这种情况。
　　情况二：因为栈溢出了，导致日志生成失败，怎么办？应对方式：为了防止栈溢出导致进程没有空间创建调用栈执行处理函数，我们通常会使用常见的signalstack。在一些特殊情况，我们可能还需要直接替换当前栈，所以这里也需要在堆中预留部分空间。
　　情况三：整个堆的内存都耗尽了，导致日志生成失败，怎么办？应对方式：这个时候我们无法安全地分配内存，也不敢使用stl或者libc的函数，因为它们内部实现会分配堆内存。这个时候如果继续分配内存，会导致出现堆破坏或者二次崩溃的情况。Breakpad做的比较彻底，重新封装了LinuxSyscallSupport，来避免直接调用libc。
　　情况四：堆破坏或二次崩溃导致日志生成失败，怎么办？应对方式：Breakpad会从原进程fork出子进程去收集崩溃现场，此外涉及与Java相关的，一般也会用子进程去操作。这样即使出现二次崩溃，只是这部分的信息丢失，我们的父进程后面还可以继续获取其他的信息。在一些特殊的情况，我们还可能需要从子进程fork出孙进程。
　　选择合适的崩溃服务
　　对于很多中小型公司来说，并不建议自己去实现一套如此复杂的系统，可以选择一些第三方的服务。目前各种平台也是百花齐放，包括腾讯的Bugly、阿里的啄木鸟平台、网易云捕、Google的Firebase等等3。2崩溃现场应采集哪些信息1。崩溃信息：进程名、线程名：
　　崩溃的进程是前台进程还是后台进程，崩溃是不是发生在UI线程。崩溃堆栈和类型：
　　属于Java崩溃、Native崩溃，还是ANR2。系统信息Logcat：这里包括应用、系统的运行日志机型、系统、厂商、CPU、ABI、Linux版本等设备状态：是否root、是否是模拟器3。内存信息
　　OOM、ANR、虚拟内存耗尽等，很多崩溃都跟内存有直接关系系统剩余内存：
　　当系统可用内存很小（低于MemTotal的10）时，OOM、大量GC、系统频繁自杀拉起等问题都非常容易出现应用使用内存：
　　包括Java内存、RSS（ResidentSetSize）、PSS（ProportionalSetSize），我们可以得出应用本身内存的占用大小和分布虚拟内存：
　　可以通过procselfstatus得到，通过procselfmaps文件可以得到具体的分布情况，有时候我们一般不太重视虚拟内存，但是很多类似OOM、tgkill等问题都是虚拟内存不足导致的4。资源信息
　　有的时候我们会发现应用堆内存和设备内存都非常充足，还是会出现内存分配失败的情况，这跟资源泄漏可能有比较大的关系文件句柄fd：
　　文件句柄的限制可以通过procselflimits获得，一般单个进程允许打开的最大文件句柄个数为1024。但是如果文件句柄超过800个就比较危险，需要将所有的fd以及对应的文件名输出到日志中，进一步排查是否出现了有文件或者线程的泄漏线程数：
　　当前线程数大小可以通过上面的status文件得到，一个线程可能就占2MB的虚拟内存，过多的线程会对虚拟内存和文件句柄带来压力。根据我的经验来说，如果线程数超过400个就比较危险。需要将所有的线程id以及对应的线程名输出到日志中，进一步排查是否出现了线程相关的问题。JNI：
　　使用JNI时，如果不注意很容易出现引用失效、引用爆表等一些崩溃。我们可以通过DumpReferenceTables统计JNI的引用表，进一步分析是否出现了JNI泄漏等问题。5。应用信息
　　除了系统，其实我们的应用更懂自己，可以留下很多相关的信息崩溃场景
　　崩溃发生在哪个Activity或Fragment，发生在哪个业务中关键操作路径
　　不同于开发过程详细的打点日志，我们可以记录关键的用户操作路径，这对我们复现崩溃会有比较大的帮助其他自定义信息
　　不同的应用关心的重点可能不太一样，比如网易云音乐会关注当前播放的音乐，QQ浏览器会关注当前打开的网址或视频。此外例如运行时间、是否加载了补丁、是否是全新安装或升级等信息也非常重要。6。其他信息
　　除了上面这些通用的信息外，针对特定的一些崩溃，我们可能还需要获取类似磁盘空间、电量、网络使用等特定信息。所以说一个好的崩溃捕获工具，会根据场景为我们采集足够多的信息，让我们有更多的线索去分析和定位问题。当然数据的采集需要注意用户隐私，做到足够强度的加密和脱敏。3。3崩溃分析三部曲第一步：确定重点
　　确认和分析重点，关键在于在日志中找到重要的信息，对问题有一个大致判断。一般来说，我建议在确定重点这一步可以关注以下几点。1。确认严重程度
　　解决崩溃也要看性价比，我们优先解决Top崩溃或者对业务有重大影响，例如启动、支付过程的崩溃。2。崩溃基本信息
　　确定崩溃的类型以及异常描述，对崩溃有大致的判断。Java崩溃类型比较明显Native崩溃：需要观察signal、code、faultaddr等内容，以及崩溃时Java的堆栈；ANR：先看看主线程的堆栈，是否是因为锁等待导致。接着看看ANR日志中iowait、CPU、GC、systemserver等信息，进一步确定是IO问题，或是CPU竞争问题，还是由于大量GC导致卡死。3。Logcat
　　Logcat一般会存在一些有价值的线索，日志级别是Warning、Error的需要特别注意。从Logcat中我们可以看到当时系统的一些行为跟手机的状态，例如出现ANR时，会有amanr；App被杀时，会有amkill。4。各个资源情况
　　结合崩溃的基本信息，我们接着看看是不是跟内存信息有关，是不是跟资源信息有关。比如是物理内存不足、虚拟内存不足，还是文件句柄fd泄漏了。第二步：查找共性
　　如果使用了上面的方法还是不能有效定位问题，我们可以尝试查找这类崩溃有没有什么共性。找到了共性，也就可以进一步找到差异，离解决问题也就更进一步机型、系统、ROM、厂商、ABI，这些采集到的系统信息都可以作为维度聚合，找到了共性，可以对你下一步复现问题有更明确的指引。第三步：尝试复现
　　只要能本地复现，我就能解，相信这是很多开发跟测试说过的话。有这样的底气主要是因为在稳定的复现路径上面，我们可以采用增加日志或使用Debugger、GDB等各种各样的手段或工具做进一步分析。3。4疑难问题：系统崩溃的解决思路1。查找可能的原因。
　　通过上面的共性归类，我们先看看是某个系统版本的问题，还是某个厂商特定ROM的问题。虽然崩溃日志可能没有我们自己的代码，但通过操作路径和日志，我们可以找到一些怀疑的点。2。尝试规避。
　　查看可疑的代码调用，是否使用了不恰当的API，是否可以更换其他的实现方式规避。3。Hook解决。
　　这里分为JavaHook和NativeHook。
　　崩溃攻防是一个长期的过程，我们希望尽可能地提前预防崩溃的发生，将它消灭在萌芽阶段。这可能涉及我们应用的整个流程，包括人员的培训、编译检查、静态扫描工作，还有规范的测试、灰度、发布流程等。3。5获得logcat和Jave堆栈的方法：一。获取logcat
　　logcat日志流程是这样的，应用层liblog。sologd，底层使用ringbuffer来存储数据，获取的方式有以下三种：1。通过logcat命令获取优点：非常简单，兼容性好。缺点：整个链路比较长，可控性差，失败率高，特别是堆破坏或者堆内存不足时，基本会失败。2。hookliblog。so实现
　　通过hookliblog。so中androidlogbufwrite方法，将内容重定向到自己的buffer中。优点：简单，兼容性相对还好。缺点：要一直打开。3。自定义获取代码通过移植底层获取logcat的实现，通过socket直接跟logd交互。优点：比较灵活，预先分配好资源，成功率也比较高。缺点：实现非常复杂二。获取Java堆栈
　　native崩溃时，通过unwind只能拿到Native堆栈。我们希望可以拿到当时各个线程的Java堆栈1。Thread。getAllStackTraces（）。优点：简单，兼容性好。缺点：a。成功率不高，依靠系统接口在极端情况也会失败。b。7。0之后这个接口是没有主线程堆栈。c。使用Java层的接口需要暂停线程2。hooklibart。so
　　通过hookThreadList和Thread的函数，获得跟ANR一样的堆栈。为了稳定性，我们会在fork子进程执行。优点：信息很全，基本跟ANR的日志一样，有native线程状态，锁信息等等。缺点：黑科技的兼容性问题，失败时可以用Thread。getAllStackTraces（）兜底
　　获取Java堆栈的方法还可以用在卡顿时，因为使用fork进程，所以可以做到完全不卡主进程。这块我们在后面会详细的去讲。四、卡顿优化4。1什么是卡顿
　　卡顿，顾名思义就是用户体感界面不流畅。我们知道手机的屏幕画面是按照一定频率来刷新的，理论上讲，24帧的画面更新就能让人眼感觉是连贯的。但是实际上，这个只是针对普通的视频而言。对于一些强交互或者较为敏感的场景来说，比如游戏，起码需要60帧，30帧的游戏会让人感觉不适；位移或者大幅度动画30帧会有明显顿挫感；跟手动画如果能到90帧甚至120帧，会让人感觉十分细腻，这也是近来厂商主打高刷牌的原因。
　　对于用户来说，从体感角度大致可以将卡顿分为以下几类：
　　这些体验对于用户可以说是非常糟糕的，甚至会引起感官的烦躁，进而导致用户不愿意继续停留在我们的App。可以说，流畅的体验对于用户来说至关重要。4。2为什么会发生卡顿
　　用户体感的卡顿问题原因很多，且常常是一个复合型的问题，为了聚焦，这里暂只考虑真正意义上的掉帧卡顿。4。2。1绕不开的VSYNC
　　我们通常会说，屏幕的刷新率是60帧，需要在16ms内做完所有的操作才不会造成卡顿。但是这里需要明确几个基本问题：为什么是16ms？16ms内都需要完成什么？系统如何尽力保证任务在16ms内完成？16ms内没有完成，一定会造成卡顿吗？
　　这里先回答第一个问题：为什么是16ms。早期的Android是没有vsync机制的，CPU和GPU的配合也比较混乱，这也造成著名的tearing问题，即CPUGPU直接更新正在显示的屏幕buffer造成画面撕裂。后续Android引入了双缓冲机制，但是buffer的切换也需要一个比较合适的时机，也就是屏幕扫描完上一帧后的时机，这也就是引入vsync的原因。
　　早先一般的屏幕刷新率是60fps，所以每个vsync信号的间隔也是16ms，不过随着技术的更迭以及厂商对于流畅性的追求，越来越多90fps和120fps的手机面世，相对应的间隔也就变成了11ms和8ms。
　　那既然有了VSYNC，谁在消费VSYNC？其实Android的VSYNC消费者有两个，也就对应两类VSYNC信号，分别是VSYNCapp和VSYNCsf，所对应的也是上层view绘制和surfaceFlinger的合成，具体的我们接下来详细说。
　　这里还有一些比较有意思的点，有些厂商会有vsyncoffset的设计，App和sf的vsync信号之间是有偏移量的，这也在一定程度上使得App和sf的协同效应更好。4。2。2View颠沛流离的一生
　　在讲下一part之前先引入一个话题：
　　一个view究竟是如何显示在屏幕上的？
　　我们一般都比较了解view渲染的三大流程，但是view的渲染远不止于此：此处以一个通用的硬件加速流程来表征
　　Vsync调度：很多同学的一个认知误区在于认为vsync是每16ms都会有的，但是其实vsync是需要调度的，没有调度就不会有回调；消息调度：主要是doframe的消息调度，如果消息被阻塞，会直接造成卡顿；input处理：触摸事件的处理；动画处理：animator动画执行和渲染；view处理：主要是view相关的遍历和三大流程；measure、layout、draw：view三大流程的执行；DisplayList更新：view硬件加速后的drawop；OpenGL指令转换：绘制指令转换为OpenGL指令；指令buffer交换：OpenGL的指令交换到GPU内部执行；GPU处理：GPU对数据的处理过程；layer合成：surfacebuffer合成屏幕显示buffer的流程；光栅化：将矢量图转换为位图；Display：显示控制；buffer切换：切换屏幕显示的帧buffer；
　　Google将这个过程划分为：其他时间VSync延迟、输入处理、动画、测量布局、绘制、同步和上传、命令问题、交换缓冲区。也就是我们常用的GPU严格模式，其实道理是一样的。到这里，我们也就回答出来了第二个问题：16ms内都需要完成什么？准确地说，这里仍可以进一步细化：16ms内完成APP侧数据的生产；16ms内完成sflayer的合成
　　View的视觉效果正是通过这一整条复杂的链路一步步展示出来的，有了这个前提，那就可以得出一个结论：上述任意链路发生卡顿，均会造成卡顿。4。2。3生产者和消费者
　　我们再回到Vsync的话题，消费Vsync的双方分别是App和sf，其中App代表的是生产者，sf代表的是消费者，两者交付的中间产物则是surfacebuffer。
　　再具体一点，生产者大致可以分为两类，一类是以window为代表的页面，也就是我们平时所看到的view树这一套；另一类是以视频流为代表的可以直接和surface完成数据交换的来源，比如相机预览等。
　　对于一般的生产者和消费者模式，我们知道会存在相互阻塞的问题。比如生产者速度快但是消费者速度慢，亦或是生产者速度慢消费者速度快，都会导致整体速度慢且造成资源浪费。所以Vsync的协同以及双缓冲甚至三缓冲的作用就体现出来了。思考一个问题：是否缓冲的个数越多越好？过多的缓冲会造成什么问题？
　　答案是会造成另一个严重的问题：lag，响应延迟
　　这里结合view的一生，我们可以把两个流程合在一起，让我们的视角再高一层：
　　4。2。4机制上的保护
　　这里我们来回答第三个问题，从系统的渲染架构上来说，机制上的保护主要有几方面：Vsync机制的协同；多缓冲设计；surface的提供；同步屏障的保护；硬件绘制的支持；渲染线程的支持；GPU合成加速；
　　这些机制上的保护在系统层面最大程度地保障了App体验的流畅性，但是并不能帮我们彻底解决卡顿。为了提供更加流畅的体验，一方面，我们可以加强系统的机制保护，比如FWatchDog；另一方面，需要我们从App的角度入手，治理应用内的卡顿问题。4。2。5再看卡顿的成因
　　经过上面的讨论，我们得出一个卡顿分析的核心理论支撑：渲染机制中的任何流转过程发生异常，均会造成卡顿。
　　那么接下来，我们逐个分析，看看都会有哪些原因可能造成卡顿。渲染流程Vsync调度：这个是起始点，但是调度的过程会经过线程切换以及一些委派的逻辑，有可能造成卡顿，但是一般可能性比较小，我们也基本无法介入；消息调度：主要是doframeMessage的调度，这就是一个普通的Handler调度，如果这个调度被其他的Message阻塞产生了时延，会直接导致后续的所有流程不会被触发。这里直播建立了一个FWtachDog机制，可以通过优化消息调度达到插帧的效果，使得界面更加流畅；input处理：input是一次Vsync调度最先执行的逻辑，主要处理input事件。如果有大量的事件堆积或者在事件分发逻辑中加入大量耗时业务逻辑，会造成当前帧的时长被拉大，造成卡顿。抖音基础技术同学也有尝试过事件采样的方案，减少event的处理，取得了不错的效果；动画处理：主要是animator动画的更新，同理，动画数量过多，或者动画的更新中有比较耗时的逻辑，也会造成当前帧的渲染卡顿。对动画的降帧和降复杂度其实解决的就是这个问题；view处理：主要是接下来的三大流程，过度绘制、频繁刷新、复杂的视图效果都是此处造成卡顿的主要原因。比如我们平时所说的降低页面层级，主要解决的就是这个问题；measurelayoutdraw：view渲染的三大流程，因为涉及到遍历和高频执行，所以这里涉及到的耗时问题均会被放大，比如我们会降不能在draw里面调用耗时函数，不能new对象等等；DisplayList的更新：这里主要是canvas和displaylist的映射，一般不会存在卡顿问题，反而可能存在映射失败导致的显示问题；OpenGL指令转换：这里主要是将canvas的命令转换为OpenGL的指令，一般不存在问题。不过这里倒是有一个可以探索的点，会不会存在一类特殊的canvas指令，转换后的OpenGL指令消耗比较大，进而导致GPU的损耗？有了解的同学可以探讨一下；buffer交换：这里主要指OpenGL指令集交换给GPU，这个一般和指令的复杂度有关。一个有意思的事儿是这里一度被我们作为线上采集GPU指标的数据源，但是由于多缓冲的因素数据准确度不够被放弃了；GPU处理：顾名思义，这里是GPU对数据的处理，耗时主要和任务量和纹理复杂度有关。这也就是我们降低GPU负载有助于降低卡顿的原因；layer合成：这里主要是layer的compose的工作，一般接触不到。偶尔发现sf的vsync信号被delay的情况，造成buffer供应不及时，暂时还不清楚原因；光栅化Display：这里暂时忽略，底层系统行为；Buffer切换：主要是屏幕的显示，这里buffer的数量也会影响帧的整体延迟，不过是系统行为，不能干预。视频流
　　除了上述的渲染流程引起的卡顿，还有一些其他的因素，典型的就是视频流。渲染卡顿：主要是TextureView渲染，textureview跟随window共用一个surface，每一帧均需要一起协同渲染并相互影响，UI卡顿会造成视频流卡顿，视频流的卡顿有时候也会造成UI的卡顿；解码：解码主要是将数据流解码为surface可消费的buffer数据，是除了网络外最重要的耗时点。现在我们一般都会采用硬解，比软解的性能高很多。但是帧的复杂度、编码算法的复杂度、分辨率等也会直接导致解码耗时被拉长；OpenGL处理：有时会对解码完成的数据做二次处理，这个如果比较耗时会直接导致渲染卡顿；网络：这个就不再赘述了，包括DNS节点优选、cdn服务、GOP配置等；推流异常：这个属于数据源出了问题，这里暂时以用户侧的视角为主，暂不讨论。
　　2。5。3系统负载内存：内存的吃紧会直接导致GC的增加甚至ANR，是造成卡顿的一个不可忽视的因素；CPU：CPU对卡顿的影响主要在于线程调度慢、任务执行的慢和资源竞争，比如降频会直接导致应用卡顿；GPU：GPU的影响见渲染流程，但是其实还会间接影响到功耗和发热；功耗发热：功耗和发热一般是不分家的，高功耗会引起高发热，进而会引起系统保护，比如降频、热缓解等，间接的导致卡顿。4。2。6卡顿的分类
　　我们此处再整体整理并归类，为了更完备一些，这里将推流也放了上来。在一定程度上，我们遇到的所有卡顿问题，均能在这里找到理论依据，这也是指导我们优化卡顿问题的理论支撑。
　　4。3如何评价卡顿4。3。1线上指标
　　指标
　　释义
　　计算方式
　　数据来源
　　FPS
　　帧率
　　取vsync到来的时间为起点，doFrame执行完成的事件为终点，作为每帧的渲染耗时，同时利用渲染耗时刷新率可以得出每次渲染的丢帧数。平均FPS一段时间内渲染帧的个数60（渲染帧个数丢帧个数）
　　vsync
　　stallvideouirate
　　总卡顿率
　　（UI卡顿时长流卡顿时长）采集时长
　　vsync
　　stalluirate
　　UI卡顿率
　　【3帧】UI卡顿时长采集时长
　　vsync
　　stallvideorate
　　流卡顿率
　　流卡顿时长采集时长
　　vsync
　　stalluislightrate
　　轻微卡顿率
　　【36】帧丢帧时长采集时长
　　vsync
　　stalluimoderaterate
　　中等卡顿率
　　【713】帧丢帧时长采集时长
　　vsync
　　stalluiseriousrate
　　严重卡顿率
　　【14】帧丢帧时长采集时长
　　vsync4。3。2线下指标
　　Diggo是字节自研的一个开放的开发调试工具平台，是一个集评价、分析、调试为一体的，一站式工具平台。内置性能测评、界面分析、卡顿分析、内存分析、崩溃分析、即时调试等基础分析能力，可为产品开发阶段提供强大助力。
　　指标
　　释义
　　计算方式
　　数据来源
　　FPS
　　时机渲染帧率
　　数据获取时间周期内，实际渲染帧数数据获取间隔时间
　　SFGFXInfo
　　RFPS
　　相对帧率
　　数据获取时间周期内，（理论满帧实际掉帧数）数据获取间隔时间
　　GFXInfo
　　Stutter
　　卡顿率
　　卡顿比。当发生jank的帧的累计时长与区间时长的比值。
　　SF
　　JankyCount
　　普通卡顿次数
　　单帧绘制耗时大于MOVIEFRAMETIME时，计一次janky。
　　SF
　　BigJankyCount
　　严重卡顿次数
　　单帧绘制耗时大于3MOVIEFRAMETIME时，计一次bigjanky。
　　SF4。4如何优化卡顿4。4。1常用的工具线上工具
　　名称
　　释义
　　正式包慢函数
　　相对于灰度包，过滤了比较多监控，对性能损耗比较小，但是需要手动打开，单点反馈中不能保留反馈现场
　　灰度包慢函数
　　灰度上全量打开，针对版本间的数据对比和新增卡顿问题解决比较有效
　　ANR
　　ANR的及时响应和处理线下工具
　　工具名
　　备注
　　Systrace
　　暂不赘述
　　perfetto
　　加强版systrace，可定制，可以参考官方文档
　　Rhea
　　最常用也是最好用的工具，方便发现下下问题和归因，和perfetto一起使用绝配，感兴趣的同学可以移步github搜索btrace
　　profiler
　　Androidstudio自带工具，比较方便，但是数据准确度不高
　　sfgfxinfo
　　主要用于脚本和工具4。4。2常用的思路
　　这里主要针对UI卡顿和UI流相互影响打来的卡顿。
　　对于UI卡顿来说，我们手握卡顿优化的8板大斧子，所向披靡：下线代码；减少执行次数；异步；打散；预热；复用；方案优化；硬件加速；
　　总体思路就是能不干就不干、能少干就少干、能早点干就早点儿干、能晚点儿干就晚点儿干、能让别人干就让别人干、能干完一次当10次就只干一次，实在不行，再考虑自己大干一场。
　　这里例举出一些常见的优化思路，注意这一定也不可能是全部，如果有其他好的优化思路，我们可以一起交流。
　　4。4。3一些做过的事儿解决UI卡顿引起的流卡顿
　　直播对于SurfaceView的切换是一个长期的专项，分为多期逐步将SurfaceView在直播全量落地，场景覆盖秀场直播、聊天室、游戏直播、电商直播、媒体直播等，业务上对于渗透率和停留时长有比较显著的收益，同时功耗的收益也很可观。
　　这里是一个权衡的问题，SurfaceView的兼容性问题pk带来的收益是否能打平，一般来说，越是复杂的业务场景，收益约大。解决message调度
　　FWatchDog是基于对MessageQueue的调度策略和同步屏障原理，以均帧耗时为阈值判定丢帧后主动在MessageQueue中插入同步屏障，保证渲染异步message和doframe的优先执行，达到一种渲染插帧的效果，同时具备ANR自动恢复同步屏障的能力，保障打散的有效。
　　所以FWatchDog和打散是好的搭档，能产生11大于2的效果。减少执行次数
　　一个典型的应用场景就是滑动场景的GC抑制，能够显著提高用户上下滑的使用体验。这个场景相信每个业务都会存在，特别是存在大量遍历的逻辑，优化效果明显。代码下线
　　一些老的框架、无用的逻辑以及存在性不高的代码都可以下线，这里基本业务强相关，就不举具体的例子了。解决耗时函数（打散异步）
　　首先是打散，直播做了很多task的拆分以及打散，第一可以减轻当前渲染帧的耗时压力，第二可以和FWatchDog结合达到插帧的效果。这里其实还可以控制task的执行优先级，包括队列的插队等，总之MessageQueue的合理调度是很有必要的。
　　异步的使用也相对比较多，一个埋点日志的框架，以及一些inflate的加载等，都可以使用异步来解决卡顿问题。预热
　　直播提供了一个预热框架，可以让直播内部的一次性成本逻辑得到在宿主侧执行的机会，同时提供完备的队列优先级管理、同步异步管理和task生命周期管理，降低直播内部首次加载的卡顿问题。硬件加速
　　拉高硬件的运行性能，比如CPU频率、GPU频率、线程绑大核以及网络相关的调优，从底层提高App的运行体验。