开发往事：深度讲述2010到2015，微信一路风雨的背后

前言

微信作为当前国内移动端最成功的明星应用，一直被各界高度关注，作为即时通讯开发者同行，微信的成功，同样无时无刻不在被解读、研究，以期从中获得相应的启发和收获。

作为当初微信iOS客户端3名开发之一，本文作者将从技术人员的角度分享2010年到2015年这段时期内微信背后的故事。

第一章 创世纪

微信的成功，让我相信：没有什么是不可能的。

2010年后，广研的发展到了一个瓶颈期，邮箱的布局已经相当完善，阅读空间也已到了强弩之末，那年最大的兴奋莫过于邮箱漂流瓶，一个简单的功能，却让邮箱的活跃用户翻了一番。

团队要发展，但巧妇难为无米之炊，一时之间不知道可以做什么了。于是那段时间发生了一个不可思议的事情，团队第一次对未来的发展方向做了大的规划，规划很宏大，计划做一个产品矩阵，包括邮箱、阅读、存储、记事本等，基本上把团队几年之间尝试过的产品重新做了梳理，每一个都将是一个独立的门户，从一个产品内的四个功能变成四个产品。

而10年的移动互联网正处在爆发的前夜，团队当然对这个发展趋势早有布局，邮箱早在08年就开始布局移动端产品，从最初的wapmail到后来的塞班版客户端，手机开发团队在10年也逐渐成熟起来。

当时确定的四大产品方向，除了邮箱外，其余三个都没有移动端，但都做了规划。由于手机开发团队规模的限制，如果我没记错的话，当时只启动了一个新产品的开发－－记事本，而且只是在ios平台试错。当时手机开发团队大部分人都是做塞班系统的开发，而ios和android作为新生的智能手机平台，它的重要性不言而喻。但那个时候ios和android平台作为新平台开发者相当少，开发团队只能临时拼凑，ios团队是从公司其他部门转岗过来的两个做windows客户端的同事，android是从塞班团队抽出来一个同事招了两个实习生开始干起来的。

2010年10月，一个产品的发布在互联网行业一石激起千层浪：kik messenger，这个应用有多火？它直接导致2011年成千上万的类kik应用被研发出来，这其中就包括后来大红大紫的微信、米聊、line和kacao。

kik messenger的火爆源于它的极致简单跨平台，它是为移动而生的应用，几乎不花任何力气就在很短的时间基于手机通讯录建立起自己的关系链，这对于很多web2.0时代的sns应用来说，是不可能做到的。很短时间内，它就以席卷一切的气势开始革命，首当其冲的是各国的运营商们，这个跨平台跨国界的手机通讯工具，它可以在不同的手机终端实现文本图片的消息沟通，秒杀短信和彩信体验，它的体验之极致，甚至让当时的手机巨头－－黑莓－－在自己的手机平台封杀它。

在kik甫一出现之际，小龙就预见它的火爆之势。小龙当时给pony发了一封邮件谈这个事情，并申请广研团队做一个类似的应用出来。而pony也极为赞许，并为这个应用起了一个名字－－微信。

当时做了一个多月的记事本立即停止，开始投入微信的开发中，很多代码直接复用过来，目标只有一个：快。

就这样，十个人的微信团队又一次在没有任何经验的情况启动了一个试错的项目，这次是三个平台（ios、android、塞班）同时进行。

而据说当时公司还有其他团队也在同时做类似的事情，且团队要强大的多，人力丰富有经验。但是，广研的小团队文化，为了取悦自己的巨大信念，使得广研微信团队能够在几个团队中脱颖而出，第一个完成了产品开发，只用了不到四个月时间，在2011年1月21号于ios平台首先发布了它的1.0版本。

在11年初的春节期间，当pony第一次使用微信并给出“体验很赞”的评价时，微信团队的信心达到了前所未有的高度。

但，此时，广研的其他同事却并不看好这个体验简单到有些简陋的手机应用。

第二章 冲出重围

微信的成功，除了团队的努力，时机的把握也很重要。

11年2月，新年伊始。上一年年底的兴奋似乎已经逝去，微信在经过一个春节的讨论之后，尝鲜的人开始散去，只有很少的同事还在用着这个应用，因为那个时候有ios和android智能手机的同事还很少。微信并没有像kik那样在很短的时间积聚大量的用户。

