胡泽锐：移动开发即服务——腾讯云移动开发平台技术分享

作者：胡泽锐，2010 年毕业加入腾讯，先后负责过QQ空间、网页应用、移动应用、移动游戏相关的工作，有着丰富的平台产品经验以及大前端开发经验，目前在腾讯云负责前端以及终端相关的工作，提出并推动移动开发平台产品的落地。

很高兴能和大家分享移动开发的历史、现状、以及未来，一起探索面向云端的全新模式——移动开发即服务。正因为有了移动开发即服务的理念，才有了移动开发平台这个产品。传统模式下，大家都是以单个产品或者能力的方式提供服务，比如推送的就提供推送的服务，分析的就提供分析的服务。也许在单个产品下，能做到体验的极致，在接入使用，或者管理上能做到很方便。但对整个移动开发来讲，这种单品的割裂会导致整个移动开发体验的不流畅、不完善，各个产品之间的割裂会导致整个移动开发的节奏也是割裂的，我们无法完整地做到一件事情从头到尾只在一个平台上做，所以腾讯云提出一个全新的模式——移动开发即服务。

这里面包含两个概念，一是要做移动开发整体的事，我们要服务移动开发整个的生命周期。二是做服务的事，服务这里也包含两点：一是我们的开发体验必须要做到完善，二是使用体验也要尽力做到最好。

移动开发平台

下图是腾讯云和腾讯内的各个产品合作，深度整合各个产品，联合推出的全新的移动开发平台。如果只是看功能的话，这些产品都不是什么特别新的东西，比如移动分析，这些产品不只在腾讯公司内部广泛应用，在公司外部也有类似的产品提供对应的服务。比如MTA我们公司已经使用了很久；bugly在公司内外得到印证，在业界也有广泛的使用；计费米大师集成了公司所有产品的计费功能，包括应用宝、开发平台这种toB的产品，也有王者荣耀、QQ飞车具体的应用。

移动开发平台就是将这些产品进行深度整合，变成一个整体，以一种全新的开发模式和体验提供给开发者。开发平台4月份上线，在一个多月的使用过程中，我们发现开发者使用的火爆程度超出了我们的预期。通过对用户回访以及统计数据，我们总结出三个关键点。

1、易用

在进行用户回访的时候我经常问一个问题，你觉得在接入和使用产品的过程中有没有遇到什么难题？用户一般给我的反馈都是这样的：挺顺利的、没有遇到什么问题；挺好的、能顺利接入。其中有两个回答我印象比较深刻，一是说挺好的，文档能看懂；二是说文档挺齐全的，想用的几个功能，如自定义、标签推送都能很快找到。

也许对外部的人来说，这种反馈很普遍很正常。但以一个移动开发者多年的经验，我觉得这两点其实是很高的评价。我们一般在使用其他的产品时，经常会遇到几个问题。第一个是文档看不懂；第二个是跟着文档操作遇到问题时不知道该怎么做，不知道要怎么进行下去；第三个是在遇到一些比较高级功能的时候，找不到文档应该怎么做。所以，我认为上面的两个回答是对开发平台易用性比较高的评价。

2、效率提升

这个提升包括两个方面，在接入过程中，接入一个能力也好、多个能力也好，开发平台提供比较简便便捷的方式，节省用户接入的时间。第二个是在使用过程中，因为我们提供比较齐全的功能，能够让用户比较专注在核心业务上，而减少被打断的时间。

3、高留存

从统计数据来看，我们发现使用我们产品的开发者，最终的留存率可以达到50%，这是一个很可观的数字。另外，我们也接到很多用户咨询，希望把线上的产品迁移到我们的开发者平台上。我们现在主要是提供新开发的产品，还没有针对现有产品提供迁移的服务。因为这类用户的咨询量也比较大，所以我们也在准备这方面的事情。

