通过 SDK 抽象改善移动用户体验

您是否知道一个典型的应用程序平均使用 18 个第三方 SDK，如果是游戏，则更多？

SDK 膨胀和疲劳开始时很无辜，产品和工程团队提出了完全合理的问题：

如何收集数据并使用我需要的服务来改进应用程序和业务成功？

有许多 3rd 方集成和 SDK 可以帮助您做到这一点，如下图所示。但在不知不觉中，您使用了如此多的 SDK，您的应用程序因性能、不稳定和安全问题而变得臃肿和疲劳，最终——具有讽刺意味的是——给您的用户带来糟糕的体验。

虽然通常情况下，如果您想提供高质量的移动体验，您需要一种方法来了解用户行为并个性化这些体验，但考虑这些添加对您的应用程序性能的影响也很重要。

在最近的 mParticle 网络研讨会中，我们讨论了 HeadSpin 的性能洞察和 mParticle 的 SDK 抽象如何帮助您做出更好的选择并改善应用程序的移动用户体验。以下是涵盖的一些关键点。

 

哪些迹象表明您的应用正遭受 SDK 膨胀和疲劳？

1.) 缓慢的应用程序构建

你对你在 Xcode 或 Android Studio 中构建的很棒的应用程序感到非常兴奋——但应用程序构建速度非常慢。这可能会降低您的工作效率，但您认为这并不是真正的阻碍，您可以忍受它。但是那些缓慢的构建是你的应用程序中构建过多的早期指标。

2.) 依赖关系地狱

学习新的 API 并跟上 SDK 更新一直在消耗您的时间。当您的应用程序有太多依赖项时，问题就会变得更加复杂。如果您遇到一个依赖项的问题，该依赖项依赖于与该其他依赖项冲突的另一个依赖项，则您的应用程序很可能是 SDK 膨胀的候选者。

3.) 稳定性和性能问题

将您的应用发布到世界上之后会发生什么？当真正的客户开始抱怨崩溃、网络问题、整体不稳定和性能缓慢等问题时，这些很可能是由架构或膨胀问题引起的。在对此采取行动之前，不要等待差评。

4.) 安全风险

有你知道的问题和你不知道的问题。最终出现在您的应用程序中的每个项目都应该从安全角度进行审核，否则您可能会发现自己面临更隐蔽的问题的风险。如果您发现自己必须审核应用程序中的许多不同的二进制文件和包，您就会知道您可能遇到了 SDK 膨胀问题。

5.) 数据质量

如果您发现不一致的命名或分析事件在错误的时间触发，这可能表明分散的数据策略引起了数据质量问题。这是 SDK 膨胀和疲劳的另一个常见副产品。保持联合数据同步至关重要。您需要将良好的数据输入到用户分析工具中，以获得改进应用程序和发展业务所需的可靠报告。

最终，如果您使用多个 SDK 和集成，所有这些都会在您的应用程序中造成膨胀和疲劳。

使用 HeadSpin 识别性能问题

HeadSpin 提供了许多不同的分析视角，可以帮助您识别由 SDK 引起的负载。

1.) 依赖关系的 CPU 时间

一项真正对开发人员有帮助的分析是能够通过依赖性一目了然地了解 CPU 时间。

 

工作原理：您只需将您的 APK 或 IPA 连同相应的用户流程一起上传到 HeadSpin 的 Nimble 应用程序平台，以便应用程序逐步执行。 在流程执行时，Nimble 会分析应用程序的客户端性能。

在我们为一家零售商所做的分析中（如上所示），您可以看到，占用 CPU 时间的不仅是应用程序原生代码，还有应用程序中使用的大量第三方 SDK 和库，例如 AppsFlyer、ThreatMetrics、Appboy 等。我们可以针对不同的场景运行此分析，例如冷启动或热启动，或其他关键用户旅程，以查看这些 SDK 在这些活动期间消耗的 CPU 时间比例。

2.) SDK 发起的网络调用

HeadSpin 的另一个有用分析是不仅可以查看正在加载哪些 SDK，还可以查看第三方 SDK 进行的所有网络调用。

