在某些时候，您的企业将意识到它必须认真对待提高移动应用程序的性能/质量。对于监控移动应用程序性能所涉及的内容存在很多混淆/误解。在此博客中，我将描述开始的整个过程以及移动应用程序性能监控在生产中的工作方式。
在与许多公司谈论他们的企业移动应用程序时，我注意到移动计划频繁启动的趋势。在许多情况下，市场营销人员或业务人员迫切需要面向消费者的应用程序，用于公司品牌的一些新项目或计划，无论是用于促销活动还是其他类型的活动。
但是企业 IT 团队不具备本地移动应用程序开发的内部技能，而且移动应用程序通常不属于传统 IT 运营团队的领域，他们需要很长时间才能做好准备，所以企业使用他们的自由裁量权、项目或广告/营销预算与代理机构或咨询公司合作，以便及时为手头的项目构建应用程序。
然后，一旦该应用程序出于其最初目的在您的客户中广为流传，将不可避免地发生以下过程：
- 当公司决定将其用于其他目的时，应用程序的预期范围将扩大，并具有超出最初最低限度可行产品定义的附加特性和功能，
- 由于未预料到的问题或由于后来添加的新功能引入的错误和性能问题，应用程序肯定也会出现问题，例如将应用程序绑定到企业 IT 基础架构中以获取支持新功能所需的服务，
- 用户会对这些问题感到不安，并在应用程序商店或社交媒体上发表严厉的评论，这会使应用程序的排名很差。他们甚至可能会完全删除该应用程序，
- 公司将意识到糟糕的应用程序体验正在损害公司品牌并损害其客户和商誉，并且
- 会有人疯狂地呼吁，有人必须为此做点什么才能使它正确。
在这一点上，IT 可能不得不介入，因为现在该应用程序已成为公司业务战略的重要组成部分，并与企业 IT 基础架构相关联。 IT 运营团队很可能已经熟悉他们负责管理的企业应用程序的应用程序性能管理 (APM)，但由于他们没有开发和管理移动应用程序，因此他们可能不熟悉或不知道如何操作APM 适用于移动应用程序。
监控移动应用程序的性能与传统的 IT Ops APM 有点不同，在传统的 IT Ops APM 中，服务器端应用程序运行在由 IT 在企业数据中心或私有或公共云环境中管理的服务器基础架构上。主要区别在于，传统 IT 企业应用程序由 IT 团队自己直接管理，他们经常负责构建（开发）应用程序，然后在他们可以直接访问它的服务器基础架构上部署和管理它，并且控制它。
在移动应用程序生态系统中，应用程序与访问、控制、管理和监视应用程序的过程之间存在一定程度的间接性。在传统的 APM 世界中，IT 可以通过应用程序基础架构添加对应用程序性能的监控，而无需修改应用程序本身，因为他们可以直接访问托管和运行应用程序的系统。
由于涉及的间接级别和缺乏对运行应用程序的设备的直接访问，在您的客户使用移动应用程序时添加性能监控的过程是不同的。
由于您的客户直接在他们的个人或公司手机上使用移动应用程序，因此监控“生产中”应用程序性能的机制称为移动真实用户监控或移动 RUM。图 1 显示了将 AppDynamics Mobile 真实用户监控添加到您的移动应用程序以便您可以监控其性能的整个过程。
开发者进程
您要做的第一件事是将 AppDynamics Mobile RUM SDK 合并到您的本机移动应用程序中。
- 开发人员从 AppDynamics 网站下载 iOS 或 Android SDK
- 开发人员使用各自的集成开发环境 (IDE)，即用于 iOS 应用程序的 xCode 和带有 Android 开发人员工具插件的 Eclipse 或用于 Android 应用程序的 Android Studio
- 开发人员使用相应的 IDE 将相应的 SDK 编译到您的应用程序中
- 作为测试和 QA 流程的一部分，您可以让有限数量的 Beta 用户测试您的应用并在您将其发布到应用商店之前监控性能
- 使用可用的 Beta 分发机制之一分发 Beta
- 开发人员将您的应用程序的新版本提交到适当的应用程序商店
- 应用通过审核后，新版本的应用会在审核通过后出现在应用商店中
- App已上架应用商店供客户下载新版本
用于移动应用程序性能监控的数据交换
一旦最终用户更新到新版本的应用程序并开始使用它，就会触发许多数据流。
- 发生的第一件事是，在某个时候，应用程序将通过网络向某些后端基础设施发出一些请求。作为请求的一部分，通过 SDK 内置到应用程序中的 AppDynamics Mobile RUM 代理将自动检测请求并将 AppDynamics 标识符添加到标头中。
- 当响应被发送回移动应用程序时，附加信息将被添加到标头中，包括 GUID（全球唯一标识符），它唯一地标识特定请求以供以后分析，执行该特定业务事务所花费的时间，平均BT 执行时间，以及该特定 BT 的标识符
部署灵活性
数据流的下一部分取决于您选择如何实施部署选项。 AppDynamics 提供灵活的部署选项，包括纯 SaaS 选项和混合 SaaS/本地选项的纯本地选项。
第一个选项是选择使用 Mobile RUM Cloud SaaS 数据收集器或内部部署的 Mobile RUM 服务器。在数据流的第 3 步中，AppDynamics 移动应用程序代理将向移动 RUM 云（图中的 3A）或移动 RUM 服务器（图中的 3B）发送信息，包括对象 ID、NSURL（在iOS 或 Android 等价物），来自先前崩溃的任何崩溃 API 数据，以及您可能已选择为您的应用程序收集的任何自定义数据。
移动 RUM 云或移动 RUM 服务器从您的客户正在使用的所有移动应用程序客户端收集此数据，对数据进行一些处理/聚合，然后将其传递到下一步。此步骤中没有永久数据存储。
第二个选项是选择使用 AppDynamics SaaS 控制器或 AppDynamics 内部部署控制器。在数据流的第 4 步中，处理/聚合的数据从移动 RUM 云或移动 RUM 服务器发送到 SaaS 控制器或内部部署控制器。
控制器是您的所有应用程序性能数据相关联、基线化、存储和访问的地方，以便组织中参与运行、维护、操作和业务的所有人员进行监视、警报、分析和操作。你的申请。
您的员工通过基于 Web 的 AppDynamics 门户访问 Controller，在那里他们可以查看您的应用程序性能数据的特定角色视图，并可以通过作战室协作更快地解决问题（故障排除、问题识别和隔离）或监控业务通过自定义性能操作和业务/执行仪表板。