前些日子参加了Velocity大会，在大会上听云的张涛先生在国内第一次提出了mAPM（移动APM）的概念。笔者是一个由传统运维工程师创业的移动开发者，刚好对APM有所了解。本文将对国内外移动APM做一个简单的介绍，希望大家喜欢。
在传统企业里，IT运营部门仍然在购买APM监控工具，但这部分市场对于大多数APM服务商而言都显得太过单调。理由很简单，目前市场上几乎找不到针对移动App运营团队所需要的APM解决方案。通常传统企业的App都属于非重点项目，通常由来自业务部门的开发者或者应用程序支持团队负责运营管理。在多数传统企业中，根本不具备部署第三方APM工具监测管理App的能力。而大多数移动开发企业又都属于传统企业转型或初创企业（比如笔者），不是关注应用管理的意识不强，就是干脆没有预算来采购APM工具--有了问题直接让研发人员跑日志、看log,基本上还处于非常低端的形态。但是随着整个移动市场爆发，业务模式已经出现了翻天覆地的变化，数据和用户总量几何级增长使应用监控需求也在快速增长，这也间接地带动了APM行业发展。笔者预言：mAPM的时代来了！
换句话来说，新的mAPM方案要想从现有产品中脱颖而出就必须拥有明确的竞争力与吸引力，同时确保开发者能够参与到mAPM工具嵌入工作中来。目前，APM的SaaS化解决方案，已经可以实现事故管理与综合性事务处理。这对App性能管理的可用性来说非常重要。
国外mAPM服务商的解决方案已经有很多了，Keynote Systems公司为此投入重资，逐步将自身从传统APM转型到mAPM.目前Keynote Systems的移动业务在其总营收中占比已超过五成。如今他们已经能够实现移动设备模拟，利用实际设备在其POP内部执行测试任务。此外其它多家厂商也拿出了包括mAPM的综合性能监控解决方案。国内最近也有一些公司在做mAPM业务，其中包括Velocity大会上首次提出mAPM概念的听云。
真正的mAPM代码应该被嵌入到原生App当中，其代码要做的除了从移动角度提供性能数据之外、还需要通过各种通道将其交付给基础设施以及接口，比如网络、服务器、第三方API,监测工具SDK要嵌入App中，其体量大小也直接影响App运行的情况以及性能监测数据的准确性。
听云是国内首家mAPM解决方案提供商。通过应用内嵌入听云App SDK,同步真实用户访问体验，及时发现使用过程中的崩溃、连接超时、内存泄漏等问题。据笔者了解，听云是基调网络的SaaS化服务平台，针对移动App客户端--网络--Server端的整体解决方案。经过笔者的测试，其mAPM设计思路非常清晰，SDK也只有10K左右，相比国外同类产品优势也非常明显。
除了听云，下面再介绍几个国外的解决方案（需要梯子，使用极其麻烦）：
AppDynamics公司将推出一套混合型APM解决方案，其中包括由内部或者SaaS交付的mAPM产品。这样的设计思路使该方案显示出端到端完整形态、即由设备到托管基础设施的全面覆盖。
Crittercism公司此前则打造过一款事故检测工具，用于追踪紧急问题及App启动情况。他们如今开始从移动视角出发进行网络监控，并从更深层面剖析性能表现。Crittercism公司在这一新兴市场上占有一席之地，这主要是因为他们所使用的SDK目前已经被嵌入到了数百款原生移动应用当中。
最近我还看到了New Relic发布的mAPM产品--与AppDynamics类似，他们也将移动性能与基础设施及应用程序性能结合在了一起。New Relic公司只提供SaaS式解决方案。
经过对各产品对比，笔者发现各产品的价格定位经常发生变化，不过一般来讲通常会以月活数作为依据。各解决方案的价格基本相当，相比较而言，本地化的听云平台优势比较明显，拥有永久免费的版本，听云的收费版本也不需要用外国信用卡支付，使用非常方便。
对于APM行业来讲今年将是有趣的一年。作为一个由运维工程师转行移动互联网的从业人员来说，众多精彩纷呈的mAPM产品将接踵而至，所以请大家拭目以待。如果大家还有其它疑问，请与笔者进行反馈，期待能与各位进行深入交流。
免责声明：本网站内容主要来自原创、合作伙伴供稿和第三方自媒体作者投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。任何单位或个人认为本网站中的网页或链接内容可能涉嫌侵犯其知识产权或存在不实内容时，应及时向本网站提出书面权利通知或不实情况说明，并提供身份证明、权属证明及详细侵权或不实情况证明。本网站在收到上述法律文件后，将会依法尽快联系相关文章源头核实，沟通删除相关内容或断开相关链接。
