mqc.yunos.com_个人页

告别加班 移动APP研发提速利器之EMAS跨平台解决方案

又到周末了，大家手头的工作完成的怎么样啦？还没有完成的继续加油鸭！想要告别加班，给大家推荐一个移动APP研发提速利器。本文根据2018杭州云栖大会移动研发平台EMAS专场，阿里巴巴产品专家言沛的主题演讲《移动APP研发提速利器之EMAS跨平台解决方案》整理成文。 在座各位应该都是移动APP研发负责人，大家平常工作中最关心的一点是研发成本。就像我之前在群里看见有人提问说开发一个手机淘宝首页大概要多少钱，计算钱这个问题有点复杂，会受你聘请的程序员工资多高的影响，所以我把这个问题改一下，改成开发一个手机淘宝的首页大概要多少工时，大家来猜一下？我结合自身的经验和请教了相关同事，如果只是做视觉还原的工作，大概也需要五天。 那有没有再快一点的办法，来实现页面的开发？大家第一个想到的应该是H5的方案。没错，因为H5方案开发一次可以在多端投放。而且由于它技术框架的原因，单端开发速度也比APP快。我问过专业的H5前端工程师，他说开发一个手淘首页只要1.5天。 但是，我们知道业务方对移动APP的研发诉求不仅仅是快，而是著名的“既要、又要、还要”，就是既要迭代快，又要性能好，还要用户体验顺畅。H5方案可以满足第一点的需求，但是它有它无法回避的劣势。举例来说对内存的控制比较差，当一个列表比较长的时候会占用比较多的内存。第二是页面的流畅性比较差，直观的感受就是你的手指在屏幕上快速来回滑动的时候，屏幕响应速度慢，技术上来说就是帧率低。第三是动画流畅性，特别是大区块中，做动画会有卡顿的感觉。有没有一个办法既能保持H5的优点，又能克服那些缺点？答案是有的，那就是Weex。 我介绍一下Weex的原理。Weex可以把前端编写的代码编译成JS Bundle，通过服务器下放到手机，最关键的是在iOS或者安卓环境下是采用Native渲染。如果用Weex实现手淘首页，大概也需要1.5天的样子。大家可以用手机淘宝扫一下屏幕上的二维码，体验一下用Weex简单拷贝的手淘首页。 传统移动APP开发的时候其实还有一个痛点，就是版本迭代的问题。因为APP的迭代和更新是依赖用户来不来更新，很难保证用户都愿意及时更新你最新的版本，所以造成线下版本碎片化比较严重。Weex天生支持动态更新，可以随时发版，可以保障每次打开都是最新的版本。 刚才介绍了Weex各种优点，到底有哪些APP使用了Weex的技术？我相信这也是大家比较关心的。 首先，Weex诞生于手机淘宝。在这里分享一个小花絮，就是Weex技术在手淘落地的第一个场景是什么，落地的第一个场景就是“双十一”的会场列表，就是一堆全是商品的列表页。我们这个技术一上来就用在“双十一”的场景上，说明我们当时的开发对自己的技术非常有自信。 我们来看一下数据。双促会场从之前99%用Weex实现到最近100%用Weex实现；第二是行业导购，从之前小部分频道业务用Weex来实现也到现在的100%都用Weex来实现。行业导购业务包括有好货、买遍全球、每日好店等业务。如果大家熟悉淘宝，它们都是在手机首页上主推的频道业务。如果大家用过这些业务，会发现它们的体验做得非常棒，甚至你根本体会不出来它是否用Weex实现；第三是交易链路和基础业务，比如说店铺、淘宝、足迹等等，这些业务从之前完全没有用Weex来实现到现在大概有6个页面用Weex来实现。其实这些页面是非常底层、核心的业务，也可以用Weex来实现，没有任何问题。 除了手机淘宝之外，阿里还有很多其他的APP也用Weex实现，我在这里截取一部分APP的LOGO，大家可以发现大家平常在用的比较多的阿里集团的APP都基本上采用Weex的技术。我在这里想简单介绍一下飞猪。 飞猪有它自己的独立客户端，在手淘里面也有一个比较重要的入口，它的要求都已经不仅仅是跨端了，而是到了一个跨APP投放的需求。飞猪在之前的时候也是用H5来实现的，为了提高用户体验，所以他们针对H5的方案也做了非常多的优化。但是Weex的技术推出之后，飞猪同学体验到Weex的技术优势之后全面拥抱了Weex的技术，把之前H5页面纷纷转向Weex来实现。现在在飞猪业务里面，几乎已经很难找到用H5实现的页面。在这个过程中，他们也做了很多的技术沉淀，比如说Weex UI开源组件就是由他们的团队负责的。 Weex不仅仅是阿里巴巴的Weex，它也是apache上的开源项目。我这里截取apache项目里面的一些基础数据，包括star、fork、contributors。其实Weex这个项目做过一次代码迁移，从阿里巴巴的仓库迁到apache项目上，所以如果把这两个项目的数据加起来，肯定会比这个更多一些。同时，Weex也是阿里巴巴所有开源项目里面Star数最多的开源项目。 既然是开源的Weex，那么除了阿里巴巴集团之外，业界又有不少APP用了Weex的技术。这些APP都是在我们的Weex官网上自主提交的信息，我这里截取了一小部分。我觉得使用了Weex而没有提交的APP，可能也不在少数。 刚刚讲了各种Weex的优势，这么牛，有人想问Weex到底还有什么不足之处？就像人无完人，Weex也有一点点不足的地方。Weex支持的样式和语法是满足W3C标准，但是并不是所有的W3C标准都支持，所以这就有学习成本。以我自己为例，从小白开始学习到上手简单的页面开发，大概需要花我7天的时间。但是7天之后，就可以体验全新的移动APP研发模式。 当你学会了 Weex 这个技术，也想用Weex开发自己的APP的时候，你会怎么做？如果按照Weex的官网教程下来，可以构建出你的APP，但这可能会花费比较长一点的时间。而且我们知道生产环境下对一个APP的研发要求，不仅仅是在你本地的电脑上构建一个包就可以了，所以针对这种场景的完整解决方案，我们的EMAS跨平台产品就此诞生。 EMAS跨平台产品矩阵大概包括开发者社区、IDE、商业组件、DevOps，应该说覆盖了从研发、调试、测试、发布、运维完整的生命周期的管理需求。 我们首先看一下开发者社区。做过研发的都知道如果我们要学习掌握一门新的技术，仅仅是文档还是不够的，最好是能看到一些前人的经验总结以及丰富的生动的demo供我参考。所以我们在Weex官网基础上补充了它所不具备的东西，主要目的是帮大家降低学习Weex的成本。开发者社区，有后续取代现在官网的计划。 然后是EMAS studio，这是我们推出的第二代Weex IDE，基于VisualStudio Code定制开发，在这里你可以完成新建项目、编码、调试、预览等等，所有的功能都在IDE里面完成，就不需要IDE和浏览器之间来回切换。特别是调试功能，通过手机扫IDE里面的二维码建立debug服务，可进行单步调试，对定位端上遇到的问题是非常有帮助的。 当我用了专业的开发者工具，以我的经验来看还有一个点比较影响我开发业务的时间，那就是有没有组件可以供我使用。Weex内置组件以及Weex UI开源组件可以满足常规业务的开发，但深入到有行业特征属性的时候，比如说手势密码或者是雷达图等就有所缺失了。所以我们把一些具有行业特征属性的组件封装在一起供商业客户使用，帮助大家提高用Weex实现业务的效率。 刚才提到了社区、IDE、组件，都是为了帮我们快速用Weex实现自己的业务，但我们最终想要拿到的是什么？可不仅仅是一个Weex的代码或者是Js Bundle，而是一个稳健的实实在在的APP。跨平台DevOps就可以实现这个工作，在这里可以实现DEMO生成、云构建、灰度发布、正式发布、测试等都可以在DevOps上完成。 如果从功能点上划分，大概可以分成四点：业务管理、代码监控、产品发布和监控运维，每一项又包含很多的小点，我列在PPT上了，不一一展开念。我想具体解读几个亮点。首先是我们建议业务按照合理的逻辑进行拆分，按模块管理来降低业务之间的耦合度；第二，利用云构建能力，对APP进行持续交付；第三，利用我们所提供的预加载能力，可以把资源提前加载到手机里，提高页面秒开率，提高用户体验；第四，通过后台监控平台来看APP运行状况，做到对代码质量心中有数。 前面提到了这四个产品，如何把它们串联起来来完成APP的研发？为了给大家一个更加直观的感受，我画了这张图。图里面绿色代表了研发流程，蓝色代表了我们所提供的产品。总结来看，EMAS Studio、开发者社区和组件都是围绕在Weex端，帮助大家更快用Weex实现自己的业务。在native层我们可以参考devops上生成的DEMO工程，稍微修改下，就可以满足你自己的需求，这一块的开发工作量非常少，最后在DevOps上完成构建、发布。 刚才介绍了产品，我们再来讲一下有哪些客户使用了我们的跨平台产品。这里出于对客户隐私的保护，不具体讲哪个APP。可以看到覆盖餐饮、交通、金融、能源、地产和教育行业等，行业的覆盖度还是比较广。有一个新零售的客户要对他的超级APP进行重新开发，大概包含了零售的业务提供、互动、短视频、社交等等很多的功能。他们最后技术选型采用Weex去实现，再配合跨平台提供的能力，大概一共用了6个开发，花了大概三个月的时间，完成了120多个复杂页面的开发。而这时间不仅仅是开发，从学习开始一直到发布。另外，因为Weex所做的页面也可以以H5的方式打开，所以他们顺便还做了公众号项目里面10来个页面的改造升级。 前面讲了很多Weex的优势和对weex开发的支持，那我们的跨平台仅仅是Weex吗？答案肯定是“不是”的。我们深谙行业里面还有很多业务是用H5来实现的，所以我们后续会推出兼容H5的方案，第二是最近比较流行的Flutter方案，我们也是在学习和研究之中。应该说对未来主要流行的跨平台的技术方案，我们都会保持密切的关注，在合适的时候推出相应的产品。

