和 Twitter 开发者们一起学习通知管理技巧
文本由 Google 和 Twitter 合作完成。作者: Twitter 软件工程师 Jingwei Hao; 主要贡献者: Twitter 软件工程师 César Puerta, Fred Lohner 以及 Google 开发技术推广工程师史婧羽
通知推送是 Twitter 用户获取最新动态的重要渠道之一。然而我们平时探讨设备异常耗电的问题时，却常常忽略了这个 “超级电池杀手”。比如: 高优先级通知可以将设备从 Doze 状态中唤醒；推送产生的联网数据下载也会加速电量的消耗。
高优先级
https://firebase.google.cn/docs/cloud-messaging/concept-options#setting-the-priority-of-a-message
Doze
https://developer.android.google.cn/training/monitoring-device-state/doze-standby
作为 Twitter 的开发者，我们深知续航时间是影响用户体验的关键要素之一。因此，在产品迭代过程中，我们从多个角度对应用进行了优化，着重攻克了通知管理这一挑战，确保应用能够与 Android 省电特性协同工作。本文章分享了 Twitter 在节省电池电量方面的一些实践，希望各位读者在阅读过程中可以有所收获，为应用制定更出色的优化方案。
Firebase Cloud Messaging 迁移
今年上半年，我们把 Twitter 的通知消息推送库从 GCM 更新到了 Firebase Cloud Messaging (FCM) ，让应用可以使用最新的 API 和 Firebase 提供的其它特性。
GCM:
https://developers.google.cn/cloud-messaging/
这次迁移工作十分特殊，主要原因有:
通知推送是 Twitter 移动参与战略的重要组成部分。用户通过推送不仅能够获取资讯，了解世界，还可以帮助炸鸡少年完成梦想。因此，不论在迁移中，还是在迁移后，我们都必须保证通知传递渠道的可靠性，以免影响平台的正常运作。
由于应用不能同时支持 GCM 和 FCM, 因此我们在迁移过程中无法使用 A/B 测试。
"炸鸡少年" Twitter:
https://twitter.com/carterjwm
为了降低风险，我们在 dogfood、alpha 和 beta 三个渠道上都进行了彻底的迁移测试和回滚测试，实时指标监测变化并采取了分段发布策略。从 GCM 到 FCM 的迁移过程中，我们很高兴看到所有用例都对 FCM 接受良好，可顺利工作。
事实证明，将信息库迁移至 FCM 有助于我们在 Android 上测试省电特性。通过调用 getPriority() 和 getOriginalPriority() 等 API, 我们可以及时获知 FCM 消息是否被用户降级。
getPriority()
https://firebase.google.cn/docs/reference/android/com/google/firebase/messaging/RemoteMessage.html#getPriority()
getOriginalPriority()
https://firebase.google.cn/docs/reference/android/com/google/firebase/messaging/RemoteMessage.html#getOriginalPriority()
为 FCM 消息设置正确的优先级
在 Twitter 的后台，我们需要尽力确保数据信息被分配至正确的级别，以保证高优先级的 FCM 消息仅用于生成用户可见通知。实际上，在用户收到的通知中，只有很少的一部分属于高优先级消息。
Android 9 Pie 新增了一款名为应用待机分组的电量管理特性。系统根据应用所在的分组实施不同程度的限制。根据应用所属分组，每日接受的高优先级消息数量可能受限。因此，开发者在设定高优先级消息时，应当首先考虑那些更可能与用户产生交互的通知。如果高优先级消息无法与用户发生互动，可能会导致以下不良结果: 一旦应用耗尽了所属分组的高优先级消息额度，那么后续真正紧急的 FCM 消息会被降至普通优先级，并在设备处于 Doze 状态时被延迟处理。
应用待机分组
https://developer.android.google.cn/about/versions/pie/power#buckets
为了进一步了解待机分组对应用性能造成的影响，我们分别在消息发送和传递两个时段，收集了消息优先级的相关数据:
测试期间，我们发现所有高优先级 FCM 消息均未遇到降级问题，尤其是，在信息传递后，被分配至 “频繁” 或更低分组的 2% 设备也是如此。
有一点特别需要注意: 系统可能会限制活跃度较低的设备接受高优先级 FCM 消息。
当应用收到高优先级 FCM消息后, 86% 的设备被提升至活跃分组。这也说明了我们的分级标准与用户的使用习惯相符。
可能会限制:
https://developer.android.google.cn/topic/performance/power/power-details
测试结果令人满意，不论 Android 系统是否判定应用处于活跃状态，用户都可以立刻接收到重要通知，不存在任何延迟情况。这同样证明了我们根据用户的交互习惯，为应用创建了正确的高优先级 FCM 消息。
避免通知预先加载后续数据
为了打造更丰富的用户体验，开发者在设计应用的通知功能时通常会对数据进行预取处理。这可能会在通知的有效负载中增加一段元数据。当消息被传递至设备后，应用会通过有效负载数据启动一个或多个网络调用，以便在在设备显示消息之前下载更多的数据。FCM 的有效负载上限为 4KB, 如果应用希望在通知内呈现更多内容，就必须预先加载超出上限部分的数据，但是数据预取会增加设备的耗电量，并加重消息延迟的问题。在 Twitter 推送给用户的所有通知中，只有一类通知的预加载数据量低于 1%。如果数据预取无法避免，建议开发者通过 JobScheduler 和 WorkManager 调度任务，以此避免 Oreo 之后版本施加的后台执行限制对推送造成影响。
JobScheduler:
https://developer.android.google.cn/reference/android/app/job/JobScheduler
WorkManager:
https://developer.android.google.cn/topic/libraries/architecture/workmanager/
后台执行限制:
https://developer.android.google.cn/about/versions/oreo/background
创建通知渠道
此外，Android 8 Oreo 引入了通知渠道。我们在设置渠道的重要性级别时考量了诸多因素，其中最重要的两点分别是用户体验和节省电量。 目前，我们在 Twitter 的 Android 客户端上共设有 9 条通知渠道，其中只有消息传送、紧急和安全这 3 条渠道的重要性级别较高，其余 6 条渠道的重要性级别都比较低，不会对用户造成过多的困扰。
通知渠道:
https://developer.android.google.cn/training/notify-user/channels
重要性级别:
https://developer.android.google.cn/training/notify-user/channels#importance
总结
为了给 Twitter 用户们打造更棒的体验，我们分别从以下四个方面优化了通知管理方式: 迁移至 FCM，设置正确的通知优先级别，限制数据预取以及创建合适的通知渠道。我们很高兴看到这些变更带来的喜人成绩: 优化后，设备续航时间更长了，应用也可以与最近几个 Android 版本推出的省电特性无缝配合。
为大型应用设计电量优化方案是一个十分复杂的长期过程，这一点在 Android 平台不断扩大，精细控制日益增多的背景下尤为明显。Twitter 坚信持续优化能够有效改善应用的性能并提高资源的利用效率。希望本文内容能够解答您在性能优化和资源调用方面的疑惑，在开发路上助您一臂之力。
推荐阅读