最近同事在整理消息中心的产品设计逻辑，几轮讨论听下来也是有不少料的，那么我也来记录记录当中的干货&自己的想法。
【1】那些成功的产品是怎么做的（微博&微信）
微博，划分折叠为“评论，@我，赞；私信（已关注、未关注），群通知”五类型消息
评论，来源包括直接的评论跟参与的评论，除回复功能外，直接的评论可以查看完整对话。
@我 ，则更多展示完整的微博信息，跟标准的微博信息流无异，操作也基本一致。
赞，基本跟@我一致。
私信，简直就一垃圾桶，新浪的产品本来用意估计是要做社交聊天，但随着微博社交属性弱化，最终却成了营销号，加上还有“未关注人的私信”分类，则更加验证了我的猜想咯，呵呵呵
群通知，实在是没用过，这里就不多说了……
总结一下，评论、@我、赞都属于单向推送，与其他微博号产生的公开关系，当中评论最重且容易产生进一步交流，而@我跟赞则属于一种表态，被push后也只是简单地查看了解下被认同的具体是哪一条内容罢了。相对地，私信则属于双向动态的私密关系，本应该是‘约’、勾搭的最好落脚地，但只能兴叹世事难料~
微信，时间轴为组织关系，列表式展示所有非公开双向的信息，包括对话，订阅号，公众号的推送
不得不说他的设计逻辑是优秀的，首先是统一的列表交互形式易于理解，还有巧妙地将不能融合在一起、容易烦杂却有价值的社交动态另置于朋友圈（赞，评论等）
综上，消息分类维度有：单向/双向，公开/私密，人/系统，当然还有低频/高频等等；app设计时应该就自身需要，取关注重视的维度来进行组合。不过老实说，好的产品是在不知不觉中产生感受的，一般的小白不会惊叹只会用上瘾，只有上帝视觉的产品经理才能告知其中的设计出发点。
【2】如何结合自家app实际设计？
本家app可谓是超级大平台，各类型的消息、推送、评论、赞、转发、私聊要统一起来也是个大工程。参考过业界比较成功的消息系统，我们也做出了两跟随的方案，分tab归类or列表时间轴（微博or微信）。实际结合过程中当然没这么容易，跟随微博的方案虽然正适合咱信息分类维度多的特性能做好区分，但正如所有分tab交互设计得劣势，非首tab的曝光率低是最大的问题。而如果用列表时间轴的方式，考虑的则是对于大V来说，可能会出现系统消息（赞，评论）多，该分类不断置顶的现象【真自己开始设计抄袭的时候才发现微信朋友圈与聊天间的区间是这么的逻辑自然，服务号的每日限制推送条数是那么的人性化】
方案讨论了几轮下来，最终还是没有比较满意的结论，于是大佬拍板决定按微信的交互来，理由是消息跳动置顶的负面影响不必交互统一、学习成本低、曝光率高重要~这样做是否正确？时间会告诉一切，而且互联网产品不怕错，快速迭代能有试错的机会~
【3】说说技术实现
实时消息获取的技术实现。iOS消息推动需要系统授权；而安卓，则需要常驻一个服务在系统，这几乎是所以IM的必要做法，音乐app做社交，从信息轮询转变，也必须经历这样的阵痛吧。