工作原理：HeadSpin 对在我们全球基础设施中的真实网络和设备上运行的应用程序执行性能测试，我们的 AI 引擎会自动分析所有客户端-服务器流量以生成一个仪表板，该仪表板可对影响应用程序性能的因素进行可视化和优先排序。

在启动应用程序时等待缓慢的启动画面是我们都可以涉及的事情。 在我们对一个应用程序冷启动的分析中（如下所示），我们立即注意到在应用程序委托阶段加载了许多 SDK，例如 Crashlytics 和 Adjust。 特别是，TCP 连接（橙色）因耗时过长而引人注目，尤其是与 TLS 握手（紫色）有关。 Adjust SDK 正在打开连接，当我们查找目标 IP 地址时，结果发现 SDK 试图在任何其他应用程序活动发生之前一直连接到公司在德国的位置。 

现在，让我们考虑我们所做的另一个分析。我们发现他们的应用程序用户必须等待 16 秒才能第一次有机会与应用程序交互，用度量交互时间 (TTI) 表示。进一步深入，我们看到对社交应用程序的调用正在被串行加载，这占了 5.3 秒的时间。

同样，在我们对一款金融应用程序进行的分析中，第 3 方 SDK 是导致启动时间变慢的主要原因。例如，我们看到托管在 Google 上的 UrbanAirship 正在重定向到亚洲，而不是它应该有的美国。

像这样的网络调用对于开发人员来说可能是一个黑匣子，尤其是当您使用 CocoaPods 或其他依赖项管理器来导入 SDK 时。但是，在客户端-服务器性能方面的影响确实可以叠加，尤其是在进行大量调用的情况下。

如何构建一个更合适应用程序

您可以做些什么来减少应用程序的膨胀和疲劳？以下是我们的建议：

• 让您的应用程序网络感知：移动 SDK 通常运行后台进程并建立 TCP 连接，最终会唤醒您的移动无线电。这不仅会导致进行网络呼叫的费用，而且还会延长设备的电池寿命。考虑在连接性检查之后包装您的 SDK 集成调用。您可以使用 Telephony Manager (Android) 和 NWPathMonitor (iOS) 库来查询连接状态。
• 根据用户选择做出决定：根据用户选择加载或利用 SDK 功能。除非需要，否则不要只在启动时加载 SDK，如果 SDK 允许，请自定义设置和配置以获得最佳用户体验。
• 使用抽象层消除 SDK 和 API 膨胀：通过 mParticle，您可以创建数据抽象和基础架构，帮助您避免 SDK 膨胀等问题并提高数据质量。您可以确定数据的来源、去向，并利用各种工具准确控制数据的外观、每个用户的持久化方式以及过滤方式用于安全和数据治理。
• 不要在您的应用程序中接受闭源 SDK：您应用程序中的每个额外二进制文件都会对其性能和稳定性产生影响。主线程访问、唤醒锁、崩溃等都可能导致问题。来自 mParticle 的 Sam Dozer 整理了一份应用程序开发人员权利法案，基本上说你有权对你的应用程序的质量和可维护性拥有完全的所有权。
• 考虑减少用户跟踪：您真的需要向这么多域发出跟踪请求吗？这不仅对应用程序性能和电池使用不利，而且实际上会给您的用户留下不好的印象。考虑到如今的消费者甚至会代理他们的设备来避免这种情况。

观看我们的网络研讨会

HeadSpin 监控、测量并提出建议，以提高跨应用程序、设备和网络的移动性能——无需 SDK。 mParticle 平台旨在成为您的 SDK 抽象层和数据中心，并完成与每个单独的应用程序服务集成的工作，因此您不必这样做。 一起使用它们可以：

• 识别并消除影响性能的开销
• 最大限度地减少应用程序膨胀和架构复杂性
• 收集和激活有价值的应用程序参与数据，而无需占用工程师的核心开发周期
• 保持整个基础架构的可见性

如果您想详细了解 SDK 膨胀以及我们如何提供帮助，请查看我们的点播网络研讨会，与 HeadSpin 开发人员产品副总裁 Jeena James、HeadSpin 客户成功负责人 Nathan Krishnan 和 Sam Dozer, Sr . mParticle 工程总监。