这些关键词从正面、侧面体现了整个产品的易用性和可用性。后面我会具体分享一下，在整个开发平台在设计和使用过程中，我们都做了哪些事情来提高开发者的易用性和可用性。

移动开发的演进历史

上图是根据个人工作经验及移动开发的历史进程总结出的四个时间点。2010年是我首次接触移动APP开发；2012-2013年真正从零到上线参与和主导一个移动APP的开发；2014-2015年在我负责移动游戏的时候，当时的服务已经是比较成熟的阶段了；2017年我在腾讯云负责终端和前端的工作，有一次与合作伙伴进行一个移动APP的项目，首次以外部人员的角度认识如何去构建一个移动应用。在这期间我们也遇到了各种各样的问题，使我下定决心去做一个移动开发平台这样的产品。

2010年，其实是移动开发刚兴起的阶段，我认为这是一个拓荒的时代。因为当时国内资料特别少，我们经常从国外找一些资料，早期阶段遇到的最大问题就是在性能方面，当时花费了相当多的时间去改进性能。我们关注内存、渲染、速度，用各种方式去进行优化。

第二个阶段是2012-2013年，就是在这个时期提出了移动优先的概念。手机进入大屏时代，比较标志性的事件是三星note系列的大卖和iPhone5的推出。当时很多开发者一窝蜂地涌入移动开发，但那时的移动服务还是很不齐全的。有一次我们需要一个像现在的信鸽这样的推送服务，我们尝试了很多服务，发现都很难满足需求。所以我们只能自己做一个，但这个过程非常艰难。推送要保证触达率、时延等，我们在开发过程中经常被打断，比如做到一半，有人提出自己接收不到推送，我们就必须停下来寻找原因，在上线之后也会遇到推送触达率不够这样的问题。移动推送只是一个简单的缩影，当时会遇到很多这种组件不完善的问题。虽然大家都在转向移动开发，但当时的服务还不够齐全。

2014-2015年我在公司内部负责移动游戏，当时开发的过程就好了很多，一些周边的事情已经不需要自己去做了。我在做架构设计的时候，会将一些不同阶段用到的功能预先加入进来，比如移动分析、移动推送这类常用的服务，像排行榜、公告系统等也会在一开始包含进来。虽然服务比较齐全，但是也会遇到一些问题，比如集成方式不统一、初始化方式不统一、使用方式不统一，不同的厂家或不同的部门提供的是不同的集成方式、初始化方式、使用方式，对于使用者来说就很不友好。所以我们就做了一些封装，比如当时把所有初始化的东西放在统一的地方去屏蔽初始化的细节。二是在上面包了薄薄一层，尽量让整个使用方式统一。我相信大家做移动应用的时候也经常遇到这样的事情，需要自己把不同厂家提供的不同的接口统一起来。

2017年，我和合作伙伴一起进行了一个移动应用的项目，但是也调研了国外的云厂家是怎样去做的，比如亚马逊。当时亚马逊已经提出了这样的概念，把所有场景、所有生命周期的东西包含在一起，推出一个Mobile Hub产品，包括移动开发的整个阶段，比如开发、测试、部署，整个研发的体验都做得比较好。国外移动开发者服务进入一个新的阶段，我们认为这是面向云的一个阶段，但其实国内在这方面做得还比较初级。当然不同的产品面向云的方式会有点不太一样，我们现在提供的方式也会与aws有点不一样。不过基本上的理念是差不多的，是一个面向云的全新开发模式，让移动开发者以整个移动开发的方式来做，而不是以推送、分析这样的单个产品去做。

我们回顾一下做移动开发的整个进程。从零开始做一个应用，在没有开发前就应该去做架构的规划，我会考虑把可能用到的能力，先统一集成进来。首先我需要分析能力，第一步我就要先去官网注册一个帐号，然后把SDK集成进来，第三是编码去使用它，第四是上线之后需要查看数据的管理时候要去控制台。搞定分析后，发现推送需要将这个过程再做一次，还有很多其他服务也是如此。这种事情至少做了五六遍，做了很多重复的事情，只是为了把不同的能力整合到一起。

