app推送架构设计之全局观

• BroadcastReceiver只负责显示Notification，而Service才是推送消息的实际执行者，那为何要如此设计呢？
  
  • BroadcastReceiver生命周期最多只有8秒，超过8秒会造成ANR，而Service则不存在这个问题。很明显，BroadcastReceiver天生就是不适合处理复杂操作的组件。因此，考虑到未来推送的复杂性和扩展性，上图的具体处理流程将是：
    
    1. BroadcastReceiver接收push消息
    2. 显示Notification
    3. 点击Notification（Notification包含的PendingIntent用于启动Service），启动Service
    4. Service解析Notification传递过来的Intent，执行具体操作（可通过策略模式，让代码不要那么烂），比如打开一个页面、执行网络请求、执行本地操作……
  • Notification上按钮的点击是无法自动取消Notification，因此，Service还用于取消Notification
  • 将Notification的显示和执行分开，同时通过策略模式进行执行。这样的好处是便于维护和降低代码耦合