移动app快速开发的几点经验

Posted 2020-12-21

移动app快速开发的几点经验

导读：GIAC大会期间，来自mob的技术专家余勋杰给大会分享了 MobSDK 用户接口演进，就此机会，Keep技术研发部移动端首席架构师吴建军代表高可用架构对余勋杰老师进行了访谈。让我们大家一起看看余勋杰老师的独特见解。

余勋杰 Mob移动开发者服务平台/MobSDK项目总监 超过8年android开发经验，参加过多个 LBS 项目、流媒体项目和社会化模块项目，知名App“遇见”公司早期成员，在Android Java层和本地代码层均有丰富开发经验。现任Mob移动开发者服务平台技术副总监，主导MobSDK Android端的架构设计及实现。

高可用架构：MobSDK全面支持了移动APP开发，同时在不同领域也有不少的竞品，请问，您这边最大的优势是什么？

余勋杰：最大的优势主要是几个方面：

第一，我们更加全面。我们已经构建了一个移动SDK矩阵，有10多个产品，包括13个SDK以及另外一些垂直方案。我们的竞品一般只有一两个，一般情况下，应用可能会同时使用到多个SDK或者是多个工具。这个时候使用我们的方案，就会有更加统一的，比如说API、文档或者是一些应用规范。作为一个开发者来说，可以大大缩短他们的时间。

第二，因为这些都是我们自己出品的，所以比如说我在PPT里面说到的一些公共依赖更少。如果说你同时使用多个不同的竞品的东西，他们都会自己有一套基础代码，这样会导致你的包体积会明显变大。

另外，和多数的竞品不同，我们一直在努力推广我们的自动集成。从2018年开始之后，基本上都是自动集成的方案。我们的竞品最传统的是下载一个包，复制一些库进去，或者是像现在做得比较好的，比如微信，他们还会使用Maven的集成方式。但是就像我在PPT上说过的，可能之后的问题还是很多，比如需要反复参阅文档调整依赖库和配置，而我们有自动集成就不需要做这件事情了。

第三，技术支持。这是我们非常有自信，也是做得很好的方面，我们提供了7×24小时一对一的人工技术支持服务，开发者基本上可以在任何时候，通过几乎所有的平台，比如说QQ、微信、电话甚至是论坛，从我们这里获取所需的帮助。

高可用架构：管理众多的SDK的技术产品，您这边有什么秘笈可以和我们分享吗？

余勋杰：其实我们也并没有说在管理方面做得非常突出，归纳起来可能会有几点。首先是项目制，我们会为每一款SDK都确立一个独立的项目组，然后我们这些SDK产品就由这个项目组来进行，比如说设计、研发、迭代这样的一些工作。

其次，因为我们这边从好几年前就已经预料到会有越来越多的项目，所以确立了一套产品的项目规范。对项目的立项、设计、研发、测试和发布（在一些定制化的产品中，可能是交付）各个环节都做了很详细的约束。这样就可以尽量的规避比如说在研发或者是发布之后会出现的一些问题。

最后，多维度的产品驱动能力。一方面作为一家技术导向的公司，我们对内会提倡工匠精神，鼓励我们的产品、研发部门不停去打磨自己的产品，优化以及迭代。另一方面，我们对外提倡用户至上的精神，我们会要求技术支持和商务合作的同事，在做好客户服务的同事，还要积极收集用户对我们产品功能和服务的反馈意见，通过对这些反馈信息的梳理，形成我们新的产品方案，然后继续来推动我们我们产品的迭代。

高可用架构：使用MobSDK来构建一个自建的电商SDK投入的人力大约会是多少？

余勋杰：如果说要做一个电商APP，在我们这边会有两个方案可以选择。方案一是我们提供“APP工厂”这样一个解决方案，开发者可以直接在我们官网找到这个方案的入口，先选择“电商模板”，然后在我们的网页上添加一些应用的基础配置，比如说应用名称、开发者签名、图标等，就可以生成一个包括安卓端和ios端的APP。如果说以这样的方式产生一个电商APP，只需要几分钟就可以产生一个可以直接拿来用的电商APP。

不过多数的用户还是希望自己的APP和别人长得不一样，需要一些模板以外的定制化的功能。所以我们也提供了对应的电商SDK，基于这个SDK，开发者可以在客户端实现商品的展示、购买、支付、物流查询等等的功能，也包括可以在我们的开发者后台对商品类型进行配置、发布，还有优惠券、物流管理等。如果说基于这个SDK来做，则可以在一两天的时间里，就把电商的功能集成到自己的APP当中去。

高可用架构：针对现在特别火的短视频，它会有SDK吗？

余勋杰：如果说像快手、抖音这样的一些直播的平台，我们在直播刚刚出来的2016年时，就做了这样功能的产品，它包含了直播、送礼物、聊天以及相互关注这样的功能，不过后来因为一些政策和市场发展的因素，我们发现这个项目的市场需求量并不是很大，所以就没主推这款产品，不过这个功能还是有的。