当时大家普遍不看好这个简单的应用。理由大致是：功能太简单了；qq会杀死所有的类kik应用－－它只要做一个手机客户端。公司当时正在忙活着微博大战，虽然有几个团队同时在做类kik应用，但公司内对这些应用的关注并不高。

但是公司的高层对这个应用还是寄予重望的，开年第二天，tony亲自过来南方通信大厦给微信团队打气。而且，我们也能明显感觉到小龙已经把注意力完全转移到这款手机应用上面。

2月底，harvey突然找到我，直接了当的问我：要不要过去微信做客户端？然后又解释说：过去微信团队只是暂时的，如果产品做不成，还是要回到阅读空间团队继续做下去。

当时我很纠结，在机器学习和数据挖掘上刚刚找到感觉，放弃它很是不舍。harvey让我考虑后再答复他。

我没有想太久，那天下午就答复了harvey：我去。

2011年3月1号，正式加入微信团队，成为ios客户端的第三个开发工程师，进小黑屋。

当时ios开发团队的andy给了我两本书，《objc基础教程》和《ios3.0开发技术大全》，让我在一周内看完第二周参加开发。

虽然从来没做过客户端开发，但是我一直觉得客户端开发没什么难度，况且我钻研计算机学科最难的课题－－机器学习和数据挖掘－－有一段时间了，普通的开发工作对我来说真是小菜一碟的事情，harvey当时也对我说：客户端开发只要上网找找资料学习一下，和同事讨论一下就可以解决大部分问题了。

确实没错。

我两天就把两本书翻了一遍，接下来的几天开始阅读代码，andy的代码还是比较容易读懂的，我在一个本子上画了两天流程图基本搞清楚了底层的大部分逻辑。在第一周的最后一天，我写了一个ios的“hello，world”。

第二周开始，从一个小需求开始，一点点堆积objc代码。一周下来，也是相当的纯熟了。于是接下来就参与了一个后来颇为重要的功能的开发－－群功能。

在3月份，接连发了两个版本，但是用户数据依然不见起色。

很快，我们在4月初又发了第四个版本，这个版本微信的四个tab位置被确定下来，最初的四个tab分别是：微信、通讯录、找朋友和设置。其中，找朋友这个tab可以看出当时微信的急迫，在这里，系统通过通讯录联系人、qq好友、qq邮箱联系人甚至企业域名邮箱联系人等多种关系链给你推荐好友，以期在很短的时间内能够积聚到用户。

但，用户数据依然不见起色。

另外一款应用的火爆引起了我们的注意：talkbox。这个发语音短消息的应用有着与kik类似的逻辑，但语音无疑是最大的亮点。类似的功能qq很早就做过，但一直不温不火，但是当它被放到手机上之后，瞬间捕获了大量的用户。

另外一方面，智能手机在这个时候开始高速普及，尤其是iphone4的发布，以革命之势席卷了整个手机市场。

小龙判断：智能手机和pc是完全不同的，基于智能手机平台的功能和pc上也是完全不同的。

也是从那个时候开始，团队就一直在挖掘手机平台的各种可能，不断尝试利用手机天然的能力做出极致简单且自然的功能。

很快，我们决定要做语音。问题来了，团队没有做过多媒体的经验，语音需要的编解码能力如果等着公司相关部门支持，怕是一个月也未必搞得定。当时我自告奋勇要求去搞语音引擎，虽然有信心，但内心很虚，一方面从来没有接触过语音编解码，另一方面，小龙和harvey判断用户对流量很敏感，我们要做到比talkbox更小的流量（三分之一的流量）但却要一样的品质。

两天后，我发邮件给小龙：搞定了。那是我在广研做过的最有成就感的事情，估计那个时候小龙内心一定默念：呐尼！但这绝不是最后一次。类似的事情很快又一次发生在2.5版本的视频功能上，同样的要求（whatsapp四分之一的流量）编解码只用了四天时间，那次我通宵了两晚，并且在旅游的时候还在写代码，一时之间成为团队笑谈。

其实我只是把开源项目做了适配，在ios上跑了起来，内里逻辑并没有太花时间去理解，我知道，项目的速度很重要，先完成再理解。后来很多的项目都是在这样的情况下完成的。

