具有强运营属性的客户端产品基础技术架构

计算机诞生到如今的几十年里，软件开发技术也经历了数不清的更新换代。从开发语言，到开发框架，再到软件开发模型，不同层级之间都是百花齐放的情景。而互联网的崛起，也让C/S和B/S架构的系统瞬间爆发。B/S架构是互联网的开拓者，但是由于早期硬件性能不足，浏览器功能单一，所以B/S架构没有十分突出的发展势头，也从另一方面拖慢了前端技术的发展。而C/S架构的系统在互联网发展的这前几十年里应该是出尽了风头。因为可以提供精准灵活的功能，对性能可控，所以很多系统都会通过客户端的方式来提供服务，这也让客户端开发在这几十年里得到了长足的发展，至少在技术方面是这样。

十年前的客户端开发可能就是一堆功能做出来，发布出去，只需要主要功能正常，那这个客户端的其他问题就没有人过问了。甚至当主要功能出现问题的时候，开发者想找原因都无从下手。运营的概念出现的不晚，可是客户端运营却很晚才被重视起来。在PC时代，也只有少数拥有独角兽一样的产品的公司会注重对客户端的运营，这需要公司具有很强的产品基因。客户端是用户使用互联网服务的终端，会给用户最直观的感受，所以一个客户端产品的好坏，可以决定一个公司的口碑。而真正懂得客户端产品运营，又可以从运营中得到反馈，不断提升产品质量，发掘新功能。所以客户端运营正在变得越来越重要，尤其在移动互联网白热化的现在，一个APP就是一个客户端，而很多中小型或者startup的初创企业都是依托一个APP来提供服务，也许你的服务模式很好，但是却有一个体验很差的客户端APP导致流失大量用户。所以本文主要简单介绍一下一款具备强运营能力的客户端产品需要哪些通用的基础技术设施，无论是PC端还是移动端。

为什么需要运营？一个没有运营经意识的团队，开发一个客户端的时候可能只要把业务功功能实现就觉得一劳永逸了，而发布一个版本出去就像泼出去一盆水，或者断了线的风筝。对于这个版本发出去之后在用户端的表现状态却没有任何关注，或者通过耗时费力的用户回访来收集一些产品使用数据，这样的客户端产品是没有可运营的基础能力的。对于立志做精品互联网客户端产品的团队来说，产品需要快速迭代，迭代的过程需要 加入什么样的Features或者需要对现有Feature做什么样的改进提升？这些都是需要团队决策的，但是这些决策很大程度上都依赖于旧版本现存问题，以及用户对旧版本的使用体验等等。所以靠用户回访这种刀耕火种的运营方式很难适应今天动辄几百万几千万用户的客户端产品了，而这时候一个客户端产品就需要具备一些基础的技术运营能力了。

一．整体架构

从架构来说来说，客户端开发技术应该已经经历了三个大的世代。第一个世代是最早一批C来写的网络程序，没有任何模块划分，逻辑分层，可能一个函数写几千行。而这个时候开发者的唯一关注点就是功能的实现，不会考虑太多其他方面。第二个世代，开发者开始考虑程序的组织结构，模块划分，逻辑分层等，注重于程序的长期可维护性。第三个世代，也就是现在正处于的世代了。现在的客户端会考虑扩展性，因为要适应迭代，方便的加入新的功能模块。而现在主流的架构是插件化，这也是后面要介绍的几个功能模块的基础。插件架构的出现也有很长一段时间了，也有比较多的实现方式。就目前来说插件架构的最优目标就是实现插件的的“热插拔”，在实现层面根据不同平台也有很大不同，比如Windows平台的动态链接库（DLL）或者Linux系统下的SO，在Android和IOS系统平台下比较简单的实现方法是使用基于Web的轻量插件。一旦插件框架确定之后，不同业务模块插件可以并行开发，提高开发效率，提高软件项目的可维护性。本文的重点不在某一个点，所以这里就不详细介绍如何设计一个插件框架了，后面有机会再专门介绍。

