APM （Application Performance Management，即应用性能管理，在分布式领域也称为分布式跟踪管理）对企业的应用系统进行实时监控，它是用于实现对应用程序性能管理和故障管理的系统化的解决方案。
建网站原本是网站策划师、网络程序员、网页设计师等，应用各种网络程序开发技术和网页设计技术配合操作的协同工作。创新互联公司专业提供成都网站设计、做网站,网页设计,网站制作(企业站、响应式网站开发、电商门户网站)等服务,从网站深度策划、搜索引擎友好度优化到用户体验的提升,我们力求做到极致!
随着分布式系统和微服务架构的应用和发展，应用性能管理成为系统运维管理和网络管理的一个重要方向，它能够对企业的关键业务应用进行监测、优化，提高企业应用的可靠性和质量，保证用户得到良好的服务，降低IT总拥有成本(TCO)。应用性能管理APM能够对整个企业的IT系统各个层面进行集中的性能监控，并对有可能出现的性能问题进行及时、准确的分析和处理。它能轻松地从一个IT应用系统中找到故障点，并提供有相关解决建议或方法，从而提高整体的系统性能。一个企业的关键业务应用的性能强大，可以保证企业业务应用系统的高效性和稳定性，为企业带来核心竞争力的提升。
当下成熟的互联网公司都建立有从基础设施到应用程序的全方位监控系统，力求及时发现故障进行处理并为优化程序提供性能数据支持，降低整体运维成本。国内外商业的APM有Compuware、iMaster、博睿Bonree、听云、New Relic、云智慧、OneAPM、AppDyn、Amics等。 本文主要针对Java技术体系介绍APM的框架、核心功能以及业界主流APM工具的功能特点。
随着互联网技术和应用的快速发展，应用程序本身变得越来越难以管理，因为它们从单体架构转向高度分布的、多层、多元素的分布式应用架构，应用系统在许多情况下依赖于应用程序的开发框架。APM概念框架旨在帮助企业优先考虑在IT系统架构中需要首先关注的方法，以便企业能够快速实施并全面了解五维APM模型。
APM被形象的称为应用程序的私人医生，越来越收到企业的青睐，比起通过日志方式记录关键数据显然要更加实用，APM主要包含如下核心功能：
基于Java体系的应用程序运行时的性能指标可通过Java.lang.Runtime、java.lang.Management中的方法采集。除此之外，著名的Metrics类库也能够通过这些底层技术获取Java程序性能指标。CPU利用率、内存利用率等基础数据的采集仅仅是性能监控的一部分，Metrics提供了更为丰富的五个基本度量类型，可在此基础上开发满足需求的监控指标。
大多数企业希望有一个功能完善的APM系统具有JVM性能监控、服务调用追中、监控告警功能，CAT、PinPoint、SkyWalking、Hawkular相对来讲功能更为完备，推荐企业使用。
理论上是不行的，要想实时就必须连续不断传输的视频信号，而你的软件是播放视频文件的，文件的话必须有头尾，如果做成文件格式再播放，那就不叫实时监控了。
1. 部署简单
Go
编译生成的是一个静态可执行文件，除了glibc外没有其他外部依赖。这让部署变得异常方便：目标机器上只需要一个基础的系统和必要的管理、监控工具，完全不需要操心应用所需的各种包、库的依赖关系，大大减轻了维护的负担。
2. 并发性好
Goroutine和channel使得编写高并发的服务端软件变得相当容易，很多情况下完全不需要考虑锁机制以及由此带来的各种问题。单个Go应用也能有效的利用多个CPU核，并行执行的性能好。
3. 良好的语言设计
从学术的角度讲Go语言其实非常平庸，不支持许多高级的语言特性;但从工程的角度讲，Go的设计是非常优秀的：规范足够简单灵活，有其他语言基础的程序员都能迅速上手。更重要的是
Go 自带完善的工具链，大大提高了团队协作的一致性。
4. 执行性能好
虽然不如 C 和 Java，但相比于其他编程语言，其执行性能还是很好的，适合编写一些瓶颈业务，内存占用也非常省。
Go语言由Google公司开发，并于2009年开源，相比Java/Python/C等语言，Go尤其擅长并发编程，性能堪比C语言，开发效率肩比Python，被誉为“21世纪的C语言”。
Go语言在云计算、大数据、微服务、高并发领域应用应用非常广泛。BAT大厂正在把Go作为新项目开发的首选语言。
Go语言能干什么?
1、服务端开发：以前你使用C或者C++做的那些事情，用Go来做很合适，例如日志处理、文件系统、监控系统等;
2、DevOps：运维生态中的Docker、K8s、prometheus、grafana、open-falcon等都是使用Go语言开发;
3、网络编程：大量优秀的Web框架如Echo、Gin、Iris、beego等，而且Go内置的 net/http包十分的优秀;
4、Paas云平台领域：Kubernetes和Docker Swarm等;
5、分布式存储领域：etcd、Groupcache、TiDB、Cockroachdb、Influxdb等;
6、区块链领域：区块链里面有两个明星项目以太坊和fabric都使用Go语言;
7、容器虚拟化：大名鼎鼎的Docker就是使用Go语言实现的;
8、爬虫及大数据：Go语言天生支持并发，所以十分适合编写分布式爬虫及大数据处理。
APM的意思有多种，如“每分钟操作次数”、“高级电源管理”、“旅客自动捷运系统”、“自动化精确生产”、“应用性能管理”。
1、APM（每分钟操作的次数）
APM，（英语：ActionsPerMinute）每分钟操作的次数，又称“手速”。该词多见于星际争霸和魔兽争霸系列游戏中，在一定程度上反映了玩家的水平。在即时战略游戏中，每分钟操作数指的是每分钟操作指令数，这一般包括鼠标点击和键盘敲击。APM很好地反映了玩家的操作速度。
高APM通常还意味着良好的微操作——即在游戏中精心操控每一个单位使其作用达到最大化。最著名的星际争霸APM测试软件是BWChart。
2、APM（高级电源管理）
APM（英文AdvancedPowerManagement），高级电源管理，一种工业标准，它允许系统处理器和各个组件进入省电模式，包括挂起、睡眠和关机。
3、APM（旅客自动捷运系统）
APM，（英语：AutomatedPeopleMoversystems）中文名为自动旅客捷运系统，该系统也称为自动导轨快捷运输系统(AGTS)，是一种无人自动驾驶、立体交叉的大众运输系统。
旅客捷运系统并不是一种独立及特殊的铁路运输技术，通常都会应用到多种铁路运输技术。2010年11月8日，广州市地下铁道总公司宣布，中国大陆第二条无人驾驶APM（自动旅客捷运系统）广州地铁APM线11月8日通车试运营。
4、APM（自动化精确生产）
APM（英语AutomatedPreciseManufacture），自动化精确生产，AMD采用的一种高效的、基于合作伙伴的研发模式，确保它的产品和解决方案可以始终在性能和功率方面保持领先。
5、APM（应用性能管理）
应用性能管理（英语：ApplicationPerformanceManagement），是一个比较新的网络管理方向，主要指对企业的关键业务应用进行监测、优化，提高企业应用的可靠性和质量，保证用户得到良好的服务，降低IT总拥有成本(TCO)。
使用全业务链的敏捷APM监控，可使一个企业的关键业务应用的性能更强大，可以提高竞争力，并取得商业成功，因此，加强应用性能管理（APM）可以产生巨大商业利益。
参考资料来源：百度百科-APM（每分钟操作的次数）
参考资料来源：百度百科-APM（高级电源管理）
参考资料来源：百度百科-APM（旅客自动捷运系统）
参考资料来源：百度百科-APM（自动化精确生产）
参考资料来源：百度百科-APM（应用性能管理）
Github 链接 Collie
如何衡量一个APP性能好坏？直观感受就是：启动快、流畅、不闪退、耗电少等感官指标，反应到技术层面包装下就是：FPS（帧率）、界面渲染速度、Crash率、网络、CPU使用率、电量损耗速度等，一般挑其中几个关键指标作为APP质量的标尺。目前也有多种开源APM监控方案，但大部分偏向离线检测，对于线上监测而言显得太重，可能会适得其反，方案简单对比如下：
还有其他多种APM检测工具，功能复杂多样，但其实很多指标并不是特别重要，实现越复杂，线上风险越大，因此，并不建议直接使用。而且，分析多家APP的实现原理，其核心思路基本相同，且门槛也并不是特别高，建议自研一套，在灵活性、安全性上更有保障，更容易做到轻量级。本文主旨就是 围绕几个关键指标 ：FPS、内存（内存泄漏）、界面启动、流量等，实现 轻量级 的线上监测。
Crash统计与聚合有比较通用的策略，比如Firebase、Bugly等，不在本文讨论范围
每个APP的网络请求一般都存在统一的Hook点，门槛很低，且各家请求协议与SDK有别，很难实现统一的网络请求监测，其次，想要真正定位网络请求问题，可能牵扯整个请求的链路，更适合做一套网络全链路监控APM，也不在讨论范围。
线上监测的重点就聚焦后面几个，下面逐个拆解如何实现。
直观上说界面启动就是：从点击一个图标到看到下一个界面首帧，如果这个过程耗时较长，用户会会感受到顿挫，影响体验。从场景上说，启动耗时间简单分两种：
本文粒度较粗，主要聚焦Activity，这里有个比较核心的时机：Activity首帧可见点，这个点究竟在什么时候？经分析测试发现，不同版本表现不一，在Android 10 之前这个点与onWindowFocusChanged回调点基本吻合，在Android 10 之后，系统做了优化，将首帧可见的时机提前到onWindowFocusChanged之前，可以简单看做onResume（或者onAttachedToWindow）之后，对于一开始点击icon的点，可以约等于APP进程启动的点，拿到了上面两个时间点，就可以得到冷启动耗时。
APP进程启动的点可以通过加载一个空的ContentProvider来记录，因为ContentProvider的加载时机比较靠前，早于Application的onCreate之前，相对更准确一点，很多SDK的初始也采用这种方式，实现如下：
这样就得到了冷启动的开始时间，如何得到第一个Activity界面可见的时间呢？大概回执流程如下
网上有一些认为可以监听onAttachedToWindow或者OnWindowFocusChange，onAttachedToWindow的问题是可能太过靠前，还没有Draw, OnWindowFocusChange的缺点可能是太过滞后。其实可以简单认为在view draw以后，View的绘制就算完成，虽然到展示还可能相差一个VSYNC等待图层合成，但是对于性能监测的评定，误差一个固定值可以接受：
在onResume函数中插入一条消息可以吗，理论上来说，太过靠前，这条消息在执行的时候，还没Draw，因为请求VSYNC的同步栅栏是在是在Onresume结束后才插入的，无法拦截之前的Message，但是由于VSYNC可能存在复用，Onresume中插入的消息也有可能会在绘制之后执行，这个不是完全一定的，比如点击MaterialButton启动一个Activity，第二个Activity的setView触发的VSYNC就可能复用MaterialButton的波纹触发的VSYNC，从而导致第二个Activity的performTraval复用第一个VSYNC执行，从而发生在onResume插入消息之前，如下
综上所述， 将指标定义在第一次View的Draw执行可能比较靠谱 。具体可以再DecorView上插入一个透明View，监听器onDraw回调即可，如果觉得不够优雅，就退一步，监听OnWindowFocusChange的回调，也勉强可以接受, OnWindowFocusChange一定是在Draw之后的。如此就可以检测到冷启动耗时。APP启动后，各Activity启动耗时计算逻辑类似，首帧可见点沿用上面方案即可，不过这里还缺少上一个界面暂停的点，经分析测试，锚在上一个Actiivty pause的时候比较合理，因此Activity启动耗时定义如下：
同样为了减轻对业务入侵，也依赖registerActivityLifecycleCallbacks来实现：补全上方缺失
到这里就获取了两个比较关键的启动耗时，不过，时机使用中可能存在各种异常场景：比如闪屏页在onCreate或者onResume中调用了finish跳转首页，对于这种场景就需要额外处理，比如在onCreate中调用了finish，onResume可能不会被调用，这个时候就要在 onCreate之后进行统计，同时利用用Activity.isFinishing()标识这种场景，其次，启动耗时对于不同配置也是不一样的，不能用绝对时间衡量，只能横向对比，简单线上效果如下：
FPS是图像领域中的定义，指画面每秒传输帧数，每秒帧数越多，显示的动作就越流畅。FPS可以作为衡量流畅度的一个指标，但是，从各厂商的报告来看，仅用FPS来衡量是否流畅并不科学。电影或视频的FPS并不高，30的FPS即可满足人眼需求，稳定在30FPS的动画，并不会让人感到卡顿，但如果FPS 很不稳定的话，就很容易感知到卡顿，注意，这里有个词叫 稳定 。举个 极端 例子：前500ms刷新了59帧，后500ms只绘制一帧，即使达到了60FPS，仍会感知卡顿，这里就突出 稳定 的重要性。不过FPS也并不是完全没用，可以用其上限定义流畅，用其下限可以定义卡顿，对于中间阶段的感知，FPS无能为力，如下示意：
上面那个是极端例子，Android 系统中，VSYNC会杜绝16ms内刷新两次，那么在中间的情况下怎么定义流畅？比如，FPS降低到50会卡吗？答案是不一定。50的FPS如果是均分到各个节点，用户是感知不到掉帧的，但，如果丢失的10帧全部在一次绘制点，那就能明显感知卡顿，这个时候， 瞬时帧率 的意义更大，如下
Matrix给的卡顿标准：
总之，相比1s平均FPS，瞬时掉帧程度的严重性更能反应界面流畅程度，因此FPS监测的重点是侦测瞬时掉帧程度。
在应用中，FPS对动画及列表意义较大， 监测开始的时机 放在界面启动并展示第一帧之后，这样就能跟启动完美衔接起来，
侦测停止的时机也比较简单在onActivityPaused：界面失去焦点，无法与用户交互的时候
如何侦测瞬时FPS？有两种常用方式
360的实现依赖Choreographer VSYNC回调，具体实现如下：循环添加Choreographer.FrameCallback
这种监听有个问题就是，监听过于频繁，因为在无需界面刷新的时候Choreographer.FrameCallback还是不断循环执行，浪费CPU资源，对线上运行采集并不友好，相比之下BlockCanary的监听单个Message执行要友善的多，而且同样能够涵盖UI绘制耗时、两帧之间的耗时，额外执行负担较低，也是本文采取的策略，核心实现参照Matrix：
为Looper设置一个LooperPrinter，根据回传信息头区分消息执行开始于结束，计算Message耗时：原理如下
自定义LooperPrinter如下：
利用回调参数""与""的 区别即可诊断出Message执行耗时，从而确定是否导致掉帧。以上实现针对所有UI Message，原则上UI线程所有的消息都应该保持轻量级，任何消息超时都应当算作异常行为，所以，直接拿来做掉帧监测没特大问题的。但是，有些特殊情况可能对FPS计算有一些误判，比如，在touch时间里往UI线程塞了很多消息，单条一般不会影响滚动，但多条聚合可能会带来影响，如果没跳消息执行时间很短，这种方式就可能统计不到，当然这种业务的写法本身就存在问题，所以先不考虑这种场景。
Choreographer有个方法addCallbackLocked，通过这个方法添加的任务会被加入到VSYNC回调，会跟Input、动画、UI绘制一起执行，因此可以用来作为鉴别是否是UI重绘的Message，看看是不是重绘或者触摸事件导致的卡顿掉帧。Choreographer源码如下：
该方法不为外部可见，因此需要通过反射获取，
然后在每次执行结束后，重新将callback添加回Choreographer的Queue，监听下一次UI绘制。
这样就能检测到每次Message执行的时间，它可以直接用来计算 瞬时帧率 ，
瞬时掉帧小于2次可以认为没有发生抖动，如果出现了单个Message执行过长，可认为发生了掉帧，流畅度与瞬时帧率监测大概就是这样。不过，同启动耗时类似，不同配置结果不同，不能用绝对时间衡量，只能横向对比，简单线上效果如下：
内存泄露有个比较出名的库LeakCanary，实现原理也比较清晰，就是利用弱引用+ReferenceQueue，其实只用弱引用也可以做，ReferenceQueue只是个辅助作用，LeakCanary除了泄露检测还有个堆栈Dump的功能，虽然很好，但是这个功能并不适合线上，而且，只要能监听到Activity泄露，本地分析原因是比较快的，没必要将堆栈Dump出来。因此，本文只实现Activity泄露监测能力，不在线上分析原因。而且，参考LeakCanary，改用一个WeakHashMap实现上述功能，不在主动暴露ReferenceQueue这个对象。WeakHashMap最大的特点是其key对象被自动弱引用，可以被回收，利用这个特点，用其key监听Activity回收就能达到泄露监测的目的。核心实现如下：
线上选择监测没必要实时，将其延后到APP进入后台的时候，在APP进入后台之后主动触发一次GC，然后延时10s，进行检查，之所以延时10s，是因为GC不是同步的，为了让GC操作能够顺利执行完，这里选择10s后检查。在检查前分配一个4M的大内存块，再次确保GC执行，之后就可以根据WeakHashMap的特性，查找有多少Activity还保留在其中，这些Activity就是泄露Activity。
内存检测比较简单，弄清几个关键的指标就行，这些指标都能通过 Debug.MemoryInfo获取
这里关心三个就行，
一般而言total是大于nativ+dalvik的，因为它包含了共享内存，理论上我们只关心native跟dalvik就行，以上就是关于内存的监测能力，不过内存泄露不是100%正确，暴露明显问题即可，效果如下：
流量监测的实现相对简单，利用系统提供的TrafficStats.getUidRxBytes方法，配合Actvity生命周期，即可获取每个Activity的流量消耗。具体做法：在Activity start的时候记录起点，在pause的时候累加，最后在Destroyed的时候统计整个Activity的流量消耗，如果想要做到Fragment维度，就要具体业务具体分析了，简单实现如下
Android电量状态能通过一下方法实时获取，只是对于分析来说有点麻烦，需要根据不同手机、不同配置做聚合，单处采集很简单
不过并不能获取绝对电量，只能看百分比，因为对单个Activity来做电量监测并不靠谱，往往都是0，可以在APP推到后台后，对真个在线时长的电池消耗做监测，这个可能还能看出一些电量变化。
没想好怎么弄，显不出力
APP端只是完成的数据的采集，数据的整合及根系还是要依赖后台数据分析，根据不同配置，不同场景才能制定一套比较合理的基线，而且，这种 基线肯定不是绝对 的，只能是相对的，这套基线将来可以作为页面性能评估标准，对Android而言，挺难，机型太多。
GITHUB链接 Collie