经过一个月的努力，微信2.0语音版终于在5月初发布了（这是正式第一版本，之前的版本都加了beta）。当我们看到用户数据一柱擎天的时候，很久以来压抑在团队头上的石头开始粉碎。

接下来的发展，我们一直在追赶当时另外一个很火爆的类kik应用－－米聊。我们当时从米聊的账号分配算法可以估计到他们的用户量，然后与自己的用户量做对比。但其实，我感觉大家并不担心米聊，以我们的产品研发速度和公司的用户基数，超越米聊是时间问题，大家真正担心的，是同门的另一个应用－－QQ。

但，作为一个处在生存期的应用，必须一个假想敌来超越（这也算是广研做产品的一个潜规则吧），那就米聊吧。

当时用户对微信、米聊甚至talkbox，感觉是差不多的，大家都在谈论着这三个应用谁抄袭谁，后来米聊做了涂鸦功能，他们的同事在知乎发表文章，说静等微信抄袭。

微信给的答复是8月初的2.5版本，除了那个我通宵两夜的视频功能外，那个版本最大的惊喜莫过于附近的人。可以这么说，语音版奠定了微信的基础，但真正让外界感受到微信强大的，是附近这个功能。

当附近的人发布的时候，相信很多人有这样的惊叹：微信原来有这么多人在用啊！

是的，我们很快甩开了所有竞争对手。

当国庆节那天我们发布摇一摇的时候，微信的地位已经是似乎无法撼动了。

但是，我们的担心还在，那个内心的幽灵一直挥之不去，团队依然崩的很紧不敢松懈。

本章结束。

另外多说一句：微信的“弹性工作制”也是从那个时候开始的，以前广研的作息最晚不过10点，从微信2.0之后，通宵会经常出现。

第三章 平台化

朋友圈和公众号是伟大的发明。

文字、图片、语音和群是微信作为通讯工具的基础，附近的人和摇一摇则进一步拓展了通讯的范围，向社交演进。到这个时候，微信已经是一个相当完备的移动通讯应用。

朋友圈是必然的。

QQ邮箱作为pc端仅次于QQ即时通讯工具的第二大通讯工具，它向社交的演进是受限的，因为用户上网交流的主场景不在邮箱，所以QQ邮箱选择从阅读切入社交，它遇到的困难远大于qzone。

而微信是移动端上网聊天的主场景，用户在移动端的主要活动聚集地，它天然的适合做社交，所以，微信有朋友圈是必然的。

朋友圈的成功有两个基础。

其一是阅读空间在社交领域三年的浸淫，让团队对社交有了比较深入的理解。

其二是超强的团队执行力。

第一点在前面阅读空间的文章中已经说的比较多了。主要谈谈第二点，朋友圈的整个研发过程耗时4个月，投入的人力不超过十个，但却在这短短的4个月时间内，团队完成了完整的30多个版本的开发迭代，我们形象的把这个开发过程叫做回转开发流程，每天上午，开发团队通过邮件接收产品经理整理出的下一个版本功能点启动开发，傍晚的时候把功能交付给小龙和产品经理，他们在晚上就当前版本讨论分析，然后在下半夜给出新的想法甚至方向，产品经理在天刚亮的时候把想法细化为一个个功能点发邮件给开发。周而复始。

当团队决定要发布朋友圈的时候，我想大家已经到了极限了，因为那时候还有bug没有解决，小龙说：bug也是一种文化，就发了。

朋友圈发布前，小龙和harvey打了一个赌，他们赌三个月之后的朋友圈日发图量的规模，小龙认为可以达到1000万，harvey觉得是200万。这个问题的答案我就不说了，各位可以自己去猜。

朋友圈的体验，相信很多人已经再熟悉不过了。咋一看他和facebook没什么区别，都是一个消息timeline的体验，但是用过一段时间后，你会发现本质的不同。朋友圈延续了微信的双向好友关系，没有向二度关系扩散，把用户隐私保护作为设计的基础，你在微信中无论是聊天还是晒命，都是没有任何压力的。

当然，朋友圈的体验还有很多体现产品情怀的细节。但保护隐私我觉得是最key的设计点。之后，微信内其他的任何功能，双向好友关系是设计的底线，不能逾越。

那么，在微信内看到的都是好友的信息，怎样看到更多丰富的内容呢？这就回到了阅读这个命题。