二．用户使用数据上报系统
早期的客户端产品可能仅仅是一个单机软件产品，不会有网络模块，更无从谈起数据上报功能了。而后来出现了C/S架构的客户端产品，但是对于网络的使用也仅限于业务功能，并不会专门设计数据上报系统。而在移动互联网发展高峰期的今天，仍然有很多客户端或者APP根本没有意识到数据上报的重大意义。互联网发展的这么多年，很多理念都在改变，客户端的开发技术和理念也在不断的改变。在大数据如火如荼的今天，一个优秀的产品团队都会有很强的数据驱动意识。尽管很多产品经理崇尚乔布斯的偏执作风，但是并不是每个产品经理都是乔布斯，并不是每个老板都是乔布斯，所以在产品这方面最有说服力的应该是从真实用户那里收集到的实实在在的数据，所以客户端产品的一个最重要的可运营属性就是要提供用户基本使用数据的上报系统。

现在在移动端APP产品中，如果产品是通过官方商店发布的，App Store或者Play Store都会提供一些基础数据的分析，比如下载量，下载用户的详细信息等。而同时对于C/S业务的客户端产品，用户在线数，登录数，在线时长，日/月/年活跃数都可以通过后台获取到。当然这些数据对客户端运营也是必不可少的，但是这仅仅是很少的一部分数据而已。如果客户端产品能够对诸如点击率，点击链，页面停留时间，业务成功/失败率，偏好设置等等一系列的数据做上报，产品人员通过对这些数据的静态和动态分析，能够对产品在多维度形成非常直观的量化感知，从而对产品后期的改进做出相应的决策，同时还可以挖掘产品潜力扩展新业务增加新功能。比如通过数据分析生成用户画像，有助于了解产品的用户群体特征，以后在推产品新功能的时候可以有目的的灰度，这样能够进一步提高用户反馈的精确度。比如对用户点击链和页面停留时间的分析，可以得出目前产品中那些功能是用户喜爱但是入口却被放置在了比较隐蔽的地方，以此来进行调整，降低用户的使用门槛，增加热门功能的曝光度。再比如对用户的偏好设置进行分析，调整默认设置去迎合多数用户的使用习惯，同时根据相对数据来决定是要让少数用户服从多说用户的习惯还是保留一个可选项等。正确的数据是不会说谎的产品指导准则，也是减少团队扯皮拉锯的利器，提升效率，精准解决产品中的大部分痛点。

对于数据上报功能的设计，重点需要考虑扩展性，因为对于数据种类的需求无法一次就确定，往往随着产品的迭代会增加新的数据需求。这时候如果能够通过不修改上报模块，只在目标监控点增加采数据集代码就能完成新增需求，这就说明上报系统已经具有不错的扩展性了。当然这只是在客户端增加了数据上报的基础设施，真正运营的工作还要靠团队建立一个强大的大数据分析平台了，数据上报之后其实只是一堆数字垃圾而已，而真正赋予这些数字垃圾信息化价值的过程是分析。试想作为产品经理的你每天一到公司都会收到关于产品的数据邮件，可以看到新鲜的数据报表，曲折的线图，跃动的燃烧图等，这些都将为你的工作和负责的产品提供非常有价值的支撑，你应该感谢有这么好的运营团队。

三．稳定性发现和保障模块

稳定性是一个优秀客户端产品的必备属性，而客户端产品在用户端最严重的问题应该就是崩溃（Crash）了，在移动端OS中表现为闪退。试想如果某个新版本由于测试疏忽导致发布出去的版本在启动后立刻Crash，而且是必然出现的。如果没有做相应的Crash数据上报，开发团队就无法估计这个问题的严重性，覆盖率，这对业务带来的损失是比较严重的。而由于没有做Crash上报，也无法收集到足够的用于分析Crash的数据，从而增加解决问题的难度和时间。