移动APP持续交付系列之云构建价值分析

现状企业A：小APP，Android、iOS研发各三人；大APP，Android、iOS研发各10人。CICD通过部署一台jenkins服务器 + 一台Android 构建机器来完成Android的APP构建，iOS构建完全依赖开发本地环境。企业B：3个APP5个研发同学，5台服务器年成本一万左右 ，代码规范比较差导致质量不好企业C：十几个研发，五六台服务器。 寻求一站式交付平台可以看出：在企业内部为了支持APP构建需求一般会部署一台jenkins用作构建任务管理，一台以上的linux服务器用于Android APP构建，视实际使用情况量级较小的iOS APP一般在本地完成构建，量级较大的APP会有单独的构建机器。成本中小企业在APP构建部分的成本主要包括三个部分： 机器成本用途 数量配置价格(元/年)jenkins服务器 14C8G+50G存储3830.10Android构建机器 14C8G+50G存储3830.10iOS构建机器（自行采购）1 2.6GHz 处理器1 TB 存储容量 mac mini4945.00/4 （三年使用寿命来均摊成本）OSS 存储200G0.12元/GB/月 * 12 maven、cocoapods类库仓库总计9184.45以最小资源消耗来看至少 1台jenkins + 1台Android + 1台mac ，在业务量偏大的场景下可能需要更多的资源来支持构建、maven仓库、cocoapods仓库等。 人力成本人力成本主要体现在以下几个方面： jenkins服务的搭建、日常维护、升级、异常处理Android编译机器的环境搭建、维护、Android SDK升级等mac mini环境搭建、维护，xcode、cocoapods、证书等升级维护管理构建异常等特殊情况下的问题排查、解决简单测算下一名Android 研发薪资 13263/月* 12 = 159156 (平均薪资数据取自猎聘网)假设平均花费0.5个Android研发资源 159156 * 0.5 = 79578 元/年 时间成本中小企业团队没有足够的资源进行构建效率提升，使得每次构建相对消耗时间较长。无形中消耗了更多的时间成本。 这部分目前没有能直观的量化数据进行成本核算。总计成本： 9184.45 + 79578 = 88762.45 元从成本结构观察，支撑APP 构建的成本主要在于人力成本的支出，而且这部分的工作是相对分散和繁杂的，也相对比较隐蔽不容易直观体现和测算。云构建云构建是指通过云技术提供Linux、MacOS的构建服务，为用户提供简单接入、低成本运行、高效的构建能力。优势提供编译缓存、并发构建等能显著提升构建效率的加速能力提供环境、网络隔离，稳定的编译环境按需获取资源进行构建，根据实际的构建需求动态调度实现资源的扩展和缩减根据构建日志智能反馈构建失败的排查建议能够无缝对接代码扫描、APP自动化测试、APP灰度发布等能力，支持持续集成和支持交付总结随着云计算概念的普及，大家对IAAS已经有比较多的认知。构建是研发基本的需求，通过云服务既可以降低机器成本，又能有效降低开发者在构建服务的资源投入，将精力和时间更多的关注在业务中。

