淘系技术
TA的个人档案
作者| 蒋卫星(韦青) 出品|阿里巴巴新零售淘系技术部 本文内容大纲： 1、轻量级图形渲染引擎与应用 2、渲染引擎演进与优化之路 3、渲染引擎未来的发展方向 GCanvas 的定位是遵循 w3c 标准的跨平台的轻量级图形渲染引擎。有清晰的定位和目标，并且紧贴现有的业务，为业务提供丰富表现形式。 GCanvas 发展 GCanvas 引擎从早期的 H5 性能加速，到 Weex 业务落地，从小游戏的业务探索，到服务端渲染，再到小程序。经过几个阶段的发展后日渐成熟。 淘系无线架构的不断升级迭代，GCanvas 随之保持着更新迭代的步调，在多个业务场景中使用，了解下一些应用案例。 应用案例 GCanvas 的目标人群是业务开发者，满足业务的功能需求，对开发者也非常友好，尤其是前端开发者。熟悉 H5 Canvas 的同学，很容易上手，无任何学习成本。 Weex2017年双十一预热会场，GCanvas 与魔影合作的版头动画 天猫未来店天猫未来店的智能电子标签，基于 GCanvas JSBinding 的智能电子标签 小游戏野生小伙伴，基于GCanvas小游戏应用 Sketch RenderDemo+ 中的 Sketch Render ，基于 GCanvas 实现的服务端渲染 Sketch 文件 支付宝小程序/淘宝商家应用Canvas基于支付宝小程序/淘系商家应用同层渲染组件支付宝小程序诸葛找房 - 2D 淘宝商家应用AR试妆 - WebGL 架构演进与优化 以业务先赢的基本原则，保证业务的前提下，架构容器和升级变化过程中，GCanvas 引擎也经历了演进和升级优化。 2017年的架构以插件为主的实现，仅支持移动端 最新架构提供标准接口，链路升级，API升级，不仅支持移动端还支持服务端 架构变化主要有以下几个方面： 适配支持更多的 JS 框架和库 JS 到 Native 调用通路，从模块路由反射升级到 JSBinding 渲染 API 支持 Metal 增加 MacOS 和 Linux 平台支持 ► 内功修炼 在快速迭代过重中，保持修炼内功。为保证高性能这个根本，在链路、内核以及底层图形 API 等方面也都做了不少优化与升级。 JS 到 Native 链路优化 从 Weex 调用链路到 JSBinding，Weex 容器的 JS 到 Native 的通路采用模块路由和反射的调用方式调用具体的模块和组件。在 UI 和一些非高频的场景完全能满足需求。 但是对于连续操作、连续动画等高频的 JS 到 Native 通讯的场景，链路上的耗时非常大，导致卡顿产生。这也是为什会 BindingX 和 GCanvas 的 JSBinding 的出现。 BindingX是另一种解决频发通讯消耗的方案，有兴趣的可以看下BindingX。 GCanvas 的 JSBinding 的实现：通过链路调用的改造，整体帧率平均提升10帧左右。Android 和 iOS 的 JSBinding 实现方案类似。 以 iOS 举例说明：iOS 尝试使用 JSExport 和全局方法，两种 JSBinding 方案。 第一种方案，使用 JSExport 和 JSExportAS 第二种方案，使用 C Export 将方法和属性用 JSStaticFunction 和 JSStaticValue 进行绑定 两种实现方案，经过测试对比第二种方案在性能更好。原因在于静态 JS 方法是通过方法名到 Native 函数的直接映射，而 JSExport 的方案则需要类型检查，协议校验，再调用 Native 方法中间经过额外的处理。 简单的耗时测试数据对比： JS 到 Native 数据传输方法调用与属性访问之外，参数数据的传输也影响每帧耗时，尤其是在 WebGL 的场景，通常有很大顶 点数据需要处理，有几万-几十万字节，甚至更多。JS 到 Native 的大数据传输避免内存拷贝。 JS 与 Native 对象生命周期JSBinding 的对象生命周期管理，JS 对象与 Native 对象一一对应，在 JS 对象创建触发 JSObjectInitializeCallback 回调，创建 Native 对象，并将 JS 与 Native 建立关联。JS 的 GC 回收对象触发 JSObjectFinalizeCallback 的回调中去释放对应 Native 对象。 帧率优化除了调用链路对帧率的提升，单帧绘制的 CPU 和 GPU 耗时相关的优化点 顶点数据计算，顶点数据合并提交 优化缓存策略，优化文字相关纹理的缓存 增加状态管理，减少 GPU 提交数据和频次 优化多边形填充效率 抗锯齿等耗时特性可选 w3c 标准完善 支持阴影 支持虚线 支持多Clip区域嵌套 支持Winding Rule支持 扩展能力，扩展一些非标接口支持 Sketch 渲染 阴影的扩散 路径的图案填充 路径的高斯模糊 路径的内描边和外描边 底层图形API升级在 iOS12 之后，苹果将 OpenGL ES API 设为废弃，在已支持的设备上 OpenGL ES 的调用都已映射到 Metal 相应的后端实现，Metal 替换 OpenGL 势在必行。GCanvas 也已投入开发 Metal，可选择使用 Metal 作为渲染的后端。已完成了 2D 的绝大部分能力。 选择 Metal 会带来以下方面的收益： 内存数据使用更高效，内存数据可共享， 尽可能的榨取更多 GPU 性能 摆脱 OpenGL 的状态机，更友好的面向对象编程 苹果后续的持续投入和更新 丰富的调试工具，能精确到每个顶点数据和每个素点颜色 便捷调试这着色器语言(Metal Shader Language) 在内核升级优化的过程中，也有很多同学积极参与其中来在此表示感谢。 稳定性 增加了 API 的自动化测试以及 CI 建立保障稳定性。 未来的方向 GCanvas 开源社区加大投入增加社区影响力, 请大家积极关注并star 更多纹理压缩格式的支持 Vulkan 的持续演进 更多平台的支持，IoT 设备上应用 与云端渲染的融合，提供 Fass 能力 WebGPU 以及 GPU 计算方向探索 WebAssembly 的应用 We are hiring 淘系技术部依托淘系丰富的业务形态和海量的用户，我们持续以技术驱动产品和商业创新，不断探索和衍生颠覆型互联网新技术，以更加智能、友好、普惠的科技深度重塑产业和用户体验，打造新商业。我们不断吸引用户增长、机器学习、视觉算法、音视频通信、数字媒体、移动技术、端侧智能等领域全球顶尖专业人才加入，让科技引领面向未来的商业创新和进步。 请投递简历至邮箱：ruoqi.zlj@taobao.com 了解更多职位详情：2684亿成交！每秒订单峰值54.4W！这样的团队你想加入吗？ 更多技术干货，关注「淘系技术」微信公众号
作者|潘佳(林晚) 出品|阿里巴巴新零售淘系技术部 “疯狂的”淘宝直播间 今年直播又火了！ 2019年双11淘宝直播带来近 200亿 成交，以天猫双11交易总额2684亿计算，直播已经占总成交额的近 7.45%！ 今年的变化 除了以往的手淘和猫客，现在 UC 浏览器、新浪微博、支付宝、优酷、闲鱼、飞猪、饿了么、口碑等等一系列阿里系 APP 里也可以观看直播、购买商品了，可以想象一下这些场景： 点了一杯奶茶外卖，在本地生活 APP 里通过直播能够看到小哥哥正在制作谁的订单，我排在第几号了，线下门店的卫生情况、制作过程、客流量、商品咨询都可以在直播间里了解到 在支付宝小程序里，边看直播边抢主播发来的口令红包 在阿里健康的消费医疗直播间里，跟今日特约的医师进行线上咨询 最近在计划一趟旅行，在飞猪APP里通过直播看着小姐姐介绍航旅套餐，还有小窗合流的当地风景观光片 ... 除了导购直播、客服直播、医疗直播、手艺直播等等，我们还能看到各种风格类型和互动形式的台网联动直播、秀场直播、晚会直播，以下是今年承接的几场大型互动晚会： 这些直播无论内容和互动有什么样的区别，他们都有一个共同的特征：直播间右上角「淘宝直播」的水印 问个问题，所有这些类型的直播间，都是淘宝直播的开发同学支持的吗？这需要一个多么庞大的技术团队呢？答案是这个团队其实很缺人，所以他们「勤奋」地做了一件「偷懒」的事情：ALive 开放，让阿里经济体里需要直播能力的业务能自主接入、自主开发，于是就有了今年百花齐放的直播生态。 ALive演进 ALive 的使命是汇集淘宝直播强大的音视频处理能力，提供直播、互动、营销一体化解决方案，实现「生态开放、直播未来」的愿景。 时移到2018年7月，当时的淘宝直播还是小作坊模式，所有的业务对接都由淘宝直播技术团队承接，各团队都在超负荷工作。随着对接的外部业务越来越多，各类直播间定制化需求越来越高，技术团队开始构思开放之路，解放一方生产力，赋能二方、三方直播能力。 ▶ 分析 直播对于观众来讲其实就是两个诉求：观看直播、参与互动。来看下当时的淘宝直播是如何满足用户这两个诉求的： 整体结构分为两部分：一个是直播能力，一个是互动通信能力。通过直播能力，观众能观看直播流；通过互动通信能力，观众能在直播间里参与实时互动。 直播能力：最简单的模型就是“两端加一服”，即推流端、播放端、流媒体服务器。主播通过推流客户端进行直播推流，我们提供了PC端推流工具和淘宝主播APP进行ARTP低延时推流，流媒体服务经过转码、切片、存储、分发等，供播放端拉流播放。 互动通信能力：主播在中控台创建、管理直播，开播后推送互动，经过业务服务调用和消息下发，端上渲染业务组件。当时的架构，每一个组件都跑在独立的Weex容器或H5容器里。 **▶ 问题**直播能力主要由淘宝直播音视频团队提供，依托阿里云构建了完整的音视频端到端闭环，包括音视频编解码、传输通道、网络调度技术，提供超低延时、超高画质、超大并发访问的音视频服务。二、三方业务只需要接入播放器 SDK ，主播使用我们的推流工具，即可支持直播能力。 互动通信能力主要依赖端侧的技术架构，从上图的架构可以看出两个核心痛点问题： 性能低下：每个组件都是独立的 Weex/H5 页面，内存占用较高，直播间流媒体播放已经占用了较高的内存水位，多个 Weex/H5 叠加后加大了 Crash 风险。同时各组件间相互独立，资源重复加载，加载性能也较差 效能低下：前端组件由客户端挖坑位的方式加载 bundle ，开发、调试环境强依赖客户端，直播环境搭建、消息模拟、数据 Mock 、日志查看、代码调试等链路都非常复杂，开发效率极其低下 ▶ 解法 前端的技术工作大部分都在解决两个「能」的问题：性能 和 效能。针对上述痛点，技术侧需要做两件事情：一是构建一个 灵活、高效的直播容器，解决性能问题；二是提供一套 直播间组件开发的工程体系，解决效能问题。在性能和效能都得到提升后，将这些能力通过 ALive 开放平台开放给二、三方业务接入，基于这些思考，我们升级了直播架构： 直播容器的核心区别，是由原来每个组件独立为一个Weex/H5容器，变成只保留一个Weex容器，通过这个直播容器来动态加载组件。 **▶ 技术实现** 1、直播容器 我们设想的灵活、高效的直播容器，应该具有以下几个特征： 统一规范的组件消息协议：包括组件包名、组件行为、业务自定义字段等，统一由 PowerMessage 的固定消息下发 支持动态加载：直播间不同于其他详情页，互动的发送依赖主播操作，也依赖用户进入直播间的时机，每个用户参与到的互动可能都不一样，所以互动组件的动态加载对首屏性能很关键 缓存及依赖去重：同一个互动，主播可以多次推送，各个互动依赖的基础库（rax-xxx、universal-xxx）也存在较多重复，所以设计合理的缓存和依赖去重机制对性能提升也很重要 HOC高阶组件：直播间里的业务开发不同于其他独立的源码页面，比如直播间数据获取、消息和事件监听、横竖屏状态获取、带小窗跳转、直播观看时长等等都依赖直播间环境或者客户端API，业务组件都需要这些基础能力，需要通过HOC来增强业务组件 基于这些特征设定，我们设计的直播容器技术结构如下： 直播容器的核心工作流程包括以下几点： 消息和指令：容器初始化时从Native获取缓存里Mtop请求的组件列表，同时消息模块监听Native转发的固定消息。协议解析成标准化指令，交给渲染模块执行后续操作 渲染管理：渲染模块接收到创建、更新、销毁组件指令后，传递给组件HOC，如果是创建组件指令，则从加载引擎拉取组件bundle 加载引擎：rloader维护了组件缓存，当拉取的组件不在缓存内时，会解析依赖，优先从缓存的基础依赖里查找基础组件，如果没有则combo拼接，最后拉取最小量的组件bundle，并将拉取的bundle加入缓存 组件HOC：高阶组件除了上述的能力，还提供了API Bridge、全局变量注入、事件分发以及一些监控容错等机制 2、 ALive工程体系 笔者加入淘宝直播后接手的第一个项目，是由客户端同学开发的 H5 版本亲密度组件，直播间里的组件开发强依赖客户端环境，当时的开发调试手段只能通过 Charles代理本地静态资源，没有日志、没有断点、没有 Mock ，开发环境极其恶劣。 引入直播容器后，改善了性能，但是在直播间里开发组件，需要一个完整的直播间环境和直播容器才能开发调试，没有配套的工程体系，组件开发依然很低效。我们设想的ALive工程体系，应该包含以下几个部分： ALive def 套件：直播间组件开发脚手架，增强调试能力，包括直播间模拟、调试代理、热更新、编译检测等功能 直播间 Debug 工具：基于直播容器开发一个Debug 组件，提供日志调试、容器化 API 调用、数据 Mock、消息 Mock 等功能 VS Code 插件：直播间 Debug 工具在 PC 端的同等方案，结合模拟器可以独立在 PC 端开发调试 基于这些诉求，我们设计的 ALive 工程体系技术结构如下： 效果演示：组件代码热更新 效果演示：VS Code插件Mock消息 效果演示：VS Code 插件 Mock 直播间数据 ▶ 数据表现 业务数据上通过 ALive 开放带来的外部流量早已超过百万 DAU ，每一个对接方都蕴含着一个大的垂直市场。 技术数据上直播容器的稳定性较好，组件的渲染时长由于并发请求限制，还存在一定的优化空间。ALive工程体系建设带来的提效非常明显，通过团队日常排期表数据粗略统计，开发效能提升大约在30%左右。 ALive展望 **▶ 业务侧：ALive互动市场** 今年猫晚直播间里所有的互动都由优酷侧同学通过ALive接入开发，我们看下猫晚同时在线观看人数的曲线图： 这张图里有个比较有意思的规律：猫晚同时在线人数的每一次峰值，都对应有互动的推送。这里有两点思考，第一是我们提供的直播容器其实是跑在刀尖上的，每一次峰值都是一次检验，所以对于直播容器除了前面提到的灵活、高效，还有一个更重要的要素，那就是稳定，这个稳定一方面依赖服务提供方，也就是淘宝直播技术团队的技术保障，另一方面依赖服务调用方严格遵循直播间互动接入SLA。第二个思考，优酷侧这次开发了这么多互动组件，能沉淀复用吗？ 嗯，这个问题亚博科技的同学已经给出了答案。今年阿里88会员节演唱会里的互动由亚博科技同学通过ALive接入开发，Bingo幸运球玩法效果非常不错，晚会结束后亚博科技同学主动提出将Bingo玩法沉淀到日常，于是有了后面的连连看、招财猫。招财猫互动在今年的双11活动期间，为直播间促活停留数据带来了非常不错的增长： 基于这些实践经验，ALive后续会规划互动市场，将各方业务开发的互动玩法按照拉新、促活/停留、转粉、成交、回访等维度进行分类管理，其他业务可以通过玩法优势、使用范围、已接入业务效果等选择复用组件，也可以为互动团队提供更多的数据参考，集中精力生产、迭代更优效果的直播互动玩法。 ▶ 技术侧：小程序直播开放 在我们讲开放的时候，经常提到的几个关键词是轻量、灵活，但我们发现手淘端外业务在直播接入过程中，需要接入播放器SDK和Weex SDK才能满足直播能力，接入成本依然较高。前端将视角瞄向了小程序体系，期望不依赖SDK来满足其他APP端内的直播诉求。目前我们已经实现了支付宝端小程序直播（支付宝搜索淘宝直播即可体验），目前还有两件事情需要突破： 提供类似于Rax直播容器的小程序直播容器，提供二、三方组件开发能力 和支付宝端对接过程中，我们大部分精力在处理播放的问题，比如iOS/Android端播放控制不一致、H.265播放黑屏等。如果换一个客户端，是否要重新再对接一遍？ 针对第一个问题，已经有可行方案，区别于Rax体系下的组件动态加载，小程序体系下需要预定义好组件使用范围，通过Page生成服务产出对应的Page Bundle。针对第二个问题，鉴于我们团队之前自研了基于WebAssembly的Web端播放器，我们一直在探索将该前端方案的播放器迁入小程序体系，实现前端的播放方案，解决播放器SDK版本限制的束缚，这个突破会极大程度地降低直播接入成本。 另一方面我们团队在尝试通过H5接入ARTC低延时方案，实现H5端的低延时推拉流方案，如果该方案也能在小程序体系下跑通，意味着二、三方业务将能通过H5/小程序实现推流、拉流、播放，形成web和小程序侧的音视频闭环。技术上进一步降低接入成本、增强通投能力，更轻量、灵活、稳定的ALive开放体系，将给业务带来更强劲的推力。 最后 ▶ 关联项目 媒体智能：直播、短视频从生产侧到消费侧的媒体智能方案。直播互动目前都是传统互动，互动和流内容是割裂的。直播间里的AR/AI玩法有机会给用户留存和观看时长带来较大提升，设想在直播间里抢的红包雨可能是由主播通过手势挥洒出来的、李佳琦喊出“Oh My God”的时候自动跳出字幕特效等等，除了玩法增强，媒体智能还能提供更智能化的服务，比如主播展示商品时智能识别，用户可在流画面内点击商品直接购买等等，场景非常丰富。团队自研的媒体智能编辑器 Media AI Studio已经产出原型版本，整体项目旨在通过媒体智能工具链和工程化体系建设，将智能玩法开发周期提效成“7+3+1”模式（7天算法开发、3天玩法编写、1天素材制作，即可上线一个全新玩法） Electron多媒体生产端：基于Electron + OBS + MLT的多媒体PC生产端工具，包括直播推流、回放编辑、视频剪辑等核心能力 VideoX播放器：PC/H5/Weex/小程序多场景整合的统一播放方案 团队在多媒体生产端和消费端的各个项目齐头并进，又都和ALive相互串联，最终将形成合力构建出丰满完整的多媒体前端体系。 We are hiring 淘宝直播多媒体团队火热招聘。简历投递至：joven.panj@alibaba-inc.com 更多技术内容，关注「淘系技术」微信公众号
作者|哲良、八风、泽彬出品|阿里巴巴新零售淘系技术部 诺亚(Noah) 自适应流控解决方案 基于自动控制算法，解决了人工限流配置疏漏或过时的痛点，大幅提升应用抵抗流量冲击的能力。在刚过去的双11中，诺亚(Noah)保障了大量业务应用系统，有超过 15K 的容器大规模部署；稳定性上最高可提升 20 倍于业务负载流量的上限 QPS ；最高可提升 100% 的资源利用率；同时优化了体验与效率。提升淘系(及更多BU)的稳定性底盘，成为应用稳定性保障的核心能力，推动了业界在大型分布式在线业务系统的高可用/稳定性保障的进展。 背景 随着业务的不断发展，应用数量、拓扑依赖与复杂性都在持续增长，流量模型的有效预测也变得更加困难。系统与流量的不确定性都会导致系统容量评估疏漏或评估过时。这些情况在双11、春晚等大型复杂活动中会更加的突显。 面向流量的「意义」 流量会受到业务的影响而发生强变化的，这种变化是不确定的且在频繁发生的。 应对这种不确定性需要基础架构有可靠的、自适应的方式，能够 实时接受与感知变化 作出保护响应来抵御变化，自适应的、柔性的实施系统/架构 然后是弹性，针对基础资源做实时调节 这样才能具备有效的抵抗力、适应力，活着是前提，有了这个前提，才有机会将基础资源驱动起来（弹性），而业务无需耗费心力去关注这种不确定性带来的业务可用性风险。 关于高可用的重新思考 业界在讨论高可用时，主要说的是资源失效的对应方式，比如通过应用集群、主备、热切换等应对单机失效；通过单元化架构、异地多活等应对单机房/地域失效。 从上面对资源失效的问题与对策可以看出，高可用所要解决的核心问题是保证服务不挂，准确的说是要大大降低服务挂掉的概率。 到了今天我们的应用架构，我们的可用性痛点问题是什么呢？对于你自己开发的应用，或听到某某服务挂了时，你会担心或者想到什么？在可用性方面，相信更多的回答会是『服务压跨了』，典型的是问题场景是『大流量、突发流量』下，比如：直播场景中主播一声吼，后端流量飙升；社交媒体场景中明星官宣结婚，带来热点流量暴涨；电商运营场景中，秒杀活动大流量脉冲；互动玩法场景中持续不断发布互动活动，一个新的活动导致系统整体可支撑的QPS可能下降很多。这些场景与问题在日常应用开发和服务保障过程中，应该是深有痛点吧 :) 在应用架构上，业界对面向流量的可用性，不如像面向资源一样得到充分的关注、有着丰富成熟的思路和广泛有效的实践，我们有意于改变 面向流量的可用性 这个主题的现状，更多的直面问题、探索思路、实践推进。 传统方案有什么问题？ 面向流量的可用性现有的应对方式是静态限流。 传统的针对 QPS 限制的静态限流方法的问题： 流量/请求 依赖 请求模型的准确评估，即测试流量的请求大小与实际需保持一致。热点流量，如热点用户被频繁访问/爆冷商品等。运营导致用户动线走了较重的逻辑分支。 依赖 来的流量的准确预估。但我们要承认，流量一定无法准确被评估，系统会被摸死（即拒绝操作导致的过载）。 业务代码逻辑 依赖 测试之后系统自身和其下游依赖的逻辑不变，性能需保持一致。但是业务总是在演进，除非全网封网，否则限流阈值一上线就已经过时了。 资源 依赖 各台机器性能完全一致且稳定不变。 机器型号不同，处理能力是不可能做到完全一致的。 虚拟化/容器化之间有影响，你无法控制你的邻居会做什么。 流程 依赖 事先人工准确执行了评估过程但人总是靠不住的，只要人工来执行就一定会疏漏、出错。 另外对于长尾应用/非核心应用，支持力度没有保障，人力资源总是有限的。 传统方法无法解决人工评估过时导致的流量与容量不一致的问题，我们需要一种能够实时评估系统容量，并就地对流量进行控制的解决方案。 诺亚(Noah)自适应流控 面对系统稳定性问题，诺亚(Noah) 自适应流控解决方案采用不同于业界传统的针对QPS限制的静态限流方法，首次以自动控制算法为核心手段，提供自适应流控解决方案，解决了限流配置过时的痛点，大幅提升应用抵抗流量冲击的能力，极度简化了相关配置工作，同时在系统资源利用率、用户体验、运维效率等方面均有大幅优化提升。 诺亚(Noah)自适应流控解决方案 在绝大部分情况下，CPU利用率作为资源供给的主要信号是最为直接的。诺亚(Noah) 自适应流控解决方案即是以自动控制CPU资源为核心方法的，其具备了一下3点优势： 在系统稳定性控制效果方面表现为精准和有效的控制，并具备很强的可解释性。 没有提前的人工评估，便没有提前评估的过时与人工评估的疏漏和错误。 应用场景更为广泛，不受异步场景约束，可同时使用于同步和异步场景。 诺亚(Noah) 自适应流控解决方案能够实时自动评估 QPS ，在技术方案上使用自适应性来解决业务流量的不确定性。 业务落地 作为淘宝应用架构升级（代号Tango：Taobao Architecture Next GeneratiOn）在稳定性上的核心产品，诺亚(Noah)在刚刚过去的双11大促过程中，保障大量业务应用系统，有超过15K的容器大规模部署（涉及淘宝、天猫、聚划算、盒马、猫超、优酷等等众多业务）。提升系统稳定性、提升资源利用率、优化体验与效率，提升了淘系(及更多BU)的稳定性底盘，成为应用稳定性保障的核心能力，推动了业界在大型分布式在线业务系统的高可用/稳定性保障的进展。 诺亚(Noah) 自适应流控解决方案目前已上线超过9个月，在线上实战和全链路压测中，诺亚保护了大促会场、直播、导购等等核心业务场景；应用系统在出现容量缺失30%或近20倍超大流量脉冲场景下仍保持稳定运行。 诺亚(Noah)自适应流控的效果收益： 可用性提升 压垮QPS上限，最高可提升 20倍 于业务负载流量。 在大流量压力下降后，1秒 快速恢复服务。 大流量压力下，仅需直接扩容机器 一步即可，无需紧急调整限流。 用户体验的优化 应用在高负载情况下，服务成功率最高可提升 2.7倍，同时响应时间维持正常水平不劣化。 成本的优化 资源利用率最高可提升 100%（去除为了稳定性/不确定性而留的资源冗余） 效率提升 全链路压测/性能压测更顺畅。无需人工限流阈值设置，避免人工评估错误导致系统被压垮后需要大量调整时间。 自适应流控的实际控制效果：在流量飙升/大流量压力时，CPU稳定控制在阈值，且服务RT正常 诺亚后续的发展 目前诺亚(Noah) 自适应流控解决方案保障了大量业务应用系统，提升稳定性、提升资源利用率、优化体验与效率，提升淘系(及更多BU)的稳定性底盘，成为应用稳定性保障的核心能力，推动了业界在大型分布式在线业务系统的高可用/稳定性保障的进展。 对未来更体系化建设的几点展望： 自适应能力由限流拓展到隔离/熔断等更多稳定性能力，如 自适应线程资源隔离 自适应服务比例 自适应服务熔断 由单机的自适应限流拓展到链路级，尤其是客户端流量入口接入层 与接入层协同，让入口流量与应用的处理容量自适应匹配 确定性地保障面向流量的高可用 自适应控制流量拓展到自适应伸缩容 流量控制与处理资源控制（伸缩容）协同 无论是流量的控制还是资源的控制，都是为了让处理流量与资源容量匹配 保障系统不过载，提升稳定性与业务请求的成功率 One More Thing 淘系技术部依托淘系丰富的业务形态和海量的用户，我们持续以技术驱动产品和商业创新，不断探索和衍生颠覆型互联网新技术，以更加智能、友好、普惠的科技深度重塑产业和用户体验，打造新商业。我们不断吸引用户增长、机器学习、视觉算法、音视频通信、数字媒体、移动技术、端侧智能等领域全球顶尖专业人才加入，让科技引领面向未来的商业创新和进步。 请投递简历至邮箱：ruoqi.zlj@taobao.com 了解更多职位详情：2684亿成交！每秒订单峰值54.4W！这样的团队你想加入吗？
作者| 彭鑫(公亮) 出品|阿里巴巴新零售淘系技术部 11月中旬，作者在 TOP 100 案例和人人都是产品经理的两次大会上分别进行了两场关于价值交付的分享，结合分享后的反馈焦点，立足业务整体交付的价值最大化，特产此文。 持续需求交付的痛点 ▶ 没有价值的交付等于没有交付 随着敏捷方法的普及，越来越多的团队引入了敏捷以推动业务的快速迭代、小步快跑、及时的响应市场变化。在各种敏捷框架的指引下，交付效率得到提升，很容易的就做到持续的需求交付。 有了高效率的需求交付就一定能拿到业务结果吗？并不尽然，需求的交付集合只代表了功能的完成，并不能与业务价值划等号。好比一个简单的乘法公式：100 x 0 = 0，其中100代表交付效率，0代表业务价值，两者结合的最终业务成果也一定是0。 因此，只做需求的交付效率是不够的，还要关注交付的业务价值，二者相辅相成缺一不可，共同为业务结果保驾护航。 ▶ 交付的三大痛点 在跑敏捷的过程中发现，有的团队本身就有一些和敏捷方法无关的业务问题或者组织问题，通过敏捷实践被暴露和放大，会影响业务价值的交付，拖累业务结果。主要表现为以下几个方面： 没有战略目标丢失了业务主心骨 主要表现为战略不清晰，目标不聚焦。这是许多公司的通病，往往这类公司有着美好的公司愿景，比如要改变行业或成为行业第一，但战略规划是模糊的，也找不准定位和坚持的方向。战略是对美好愿景的长远规划，是远大的目标，是公司活动的纲领和指导思想。正因为战略是如此的重要，就特别需要管理层弄明白。 用堆需求的勤劳掩盖业务规划的懒惰 团队引入敏捷之后，就单个团队而言运转很好，Scrum Team的沟通效率得到了大大的提高，有着非常非常高效的交付。但也出现了新的问题 —— 需求越堆越多，但业务长远的规划没有了，各业务团队之间的配合也没有了，“竖井效应”越来越明显。正是缺少业务规划，建立不了各业务之间的关联关系，导致协同作战也越来越遥远。 业务价值没挖透却想着天上掉馅饼 当堆了那么多功能之后，突然发现竞品刚刚推出了一个很火的活动，不是自家刚做过的吗？我们没火但为什么竞品火了？是自家公司的人不行吗？是自家的用户不行吗？其实不是！这里有两个原因，一是在被误解的“小步快跑”交付思想下，许多业务的价值点没有挖透。二是职能团队之间没有形成联动，只做了功能的交付和自运营。试想，一个功能的交付如何打得过一个由产品、运营、PR、市场、渠道等多职能海陆空协同的业务交付呢？价值挖掘不到位，就好比下图的挖井，明知道下面有水源，但不管换多少个地方挖但总挖不出水来。 ▶ 找到根因才能解决问题 归根到底，以上问题的原因有2个。 一是创新业务的不确定性。创新业务在高速发展阶段，本身有许多的不确定性，而管理机制却不能满足业务的需要。 二是价值挖掘的不充分性。在执行时各职能的配合没有形成合力，例如同一个活动上线，我们靠自增长肯定是拼不过竞品的全方位协同作战的。 针对以上的问题，我们通过实践在业务目标对齐、过程高效交付、组织保障配合三个方面做到持续价值交付，并促进业务目标的达成。 打造持续的价值交付 ▶ 要做好价值交付先要做到业务目标对齐 1、先把业务价值交付的思想武装起来 要做到业务价值的交付，就要敢于打破常规，把敏捷的持续交付从需求领域放大到业务领域。 如下图，中间区域是敏捷方法中经典的 Scrum 运作框架（演绎后的叫法略有不同），在此基础上增加业务的反馈闭环，暨在链路前端增加半年一度的业务规划和月度的产品规划，在链路后端也增加了双月一次的业务复盘。业务复盘也可以固定到月，还可以按需不定期的召集，业务复盘中还可附带轻量级的共创，结果会关闭一些项目也会新启动一些新的项目。 业务规划和复盘，注定不是单业务的单项目的，一定是面向所有业务和重大项目的，规划会上会产生新的共同目标，会有横向的业务链接和依赖梳理。业务型PMO在此时的作用就是：当战略目标、业务规划不清晰时，要带领团队制定战略目标、弄清楚业务规划、找到各业务之间的链接并拉通。 2、以规划会为价值交付的起点 业务规划会是最需要 CEO、HR 打好配合战的时候。规划会、复盘会需要 CEO 现场拍板给结论做决策，不要拖延。想不清楚的业务就不要启动，业务不具备启动条件的也不要启动，要做到恰到好处，即所谓的天时地利人和。当然，这不是说就停滞不前，想不清楚的还要继续想，缺特殊人才的就抓紧时间补人。HR不但要负责后勤保障，还要一同参与其中（或组织），还要根据业务的决策结果会做组织架构的调整，也还要根据需要落地招聘。 大的共创会建议放到外部的场地来开，比如沙家浜、井冈山等著名的红色旅游景区。一是仪式感非常强，还能做一些集体活动利于打开大家的心扉、放飞自我，为执行做好铺垫。二是避免日常的打扰提高大家的参与度，在效率上、产出质量上都能有很大的提升。共创会的开发有很多种，本文不做详述。 3、从唐僧团队看目标原则 西游记的唐僧团队是一个非常伟大的团队，不止如此，他们的战略目标和个人目标的设计、支撑也做得非常好。唐僧一开口就提战略目标：“贫僧从东土大唐而来，前往西天拜佛求经”，战略目标清晰，简单扼要。其实战略还有后半句——“取得真经，普度众生”，这与唐僧取经的愿景形成了一致，也说明了战略是分步骤的，不同时期和阶段，战略目标也有差别。 再说唐僧团队其他人的目标，孙悟空希望护得唐僧顺利取得真经，把头上的金箍拿掉好回花果山做他的美猴王，八戒希望取经后回到高老庄继续做乘“猪”快婿，沙僧和白龙马则希望通过取经这一功德改变自己的生存现状（告别流沙河和脱胎换骨）。 这四个目标虽然各不相同，但都有共同的目标——护送唐僧取得真经，非常完美的匹配唐僧第一阶段的战略目标。这就好比一个公司，每个部门可以有自己的小目标，但必须支撑大目标，同时通过达成大目标来成就个人。 我们在制定战略目标时需要注意4个原则：匹配战略、阶段聚焦、可衡量、并且一致认同。特别要强调的是，一致认同不但要团队内部认同，也要横向团队的认同以便打好跨团队的协同和配合战。 4、里程碑是强者的脚印 战略目标制定之后，要转化为每个业务的目标、每个项目的目标，还需要制定阶段可衡量的目标以及阶段的业务打法、抓手和策略。所有的拆解颗粒度至少以月为维度，不仅有目标、还要有关键成果的支撑。对于重运营的项目，还要拆解到周、或者是到日。 有个心理学家做过一个实验，他让三组人走同样的路程去不同的村庄。第一组人仅知道村庄的名称。第二组人知道村庄的名字和路程。第三组人不仅知道村庄的名字和路程，还知道公路旁每一公里处就有一块里程碑。 由于各组对此了解的情况不同，测试的结果也不同。第一组人由于对路况一无所知，越走情绪越低落，尚未到达终点队伍已经解散。第二组人因为知道路程，所以当他们情绪低落时，只要有人喊“快到了”大家就又加快了步伐。而第三组人因为目标明确，阶段可衡量，于是越走情绪越高涨很快到达终点，而且所花费的时间仅为第二组人的 1/5 。 在项目上，我们不但要拆解好里程碑的目标，还要注意目标下各职能团队的子目标对总体目标的支撑。 比如12月份要上一个圣诞节的营销活动，定了总的目标为活动的总参与人数、留存。往下拆解到产品团队就要保证对应的版本要尽早的发出去，保证营销活动的 app 升级率要到达到 80% 。技术团队的目标是要保证活动页面的稳定性，包括内存使用量，流畅度。而市场团队也会有相关的目标，比如内容量，分发量等。 要做就要认真的做，不是单点打，要充分调动各方资源，打海陆空多兵种的配合战，保障方案落地，充分挖掘项目的用户价值，让收益最大化。下表可以作为目标拆解的参考。 目标明确后，还要靠快速的行动抢占市场，这是一场硬对硬的战争，因此在过程交付上我们也要高效起来。 ▶ 要做好价值交付还要做到过程高效交付 1、明确权责利万事有小主 要做到高效交付，必须明确参与人员的权责利。我们做到了把不同职能、不能角色、不同的活动串联到一张宽表，这样大家能明白在什么阶段，是谁对什么结果负责，应该协同的团队有哪些。 如下图所示，绿色的区域表示负责人，蓝色的区域表示参与方，红色的内容是卡口节点（关键内容必须经过审核确认）。 PMO 的工作将会贯穿于链路的每一个环节。 这个图表是经过凝练的粗表，在每个流程下还有更详细的流程和分工。比如“提测发布”的下面还会涉及 TC 评审、自测、冒烟、灰度、发布、线上监控和回滚机制等的流程，不但包括负责人，还包括规则等执行细则。关于流程，每个业务需要立足于自身的组织特点而设定不同的制度和机制，切勿完全照搬。 2、班车机制带起业务节奏 仅仅有规则还是不够的，还需要有节奏。业务要有业务节奏，项目要有项目节奏，好比行进中的军队，在统一的号令下才能做好多兵种的协同亮剑。 基于同一个产品的发布，我们引入了班车机制，每周五做发布评审，下一个周三正式发布。一个产品有那么多的业务团队集成，点对点的发布沟通很难做，所谓婆婆太多，众口难调。通过班车机制的建立，我们到点发车，这样每一个业务方和团队，都能按着这种规律化的时间自己安排业务节奏，好比找人，给了明确的地址以及人员特征，简单到按图索骥自行匹配即可。 3、过程透明和高效决策一起跑 在业务和项目的执行中，让一切透明，让数据说话是管用的法宝。通过数据的透明，能让团队形成赛马，也会形成就事论事的沟通方法。 我们的看板不止电子看板还有物理看板，通过两种看板的结合，既有仪式感，也能收集到过程数据。看板内容除了需求看板外，还有业务数据看板。业务数据的看板会依据业务的实际情况，做到每周或者每天更新数据。以上的内容，也可以使用电子看板操作，但会配备大屏电视来落地。 为了保障大家的研发效率，站会通常会选择在晚餐前开。白天的各种信息可以在这个点进行收敛和同步，其后根据进展进行赶工，保障对下游的交付。在站会上，不强调每个人都讲，需要根据需求交付的最终状态的大节点不同来重点关注。比如，风险中、阻塞中或者一个状态太久没移动的需求要被重点关注。有时候存在协同性高的项目，我需要听每个站会，就会安排多个站会按顺序执行。日常的项目，也会通过 SoS 站会来关注进展和风险。 为了快速响应用户的问题，建立了需求快速决策机制、线上故障的应急机制、为降低用户使用产品的门槛引入在线客服。客服背后有对应的日常值班小组，由各个职能团队的小伙伴轮值，这样既帮助用户解决问题，又能走进用户了解用户痛点。日常值班小组不但解决了突发情况的快速响应问题，还能保证大家在工作上保持足够的专注力，避免被频繁的打断。 目标明确，高效执行的背后是人，这一切离不开组织保障。 ▶ 要做好价值交付更要做好组织保障 一个团队的火力猛烈程度取决于团队的人才优势是否足够，因此我们建立了员工能力模型，告诉大家我们需要到达什么样的段位，同时也是对外招人的衡量维度。只有志同道合，才能万众一心。当然志同道合并不是说要一模一样，人才也是需要多元化的。 一支军队要作战，还需要士气，在氛围营造上我们注意轻量级的仪式感，大部分的内容为就地取材加以有意放大。某个项目的第一次预演会上，一个前端同学出现了多个低级的bug，每出现一次他都会说：放心，我知道问题，今天搞定。我抓住机会，把“知道问题”这个词临场放大为“什么都知道”，不但缓解了相关同学的压力，也让整个项目氛围变得很融洽。因此我要求 PMO 的同学必须有团队建设的能力，部分原因也是基于这一点。 真正的胜利，是鼓舞心中的希望。通过把看起来无法达成的大目标拆解为一个个踮起脚尖可达成的阶段目标，随着一个个阶段目标的达成，大目标也在不知不觉间达成。让一个个的不可能变为拿到结果，也让大家感到成就感，证明每一个人的价值。 目标达成，我们不但让马儿跑得欢，还要给马儿草吃，每个季度都会对拿到结果的优秀团队和优秀项目进行激励。激励会上还有一个保留的节目，谢谢身边同学的一起努力，拉拉手，揉揉肩。为结果买单，为过程鼓掌。 ▶ 三个“一”打通业务价值 通过一系列的活动和机制的运作，最终形成了一张图、一场仗、一颗心。 一张图是指业务一张图。通过不断的跨团队的对齐和拉通，做到了业务目标朝战略对齐、团队和项目的需求朝业务目标对齐、开发任务和交付朝需求对齐，建立了目标分解树，做到了上下有效支撑，左右横向对齐。 一场仗是指行动一场仗。通过一系列的活动比如业务规划会、需求排期会、站会、班车机制等形成统一指挥，核心围绕业务目标，能做到业务快速调整，人力部署快速响应，在过程中建立了节奏感。 一颗心是指团队一颗心。通过生产关系梳理和组织过程结构优化，从分散的团队到弱矩阵再到虚拟的特性团队，组织上充分授权，通过透明化的协作、和一系列大大小小的战役建立起战友情，凝聚了整个业务团队的战斗力。 通过半年的努力，相比上一个半年，通过双周迭代和按需发布产品版本的发布频率降低到10天一次（提升了220%），需求的Leadtime也降低了167%。在业务结果上，两个关键的指标增长超过预期，完成度达到108%，而当初在定目标时没有人觉得这一目标能达成。 持续价值交付的敏捷价值观 在持续价值交付的路上，我对敏捷的四个价值观也有了更多的理解和补充。 个体和互动就是要打破职能边界、对齐目标、确保步调一致。在互动的过程中不过2个事情：让业务更清晰更可执行，让过程更透明执行更高效。 可工作的软件不但快速交付真实的用户价值，还要与客户协作共建有价值的产品，交付上，不只关注研发效能，也要关注交付的业务价值，两者相辅相成，我们要“在一起”。 响应变化就是提供系统性的项目管理框架，帮助业务创新、试错。项目管理的过程中，我们要善用套路和方法，但也不唯方法论。不管碰到什么问题，我们总有办法解决和克服。 总之，通过持续、深入的做价值交付，让业务目标、项目目标对战略目标形成有力的支撑并聚焦，横向团队做到目标对齐海陆空的协同出击，在执行过程中要做到过程透明、数据透明，建立日常节奏和应急机制，快速响应业务新机会、及时解决用户碰到的问题。对于阶段结果，要做到及时激励，及时复盘，及时修订。最终我们要做到业务一张图、行动一场仗、团队一颗心，通过合力持续交付价值，让业务拿到结果，个体获得成长。 One More Thing 淘系技术部依托淘系丰富的业务形态和海量的用户，我们持续以技术驱动产品和商业创新，不断探索和衍生颠覆型互联网新技术，以更加智能、友好、普惠的科技深度重塑产业和用户体验，打造新商业。我们不断吸引用户增长、机器学习、视觉算法、音视频通信、数字媒体、移动技术、端侧智能等领域全球顶尖专业人才加入，让科技引领面向未来的商业创新和进步。请投递简历至邮箱：ruoqi.zlj@taobao.com了解更多职位详情：2684亿成交！每秒订单峰值54.4W！这样的团队你想加入吗？ 获取更多技术干货，关注「淘系技术」微信公众号。
作者| 妙净、波本出品|阿里巴巴新零售淘系技术部 导读：作为今年阿里经济体前端委员会的四大技术方向之一，前端智能化方向一被提及，就不免有人好奇：前端结合 AI 能做些什么，怎么做，未来会不会对前端产生很大的冲击等等。本篇文章将围绕这些问题，以「设计稿自动生成代码」场景为例，从背景分析、竞品分析、问题拆解、技术方案等几个角度切入，细述相关思考及过程实践。 背景分析 业界机器学习之势如火如荼，「AI 是未来的共识」频频出现在各大媒体上。李开复老师也在《AI·未来》指出，将近 50％ 的人类工作将在 15 年内被人工智能所取代，尤其是简单的、重复性的工作。并且，白领比蓝领的工作更容易被取代；因为蓝领的工作可能还需要机器人和软硬件相关技术都突破才能被取代，而白领工作一般只需要软件技术突破就可以被取代。那我们前端这个“白领”工作会不会被取代，什么时候能被取代多少？ 回看 2010 年，软件几乎吞噬了所有行业，带来近几年软件行业的繁荣；而到了 2019 年，软件开发行业本身却又在被 AI 所吞噬。你看：DBA 领域出现了 Question-to-SQL，针对某个领域只要问问题就可以生成 SQL 语句；基于机器学习的源码分析工具 TabNine 可以辅助代码生成；设计师行业也出了 P5 Banner 智能设计师“鹿班”，测试领域的智能化结合也精彩纷呈。那前端领域呢？ 那就不得不提一个我们再熟悉不过的场景了，它就是设计稿自动生成代码（Design2Code，以下简称 D2C），阿里经济体前端委员会-前端智能化方向当前阶段就是聚焦在如何让 AI 助力前端这个职能角色提效升级，杜绝简单重复性工作，让前端工程师专注更有挑战性的工作内容！ 竞品分析 2017 年，一篇关于图像转代码的 Pix2Code 论文掀起了业内激烈讨论的波澜，讲述如何从设计原型直接生成源代码。随后社区也不断涌现出基于此思想的类似 Screenshot2Code 的作品，2018 年微软 AI Lab 开源了草图转代码 工具 Sketch2Code，同年年底，设计稿智能生成前端代码的新秀 Yotako 也初露锋芒， 机器学习首次以不可小觑的姿态正式进入了前端开发者的视野。 基于上述竞品分析，我们能够得到以下几点启发： 1、深度学习目前在图片方面的目标检测能力适合较大颗粒度的可复用的物料识别（模块识别、基础组件识别、业务组件识别）。 2、完整的直接由图片生成代码的端到端模型复杂度高，生成的代码可用度不高，要达到所生成代码工业级可用，需要更细的分层拆解和多级子网络模型协同，短期可通过设计稿生成代码来做 D2C 体系建设。 3、当模型的识别能力无法达到预期准确度时，可以借助设计稿人工的打底规则协议；一方面人工规则协议可以帮助用户强干预得到想要的结果，另一方面这些人工规则协议其实也是高质量的样本标注，可以当成训练样本优化模型识别准确度。 问题分解 设计稿生成代码的目标是让 AI 助力前端这个职能角色提效升级，杜绝简单重复性工作内容。那我们先来分析下，“常规”前端尤其是面向 C 端业务的同学，一般的工作流程日常工作内容大致如下： “常规”前端一般的开发工作量，主要集中在视图代码、逻辑代码和数据联调（甚至是数据接口开发，研发 Serveless 产品化时可期）这几大块，接下来，我们逐块拆解分析。 视图代码 视图代码研发，一般是根据视觉稿编写 HTML 和 CSS 代码。如何提效，当面对 UI 视图开发重复性的工作时，自然想到组件化、模块化等封装复用物料的解决方案，基于此解决方案会有各种 UI 库的沉淀，甚至是可视化拼装搭建的更 High Level 的产品化封装，但复用的物料不能解决所有场景问题。个性化业务、个性化视图遍地开花，直面问题本身，直接生成可用的 HTML 和 CSS 代码是否可行？ 这是业界一直在不断尝试的命题，通过设计工具的开发插件可以导出图层的基本信息，但这里的主要难点还是对设计稿的要求高、生成代码可维护性差，这是核心问题，我们来继续拆解。 ▐ 设计稿要求高问题 对设计稿的要求高，会导致设计师的成本加大，相当于前端的工作量转嫁给了设计师，导致推广难度会非常大。一种可行的办法是采用 CV（ComputerVision, 计算机视觉） 结合导出图层信息的方式，以去除设计稿的约束，当然对设计稿的要求最好是直接导出一张图片，那样对设计师没有任何要求，也是我们梦寐以求的方案，我们也一直在尝试从静态图片中分离出各个适合的图层，但目前在生产环境可用度不够（小目标识别精准度问题、复杂背景提取问题仍待解决），毕竟设计稿自带的元信息，比一张图片提取处理的元信息要更多更精准。 ▐ 可维护性问题 生成的代码结构一般都会面临可维护性方面的挑战： 合理布局嵌套：包括绝对定位转相对定位、冗余节点删除、合理分组、循环判断等方面； 元素自适应：元素本身扩展性、元素间对齐关系、元素最大宽高容错性； 语义化：Classname 的多级语义化； 样式 CSS 表达：背景色、圆角、线条等能用 CV 等方式分析提取样式，尽可能用 CSS 表达样式代替使用图片； 将这些问题拆解后，分门别类专项解决，解决起来看似没完没了，但好在目前发现的大类问题基本解决。很多人质疑道，这部分的能力的实现看起来和智能化一点关系都没有，顶多算个布局算法相关的专家规则测量系统。没错，现阶段这部分比较适合规则系统，对用户而言布局算法需要接近 100% 的可用度，另外这里涉及的大部分是无数属性值组合问题，当前用规则更可控。如果非要使用模型，那这个可被定义为多分类问题。同时，任何深度学习模型的应用都是需要先有清晰的问题定义过程，把问题规则定义清楚本就是必备过程。 但在规则解决起来麻烦的情况下，可以使用模型来辅助解决。比如 合理分组（如下图） 和 循环项 的判断，实践中我们发现，在各种情况下还是误判不断，算法规则难以枚举，这里需要跨元素间的上下文语义识别，这也是接下来正在用模型解决的重点问题。 逻辑代码 逻辑代码开发主要包括数据绑定、动效、业务逻辑代码编写。可提效的部分，一般在于复用的动效和业务逻辑代码可沉淀基础组件、业务组件等。 接口字段绑定：从可行性上分析还是高的，根据视觉稿的文本或图片判断所属哪个候选字段，可以做，但性价比不高，因为接口数据字段绑定太业务，通用性不强。 动效：这部分的开发输入是交互稿，而且一般动效的交付形式各种各样参差不齐，有的是动画 gif 演示，有的是文字描述，有的是口述；动效代码的生成更适合用可视化的形式生成，直接智能生成没有参考依据，考虑投入产出比不在短期范围内。 业务逻辑：这部分开发的依据来源主要是 PRD，甚至是 PD 口述的逻辑；想要智能生成这部分逻辑代码，欠缺的输入太多，具体得看看智能化在这个子领域能解决什么问题。 ▐ 逻辑代码生成思考 理想方案当然是能像其他诗歌、绘画、音乐等艺术领域一样，学习历史数据，根据 PRD 文本输入，新逻辑代码能直接生成，但这样生成的代码能直接运行没有任何报错吗？ 目前人工智能虽说发展迅速，但其能解决的问题还是有限，需要将问题定义成其擅长解决的问题类型。强化学习擅长策略优化问题，深度学习目前在计算机视觉方面擅长解决的是分类问题、目标检测问题，文本方面擅长 NLP（Natural Language Processing, 自然语言处理） 等。 关于业务逻辑代码，首先想到的是对历史源代码的函数块利用 LSTM（Long Short-Term Memory, 长短期记忆网络）和 NLP 等进行上下文分析，能得到代码函数块的语义，VS Code 智能代码提醒 和 TabNine 都是类似的思路。 另外，在分析问题中（如下图）我们还发现，智能化在业务逻辑领域还可以协助识别逻辑点在视图出现的位置（时机），并根据视图猜测出的逻辑语义。 综上，我们总结一下智能化现阶段的可助力点： 由历史源代码分析猜测高频出现的函数块（逻辑块）的语义，实际得到的就是组件库或者基础函数块的语义，可在代码编辑时做代码块推荐等能力。 由视觉稿猜测部分可复用的逻辑点，如这里的字段绑定逻辑，可根据这里文本语义 NLP 猜测所属字段，部分图片元素根据有限范围内的图片分类，猜测所属对应的图片字段（如下图示例中的，氛围修饰图片还是 Logo 图片）；同时还可以识别可复用的业务逻辑组件，比如这里的领取优惠券逻辑。 所以，现阶段在业务逻辑生成中，可以解决的问题比较有限，尤其是新的业务逻辑点以新的逻辑编排出现时，这些参考依据都在 PD 的 PRD 或脑海中。所以针对业务逻辑的生成方案，现阶段的策略主要如下： 字段绑定：智能识别设计稿中的文本和图片语义分类，特别是文字部分。 可复用的业务逻辑点：根据视图智能识别，并由视图驱动自由组装，含小而美的逻辑点（一行表达式、或一般不足以封装成组件的数行代码）、基础组件、业务组件。 无法复用的新业务逻辑：PRD 需求结构化（可视化）收集，这是一个高难度任务，还在尝试中。 小结 目前用智能化的方式自动生成 HTML + CSS + 部分 JS + 部分 DATA 的主要分析如上，是Design to Code 的主要过程 ，内部项目名称叫做 D2C ，后续系列文章会使用此简称，集团内外的落地产品名称为 imgcook。随着近几年主流设计工具（Sketch、PS、XD 等）的三方插件开发能力逐渐成熟，飞速发展的深度学习那甚至超过人类识别效果的趋势，这些都是 D2C 诞生和持续演进的强大后盾。 目标检测 2014-2019 年 paper 技术方案 基于上述前端智能化发展概括分析，我们对现有的 D2C 智能化技术体系做了能力概述分层，主要分为以下三部分： 识别能力：即对设计稿的识别能力。智能从设计稿分析出包含的图层、基础组件、业务组件、布局、语义化、数据字段、业务逻辑等多维度的信息。如果智能识别不准，就可视化人工干预补充纠正，一方面是为了可视化低成本干预生成高可用代码，另一方面这些干预后的数据就是标注样本，反哺提升智能识别的准确率。 表达能力：主要做数据输出以及对工程部分接入 通过 DSL 适配将标准的结构化描述做 Schema2Code 通过 IDE 插件能力做工程接入 算法工程：为了更好的支撑 D2C 需要的智能化能力，将高频能力服务化，主要包含数据生成处理、模型服务部分 样本生成：主要处理各渠道来源样本数据并生成样本 模型服务：主要提供模型 API 封装服务以及数据回流 前端智能化 D2C 能力概要分层 在整个方案里，我们用同一套 数据协议规范（D2C Schema）来连接各层的能力，确保其中的识别能够映射到具体对应的字段上，在表达阶段也能正确地通过出码引擎等方案生成代码。 智能识别技术分层 在整个 D2C 项目中，最核心的是上述识别能力部分的 机器智能识别 部分，这层的具体再分解如下，后续系列文章会围绕这些细分的分层展开内部实现原理。 物料识别层：主要通过图像识别能力识别图像中的物料（模块识别、原子模块识别、基础组件识别、业务组件识别）。 图层处理层：主要将设计稿或者图像中图层进行分离处理，并结合上一层的识别结果，整理好图层元信息。 图层再加工层：对图层处理层的图层数据做进一步的规范化处理。 布局算法层：转换二维中的绝对定位图层布局为相对定位和 Flex 布局。 语义化层：通过图层的多维特征对图层在生成代码端做语义化表达。 字段绑定层：对图层里的静态数据结合数据接口做接口动态数据字段绑定映射。 业务逻辑层：对已配置的业务逻辑通过业务逻辑识别和表达器来生成业务逻辑代码协议。 出码引擎层：最后输出经过各层智能化处理好的代码协议，经过表达能力（协议转代码的引擎）输出各种 DSL 代码。 D2C 识别能力技术分层 技术痛点 当然，这其中的 识别不全面、识别准确度不高 一直是 D2C 老生常谈的话题，也是我们的核心技术痛点。我们尝试从这几个角度来分析引起这个问题的因素： 1、识别问题定义不准确：问题定义不准确是影响模型识别不准的首要因素，很多人认为样本和模型是主要因素，但在这之前，可能一开始的对问题的定义就出现了问题，我们需要判断我们的识别诉求模型是否合适做，如果合适那该怎么定义清楚这里面的规则等。 2、高质量的数据集样本缺乏：我们在识别层的各个机器智能识别能力需要依赖不同的样本，那我们的样本能覆盖多少前端开发场景，各个场景的样本数据质量怎么样，数据标准是否统一，特征工程处理是否统一，样本是否存在二义性，互通性如何，这是我们当下所面临的问题。 3、模型召回低、存在误判：我们往往会在样本里堆积许多不同场景下不同种类的样本作为训练，期望通过一个模型来解决所有的识别问题，但这却往往会让模型的部分分类召回率低，对于一些有二义性的分类也会存在误判。 ▐ 问题定义 深度学习里的计算机视觉类模型目前比较适合解决的是分类问题和目标检测问题，我们判断一个识别问题是否该使用深度模型的前提是——我们自己是否能够判断和理解，这类问题是否有二义性等，如果人也无法准确地判断，那么这个识别问题可能就不太合适。 假如判断适合用深度学习的分类来做，那就需要继续定义清楚所有的分类，这些分类之间需要严谨、有排他性、可完整枚举。比如在做图片的语义化这个命题的时候，一般图片的 ClassName 通用常规命名有哪些，举个例子，其分析过程如下： 第一步：尽可能多地找出相关的设计稿，一个个枚举里面的图片类型。 第二步：对图片类型进行合理归纳归类，这是最容易有争论的地方，定义不好有二义性会导致最有模型准确度问题。 第三步：分析每类图片的特征，这些特征是否典型，是否是最核心的特征点，因为关系到后续模型的推理泛化能力。 第四步：每类图片的数据样本来源是否有，没有的话能否自动造；如果数据样本无法有，那就不适合用模型，可以改用算法规则等方式替代先看效果。 D2C 项目中很多这样的问题，问题本身的定义需要非常精准，并且需要有科学的参考依据，这一点本身就比较难，因为没有可借鉴的先例，只能先用已知的经验先试用，用户测试有问题后再修正，这是一个需要持续迭代持续完善的痛点。 ▐ 样本质量 针对 样本 问题，我们需要对这部分数据集建立标准规范，分场景构建多维度的数据集，将收集的数据做统一的处理和提供，并以此期望能建立一套规范的数据体系。 在这套体系中，我们使用统一的样本数据存储格式，提供统一的针对不同问题（分类、目标检测）的样本评估工具来评估各项数据集的质量，针对部分特定模型可采取效果较好的特征工程（归一化、边缘放大等）来处理，同类问题的样本也期望能在后续不同的模型里能够流通作比较，来评估不同模型的准确度和效率。 数据样本工程体系 ▐ 模型 针对模型的召回和误判问题，我们尝试 收敛场景来提高准确度。往往不同场景下的样本会存在一些特征上的相似点或者影响部分分类局部关键特征点，导致产生误判、召回低，我们期望能够通过收敛场景来做模式化的识别，提高模型准确度。我们把场景收敛到如下三个场景：无线 C 端营销频道场景、小程序场景以及 PC 中后台场景。这里面几个场景的设计模式都有自己的特色，针对各个场景来设计垂直的识别模型可以高效地提高单一场景的识别准确度。 D2C 场景 过程思考 既然使用了深度模型，有一个比较现实的问题是，模型的泛化能力不够，识别的准确率必然不能 100% 让用户满意，除了能够在后续不断地补充这批识别不到的样本数据外，在这之前我们能做什么？ 在 D2C 的整个还原链路里，对于识别模型，我们还遵守一个方法论，即设计一套协议或者规则能通过其他方式来兜底深度模型的识别效果，保障在模型识别不准确的情况下用户仍可完成诉求：手动约定 > 规则策略 > 机器学习 > 深度模型。举个例子比如需要识别设计稿里的一个循环体： 初期，我们可以在设计稿里手动约定循环体的协议来达成 根据图层的上下文信息可做一些规则的判断，来判断是否是循环体 利用机器学习的图层特征，可尝试做规则策略的更上游的策略优化 生成循环体的一些正负样本来通过深度模型进行学习 其中手动约定的设计稿协议解析优先级最高，这样也能确保后续的流程不受阻塞和错误识别的干扰。 业务落地 2019 双十一落地 在今年的双十一场景中，我们的 D2C 覆盖了天猫淘宝会场的新增模块，包括主会场、行业会场、营销玩法会场、榜单会场等，包含了视图代码和部分逻辑代码的自动生成，在可统计范围内，D2C 代码生成占据了大比例。目前代码的人工改动的主要原因有：全新业务逻辑、动画、字段绑定猜测错误（字段标准化情况不佳）、循环猜测错误、样式自适应修改等，这些问题也都是接下来需要逐步完善的。 D2C 代码生成用户更改情况 整体落地情况 我们对外的产品 imgcook，截止 2019.11.09 日，相关的使用数据情况如下： 模块数 12681 个， 周新增 540 个左右； 用户数 4315 个，周新增 150 个左右； 自定义DSL：总数 109 个； 目前可提供的服务能力如下： 设计稿全链路还原：通过 Sketch、PhotoShop 插件一键导出设计稿图层，生成自定义的 DSL 代码。 图像链路还原：支持用户自定义上传图片、文件或填写图片链接，直接还原生成自定义的 DSL 代码。 后续规划 继续降低设计稿要求，争取设计稿 0 协议，其中分组、循环的智能识别准确度提升，减少视觉稿协议的人工干预成本。 组件识别准确度提升，目前只有 72% 的准确度，业务应用可用率低。 页面级和项目级还原能力可用率提升，依赖页面分割能力的准确度提升。 小程序、中后台等领域的页面级还原能力提升，含复杂表单、表格、图表的整体还原能力。 静态图片生成代码链路可用度提升，真正可用于生产环境。 算法工程产品完善，样本生成渠道更多元，样本集更丰富。 D2C 能力开源。 未来我们希望能通过前端智能化 D2C 项目，让前端智能化技术方案普惠化，沉淀更具竞争力的样本和模型，提供准确度更高、可用度更高的代码智能生成服务；切实提高前端研发效率，减少简单的重复性工作，不加班少加班，一起专注更有挑战性的工作内容！ 感兴趣的同学可加入钉钉群一起交流：21909696 D2智能化专场 今年的 D2 智能化专场将通过行业的应用案例和实践经验的风向，让大家对智能化改变前端有切实的感受，欢迎大家来一起探讨。 Tensorflow.js 前端的机器学习平台 演讲嘉宾：王铁震话题介绍：TensorFlow.js 是谷歌开发的机器学习加速平台。这个库用于在浏览器、Node.js 和其他 JavaScript 平台中训练和部署机器学习模型，为 JavaScript 开发者提供了简洁高效的API。在本讲中，您将了解到 TensorFlow.js 生态系统，如何将现有的机器学习模型植入到前端，同时还会探讨进一步优化的方式，未来发展的方向。 前端智能化实践 - 逻辑代码生成 演讲嘉宾：甄子话题介绍：从生成UI代码到生成逻辑代码有多远？如何用页面结构和数据结构的视角去看待并解决代码生成问题？如何赋予开发者自定义的能力来解决业务问题？用实践检验前端智能化的力量，用设计去论证前端智能化的未来，诚邀您一起探讨前端在机器学习和人工智能领域的发展。 数据分析的人工智能画板 - 马良 演讲嘉宾：言顾话题介绍：随着越来越多的企业重视数据可视化，通过降低工程门槛来帮助用户创建可视化大屏成为当前的一大趋势。然而除了工程成本，数据可视化的设计效率，极大影响着数据挖掘的效率。在此之上，由于多方技术人员的参与，沟通成本过大，导致流程耗时久，且难以迭代，极大限制了潜在用户以及潜在的可适用场景。对可视化大屏搭建平台来说，急需一款产品能够提高用户的数据可视设计能力，让用户突破模版限制，轻松创造属于自己的个性化大屏。 更多技术干货，关注「淘系技术」微信公众号！
2020年02月
发表了文章
2020-02-17 18:23:32
发表了文章
2020-02-14 13:30:00
发表了文章
2020-02-13 18:18:49
发表了文章
2020-02-13 11:06:50
发表了文章
2020-02-11 12:04:36
发表了文章
2020-02-06 17:31:11
发表了文章
2020-02-05 14:48:19
发表了文章
2020-02-04 15:45:23
发表了文章
2020-02-03 18:06:59
2020年01月
发表了文章
2020-01-20 17:38:29
发表了文章
2020-01-17 18:00:18
发表了文章
2020-01-17 17:57:43
发表了文章
2020-01-10 15:54:28
发表了文章
2020-01-10 13:54:40
发表了文章
2020-01-10 10:34:43
发表了文章
2020-01-07 15:37:07
发表了文章
2020-01-06 11:04:20
发表了文章
2020-01-03 16:37:42
发表了文章
2020-02-17
发表了文章
2020-02-14
发表了文章
2020-02-13
发表了文章
2020-02-13
发表了文章
2020-02-11
发表了文章
2020-02-06
发表了文章
2020-02-05
发表了文章
2020-02-04
发表了文章
2020-02-03
发表了文章
2020-01-20
发表了文章
2020-01-17
发表了文章
2020-01-17
发表了文章
2020-01-10
发表了文章
2020-01-10
发表了文章
2020-01-10
发表了文章
2020-01-07
发表了文章
2020-01-06
发表了文章
2020-01-03
发表了文章
2019-12-30
发表了文章
2019-12-27