当所有的能力集合在一起，还需要做代码整体体系的设计。设计完成后，我就会发现一些存在的问题，比如代码散乱，我花了很大的精力去解决代码散乱的问题。这个问题是怎么造成的？第一是集成方式不统一，有些是给我一个SDK的包手动集成进去，有些是用工具如gradle，cocoapods集成进来，还有是提供另外的方式让我集成进来。集成这一部分没有办法做到在同一个地方把所有的服务全部整合在一起，在一个人开发的时候可能问题不大，但在多人合作的时候就会出现一些问题。比如当我在做项目沟通或者项目交接的时候，必须要说清楚推送服务的集成方式，还需要写文档说明每个能力是如何实现的，我们花了很多的时间和精力去解决这样的问题。二是初始化和使用方式不统一，有的是按需初始化，有的是让我在项目一开始就进行初始化。使用方式也不太统一，各种模式混杂所导致的问题就是使用的时候让人难以理解，项目交接的时候也非常困难。有些初始化的部分代码不一样，而且代码也散乱在不同的地方。在一个架构师的角度看来，这是一个非常不好的体验。

第二个是沟通成本高。当我做完整体的架构设计之后，还必须召集整个团队的开发人员一起开会，告诉他们如何使用这个产品，如何使用每个能力。这是启动阶段的开发和培训，需要占用一部分的时间。整个开发团队在开发过程中也无法做到只专注业务，他们经常会遇到一些问题。比如在使用某个服务的时候需要一个功能，找不到的话就找人联系我，我再去查看对应的文档，或是尝试解决后并反馈给他，这中间有一个时间成本。而且在这种情况下，开发过程中每次的打断其实都让整个团队的效率降低。

第三个是研发效率的低下。看到云服务带来的便捷，会感觉到传统模式下的方式其实是不够高效的。举个简单的例子，如果想要集成一个简单的文件上传下载的服务，以前我会搭建一个存储的服务器，自己实现上传下载的细节。但现在不是这样了，大家都可以用对象存储服务去做这样的功能，提供了便捷的SDK去做这样的事。但是我需要自己把这个能力集成进来，集成服务之后才可以便捷地使用，使用几行代码实现文件上传和下载。现在是云时代，云可以提升研发效率、提高各种研发性能，但是移动开发者没有办法直接享受到云的便捷，需要做一些事情把云的服务整合进来。当时做架构时只能花很多精力、写很多文档和范例解决沟通成本高的问题，将云的功能整合进来，提供给团队的开发者。

我觉得这种事情其实应该规范化、批量化，我们应该给移动开发者提供一个更好的服务，将整个移动开发作为一个整体的服务。我想起2015年看到的某咨询机构调研中的一个片断，当时的体会并不是特别深，但当我做完这个应用的时候，脑海里就想起了这个图。2015年中国移动开发者使用第三方服务工具最看重的因素，排名第一和第二的分别是丰富性和易用性。刚看到时也没有特别大的感受，但2017年在进行应用的时候发现确实是这样。丰富性和易用性，是我们移动开发者真正考虑的很重要的因素。

移动开发即服务

当我们下定决心做移动开发平台的时候，首先我们进行了用户调研，通过各种手段跟用户面对面的沟通。通过调查问卷，调研了移动开发者的诉求究竟是什么。一轮调查下来，不停地抽象，最后总结出一句话：把精力放在核心业务上，提升效率。这是一个非常朴素的需求，但事实上我们的现状很难满足这样的需求。比如做到一半时需要一个存储能力，经常就需要放下手头的事去调研一下市面上都提供了哪些存储服务，再把它集成进来。做到一半时需要一个推送服务，也要调研一下市面上推送服务的厂家，经过调研再把它确定下来。特别是架构师，经常把精力花费在一些本应该很容易解决的事上。所以我们认为移动开发者的核心诉求是把精力放在核心业务上、提升效率。让一些可以通用化的，类似于分析服务、推送服务、存储服务的这些服务由第三方厂家提供，因为这不是我核心的逻辑。