数字化转型 移动化先行 云栖大会上发布了哪些移动研发新利器？

随着企业使用互联网技术的不断深入，企业在产品研发、供应链管理、市场运营及企业内部的场景当中，生产效率得到大幅度提升。随着移动互联网技术在社会层面深度普及，移动设备的普及性使得企业成为数字化转型的最佳载体。本文以2018年云栖大会杭州站移动研发平台EMAS专场上，阿里巴巴高级技术专家泠茗的演讲整理成文。 在去年的云栖大会上，我们正式发布了移动研发平台EMAS。通过一年时间的发展，我们完成了整个阿里集团移动端的基础设施对外商业化的输出。我今天的分享会分为四个部分，先整体介绍EMAS平台的全景情况，然后会发布最新的围绕移动网络场景开放产品矩阵，最后会分别介绍超级App和智能运营的解决方案。 随着整个数字化进程不断向前推进，互联网技术也开始从传统的消费级市场向企业级市做深度的渗透。工业级也好，商业级也好，也是把数字化转型作为支撑企业下一个企业发展核心驱动力。2017年全球排名前十市值公司当中有7家是互联网公司，所以互联网公司在整个消费级市场的数字运营的经验，应该说也是传统企业进行数字化转型很重要的参考。 我们今天仔细看一下阿里巴巴的数字生态模型，其实呈现出非常典型的四层折叠式的生态，不管是起家的电商业务还是新兴的金融业务也好。第一层连接层，手机淘宝、支付宝作为企业连接消费者终端最重要的连接点，包括企业构建新型的面向消费者终端交互模型。第二层，面向消费者所提供的海量的产品和服务。第三层数据层，基于海量的产品、服务，我们所沉淀的核心数据，包括用户画像、商业画像、信用体系、风控体系，如何用这些数据进一步拓展业务的边界和业务的价值。最底下一层是基于云计算、大数据支撑上层业务的弹性扩展平台层。 进一步看整个阿里巴巴的技术架构模型，可以发现阿里巴巴技术架构模型和我刚才所提的四层折叠式数字生呈现相生相伴的架构模型。包括第一层的移动中台——移动研发平台EMAS，包括业务中台，包括数据中台。业务中台承载商品中心等通用系统，数据中台承载通用的实时、离线计算平台。最底下是中间件所构建的平台层。在这样一个庞大的数字生态图谱当中，连接层扮演什么样的角色？数字化运营前提是数字化管理，帮助消费者和企业之间建立向性的交互模型。连接层在这样一个庞大的数字生态图谱当中，其实就是扮演这样的角色，是企业用户流量的核心入口和业务载体，所以这是数字化转型的第一步。移动研发平台EMAS核心目标也是帮助企业客户完成整个业务连接层的智能化和数据化，能够帮助企业为下一个阶段的业务增长，奠定相应的业务模型和相应的技术支撑。 这幅图是整个移动研发平台EMAS产品的全景图。EMAS划分为五大部分：第一部分是开发套件，这一层沉淀客户组件和终端组件，包括UI图片组件、路由组件、网络库等，还包括跨平台的开发框架及H5容器。基于开发套件，包括企业开发人员帮助完成开发。第二层是基础架构层，我们开发了大量和移动APP和业务结耦的移动基础设施，像数据分析等一系列和业务结耦的基础设施，通过基础架构这一层开放出来。第三层是研发支撑层，这一层我们围绕整个APP的全生命周期提供了持续交付的工作体系，帮助企业的研发人员能够一站式原则代码的托管、代码扫描、持续构建包括移动终端的测试，再到线上的灰度发布、生产发布及线上的运维、运营，通过整套持续交付工作流体系，来完成移动APP的全生命周期的托管和管控。最底下一层是工程理念层，我们希望通过EMAS平台，不仅仅是把阿里巴巴所沉淀的一系列的应用的基础设施开放出来，我们还希望把阿里巴巴沉淀的一系列的软的业务方法论开放出来，包括我们的双平台的研发规范，包括我们如何定义一个APP是一个用户体验优秀的APP，包括APP发布的性能以及质量、指标基线等，包括不同阶段不同过程的企业研发团队的组织架构应该如何构建，阿里巴巴在这方面有非常多的经验可以传递。最顶上一层是解决方案层，我们希望基于刚才介绍的产品组合以及业务方法论，我们希望能够帮助企业业务部门同学解决一些热点场景下的痛点，比方说怎么在移动场景下做智能运营，包括我们怎么样做移动场景下的营销等等，这是整个EMAS的产品全景图。 随着EMAS正式对外发展，我们也与非常多的企业建立了相应的连接，我们也希望EMAS能够真正帮助企业带来和传统研发不一样的东西，能够为企业带来真正的新的价值，包括新的体验。 如何基于AI、3D、短视频等新兴的移动技术，帮助企业构建新型的前台体验，帮助企业前台业务转型升级。包括如何基于我们的开发框架、开发套件以及我们的基础设施，帮助企业提升业务研发的速度，真正降低、压缩整个产品的周期50%以上。包括新的模式，面向近十年打磨的一整套APP持续交付体系，我们怎么样帮助企业重构它的传统的产品研发、运营、运维、测试等不同职能团队之间的协同模型，真正帮助企业提升研发运营效率500%以上。包括新的增长，基于我们新的产品的交付模型以及我们新的产品的运营模型，我们怎么样帮助企业去重构它在消费级市场的作业模型，能够真正为企业下一个阶段的增长带来新的动能。这是我们希望EMAS能够带给企业不一样的东西。 介绍完EMAS，接下来看一下我们这个季度开放的围绕移动网络领域，新的产品矩阵。移动业务是一个非常重在线体验的业务形态，所谓在线就是对网络有非常强依赖，移动网络相关的基础设施强弱与否与移动体验息息相关。底细的图是阿里巴巴移动网络基础设施架构图，在集团内部，所有的APP全网流量会划分为两条主干，一条主干直接对解CPA体系，另外一条主干对接移动网络接入体系，用来承载全网动态网络请求。基于最佳实践及业务经验，我们今天开放了四个和移动APP紧密相关并且非常关键的基础设施，包括移动API网关、消息推送，其实我们的消息推送在公共云场景开放了一段时间，我们今天也完成了消息推送专门化、私有化对外输出的能力。还包括移动端配置管控的服务，以及整个移动网络统一接入的核心引擎通道服务，接下来一起看一下几个新品的适用场景及产品特性。 首先是移动API网关。随着微服务化进程不断演进，企业遇到的问题就是如何对后端的服务进行管控。企业的业务场景下，可能会有海量的业务场景，可能会有不同的研发团队进行后端服务的开发，甚至有时候是请供应商来做相应的开发。所以不同的后端系统，整个基础架构的实现也好，包括它的通信协议也好，其实都是各不相同的。另外一方面，随着微服务化进程进一步往前演进，企业后端力度拆分非常细。如果通过终端设备跟微服务进行交互，对终端设备而言网络的交互会非常重，是非常不合理的。另外对所有的业务请求，其实都是一些相同的工作，包括对请求的鉴权、限流、加密、加速等等，所以我们需要从API网关一层完成全网关流量的监控。像鉴权、限流等工作，都要通过API网关承载，再把固有的流量放到后端微服务系统当中去。同时围绕API一键编排和服务治理，也通过API网关来完成，节省研发成本。我们的全网动态流量都是到移动API网关，同时API网关也支持通用的RPC框架，其后端业务系统进一对接。性能上适配移动网络场景下的网络优化及连接等环节，我们都有专门的网络专家团队进行优化。在架构上，整个API网关架构也适用阿里巴巴集团“双十一”体系下的前端接入的架构，意味着我们可以非常平稳支撑像“双十一”零点脉冲流量及一级并发的连接。在安全方面，我们也是基于1.3的框架，实现自定义的加密算法，对比传统的HTTP算法也有大幅度的提升。我们可以帮助企业实现前后端架构的分离，实现架构体系，同时在可运维性以及稳定性方面，也能够得到大幅度的提升。 第二部分是远程配置服务。企业的终端研发人员经常碰到的需求场景是需要通过实时变更后端的参数，来实现APP终端行为以及它的外端的实时变化。像现在的我们需要基于用户的画像以及用户在这个时间点在终端一系列的点击、浏览、搜索行为进行动态的商品或者是页面的相应投递，像一些终端开关等场景，如何系统化对这些配置进行组织和管理，并且保障这些配置下发的及时性和精准性，这就是今天远程配置服务所关注的环节。有的同学可能会说这不就是一个很简单的配置下发推送的场景？如果用一句话形容它的所有工作确实是这样的场景，但如果细看场景细节，就会发现里面有很多的细节需要解决。比如说配置下发的时候，如果你采用推送模式，你就要专门为远程配置连接一条长链接的资源。另外随着终端体量的不断增大，服务端进行一次全网的配置下发所需要的计算成本也非常高，会直接对配置下发的即时性带来一定的挑战。还有是远程配置本身也需要设计非常帮的ACK的算法，同时还需要设计非常复杂的补偿机制，一旦首轮配置下发失败如何进行补偿。 假如我们是采用直接拉取的模式，这时候如何进行拉取的间隔设置也是非常讲解的，如果你间隔时长设置比较长，意味着整个配置下发的即时性无法得到保障。如果间隔时长设置得非常短，远程配置对后端服务的访问压力是非常大的，并且可能80%、90%以上的配置查询可能都是一些无效的访问，带来的资源浪费非常大。所以在远程配置场景，我们也是选用优化好的推拉模型。 面向全网全量的模型，我们采用主动拉取的模式，但是主动拉取又不是传统的模式，我们会跟移动API网关进行结合。大家知道在移动场景下，API网关访问请求非常高。所以我们会把配置信息附带到API网关当中，以确保下发的即时性。 针对定向配置下发，我们依然会采用推送模式，在推送模式推动整个长链接。另外围绕配置的版本数据、索引数据及配置的内容数据，我们进行隔离的管理。版本信息会放在服务端进行管理，配置的真实内容信息会放到CDN上进行管理，以进一步降低服务端进行配置索引计算的成本，来提升下发的即时性。同时通过CDN，能进一步降低配置内容拉取带来的带宽成本。这是远程配置服务所做的工作。 第三部分是通道服务。刚才提到了移动API网关也好，远程配置也好，消息推送也好，非常重网络依赖的基础设施对底层网络的诉求是如何高速、稳定、安全地把数据发送到B端，这是通道服务所关注的环节。我们希望通过通道服务，正式把阿里巴巴体系内的面向移动场景下的四层接入网关服务开放出来，企业研发人员可以基于此进行上层的研发，甚至进行自己的API网关、消息推送等场景。像流量调度、负载均衡、长链接维护等内容，都交给通道服务来完成。同时，通道服务会开放出统一的客户端网络SDK，也能够进一步降低企业客户端研发人员网络研发的成本。有同学可能对移动API网关和通道服务的定位有一些混淆，移动API网关更偏上层，是七层围绕API的一键编排和服务治理的服务，通道更底层，关注网络细节，没有任何业务属性。 介绍完我们的新产品，接下来看一下我们开放的新解决方案。超级APP和小程序的概念，应该说是近几年整个移动业界最火的话题，当然这里也为超级APP的定义，可能有的同学理解上有一些偏差，我也称体量非常大上千万甚至上亿的APP才能够叫做超级APP，这个理解有点偏差。我们现在对超级APP的定义，是在于内部定义。传统的移动研发模式，可能会把垂直场景的诉求演化为APP的方式进行承载，包括APP可能由不同的研发团队、不同的供应商实现，整个系统实现和技术架构都是用不一样的方式。导致的结果是整个系统的实现，你的流量也好，你的数据也好，你的规范也好，全部都是割裂的，烟囱式的，不利于后期整体的运维、流量的运营及业务的联动。而这一类型的场景，其实我们通过小程序的方式来承载是非常合适的，也就是今天有大量的企业人员在问能否帮我构造一个类似像淘宝、支付宝、微信小程序的框架。所以我们今天这个超级APP的定义，其实是说超级APP是一个能够承载不同业务场景下的小程序的小程序。超级APP的目标，也是真正帮助企业实现统一的流量入口、统一的运营策略、统一的业务管控及统一的研发规范，真正帮助企业实现流量的聚合及内部研发效能的变革。 要实现这样一个超级APP解决方案，我们会遇到什么样的技术挑战？主要有软硬两个维度。要有这样一个超级APP，我们要有一套研发工具和研发规范，来帮助我们约束不同场景下小程序子应用对接到我们的超级APP体系当中来。刚才提到硬的一部分，我们提到需要一整套的研发规范，来帮助我们现阶段传统的组件化的APP向一个应用化的APP架构模型过渡。我们这里也开发了统一开发套间，包括统一的UI图表、脚手架，能约束不同的研发团队和供应商在统一场景下进行小程序应用的开发。第二是提供多栈溶剂，提升APP渲染性能，构建一个优雅可拓展的小程序。第三部分是围绕APP底层执行引擎，我们提供相应的高性能技术组件，包括网络库、图片库、缓存、路由框架等等，这也是整个APP运转的核心引擎，与整个APP终端的用户体验是息息相关的环节。 刚才提到的是技术硬核，在工程软核也需要一整套研发规范，来定义整个APP小程序研发运维的范式，包括统一的DSL，帮助企业来完成整个代码质量的审核以及业务的管控，包括统一的通信协议，来定义桥接层的通信标准，来完成整个API的管控和扩展，包括统一的发布基线，围绕APP的用户体验以及发布的性能、质量、基线如何来量化发布标准，包括统一的环境管控，如何来确保整个运行时小程序是相互隔离的，包括在运行时APP的稳定和安全如何来确保。包括小程序的持续交付体系，如何建立统一的小程序生产流水线，确保不同的研发团队、不同的供应商在你的研发流水线上产出的小程序子应用，它是围绕用户体验还是围绕质量、围绕性能，都能够在一个统一的基线上，不会有太大的偏差。通过技术硬核和工程软核两个维度，帮助企业真正实现自己的超级APP。 最后一部分解决方案是智能运营解决方案。熟悉EMAS的同学应该清楚我们陆续在公共云和专有云场景开放了移动数据分析服务，能够帮助企业人员暂时完成数据的埋点、存储、上报及计算和展示的一站式数据管理的平台。如何基于这样的数据工程平台，进一步挖掘这些数据背后的业务价值？这一点，应该说是整个数字化运营最核心的课题。 淘宝也是业界最早开始践行数字化运营和精准化营销的业务场景。基于我们非常强大的数据工程平台，我们可以完成实时的海量的终端设备数据的采集以及云系的计算，同时基于行业知识模板的输入，可以完成相应的数据清洗、数据加工以及建模，这是在离线时我们所完成的数据训练过程。在APP运行时，基于刚才所提的强大的数据工程平台，我们能够支持海量的设备实时录制的反馈，同时基于我们在离线时计算出的数据模型，能够构建相应的精准化营销、个性化推荐的一整套体系。基于这些的系统，我们可以在一些业务场景进行相应的精准化运营，包括千人千面，可以基于用户历史浏览信息、基于用户在当前APP上实时浏览、点击及搜索行为，预测用户购买预期，然后投递相应的商品给用户。包括在一些非支流场景，我们可以看用户点击、购买时间，来进行物品的展示。包括定向运销，我们可以基于用户标签进行相应的匹配，针对不同人群在某一个特定时间点触发之后，进行定向相应商品的推荐。包括我们可以建立商品定价及销量之间的模型关系，来进行智能选品和智能定价体系。通过一整套精准化营销的解决方案，我们能够帮助企业业务人员闭环完成单个流量完成的运营周期，从流量的拉新到流量的触达再到流量的变现，大幅度提升企业流量变现的效率。在今天这个论坛，我们的资深技术专家也会位大家分享阿里巴巴在数字化时代我们的智能化运营、精准化营销的最佳实践。