这次给出的解决方案是－－公众号。

关于公众号的话题，我打算在之后谈及微信商业化的时候再详细展开，我觉得它是一个潘多拉盒子。

2012-2014年的移动互联网，朋友圈和公众号的影响力相信大家都看到了。在它们出现之前，微信是一个成功的产品，在它们出现之后，微信成为了一个平台，在公司的战略中，它真正成为了一个与qq并驾齐驱（甚至领先）的双引擎之一。

2011年，微信有语音、附近的人、摇一摇；2012年，微信有朋友圈和公众号；接下来呢？

商业化和国际化。

有幸参与了微信从一个成功的产品演进为一个平台的过程，更庆幸接下来的两年里全程参与了微信的商业化进程，这又是一次学习与探索的历程，这段时间接触的人和事，各种感受给了我极大的冲击。

这段时间比较忙，更新无法保证及时，也没有时间雕琢，写的比较粗糙。最后奉送一个小故事作为收尾吧。

朋友圈本来是打算在2012年春节前发布的，团队一直绷的很紧坚持到春节前两天，在那天发生了两件事情，第一件事情是两位核心开发同事因为一点小事吵了起来，整层楼都听到了他们的怒恐。第二件事情是当天晚上我们团队去给一个同事送行（请假回家过年），全部人吃饭到10点还没回来，老大们急坏了，以为我们罢工了。这两件事情，最后给我们带来两个好消息，其一是年前不用发布了。其二是年后经过更加密集的迭代，有了一个更完美的朋友圈。

就这样吧。

第四章 商业化

微信的商业化布局在2012年底就已经付诸行动了。当时的讨论范围非常广泛，支付、卡券、微生活、微电商、游戏等等都经过很多的讨论，这个大讨论牵涉了公司内几乎所有的bg和部门。

讨论是发散的，但执行是聚焦的。

微信商业化是三层架构：最底层是微信的社交平台，它聚集了海量的用户，这是商业化的养分；第二层是开放公众平台，它连接所有的主体（服务和内容提供方），这是商业化的土壤；第三层是业务，包括游戏、支付业务、广告、O2O、电商、企业、硬件等，这是商业化的收成。

微信商业化从启动以来的这两年，在这个框架下逐步展开。

这个框架是非常清晰明了的，逻辑也比较简单，并无特别。但是与其他大的平台相比，执行起来却差别很大，我觉得百度强于技术、阿里强于商业、QQ强于运营，而微信强于产品，这就必然导致几大平台走出不同的商业化道路。

在微信的商业化决策中，一直还是以产品需求为导向的。小龙和团队讨论任何的商业化项目，主题一直是围绕着用户的需求展开的，战略、战术、竞争等等不会成为焦点。

问题来了。

商业是喧嚣的，不去吆喝怎么做生意呢？但是微信是用户的家园，是不能容忍喧嚣，尤其是，微信一直坚守为用户构建一个舒适的环境，没有干扰、没有隐私暴露、轻松可信赖。要在维护这个环境的前提下做商业化，难度是很高的。在C与B的博弈中，微信是倾斜于C的。

小龙在设计微信的过程中，提炼了很多的准则。除了上篇文章提到的不可逾越双向好友关系之外，有另外一个准则最能解释微信的各种商业化设计。

微信内的信息是和用户相关的，不是系统推送的。

这个准则延伸出去，有很多的结论。比如，不要做过度的活动推广，不要诱导分享，不要诱导关注，信息流要清晰，信息流突出好友等等。

这条准备保证了：微信是用户的，微信不是商家的，微信也不是微信团队的。用户打开微信，期待看到的是自己关注的信息，自己好友的消息，而不是系统推荐的不痛不痒的信息。

当然，这条准则不是强制性的，它是强制建议性。商业化是一个复杂的课题，有很多意想不到的事情。有一些重要的合作伙伴，他们提供关键的信息给微信用户，但需要微信给他们提供入口作为条件。微信在可控的前提下，提供了一些这样的入口，不过这些入口的收效却甚微。这就从另外一方面佐证了这个准则的正确，系统推荐的信息用户不待见。

但是，遵守这条准则执行起来很难很难。