确定了核心诉求后，我们经过分析后认为移动开发平台应该从下面几个方面去设计。

1. 架构师思维。帮助开发者以架构师的思维构建移动应用，我们应该让一两年、两三年经验的移动开发者很容易以架构师的角度去构建整个移动应用。
2. 傻瓜式应用。使用的方式越简单越好，最好是让傻瓜都能用。
3. 灵活搭配。我可能会在各种阶段引进能力，例如在一开始的开发阶段，或者运营阶段。比如我一开始可能不打算做付费，一定阶段之后发现我可以做付费，我要开始做付费了，这时候需要引进付费能力。移动开发者应该能在任意阶段去做这样一个事情，在任何阶段即插即用、按需使用，帮助开发者提升效率。

说到架构师思维，当时认为可以分两部分考虑这样的问题。第一部分就是服务，架构师是如何考虑服务的？一是易用，二是性能，三是可扩展，第二和部分是代码，代码的可读性、可维护性和可拓展性是我作为架构师必须要重点关注的几个问题。所以我们的移动开发平台所提供的服务，必须是满足易用、可扩展和高性能的。我们应该也能让架构师在代码层面，做到可读可维护可扩展。这是从架构师的角度去思考问题，我们需要做到的一些事情。

既然我们的思路已经确定了，要怎么去做呢？我们的产品一共分为控制台和SDK两个部分，一是控制台，控制台必须是统一的，所有的服务必须在同一个地方控制，这是没有任何疑问的。所有的服务必须在统一的地方去做控制和管理，集成也应该是统一的。SDK是移动开发者最最关注的一个点。当时思考把SDK分为三个方面，SDK的集成、SDK的初始化、SDK的使用，我们从这三个象限来考虑整个用户的使用体验。SDK的部分我们考虑了几种方式，首先我们提出all in one的模式，也是按需打包的模式，这是国内厂家最常见的模式。但它们在初始化的时候是独立的，使用的时候也是独立的，这种方式很快就被我毙掉了，这种模式会存在比较多的问题，比如打包下载，手动集成，当我有版本升级的时候怎么处理？很麻烦。第二是当我需要一个新能力的时候怎么处理？是单独勾一个还是把以前用的全部勾上下载呢？用户会有这样的困扰。这种体验，跟传统的体验方式可能会有一些优化，但我觉得达不到我的预期。

第二种模式，统一配置，按需使用。现在我们使用的也主要是这种方式，所有包的集成和使用都是用配置来实现的，集成是不需要任何代码，通过配置方式去做的。然后各自独立初始化，这点可能大家觉得初始化跟之前还是一样，但其实会有点不一样的点。正常情况下是不需要初始化的，比如使用标准配置就不需要进行初始化。但是如果需要定制服务，比如说我的分析是多少秒上报一次或实时上报，还是说一段时间整合在一起上报或达到一定的量上报，这是开发者根据他的需要去做独立配置的，这种情况就需要去做初始化，做不到零代码集成。你使用标准配置的情况下，你的使用和初始化集成都是零代码的，但当你需要做定制的时候可能就需要代码去做一些事情。

怎么能用更好的方式给移动开发者提供服务呢？这是我一直在思考的问题，有一天突然想到像我们这种不懂服务器的人都能独立搭建一个服务器，比如ngnix，tomcat，那是为什么？是不是我们的移动开发也能做到这样，集成和初始化其实都不需要代码去做参与？延着这条路去想，就想出了一种新的方式，零代码集成、基于配置。现在也正在向这方面去做，希望能做到完全的自动初始化。