官宣 | 移动互联网+智能运营体系搭建=你家有金矿啊！

每个企业都有许多的数据，但能否将数据转化成商业价值，是企业非常关心的问题。阿里巴巴曾自嘲是一家坐在数据的金矿上啃着馒头的企业，前几年集团积累了很多的数据，但这些数据并没有真正应用起来，受限于几个原因，比如大数据的技术框架还不成熟，运营团队对数据应用的意识还不是很强，但今天，数据在阿里巴巴的应用范围已经越来越广泛。 本文根据2018年云栖大会杭州站移动研发平台EMAS专场上，阿里巴巴资深技术专家元绰的演讲整理成文，介绍面向移动互联网时代的智能运营体系搭建，主要分成三块内容：第一，智能运营的使命和典型应用场景；第二，个性化推荐系统的架构；第三，AB在智能运营系统中的应用。 一、智能运营的使命和典型应用场景 衡量一个智能运营系统做得好不好，目标非常明确，就是看能不能帮企业实现数据的增长，因为增长是企业最核心的诉求。 要实现企业智能运营，首先要进行数据运营闭环的建设。传统的BI，收集数据，给老板产出报表，让老板做决策，但智能运营系统，最重要的是把数据应用到实际业务场景中，形成数据闭环。收集数据，通过模型的训练转换成系统的预测能力，运用到实际业务场景中，最后把用户的使用数据反馈给我们的系统。经过几轮迭代，整个系统的预测能力会越来越强。 企业希望提升业务结果，业务结果的提升依赖于平台上的用户对我们的认可。EMAS的业务统计模块可以承担数据采集的工作，了解了用户的行为，机器智能的作用就在于将用户的行为数据转换为企业的运营行动。 具体的流程可以分成这么几个部分：首先基于原始数据，以新客为例，根据用户对冷启动阶段的热门数据的点击情况，对用户进行第一次打标，我们大体识别该用户属于什么样的类型；其次，我们做尝试性推送，比如资讯或者产品，用户根据我所推送的资讯或者产品，会有相应的点击行为，经过几次交互，机器对该用户的理解会加深。最后，经过用户跟平台的多次互动后，企业配合相应的运营策略，比如促销，转化效果就会有比较明显的提升，这是智能运营系统的基本流程。 我们对用户的全生命周期理解，是从新客到老客以及老客帮你做传播这一整个阶段，时间周期还是比较长的。针对一个新用户，你直接把希望他下单的信息推送给他，效果往往不会特别好。所以必须要对用户整个生命阶段做一些细致的分析。 智能运营的三个典型的应用场景： 第一，千人千面。淘系在PC时代也做过推荐相关的工作，但效果不好。但到了无线时代之后，个性化推荐的效果就提升明显，源于用户行为发生了很大的变化。无目的性，碎片化，随时随地。我们能否将用户给我们的碎花片时间充分利用好，让我们的消费者一下子对我们的产品感兴趣，需要企业对用户要有非常深的理解和洞察。 第二，精准营销。营销活动前，分析所面向的人群，具体的定价策略，以及在这样的定价策略下的销量预测，这样企业就可以预先知道KPI的完成情况。 第三，智能选品。前面讲的更多的是，产品如何更多与用户进行互动，智能选品适用的场景是我们对目标客群有认知，希望触达我们原来没有触达到的那批用户。超市希望吸引年轻人，就需要调整货品结构，把年轻用户吸引回来。盒马、淘宝心选，是阿里做的比较好的案例。 二、个性化推荐系统架构 接下来，给大家介绍一下个性化推荐系统。个性化推荐在阿里巴巴集团这几年有很多的沉淀。以手机淘宝首页为例，很多地方都做了个性化，比如入口图，每个APP都有子频道，子频道的入口图大部分用的是设计师做的静态图，如果用子频道的数据跟用户做个性化匹配，做千人千面的入口图，入口点击的转化会有很大的提升。 好的个性化推荐需要有哪些注意点： 第一，工程实现。个性化推荐，传统的实现方法，是截止某一个时间点给用户计算一个推荐列表，每天把这个数据刷新一遍。这样做的问题是什么？用户的数据量一直在增长，相应的存储成本也会随之增长，企业投入成本会很大。所以系统设计的时候需要考虑借助标签的能力。另外，每个人对标签对应的货品排序应该不一样，我们要增加二次排序，要保证每一个人的推荐列表虽然货品一样，但是顺序有差异。 第二，实时推荐。离线推荐主要是基于历史数据，实时推荐是基于当天的数据，当天给用户做推荐，转化率往往最高。但是对我们的挑战是什么？第一，必须有实时计算的能力，因为用户给我们的时间非常少，如果你延迟五分钟，基本上用户就流失了。第二，从算法角度来讲，必须要做一个平衡，你是基于历史推荐数据，还是当天的实时数据，到底哪个转换率最高，要做一个平衡。 第三，时间和空间。拿电商来说，羽绒服或者衣服都有季节属性，羽绒服适合冬天穿，电子产品有新老款，判断一个用户从来都只买新款，你就应该把新款推荐给他。另外，推送有时间衰减效应，不能一直推相同的货品。时间和空间是必须考虑的两个维度。 第四，发现性。大家在做个性化推荐的时候，模型基本上都是以一个具体的目标来做优化，但这里会有一个什么问题呢？会产生很严重的马太效应：第一，我的推荐依赖于我的历史数据。为什么给你推衣服？是因为你老是看衣服，模型判断推衣服的转化肯定是最高的，我推荐了，然后你又点了，这样又产生了一条历史数据，我发现效果确实很好，那模型下次推什么？肯定还是给你推衣服。但实际上每个人的兴趣爱好很广泛，我给你推的品类越来越窄，最后发现你的行为也越来越窄，这跟人的实际特征是不匹配。我们要在推荐系统里扩展品类的宽度。第二，推什么样的产品转化率最高？肯定是爆款，不管是金融行业还是其他的行业，爆款转化率最高，模型判断推爆款的转化比一般产品的转化要更高，导致什么结果？系统推荐的产品范围也越来越窄，这是很严重的问题。就是说给用户推荐的品类越来越窄，产品范围越来越窄。所以在整个模型过程中，去尝试推荐一些他可能原来历史记录里面不存在的东西，去做一些尝试性的发现，这是非常有意义的，否则对短期收益有好处，但是对长期收益有影响。所以转化率很重要，但是发现性更重要，品类拓宽会让你的业务体量越来越大，产品也一样，爆款之后肯定有新品，新品也需要变成爆款。 第五，脏数据。脏数据一般分两类，第一类是无效数据，比如说“双十一”，因为当天他们的行为非常特殊。“双十一”当天买了你平时可能不会买的东西。这样的数据对日常推荐并没有太大的帮助，这些数据必须要剔掉。第二类数据是作弊数据。像刷信用、刷积分的数据量往往很大，这样的数据如果不剔除掉，最终预测的结果和你原来的真实值之间的偏差会非常大。 最后介绍一下阿里巴巴实时推荐的系统架构，大概会分成这么几个部分，有EMAS数据统计模块，采集数据，拿到数据之后要对数据进行加工和训练，形成模型后把数据应用到生产环境。生产环境，一般来说是存储到图数据库，因为它是网状结构，最后是一个非常简单的API，可以简单调用数据。系统中有一块很重要，就是在模型训练过程中必须要具备支持行业经验的输入，因为我们在实践过程中发现，今天通用的模型去叠加一些行业规则，它的效果是非常好的，因为每个行业有每个行业的特殊性，今天一套通用算法想应用到所有行业是不现实的。这是我们个性化推荐系统的简单系统架构图，它一定要是一个闭环，数据一定要转起来，因为数据不转起来我们就不知道我推荐的结果是否准确、对用户的洞察是否准确，我们要必须保证数据运行一段时间后，数据是整体往上涨的。 三、AB在智能运营中的应用 最后给大家讲一下AB测试在智能运营中的应用。大家也知道今天算法的发展非常快，像前几年深度学习很火，这几年强化学习，一些新的算法发展很快，我们在模型迭代过程中需要应用新的算法。但一般来讲，我们不一定能确认哪个算法的效果更好，我今天在线下做非常多的评测，但最后还是要到生产环境去做实验。我们可以做分桶测试，基准桶和测试桶，测试桶我们用一个模型，基准桶用另一个模型，比较两个模型的效果。实际在应用过程中，我们在做AB测试前，必须要做AA测试，保证在实验之前两个桶的数据是一模一样的，这个时候你再把一个桶的模型换掉，数据是可信的。

30天再造一个“手机淘宝” 是怎样的一种体验？

111

测试