其一，执行团队很难找到合适的B端一起参与项目开发。用户接收的信息流往往是需要B端角色一起参与，微信要求他们提供优质的内容，但是能够提供优质内容的B端很少，所以微信的B端运营规则显得很严，打压很厉害。

其二，微信商业化项目的设计很难。一般都会引入好友关系，会通过加强用户参与互动把功能做起来，但是这些功能无论怎样设计，都会太接近朋友圈，朋友圈在这里成了一个过不去的坎。团队在几个领域的项目中进行了几十次的迭代尝试，最终没有一个能够通过验收。

2014年，团队在电商、O2O、服务等领域做了很多的尝试，但是很少有项目能够达到满意的效果，真的是举步维艰。这一年，团队是在挫折中学习与探索。

不过，还是有一些成功的项目的。

游戏是第一个商业化项目，也是目前最成功的一个商业化项目。2013年的飞机大战打响了微信商业化的第一枪。

飞机大战这个小游戏多说一下，它和我的关系忒大了。

最初小龙只打算做一个坦克大战的动画作为5.0的启动页，不过那会我开小差在玩游戏引擎，顺便就做了一个飞机大战的demo。小龙看了之后觉得不错，让我们尝试把它做的更完整更有意思一些，于是我拉了一个小团队开始做这个事情，我们奋战了一个多星期，几乎每天都通宵的节奏做了四个不同的版本，美术、音效、玩法经过激烈的pk迅速换了一遍又一遍。我们甚至做了商业化的策划。

飞机大战的稳定性是很关键的，因为每一个用户启动微信都会先玩这个小游戏，如果出问题，所有用户就进不了微信了，当时我的领导甚至对我说，如果稳定性有问题，你可以卷铺盖走人了。

经过小伙伴们一个月的努力，最终飞机大战获得了不错的效果。那年回家，一路上听着不断的“求求求”的枪声，还是挺过瘾的。

上篇文章我提到过，公众号是一个潘多拉盒子。最初我觉得公众号是为了解决在微信上阅读的需求而设计的，它的订阅－推送模式说明了这一点。（我想，是不是小龙觉得团队太久没有阅读都变low了：）但是，公众号设计成一套消息系统，使得它拥有了无限的可能性，我又想到小龙很早之前提的统一通信的理想，公众号的设计我觉得是在完成这个理想。

从最初解决阅读的媒体订阅号，到后来连接一切的服务号，公众号给微信开了一个好大的口子。整个中国为这个小小的号沸腾了。但是团队一直以做优质平台为目标，两年多以来一直在非常谨慎的探索中为平台增加能力，节奏显得很慢，内外的质疑声越来越大，大家都不看好公众平台的商业化价值。

直到，团队在公众号的最下面开了一个口子，尝试做效果广告。这是一次成功的试验，效果超乎团队预期。优质的内容充分展示了它的商业价值，也更加坚定了团队做好优质的决心。微信广告团队一直没有以提升收入作为目标，团队通过不懈的学习与探索，坚实基础，努力把自己打造为最优质的效果广告平台，为用户提供有价值的信息。

微信商业化的故事一篇文章是写不完的。面向未来，各种挑战层出不穷，单纯的试错法也面临复杂问题的挑战，底层社交平台也面临发展的挑战，公众平台面临很多竞争对手对规则的挑战。后面的压力会越来越大。

但是，有两样东西还在：正确的方向和团队的激情。我相信，我们还是可以做的更好的。

-- 全文完 --

全站即时通讯技术资料分类

[1] 网络编程基础资料：
《TCP/IP详解 - 第11章·UDP：用户数据报协议》
《TCP/IP详解 - 第17章·TCP：传输控制协议》
《TCP/IP详解 - 第18章·TCP连接的建立与终止》
《TCP/IP详解 - 第21章·TCP的超时与重传》
《理论经典：TCP协议的3次握手与4次挥手过程详解》
《理论联系实际：Wireshark抓包分析TCP 3次握手、4次挥手过程》
《计算机网络通讯协议关系图（中文珍藏版）》
《NAT详解：基本原理、穿越技术(P2P打洞)、端口老化等》
《UDP中一个包的大小最大能多大？》
《Java新一代网络编程模型AIO原理及Linux系统AIO介绍》
《NIO框架入门(三)：iOS与MINA2、Netty4的跨平台UDP双向通信实战》
《NIO框架入门(四)：Android与MINA2、Netty4的跨平台UDP双向通信实战》
>> 更多同类文章 ……

