移动终端APP大团队开发模式

本篇文章来自于腾讯SNG和msup共同举办的技术开放日移动端专场讲师石延龙的分享，由壹佰案例整理编辑。

本文将以手Q项目为例介绍大项目开发优化的流程和思想。一个项目从小的融资阶段发展到现在庞然大物般的大项目之后有什么问题，怎么解决？

手Q大团队的现状

QQ的历史很长，很多平台经过组织变更融合之后出现很多矛盾，还有很多功能在拓展、在继续变大，项目团队有14个部门，超过800个终端开发在写代码。

以Android为例，从4.0版本以来，平均45天一个大版本的迭代节奏，Android一个版本开发和修改的代码量是30万、bug是2000个，我们做了200个需求，可能跟大家见面的不一定有那么多，单版本在Android主干提交代码有130人。

多分支并行开发 双版本并行发布

手Q实行的是多分支并行开发双版本并行发布的运作方式，每个版本的开发周期都分为开发期和发布期：开发期是根据需求实行多分支开发；发布会有小范围灰度1-2次、大范围灰度1-2次，每一周一个版本，第一个版本发布时开始第二个版本的开发期、第二个版本的发布期开始第三个版本的开发期，以此类推。

每一个时间点上都有分支、版本以及非常多的功能需求，这样的开发模式下怎么控制质量是最重要的。我们的方法是争取在每一个分支的每一个阶段不放过每一个问题。

具体的做法是：这几个阶段每个需求都有准备期、开发期、合流期和发布期，根据耦合情况和风险将需求拆分到每一个分支，每一个分支都要有配额、权限、审批，在分支开发期所有的coding都是在功能完成、无bug状态才能进入合流流程，合流流程很繁重，必须测试通过后才能进入主流，主流把各个功能集成起来做一个集成测试。

五个手段实现质量控制

我们不仅要承担功能开发，还要承担质量的控制，除了功能的验证之外，尤其要关注的是性能以及资源，性能就是时延、流畅度、内存；资源就是安装包、方法数的增量，尽量控制这些数据的合理增长。运用以下五个手段实现质量控制：

第一、制定一些指标，包括核心指标（时延、启动速度、KPI指标）以及非核心指标。核心指标各个主界面、主场景的打开速度以及页面FPS。在各个指标的统计上可以看到纵向的对比、大盘的对比、用户时延的实际数据，这是衡量核心技术团队KPI的东西，不能有飘红，飘红的话赶紧跟进。

第二、实行数据监控。合流的数据各方面都要跑通，安装包的增量要合理，进行静态代码扫描，最重要的是核心产品的性能指标要达标，有红的地方就不能通过。将日常监控的数据累计起来，可以看到它们的趋势，在趋势对比中找到一些异常，有下降、有毛刺的地方就是出现问题的地方，是要跟进、并解决的问题。

第三，在开发过程中还要做实时报警、跟进。代码跟进，实时监控，比如突然出现一张大图浪费了很大的内存，这种情况是不允许出现的，我们有很多辅助工具能够监控各个场景。

第四，发挥人工的功能，在开发群里每天都会有开发值班，响应老板、用户、开发同事反馈的问题并及时跟进，大家作为产品的第一个体验者，尽量做到第一个发现并解决问题。

第五、做技术运营，对用户的非个人隐私数据做一些预处理、后处理或大盘优化。

以消息优化和富媒体优化为例 看手Q怎么做技术运营

一、消息优化

1、加载优化。信息量大于30W的超过60%，在消息加载过程中，必须要有加载的策略。加载策略简单来说是：最优先加载的是首屏数据的资料、未读数、摘要，加载完以后，对用户可能打开的首屏会话的历史消息进行加载，这时进入历史会话的速度还是很快的，然后再加载其他的会话、消息和历史消息。

2、拉取流程的优化。更新资料、更新消息、更新好友、更新群组上线、CC消息等，最简单的优化方法就是一次把所有的包发出去，节省RTT，这样是最快的方法但是效果却不是很好。我们知道终端与后台之间有一个接入层，叫SSO，之后是后台的业务服务器，参考方法是做一个代理服务器，接受终端的请求，不需要多，一条就可以将各种更新资料的时间戳发上来。然后请求拆分，拆分到多个业务服务器，还像之前一样收到请求之后返回就OK，这样流量包减少了，减少流量的同时减少了耗时。

