iOS 应用内推送组件技术方案
简述
应用内通知是指在应用的界面之内展示的消息，旨在向用户提供提醒，聊天消息或其他实时信息。
目前App内多个业务实现了应用内通知的功能，例如：一起听、私信以及收藏引导等。
目前存在一些潜在问题：
- 没有统一的视觉组件复用，每次开发需要造轮子或魔改，且造成外观样式的不统一和交互手感的不一致。
- 缺乏中心化的整体控制，用于明确业务的优先级和弹出顺序。在后续业务发展中，可能出现多个通知互相争夺的情况。
本方案旨在提供一套完整的应用内推送能力，使业务方通过简单接口即可使用，并提供完善的扩展能力。同时对所有通知提供初步的控制逻辑，在后续持续迭代。
流程/框架
流程如下：
架构如下：
视觉组件
应用内通知视觉样式由模板决定。业务只需要定义模板中各个部分的内容即可。
- 图标（必要）：业务需要展示的图标；
- 标题（必要）：用来简述通知的信息；
- 文本（必要）：用来描述详细内容的信息；
事件回调
目前通知有三个回调时机：
- 即将展示：通知在即将上屏展示前，会触发一次回调。业务可以实现此回调来更新最新的信息或者旧BI的曝光事件触发以及撤回此条通知不再展示。
- 即将隐藏：通知隐藏由五种事件触发：用户点击通知，用户点击关闭按钮，用户上推通知条出屏幕，展示时间超时被收回，展示时收到了高优先级通知的打断。业务可以实现此回调来上报曝光结束事件，或对业务逻辑进行处理。
- 通知被丢弃：受制于频控策略等影响，通知被丢弃，在丢弃时，触发此回调。
优先级和业务渠道
在通知发起时，需要明确通知的优先级和业务渠道。
优先级为预先定义好的枚举值，其作用在于处理通知之间的打断关系：
- 高优先级的通知会打断目前已经展示的低优先的通知，对屏幕进行抢占。
- 而相同优先级的通知，会进入等待池中等待通知的展示。
- 低优先级的通知会等待所有的通知消费完成后再进行展示。
渠道为字符串，扩展字段，目前不做逻辑处理，用以后续对通知业务做细分管控。
外部注入的控制策略
外部可以实现 ControlProtocol 协议，并将其注入到 Center 中来实现对控制策略的注入。
目前 ControlProtocol 将实现两个时机：
- 业务需要展示新的通知时触发。此时可以对当前通知进行丢弃或对当前等待队列进行排序和剔除。
- 通知即将上屏时触发。此次可以对当前通知进行丢弃。
勿扰状态
当业务需要用户沉浸体验不被打扰时，可以实现勿扰状态的方法，并对勿扰状态进行合理的维护。
ControlProtocol 协议中有勿扰状态的控制逻辑。在勿扰状态开启时，所有的通知都会被丢弃。
历史逻辑的处理
在接口层面上和之前通知组件的大致兼容。
在新的组件完成后，会移除NMPushKit中的NMDyNotification相关类，并对其使用方进行迁移，使 InAppPush 组件可以管控大部分场景。