[2] 有关IM/推送的通信格式、协议的选择：
《为什么QQ用的是UDP协议而不是TCP协议？》
《移动端即时通讯协议选择：UDP还是TCP？》
《如何选择即时通讯应用的数据传输格式》
《强列建议将Protobuf作为你的即时通讯应用数据传输格式》
《移动端IM开发需要面对的技术问题（含通信协议选择）》
《简述移动端IM开发的那些坑：架构设计、通信协议和客户端》
《理论联系实际：一套典型的IM通信协议设计详解》
《58到家实时消息系统的协议设计等技术实践分享》
>> 更多同类文章 ……

[3] 有关IM/推送的心跳保活处理：
《Android进程保活详解：一篇文章解决你的所有疑问》
《Android端消息推送总结：实现原理、心跳保活、遇到的问题等》
《为何基于TCP协议的移动端IM仍然需要心跳保活机制？》
《微信团队原创分享：Android版微信后台保活实战分享(进程保活篇)》
《微信团队原创分享：Android版微信后台保活实战分享(网络保活篇)》
《移动端IM实践：实现Android版微信的智能心跳机制》
《移动端IM实践：WhatsApp、Line、微信的心跳策略分析》
>> 更多同类文章 ……

[4] 有关WEB端即时通讯开发：
《新手入门贴：史上最全Web端即时通讯技术原理详解》
《Web端即时通讯技术盘点：短轮询、Comet、Websocket、SSE》
《SSE技术详解：一种全新的HTML5服务器推送事件技术》
《Comet技术详解：基于HTTP长连接的Web端实时通信技术》
《WebSocket详解（一）：初步认识WebSocket技术》
《socket.io实现消息推送的一点实践及思路》
>> 更多同类文章 ……

[5] 有关IM架构设计：
《浅谈IM系统的架构设计》
《简述移动端IM开发的那些坑：架构设计、通信协议和客户端》
《一套原创分布式即时通讯(IM)系统理论架构方案》
《从零到卓越：京东客服即时通讯系统的技术架构演进历程》
《蘑菇街即时通讯/IM服务器开发之架构选择》
《腾讯QQ1.4亿在线用户的技术挑战和架构演进之路PPT》
《微信技术总监谈架构：微信之道——大道至简(演讲全文)》
《如何解读《微信技术总监谈架构：微信之道——大道至简》》
《快速裂变：见证微信强大后台架构从0到1的演进历程（一）》
《17年的实践：腾讯海量产品的技术方法论》
>> 更多同类文章 ……

[6] 有关IM安全的文章：
《即时通讯安全篇（一）：正确地理解和使用Android端加密算法》
《即时通讯安全篇（二）：探讨组合加密算法在IM中的应用》
《即时通讯安全篇（三）：常用加解密算法与通讯安全讲解》
《即时通讯安全篇（四）：实例分析Android中密钥硬编码的风险》
《传输层安全协议SSL/TLS的Java平台实现简介和Demo演示》
《理论联系实际：一套典型的IM通信协议设计详解（含安全层设计）》
《微信新一代通信安全解决方案：基于TLS1.3的MMTLS详解》
《来自阿里OpenIM：打造安全可靠即时通讯服务的技术实践分享》
>> 更多同类文章 ……

[7] 有关实时音视频开发：
《即时通讯音视频开发（一）：视频编解码之理论概述》
《即时通讯音视频开发（二）：视频编解码之数字视频介绍》
《即时通讯音视频开发（三）：视频编解码之编码基础》
《即时通讯音视频开发（四）：视频编解码之预测技术介绍》
《即时通讯音视频开发（五）：认识主流视频编码技术H.264》
《即时通讯音视频开发（六）：如何开始音频编解码技术的学习》
《即时通讯音视频开发（七）：音频基础及编码原理入门》
《即时通讯音视频开发（八）：常见的实时语音通讯编码标准》
《即时通讯音视频开发（九）：实时语音通讯的回音及回音消除概述》
《即时通讯音视频开发（十）：实时语音通讯的回音消除技术详解》
《即时通讯音视频开发（十一）：实时语音通讯丢包补偿技术详解》
《即时通讯音视频开发（十二）：多人实时音视频聊天架构探讨》
《即时通讯音视频开发（十三）：实时视频编码H.264的特点与优势》
《即时通讯音视频开发（十四）：实时音视频数据传输协议介绍》
《即时通讯音视频开发（十五）：聊聊P2P与实时音视频的应用情况》
《即时通讯音视频开发（十六）：移动端实时音视频开发的几个建议》
《即时通讯音视频开发（十七）：视频编码H.264、V8的前世今生》
《简述开源实时音视频技术WebRTC的优缺点》
《良心分享：WebRTC 零基础开发者教程（中文）》
>> 更多同类文章 ……

