我刚才随手列了一下我用不了不太爽的微信地方：
1. 米聊号，记不住。赛马米聊号显然是机制一个有雄心的设计，但在今天，打败似乎操之过急。米聊
2. 也许因为米聊号不好记的微信原因，我发现有些用户有多个米聊号，赛马我有 225 个米聊好友，机制其中不下 10 个人有 2、打败3 个米聊账号。米聊因为米聊是微信一个自动帮我添加好友的产品，还不像 QQ 一样每个人有多个账户可以扮演不同身份，赛马让我根本不知道跟哪个说话。机制
3. 米聊显示每个人上一次的打败登录时间，我翻了几十个，米聊最远没登录过的是“上星期”。我觉得这有一定的欺骗性，也许没有，但让我有一种奇怪的感觉，担心这是一种委婉的说法——一个月没登录也等于一星期没登录？——其实有一些长期不登录的用户没事儿，只要正确提示，我也知道可以不跟他说话，用其他方式找他。现在我该不该和那些一周没登录过的用户说话呢？
4. 莫名其妙的加了一堆好友，没有选择性，微信则可以选认识的人里谁是你想添加为好友的。米聊这种不需要你许可就添加好友的产品，现在又有一个添加好友的通知，让我越发不知道干吗用的。
5. 把所有的新用户通知都放主界面，是模仿 kik/ whatsapp，这个很干扰。微信解决的更好。
6. 米聊点一个人的账户，进去之后太多资料，微信则是四个功能选项。我喜欢后者，除了直接，还有一个心理因素：让我觉得米聊不太像熟人的交流工具。
7. 名片、IM、群组、SNS，感觉米聊每个都想做，但没有一个做到绝对独特。
8. 删除一个好友的流程较为麻烦，大概需要三下。微信是两下。
9. 聊天时，米聊软键盘右下角是“换行”，微信是“发送”。显然后者更好。说起来，这是我使用中最干扰的细节。
10. 似乎通知系统有点问题，我在 iOS 5 下面老接不到通知。
11. 不知为什么老提示有未读信息，即使我已经刷了许多次。
12. 组建群聊，比如我在跟 A 聊天的界面里加了 B，说第一句话时还在 A 的界面里，再回过来就进入到另一个 A+B 的界面了。
13. 语音功能似乎有点问题，基本上播放时第一秒都是空白的延迟。这是 Talkbox 不会出现的。
14. 广播是一种奇怪的群组模式，用户没有主动性的被加入其中，有点干扰，但又没有特殊的主题。
15. 输入文字、push-to-talk 等功能挤在一起，对于手指粗的人不太方便。
几个月前，我曾经建议雷军去掉米聊中那个看似比较火的“广播”功能，雷军的回答是，如果米聊做成纯通信工具，就死定了。广播承载着雷军的社区理想，或许他认为，米聊要想存活并发展，就必须从帮助用户节省时间，走到帮助用户杀时间。
但是，基于电话本做“熟人社区”这个想法，其实非常不靠谱。电话本中可能包含着很多私密关系，父母、同学、同事、前女友、前前女友等等，米聊要把这些人拉到一起聊天，相当恐怖。熟人社区的想法，其实反映的是雷军的Facebook情结，但即使是Facebook，当父母、老板们大举进入，如果没有更好的隐私控制策略，那些曾经活跃的年轻人就该沉默或者离开了。
米聊的困境在于，它要挑战手机QQ，就必须形成自己的粘性，而这种粘性的最容易判断的指标，就是社区的活跃度。但不同的关系强度，根本无法形成一个统一的社区。所以最终，米聊的社区梦，不过是个黄粱梦。
对比一下微信，正好微信刚刚推出了“查看附近的人”这个功能，即所谓弹性社交功能。这是一个好玩的卖点，但却不是产品的关键点。微信的核心诉求，其实是一个移动hub，将腾讯的多个产品关联起来（如QQ离线消息、QQ邮箱、微博私信等），随时随地通知和响应。很多功能看上去只是其他产品的附属功能，但集成很多附属功能的产品，很可能不再是一个附属产品，这是一种低调务实的产品策略。
最终打败QQ的，很可能是微信，而不会是米聊。这是我的判断。社交是通信，社区是媒体，这点不搞清楚，会产生越来越多的逻辑冲突。
你这基本上就是在问一个身家100亿的富豪会不会羡慕一个身家500亿的富豪，然后自惭形秽觉得自己是屌丝。
答案是不会。
告诉你一个真相，身家100亿和身家500亿之间的区别，真的没有月入一万和月入五万那么大。
这算是我在知乎回答的第一个问题。
先说我的论点：
1.小米曾经确实“全力”做过米聊。所以第一问题的基础有问题，所以也没法说对错。当然目前得票最高的是在错误的前提下论证了，小米没有全力做米聊也没有错。
2.雷军当然不会后悔。
下面详细说说我的论据。
先说说背景，我是2011年8月加入小米，当时加入米聊校园渠道做推广，正赶上米聊和微信死磕的时候。
1)为什么说小米曾经“全力”做过米聊？
2010年雷老板组建了一个超级豪华的团队，开始启动小米。最开始还没有周博士，本着练兵融合团队，也是为了布局。让来自微软谷歌金山百度等互联网和 it人开始做 app练手。刚开始有小米司机，小米分享，迷人浏览器啥的。其中有一个项目，当时好像叫小米通讯助手，主要目标有点像现在的 miui黄页。发布后用户增长极其缓慢。直到冯智勇发现 talkbox,加入语音对讲，然后借助微博，一下子用户数曲线直接变成了垂直增长。后才改名米聊。正式放弃其他所有实验项目，全力投入米聊。另外有两个数据也可以佐证。米聊当时是唯一一个有两个合伙人盯的项目，前一百号员工有一半都扑在米聊上面。我也是因为米聊要大力推广，才有机会加入小米。
而且即便到了2012年，已经没有希望追上微信，雷老板也没放弃米聊，整个米聊团队近200人单独搬到宏源潜心练剑，希望找到下一个反超的弯道。
当然要说整个小米 all in米聊那不可能。因为雷军一开始布局就不是要这么玩的。当然也不是李楠说的机会成本。米聊就是无心插柳的意外收获。雷军当然知道它要是成了价值多大。所以在当时确实尽了最大的力量。
2.为什么雷军不会后悔？
首先如上所述，米聊是意外之财。开始并不在雷的整个布局里，是练兵偶然获得的。
其次雷已经尽了最大力量，大家可能不知道，雷为了阻击微信，还请了朋友做其他 app企图迷惑腾讯。
最后无论如何复盘，这是一场不可战胜的战役。从腾讯那边分析各个答案都说到一些。米聊也有很多故事，涉及老东家的一些隐私，我就不多说了。
总之米聊完成了它的使命，大家听说过tita吗？
米聊曾经是我的最爱，我的全部，工作生活，无限伤感。祝愿这次并入互娱能回生～
米聊和微信之间的距离，既有产品因素，也有公司成因，当然也有人为因素。
产品因素：
1、
米聊走的还是传统方式的IM思路，即通讯+社交的产品思维，这种模式其实早已被证明是行不通的，之前的网易泡泡、新浪收购的朗玛UC（后来改名新浪UC）都是如此。
米聊生于移动互联网时代，而且在当时的天时地利人和方面，米聊有很好的机会和很大的优势，但在产品方面和传统IM并无太大差别的产品功能，所以从一开始就决定了早晚会被更加具备创新和突破的IM干翻。
点对点通讯、以及后来推出的米吧……这些功能都能在QQ上找到，那为什么用户还要舍弃人际关系抛弃QQ来使用米聊呢？
2、
微信从一开始就凸显出与QQ的差异化，从2.0版本开始，微信除了点对点通讯之外便开始了新的突破，比如查找附近的人、摇一摇等是个转折点；之后的朋友圈、公众平台、微信红包等等突破已经和米聊彻底拉开了距离。
从现在的情况来看，仅仅就产品来说，微信的每一个变化其实都是有着深切的用户需求的，而之前米聊虽然也有一些突破，但和微信相比，太过轻微和渺小。
3、
其他知友提到的导入QQ联系人关系，这确实是个优势，但我觉得这并不是微信能干掉米聊的最主要优势。
当时米聊依托手机通讯录而迅速崛起，在社交关系链方面，手机通讯录的社交属性并不弱于QQ。
公司原因：
1、
小米对米聊其实并未重视，最起码和小米手机相比，米聊的的权重自然是排后的。
但腾讯不同，腾讯在看到微信的成长趋势之后，对微信的资源补给和扶持力度，恐怕是其他IM公司望尘莫及的。而微信崛起的那几年，也正是小米手机火起来的时间段，这个时候米聊只能退居二线。
雷军在后来的专访中也似乎承认了这点。
2、
腾讯公司以社交起家，社交是腾讯的基因和命脉。
另，十余年的QQ社交经验，腾讯更明白市场与用户需求，这点米聊稍弱一点。
这方面，简单的来说就是腾讯做社交产品是接地气的，而米聊团队则清冷了一些。虽然微信由产品狂人张小龙执掌，但米聊当时的负责人也履历光鲜，但遗憾的是后者的光鲜履历似乎只体现在小米公司品牌上，并未体现在米聊的产品上。
3、
腾讯公司对微信的成长与扶持，除了给予相当的支持外，在市场营销、品牌传播等方面也是下了很大功夫的（我有幸当时曾参与过微信的几个版本的市场推广与营销工作），反观米聊，这方面工作几乎为零。
人为因素：
1、
米聊产品及开发团队不接地气，这个团队给我的感觉只会做产品而已，但是微信却是“做用户与市场需要的产品”；
2、米聊的市场运营也平平谈谈。
有段时间米聊推出了公众号服务（当时叫VIP号吧？），我当时实名申请，暂且不说申请过程中的程序繁琐和流程漫长，在申请成功之后的官方运营要求，就让人难以忍受。比如官方要求每个帐号每个礼拜至少要推送有3天时间推送……（微信公众帐号可没要求运营者必须多少天推送一次），在和官方工作人员交流的过程中，态度强硬，最后我直接让他们将帐号收回去了。
总的来说，米聊没火起来是有必然原因的，相对微信而言，米聊落败微信太正常了。
从今天的情况来看微信的成长，单方面将微信的成功归功于可以通过QQ导入好友关系也是片面的。
我认为一款产品的成功，是产品、市场、人力、财力、资源等等综合因素结合的成果，而米聊在这多方面的表现都并不及格。
多玩YY、陌陌等也是IM类的产品，但人家能成功米聊失败，这里面自然有米聊自己的问题。
------------------------
随意作答，看观随意。
小米米聊是看准了社交这条赛道并且提前起步，但却在路上遭受重型卡车碾压。
米聊的失败，固然有自己运营、推广上的原因。但有些事情，似乎早就是注定的。
2010年，那时的小米只不过拥有数十万的米粉群体支持，而同年的腾讯QQ同时在线用户已突破1亿。当腾讯开放QQ好友的关系链导入微信时，米聊就已经输了。
相比于电商、搜索引擎的可替代性强，用户的社交关系显得牢不可破。用户选择这个社交软件，不仅仅是它多好用，而是我要联系的人都在里面。
这使得在社交这个大盘子上，小米、中国移动、百度、网易、阿里、头条等大厂轮番上阵，都没撼动腾讯的地位。
当然，腾讯也不是万能的，就好像重金投入的腾讯微博也没干掉借新浪博客起家的新浪微博。
我很早之前下载过米聊，但是不久就删了，原因很简单：身边就没有人用这个软件，全都清一色的用QQ，作为一个社交软件，连最基础的朋友之间的社交能力都发挥不出来，那对用户来说有什么价值？
而那时社交软件还是QQ的天下。甚至后面的微信最终能奠定今天的地位，QQ在其中有着很重要的作用，基本上早期的微信都是靠QQ给引流的。
我现在的微信注册的时候用的还是QQ账号，微信好友在当时也是可以通过QQ关联的，后面取消了。就连早期的朋友圈也会有一个功能就是同时发布到QQ空间，回看我早期的朋友圈，基本上QQ空间都能找到一条一模一样的。
只不过那时社交软件的王是QQ，我怎么也想不到若干年之后最重要社交软件居然变成微信。
而那时候的米聊有啥？缺乏用户基础，对于很多人来说难以发挥其社交价值，是根本没有办法和那时的QQ以及后来的微信相提并论的，再说后续米聊并没有在其原有的框架内做出大的修改，在如今还能崛起的社交软件中或多或少都是找到创新点的，而米聊在传统道路既没有优势，但却仍沿用传统的路径，缺乏创新，所以米聊是注定失败的。
硬扛死撑并不能等来春天…
米聊是一个预装必卸的APP，米聊硬扛了10年，这10年行业发生了巨变，美团滴滴头条知乎等公司都是在这十年里成长起来的。所以我没搞明白米聊硬扛10年的意义何在？
这10年的服务器成本、带宽成本、员工工资（2021还在开发更新…）乱七八糟，也不少钱吧？这些钱干点啥不香？非得死磕微信…
同为IM，为数不多能做出差异化的也就是陌陌了，而在这期间米聊是有很多机会的。比如你可以布局商务IM，把领域再细分一些，看看疫情期间起来的「钉钉」，你米聊在干什么？
米聊背靠小米，有强大的办公组件WPS，有金山的云服务，有数亿的小米手机用户（MIUI），结果呢？一个资源都没利用上，也是没谁了…
说到底，还是心太野，想成为微信的替代品。
看看最新版的米聊都在搞什么骚操作：
明知道干不过微信QQ，也不可能成为第二个微博，既缺乏稳固的原始用户，又啥都想做，不早做差异化转型，你不凉，谁凉？
米聊或许悲壮，但并不值得同情。
这根本不是米聊“复出”，而是米聊死后被后辈拖出来蹭热度。
换个说法，这是小米的借势营销而已。如果对外说小米推出了一款新应用——结果：无人理会。
如果说小米米聊复活——结果：成为热点。
而在中国版Clubhouse的道路上上，远不止小米一人，各大小巨头都不会放过这一个“可能”爆发的新车道。 反正失败了对它们而言也没什么损失，但要是错过了就亏大了。
阿里巴巴——MeetClub
网易——侃侃
映客——对话吧
小米上市前一直号称自己是互联网企业，但却未曾推出过一款现象级ＡＰＰ。所以这次模仿大火的Clubhouse也不足为奇，毕竟这并不是第一次，也不会是最后一次。
例如已经凉透了的朕惊视频——以“播单”形式聚合新视频 ：
凉得差不多的小米直播——当年小米无人机的发布平台：
从出生到挂掉都没什么人知道的小米有乐等：
微信全是QQ引流过去的用户，米聊根本不可能竞争过微信，米聊的问题在于没有及时改弦更张，做细分社交领域，而是轻易的撤退不干了。
本文由作者“大白菜”分享，有较多修订和改动。注意：本系列是给IM初学者的文章，IM老油条们还望海涵，勿喷！
接上两篇《IM系统设计篇》、《编码实践篇（单聊功能）》，本篇主要讲解的是通过实战编码实现IM的群聊功能，内容涉及群聊技术实现原理、编码实践等知识。
建议你在阅读本文之前，务必先读本系列的前两篇《IM系统设计篇》、《编码实践篇（单聊功能）》，在着重理解IM系统的理论设计思路之后，再来阅读实战代码则效果更好。
最后，在开始本文之前，请您务必提前了解Netty的相关基础知识，可从本系列首篇《IM系统设计篇》中的“知识准备”一章开始。
本文是系列文章的第3篇，以下是系列目录：
- 《基于Netty，从零开发IM(一)：IM系统设计篇》
- 《基于Netty，从零开发IM(二)：编码实践篇（单聊功能）》
- 《基于Netty，从零开发IM(三)：编码实践篇（群聊功能）》（* 本文）
- 《基于Netty，从零开发IM(四)：编码实践篇（系统优化）》（稍后发布.. ）
在上篇《编码实践篇（单聊功能）》中，我们主要实现了IM的单聊功能，本节主要是实现IM群聊功能。
本篇涉及的群聊核心功能，大致如下所示：
- 1）登录：每个客户端连接服务端的时候，都需要输入自己的账号信息，以便和连接通道进行绑定；
- 2）创建群组：输入群组 ID 和群组名称进行创建群组。需要先根据群组 ID 进行校验，判断是否已经存在了；
- 3）查看群组：查看目前已经创建的群组列表；
- 4）加入群组：主要参数是群组 ID 和用户 ID，用户 ID 只需从 Channel 的绑定属性里面获取即。主要是判断群组 ID 是否存在，如果存在还需要判断该用户 ID 是否已经在群组里面了；
- 5）退出群组：主要是判断群组 ID 是否存在，如果存在则删除相应的关系；
- 6）查看组成员：根据群组 ID 去查询对应的成员列表；
- 7）群发消息：选择某个群进行消息发送，该群下的成员都能收到信息。主要判断群组 ID 是否存在，如果存在再去获取其对应的成员列表。
其实群聊和单聊，整体上原理是一样的，只是做了一下细节上的升级。
在首篇《IM系统设计篇》的“6、IM群聊思路设计”设计部分也做了详细的说明了。
群聊的大概流程就是：根据群组 ID 查找到所有的成员集合，然后再遍历找到每个成员对应的连接通道。
具体的群聊架构思路如下图：
如上图所示，群聊通讯流程技术原理如下：
- 1）群聊和单聊整体上的思路一致：需要保存每个用户和通道的对应关系，方便后期通过用户 ID 去查找到对应的通道，再跟进通道推送消息；
- 2）群聊把消息发送给群员的原理：其实很简单，服务端再保存另外一份映射关系，那就是聊天室和成员的映射关系。发送消息时，首先根据聊天室 ID 找到对应的所有成员，然后再跟进各个成员的 ID 去查找到对应的通道，最后由每个通道进行消息的发送；
- 3）群成员加入某个群聊聊的时候：往映射表新增一条记录，如果成员退群的时候则删除对应的映射记录。
补充说明：因为本系列文章主要目的是引导IM初学者在基于Netty的情况下，如何一步一步从零写出IM的逻辑和思维能力，因而为了简化编码实现，本篇中编码实现的客户端都是基于控制台实现的（希望不要被嫌弃），因为理解技术的本质显然比炫酷的外在表现形式更为重要。
用户登录效果图：
群组操作效果图：
服务端映射关系的管理，分别是：
- 1）登录信息（用户 ID 和通道）；
- 2）群组信息（群组 ID 和群组成员关系）。
主要通过两个 Map 去维护，具体如下：
public class ServerChatGroupHandler extends ChannelInboundHandlerAdapter {
private static Map<Integer, Channel> map=new HashMap<Integer, Channel>();
private static Map<Integer, Group> groups=new HashMap<Integer, Group>();
}
//组和成员列表关系实体
@Data
public class Group implements Serializable {
private String groupName;
private List<GroupMember> members=new ArrayList<GroupMember>();
}
//成员和连接通道的关系实体
public class GroupMember implements Serializable {
private Integer userid;
private Channel channel;
}
我们准备好相应的实体，以及实体和指令的映射关系，具体如下所示：
private static Map<Byte, Class<? extends BaseBean>> map=new HashMap<Byte,Class<? extends BaseBean>>();
static{
//登录的请求和响应实体
map.put(1, LoginReqBean.class);
map.put(2, LoginResBean.class);
//创建群组的请求和响应实体
map.put(3, GroupCreateReqBean.class);
map.put(4, GroupCreateResBean.class);
//查看群组的请求和响应实体
map.put(5, GroupListReqBean.class);
map.put(6, GroupListResBean.class);
//加入群组的请求和响应实体
map.put(7,GroupAddReqBean.class);
map.put(8,GroupAddResBean.class);
//退出群组的请求和响应实体
map.put(9,GroupQuitReqBean.class);
map.put(10,GroupQuitResBean.class);
//查看成员列表的请求和响应实体
map.put(11,GroupMemberReqBean.class);
map.put(12,GroupMemberResBean.class);
//发送响应的实体（发送消息、发送响应、接受消息）
map.put(13,GroupSendMsgReqBean.class);
map.put(14,GroupSendMsgResBean.class);
map.put(15,GroupRecMsgBean.class);
}
通过下面这张图，能看的更清晰一些：
IM群聊功能的实现，我们需要两个两个业务 Handler：
- 1）分别是客户端（ClientChatGroupHandler）；
- 2）服务端（ServerChatGroupHandler）。
客户端 Handler，主要是通过判断实体类型来做不同的业务操作，当然也可以使用 SimpleChannelInboundHandler 去进行 Handler 拆分。
public class ClientChatGroupHandler extends ChannelInboundHandlerAdapter {
@Override
public void channelActive(ChannelHandlerContext ctx) throws Exception {
//在链接就绪时登录
login(ctx.channel());
}
//主要是“接受服务端”的响应信息
@Override
public void channelRead(ChannelHandlerContext ctx, Object msg) throws Exception {
if(msg instanceof LoginResBean){
LoginResBean res=(LoginResBean) msg;
System.out.println("登录响应："+res.getMsg());
if(res.getStatus()==0){
//登录成功
//1.给通道绑定身份
ctx.channel().attr(AttributeKey.valueOf("userid")).set(res.getUserid());
//2.显示操作类型【请看下面】
deal(ctx.channel());
}else{
//登录失败，继续登录
login(ctx.channel());
}
}else if(msg instanceof GroupCreateResBean){
GroupCreateResBean res=(GroupCreateResBean)msg;
System.out.println("创建响应群组："+res.getMsg());
}else if(msg instanceofGroupListResBean){
GroupListResBean res=(GroupListResBean)msg;
System.out.println("查看群组列表："+res.getLists());
}elseif(msg instanceofGroupAddResBean){
GroupAddResBean res=(GroupAddResBean)msg;
System.out.println("加入群组响应："+res.getMsg());
}elseif(msg instanceof GroupQuitResBean){
GroupQuitResBean res=(GroupQuitResBean)msg;
System.out.println("退群群组响应："+res.getMsg());
}else if(msg instanceof GroupMemberResBean){
GroupMemberResBean res=(GroupMemberResBean)msg;
if(res.getCode()==1){
System.out.println("查看成员列表："+res.getMsg());
}else{
System.out.println("查看成员列表："+res.getLists());
}
}else if(msg instanceof GroupSendMsgResBean){
GroupSendMsgResBean res=(GroupSendMsgResBean)msg;
System.out.println("群发消息响应："+res.getMsg());
}else if(msg instanceof GroupRecMsgBean){
GroupRecMsgBean res=(GroupRecMsgBean)msg;
System.out.println("收到消息fromuserid="+
res.getFromuserid()+
",msg="+res.getMsg());
}
}
}
通过子线程循环向输出控制台输出操作类型的方法，以下方法目前都是空方法，下面将详细讲解。
private void deal(final Channel channel){
final Scanner scanner=new Scanner(http://System.in);
new Thread(new Runnable() {
public void run() {
while(true){
System.out.println("请选择类型：0创建群组，1查看群组，2加入群组，3退出群组，4查看群成员，5群发消息");
int type=scanner.nextInt();
switch(type){
case 0:
createGroup(scanner,channel);
break;
case 1:
listGroup(scanner,channel);
break;
case 2:
addGroup(scanner,channel);
break;
case 3:
quitGroup(scanner,channel);
break;
case 4:
listMembers(scanner,channel);
break;
case 5:
sendMsgToGroup(scanner,channel);
break;
default:
System.out.println("输入的类型不存在!");
}
}
}
}).start();
}
服务端 Handler，主要是通过判断实体类型来做不同的业务操作，当然也可以使用 SimpleChannelInboundHandler 去进行 Handler 拆分。
以下方法目前都是空方法，下面将详细讲解。
public class ServerChatGroupHandler extends ChannelInboundHandlerAdapter {
private static Map<Integer, Channel> map=new HashMap<Integer, Channel>();
private static Map<Integer, Group> groups=new HashMap<Integer, Group>();
@Override
public void channelRead(ChannelHandlerContext ctx, Object msg) throws Exception {
if(msg instanceof LoginReqBean) {
//登录
login((LoginReqBean) msg, ctx.channel());
}else if(msg instanceof GroupCreateReqBean){
//创建群组
createGroup((GroupCreateReqBean)msg,ctx.channel());
}else if(msg instanceof GroupListReqBean){
//查看群组列表
listGroup((GroupListReqBean)msg,ctx.channel());
}else if(msg instanceof GroupAddReqBean){
//加入群组
addGroup((GroupAddReqBean)msg,ctx.channel());
}else if(msg instanceof GroupQuitReqBean){
//退出群组
quitGroup((GroupQuitReqBean)msg,ctx.channel());
}else if(msg instanceof GroupMemberReqBean){
//查看成员列表
listMember((GroupMemberReqBean)msg,ctx.channel());
}else if(msg instanceof GroupSendMsgReqBean){
//消息发送
sendMsg((GroupSendMsgReqBean) msg,ctx.channel());
}
}
}
客户端请求：
private void createGroup(Scanner scanner,Channel channel){
System.out.println("请输入群组ID");
Integer groupId=scanner.nextInt();
System.out.println("请输入群组名称");
String groupName=scanner.next();
GroupCreateReqBean bean=new GroupCreateReqBean();
bean.setGroupId(groupId);
bean.setGroupName(groupName);
channel.writeAndFlush(bean);
}
服务端处理：
public class ServerChatGroupHandler extends ChannelInboundHandlerAdapter {
private static Map<Integer, Channel> map=new HashMap<Integer, Channel>();
private static Map<Integer, Group> groups=new HashMap<Integer, Group>();
private void createGroup(GroupCreateReqBean bean,Channel channel){
//定义一个响应实体
GroupCreateResBean res=new GroupCreateResBean();
//查询groups是否已经存在
Group group=groups.get(bean.getGroupId());
//判断是否已经存在
if(group==null){
//定义群组实体
Group g=new Group();
//定义一个集合，专门存储成员
List<GroupMember> members=new ArrayList<GroupMember>();
//属性赋值
g.setGroupName(bean.getGroupName());
g.setMembers(members);
//添加到Map里面
groups.put(bean.getGroupId(),g);
//响应信息
res.setCode(0);
res.setMsg("创建群组成功");
}else{
res.setCode(1);
res.setMsg("该群组已经存在!");
}
channel.writeAndFlush(res);
}
}
客户端请求：
private void listGroup(Scanner scanner,Channel channel){
GroupListReqBean bean=new GroupListReqBean();
bean.setType("list");
channel.writeAndFlush(bean);
}
服务端处理：
public class ServerChatGroupHandler extends ChannelInboundHandlerAdapter {
private static Map<Integer, Channel> map=new HashMap<Integer, Channel>();
private static Map<Integer, Group> groups=new HashMap<Integer, Group>();
private void listGroup(GroupListReqBean bean,Channel channel){
if("list".equals(bean.getType())){
//定义一个响应实体
GroupListResBean res=new GroupListResBean();
//定义一个集合
List<GroupInfo> lists=new ArrayList<GroupInfo>();
//变量groups Map集合
for(Map.Entry<Integer, Group> entry : groups.entrySet()){
Integer mapKey = entry.getKey();
Group mapValue = entry.getValue();
GroupInfo gi=new GroupInfo();
gi.setGroupId(mapKey);
gi.setGroupName(mapValue.getGroupName());
lists.add(gi);
}
//把集合添加到响应实体里面
res.setLists(lists);
//开始写到客户端
channel.writeAndFlush(res);
}
}
}
客户端请求：
private void addGroup(Scanner scanner,Channel channel){
System.out.println("请输入加入的群组ID");
int groupId=scanner.nextInt();
Integer userId=(Integer) channel.attr(AttributeKey.valueOf("userid")).get();
GroupAddReqBean bean=new GroupAddReqBean();
bean.setUserId(userId);
bean.setGroupId(groupId);
channel.writeAndFlush(bean);
}
服务端处理：
public class ServerChatGroupHandler extends ChannelInboundHandlerAdapter {
private static Map<Integer, Channel> map=new HashMap<Integer, Channel>();
private static Map<Integer, Group> groups=new HashMap<Integer, Group>();
private void addGroup(GroupAddReqBean bean,Channel channel){
GroupAddResBean res=new GroupAddResBean();
//1.根据“群组ID”获取对应的“组信息”
Group group=groups.get(bean.getGroupId());
//2.“群组”不存在
if(group==null){
res.setCode(1);
res.setMsg("groupId="+bean.getGroupId()+",不存在!");
channel.writeAndFlush(res);
return;
}
//3.“群组”存在，则获取其底下的“成员集合”
List<GroupMember> members=group.getMembers();
boolean flag=false;
//4.遍历集合，判断“用户”是否已经存在了
for(GroupMember gm:members){
if(gm.getUserid()==bean.getUserId()){
flag=true;
break;
}
}
if(flag){
res.setCode(1);
res.setMsg("已经在群组里面,无法再次加入!");
}else{
//1.用户信息
GroupMember gm=new GroupMember();
gm.setUserid(bean.getUserId());
gm.setChannel(channel);
//2.添加到集合里面
members.add(gm);
//3.给“群组”重新赋值
group.setMembers(members);
res.setCode(0);
res.setMsg("加入群组成功");
}
channel.writeAndFlush(res);
}
}
客户端请求：
private void quitGroup(Scanner scanner,Channel channel){
System.out.println("请输入退出的群组ID");
int groupId=scanner.nextInt();
Integer userId=(Integer) channel.attr(AttributeKey.valueOf("userid")).get();
GroupQuitReqBean bean=new GroupQuitReqBean();
bean.setUserId(userId);
bean.setGroupId(groupId);
channel.writeAndFlush(bean);
}
服务端处理：
public class ServerChatGroupHandler extends ChannelInboundHandlerAdapter {
private static Map<Integer, Channel> map=new HashMap<Integer, Channel>();
private static Map<Integer, Group> groups=new HashMap<Integer, Group>();
private void quitGroup(GroupQuitReqBean bean,Channel channel){
GroupQuitResBean res=new GroupQuitResBean();
//1.根据“群组ID”获取对应的“组信息”
Group group=groups.get(bean.getGroupId());
if(group==null){
//2.群组不存在
res.setCode(1);
res.setMsg("groupId="+bean.getGroupId()+",不存在!");
channel.writeAndFlush(res);
return;
}
//3.群组存在，则获取其底下“成员集合”
List<GroupMember> members=group.getMembers();
//4.遍历集合，找到“当前用户”在集合的序号
int index=-1;
for(inti=0;i<members.size();i++){
if(members.get(i).getUserid()==bean.getUserId()){
index=i;
break;
}
}
//5.如果序号等于-1，则表示“当前用户”不存在集合里面
if(index==-1){
res.setCode(1);
res.setMsg("userid="+bean.getUserId()+",不存在该群组里面!");
channel.writeAndFlush(res);
return;
}
//6.从集合里面删除“当前用户”
members.remove(index);
//7.给“群组”的“成员列表”重新赋值
group.setMembers(members);
res.setCode(0);
res.setMsg("退出群组成功");
channel.writeAndFlush(res);
}
}
客户端请求：
private void listMembers(Scanner scanner,Channel channel){
System.out.println("请输入群组ID：");
int groupId=scanner.nextInt();
GroupMemberReqBean bean=new GroupMemberReqBean();
bean.setGroupId(groupId);
channel.writeAndFlush(bean);
}
服务端处理：
public class ServerChatGroupHandler extends ChannelInboundHandlerAdapter {
private static Map<Integer, Channel> map=new HashMap<Integer, Channel>();
private static Map<Integer, Group> groups=new HashMap<Integer, Group>();
private void listMember(GroupMemberReqBean bean,Channel channel){
GroupMemberResBean res=new GroupMemberResBean();
List<Integer> lists=new ArrayList<Integer>();
//1.根据“群组ID”获取对应的“组信息”
Group group=groups.get(bean.getGroupId());
if(group==null){
//2.查询的群组不存在
res.setCode(1);
res.setMsg("groupId="+bean.getGroupId()+",不存在!");
channel.writeAndFlush(res);
}else{
//3.群组存在，则变量其底层的成员
for(Map.Entry<Integer, Group> entry : groups.entrySet()){
Group g = entry.getValue();
List<GroupMember> members=g.getMembers();
for(GroupMember gm:members){
lists.add(gm.getUserid());
}
}
res.setCode(0);
res.setMsg("查询成功");
res.setLists(lists);
channel.writeAndFlush(res);
}
}
}
客户端请求：
private void sendMsgToGroup(Scanner scanner,Channel channel){
System.out.println("请输入群组ID：");
int groupId=scanner.nextInt();
System.out.println("请输入发送消息内容：");
String msg=scanner.next();
Integer userId=(Integer) channel.attr(AttributeKey.valueOf("userid")).get();
GroupSendMsgReqBean bean=new GroupSendMsgReqBean();
bean.setFromuserid(userId);
bean.setTogroupid(groupId);
bean.setMsg(msg);
channel.writeAndFlush(bean);
}
服务端处理：
public class ServerChatGroupHandler extends ChannelInboundHandlerAdapter {
private static Map<Integer, Channel> map=new HashMap<Integer, Channel>();
private static Map<Integer, Group> groups=new HashMap<Integer, Group>();
privatevoidsendMsg(GroupSendMsgReqBean bean,Channel channel){
GroupSendMsgResBean res=new GroupSendMsgResBean();
//1.根据“群组ID”获取对应的“组信息”
Group group=groups.get(bean.getTogroupid());
//2.给“发送人”响应，通知其发送的消息是否成功
if(group==null){
res.setCode(1);
res.setMsg("groupId="+bean.getTogroupid()+",不存在!");
channel.writeAndFlush(res);
return;
}else{
res.setCode(0);
res.setMsg("群发消息成功");
channel.writeAndFlush(res);
}
//3.根据“组”下面的“成员”，变量并且逐个推送消息
List<GroupMember> members=group.getMembers();
for(GroupMember gm:members){
GroupRecMsgBean rec=new GroupRecMsgBean();
rec.setFromuserid(bean.getFromuserid());
rec.setMsg(bean.getMsg());
gm.getChannel().writeAndFlush(rec);
}
}
}
本篇中涉及的功能点稍微有点多，主要是实现了群聊的几个核心功能，分别是：创建群组、查看群组列表、加入群组、退出群组、查看成员列表、群发消息。
这些功能经过拆解，看起来就不是那么复杂了，希望大家都可以亲自动手实现一遍，加深理解，提高学习效果。
实际上，真正的产品级IM中，群聊涉及的技术细节是非常多的，有兴趣可以详读下面这几篇：
- IM群聊消息如此复杂，如何保证不丢不重？
- 移动端IM中大规模群消息的推送如何保证效率、实时性？
- 关于IM即时通讯群聊消息的乱序问题讨论
- IM群聊消息究竟是存1份(即扩散读)还是存多份(即扩散写)？
- 一套高可用、易伸缩、高并发的IM群聊、单聊架构方案设计实践
- 网易云信技术分享：IM中的万人群聊技术方案实践总结
- 阿里电商IM消息平台，在群聊、直播场景下的技术实践
- 企业微信的IM架构设计揭秘：消息模型、万人群、已读回执、消息撤回等
- 融云IM技术分享：万人群聊消息投递方案的思考和实践
[1] 手把手教你用Netty实现心跳机制、断线重连机制
[2] 自已开发IM很难？手把手教你撸一个Andriod版IM
[3] 基于Netty，从零开发一个IM服务端
[4] 拿起键盘就是干，教你徒手开发一套分布式IM系统
[5] 正确理解IM长连接、心跳及重连机制，并动手实现
[6] 手把手教你用Go快速搭建高性能、可扩展的IM系统
[7] 手把手教你用WebSocket打造Web端IM聊天
[8] 万字长文，手把手教你用Netty打造IM聊天
[9] 基于Netty实现一套分布式IM系统
[10] 基于Netty，搭建高性能IM集群（含技术思路+源码）
[11] SpringBoot集成开源IM框架MobileIMSDK，实现即时通讯IM聊天功能
学习交流：
- 移动端IM开发入门文章：《新手入门一篇就够：从零开发移动端IM》
- 开源IM框架源码：https://github.com/JackJiang2011/MobileIMSDK（备用地址点此）
（本文已同步发布于：http://www.52im.net/thread-3981-1-1.html）
可能他们不喜欢亚洲人 或者你的脸不在他们的点上 很正常 或者你的英语很蹩脚
近日，小编九哥更新miui系统后发现，桌面最后一屏多了一个米聊图标，当时我就震惊了，这货居然还活着！顺手点击图标登陆账号，简单的翻了翻，发现也没什么可玩的，仅有的几个联系人都不在线，发了留言几天也不见回复，附件的人也搜不到几个。不知道这个时候小米还在借miui强推玩意儿干嘛，难道还想翻盘不成？
2010年雷军率先模仿国外即时通讯软件，推出了国内第一款基于手机通讯录强联系SNS社区的跨手机平台即时通讯软件，取名为米聊，先后发布了安卓版、iOS版和Symbian版。当时雷军判断国内最大的竞争对手只有腾讯一家，当雷军得知腾讯的QQ邮箱团队正在研发类似的产品时，当即判断米聊最多只有三个月的时间优势了，于是米聊团队夜以继日的开发产品、优化服务、宣传推广。然而三个月后腾讯微信横空出世，所有QQ用户均可凭原有QQ账户登录微信，腾讯给微信强势导入大量用户为微信打败米聊奠定了基础。
然而，腾讯QQ用户的导入并不是米聊失败的唯一原因，微信后来推出的“附近的人”、“摇一摇”和“漂流瓶”、“朋友圈”等等杀手锏才是微信迅速爆红而米聊节节溃败的原因。一款app如果不能很好的解决用户的需求，导入再多的用户也是徒劳，比如说腾讯微博再怎么导入QQ用户也竞争不过新浪微博，腾讯SOSO也还不是败给了百度。
有的人还把米聊的失败归结于雷军给它取的名字，米聊听起来就像只有小米手机专用的聊天app似的，事实上有很大一部分网友也是这样认为的，这也可以算作米聊失败的原因之一吧，但不是最主要的原因，主要原因还是缺少杀手级应用。
小米作为一个初创企业，一开始雷军就提出了小米的三驾马车即MIUI软件、小米手机硬件和米聊等互联网服务，那时候的小米还不够成功，还有很多事情需要做，精力更多的还在研发MIUI软件和小米手机，所以在米聊的研发上缺乏创新。
面对微信这样强大的对手，米聊没有翻盘的机会，因为人们不需要第二个“微信”，小米你若有时间和精力，请把手机的产能提上去吧，米粉的热情都要被你玩抢购透支了。
原文地址：曾经被微信打得溃不成军的米聊现在活得还好么 _ 九哥9SiR
文/九哥，禁止未经授权转载，如需转载，请登录快版权获取正版授权。
差友们好，前两天微信 10 周年公开课上，张小龙公布了微信的最新数据，并对未来做了一些展望（ 画饼 ）。
然后啪一下，很快噢，微信就推出了 8.0 版本，全新的表情特效让网友们玩开了花，好不热闹！
这边微信在烟花爆竹喜气洋洋，而另一边同样是 10 岁的米聊，却宣布即将关闭。
而很多网友表示在这个新闻之前，还不知道有这么个软件（ 很抱歉以这种方式认识你 ）。
米聊呢就是小米推出的一款即时通讯 App，可以发送消息语言聊天等等，当年和微信、飞信等一起争夺通讯市场，甚至在初期还一度领先过微信。
但最终为啥没打过微信，这事还得从 10 年前说起。
2010 年 10 月，一款叫 Kik messenger 的即时通讯 App 在国外推出，主推的跨运营商跨系统的免费聊天功能，让这款 App 不到半个月时间就吸引了 100 万用户。
由于当时的 QQ 并没有智能手机版本，小米嗅到了商机后于同年 12 月推出一款免费的即时通讯 App：米聊。在没有太大的竞争压力下，米聊用户涨的很快。
同样受到 Kik 启发的，还有腾讯，他们在 2011 年 1 月份也推出了一款即时通讯 App：微信，不过最初的微信也只有发文字消息和图片的功能。
在 2011 年 1 月，一个叫做 Talkbox 的软件推出了语音聊天功能。或许是借鉴了这个功能，米聊于 2011 年 4 月推出了对讲机功能，独特的语音对讲模式吸引了大量的新用户，并很快突破了 100 万。
没过多久，微信在 5 月份也推出了对讲功能。
米聊早期用户数▼
米聊对讲机功能和微信对讲功能对比▼
其实在最早期的时候，不管是用户数还是更新速度上，米聊都要稍微领先于微信。
但是自 2011 年 5 月份之后，腾讯开始在微信上发力，微信添加好友的方式新增了通讯录和 QQ 号，用户甚至可以在微信里直接回复 QQ 的消息。
要知道 QQ 当时的用户量级是十分庞大的，微信直接动用QQ的关系链来引流，可以说是踩在了巨人的肩膀上。
在推出了附近的人、摇一摇等陌生人社交功能之后，微信用户开始突飞猛进，2011 年底就已破亿。
而米聊这边虽然也在更新，用户也在持续增加，但毕竟不是每个人都有像 QQ 这样能在背后输送大量用户的老大哥啊，米聊就这样被微信彻底甩开了。
或许雷军自己也很清楚，如果腾讯进军早的话，米聊胜出的概率会大大减少。
所以自打微信推出并一度反超米聊后，小米公司的重心便逐渐脱离米聊，放在了小米手机和 MIUI 上。
2011 年 8 月 7 日，在小米手机 1 和 MIUI（ v1 ）发布前几天，雷军发了一条微博：“ 舍得，有舍才有得，小舍小得，大舍大得 ”。世超觉得大概意思吧，就是放弃了米聊，但是呢，小米手机和 MIUI 得到了发展和突破。
从小米手机的现在市场份额来看，当初的选择也许是正确的。
有差友就要问了，既然打不过微信了，为什么不早点关闭米聊呢？
你想啊，米聊虽然打不过微信，但是它背后还有几百万的论坛粉丝，还是有很多人一直在使用米聊，毕竟米聊也有一些微信没有的独特功能。
比如「 屏幕共享 」和「 远程协助 」这两个功能就挺不错的。
「 屏幕共享 」就是可以和别人分享当前的手机屏幕，用于演示教学等操作。
偶尔会遇到父母手机出问题的情况，这时就可以通过米聊的「 远程协助 」帮他们看看，而且该功能会强制打开视频让双方先确认下身份。
虽然功能很贴心，但不知什么原因，世超在测试远程协助的时候却卡得无法操作。。。
在微信里，世超经常被拉到一些莫名其妙的群聊就挺烦的。但是米聊可以关闭「 好友直接拉我进群 」，关闭后，需要经过自己的确认才会好友被拉进群聊。
此外家里如果有不识字的老人，米聊的语音播报可以把文字读出来。
最骚的，米聊的消息撤回功能没有时间限制！周三发的消息，周日还可以撤回。那这样的话，我寻思情侣分手后，会不会一句一句撤回之前的海誓山盟。。
虽然米聊上一些功能的确还不错，但是微信已经占据了绝对的优势，最后的结果也只是米聊用户放弃米聊，转向微信。
这么解释吧，如果把通讯软件比作人们沟通的语言，微信就相当于普及度很高的普通话，米聊呢就相当于某个地方的方言。
当你想用方言和周围人沟通，但发现他们都在说普通话，你也只能跟着说普通话了。
随着用户不断减少，直到官方认为米聊没有维护的必要了，便发布了关闭服务器的通知。
在米聊下架之前，很多网友为了收藏和纪念，特意去下载了米聊。
不过世超要提醒一下各位，由于米聊维护和管理力度不够，消息可随意撤回，现在有很多犯罪分子利用米聊来进行诈骗。
在应用市场米聊的评论区甚至可以看到很多受害者的评论。使用米聊时如果遇到陌生人主动搭话，一定要提高警惕。
其实除了小米，锤子、字节跳动等公司都尝试做过即时通讯 App，但最终都没有撼动微信的统治地位。
还记得当年的三英战吕布吗▼
接下来是否还会出现挑战微信的 App 呢？如果有的话，要成功也很难很难吧。。
昨日（2月19号），又有一位老朋友要正式与我们告别，那就是十年前小米推出的即时通讯APP——米聊。
其实早在一月前，小米就发出了通告，米聊将于2021年2月19日12点关停，然而尽管有所准备，但当这一天真的到来时，还是不免有些唏嘘。
米聊出现得比微信更早，是十年前社交APP领域无可争议的弄潮儿，并且凭借率先添加的语音聊天功能，一度受到用户热捧，在关停公告下，众多网友纷纷发文感叹“爷青结”。
米聊也在公告中表示，感谢每一位米聊用户在过去的支持与陪伴，对于此次米聊的停服给大家造成的不便，我们深表歉意，未来米聊团队也会努力为大家带来更多新的服务。
同时，请用户在停服前自行导出聊天记录及个人资料等信息，停服后将无法导出用户在米聊内的任何信息。
米聊退场了，我们也只能迎接这一场告别。
2010年10月，美国出现了一款名为Kik Messager的即时通讯APP，凭借免费短信聊天功能，Kik Messager只用了半个月时间，用户量就突破了100万，成为当时的明星APP。
看到机会的雷军迅速调兵遣将，并于同年12月，推出了类似的产品——米聊。
彼时，人们的主要联系方式还是电话和短信，市面上拥有大规模用户的即时通讯应用，几乎只有腾讯的QQ，但QQ却是PC时代的产物，移植到手机上，并不能很好的适应，这意味着里面有着广阔的市场空间。
雷军也曾公开谈到，米聊是继移动互联网风口，小米发现的第二个有千亿美金市场的机会，看看如今的微信，可见雷军的预见非常准确。
初生的米聊发展还算迅速，在不到半年的时间里，用户就超过了400万，然而雷军却仍旧惴惴不安，因为他担心腾讯的狙击。
遗憾的是，雷军的预感又一次应验了，只是在米聊推出的一个月后，在2011年1月21日，微信1.0测试版正式上线，或许在这时候，就已经注定了米聊的结局。
事实上，在米聊刚刚推出的时候，雷军就根据腾讯的应对，为米聊下了上、中、下三卦：
如果腾讯用QQ来迎战米聊，那是腾讯的战略失误，小米尚有一丝机会，因为QQ不太适应移动互联网的潮流；
如果腾讯没有出现失误，用了完全相同形态的产品迎战的话，小米必须抢先偷跑一年，才有50%的胜算。
如果腾讯在一年内拿出一模一样的产品，基于腾讯综合资源是小米的一万倍，那小米获胜的概率将是零。
结果大家也就知道了，不仅没有一年，只是一月后，腾讯就拿出了同样的产品，最后的结局同样也没有意外，微信完胜。
其实在微信刚推出时，发展十分缓慢，上线近半年，用户还没有100万，而此时米聊用户已经突破400万了，看上去米聊尚有一战之力，可惜这只是暂时的。
或许是因为腾讯也知道自己处于优势地位，因此显得十分从容，前期只是在测试而已，在上线半年，对微信有了全面了解后，发展的态势立马激进了起来。
不仅跟着米聊推出了语音聊天功能，还相继上线了查看附近的人、摇一摇、漂流瓶等功能，而最重要的是导入了QQ的关系链，一系列招式打出后，微信立马高歌猛进，只用了半年，到2011年底，微信的用户数就达到了5000万。
面对微信，米聊完全没有胜算，也有网友感叹道，“如果当时微信没有出现，现在即时通讯工具龙头或许会是米聊”，可惜世上没有如果。
如今微信月活用户超过12亿，成为腾讯最为牢固的流量基石，而米聊只能黯然退场，宣告死亡，如此鲜明的对比，实在让人唏嘘。
在雷军的畅想中，米聊能否成功，在于腾讯是否会给自己时间，而结局就是时间没有站在他这边。
但我们站在现在的角度往回看，就知道即使真的给了雷军一年的抢跑时间，米聊也几无胜算。
一方面，是小米没有那么多精力和能力来做好米聊。
当时的小米还算是一家创业公司，本身就没有多少人，即使全部用来做米聊，也无法和腾讯比拼迭代速度。
而互联网竞争，比拼的就是速度，看看现在的互联网企业，不是996，就是大小周，这就是在拼速度，想要把对手熬死，比如最近一年大火的社区团购，作为一条新兴赛道，工作强度巨大，连23岁的小姑娘都因此猝死，可以想象其中的残酷。
显然，小米在体量上无法和腾讯相比，就意味着它无法支撑米聊与微信长期竞争，这也注定了失败的结局。
另一个更重要的方面，就是小米当时没有流量入口。
2010年的小米还处于草创阶段，手机销量也不算高，所以米聊尽管有着新颖的光环加成，但也只能靠打广告和口口相传来获得用户，以至于用户数量增长速度只能说是差强人意。
但处于这种境况的米聊，竞争对手却是微信，这个拥有腾讯QQ数亿流量入口的竞品。
依靠腾讯QQ的导流，微信根本不愁用户，只是上线一年多，微信用户数就突破了1亿大关，而这时的米聊用户数量还在百万级徘徊，彼此已然不是一个量级了。
所以即使给米聊时间，其也是根本比不过微信的，不过这也不能责怪米聊，从一开始米聊就有先天不足的缺点，而微信却是天时地利人和皆备，这还怎么打呢！
话说回来，对于米聊的失败，雷军也早就认清楚了，在2012年5月，微信用户突破1亿后，雷军就曾公开承认米聊输了。
但让人想不到的是，米聊竟然死扛着坚持了十年，而且没有做出任何转变，还是要和微信一样做即时通讯应用。
十年时间，行业都已经发生了巨变，美团、滴滴、头条、知乎等巨头企业，都是在这十年里成长起来的，米聊本应该有非常多的机会转变的。
比如做陌生人社交的陌陌，还有近来崛起的企业服务钉钉，这些都是非常好的赛道，而这些年小米发展迅速，拥有了数亿手机用户，还有强大的办公组件WPS，已经拥有了巨大的资源，如果是这时的小米做米聊，和微信相比，谁胜谁负还未可知呢。
结果米聊一直没有做差异化转型，还是和微信死磕，最后落得关停的下场，只能说雷军也是头铁吧。
总之，互联网江湖来来去去，有的光芒万丈，就有更多的惨淡退场，米聊不是第一个，也不会是最后一个，其中的生死，看实力，更看天意。
作者：老罗
文章首发于微信公众号「非著名程序员」，欢迎大家关注。
2021 年 2 月 19 号一个历经十年的小米产品：「米聊」，正式停止服务，从此寿终正寝。
可是不到一周的时间，新米聊正式重新上线，同时定位为面向专业人士的语音聊天 App，对标的是：Clubhouse 。
没想到吧？千算万算，千想万想都没有想到雷布斯会下这一招棋吧？
①
事件回顾
我们理顺一下时间线哈。
2021 年 1 月 19 日，米聊 App 发布公告称，2021 年 2 月 1 日 12 点，米聊将停止账号注册、消息收发；2021 年 2 月 19 日 12 点，将停止米聊登录，并关闭服务器，届时及以后将无法登录和使用米聊。
而 Clubhouse 是在哪个时间点突然风靡全球的呢？
2 月 1 日，马斯克在 Clubhouse 直播，他谈到了 “移民火星的时间、比特币、创业” 等多个话题，吸引了至少 5000 人观看互动，房间的嘉宾还包括风投公司 A16Z 的联合创始人马克・安德森（Marc Andreessen）和天使投资人里拉姆・克里希南（Sriram Krishnan）等多位知名人士。
随后，Facebook 首席执行官马克・扎克伯格 (Mark Zuckerberg) 用 “Zuck23” 的用户名 Clubhouse 上开设了一个帐户，登录后接受了采访。
随即，从 2 月 2 日开始，Clubhouse 在国内受到追捧。
在一周前，也就是 2 月 20 号发布的「新米聊」。说明在原来的「米聊」正式停服之后，马上就发布了「新米聊」。
也就是说从 2 月 1 号 Clubhouse 火爆全网到 2 月 20 日推出「新米聊」，米聊团队用了不到 20 天的时间开发出了中国版的 Clubhouse 。米聊团队大概率这个春节都在加班加点的干活了。
毕竟雷布斯不想错过这个风口。
②
新版米聊
我们简单看看新版米聊吧。其实也没有什么特别好看的，因为目前曝光的情况来看就是一个翻版的 Clubhouse 。
米聊官方的信息已经更新：
新米聊的 App 简介也是：新「米聊」是一个面向行业人士的语音社交 App。
在新「米聊」，你可遇到各行大咖的分享会，还可以举手参与分享。你也可以创建你感兴趣的话题，拉上你的朋友或者开放让其他感兴趣的人进来，一起交流、一起碰撞想法。
跟 Clubhouse 如出一辙。
新米聊并未与原先的米聊账号打通，同时目前并未开放注册，而是出于小范围的邀请内测阶段。目前也是采用邀请制，只有受到邀请的人填写邀请码才可以注册使用。
③
雷布斯能抓住这个风口吗？
正值语音社交新秀 Clubhouse 在全球火爆之际。从新米聊的定位和注册方式来看，与 Clubhouse 如出一辙。曾是微信先驱和对手的米聊失败了，而作为 Clubhouse 的跟随者，新米聊能够抓住这次风口吗？
众所周知，雷军在曾经的采访当中提到过，他在 2010 年一下子遇到了两个千亿美金市场的风口，一个是互联网手机，一个是语音社交「米聊」。
当然了，雷军抓住了互联网手机的风口，但是米聊却败给了比他出发还晚的微信。
2010 年 11 月，成立第一年的小米就决定做米聊，并在 12 月正式推出了米聊 App。这款拥有对讲功能的 App，半年过去用户迅速超过 400 万，早期一度领先微信。不过 2011 年 1 月腾讯就迅速推出了微信，微信基于 QQ 的关系链可以说大发神威，完成了用户的迅速迁移，米聊丧失了时间差优势，并在后来迅速被微信赶超。
这次雷总能够抓住音频社交的风口呢？是否还会败给腾讯呢？
我相信如果这次音频社交的领域如果腾讯不参战的话，以米聊团队上次失败的经验，结合小米今非昔比，肯定能够在这个音频社交领域闯出一片天地。
上次米聊败给微信，不仅仅是败给了有用广大社交用户基础的腾讯，还败给了当时小米刚刚成立，并没有钱参战，工程资源也不到位。
根据小米最新的传记《一往无前》这本书上的爆料：当时小米公司成立不久，工程资源不够，米聊的稳定性不够好，容易掉线，丢语音，体验差。当拥有海量用户时，即时通信对稳定性的要求非常高，这是小米技术欠缺的，但是对做了多年即时通信的腾讯来讲优势巨大。
另外雷军说一家公司只能拥有一个核心战略资源，手机已经成功，所以，资源只能像手机倾斜，米聊只能战略收缩。
但是，现在的小米今非昔比，技术和产品能力经过十年磨砺已经成熟，而且现在也有钱有资源了。
以目前来讲，即使是腾讯参战音频社交领域，开发一款同类的 Clubhouse 和新米聊竞争，估计也会打的非常惨烈。
所以，我猜测，如果腾讯参战，估计他俩也得 55 开，如果腾讯不参战，米聊抓住这次机遇的几率非常大。
④
总结
其实，关于 Clubhouse 的这次风口，我感觉就目前来看，不是谁能不能抓住这次风口，而是这个风口的市场到底有多大，还是值得探讨的。
就目前来看， Clubhouse 就在 2 月初那个阶段非常火，随着使用时间过长，大家好奇心逐渐消磨之后，已经降温的很厉害了。类似 Clubhouse 这样的音频社交以我来看，注定是一个专业人士的市场，也就是规模不会太大。因为这是基于专业人士交流和知识分享的。
聊天室的知识传播，用户的仰望心态是会疲惫的，大多数用户都是不喜欢被说教的，更不喜欢学习，这注定是一个小众的产品。所以，这个市场我的判断是即使成功了，也就是日活千万级的市场，肯定不会日活过亿。
你们说呢？
特别推荐：最后，欢迎大家关注我的微信公众号：【非著名程序员】，这绝对是一个宝藏公众号，我每天都会分享一篇生财和赚钱的观点，首发于公众号，让大家每天「钱近」一小步。
让我们一起生财有术，生财有道。
2010年，刚刚成立的小米公司还没有开始造手机，他们造了一款聊天软件，叫米聊。如果你没有用过米聊，你可以看看你的微信，米聊和今天的微信非常像。或者应该反过来说，微信和曾经的米聊非常像，而我们今天用的微信，其实比米聊晚了3个月才发布第一版。
为什么最擅长做社交软件的腾讯居然比刚刚成立的小米更晚发布新的社交软件？
这恰恰是因为腾讯最擅长做社交软件，它觉得自己已经有QQ了，不再需要另一款和QQ很像的社交软件，即使新的社交软件有些不同，即使新的社交软件能实现按着屏幕发语音。
米聊发布后，获得了非常积极的市场反应。一种危机意识开始在腾讯内部蔓延，很多人觉得：“不行，我们一定要做。”但是，米聊已经有了先发优势，腾讯该怎么办？
于是，腾讯安排了三个团队同时做微信：QQ团队、成都的一个团队，以及在广州负责邮箱业务的张小龙团队。
所有人都很自然地认为，QQ团队是最应该把这件事做成的。但是，万一这个团队不行呢？那么，整个腾讯的未来就会输在这个“万一”上。
马化腾在后来的一次演讲中说：“坦白讲，微信这个产品如果不是出在腾讯，不是自己打自己，而是出在另外一个公司，我们可能现在根本就挡不住。回过头来看，生死关头其实就是一两个月。”
最后的结果，我们都知道了：张小龙团队赢了，不，应该说是腾讯赢了。这三个团队的基础成功率可能都不高，但是马化腾用三个团队一起做的方式增加了尝试次数，从而提高了腾讯的整体成功率。
所以，最厉害的不是张小龙，而是马化腾。张小龙是一匹千里马，而马化腾经营的是马场。这就是腾讯著名的“赛马机制”。
马化腾说：“我们当时很紧张，腾讯内部有三个团队同时在做，都叫微信，谁赢了就上谁的。最后，广州做邮箱出身的团队赢了，成都的团队很失望，就差一个月。”
如果腾讯没有成功，今天大家见面，可能就不是说“加个微信吧”，而是说“加个米聊吧”。
但是，你认真想一想，腾讯“赛马机制”的基本逻辑是什么？是“多生儿子，择优而立”。这和康乾盛世的逻辑是一模一样的。自“多生儿子，择优而立”成就了微信之后，腾讯又开启了一轮新的盛世。
不管是曾经的康乾盛世，还是今天的腾讯转型，其持续成功的背后，都有同一个赛马机制作为底层逻辑。 @泼猴在知乎
