@AssKicker 关于4,5,6 我大概明白你的问题咯, 你的问题大概在于现有的push平台都没提供一个交互良好的界面吧.

我刚才测试了下, JPush是支持emijo的. http://xiezefan.qiniudn.com/emijo_test.jpg 但在控制台中的确不能发送emijo, 就算复制进去都不行, 用原始编码也不可以. 我这是通过 推送API调用 推送的.

可能是因为一些Android设备对Emijo支持不是很好吧. 为了支持全平台, 在通用的推送页面中加入Emijo并不是一个很好的设计吧.(个人看法)

建议你自己可以实现一个Web Portal, 简单实现下自己的推送要求, 我所知的很多用户都是通过自己的管理后台调用推送api去进行推送. 这样可以做到更灵活, 像表情支持, 预览, 声音选择都可以通过自己的业务要求来实现.

其实我觉得, 为什么各大push平台都没提供很完善的推送交互界面, 可能更大的原因在于, 对于绝大多数用户来说, 这并不是主要需求并且很多时候他们希望把push管理这个功能集成到自己的管理后台.

@AssKicker 简单回复下你的几个问题

1. 页面体验不好, 这个在于推送产品的核心竞争力在于推送到达率与各种智能推送相关的业务(如分区域推送, 分性别推送等). 对于创业公司来,做不了大而全, 就先做小而美吧.
2.apns有一个开发模式和一个生产模式, apns开发中收不到消息, 90%是没设置这个的原因吧.
3.推送慢不知道是指哪一个方面? 是指收到消息慢么? apns推送其实对于push平台来说只是做一个转发(当然push平台提供的更多是全平台统一的api接口和各种智能推送), 你收到消息慢可能和你本地的网络环境与apns服务器之前的通讯质量有关. (我们也有遇到过关于推送过快, 导致大批量用户收到推送后进入相关页面, 导致客户服务器承受不知的问题. 后来也有相应的api提供定速推送的功能.)
4.emoji表情, 这个有支持.
5.模拟预览, 这个有支持. 虽然我觉得不是很好用.
6.关于声音的问题, 额, 这个我觉得更多的是业务平台去解决的问题嘛? 不是推送平台应该做的事情咯.

不知道对于一个to B的产品来说, 楼主所指的用户体验是哪一方面?
评价推送产品的好坏, 最重要的还是推送的到达率咯. 如果有机会的话, 可以小批量上线一个版本, 去测试各个推送的到达率.
我所知很多客户在选择我们的产品的时候, 多做过这样的测试评估.
而对于 大公司产品 = 靠谱, 真是一个错误的认知
利益相关:某推送平台的员工

在一家IT公司实习, 年会抽奖中的大多都是老员工. 有的人据说每年都中2等奖的.
但是我一点怨言都没有.
因为
TMD抽!奖!程!序!是!我!写!的! T_T
人品差不能怪谁呀.

@n37r06u3 才疏学浅, 只是从经验触发吧. 嘻嘻. 以我接触的API为例子, 新浪微博的API大多采用access_token的形式, JPush则采用Basic认证

@heaton_nobu 我说的两种方案并不是登陆的方法. 实际上, HTTP协议是无状态协议 , 也就是说他不能记忆客户端请求的状态, access_token 和 session 都是通过验证用户登陆后返回的一个token&id来记录客户端的状态(是否登陆,是否有权限), 只不过区别在于session有很多现成的实现, 而access_token更多的是需要自己业务实现, 不过好处在于access_token不需要依赖cookies. 而Basic认证(就是使用Authorization)则是每次请求都携带认证信息. 对于每次API请求服务端都会做鉴权.
无论上述哪种实现, 最好就是能做到对业务代码无侵入性(业务代码可以认为他每次接到的请求都是合法有权限的且不知道客户端是使用何种权限进入的).
至于性能问题, 我曾经将用户权限存到内存数据库中, 如Redis, 请求的时候, 从内存中取数据并鉴权性能还可以接收, 至于如何存储用户权限以达到最少计算次数与最低复杂度, 要依靠你的项目而定. 如果用户量太大的话, 可以采用LRU(最近最久未使用)等算法. 讲太久未调用API的user从内存数据库中删除, 当再次调用的时候才从数据库中读到内存.

一般有两种做法吧
1. 使用access_token
2. 使用HTTP Header 的 Authorization

access_token一般用在get请求中, 因为很容易被捕获到, 所以一般设计为有时效性的, 例如 一次性的accss_token, 或者 1小时内有效.

Authorization的话, 一般以这种形式提交上去
Authorization : Basic base64_auth_code
其中 base64_auth_code 用是 username + ":" + api_secret 做 base64编码, 因为base64是可逆的, 所以如果 api_secret 是使用用户的password等敏感信息的话, 可以考虑做 md5加密.
如 Authoirzation : Basic Base64(username:md5(password))

在服务端的话, 可以考虑在controller层写filter过滤用户权限, 并做响应的转发.

少了大名鼎鼎的 async 少年
任务调度的 later, node-sechedule，agenda