[8] IM开发综合文章：
《移动端IM开发需要面对的技术问题》
《开发IM是自己设计协议用字节流好还是字符流好？》
《请问有人知道语音留言聊天的主流实现方式吗？》
《IM系统中如何保证消息的可靠投递（即QoS机制）》
《谈谈移动端 IM 开发中登录请求的优化》
《完全自已开发的IM该如何设计“失败重试”机制？》
《微信对网络影响的技术试验及分析（论文全文）》
《即时通讯系统的原理、技术和应用（技术论文）》
《开源IM工程“蘑菇街TeamTalk”的现状：一场有始无终的开源秀》
>> 更多同类文章 ……

[9] 开源移动端IM技术框架资料：
《开源移动端IM技术框架MobileIMSDK：快速入门》
《开源移动端IM技术框架MobileIMSDK：常见问题解答》
《开源移动端IM技术框架MobileIMSDK：压力测试报告》
《开源移动端IM技术框架MobileIMSDK：Android版Demo使用帮助》
《开源移动端IM技术框架MobileIMSDK：Java版Demo使用帮助》
《开源移动端IM技术框架MobileIMSDK：iOS版Demo使用帮助》
《开源移动端IM技术框架MobileIMSDK：Android客户端开发指南》
《开源移动端IM技术框架MobileIMSDK：Java客户端开发指南》
《开源移动端IM技术框架MobileIMSDK：iOS客户端开发指南》
《开源移动端IM技术框架MobileIMSDK：Server端开发指南》
>> 更多同类文章 ……

[10] 有关推送技术的文章：
《iOS的推送服务APNs详解：设计思路、技术原理及缺陷等》
《Android端消息推送总结：实现原理、心跳保活、遇到的问题等》
《扫盲贴：认识MQTT通信协议》
《一个基于MQTT通信协议的完整Android推送Demo》
《求教android消息推送：GCM、XMPP、MQTT三种方案的优劣》
《移动端实时消息推送技术浅析》
《扫盲贴：浅谈iOS和Android后台实时消息推送的原理和区别》
《绝对干货：基于Netty实现海量接入的推送服务技术要点》
《移动端IM实践：谷歌消息推送服务(GCM)研究（来自微信）》
《为何微信、QQ这样的IM工具不使用GCM服务推送消息？》
>> 更多同类文章 ……

[11] 更多即时通讯技术好文分类：
http://www.52im.net/forum.php?mod=collection&op=all

附录：有关QQ、微信的文章汇总

