u插上电脑卡-(插上u盘电脑卡)

Android开发中卡顿问题一直是个比较棘手又重要的问题，严重影响用户体验；卡顿是人的一种视觉感受，比如我们滑动界面时，如果滑动不流畅我们就会有卡顿的感觉，这种感觉我们需要有一个量化指标，在编程时如果开发的程序超过了这个指标我们认为其是卡顿的

当用户在使用我们应用的时候，很多问题是很难被及时发现的，比如内存占用高，就容易造成app卡顿现象，一旦发生卡顿就会被用户直观的感受到,所以app卡顿是很影响用户体验的，所以优化一直是我们要考虑的重要部分，正文会介绍“优化卡顿的工具—友盟+u-apm”及几种优化工具

谷歌官方对于流畅度的优化也是高度重视的，有界面渲染三核心Vsync、Triple Buffer和Choreographer

而对于开发者来说，卡顿的问题很难定位，发生问题的原因过于复杂，比如：代码问题、内存问题、绘制问题以及IO操作等等；而且线上发生的卡顿问题在线下我们很难发现，因为这种情况大多与用户用的系统环境有很大的关系，因此我们需要在用户反馈卡顿问题的时候，并记录下用户使用的场景等，这样的过程比较繁琐。要解决这些问题可以借助工具，友盟+u-apm应用性能监控平台这款监测工具，就可以帮助开发者查找和定位app出现问题，解决这些问题从而使用户有个良好的体验感！

FPS的高低不能准确的反映应用的流程度，只有有更新的时候才刷新界面。当界面没有变动的时候，手机不需要对界面进行更新，所以此时的FPS会很低，如果1秒钟内都没有变动那么FPS=0

所以我们需要利用其他方式来衡量应用的流程度，比如可以利用丢帧数来衡量。单位时间内丢帧数可以反映出应用是否流程，不丢帧是终极目标，但每秒丢帧在6-7帧左右可以接受，如果丢10帧以上就需要优化了；对于开发人员来说，会使用一些工具（比如：友盟+U-APM）找出卡顿比较集中的地方，找出原因，消除或减弱卡顿

android系统每隔16ms绘制一帧UI且要在16ms内完成，（ 1秒 / 0.016帧每秒 = 62.5帧/秒 ）差不多每秒更新60次；这是因为我们大脑和眼睛一般看24Fps的画面就已经是连续的运动了，看60Fps的画面更看不出端倪，但是60帧可以表达出更加绚丽多彩的内容

一旦没及时绘制，就会出现掉帧问题，也就是常说的卡顿。这是因为绘制的东西太多的话，CPU、GPU处理不及时

当然了，设备性能越好，处理能力越强，卡顿会越少，玩游戏的电脑配置高也是出于这方面考虑

核心：分析在16ms中我们的应用做了什么工作，那些工作阻止我们在16ms时更新界面

通常情况下，在16ms中我们有那些工作需要处理。而实际开发中我们还加入交互、业务处理等工作，这些工作都需要在16ms中处理完成。对于开发人员来说，需要有一个工具，很直观的帮助我们判断出那些工作占用了多少时间

常规做法

● 没有用的父布局——没有背景绘制或没有大小限制的父布局，不会对界面效果产生任何影响；特别是进来的布局，很容易产生问题；可以通过标签替代

● 在布局层次一样的情况下，建议使用LinearLayout代替RelativeLayout。使用LinearLayout导致的层次变深，可以使用RelativeLayout进行替换。同样的界面我们可以使用不同的方式去实现，选择一个层级最少的方案

● 不常用的UI被设置成了GONE，尝试使用代替。去掉多余的背景颜色，减少过渡绘制，对于有多层背景色的布局来说，留最上面的一层即可；谨慎使用alpha，如果后渲染的元素有设置alpha值，那么这个元素就会和屏幕上已经渲染好的元素做blend处理，这样会导致不少性能问题，特别是出现在列表的Item中

对于使用Selector当背景的布局，可以将normal状态的color设置为透明。我们不能因为提高性能而忽略了界面需要达到的效果（平衡Design与Performance）

以上就是Android卡顿产生的原因和优化流程，那么具体如何规避卡顿，这就要求开发者在平时的开发中养成良好的代码习惯，书写高质量代码