有问题是，过程中，首屏数据会跳动，或者是把历史消息拉回来而不是首屏的数据，要怎么改进？业务服务器收到回报后不直接返回给终端，而是返回给代理服务器，代理服务器对收到的这些杂乱消息进行排序，并将首屏数据提前返回，后面的数据再慢慢回来。

开发80%的时间都在处理各种网络传输异常，传输延迟是理论的5-10倍，丢报率超高，每天有600万条消息发送失败，有4500万条消息处于发送时间超长状态。这种状况急需改进，具体的改进方案是：1、冗余的双连接对抗高丢报；2、积极探测长连接对抗假网络；3、抢占联网速度，拯救弱网络消息。

二、富媒体优化

这是一个全栈的方案，包括终端网络协议、协议网络以及后台，技术非常多，拿一两个举例说明。

1、终端发送预支流量 控制流量风险

首先是终端发送的流程，基于这个流程以及当前给的数据，怎么做到1秒钟发完，压缩、信令上传和发送并行，用户选图耗时平均2秒钟，在选图的时候预压缩、预请求信令，直到最后用户点发送消息的时候，就把消息发出去了。

这个过程帅气而不影响压缩，压缩只是稳定的消耗，在交互过程中没有繁重的影响，启动了独立进程来完成。需要考虑的是流量的问题，用户点完一张图以后就发送了，这里有流量的风险，万一用户只是选择图片并不想发送怎么办？

敢做这样的优化方案就是对大盘的用户行为做了详细的分析，95%的用户对选图片的行为不后悔，但还是有风险，黑天鹅总是可能会存在。

这是银行家的方法，自学习自优化，用户是银行，我是他的管家，每天向他预借200K流量用于预发送，当预发送完毕之后我从这200K里减50k，减掉之后，用户不发了，我就亏了，我不能再消耗用户的流量，只能消耗200K，所以一天的最大风险是200K。如果用户实际发图了，我再把50K补回来，就没有消耗，这样的方法可以很好地控制流量风险。

2、早触发慢启动 获取最优速度

中间的大数据通道是前后端的协议，右边的TCP是AIMD很慢，如果每次发送图片都要经过这样一个过程，传输速度肯定很低，怎么办？

三次握手，其实我在预测用户发图行为时就已经完成了；下一个是提早触发慢启动，确保真正传输数据前处于最佳状态；可以扩大服务器通告窗口，服务能力需要后台支持，达到很好的服务速度；最后一个是下一次传图复用通道，立即获得最优速度。基于这个结果传输速度平均提升48.4%。

 现场问答 

：大项目多个分支在拉取时的策略是什么？最后归并的时候如何降低归并成本？

：拉取策略是要根据业务做评估的，开发什么功能要做评估，尽量将耦合的业务拉到一个分支上面，最后才不会出现冲突，尽量内部聚合、外部解耦；

减少归并时的冲突方案就是一个自动rebase系统，一个分支要归并到主干的话，都需要定期的rebase，将主干同步到分支上，这样分支随时都有主干的修改。

：如果版本用SNG管理模式的话，线上出现了bug的问题怎么修复？是逐一在主线修复后再在所有分支上进行向下修复？还是合并到相应的主干上去进行修复？

：发布的时候从主干拉一个分支出去做发布，发布完分支以后就会把打tag，在这个tag基础上形成一个Patch包下发。线上的版本肯定是主干拉出去的，在发布阶段不会有差异，只有在主干发布完才有。

：首期已经把卡顿量化出来，把性能指标量化出来的思路是什么？

：卡顿通过监控主线程的耗时来进行量化，如果主线程超过逻辑耗时，Android超过300毫秒就会卡，用例场景不变，监控这一段主线程耗时，这个值不比前面高或者高于多少，这是量化标准。文中说的是时延，时延就是打开主界面时，点击图标到主界面的完全展示的时间，这个可以自己做也可以在插桩代码中做，关键的场景都是插桩做的，然后统计时延做一个量化指标。