Crash数据上报是了解一个客户端产品稳定性的基本解决方案，也为解决Crash问题提供了充分的方法手段。Crash数据上报系统一般关注的是实时Crash量，日Crash率，实时Crash量作为应急响应的一个依据，而日Crash率作为衡量产品质量的一个重要数据，可以作为团队工作输出的一个量化标准。Crash上报除了上报的基本的数据例如Crash时间，模块，产品版本等等之外，最重要的是需要上报用于分析Crash的程序现场数据，如堆栈，内存dump等（PC上通常这两个是在合并在一起的）这才是Crash数据上报的根本目的，因为这样才能快速分析定位问题，然后发布补丁或者直接升级版本。移动端的APP Store都已经提供了这个基本的分析功能，一般来说都能有助于解决产品的Crash问题。不过相比自己实现的Crash数据上报模块来说，App Store提供的功能比较固化，不利于和现有其他的自动化系统做集成。13年的时候PC QQ的日Crash率已经降低到了0.15%，每双击启动QQ程序100次只有0.15次Crash，而且是稳定数据。

四．性能数据

性能也是一个优秀的客户端程序需要关注并不断提升优化的，因为性能直接关系到产品的用户体验。性能问题是产品用户体验的前提，如果产品性能很粗糙，用户体验就没有任何保障了。一款产品在交互视觉等方面的设计和实现都无可挑剔，但是却由于CPU占用，内存占用，I/O过多导致用户界面长时间无响应，等待时间过多，甚至直接影响用户的物理设备的使用，那这款产品也不会让用户轻易信任和喜欢。

所以对产品性能数据的掌握，也是不断提升产品质量的一个重要手段，在客户端中对用户使用时候的程序性能数据进行收集上报，通过分析发现产品的整体或者某个业务模块的性能问题，然后着力解决。一般性能数据包括CPU占用，内存占用，I/O操作耗时，活动响应耗时等等。在移动端App中可能由于OS机制的不同限制了某性能数据的获取，但是为了长期的产品质量，也还是应该最大限度的对这些至关重要的数据进行上报。

五．云端可控

前面讲通过Crash数据上报可以快速解决Crash问题，但是从发现问题到解决，再到真正把已经解决Crash问题的新的产品推送到用户终端，这中间仍然是一个漫长的过程，如何在这段时间中让已经使用了出问题的客户端的用户避免触发Crash，以保护产品口碑，降低损失呢？云端可控就是为了解决这种问题的应急方案。

所谓云控就是通过后台的可配置开关来控制客户端的某个模块的功能的开启或者禁止，这样如果一旦发现客户端大量Crash之后，通过Crash上报先确定问题模块，然后通知后台关闭对应模块的控制开关。这样一来客户端就把会发生Crash的模块在用户端隐藏掉了，用户可以继续使用核心以及其他正常的扩展功能，而仅仅是出问题的模块暂时停止服务。这样就可以最大限度地降低由于Crash带来的对其他正常业务模块影响。可见云控系统对客户端应急运营有多么大的帮助，当然也有一些厂商会用这项技术来做一些见不得人的事情。有一点需要明白，一个设计优良的云控离不开一个高扩展性的整体架构。

作为在PC客户端开发领域工作了四年的我来说，这篇文章写的比较散乱。文章出现最多的应该是“数据”这个词，3年前做过一段客户端数据相关的工作，在那之前QQ的上报数据也只是一堆垃圾，没有人关心没有人处理。后来部门的领导慧眼独具说要把数据做起来，于是我就接手了这个工作，也有幸见识了公司的大数据分析处理平台，洛子任务调度系统，TDW，罗盘报表系统等，写了几百张数据表的分析任务脚本，当时就已经感叹数据对于产品的重要性。而现在大数据依然是一片红海，从而也带动了拓宽了“运营”市场，只要能出数据的地方就有可以运营的事物。客户端从技术方面来说发展的终极方向是application stream，将来你打开一个客户端，就像打开一个网页一样，不同的是浏览器读取HTML，而客户端读取二进制流。那时候的客户端就没有所谓的下载安装这个过程，发布新版本就像部署网站新版一样简单及时。但是无论这个客户端的发布形式如何改变，数据对于客户端的提升永应该是不会变的。