[1] 有关QQ、微信的技术文章：
《微信后台团队：微信后台异步消息队列的优化升级实践分享》
《微信团队原创分享：微信客户端SQLite数据库损坏修复实践》
《腾讯原创分享(一)：如何大幅提升移动网络下手机QQ的图片传输速度和成功率》
《腾讯原创分享(二)：如何大幅压缩移动网络下APP的流量消耗（下篇）》
《腾讯原创分享(二)：如何大幅压缩移动网络下APP的流量消耗（上篇）》
《微信Mars：微信内部正在使用的网络层封装库，即将开源》
《如约而至：微信自用的移动端IM网络层跨平台组件库Mars已正式开源》
《开源libco库：单机千万连接、支撑微信8亿用户的后台框架基石 [源码下载]》
《微信新一代通信安全解决方案：基于TLS1.3的MMTLS详解》
《微信团队原创分享：Android版微信后台保活实战分享(进程保活篇)》
《微信团队原创分享：Android版微信后台保活实战分享(网络保活篇)》
《Android版微信从300KB到30MB的技术演进(PPT讲稿) [附件下载]》
《微信团队原创分享：Android版微信从300KB到30MB的技术演进》
《微信技术总监谈架构：微信之道——大道至简(演讲全文)》
《微信技术总监谈架构：微信之道——大道至简(PPT讲稿) [附件下载]》
《如何解读《微信技术总监谈架构：微信之道——大道至简》》
《微信海量用户背后的后台系统存储架构(视频+PPT) [附件下载]》
《微信异步化改造实践：8亿月活、单机千万连接背后的后台解决方案》
《微信朋友圈海量技术之道PPT [附件下载]》
《微信对网络影响的技术试验及分析（论文全文）》
《一份微信后台技术架构的总结性笔记》
《架构之道：3个程序员成就微信朋友圈日均10亿发布量[有视频]》
《快速裂变：见证微信强大后台架构从0到1的演进历程（一）》
《快速裂变：见证微信强大后台架构从0到1的演进历程（二）》
《微信团队原创分享：Android内存泄漏监控和优化技巧总结》
《全面总结iOS版微信升级iOS9遇到的各种“坑”》
《微信团队原创资源混淆工具：让你的APK立减1M》
《微信团队原创Android资源混淆工具：AndResGuard [有源码]》
《Android版微信安装包“减肥”实战记录》
《iOS版微信安装包“减肥”实战记录》
《移动端IM实践：iOS版微信界面卡顿监测方案》
《微信“红包照片”背后的技术难题》
《移动端IM实践：iOS版微信小视频功能技术方案实录》
《移动端IM实践：Android版微信如何大幅提升交互性能（一）》
《移动端IM实践：Android版微信如何大幅提升交互性能（二）》
《移动端IM实践：实现Android版微信的智能心跳机制》
《移动端IM实践：WhatsApp、Line、微信的心跳策略分析》
《移动端IM实践：谷歌消息推送服务(GCM)研究（来自微信）》
《移动端IM实践：iOS版微信的多设备字体适配方案探讨》
>> 更多同类文章 ……

[2] 有关QQ、微信的技术故事：
《技术往事：创业初期的腾讯——16年前的冬天，谁动了马化腾的代码》
《技术往事：史上最全QQ图标变迁过程，追寻IM巨人的演进历史》
《开发往事：深度讲述2010到2015，微信一路风雨的背后》
《开发往事：微信千年不变的那张闪屏图片的由来》
《开发往事：记录微信3.0版背后的故事（距微信1.0发布9个月时）》
《一个微信实习生自述：我眼中的微信开发团队》
>> 更多同类文章 ……

作为半路出即时通讯开发者，微信一直是只能仰望的高山，从这些文字里能明显感受到一个伟大产品从无到有的过程，多谢分享。。

产品就跟人一样，一旦成功了，放的屁都会被人拿来研究
不过楼主分享的这篇文章不错，适合闷头搞技术同行看，从这里面能学到技术之外的东西，赞!

据腾讯内部的人表示，张小龙可能只是为了造神而塑造的形象而已，但谁知道会不会是出于妒忌才这行说呢，不管怎么样微信成功了

这篇文章不是鸡汤文，技术之余可以看看，能感受的到微信的成功并非偶然。研究了这么多微信团队分享的文字，这帮人确实不太一样，很执着，很好奇微信内部的激励机制啊，如何能让一帮自命清高的技术人员能像打了鸡血一样的往前奔跑

作为一个iOS小白，看完这篇文章，让我有了继续钻研下去的动力，谢谢楼主

引用：zhangshipin113 发表于 2016-09-21 16:39
作为一个iOS小白，看完这篇文章，让我有了继续钻研下去的动力，谢谢楼主

比我们聪明的人，比我们还努力。
但是还得继续努力。

一个团队，要对一个产品有一个本质的认识，要有一个执着的产品追求，在此基础上提炼出来一个哲学指导，才会使得向前的路走的很顺，不跑偏，不走弯路。而张小龙可能就是这其中的一个人，深深把控着这个哲学逻辑，让团队的每个人无论在无论多么复杂的问题和环境面前，都能找到辨别问题的基本原理。

引用：x931609201 发表于 2018-01-02 14:24
一个团队，要对一个产品有一个本质的认识，要有一个执着的产品追求，在此基础上提炼出来一个哲学指导，才会 ...

说的在理

简单纯粹，真好