首先集成跟以前一样，通过配置的方式去集成，零代码。二是初始化，刚才说对于标准情况能做到自动初始化的，但对于定制的服务需要代码，现在针对这种情况也是基于配置来做，配置完之后一下载就自动初始化了。这种情况下所有的集成和初始化全部用配置文件来做，真正做到零代码的集成。

从一个架构师的角度，我认为这样成本会降得特别特别低。因为所有的初始化和集成，都是通过配置文件来做。当有版本升级的时候，改一个配置就可以了。当我需要一个新的策略的时候，也是改一个配置就可以了。这种情况下不管做项目交接也好，或者对下面人培训也好，整个沟通的成本都特别低。

然后是统一的使用方式，这一部分我们也希望做到零代码，这个听起来好像不太可能，但实际上我们已经在往这个方向努力。比如自定义事件上报功能，点击一个按纽后上报一条信息。正常使用的情况是在代码里加点击事件，加一行代码就上报了。现在是通过配置来做这样的事，配置点击什么按钮，上报什么事件，集成之后点击按钮之后自动上报一个新事件，通过配置的方式来做到自定义的上报或使用，零代码使用。

所以我们希望使用方式也能做到零代码，整个过程都做到零代码，通过配置去使用，这是我们的目标和愿景。这样才能真正为移动开发者提供移动开发即服务的产品，以后移动开发者对于所有周边的事情，都不需要去关注了。只需要关注大家都能看懂的配置文件，以后的项目交接或者项目培训都很简单了，之后希望可以做到这种全站的无代码集成使用。

我们希望提供一个一体化的闭环体验。上图是我们即将推出的一些功能，比如分享和广告监测。我们经常需要通过分享来扩大影响力或者拉来一些新的用户，正常的分享SDK只提供了分享功能，但我们提供分享功能是希望分享之后还能监测每一个阶段，比如用户是否点击，让每一个环节可追踪可优化。广告监测主要是因为现在获客成本越来越高，我们也经常做一些广告拉一些新客户进来。但每一个广告的效果其实很难做到精确追踪，我们也希望有一个广告监测的功能，帮助开发者监测每一个广告的效果，帮助大家省钱。

第三是计算，第四是数据库。我们希望优化中国移动开发的方式，不再和后台强耦合，直接通过云端去构建整个应用，从demo到上线、运行、上量，我们的计算服务都是可用的，提供的是弹性的能力，现在能用上线之后也能用，数据库也是。我们希望通过这些产品打造云端一体化的产品闭环体验，从开始的计算、数据存储、文件存储到后面用户的分析、广告的监测，用户的推送和活跃的运营、支付，一切都在一个平台上可以做到。从研发、测试、发布、运维到运营，希望我们的移动开发平台能成为整个开发生态闭环的产品。

Q/A

Q：刚才听到最终的方案是有一个控制台，通过一些配置，下一个包，集成到比如说移动应用里面，直接就可以实现你的无代码。但假设我们在开发过程中，或者说产品不断迭代中可能改需求了，比如某一个配置我想改了，但那个SDK已经集成到APP里面了，有什么方式可以去解决这个需求吗？

A：我们在一开始设计的时候已经考虑到了，你可能在不同的阶段，都会使用我们的功能，甚至去优化我们的一些功能。这种情况下怎么办？第一，我们提供的是一个通用服务，你的需求可能变了，比如在推送的时候一开始需要对帐号进行推送，之后需要对标签进行推送。这种变更不应该涉及到通用服务这一部分，我们应该能适配你们的需求，你们的需求达不到，那是我们自己做得不够。第二点，你的配置已经集成到服务中了，如果需要一些变更，修改配置文件就好了。我们希望在任何阶段任何时候使用我们的服务，不管更改也好、重新使用也好，或是优化也好，我们都应该用一个最便捷的方式去帮助你去做这样的事。

Q:是不是跟可视化埋点一样？

A：有点像，我只是举个例子，希望后面用配置的方式去使用我们每一个服务，从开发到后面整个的使用全部用配置文件实现。