另外是像录制一些视频，然后把它发到一些社交平台上的功能，这个我们在更早的2015年，那个时候游戏录屏领域很火，我们也做了一款对应的产品ShareREC，这款产品适配了现在市场上主流的游戏引擎，比如说Unity3D、Cocos2d-x等，甚至在安卓端还可以做到直接脱离任何一个游戏，录整个系统。录制时可以选择不同的码率、分辨率来完成录制，录制后也可以对视频进行编辑。但是因为之前带宽跟资费比较贵，所以这款产品后来也并没有很好的市场，当然也有一些成功的案例。但是随着未来5G时代的降临，带宽的提高和资费不断的下调，这款产品会更远大的前景。

高可用架构：作为一个APP的开发者，如何通过MobSDK来快速搭建自己的应用？

余勋杰：MobSDK不是一个IDE，所以我们并没有办法说基于MobSDK来搭建一个APP，而且一个APP其实也不是因为几个SDK累在一起就可以变成一个APP。一般想借MobSDK来做APP这方面的开发的话，就像刚刚说的还是有两个方案。

第一，基于我们的APP工厂，先进到官网APP工厂的主页，然后选择APP的类型。我们现在提供几个模板，比如社交聊天、新闻资讯和电商等等。如果想基于这样的一些模板来产生APP的话，就像刚刚说的，几分钟就可以搞定自己的一个APP，甚至都不需要开发能力。第二，因为这个还是基于模板的，一般应用都会有定制化的需求。如果想基于功能来使用MobSDK的话，我比较建议的是比如说需要社会化分享以及登录的话，可以使用ShareSDK。短信验证码的话，我们也有一个SMSSDK，这个可以提供短信验证码。如果说需要推送，我们有MobPush，它已经支持了基本上市面上所有的厂商推送，并且还支持智能标签、短信补偿这类竞品收费而我们免费的功能。最后我们还有应用内统计的产品Mob统计分析SDK，用于实现统计功能。

高可用架构：MobSDK对于APP的开发者来说，是不是可以比喻成云服务之于后端工程师。

余勋杰：有点类似，我们当时在打造产品矩阵的时候也是奔着软件云的目标去做的。MobSDK本身有几个层次的概念。最底层是我们十几款的SDK，涵盖了移动开发大部分的领域，它们的定位就有点像云服务器，提供了最基本和最重要的一些功能。

在这些SDK之上我们有另外一个概念，就是“SDK+运营赋能”的概念。我们在SDK当中引入了大数据和运营能力，会输出一些垂直方案，比如说刚刚说到的APP工厂，或者是我们的增长变现或者是Mob游戏解决方案类似这样的一些解决方案，后面还有更多，这些就像是云服务器加上附加的一些增值服务。

最后是除了SDK和解决方案这样的通用服务之外，我们也在逐步开放一些定制化的商务合作。现在很多云服务也是提供定制化服务的，我们也提供类似的概念。这种定制化服务我们基本上是有一对一的商务和APP开发者去谈，然后我们会成立类似虚拟项目组去帮助他们实现他们要的一些功能。

高可用架构：在支持开发者方面，您这边都做了哪些工作？

余勋杰：主要是三个方面：

一、产品方面。我们在不断优化和统一我们的API，使之越来越容易使用；不断地简化我们的开发文档，力求让用户一个短小的网页中就能掌握我们产品的核心使用方式；不断提高产品的自动化集成能力，免去用户在SDK集成时的各种机械劳动。
二、技术支持。刚刚说到7×24小时，一对一，多渠道的人工服务，这也是对开发者最好的支持。
三、商务合作。无论是通用的功能或者是定制化的功能，我们的商务同事都会直接和开发者进行沟通，在必要的时候也会把我们无论是技术支持还是研发的同事拉进讨论组去帮他们解决他们可能需要的一些功能和需求。

高可用架构：通过您这边在GIAC的分享，也是想了解一下关于您这边工程师团队文化这一块您是怎么理解的？

余勋杰：最近这一段时间我们也在构建自己部门的文化。我们的文化是分两个层次，一个是适用于所有员工的通用文化素质、一个是区别于不同职能的专业技能。在通用文化素质上，我们强调：同心协力、迎难而上、开拓创新和互补当担。而在专业技能上，比如在研发岗位上，我们确立了：时间控制、产出质量、专业能力和项目规范4个方面的指标。这些文化和指标会引导我们的员工朝着我们期望的阿尔法狼精神发展。

在研发岗的日常管理上，我们为大多数的岗位分配A/B两个角色，一方面是相互学习，另一方面也是相互监督。以这种方式进行管理，可以在很大程度上提高代码质量，降低重大bug的几率。另外，我们也鼓励主动学习。所以每一个季度都会为每个研发人员设定一个为期一周左右的研究课题。员工完成课题后，需要撰写研究报告，并在团队内部对报告进行演讲。不仅提高了研发人员的专业技能，也提高了他们的演讲能力。

至于绩效考核，由于我们采用了职能线和项目组相结合的管理方式，所以每个人的考核也会有两个不同的指标。在职能线上，团队主管会考核下属的专业技能和规范落实情况；在项目组内，项目经理会考核组员对的业务完成情况和贡献程度。

转载本文请注明出处，技术原创及架构实践文章，欢迎通过公众号菜单「联系我们」进行投稿。

高可用架构

改变互联网的构建方式