vs2012网站开发,济南做网站的网络公司,上海品牌营销咨询公司,百度云wordpress怎么搭建网站简介#xff1a; 淘宝的开放技术目前主要有两种形态#xff0c;第一种是小程序#xff0c;第二种是今天的主角小部件。它是基于小程序技术体系#xff0c;面向标准化、轻量化、高性能的开放卡片场景。本文我们将通过技术设计策略、核心技术设施、业务场景接入、技术演进路线…简介 淘宝的开放技术目前主要有两种形态第一种是小程序第二种是今天的主角小部件。它是基于小程序技术体系面向标准化、轻量化、高性能的开放卡片场景。本文我们将通过技术设计策略、核心技术设施、业务场景接入、技术演进路线这四个方面和大家分享它。 作者 | 千之 来源 | 阿里技术公众号 私域即品牌自运营的空间可以帮助品牌持续运营自己的消费者。淘宝也在快速调整私域的布局淘宝也有非常多的私域产品譬如店铺、客服、消息等。在这些场景中品牌商家需要利用创意、内容和服务留住消费者群体并产生销售转化。但是做私域并不仅仅只是纯销售更要用内容和服务把人留下来让场里的人越留越多这部分常驻人群才是「私域流量」。 商家和品牌通过持续稳定地提供优质内容以及购买产品的后续服务私域中的消费者比公域消费者能获得更大的价值也更容易产生复购和品牌忠诚度。 所以商家会迫切希望能够深耕淘宝的私域场景帮助自身更好地运营消费者。面对不同垂直行业不同属性的大量商家全量满足商家的个性化诉求会是一个海量的工作所以我们通过开放技术引入了三方生态来服务品牌和商家帮助他们构建自己的淘系私域。 通过淘宝的开放技术三方开发者可以为品牌商家制作创意内容和服务最后在私域被消费者所触达。 那什么是淘宝的开放技术 一 开放技术形态 淘宝的开放技术目前主要有两种形态小程序是其一淘宝基于小程序做了很多业务上的探索和技术上的实践。小程序承载了大量商家的个性化诉求通过小程序商家可以持续释放自身的创意并运营自身的消费者。小程序一定程度上解决了商家和消费者的连接问题。 再后来我们发现卡片形态更适合场景的开放诉求在讲究高效率的电商场一块前置并可以高度自定义的开放区域可以有效提升消费者的触达率。我们也在积极探索一种适合电商场景并且足够灵活、开放的卡片技术。 所以今天给大家正式介绍一下淘宝开放技术的第二种形态。 基于小程序技术体系面向标准化、轻量化、高性能的开放卡片场景我们在业界首次推出了全新的开放卡片技术「小部件」。 本文将从以下四点分别进一步阐述我们的一些技术思考。 技术设计策略核心技术设施业务场景接入技术演进路线 二 技术设计策略 开放业务场景拥抱技术红利释放商家创意提升经营效率。1 生产侧 小部件为开发者提供灵活、标准的技术选型。 小部件致力于解决场景卡片的开放问题为开发者提供灵活、标准的技术选型来支撑商家的个性化诉求并带来更具备体感的消费者体验。 面向与研发强相关的小部件 我们希望开发者在同一个 IDE 中可以完成小部件/小程序的研发、调试、预览、上传等功能所以「淘宝开发者工具」作为编辑工具与研发服务的结合平台提高工具、服务之间的串联效率一站式地帮助小部件的开发者提升整体效率。此外在游戏互动卡片这块开发者也可以直接使用游戏引擎的 IDE 来提高自身的研发效率。 开发者可以基于「淘宝开发者工具」的生产环境来构建自己的小部件小部件的整个生产流程也是对齐小程序的开发模式小部件积极拥抱三方开放生态开发者可以使用标准的小程序 DSL小部件的上层技术生态对齐小程序 Web 生态无缝支持小程序前端框架、游戏引擎的运行接入。 此外面对表单配置能力我们还在「淘宝开发者工具」支持了 JsonSchema 能力通过 JsonSchema 的开放小部件的开发者可以完成与小部件配套的商家端表单配置能力的研发配置表单帮助商家可以灵活控制小部件的前台属性和后台接口。 2 投放侧 卡片形态的小部件需要一套强大的投放系统来支撑。不同场景的小部件云信息下发需要一个中心化的平台来支撑基于这个中心化的平台小部件卡片可以被灵活投放到不同的业务场景下。 开发者入驻后选择自身需要研发投放的场景后可以获取不同场景的尺寸信息和视觉规范通过这层约束得以保证场景的消费者体验一致性。而对此小部件的开发者通过我们的适配方案后仅需简单适配即可完成产物交付实现一套代码多处运行的技术目标。 为此我们提供了一套完整的投放能力。当开发者完成小部件的交付并且审核通过后商家需要在商家端完成小部件的业务配置并投放到线上环境。商家可以自主选择投放的场景譬如店铺、会员、订阅、直播等等。 前台的业务场景服务端对接投放系统完成之后即可完成场景的小部件投放。 3 运行侧 卡片本身的特殊性导致了对渲染、性能、体验的要求极高。小部件容器提供了高效、稳定的环境来保证业务代码的执行效率。 能力方面通过基础库技术协议的对齐所有的基础/业务 API 能力我们都保证了对小程序容器的复用并且和支付宝小程序容器保证了接口标准的一致性。这意味着开发者可以几乎 0 成本地调用所有小程序开放出来的 API 能力并获得和小程序完全一致的体验。 渲染方面传统的 WebView 渲染方案在卡片形态下会比较厚重多个卡片共存同一场景下的内存和体验问题也无法得到很好解决。为此我们重新设计了一套更适合卡片场景的渲染方案相对于小程序的 WebView 渲染引擎我们在卡片场景中替换为全新的渲染引擎即 Weex2.0。 通过 Weex2.0 的跨平台渲染能力我们在 iOS 和 Android 上保持了极高的一致性。三方场景的特殊性会导致卡片本身的技术容错率很低所以从性能和复杂度角度出发的角度考虑我们也收敛了整体 CSS 样式的支持度。整体样式能力的规范的整体设计很大程度上兼容 W3C 标准实现了一部分子集在子集范围内的功能都和标准一致。 此外小部件的运行安全也是非常重要的为此我们引入了沙箱机制。通过沙箱机制我们得以保证不同的小部件环境之间是互相隔离并不互相影响的通过底层技术的复用我们也合并了多个 JavaScript 虚拟机的创建保证性能和效率能够最大化。 三 核心技术设施 接下来展开讲讲我们的核心技术设施这里包括脚本引擎、渲染引擎还有图形引擎。1 脚本引擎 小部件的技术产物是 JavaScript 源文件小部件中我们使用了 QuickJS 虚拟机作为脚本执行引擎。基于 QuickJS我们可以获取一个轻量并且高效的 JavaScript 执行环境。相较于庞大的 V8 引擎QuickJS 虚拟机的启动性能和包大小收益都远远超出我们的预期。 在卡片场景下脚本引擎的快速启动是一个非常重要并且迫切的任务所以基于 QuickJS 虚拟机我们做了大量的定制和优化工作。 在虚拟机层面的优化工作有助于我们使用新的技术特性来加速基于「ByteCode」机制我们已经考虑在小部件构建的时候把 JavaScript 源码预编译为二进制来加速整体的渲染。此外我们也在推进标准字节码的设计工作通过字节码的优化可以获取加载速度与代码体积的双重优化。 同样在面向脚本引擎的接口这层我们统一对接了集团标准「JSI」。通过 JSI 的帮助我们可以实现不同 JavaScript 引擎之间的切换并且可以帮助我们在异构容器下实现同构的标准编程。 2 渲染引擎 渲染引擎是小部件的核心 我们使用了淘宝自研的渲染引擎「Weex2.0」Weex2.0 的前身是 Weex1.0相对于1.0 的 系统 UI 渲染2.0 上我们全面切换到了跨平台 C 自绘方案。通过 C 的跨平台开发我们在原生层面使用 C 实现了组件化、MVVM、声明式模板、响应式更新等复杂功能也顺便抹平了 iOS 和 Android 上平台相关的组件差异。 接口注册层面我们通过 JS Binding 直接把原生渲染接口注册绑定到 JavaScript 环境中几乎没有序列化成本。C 框架下沉以后可以更加细粒度的实现节点更新和回收复用。 渲染管线上我们借鉴了 Flutter Engine 的线程模型及布局算法最后会被提交到 Skia 本身的渲染流程上。这部分工作的复用有助于我们快速实现落地此外由于我们的渲染管线是面向 Web 的技术特点设计没有 Flutter FrameWork 中的 Dart Widget 概念更加贴合前端的技术栈。 3 图形引擎 Canvas 是 Web 生态中非常重要的组件适用于富交互并且注重互动体验的业务场景譬如游戏互动、3D渲染、图表绘制、AR渲染等图形场景。 Canvas 能力在小部件中是一个独立的组件得益于 Weex2.0 的 Platform View 机制我们在自绘的引擎中实现了同层渲染 Canvas 能力。Canvas 本质是一个 W3C 图形渲染标准面对这套标准淘宝同样自研了一套图形引擎实现「FCanvas」FCanvas 支持 WebGL 和 Canvas2D 两套标准跨容器且高性能的 FCanvas 的图形渲染能力我们对小部件也一并开放。同样Canvas2D 下和 Weex2.0 同样直接对接了 Skia 图形库。 通过小程序标准的对齐和底层 SDK 的改造我们完全兼容并支持了小程序中的游戏引擎生态。也就意味着游戏的开发者可以直接通过我们支持的游戏引擎 IDE 自助生成小部件工程卡片级别的互动游戏非常适合前置在业务场景中做投放。 四 业务场景接入 小部件是卡片那嵌入卡片的「场」自然很重要。在淘宝内目前有多个业务场景支持了小部件的投放这里面包括店铺、会员、直播、订阅等等。因为场景业务的特殊性目前多个场景的渲染方案不尽相同这里面涉及了 DX 渲染、H5 渲染、Weex 渲染、小程序渲染等多套技术方案。 面对纷杂的渲染环境这里面没有捷径。我们也思考过在不同的场景下使用对应的场景渲染方案的优劣这样会带来两个问题。 我们判断不同的渲染方案对接到一套 DSL 上的技术可行性较低相对而言这样会破坏小部件的技术一致性消费者的前台体验也无法得到保证。此外多场景的技术维护性成本会持续增长开放业务的特殊性决定了三方开发者的忍受阈值相对很低会引入大量额外排查成本。 由此在不同的渲染方案下我们都分别封装了对应的组件通过组件的调用再实现小部件的嵌入。这种方式前期成本相对而言较高但对于跨场景一致性会得到保证开发者也可以避免关心场景的渲染只需要专注于完成自身业务逻辑的开发即可。 五 技术演进路线 主要围绕三个关键词性能、场景、效率来展开。1 优化性能体验 卡片场景对加载性能和运行性能会非常敏感所以我们会持续优化技术性能针对卡片场景进一步优化内存占用并提升整体运行性能充分释放商家的创意和提升开发者的灵活度。 降低图形内存占用通过 FCanvas 的资源整合和管线优化来降低内存占用此外我们会面向开发者提供最佳实践的手段来帮助开发者合理使用。提升首屏加载速度脚本引擎的性能优化会涉及两部分工作一部分是预编译能力的支持一部分是运行时「JIT」能力支持还有的就是渲染引擎的进一步瘦身运行时优化加载任务队列支持低优先级和不必要的资源懒加载。引入小程序插件能力目前小程序的插件生态还是亟需支持我们在考虑通过 API 的方式支撑插件生态的接入可以帮助开发者直接使用会员、任务、人群等插件能力。 2 覆盖更多场景 小部件会继续拓展接入更多场景尤其是商品详情页这种高频高转化的场景也会逐步开放公域部分场景。 对商家来说可以满足商家自身多元化的经营诉求并有机会从公域收获额外的流量提升品牌经营的水位线。对于场景来说可以积极拥抱三方开放生态通过小部件的通投能力形成商业要素的结构化沉淀和利用。对于开发者来说可以帮助开发者在多赛道持续收获商业收益实现自身效益和效率最大化。 3 提升流通效率 在目前电商场流量逐步稳定的情况下我们需要更好地帮助商家管理好营销预算和收益提升卡片本身的流转效率至关重要这样能帮助商家提升整体的投入产出比。 帮助开发者降低研发成本并帮助商家提升效益进一步提升卡片流通效率。使得卡片在不同场景的分发和流转提升效率并建立相应的配套设施最大化一个卡片的商业价值。 原文链接 本文为阿里云原创内容未经允许不得转载。