目前Android Studio自带了CPU Profiler工具，它可以以图形化的形式展示执行的时间、调用栈等信息；收集的信息比较全面，包含了所有线程；但是由于其收集信息全面，导致了运行时内存开销严重，App函数整体运行都会变慢，可能会带偏我们的优化方向

Systrace它是轻量级的框架，而且开销小，可以直观反映CPU的利用率而且右侧alter可以针对一些问题给出相关的建议； 比如绘制慢或者GC频繁等

Android2.3引入的一个工具类：严苛模式。是一种运行时检测机制。可以帮助开发人员检测代码当中不规范的问题；StrictMode主要检测线程策略和虚拟机策略

● 自定义的耗时调用，detectCustimSlowCalls

● 磁盘读取操作，detectDiskReads

● 网络操作，detectNetwork

● Activity泄漏，detectActivityLeaks

● Sqlite对象泄漏，detectLeakedSqlLiteObjects

● 检测实例数量，setClassInstanceLimit

CPU Profiler 和 Systrace 都是适合线下使用的，无法带到线上。那我们如何做到线上监测卡顿呢?

我们都知道一个进程中只有个Looper对象，我们通过查看Looper源码发现，在其loop方法中的死循环中有个mLogging对象，在执行的时候打印了一个Dispatching to日志，执行完成的时候有打印了一个Finished to日志

以上介绍的卡顿检测的方法并不完美，那么有没有一款工具能实时检测App卡顿问题呢？答案是有的。这里介绍一款带有卡顿检测和分析功能的工具-友盟U-APM性能检测工具，它的卡顿分析功能可以实时检测卡顿发生代码位置、卡顿的发生时间及卡顿次数等等，还可以进行告警设置，通过钉钉或者邮件的方式在第一时间把问题反馈给开发人员，再也不用担心找不到问题代码的位置了

另外，友盟+搭载在U-APM应用性能监控平台上推出了友盟+云真机服务，为移动开发者提供了灵活地测试操作界面，支持ADB调试、WEB远程调试、扫码、抓包、虚拟定位等测试功能，并提供了测试报告供开发者后续查看。提供了海量Android、iOS真机，通过资源集中管理，合理调度分配，为开发者提供发版前测试、发现线上问题后复现等场景使用，助力开发者平衡成本与需求，提升研发效率

● 开发app的性能目标就是保持60fps，这意味着每一帧你只有16ms≈1000/60的时间来处理所有的任务；Android系统每隔16ms发出VSYNC信号，触发对UI进行渲染，如果每次渲染都成功，这样就能够达到流畅的画面所需要的60fps；友盟+U-APM就是一款对Android卡顿进行分析的平台，下面来说说如何借助友盟+这个平台对Android进行卡顿分析及优化的

● 友盟+U-APM应用性能监控平台，通过轻量级的集成接入即可拥有实时、可靠、全面的应用崩溃电脑、ANR、自定义异常等捕获能力，及卡顿、启动分析、内存分析、网络分析等性能监测能力，支持多场景、多通道智能告警监测，帮助开发者高效还原异常、卡顿用户的访问路径和业务现场，缩短故障排查时间

● 提供云真机测试能力，助力开发者从研发测试质量验收到线上问题复现排查，保障应用品质，提升测试效率；在云真机测试期间自动采集崩溃信息，提供详尽的崩溃报告协助筛查，真正实现监控测试全流程深度打通

作为开发人员，在平时的开发中要养成良好的代码习惯，写完代码后也可以先使用友盟U-APM这款工具进行监测，毕竟以防万一嘛~开发者提前监测到问题，比如：卡顿、内存、app崩溃、闪退等等，在借助友盟这款工具针对监测出的问题去解决，总要比用户使用后一系列的吐槽强，这样也不至于降低用户的体验感！

技术是无止境的，你需要对自己提交的每一行代码、使用的每一个工具负责，不断挖掘其底层原理，才能使自己的技术升华到更高的层面

Android 架构师之路还很漫长，与君共勉

PS:有问题欢迎指正,可以在评论区留下你的建议和感受； 欢迎大家点赞评论，觉得内容可以的话，可以转发分享一下