开源的IM框架--担心

a) 自行研发移动IM，技术门槛高，开发周期长。根据我们的经验，至少需要资深的Android工程师，iOS工程师，后台工程师各一名，需要至少2到6个月时间。主要的技术难点包括：

• 协议和IM服务器的选择：当前常用作IM的协议包括XMPP和MQTT，也有用SIP的，还有自行开发的私有协议。可以使用的开源的IM服务器包括OpenFire, Tigase, Prosody, Mosquitto, ejabberd等。你知道它们各自的优缺点吗，你知道哪个协议，那个IM服务器实现最适合你的需求吗，你知道你一旦选定了一个方案，你分别需要对协议和IM服务器做哪些改动和改进吗？
• 不稳定网络环境下（3G,2G,Wifi，无网络，及各种网络环境下的切换）移动终端即时通讯长连接可靠性的维护
• 移动终端耗电量优化
• 移动终端流量优化
• 发送各类富媒体消息的特定处理，如语音文件格式选择，语音压缩算法，语音降噪算法，图片压缩处理，地理位置，名片，文档等
• 消息回执处理(ack)，防止消息丢失。
• 离线消息处理。离线时的实时消息通知（比如通过第三方推送平台）
• 实时状态同步
• 支持千万级同时在线用户的高可靠，高并发的服务器集群架构的搭建和运维
• 安全

b) 移动IM是一个需要长期跟进和维护的技术，并不是产品上线后研发团队就可以解散了。作为运营者，你做好长期的技术投入的思想准备了吗？比如新的IM功能层出不穷，如匿名社交，阅后即焚，你的产品要不要与时俱进？移动IM相关的各种安全隐患和漏洞，你要不要及时修复？所以你需要问自己一个问题，移动IM技术是你的核心竞争力吗，还是只是支撑你的业务实现的一个工具？

c) 移动IM服务对服务器硬件，网络，运维环境，都有非常高的要求。需要长期持续的服务器端运维投入。

d) 绝大多数团队都不具备百万级，千万级并发的IM技术。一旦用户量爆发性增长，APP的基本可用性会有极大的隐患。

另外，不需用担心使用2个推送服务会给app带来额外的电量或流量的开支。因为现在的推送服务，包括环信，都做了很细致的优化。比如环信的android版可以做到在静默状态下24小时只消耗2.7K的流量。所以就算有2个推送服务跑在后台，也不会对app有任何影响。