bt365体育投注.主頁欢迎您!!

    <acronym id="zvmrr"></acronym>
    <td id="zvmrr"></td>
  • <tr id="zvmrr"><label id="zvmrr"></label></tr>
  • <acronym id="zvmrr"></acronym>
  • 凹凸实验室

    凹凸实验室 查看完整档案

    深圳编辑  |  填写毕业院校京东  |  全栈开发工程师 编辑 aotu.io/ 编辑
    编辑

    凹凸实验室(Aotu.io,英文简称O2) 始建于2015年10月,是一个年轻基情的技术团队。

    O2面向多终端技术体系,致力于构建沉淀与分享包括但不限于交互、页面制作技巧、前端开发、原生APP开发等方面的专业知识及案例。

    求简历:aotu@jd.com

    个人动态

    凹凸实验室 发布了文章 · 1月15日

    凹凸技术揭秘 · 基础服务体系 · 构筑服务端技术中枢

    前言

    凹凸实验室从最初的前端团队成长为如今的全端团队,意味着我们不仅关注前端的技术能力,也重视全端及全栈的能力。在这一篇,我们从前端团队角度出发,阐述我们最初搭建服务端体系遇到的一些困难,已构建的服务体系架构,以及如何更好地助力业务增长。

    些许似曾相识

    首先,我们来看下日常工作中存在的一些场景。

    • 场景A:在某些业务中,底层数据团队提供的数据接口并没有提供 HTTP 调用,需要去寻找其他服务端团队来封装,这时候需要等待其他团队排期,可能造成业务无法正常上线;
    • 场景B:前端页面性能卡顿,由于调用接口过多,需要等待其他服务端团队聚合数据;
    • 场景C:我们在一些项目需要SSR,前后端需要复用统一套模板;
    • 场景D:我们内部孵化了一些项目,需要接口服务,需要等待其他服务端团队支持。

    这些场景的背后,我们急需组建一个服务端研发团队来承担部分的业务服务开发以及更好地帮助团队未来发展。

    成型

    在团队组建上,主要采用「内部选拔」 + 「外部招聘」2 种方式。在团队发展上,我们主要经历了 3 个阶段。

    雏形

    在最初的阶段,选择以 NodeJS 作为服务端编程语言,主要以下有 2 点考虑:

    1. 团队大部分同学熟悉 Javascript,能够快速学习 NodeJS,上手成本较低;
    2. 在 SSR 方面有天然的优势,前后端能够共用部分代码。

    在这个阶段,我们快速孵化了一系列的系统和平台,比如 Mock 平台、前端监控平台、兜底平台等等,主要目标丰富前端研发体系,提升前后端的开发及协作效率,同时也沉淀了一些 NodeJS 中间件。

    成长

    在服务开发效率、性能、稳定、安全等方面有了一定的沉淀之后,我们开始思考如何更加规范服务开发,更加高效地支撑业务增长。

    在这个阶段,我们不仅输出了「研发规范」、「研发流程」、「开发框架」等一系列的知识体系,也搭建了「部署平台」、「通用管理平台」等相关研发平台。在业务开发上,我们用 NodeJS 实现了「天狗」游戏服务、用 OpenResty 实现了「数据聚合服务」、在某些频道上采用了 SSR 等等。

    赋能

    在设计中台中,我们沉淀了大量的通用服务,比如「页面」、「图片」、「编译」相关的服务,部分服务赋能给了其他团队,比如说我们将页面智能设计相关的服务赋能给了「江湖平台」、「智铺」等产品。

    在公司内部,大部分的服务端团队技术栈主要是 Java,在服务间调用采用了集团内部自研的 JSF 协议。而我们团队主要技术栈依然以 NodeJS 为主,给其他团队提供 HTTP 调用,与 Java 在接入方式、限流、代码提醒等方面存在较大差异,也无法很好利用集团内大量的中间件。

    在这个阶段,我们引入了 Java 技术栈,形成了以「NodeJS + Java」为主要服务端语言的技术体系。针对部分领域服务,我们提供了 Java 版本的 JSF 服务实现,方便第三方团队沟通合作。

    体系结构

    经过几年的沉淀,我们团队在服务端领域构建出了初步的体系结构。

    服务端研发体系的建设,主要目标是为了提升团队代码的下限,提升开发效率,提高服务交付质量,促使团队共同成长。

    system

    构建一套服务端研发体系,主要围绕 8 个方面展开,包含研发规范、研发平台、研发流程、文档建设、团队管理、监控告警、中间件管理以及基础设施。

    platform

    在整体服务架构上,我们日常的开发采用分层结构的模式,尽可能去抽离出通用的服务逻辑,输出更多的积木,降低我们的开发和维护成本。

    以下从「业务支撑」和「技术建设」方面去简单阐述我们近几年在服务端领域的一些探索和实践。

    业务支撑

    业务是团队的立命之本,只有在业务的快速增长中才能不断去验证和优化我们整个服务体系,保证整体服务的可靠性。

    羚珑服务

    羚珑全称羚珑智能设计平台,提供一站式在线设计服务:一键抠图、免费抠图、商品打腰带、改尺寸、商品主图设计、线上广告banner设计、店铺首页设计、活动页设计、页面设计、互动营销设计、小程序设计、动图视频设计、视频广告设计、商品主图视频设计、海报设计、公众号配图设计、二维码名片设计、DM传单设计、物流面贴设计、易拉宝设计、张贴海报设计等等。提供海量精美模板和免费素材,免费设计,另设有企业专区,是致力于成为商家经营的设计合作伙伴的平台。

    其下的羚珑智能页面设计是集结业内各色资深电商行业设计师,提供一站式专业智能页面和小程序设计服务的平台。整个架构服务轻量化、模块化,更便捷拓展专区业务场景。服务架构如下:

    服务架构图

    整体架构分为 Web 应用层、接口层、服务层和数据层四部分,这样拆分能做到入口统一,在部署上单点部署让发布更加便捷,独立部署则降低模块更新对整体服务的影响:

    • Web 应用层:包括羚珑及其他的平台应用;
    • 接口层:提供网关服务,应用层的请求经由网关,通过权限校验,转发到各个模块去;
    • 服务层:主要分为下面四部分:

      • 服务通信:异步通信使用 MQ,RPC 通信采用 HTTP 调用的方式;
      • 业务模块:也即服务的核心逻辑,它们被按照功能逻辑划分成不同的模块,模块内独立地处理大部分功能,达到高内聚低耦合的效果;
      • 基础服务:支撑业务模块的基础功能,统一把控用户与权限;
      • 服务管理:用于服务辅助,提升服务的稳定性、健壮性和灵活性。
    • 数据层:服务主要使用到了 MongoDB 和 Redis,前者为主要存储,后者用于数据缓存。

    项目使用 Typescript 开发,遵循统一的接口规范,保证出入参的风格统一,模块化的设计让服务运维和迭代轻松,在功能上,支持专区和场景的插拔式拓展,让业务变得无限可能。

    数据聚合服务

    在电商的业务中,比如频道、大促活动这种类型的业务会经常使用到商品组、广告组的数据,在通用的接口里面会出现较多冗余的字段,特别在批量查询服务的时候,整个响应包会比较大。

    我们采用 OpenResty 实现了 GraphQL 服务,数据按需加载,能够有效减少数据包大小;数据自动兜底,能够保障服务可用性,尤其在大促期间底层服务出现响应慢的情况下。

    o2api

    技术建设

    必要的基础建设和技术探索,是为了更好地帮助业务和团队面向未来。

    以下围绕「Talos部署平台」和「通用管理平台」来阐述我们在服务端方面的一些基础建设。

    Talos 部署平台

    Talos 部署平台基于内部的 JDOS 平台开发而来,主要是提供应用资源管理和部署功能,解决部署难、开发效率低、服务运维成本高等问题,使研发同学更专注于开发。

    主要架构图如下:
    Talos 框架图

    我们从「资源管理」、「应用部署」这两个方面来简单介绍下该平台。

    资源管理

    Talos 项目分组

    项目分组功能,可方便开发者管理以及查看分组下应用、流量、资源占用等情况。

    Talos 静态网站部署方式

    静态网站部署支持将静态网站应用部署至同一后端应用中,浏览器访问时根据域名或者前置路由匹配对应文件,达到节省资源,提高资源利用率的目。

    除此之外,还有其他的一些功能:

    • 提供 Talos 网关,方便服务转发及挂载;
    • 提供 MongoDB 可视化面板功能,方便开发同学查看线上数据库,提供只读、读写等权限;
    • 提供全流程监控功能,包括应用创建、部署、容器调整等,运行过程中 cpu、磁盘、负载等超过阈值也会告警;
    • 其他还有容器数量调整、大促时上线限制、通知等功能。
    应用部署

    支持多环境部署,可设置测试、预发、生产等环境,每个环境下有各自单独的配置文件、配置属性字段等,支持一键部署、回滚、下线等操作,部署界面如下图:

    Talos 应用部署

    支持不同项目类型部署,如 NodeJS、静态站点、自定义部署等。

    Talos 不中断部署

    支持不中断部署,利用 JDOS 的滚动更新接口,控制流程切换,将应用容器分为前后两批滚动更新,确保更新过程中应用不会中断。

    通用管理平台

    在开发过程中,往往需要硬编码一些数据,而大多数的数据在以后的维护、运营中时不时需要更新。过去我们经常被这些琐碎的修改数据给占用了些时间,降低了编码效率。解决这个问题有两种方式,第一种在数据库中存储变更数据,开发对应服务端接口进行 CRUD。这种方式我们需要的资源有数据库、服务端开发、网关域名,这么看来得不偿失了。而第二种就是在平台中动态配置表单,定义数据结构,再录入数据,同时平台提供统一的 CRUD 网关 API。在上述的背景下,通用内容管理平台应运而生。下面来看看提供了哪些实用的功能!

    通用管理平台提供了表单、数据创建,满足了大部分配置管理功能;同时提供了权限管理功能,可以供产品/运营同事更新数据,摆脱让开发同学修改数据/版本发布的烦恼。

    通用管理平台大纲

    数据表单 - 数据结构定义
    为什么要有表单,而不是直接存 JSON 数据呢?想象下在 MongoDB 数据库中,假如不能使用 Mongoose 等 ORM 框架进行数据的定义,只能通过阅读数据或者通过分离的文档进行理解表结构设计的意义,那样一定非常痛苦。

    创建表单

    表单的功能主要分为表单的字段设计、用户权限管理和表单标识编辑。其中字段设计提供了类似于关系型数据库的 Schema 设计,用户可以创建对应表结构的字段的类型、默认值,甚至可以通过正则表达式对数据进行校验。

    表单管理

    数据 - 数据存储

    数据模块提供的功能包括了数据录入、数据同步(不同环境)、版本管理和获取 API 链接的功能。

    • 数据录入:录入数据时根据表单的字段规则进行校验,防止同一个表单内的数据不一致情况;
    • 数据同步:平台上提供了两个环境,预发和正式。用户可以进行两个环境的数据全量同步和部分同步;
    • 版本管理:像大多数内容管理平台一样,为了防止用户的误操作或者是恢复旧版本数据,提供了该功能;
    • API 链接:在录入数据之后,通过该链接便可以访问录入的数据。

    通用管理平台帮助文档

    以上介绍了通用管理平台的功能点,在实践中有大量的应用接入,其中便有羚珑、Jelly、Taro、Quark 等等优秀的项目。

    结语

    目前为止,我们在服务端领域的积累和沉淀还只是冰山一角,需要进一步探索和沉淀,未来会更聚焦服务积木化,输出更多可复用、可赋能的积木,为业务增长保驾护航。

    凹凸揭秘系列文章地址

    1.《凹凸实验室的过去与未来》

    2.《凹凸技术揭秘·羚珑智能设计平台·逐梦设计数智化》

    3.《凹凸技术揭秘 · Deco 智能代码 · 开启产研效率革命》

    4.《凹凸技术揭秘·羚珑页面可视化·成长蜕变之路》

    5.《凹凸技术揭秘 · 夸克设计资产 · 打造全矩阵优质物料》

    6.《凹凸技术揭秘 · Tide 研发平台 · 布局研发新基建》

    7.《凹凸技术揭秘 · Taro · 从跨端到开放式跨端跨框架》

    8.《凹凸技术揭秘 · 基础服务体系 · 构筑服务端技术中枢》


    欢迎关注凹凸实验室博客:aotu.io

    或者关注凹凸实验室公众号(AOTULabs),不定时推送文章。

    查看原文

    赞 4 收藏 2 评论 0

    凹凸实验室 发布了文章 · 1月15日

    凹凸技术揭秘 · Taro · 开放式跨端跨框架之路

    承载 Web 的主战场转移

    2017 年 1 月 9 日凌晨,微信正式推出小程序,为移动端家族增加了新的业务形态和玩法,当大家还在探讨这一新兴平台能做什么的时候,京东率先上线了「京东购物」小程序,随后,更多的电商行业执牛耳者纷纷入驻小程序,从此,承载电商的主战场逐渐从需要自建流量的移动端 APP 向小程序倾斜。

    小程序的出现,为电商行业的研发带来了巨大的挑战。继微信之后越来越多的头部流量互联网公司纷纷盯上小程序这一蛋糕,相继推出了各自的小程序平台,比如京东、阿里、百度、字节跳动、360等等,为了让我们的电商业务能快速移植到这些小程序平台,帮助我们的业务快速拓展渠道,我们开始了新的尝试。

    我们开始尝试使用技术的手段,探索一种能够统一所有平台的新技术。

    披荆斩棘——初代架构诞生

    用 React 写小程序?

    前面有提到,为了解决各大小程序平台带来的多端开发的痛点问题,社区先涌现出了 WePympvue,那我们为什么不直接采用,而要选择“造轮子”呢?

    在当时的前端界言及前端框架,必离不开依然保持着统治地位的 ReactVue,这两个都是非常优秀的前端 UI 框架,而且在网上也经常能看到两个框架的粉丝之间热情交流,碰撞出一些思想火花,让社区异常活跃。

    而我们团队也在 2017 年勇敢地抛弃了历史包袱,非常荣幸的引入了 React 技术栈。这让我们团队丢掉了煤油灯,开始通上了电,远离了刀耕火种的前端开发方式。为了解决当时业务环境对极致性能以及低版本 IE 浏览器兼容性的要求,我们还研发出了一款优秀的类 React 框架 Nerv ,并因此对 React 开发思想以及技术栈理解更加深刻。

    遗憾的是,当时社区并没有一款使用 React 开发小程序的框架。

    与小程序的开发方式相比,React 明显显得更加现代化、规范化,而且 React 天生组件化更适合我们的业务开发,JSX 也比字符串模板有更强的表现力。那时候我们开始思考,我们能不能用 React 来写小程序?

    理性地探索

    通过对比体验 小程序和 React ,我们还是能发现两者之间相似的地方,比如生命周期、数据更新方式以及事件绑定,都具有非常多相似的地方,这为我们使用 React 来小程序提供了非常良好的基础。

    但是,我们也应该看到小程序和 React 之间的巨大的差异,那就是模板。在 React 中,是使用 JSX 来作为组件的模板的,而小程序则与 Vue 一样,是使用字符串模板的。这是两种完全不一样的东西,也是我们方案探索上的巨大障碍。所以,为了实现使用 React 来写小程序这一目标,我们必须解决两者之间巨大差异的问题。

    解决差异

    既然微信不支持 JSX,那我们只需要将 JSX 编译成小程序模板不久可以在微信上运行了吗,这一步可以通过 Babel 来实现。

    Babel 作为一个 代码编译器 ,能够将 ES6/7/8 的代码编译成 ES5 的代码,其的编译过程主要包含三个阶段:

    • 解析过程,在这个过程中进行词法、语法分析,以及语义分析,生成符合 ESTree 标准 虚拟语法树(AST)
    • 转换过程,针对 AST 做出已定义好的操作,babel 的配置文件 .babelrc 中定义的 presetplugin 就是在这一步中执行并改变 AST 的
    • 生成过程,将前一步转换好的 AST 生成目标代码的字符串

    再次回到我们的需求,将 JSX 编译成小程序模板,非常幸运的是 babel 的核心编译器 babylon 是支持对 JSX 语法的解析的,我们可以直接利用它来帮我们构造 AST,而我们需要专注的核心就是如何对 AST 进行转换操作,得出我们需要的新 AST,再将新 AST 进行递归遍历,生成小程序的模板。

    以上仅仅是我们转换规则的冰山一角,JSX 的写法极其灵活多变,我们只能通过穷举的方式,将常用的、React 官方推荐的写法作为转换规则加以支持。

    初代架构诞生

    经过我们一次次的探索,我们已经可以将类 React 代码转成可以在小程序环境运行的代码了。但是我们激动之余,冷静下来继续思考,我们还能不能干点别的有意思的事情呢。

    我们发现,在平常的工作中,我们业务通常有一些“多端”的需求。就是同一个业务或页面,需要同时适配 小程序、H5 、甚至 React Native 。这个时候,你就会发现,差不多的界面和逻辑,你可能需要重复写上好几轮。

    因此,我们希望希望在解决使用 React 开发微信小程序的同时,还能同时是适配到 H5 端、移动端、以及各平台的小程序。Write once, run anywhere,相信是所有工程师的梦想。

    但是仔细思考我们又会发现,仅仅将代码按照对应语法规则转换过去后,还远远不够,因为不同端会有自己的原生组件,端能力 API 等等,代码直接转换过去后,并不能直接执行,还需要运行时的适配。因此,我们按照微信小程序的组件库与 API 的标准,在其他端(H5、RN)分别实现了组件库和 API 库。

    Taro 1 架构

    Taro 从立项之初到架构稳定差不多用了三个月左右的时间,从最初的激烈讨论方案,各种思想的碰撞,到方案逐渐成型,进入火热的开发迭代,再到现在的多个平台小程序端、H5 端和 RN 端的顺利支持,Taro 的未来已来。

    初露锋芒——GitHub 开源

    2018 年 6 月 7 日,多端统一开发框架 - Taro 正式开源。

    作为首个支持以 React 语法写微信小程序并适配到多端的开发框架,Taro 一鸣惊人。 开源不到两个月,在 GitHub 上有 6600 多个 Star,连续数周霸榜 Github Trending;同时已经处理近 300 个 Issue ,还有 100 多个在等待反馈与优化;在公司内、外主动反馈的使用 Taro 的项目已有十多个。

    截至 2019 年 12 月 18 日,Taro 已拥有 22254 Stars 和 250 名 Contributors,社区主动提交的开发案例 150+:taro-user-cases,其中不乏多端案例。

    截止 2021年 1 月 11 日,Taro 已拥有 27914 Star ,位列小程序开发框架前列。

    Taro 团队不断跟进社区里提出的问题和反馈,一直保持着高速迭代,并围绕 多端适配、开发体验以及社区共建 三个方面持续优化 Taro 框架。

    为了方便开发者快速开发项目,我们基于 Taro 推出了业内首款小程序多端组件库 Taro UI

    Taro UI 二维码

    在多端适配方面,我们一直持续跟进,成为社区适配端最多的小程序开发框架。

    为了更好的开发体验,我们支持了 React Hooks、CSS Modules、Mobx 等。

    在社区共建方面,我们推出了 Taro 论坛、Taro 物料市场等平台,后面发布了 社区共建计划

    在跟进业务的同时,我们还需要不断跟进社区里提出的问题和反馈,因而就要不断加班加点地去完成,虽然有时会觉得很累,但是技术上的成就感以及能帮助到更多开发者时的满足感还是不断地激励着我们前进,让 Taro 项目越来越好。

    筚路蓝缕——一段痛苦摸索的升级之旅

    Taro 在 GitHub 上开源之后虽然收获了非常多的赞誉,短短的时间内就突破了 10000 Stars,但由于 Taro 初期的自定义组件架构设计得非常复杂,导致使用组件开发的时候总会引起非常多的问题,一直为许多用户诟病。

    在 Taro 设计的初期,由于微信小程序刚推出的自定义组件功能并不完善,实现不了传入自定义函数等问题,无法满足组件化灵活使用的需求,所以 Taro 的组件化架构是采用 template 标签来实现的。

    使用 template 方案来实现的组件化架构在通常情况下运行良好,但面对复杂循环嵌套输出组件的时候则问题频出,主要原因是:

    • JS 逻辑与模板隔离,需要分别处理,导致组件传参非常麻烦,难以对齐
    • template 实现的自定义组件无法嵌套子组件

    所以,在 Taro 最初的时光,自定义组件的问题一直是我们抹不去的痛,作为官方团队,在痛苦思索解决方案的同时,还要面对社区不断的问题反馈和质疑,让我们总觉得前途一片灰暗。

    但前人的经验告诉我们,不能就此放弃,鲁迅先生曾经说过「此后如竟没有炬火,我便是唯一的光」。我们在 template 方案挣扎良久之后,终于还是将目光投向了小程序自带的自定义组件身上。

    正所谓山穷水复疑无路,柳暗花明又一村,小程序的自定义组件恰好有了一波更新,经过数个日夜加班探索之后,之前困扰我们的问题都得到了一一解决,完美实现了新的自定义组件架构,带来了更加稳定的版本。

    在新的架构中,我们会把 Taro 的组件直接编译成小程序的原生组件的 Component 方法调用,再通过运行时的适配,来对组件参数、生命周期适配、以及事件传入等进行处理,借助小程序的组件化能力来实现 Taro 的组件处理。

    经过这一版方案重构之后,Taro 的稳定性与可靠性得到了质的飞跃,社区的好评声不断,而 Taro 的关注数也得到陡峭的增长。这一版架构方案也成了 Taro 持续时间最久的方案,为 Taro 日后成为「一款值得信赖」的多端方案打下了坚实的基础。

    这是一段筚路蓝缕的艰苦创业之旅,对于 Taro 团队来说也是一段非常宝贵的经验。没有一直一帆风顺的旅途,唯有不轻言放弃和勇于开拓才能云开见日,让我们走的更远。

    高歌猛进——不断地突破自我

    在完成了自定义组件架构的改造之后,Taro 开始了全速发展之路。

    在 2018 年 11 月份,Taro 推出了 1.1 版本,完成了百度、支付宝小程序的适配支持,成为业界首个同时适配多个小程序平台的多端开发框架,并且在适配期间,Taro 团队和百度、支付宝小程序官方团队建立了联系,为对方小程序的发展提出了非常多的建设性意见。与此同时,Taro 成为百度小程序官方推荐使用框架之一。

    而短短一个月之后,2018 年 12 月份,Taro 火速推出了 1.2 版本,这是一个非常具有创新意义的版本,在这个版本中,Taro 首创了小程序原生代码反向转换技术,能够将小程序原生代码反向转换成 Taro 代码。原有的微信小程序通过 Taro 转换,就能快速移植到其他平台,这为业务的快速扩张提供了巨大的想象空间,为业务的高效交付提供了极大的助力。

    而「京东快递」业务正是反向转换特性成功应用的一个典范案例。最初「京东快递」只有微信小程序平台,通过 Taro 的反向转换特性,以极低的成本快速移植到百度、头条小程序平台,并且可以只维护一份代码,同时维护 3 端应用,极大地降低了维护成本。

    在 Taro 1.2 发布之后,Taro 在业界收获了巨大的赞誉和关注:GitHub 上 Stars 数量超过 19000 粒,NPM 下载量也稳居同类开发框架之首,同时 Taro 团队也和腾讯、百度、华为等数十家业界巨头的研发团队展开了深入和有效的合作。

    时间匆匆而逝,来到了 2019 年 6 月,时隔半年,我们终于发布了 Taro 1.3,这是我们酝酿最久的版本:经历了横跨 6 个月的开发时间,近 2000 次的代码提交,同时有近百位开发者的共同参与。在 Taro 1.3 中,我们不仅仅带来了对 QQ 小程序的支持,同时还支持了快应用,成为业界支持平台最多的多端开发框架,而更重要的是,在这个版本中我们成功将业界火热的 React Hooks 搬到了 Taro 中,支持让用户使用 React Hooks 的方式来开发小程序,成为业界首创。

    从 Taro 正式版发布,到 Taro 1.3,可以看出 Taro 一直不断使用创新的理念打磨自我,以创新为使命,为业界带来体验优异的多端开发解决方案。

    拥抱变化——为未来思考

    尽管 Taro 一直保持超高的迭代速度,但自从自定义组件架构改造之后,Taro 的整体架构设计没有发生太大变化,这让 Taro 在这个时刻在变化的时代稍显佛系,且对于一个时刻想要突破自己的技术团队来说,常规性质的维护工作,显然无法安抚我们躁动的心,毕竟人的梦想,是永远不会停止的,所以我们决定启动一系列的颠覆式重构设计。

    我们首先从 CLI 开始入手进行改造,众所周知,原来 Taro CLI 的编译构建系统是自研的,整个构建系统逻辑复杂,要考虑的边际条件众多,这就导致了以下问题:

    • 维护困难,每次需要新增一个功能,例如支持解析 Markdown 文件,就需要直接改动 CLI,不够灵活
    • 难以共建,CLI 的代码非常复杂,而且逻辑分支众多,让很多想要一起共建的人难以入手
    • 可扩展性偏低,自研的构建系统,设计之初没有考虑到后续的扩展性,导致开发者想要添加自定义的功能无从下手

    基于以上问题,我们决定使用 Webpack 来实现编译构建,于是诞生了 2.0

    Taro 2.0 的 CLI 将会变得非常轻量,只会做区分编译平台、处理不同平台编译入参等操作,随后再调用对应平台的 runner 编译器 做代码编译操作,而原来大量的 AST 语法操作将会改造成 Webpack Plugin 以及 Loader,交给 Webpack 来处理。

    相较于旧的构建系统,新的小程序编译带来了以下优势:

    • 利于维护,大量的逻辑交由 Webpack 来处理,我们只需要维护一些插件
    • 更加稳定,相较于自研的构建系统,新的构建会更加稳定,降低一些奇怪错误的出现概率
    • 可扩展性强,可以通过自行加入 Webpack Loader 与 Plugin 的方式做自己想要的扩展
    • 各端编译统一,接入 Webpack 后,Taro 各端的编译配置可以实现非常大程度的统一

    可以看到新的构建系统会有很大的进步。同时,更重要的是,基于 Webpack,我们可以在小程序中尝试更多的特性与技术,例如通过 tree shaking 来优化代码包大小等等,让小程序开发更加与业界发展同步,让 Taro 更加拥抱社区。

    Taro 2.0 只是一个开始。

    在 10 年代最后一场 GMTC 全球大前端技术大会上,Taro 团队向大家展示了 小程序跨框架开发的探索与实践 的艰辛旅程,同时也提前曝光了正在紧密开发中的 Taro Next。

    那是一个完全区别于以往的版本,一条与现在 Taro 截然不同的道路,预示着 Taro 正在革自己的命。

    节物风光不相待,桑田碧海须臾改。

    20 年代呼啸而来,下一个 10 年,很多框架都会死去,很多技术也会焕然而生,没有什么是不变的,唯一不变的只有变化,我们能做的也只能是拥抱变化,为未来思考。

    乘风破浪——新架构起航

    正如前文所提到的,Taro 迎来了全新的架构。

    不同于 Taro 1、2 时代的架构,新的架构主要基于运行时,我们都知道使用 React 开发 web,渲染页面主要依靠的是 react-dom 去操作 DOM 树,而 React Native 依靠的是 Yoga 布局引擎,但是我们却能通过 React 将他们联系在一起,这主要是通过抽象的 Virtual DOM 技术来实现的,通过 Virtual DOM 达到跨平台统一的目的。而小程序中虽然没有直接暴露 DOM 和 BOM API,但是我们却可以类比 React 和 React Native 的思想,在小程序中模拟实现 DOM 以及 BOM 的 API,从而实现直接将 React 运行到小程序环境中的目的,这就是 Taro 新架构的由来。

    在新架构加持下,Taro 不再仅局限于 React 阵营,可以不再限制使用的框架语法,而 Taro 官方内置了 React、Nerv、Vue2、Vue3 四种框架的支持。

    Taro2 到 Taro3,是一次技术的跃迁,也是一次创新的胜利,更是 Taro 团队不断探索,永不止步精神的体现。Taro 这艘大船又重新杨帆起航,带着初心再次出发。

    乘风破浪破浪会有时,直挂云帆济沧海。

    众擎易举——开放式架构

    自 2020 年 7 月初 Taro 正式发布了 Taro 3,至 12 月半年时间已然略去。期间我们不断地修复着问题,同时也在构想着下一个 minor 版本。

    面对小程序平台越来越多的大环境,Taro 是选择偏安一隅,只支持部分的主流小程序,还是成为所有小程序平台开发、多端转换的基础设施,Taro 在 v3.1 给出了答案:开放式架构。

    基于 Taro 3 的架构,对于单一平台的兼容性代码分布于 Taro 核心库的各个角落,涉及编译时与运行时等部分。支持一个新的平台需要改动所有的这些地方,开发复杂度高,同时社区也难以参与贡献。

    因此我们萌生了打造一个开放式框架的想法。目标是可以通过插件的形式扩展 Taro 的端平台支持能力:

    • 插件开发者无需修改 Taro 核心库代码,即可编写出一个端平台插件。
    • 插件使用者只需安装、配置端平台插件,即可把代码编译到指定平台。
    • 开发者可以继承现有的端平台插件,然后对平台的适配逻辑进行自定义。

    Taro 3.1 架构图

    我们把内置支持的 6 个平台封装成了插件,CLI 默认会全部加载这些插件。封装的过程中,我们检索了各小程序最新的组件、API,并全数进行更新与支持,对齐各小程序最新的能力。而借助开放式架构,我们编写了若干端平台插件,开发者安装后即可使用。

    结语

    开源不易,贵在坚持。Taro 一路走来,有众多开发者相伴,进入过 中国活跃度 Top 5 的开源项目,像河水不断奔涌向前的 Taro 既争先也争滔滔不绝。 Taro 团队衷心感谢各位参与过本项目开源建设的朋友,无论是为 Taro 提交过代码、建设周边生态,还是反馈过问题,甚至只是茶余饭后讨论、吐槽 Taro 的各位。

    凹凸揭秘系列文章地址

    1.《凹凸实验室的过去与未来》

    2.《凹凸技术揭秘·羚珑智能设计平台·逐梦设计数智化》

    3.《凹凸技术揭秘 · Deco 智能代码 · 开启产研效率革命》

    4.《凹凸技术揭秘·羚珑页面可视化·成长蜕变之路》

    5.《凹凸技术揭秘 · 夸克设计资产 · 打造全矩阵优质物料》

    6.《凹凸技术揭秘 · Tide 研发平台 · 布局研发新基建》

    7.《凹凸技术揭秘 · Taro · 从跨端到开放式跨端跨框架》

    8.《凹凸技术揭秘 · 基础服务体系 · 构筑服务端技术中枢》


    欢迎关注凹凸实验室博客:aotu.io

    或者关注凹凸实验室公众号(AOTULabs),不定时推送文章。

    查看原文

    赞 1 收藏 1 评论 1

    凹凸实验室 发布了文章 · 1月4日

    凹凸技术揭秘 · Deco 智能代码 · 开启产研效率革命

    作者:凹凸曼

    1、背景介绍

    近几年中台的兴起,团队围绕业务中台化这个场景,将我们已有的诸多能力进行解构、重组、积木化,希望能将拆解后的积木进行体系化地串联,从而达到降本增效的目的。

    对于电商平台来说,每年都需要面临大量的大促活动页面需求,对于如何提高页面产出效率,大家都不约而同采用「页面可视化搭建」解决方案。对应的,我们也构建了「羚珑可视化页面搭建平台」。但近两年大促活动定制化需求井喷,平台有限的组件模块已无法满足产品运营需求,前端工程师也无法再用「复用」的思想简单地解决问题。当业务发展到一定程度,有限的人力以及冗长的开发流程更是无法满足蓬勃发展的业务需求。

    我们需要「求变」,传统的人力密集型研发无法解决的问题,是否能用智能化的思想来解决呢?顺着这个方向,我们把目标瞄准了「前端智能化」,希望借助 AI 和机器学习的能力拓展前端能力圈,打通设计与研发的工作流程,实现规模化生产。

    2、项目介绍

    Deco 智能代码项目是团队在「前端智能化」方向上的探索,我们尝试从设计稿生成代码(DesignToCode)这个切入点入手,对现有的设计到研发这一环节进行能力补全,进而提升产研效率。

    在一个日常需求开发流程中,往往需要遵循固定的一套工作流程,产品提交需求 PRD,交互设计师根据 PRD 输出交互稿,再由视觉设计师输出产品视觉稿,接着再进入前端开发工作流。对于前端工程师来说,输入源是视觉稿 + PRD,输出结果是可上线的页面代码。

    传统开发流程

    Deco 期望解决的是上述流程中,对于前端工程师而已相对低价值,以及可用复用思想处理的工作:

    • UI 视觉稿还原,即页面重构,编写 HTML + CSS;
    • 可复用的业务逻辑绑定;

    Deco新研发流程

    以「设计稿生成代码」为切入点,我们需要用智能化的解决方案来替代传统的人工页面重构(分析图层样式+切图等),期望能从视觉稿原始信息中提取结构化的数据描述,进而再与智能布局等算法结合,输出可维护的页面代码。

    3、技术方案

    设计稿智能生成代码能力的核心是如何生成一份「结构化的数据描述」信息,这份数据称为 D2C Schema。

    <div style="text-align: center;" >

    <img width="800" data-original="https://img12.360buyimg.com/img/s1920x1080_jfs/t1/161330/8/303/162801/5fed8bcaE5fc5d350/a4303b6d7968896a.jpg" />

    </div>

    Deco 设计稿智能生成代码主要做了两件事情:

    1. 从视觉稿中提取「结构化的数据描述」;
    2. 将「结构化的数据描述」表达成代码;

    本质上,Deco 智能代码是通过设计工具插件从视觉稿原始信息中提取结构化的数据描述(D2C Schema),然后结合规则系统、计算机视觉、智能布局、深度学习等技术对 D2C Schema 进行处理,转换为布局合理且语义化的 D2C Schema JSON 数据,最后再借助 DSL 解析器转换为多端代码。

    流程图

    Deco 智能代码的核心链路构成了团队「前端智能化」探索的核心技术体系,围绕产研流程的体系化建设,结合 Cloud IDE、Taro 多端统一解决方案、设计研发资产平台,以及羚珑智能设计等能力,实现一个良性的产研闭环,为整体的工程链路降本提效。

    4、智能代码技术分层

    Deco 智能代码核心链路现阶段主要包含组件识别、图层处理、布局算法以及语义化处理四大分层,下面会围绕这些细分的分层展开内部实现原理的剖析。

    4.1 组件识别层

    组件识别层负责识别设计稿图片中的元素,包括业务组件识别、基础组件识别以及区块识别。
    通过识别能力,输出设计稿中与现有组件库组件匹配的部分,进行组件推荐与复用,并辅助后续处理层处理,比如语义处理层等根据组件属性进行语义化命名,提高生成代码的可用性。

    4.1.1 组件识别

    组件识别层借助了AI能力,使用深度学习目标检测算法来进行识别,输入设计稿导出的图片,输出图片中的组件类别及组件位置。

    <div style="text-align: center;" >

    <img width="800" data-original="https://img12.360buyimg.com/img/s1301x1160_jfs/t1/155620/32/3513/300950/5fed8f0aE683fea36/fbd78d06ce64c921.jpg" />

    </div>

    4.1.2 数据集

    数据集是使用深度学习处理问题的大头,我们汇集了羚珑平台活动页数据、大促会场设计稿以及Relay平台数据,构建了含有2w+样本的组件识别数据集。其中,引入了自动化标注,通过对使用组件搭建的羚珑页面进行Dom结构解析,获得绝对精准的标注数据,减少人工标注成本。

    <div style="text-align: center;" >

    <img width="600" data-original="https://img12.360buyimg.com/img/s1194x549_jfs/t1/164331/36/210/54651/5fed8f72E5012ba90/abe749711b40888b.png" />

    </div>

    为了进一步地丰富数据集,解决组件之间数量不均衡的问题,采用了自动化样本生成方案,基于Quark 官方业务组件库以及大促会场沉淀的 jdcop 大促原子组件库,支持十类样本生成。采用组件模版搭配随机属性的方式,由组件组成完整的页面,并在导出的过程中自动进行标注。

    4.1.3 区块识别

    移动端设计稿大部分高宽比过长,有达到 10:1 以上的,且分布不均,不利于目标检测识别,由此,首先将页面划分为区块,区块识别算法基于传统图像处理流程,使用边缘检测以及漫水填充算法获得连通区域,设置过滤阈值留下楼层大小的识别框。

    <div style="text-align: center;" >

    <img width="300" data-original="https://img12.360buyimg.com/img/s592x835_jfs/t1/156017/39/3504/40455/5fed8f71Ee3aa9831/aa987f8dee9e2bb8.png" />

    </div>

    区块识别算法应用于图层处理层自动成组,优化图层的嵌套结构,助力于布局算法产生更合理的组件结构树。
    此外,将未识别区域自动划分为新楼层。通过固定高度限制,临近区块组合为一个更大粒度的区块,达到将不等高度的设计稿划分为高度相差不大的几个区域的效果,再投入目标检测网络进行识别。

    4.2 图层处理层

    图层处理层主要将设计稿中的图层进行分离、合并、提取元信息,同时结合组件识别层智能成组、分类,导出第一份 Deco Schema DSL。Deco 工作流就像软件工程里的管道与过滤器设计模式,设计稿就是管道的入参,管道中的流就是每一阶段生成的 DSL,管道的输出是一份语义化代码。

    <div style="text-align: center;" >

    <img width="900" data-original="https://img12.360buyimg.com/img/s1337x423_jfs/t1/152313/16/12717/101193/5fed8f72E0ba12f0d/3c306f3917d5c6f1.jpg" />

    </div>

    图层处理层通过借助组件识别层的 AI 能力,智能识别设计稿每个区块,将区块内的图层信息合成一个组,再通过区块匹配算法自动匹配区块与图层,实现了设计稿的自动成组,成组数据有利于布局算法判断区块的层级信息和父子关系。

    <div style="text-align: center;" >

    <img width="800" data-original="https://img12.360buyimg.com/img/s2036x1748_jfs/t1/163597/18/209/1757805/5fed9002E2bf2f58d/9873efb898135b9d.png" />

    </div>

    一份 Sketch 文稿是由若干图层元信息(分为 Document 和 Pages 等)和资源文件(主要是图片)组成的一个压缩文档(文件后缀为“.sketch”),我们通过对图层元信息进行加工处理后得到一份供布局算法服务处理的 DSL。

    通过开发 Sketch 插件,使用 Sketch 提供的 API 能够帮助我们去操作 Sketch 里的文稿,拿到图层信息后,对这些数据加工、筛选等处理。图层信息的处理主要是分为两层:

    1. 设计稿加工层:

      1. 复制出一份原样的设计稿,在这份复制的设计稿上进行各种加工的操作;
      2. Symbol 解耦,将文稿中的 Symbols 解耦为实际的图层组;
      3. 筛选不可见图层,过滤掉设计师隐藏的图层以及空图层组;
      4. 图层合并,将一些特殊的图层或图层组合并,并转为图片;
      5. 蒙层处理,蒙层下的图片如果超出蒙层范围需要裁剪,同时蒙层下的图层位置和宽高信息需要重置。
    2. 图层信息处理层:

      1. 提取图层中有用的信息,比如样式处理、文字拆分、图层层级等;
      2. 图层信息的转化,比如将图片的 base64 位字符串数据转为 CDN 图片地址;
      3. 无用图层检测,将一些无样式或透明样式的图层去除;
      4. 图层打平处理,将图层数据由树状的层级打平为一维的结构;
      5. 成组信息筛选,将未成组的数据通过比对位置和大小将其归类到已成组的数据中。

    下图是对图层信息的处理流程:

    <div style="text-align: center;" >

    <img width="800" data-original="https://img12.360buyimg.com/img/s1337x644_jfs/t1/157558/3/877/272492/5fed8f71E2ab26855/a9684747e1ffa99f.jpg" />

    </div>

    除了对图层信息的基础处理之外,我们建立了一系列的数据导出的优化规则,用于增加布局以及语义的合理性。比如在一些大促设计稿上,复杂背景图的设计可能是在一个图层组下由若干个矢量图形组成(如下图),如果原封不动地将这些图层导出,会给布局带来很多复杂度和不确定性。

    <div style="text-align: center;" >

    <img width="700" data-original="https://img12.360buyimg.com/img/s1896x962_jfs/t1/155724/18/3463/745446/5fed98aaEcef60f1b/d457b5f93367a016.png" />

    </div>

    在合图的这一流程中,针对一个图层组下所有图层都是矢量图形的情况,我们会将它合成为一张图片,这样会大大减轻布局的困难度。最终合图效果如下图:

    <div style="text-align: center;" >

    <img width="600" data-original="https://img12.360buyimg.com/img/s714x132_jfs/t1/169771/39/193/42951/5fed98a9E26e6760d/531f806f0bd5fa80.png" />

    </div>

    当然,上面提到的这些优化规则并不能满足所有的情况,毕竟设计师是自由的。为了提高布局和语义的合理性,我们对入参的设计稿提了一些规范协议供设计师以及开发者使用。

    4.3 布局算法层

    4.3.1 为什么需要布局算法

    布局算法是建立在输入源符合 Deco Schema 规范的数据,该数据规范可以通过 Deco Sketch 插件对视觉高进行处理,最终会导出设计元素信息。

    经过 Deco Sketch 插件导出的元素数据,都是以左上角 (0, 0) 为坐标原点坐标的绝对定位为基础的元素信息,并且在一般情况下(无主动编组、无AI识别等等情况 )元素都是扁平化的,也就是元素间没有从属关系。

    <div style="text-align: center;" >

    <img width="400" data-original="https://img12.360buyimg.com/img/s443x377_jfs/t1/169791/20/210/12060/5fed9913E7767b7ba/ef64707e24e847c8.png" />

    </div>

    在前端开发过程中,绝对定位布局无论是扩展性、可读性都达不到开发要求,那么如果不解决,就成为 一次性代码 。因此,需要布局算法来提高生成代码的扩展性、可读性,供后续二次开发使用。

    4.3.2 布局层核心算法

    布局算法层的设计包含三大层:数据结构转换层、布局推导层、样式计算层。

    <div style="text-align: center;" >

    <img width="600" data-original="https://img12.360buyimg.com/img/s609x588_jfs/t1/171357/38/226/85335/5fed9913E71b38017/739bb6e8d89ca65a.jpg" />

    </div>

    4.3.2.1 数据转换层

    数据结构转换层是将 Deco Schema JSON 数据转换为类似 DOM 树的结构,可以进行节点插入、删除、查找操作。

    下面是 LayoutNode 基本数据结构:

    LayoutNode {
      ...省略节点属性
     
      ...部分节点方法
      appendChild (child) {}
      prependChild (child) {}
      insertAfter (insertedChild, afterChild) {}
      insertBefore (insertedChild, beforeChild) {}
      replaceChild (newChild, replacedChild) {}
      removeChild (child) {}
      get x () {}
      get y () {}
      get width () {}
      get height () {}
      get offsetLeft () {}
      get offsetTop () {}
      get previousSibling () {}
      get nextSibling () {}
      intersect (node) {}
      contains (node) {}
      disjoint (node) {}
      tangent (node) {}
      hitTest (node) {
      ...
    }
    4.3.2.2 布局推导层

    布局推导层则是进行行列分割推导,总体上包含:空间布局算法、投影布局算法、背景图布局算法、特征检测布局算法、坐标推导算法、背景图层及冗余图层检测算法等等。

    <div style="text-align: center;" >

    <img width="500" data-original="https://img12.360buyimg.com/img/s801x444_jfs/t1/164092/36/228/85278/5fed9913Ee1d027c8/df7337312d3cd820.jpg" />
    <span style="color: #888; font-size: 0.9em;">空间布局算法</span>

    </div>

    <div style="text-align: center;" >

    <img width="500" data-original="https://img12.360buyimg.com/img/s510x296_jfs/t1/166468/16/224/48801/5fed9913E97706fe1/d3fab3b55e7f022a.jpg" />
    <span style="color: #888; font-size: 0.9em;">投影布局算法</span>

    </div>



    其中特征检测包括标题、列表、Tab 等等一些列常见的布局检测。

    4.3.2.3 样式计算层

    样式计算层,是对经过布局推导层得到的结果进行一系列的计算,而 Deoc 样式大部分布局采用 Flexbox,有些特殊情况需要使用绝对定位。在布局推导之后,Layout 结构已经有了明晰的层级关系及相邻关系。

    基于层级关系,可以通过坐标计算得出 Flexbox 主轴、侧轴;基于相邻关系,可以计算出相邻之间的 margin 等等样式。

    4.4 语义化层

    当设计稿数据经过布局算法处理后我们就能获得结构较为良好的代码,但此时我们会发现由于节点元素缺乏相应的语义化类名,代码依然不具备很好地可读性。为了最终能得到可以二次开发的代码,我们需要在布局算法层之后加入语义化处理层来让代码拥有良好的语义性。

    语义化层首要解决的问题就是如何为元素节点加上具有语义化的类名。

    为了实现这一目标,我们可以先回顾一下在我们开发的时候是如何给元素节点加上类名的,以如下的单个商品图为例。

    <div style="text-align: center;" >

    <img width="180" data-original="https://img12.360buyimg.com/img/s234x418_jfs/t1/151730/40/12814/49284/5fed997cEb8b7a43b/7211720bcc3dd8c5.png" />

    </div>

    上图是一个商品图的示例,我们会通过图片、价格、图片下方文案等因素来判断出这是一个商品,然后我们就可以给这一个区域赋予类名 goods ,而区域内的节点,比如图片可以赋予类名 goods_pic ,图片下方文案可以赋予类名 goods_tit ,价格可以赋予类名 price ,这就是我们为元素节点添加类名的一般逻辑。

    可以看出,通常我们去确定一个区域,一个组件的语义时,我们需要依据区域内节点的语义组合才能进行判定,比如上面的商品组件,需要依靠内部的图片、价格、文案等元素才能确定语义,从而确定类名。因此,语义化的处理方式,就是从容器元素的子节点出发,先确定子节点的语义,然后再推断出容器元素的语义,一层层往上进行推断,最终推断出整棵节点树完整的语义。

    在语义化层,我们主要的处理对象就是经过布局算法层处理后的 JSON Schema 数据,我们称之为布局树,此时布局树已经具备了良好的结构,我们可以对它进行语义化推断操作。推断的流程就是从树的叶子节点出发,一层层向上冒泡到枝节点,最后再冒泡到根节点。

    <div style="text-align: center;" >

    <img width="800" data-original="https://img12.360buyimg.com/img/s1734x1266_jfs/t1/155564/31/3555/279527/5fed997cE2facb891/f69f97899b664218.png" />

    </div>

    目前我们进行推断的依据主要是节点的位置、样式、大小、兄弟节点等因素,同时会结合不同节点的类型,组合一些智能化手段进行辅助推断。例如,最小叶子节点一般可能为图片、文本两种类型,针对文本我们可以通过 NLP 的方式去分析文本的词性、语义;针对部分图片,我们可以使用图片分类或识别的方式确定图片分类或者提取图片上的关键信息进行图片的语义判定。

    为了确定每个节点的语义,我们需要组合一系列的规则对现有的事实(样式、位置等信息)进行推理,而同时,经过一些规则推理后又会得到新的事实,又需要经过其他规则推理之后才能得到最后确定的结果。所以,这是一个基于规则推理的推理系统,我们可以通过实现一个正向链的推理引擎,来帮助我们进行推理决策。

    <div style="text-align: center;" >

    <img width="800" data-original="https://img12.360buyimg.com/img/s2038x886_jfs/t1/151580/21/12727/133368/5fed997cE5f52d2df/c6344c1d9ea40e82.png" />

    </div>

    例如,推断上述商品组件的过程,首先我们先找到具备价格因素的文本节点,命名为 price ,然后我们找到 price 附近,在树中所处层级相近的图片节点,并且该图片节点符合商品图大小的要求,这样我们就能基本确定同时包含价格和符合商品图特征的容器为商品容器,再根据容器中元素个数,图片附近是否有一段文本,以及对文本的 NER 分析,我们就能确定这段文本是否是商品名,从而确定其语义化类名。

    在整个语义化层中,上述的判定规则只是冰山一角,我们结合整个电商场景,分析了大量设计稿与线上案例后总结了大量的判定规则来帮助我们进行合理化语义命名,同时在语义化过程中采用 NLP 分析、图片分类及识别等 AI 手段,我们将在后续专门撰写相关文章为大家进行具体介绍。

    当然,得到节点类名只是语义化先阶段初步的成果,在未来我们将持续挖掘语义化,为后续字段逻辑绑定等实现打下坚实基础。

    5、阶段性成果

    目前,在组件识别层、图层处理层、布局算法层和语义化层这四大核心模块我们已经去取得了关键性突破,已经可以实现对 Sketch 设计稿进行分析,将其转化成结构良好,具备语义化的,可以二次开发的代码,初步实现了设计稿到代码还原重构的阶段。

    我们已经在大量的电商大促设计稿上进行测试,布局还原程度可达 90% 以上,而最终产出的代码可用率可以达到 80%,我们已经推动在部分内部业务中尝试进行使用。

    6、未来展望

    未来,在上述核心模块完善的同时,我们将加入线上可视化编辑器,允许开发者对生成的代码进行人工干预调整,从而得到更好的代码,同时我们也将探索加入字段绑定和逻辑绑定的功能,让代码可以具备业务逻辑,让 Deco 具备 T3 左右工程师的水平,进一步提升产研的效率。

    Deco 是一粒种子,也许它此时刚刚发芽,但我们对它期许颇多,我们希望通过 Deco 来探索前端智能化的道路,探索 AI 与前端结合的各种可能性,更重要的是,我们希望能够通过 Deco 开启产研的效率革命,在各种前端工程化、平台、方法论趋于完善的当下,探索为业务降本增效的另一种方式。

    Deco 的未来,值得期待。

    欢迎关注凹凸实验室博客:aotu.io

    或者关注凹凸实验室公众号(AOTULabs),不定时推送文章。

    查看原文

    赞 1 收藏 1 评论 1

    凹凸实验室 发布了文章 · 1月4日

    凹凸技术揭秘·羚珑页面可视化·成长蜕变之路

    作者: 凹凸曼

    前言

    京东零售集团 · 用户体验设计部打造的「羚珑智能设计平台」于 2019 年 5 月为内部运营及商家推出了智能页面设计工具,羚珑智能页面设计是一款在线可视化页面搭建平台,拥有在线搭建 PC、H5、小程序等多平台页面能力,覆盖频道页、活动页、店铺页、滑屏宣传页、答题类、互动游戏类、小程序等多个应用场景,为商家、运营人员提供在线服务,让不懂设计、不懂代码的用户也可以一键上线页面。

    基于「Taro」强大的多端能力,能够实现一次搭建,生成 H5、小程序、RN等跨端应用,极大地解决重复开发的问题,提高开发效率。

    聊聊羚珑智能页面设计的历史

    业务中求突破

    在 2017 年以前,京东线上大量的 PC 频道页都是通过手工开发的,开发周期非常长,当时公司内部也有一个 CMS 系统,前端开发完的页面,需要通过这个系统进行发布上线。整个页面的开发依赖这个系统,并且需要在线上完成这些工作。另外还要录入一些数据坑位,才能预览到页面。当时为了解决前端的开发效率,我们把线上开发及数据坑位录入的工作,搬到本地通过一系列自研工具完成。完全颠覆了整个频道页的开发方式,整体的开发思路沿用至今。

    日积月累,我们手上已经开发了非常多的频道页,而且到后面发现,很多页面都非常相似,只是一些样式上的差异。当发现工作重复的时候,应该是造车的时候了,可以让我们跑得更快。

    搭建平台雏形

    羚珑智能页面设计的前身,它只能说是一个页面拼装系统,有一位频道运营的同事找过来,希望能快速开发一个页面,问:“能不能把线上的某几页面中的不同楼层拼在一起,快速上线几个页面”,很显然对于不懂技术的人来说似乎非常简单的事情,但是对于我们开发来说,并非如此简单。我们尝试把不同页面的代码找出来,快速开发一个新的页面,发现很多问题,如样式冲突、脚本冲突等一系列问题。

    于是后面我们对已有的页面,进行楼层级的改造,改造后的楼层,能够独立运行,并且不同的代码及样式只作用于当前楼层,这样,不同楼层组合出来的页面,能够正常显示。

    经过改造后的公共楼层,为了让用户能够自由组合楼层去拼装出一个页面,我们搭建了一个在线可视化平台,把所有公共楼层以列表形式展示出来,支持通过拖拽形式组装页面,支持一些常规的属性配置,如公共头部、颜色等,基本上能满足部分用户诉求。

    拼装系统

    真正的可视化之路

    页面拼装系统的痛点

    页面拼装系统,它主要解决了开发及用户的一小部分诉求,离真正的可视化之路,还很远。很快拼装系统暴露了它一些问题:

    1. 在技术层面,由于楼层的粒颗度不够小,要做一些布局上的调整,需要调整到代码才能支持,缺乏一定的灵活性。以及使用过时的技术栈 jQuery,后期维护成本也非常高。
    2. 在用户运营方面,在我们的平台上不支持根据真实的数据预览效果,系统只是完成了页面框架搭建的事情。
    3. 在数据录入方面,还是难以摆脱前面提及的 CMS 系统,用户需要回到 CMS 系统上面填写真实的素材,所以存在不同系统之间的切换。

    可视化编辑器设计思路

    给合拼装系统的一些问题,我们开始重新设计一款真正基于组件化的页面搭建平台。

    羚珑智能页面可视化编辑器,包括几个基本核心要素:组件库、设计器、属性编辑。

    1. 组件库分为基础组件和业务组件,由于 PC 页面比较复杂,有布局的概念,所以我们需要设计一套布局系统,借鉴于业界优秀的栅格设计思想,再结合我们页面的实际情况,完成了页面的框架与基础组件设计。业务组件穷举了大量线上页面,把常用的组件进行组件化改造,并且支持灵活的属性配置。
    2. 设计器负责组件拖拽、组件加载、渲染逻辑、组件树操作、动态属性注入等功能。通过高阶组件的方式,能帮助我们轻松给组件添加一些特定功能。
    3. 属性编辑,组件每个属性都对应着一个类型,那么它属性数据编辑的方式也不一样。我们设计的类型基本覆盖所有组件。另外还设计了一套条件规则,让属性之间能够联动显示。

    实际上要完成一个高可用的可视化编辑器,需要了解的知识点与细节非常之多,这里不做详细展开介绍。

    经过近一年的沉淀,频道页开发已经从人工开发,全面转型为可视化,目前京东线上大部分频道页都是通过自助搭建方式完成上线。

    PC搭建平台

    编辑器全面升级

    2019年初,借鉴于过去在公司内可视化领域取得了小有成绩,我们产品方向重新定位为聚焦商家在线上经营过程中的页面设计需求,希望通过降低页面上线门槛,从而提高商家、运营人员上线页面的效率,因此,对页面可视化编辑器进行了一次迁往移动端的升级。整个视觉风格及交互方式,都进行了全面升级,去除了复杂的布局,用户使用起来更加便捷。

    编辑器全面升级

    组件库升级

    我们把组件库升级为一个全新的平台「Quark」,它作为一个独立的设计资产平台。为编辑器提供组件、图标库等物料,目前已经沉淀的官方组件有50多个,200多种布局形态,能够满足大部分页面需求。同时还支持公司内部其他研发团队开发自己的组件,接入到我们的可视化平台中,通过我们的上线页面服务上线。

    组件库升级

    属性面板升级

    配置体验影响用户搭建效率: 用户在日常使用编辑器时,需通过更改组件配置项以满足页面个性化需求。我们发现,组件配置项的面板结构复杂、组件配置项理解成本高、操作方式不符合用户习惯等体验问题已经严重影响了用户的配置体验与搭建效率。

    旧版组件配置项面板: 分类以「功能」、「样式」、「数据」做区分,用户理解成本高,经常出现同一配置项出现在多个分区的情况,极大增加了用户的操作成本。

    新版组件配置项面板: 重新定义了面板结构规范,从用户配置操作行为区分,划分为「组件名称」、「组件布局」、「数据录入」、「样式配置」与「楼层配置」5大区域,不仅利于用户理解,缩短了用户的操作路径,对于产品本身而言,清晰的布局划分与功能定义还提效了新增组件的配置项拆解工作。

    属性面板升级

    改版前 v.s 改版后 配置项面板整体结构分区、配置项元件化示意

    元素编辑器

    当我们的官方组件无法满足用户个性化需求的时候,我们思考着能否为用户提供一种自定义组件的能力,所以元素编辑器应运而生。它提供了一个自定义画板的能力,用户可以自由拖拽一些基础元素,如文本、图片、图形等,添加上一些自定义事件和动画,一个生动的的自定义组件,便能轻松完成。

    元素编辑器

    设计资产沉淀

    设计师沉淀了上千套模板提供给用户使用,这些模板全部接入「羚珑」智能图片设计能力,用户能够直接在线修改图片素材内容,轻松实现高质量的页面。另外我们的模板还支持智能配色,用户可以根据配色方案进行页面整体换肤。

    设计资产沉淀

    羚珑智能作图

    为解决用户做图的痛点,羚珑页面编辑器与羚珑图片编辑器深度结合,为用户提供在线图片编辑的能力,用户无须使用一些做图软件,便能在线上完成图片编辑。

    羚珑智能作图

    多应用场景适配

    活动场景

    我们的活动页是如何完美适配移动端和桌面端的呢?

    一个移动端页面要适配桌面端,通常的做法是通过响应式的手段来实现,这种方式比较简单粗暴,但是效果其实并不好,例如移动端的首焦图,如果在桌面端等比放大,那将会占满首屏,用户体验极差。

    所以我们采取了一系列的转换规则来实现:

    举个例子

    PC端的内容其实是跟移动端的内容做了对应关系。并且根据端的特性做了一系列通用的变换规则。比如秒杀商品中秒杀倒计时与商品在移动端为上下布局,而在PC端则为左右布局,商品单元在移动端为一排2个,在PC端则增加为一排4个。

    秒杀商品

    转化的规则是什么?

    拉伸: 在布局不发生改变、内容没有增减的情况下进行拉伸,如广告组模块:

    拉伸

    文本: 文本内容较重要时我们会做无增减的拉伸,当空间位置受限,同时文本内容又不是非常关键的信息时会选择文本截断的方式进行拉伸。

    文本

    图片: 一般来说细节图去做等比拉伸,这样尽最大可能的保证两端效果的一致性。

    图片

    由于移动端宽高比相比 PC 端要小很多,为了保证在大屏上的效果不至于出现“霸屏”的情况,还会有取舍的进行裁切。

    图片

    模块: 移动端通常会将一个楼层划分为一个模块,对应到PC端会将模块在横向进行拉伸。

    模块

    布局改变: 布局发生改变时需要将元素进行重排

    如头图banner模块,如果采取等比拉伸的策略会导致头图特别高,在 PC 端影响第一屏的页面效率,如果采取裁切的形式将会影响图片的展示效果,所以采取图片内元素重排的形式进行变化。

    布局改变

    锚点导航模块在移动端是横向的导航,上滑页面时会吸附到页面的顶部,而在 PC 端我们一般会吸附在页面的侧边固定位置。

    锚点导航

    内容增减: 单元重复展示模块一般会用内容增加和删减的形式来处理,比如商品模块在 PC 端横向空间比较大的情况下会多展示单元格数。

    内容增减

    结合这些转换规则,能让用户只要搭建一次页面,便能快速同时生成两端活动页,投放到移动、PC端平台,节省运营成本。

    互动营销场景

    过去商家想做一个互动类的页面,基本上是很难实现的。有着成本高、开发周期长等问题。互动营销场景为了解决这一系列痛点,把互动玩法进行组件拆解,再通过页面可视化平台进行配置上线。原来一个互动玩法从方案到上线大概需要一个月左右,现在通过可视化搭建方式只需要十分钟,大大提高了效率。

    互动营销场景

    互动营销场景2

    小程序场景

    我们是京东内部首个小程序可视化搭建平台,借助「Taro」的跨端能力,我们平台天然具备了发布跨端小程序页面的能力,结合京东「开普勒平台」的黄金流程,快速产生一套完整的电商小程序代码。支持发布微信、百度等多个小程序平台,完成「九阳」、「戴森」等多个商家小程序上线。

    小程序场景

    小程序场景

    店铺场景

    店铺场景下,我们实现了三个重要的应用场景:

    1. 店铺首页,为商家提供店铺首页搭建的能力,并实现了把设计结果与「京东智铺」的素材打通,满足商家店铺首页装修诉求。

    店铺首页

    1. 店铺推广,一个基于元素编辑器扩展的场景,提供滑屏类页面活动搭建的能力,提供了极具个性化宣传页能力。

    店铺推广

    1. 店铺购物小程序,以中心化小程序的形式为商家提供私域流量工具,提供丰富的营销工具,如抽奖、关注有礼、全景馆等多种玩法。

    店铺购物小程序

    编辑器积木化

    为何要做编辑器积木化?

    1. 随着场景越来越多,编辑器的代码逻辑也变得非常复杂,不同场景都有一些特殊的功能逻辑,每个场景又分为模板搭建端和用户使用端,在编辑器中的表现形式不同,而且编辑器与平台的业务逻辑强耦合。
    2. 公司内部很多平台,都有可视化搭建的诉求,如果重新开发一个可视化编辑器,少则至少需要半年时间。如果直接复用我们的编辑器积木,将会大大提升效率。也减少公司内部重复造车的情况。
    3. 我们编辑器的研发团队人力有限,不能及时满足各场景的需求,扩展性差。
    4. 改动一个小小的功能,整个编辑器都需要发布,如果出问题,所有场景都受影响。
    5. 编辑器的功能越来越多,体积也随之上升,时间久了,整个编辑器变得非常臃肿。

    为了解决这些问题,我们进行了一次编辑器的架构全面升级

    基于配置的插件化架构

    我们将编辑器划分为:主设计器 + 插槽区域,分别用两种颜色表示:

    主设计器

    1. 主设计器:负责编辑器核心逻辑,配置文件解析、插件加载器、组件加载、全局状态管理等;
    2. 插槽区域:编辑器会预留几个主插槽位置用来加载插件功能;

    我们大致来了解一下整个编辑器的工作流程:

    1. 编辑器读取配置文件,配置文件是对整个编辑器的描述,包括所有插件的配置。
    2. 编辑器中提供几个核心位置以插槽的形式,读取配置文件中的插件。
    3. 编辑器的功能抽离成一个个插件文件,通过异步的形式进行加载,这样做的好处是可以按需加载、逻辑解耦、有利于提高系统的扩展性。
    4. 每个插件加载可以动态注入到编辑器应用中,同时它能够共享编辑器的状态,完成插件之间通讯以及调用编辑器的数据和方法。
    5. 编辑器实际上只做一件事情,就是页面描述的生成,其他业务逻辑交业务侧做,这样的好处是能使编辑器完全解耦独立运行。只需要做一些与编辑器、插件的通信接口,就能快速使用起来。
    6. 各使用场景只需要关注自己的编辑器应用配置即可,互相不影响,包括插件个性化升级。

    对外赋能应用

    目前,我们的编辑器积木化解决方案已经应用在京东内部其他平台当中,如京东数科江湖平台、京东ME行业版平台等,作为页面设计引擎助力各平台的商业化快速发展。

    对外赋能应用

    结语

    目前为止,业界有很多优秀的页面可视化产品,为何一直没有尽头,一直有新的平台出现,但都没有最终极的解决方案,那是因为没有真正的「银弹」,只有适应业务发展的产品,才是最适合的。未来我们将会往智能化页面设计的方向努力,必然会擦出新的火花,敬请期待!

    参考


    欢迎关注凹凸实验室博客:aotu.io

    或者关注凹凸实验室公众号(AOTULabs),不定时推送文章。

    查看原文

    赞 5 收藏 2 评论 0

    凹凸实验室 发布了文章 · 2020-12-30

    蒲公英 · JELLY技术周刊 Vol.36: 你好 Hooks,再见 2020

    HEADER

    蒲公英 · JELLY技术周刊 Vol.36

    不知不觉,蒲公英已经伴随我们走过了一年时光,在这一年我们从基础技术前端框架图形编程人工智能等诸多领域为大家推介了三百余篇文章,尽管这一年来风雨不断,但是技术演进的方向却并不会停歇,在和 2020 挥别之前,可不要忘记本期的内容推荐哦~

    登高远眺

    天高地迥,觉宇宙之无穷

    基础技术

    文本长度不一如何影响界面布局

    使用 CSS 构建布局时,如何做好短文本内容与长文本内容的兼容,是每位优秀前端工程师的基本修养,当清楚地知道文本长度变化是否会影响界面布局时,可以避免很多不必要的问题。

    前端框架

    使用 Hooks 的五个常见错误(2020 版本)

    在 React 支持使用 Hooks 编写组件后,越来越多的同学已完全投入 Hooks 的怀抱,本文总结了五个常见错误,大家可以看看自己是否也遇到过,查漏补缺。

    图形编程

    手把手教你做游戏,金币小镇 EVA 全解

    EVA 互动技术体系为手淘在互动游戏前端开发的一整套技术解决方案,包含了资源管理方案、IDE 方案以及技术选型方案,并针对金币小镇这款游戏进行了详细的落地说明,为营销互动开发提效提供了一些思路。

    工程化

    淘宝小程序还可以这么玩?私域互动实战指北!

    超级 APP 中的小程序创意互动能怎么开发,本文给出了答案。通过 200+ 个品牌定制创意互动的落地,验证了这一整套技术方案的可行性,从技术设计,到生产链路的打通,再到多端协调达到性能最优化等等的推进,展示了如何基于业务进行架构设计的强大专业力。

    丁香园的前端研发效能讲义

    无论对于前端还是后端,都涉及到各种复杂程度不一的研发工作流,对于研发效能提升的思考和探索,从未停止过。往往需求从开发到上线,均会经历准备、开发、测试验收和发布 4 个阶段,每个阶段又涉及到各种环节,导致研发流程冗长且容易出错。一个好的工程化平台,能够串联起研发过程中的各个环节,让开发人员更加聚焦于业务开发,而不是疲于应对工具带来的问题,最终达到降本增效的目的。

    设计哲学

    基于 C4 模式绘制软件架构图

    随着敏捷开发的流行,很多团队停止或缩减了他们的图表和文档工作,包括使用UML。即使有团队在使用软件架构图,也往往也混淆不清。为此,2013 IEEE 先驱奖获得者 Simon Brown 提出了 C4 Model。C4 Model 由一系列分层的软件架构图组成,这些架构图用于描述上下文、容器、组件和代码,C4 图的层次结构提供了不同的抽象级别,每种抽象级别针对不同的受众。如果你还在苦恼架构图规范和统一,也许你应该尝试了解一下。

    沧海拾遗

    沧海拾遗,积跬步以至千里

    CSS3 动效优化: 从浏览器层面解析原理

    切图仔,真的懂自己的代码为什么要这么写么?能够知道怎么做才是性能最佳,同时还能理解其原理?如果不懂,那还不快来看看这篇文章,从根本上解释清楚了为什么我们要这么写!

    Animation 动画: 那些你不曾知晓的技巧与细节

    实现动画效果往往有很多方案,实际开发中我们往往根据需要来选择最适合的最优解。这篇文章详细讲解了动画开发中常用的各种属性、效果以及可能遇到的问题,梳理了各类实践下的技巧和细节,快来看看,为自己的知识体系查漏补缺吧~

    「蒲公英」期刊,每周更新,我们专注于挖掘「基础技术工程化跨端框架技术图形编程服务端开发桌面开发人工智能设计哲学前端框架」等多个大方向的业界热点,并加以专业的解读;不仅如此,我们还会推介精选凹凸技术文章,向大家呈现团队内的研究技术方向。

    抬头仰望,蒲公英的种子会生根发芽,如夏花绚烂;格物致知,我们登高远眺、沧海拾遗,以求积硅步而至千里。

    蒲公英 · JELLY技术周刊贡献指南

    FOOTER

    欢迎关注凹凸实验室博客:aotu.io

    或者关注凹凸实验室公众号(AOTULabs),不定时推送文章。

    查看原文

    赞 0 收藏 0 评论 0

    凹凸实验室 发布了文章 · 2020-12-25

    凹凸技术揭秘·羚珑智能设计平台·逐梦设计数智化

    作者:凹凸曼 - 羚珑

    1、简介

    羚珑智能设计平台是由京东零售集团用户体验设计部打造的在线设计设计服务平台,专注于泛零售领域的设计,帮助客户解决日常经营过程中所碰到的各类设计需求,例如商品上新时的商品主图视频、各种节日大促时的商品主图更新,还有直播带货场景时所需要的各种设计物料等等。

    羚珑致力于成为泛零售领域商家、运营生意经营中的设计好伙伴,助力他们实现设计数智化,从而实现设计层面的降本提效、提升设计结果(广告图、视频、页面等)的商业转化效果,这是我们的愿景和使命。

    从技术和功能形态层面,我们把设计数智化分成了两个方向,一个方向是「模板化设计」,另一个方向是「程序化设计」。

    2、模板化设计

    「模板化设计」的核心目标:是实现线下设计物料的数字化,在数字化设计资产的基础之上,构建广告图、短视频等可视化设计能力,为我们的终端用户提供所见即所得的在线设计 SaaS 平台。「模板化设计」为客户提供三大核心设计能力:图片、动图、视频,还有常用的在线设计辅助工具,此外通过能力的整合打包,以「羚珑企业专区」的产品形态为企事业单位提供完整的数智化设计、可视化设计的解决方案。

    2.1 图片设计,让泛零售营销场景下的广告图触手可得

    我们提供了大量契合泛零售垂直领域的设计模板,只要客户有卖货做设计的需求,便总能在羚珑平台上找到所需要的,配合功能体验持续迭代的「图层编辑器」,用户只需根据图片使用场景选择心仪的设计模板,进行所见即所得的简单操作,即可快速制作可直接用于投放的广告图;同时还提供「尺寸扩展」、「智能配色」等功能,帮助用户丰富广告图最终的设计效果,满足更多的使用场景。

    图片设计

    「图片设计」的能力目前还提供了嵌入式使用的 PaaS 解决方案,第三方的系统平台可以借助该方案来集成羚珑的图片可视化设计能力,构建自己业务的设计解决方案。目前「嵌入式图片设计」方案被京东内部多个核心营销平台所采用,例如商家装修店铺时使用的智铺,通过接入羚珑的图片设计能力,支持商家高效低本地完成店铺装修所需设计素材的制作。

    图片

    2.2 动图设计,简单两步让静态图动起来

    5G 高速网络的逐渐普及,流量和速度的大幅度提升,Web 应用、APP 以往对媒体素材尺寸、性能的苛刻要求将逐渐成为历史,越来越多的场景开始尝试使用动图视频来丰富视听效果,提升商业转化率。相比静态广告图的制作,动图需要设计师具备动画方面的专业知识,设计成本要高出数倍。羚珑平台提供的动图可视化设计,由专业设计师将常用的动效沉淀为可复用的数字资产,再通过与图片模板的精心设计和组合,从而得到用户可以直接拿来即用的通用的动图模板,用户只需要替换主图、填写利益点文案,简单的两步操作即可生成效果突出的动态广告图,大幅度降低了设计的门槛和成本。

    动图设计

    2.3 视频设计,轻松制作视听带感的短视频素材

    视频相较动图,它具有更细腻的动态效果,还可以加入带感的背景音乐,是视听表现最为丰富的媒体素材,具有极高的设计制作成本。羚珑提供的视频可视化设计解决方案,抹平了成本鸿沟,让用户依然能够像制作静态广告图一般简单高效地制作视频。视频可视化设计解决方案,提供了两个核心的编辑器。一个是面向专业设计师的后台编辑器,帮助他们实现动态素材(GIF、AE 动画、帧动画等)的数字化管理,同时提供了灵活的图层控制、丰富的动效和动效素材以及特殊音效,让设计师最大限度的发挥创意,创作视频模板。

    视频设计

    另一个是面向终端用户使用的前台编辑器,基于设计师已经设计好的视频模板,用户通过组合图片和文案,即可高效制作视听效果俱佳的短视频。

    视频设计

    羚珑提供的动图设计、视频设计能力,与图片设计一样,在京东内部系统平台也得到广泛的集成应用。

    2.4设计工具箱,为你打磨实用的图片后期处理利器

    想对已有图片做后期加工处理么?来看看羚珑的设计工具箱吧。

    设计工具箱

    2.5 企业专区,让每一个企业拥有完整的在线设计解决方案

    面向企事业单位提供设计数智化赋能的 SAAS 服务,提供了包括素材在线管理、标准化合图、快速页面搭建、自定义组件编辑在内的一整套解决方案,让企业无须投入开发成本,即可在日常运营的固定位置更新以及组织促销活动等场景中,规范化、流程化、标准化地进行设计输出。

    图片

    羚珑企业客户 - 乐信(https://www.lexin.com/

    3、程序化设计

    「程序化设计」的核心目标是利用大数据挖掘、人工智能等技术手段,结合用户的设计画像,为不同的人群输出不同风格的设计手法,助力千人千面等精准营销场景,提升转化率,所用到的技术主要包括数据挖掘、计算机视觉、机器学习。

    「程序化设计」最大的特点是「极速」和「无人运营」,适用于需要海量快速生成图片的业务场景。在京东的一个典型应用场景是京东 APP 首页焦点图的千人千面,其针对不同用户结合用户画像生成不同的设计结果,每天处理数以亿计的图片生成请求,这些依赖人工运营是根本无法达成的。

    基于「程序化设计」相关技术能力的应用,我们达成了设计大幅度降本提效的基本目标,以往设计师可能半天才能做好 1 张广告图,现在 1 台机器的 1 个进程,每秒就能做好几张图,大大节约了设计成本。

    除了降本提效,设计结果商业效果的提升也是「程序化设计」十分重要的目标。

    我们已经开始在广告图片商业价值层面进行探索和论证:根据不同用户的画像、设计偏好,生成不同风格的广告图片,从而进一步提高广告图片的商业点击率(CTR)。这种依据用户画像、设计偏好进行程序化设计的新模式,我们称其为推荐型设计。

    智能推荐型设计是一个复杂的系统工程,可以拆解成若干个图片智能化相关的技术课题,接下来为大家稍作介绍。

    3.1 设计画像

    3.1.1缘起

    在推荐搜索模型构建中,我们会为用户构造大量的标签,比如像年龄、性别、城市、品牌偏好、品类偏好等,这些标签最后勾勒出一个用户的形象,我们把它定义为机器识别的数据化形象,行业内的叫法是用户画像。

    借鉴于用户画像,我们开始思考用户在图片视觉领域是否存在类似的偏好,更通俗讲人的审美是否会因为每个人而不一样?

    3.1.2论证

    关于用户设计审美偏好的答案,有一篇文章( 《浙大女教授扎心发现:可乐包装上的字体可能正在算计你的钱包》)的结论让我们印象深刻:使用圆润可爱的字体会更能让用户对可乐产生喜爱的情感,进而让用户产生消费!

    这篇文章告诉我们,除了内容,设计本身似乎也能影响商业转化率,我们决定在京东实际的业务场景使用一系列的AB测试实验,依靠数据来进一步佐证它的结论。

    实验一:不同字体曲率对CTR影响研究

    场景:APP的核心入口首页banner图上

    图片

    通过监测数据我们得到一些结论:

    1. 儿童品类或女性偏好度较高的品类可以考虑通过圆润属性的字体来提升用户对商品的喜爱程度;
    2. 品牌认知度较弱的品类可以考虑用过圆润属性的字体来提升用户的喜爱程度;
    3. 针对女性用户/25岁以下的年轻用户进行营销时,可以更多考虑通过圆润属性的字体来提升用户对商品的喜爱程度。
    4. 不同年龄的男性女性对于字体的偏好也不太一样

    实验二:不同色系对CTR影响研究

    场景:APP/PC的核心入口首页banner图上

    图片图片

    实验三:不同布局对CTR影响研究

    场景:APP/PC的核心入口首页banner图上

    图片图片

    基于以上实验的数据分析后,我们得出一个结论:不同人群在设计上确实存在偏好关系。

    3.1.3实践

    标签(偏好)数据加工的流程:首先客户端埋点上报用户的操作行为数据(主要是点击、浏览、搜索等),其次对数仓hive表中的数据做清洗、特征计算,然后标签落库,最后提供相应接口。

    图片

    步骤一、数据清洗

    前端上报的数据落在数据仓库里,点击、曝光流量模型里面包含了各个业务的埋点数据,而我们需要清洗出针对于广告焦点图的用户行为序列数据!

    用户行为序列数据模型示例

    user模板id时间场景sku_id曝光次数点击次数
    x_747b7b44d9bc2012020.11.1App首焦23111123
    x_747b7b44d9bc2022020.11.1Pc首焦21222123
    x_747b7b44d9bc2032020.11.2xxx233341
    x_747b7b44d9bc2042020.11.2xxxx833330
    ....................

    模板标签模型示例

    名称字段字段类型枚举值示例
    模板组IDps2idstring5c122d3d82acdd181d18292c
    预览图urlarray['URL1','URL2']
    场景类型sceneint1-首焦
    设计类型designint1-图片;2-页面
    色系colorstring蓝色
    布局layoutstring左图右文
    按钮buttonstring
    背景风格bgstylestring简约

    步骤二、统计分析

    重行为难题:

    当我们在给用户构建品牌偏好时,经常会关注到用户在该品牌下产生了哪些“重”行为?“重”行为可以理解成用户为了做某件事付出了比较高的操作成本,比如用户是否特意搜索了某个品牌的商品。

    我们在讨论设计画像方案的时候,几乎找不到方法去定义这种“重”行为,所以常规的套路好像并不适合用来构建设计画像!

    经过讨论后,我们决定返璞归真回到最初的统计学的方式,假定如果用户点击某个颜色的广告图多,那就证明用户对于该颜色存在一定的偏好,然后借助于显著性检验来验证数据是否显著,得以确定最后的标签权重!

    显著性检验:

    显著性检验作为判断两个乃至多个数据集之间是否存在差异的方法被广泛应用于各个科研领域。

    图片

    步骤三、标签落库

    当我们跑出来用户标签数据后,最后其实只是一个工程问题,把相应的数据落到对应的表里。然而实际情况却要复杂的多,仍然会存在问题:数据量偏少,不足于覆盖大部分用户!

    接着又衍生出了 look alike 这种人群标签的方法,也就是我们的用户可能是完全没有数据的新用户,这个时候期望通过匹配相似人群的标签作为最后的标签结果。

    图片

    算法模型

    除了统计学的思路,我们还在探索用另外一种方式去构建设计画像,使用模型训练输出标签。之前也说过偏好问题可以认为是一个分类问题。

    常用的分类模型主要有以下两种:

    分类模型优点缺点
    决策树根据决策树可以很容易地构造出规则,而规则通常易于解释和理解;决策树可很好地扩展到大型数据库中,同时它的大小独立于数据库的大小;决策树模型的另外一大优点就是可以对有许多属性的数据集构造决策树。处理缺失数据时的困难,过度拟合问题的出现,以及忽略数据集中属性之间的相关性等。
    朴素贝叶斯有稳定的分类效率。对小规模的数据表现很好,能够处理多分类任务,适合增量式训练,尤其是数据量超出内存时,我们可以一批批的去增量训练。对缺失数据不太敏感,算法也比较简单,常用于文本分类。需要知道先验概率,且先验概率很多时候取决于假设,假设的模型可以有很多种,因此在某些时候会由于假设的先验模型的原因导致预测效果不佳。

    目前我们正在尝试使用决策树类模型 XGBoost 实现标签训练输出,它支持各种语言调用,支持单机和分布式,支持 libsvm 的稀疏矩阵的数据格式。

    3.1.4展望和目标

    设计画像是智能设计基础能力中的一环,结合程序合图,为不同的人群输出不同风格的设计手法,助于千人千面、千人千场等精准营销场景,提升商业转化率。

    3.2 实时合图

    我们面向开发者、第三方系统平台提供了服务端快速合成图片的接口,开发者可以根据自身的业务诉求集成羚珑的程序化设计能力,构建自己的设计引擎。

    「实时合图」在京东最大的应用场景是京东 APP 首焦轮播广告图的千人千面,根据不用访客的用户画像和购买行为数据分析,实时合成并推送精准的广告图,提升其商业转化率(CTR)。

    图片

    它的核心就是通过 C 去实现了合图的底层引擎,然后通过 NGINX 扩展的形式注入到 NG 里面,通过 LUA 脚本来控制各个业务上层的逻辑配置。

    图片

    此外,羚珑实时合图方案的一大亮点在于 CDN 兜住了绝大多数请求,能有效降低真正回源的请求量。

    图片

    CDN是一种加速内容分发网络,通过多节点的形式,让用户访问到离用户最近的节点资源,从而达到让内容快速呈现给用户的技术,简而言之,我们可以理解为缓存。

    3.3 智能配色

    在羚珑网站上作图,都能体验到智能配色的功能,从而大大提高图片丰富性,做到一键切换图片风格。

    图片

    基于图像智能识别技术,对图像色值进行精准识别,通过像素级别的色值替换,实现图片色彩风格的智能变换,保证配色结果的风格与质量。

    3.4 智能抠图

    智能抠图基于京东drawbot和 么么照 的能力进行构建,前者擅长商品抠图,后者适合人像抠图。目前这两种抠图能力都可以在羚珑平台上体验,另外也提供接口方式内外赋能。

    图片

    3.5 智能排版

    基于知识图谱的推理能力,我们构建了一套适用于泛零售领域的广告图片排版技术,通过知识图谱可以让图形在任意尺寸下自动适应画布,并添加合适的图元。

    3.5.1任意尺寸Banner图合成

    我们建立了一套基于知识推理的方法,从简单到复杂的递推迁移实现了banner图任意版式结构的构图,利用机器学习算法学习大量的优秀设计师模板中的布局参数,智能化的构建出符合人眼审美的排版构图,使用模型的泛化能力实现了任意尺寸的版式合图能力。

    图片

    3.5.2任意形状图形排列

    为了增加素材的丰富性与层次感,我们对一些基本图形或文字进行叠加组合,生成复合型的素材,使用场卷积堆叠算法,对图元生成卷积核在目标区域内卷积扫描,填充并目标轮廓区域,实现了任意形状轮廓的图元排列与叠加效果。

    图片

    图片

    3.6智能背景

    尺寸拓展是设计需求中经常碰到的一个痛点,一张广告图片,经常因为要下发到不同的客户端,需要做不同尺寸的版本。这个过程我们会碰到一个很大的问题,静态的背景图片没有办法很好的适应于各种尺寸中,它不像矢量素材一样,可以任意的放大或缩小,而矢量背景素材却又具有很大的设计成本。因此,我们希望可以利用程序算法动态生成任意尺寸的好看好用的背景图素材,它具有矢量背景素材的特性,又具有极低的生产成本,这是羚珑智能背景课题研究的初衷,是实现 AI 无人化设计的难题之一,我们现在就在路上。

    利用机器生成的背景,在创意层面会有一定的局限性。我们觉得以下几种类型的抽象背景素材具有机器生成的可行性。

    3.6.1粒子 + 渐变

    将大量的粒子和深色的渐变相叠加, 可以生成类似科幻大片中的背景效果图, 非常适合用作电子产品的背景图。通过对粒子大小, 色彩混合模式, 随机性等参数的修改, 可以生成更多特殊氛围效果。

    图片

    3.6.2形状组合

    纯形状组合的背景具有很强的通用性, 可用于各种品类的商品, 它是由算法生成一些随机形状组成, 并根据用户喜好风格匹配一套配色方案对图形进行着色。

    图片

    3.6.3渐变+装饰

    用装饰图形和渐变背景色融合也是常用的背景生成方案, 通过对装饰图形类型、层数、融合模式、位置等参数修改, 使得这类背景图生成方案通用性极强, 可以演化出千变万化的背景素材。

    图片

    3.7 风格识别

    我们基于深度学习,构建了风格识别的预测模型,可以从图片信息识别出风格特征元素,自动判别图片设计风格。风格识别的技术,能够在类似京东 APP 首焦广告图千人千面等精准化营销场景中得到应用落地。

    图片

    3.8智能识色

    一款颜色提取工具,通过提取图片像素点的 RGB 值,再做一个归类排序,最后通过算法由 RGB 转化为普通人可理解的颜色(红、蓝、黄、绿等)。

    图片

    3.9 美学评估模型

    美学评估我们处于调研阶段,未来应该会结合智能生成来作为自动生成图片评分的标准之一。

    图片

    4、结语 - 智能设计的未来

    羚珑目前基于数字化的设计资产,解决了设计效率和设计成本问题,但背后依然依赖设计师的资产输入。未来我们想实现真正意义上的无人化设计,利用大数据挖掘分析和机器学习等技术手段,打造一个虚拟的「AI设计师」,让它能够和现实中的设计师一样,做出好看且效果好的广告图或短视频。未来的人类设计师,可以花更多的时间去理解业务和思考设计创意,把很大一部分的设计执行工作交给「AI」。

    参考文献:

    1. 图像质量评估模型

    其他

    感谢一直关注凹凸实验室的读者,为了提供更优质的内容,希望您能抽出几分钟时间,完成一个小调查,明年凹凸公众号的内容由你决定。点击直达

    加入凹凸实验室开放、开源、专业、有爱、有梦的大家庭?点击直达

    还没有关注「凹凸实验室」的读者们,关注我们吧,我们一个月只有 4 次推送机会,我们很珍惜每一次推送,不会让你失望的。微信搜索「凹凸实验室」关注即可。


    欢迎关注凹凸实验室博客:aotu.io

    或者关注凹凸实验室公众号(AOTULabs),不定时推送文章。

    查看原文

    赞 3 收藏 1 评论 0

    凹凸实验室 发布了文章 · 2020-12-25

    凹凸实验室的过去与未来

    作者:凹凸曼

    https://www.qq.com/video/m321...

    凹凸实验室隶属于京东零售用户体验设计部(JDC),成立于 2015 年秋冬之交,诞生自深圳前海之滨,至今已走过 5 个年头,5 年的时光穿梭而过,凹凸实验室也不断发展壮大,从曾经专注前端的团队成长为如今涵盖前后端、全栈、算法、测试各类方向的全能型研发团队,工作模式也从传统的人力密集型研发转向创新型平台体系化研发,如今,凹凸的各类技术输出与沉淀在业界影响深远。

    <iframe frameborder="0" data-original="https://v.qq.com/txp/iframe/player.html?vid=m3215ilu1ay" allowFullScreen="true"></iframe>

    星火

    2015 年,凹凸实验室的前身多终端研发部成立刚好一年,彼时的多终端研发部,虽然是一个拥有 20 多位开发人员的独立前端研发部门,但更多的是在支撑着公司内部的各种业务的研发,从微信手 Q 的购物业务到京东商城的营销活动、拍拍网,以及京东云的大改版,业务的类别五花八门,作为一个工线支持部门,每天在各类业务开发中穿插,协助各类业务需求的开发。

    <div style="text-align: center; margin-bottom: 20px; color: #999">2015 加入凹凸实验室的同仁</div>

    在此期间,部门也产生了很多精品业务,凭借着在 H5 动画方面的造诣,在京东内部小有名气,每到一些大促的时间节点都能收到很多的业务需求,这让团队开始在京东内部开始崭露头角。

    <div style="text-align: center; margin-bottom: 20px;">H5 动画作品合集</div>

    在这一阶段我们也产生了很多优秀的文章,不完全列举:

    同时,在沉淀了大量精品的 H5 业务之后,我们也开始尝试打造一个可视化搭建工具 HiPage,通过拖拽搭建的方式就能将沉淀的 H5 动画元素组合出新的 H5 页面,实现快速上线,得到业务方的一阵惊叹。这是我们第一个颇具意义的技术产品,它既服务好了业务方,也满足了我们作为技术人员对技术的追求,同时也为我们埋下了关于团队方向思考的引子。

    作为技术团队,我们一直在思考,我们所能做的是否仅仅只是服务好业务就够了?或者换一个角度,作为一个工线部门,我们除了努力把业务做好,还能再做些什么?

    2015 年 9 月,一个燥热的周五晚上,在白石洲的鸡煲大排档里,关于上面的问题,关于团队的发展,关于团队的未来,团队里的几位大佬一边吃着鸡煲,一边激烈讨论。最终,留着一头飘逸长发的老黄掐灭手里的烟说道,“我们要做深圳最知名的前端团队”,在场的大家听罢后都陷入了沉思。

    彼时落入大家心中的是一点点星火,似乎点亮一丝丝前方的光明,但是,星星之火,可以燎原。

    一个月后,凹凸实验室正式成立,朝着 “要做深圳最知名的前端团队” 这个目标,团队的所有小伙伴都充满干劲。很快,我们和设计师通力合作,设计了沿用至今的团队 Logo。

    同时也确定了我们的团队的理念:开放、开源,凹凸实验室的名字也来源于此,这一理念灌注在团队血液中,为之后的技术产品研发奠定基础。全新的团队官网也建立起来了,这个官网承载了不仅仅是团队小伙伴的技术文章,同时也是一个个关于技术梦想的追求。团队内也开始举办各类技术分享、编程马拉松,组织各小组的 Code Review,整个团队的技术氛围开始形成,凹凸如一个蹒跚习步的孩童,不断摸索,不断向前,磕磕碰碰,但不失朝气。

    沉舟侧畔千帆过,病树前头万木春。

    成长

    回顾我们思考的疑问,我们在建设一个具有一定规模的前端团队的时候,其目的是否仅仅是服务好业务?

    我们给出的答案是否定的。

    正如凹凸灵魂导师老黄的文章《关于前端团队架构的思考》中所说的。

    这个就好比一个人活着不能止于「有食可进有衣可穿」这种基础的物质条件,团队也同样有「精神层面」的内涵,具体如:

    • 影响力
    • 创新力
    • 技术视野

    这些「精神层面」的东西看似很虚,但实际上会以另外一些形式正向的反馈给团队,间接影响团队服务业务的过程甚至结果。
    建设团队在公司内外的影响力,可以营造团队的专业口碑,吸引优秀的专业人才主动加盟,而优秀的人才对于团队高效处理业务需求或研发需求的能力具有促进作用。

    于是我们开始关注如何服务好业务的同时,提炼我们自己的技术产品,以业务为盾,以技术产品为剑,去打造我们梦想中的技术团队。

    从业务中来,到业务中去

    时间来到 2015 年末,此时凹凸承接的业务呈现暴涨的趋势,各类业务接踵而至,为了更好地应对业务增长带来的人力瓶颈,我们加速探索前端工程化,期望使用工程化的手段来解决前端模板化、组件化、自动化开发的问题,并推出了凹凸实验室第一个比较完善的开源产品 Athena。当然以现在的眼光来看 Athena 并不是一个优秀的产品,它的文档很糟糕,可扩展性几乎为 0,但在当时还是支撑起了团队大部分业务的开发,为业务研发增效提供源源不断的动力。请参见我们是如何做好前端工程化和静态资源管理

    在打磨好工程化工具后,我们团队也终于迎来了非常重量级的业务——京东商城 PC 首页改版,此时 PC 首页依然承载着非常多的流量,改版的工作备受重视,而同时首页的复杂度特别是对性能、体验、稳定性的要求远远超出了我们过往的项目,秉承团队过往打造精品业务的理念,我们想要将 PC 首页这个项目做到全方位的极致。所以承接项目的小伙伴压力山大,在奔赴北京熬了一个多月后,项目终于顺利上线。当双 11 前夕,线上首页稳定顺畅地出现在办公室一个个显示器上的时候,我们难掩心中的激动,互相击掌庆祝彼此的胜利。具体请参见京东2016版首页改版前端总结

    而在 PC 首页上线之后,为了进行更好地项目管理,同时保证项目流程自动、稳定地运行,我们开发了统一上线平台,可以进行项目管理、自动构建、构建后代码 diff 、项目操作日志以及一键发布和回滚等操作,极大地规范了项目流程管理工作,同时将项目的上线统一进行管控,大大降低了项目出现线上问题的可能性,开始为工程化补全串联研发流程的工作,也为后续我们开发一站式云端产研平台提供了宝贵经验。

    但是工程化带来的提效,远远跟不上业务需求增加的速度,为了应对层出不穷的业务需求,17 年,我们在 HiPage 的基础之上,继续探索页面可视化搭建,期望通过建设高可用的可视化搭建引擎,配合海量的(想象中)模板和组件,产出一套 No Code 系统,让运营或者可以自己搭建页面直接上线。于是诞生了内部代号为「Atom」 的页面搭建平台,帮助内部快速上线了几千个页面,凹凸实验室在业务方那儿成为了“活儿好”的代名词。

    同样是 17 年,随着京东商城业务的蓬勃发展,传统的设计师作图,业务方套模板生产广告图等物料的方式已然非常落后,生产效率低下极度依赖人力,同时也无法满足越来越多的个性化图片需求,为了应对这样的场景,我们开始打磨羚珑智能设计平台,通过海量图片模板和基于用户数据实时合图能力,解放了设计师的双手,也节约了业务方获得高质量图片的成本,让每个人都能轻松完成图片制作。

    拥抱开源技术的初心

    依然是 17 年,这一年我们在不断提升业务支持,围绕业务打磨技术产品的同时,在开源上我们也在不断奋进。这一年京东商城的前端主流技术栈还停留在 jQuery,而对于我们的业务来说已经无法忍受 jQuery 带来的研发效率低下的困境,我们开始探索新的技术栈,经过缜密的调研后,开始着手开发类 React 框架 Nerv,在内部业务经过一番验证后,开始在 GitHub 开源。凭借着当时团队大牛澈哥的出口转内销的推广策略,Nerv 开源第一天登上 GitHub 的 trending 榜,迅速斩获了上千 Star,这对于以开源为理念的我们来说,无疑是振奋人心的。请参见Nerv - 京东高性能前端框架

    时间匆匆忙忙来到 18 年,彼时对于业务来说又迎来新的挑战,各类小程序平台层出不穷,为了应对业务拓展渠道的需求,我们开始探索多端统一开发解决方案,并迅速推出了 Taro,实现开发一次,同时生成多端应用,凭借着对 React 语法的独特支持和一天 3 个版本火线迭代的速度,Taro 成为诸多开发者喜爱的解决方案,帮助很多业务上线多端应用,Taro 也成为凹凸实验室的一张技术名片。请参见多端统一开发框架 - Taro

    <div style="text-align: center; margin-bottom: 20px; color: #999">Taro stars 数破 2w 庆祝会</div>

    向全栈迈进

    而为了应对内部业务的数据服务请求,以及内部诸多的自研平台系统,凹凸实验室又自建了后端研发团队,为各大系统平台提供坚实的后端服务,为业务封装各类微服务方便调用,同时也在数次大促节点抗住了流量压力,团队的技术栈已经不再局限于前端了,开始向全栈模式转变。

    平台化转型

    18 年 19年,我们在不断对我们的各类工具系统进行打磨,做好能力储备。而与此同时,中台的概念兴起,我们团队也开始探索设计研发在中台领域的地位,开始打造公司的设计中台。我们深刻地认识到团队除了对人才的培养之外,更应该关注团队研发资产的沉淀,工具、平台系统、研发组件这些都是团队宝贵的研发资产。而除了不断进行研发能力建设和储备的同时,我们应该将这些已有的能力积木串联起来,成体系化地对外进行赋能,从而实现传统的人力密集型研发向创新型平台体系化研发的转变。

    破局

    2020 年,20 年代的第一年,从开年就注定是不寻常的一年。这一年我们也从宝安中心的龙光大厦搬到了前海内的卓越前海壹号。

    今年,是凹凸实验室成立的第 5 年,5 年过去,团队的技术沉淀已然成型,曾经“开放、开源”的初心理念也未曾忘却。而在这一年我们对团队的能力积木做了一次重新的梳理,并思考如何进行体系化串联。

    造积木

    回顾过往,我们已经做了非常多的技术储能,并且团队的技术产品发展是全方位地进行,从智能设计到产品研发,基本每个领域都有我们探索的印记。

    在图片和视频能力上,我们打造了 羚珑智能设计,可以通过海量图片模板和基于用户画像的智能算法实现图片和视频的智能生成。

    在多端适配与框架能力上,我们打造了 Nerv,并从 Nerv 的中孵化出了 Taro, 可以实现一次开发,生成多端应用。

    在可视化搭建能力上,我们从 HiPage 时代开始一步步探索, 到 Atom 时代可以搭建各类营销页面,再到现如今的羚珑可视化搭建,可以直接拖拽生成多端应用,并且覆盖营销、店铺等诸多场景。

    在研发资产沉淀能力上,我们打造了 夸克资产平台,已经沉淀了海量的研发组件、图片、字体、动效等研发资产。

    在数据可视化能力上,我们打造了 树懒平台,可以对业务统计和监控数据进行可视化查阅。

    在服务端能力上,我们打造了专业的 服务端团队和系统,为各类业务和平台需求提供专业可靠的服务端能力支撑。

    盖大厦

    我们拥有诸多的能力积木,但是如果不能进行体系化串联,我们就不能进行产品化包装,以及对外进行技术赋能。

    我们发现,纵观整个产研流程,将我们的能力积木放入之后,在某些环节依然有所缺失,例如,从设计师到研发,我们没有很好地进行对接,当有个性化需求需要开发以及需要进行研发组件沉淀时,我们依然需要人工将设计稿进行还原然后进行业务逻辑绑定开发,不仅仅是滞后我们的研发效率,同时对我们的设计研发体系来说也是一种断层,所以,今年我们进行了 设计稿一键生成代码 的探索,尝试对设计研发这一环节进行能力补全,同时提升我们的产研效率。

    而同时,在研发流程上,我们只有 Taro 本身是远远不够的,Taro 只能解决代码开发本身和部分工程化的问题,只是研发流程中的一环,而研发流程则是包括开发、调试、测试、上线、统计监控完整的链路,为了打通研发流程全链路,同时统一研发环境,今年我们又开始进行了 一站式云端集成研发平台 即 Cloud IDE 的探索,尝试将业务研发、资产沉淀搬到云端,仿佛在走一遍统一上线平台的老路,但却是完全不一样的风景。

    设计稿一键生成代码一站式云端集成研发平台 成为了补全产研体系化建设的两块拼图,让产研流程可以成体系化进行串联。

    目前我们现有的产研流程,首先设计稿通过智能代码能力一键生成可二次开发的代码,代码导入 Cloud IDE 中进行开发调整,最后可以通过 Taro 生成多端应用,这是一个线性的过程,而同时,在此过程中也能快速沉淀设计研发资产,设计研发资产也能作为智能代码智能识别的样本数据,沉淀设计资产又可以提供给可视化搭建平台,直接搭建出多端应用,同时羚珑智能设计将为应用提供个性化的图片和视频,丰富应用的运营能力。由此,实现了一个良性的产研闭环。

    目前,我们整体的能力全景图如下。

    启下

    立足业务,技术储能是过去五年凹凸实验室的主题。

    而智能化设计研发体系将绘制凹凸实验室未来 5 年的技术产品的梦想画卷。

    接下来我们将通过【凹凸技术揭秘】系列文章,为大家分享、剖析凹凸的关键技术布局,希望能为业界带来更多的思想碰撞,也希望能吸引更多有志青年加入我们,共同实现关于技术关于产品关于团队的梦想。

    年光似鸟翩翩过,世事如棋局局新,唯有不忘初心,坚守本心,方能乘风破浪,济沧海。

    其他

    感谢一直关注凹凸实验室的读者,为了提供更优质的内容,希望您能抽出几分钟时间,完成一个小调查,明年凹凸公众号的内容由你决定。点击直达

    加入凹凸实验室开放、开源、专业、有爱、有梦的大家庭?点击直达

    还没有关注「凹凸实验室」的读者们,关注我们吧,我们一个月只有 4 次推送机会,我们很珍惜每一次推送,不会让你失望的。微信搜索「凹凸实验室」关注即可。


    欢迎关注凹凸实验室博客:aotu.io

    或者关注凹凸实验室公众号(AOTULabs),不定时推送文章。

    查看原文

    赞 6 收藏 1 评论 0

    凹凸实验室 发布了文章 · 2020-12-23

    蒲公英 · JELLY技术周刊 Vol.35: Flash 四宗罪?

    HEADER

    蒲公英 · JELLY技术周刊 Vol.35

    Flash 曾是 Web 迈向新世代的福音书,它为这个世界带来了缤纷色彩,但也如伊甸园的苹果,闪耀着智慧的光芒,却四灾随行。诞生 1995 年至今 25 年,这个潘多拉魔盒终于要被人们关上并尘封入土,然以史为鉴可知兴替,flash 缘起为何?为何被高高捧起又跌入凡尘?只是过时,亦或是 web 初心不在?这些都值得我们去思考。

    登高远眺

    天高地迥,觉宇宙之无穷

    基础技术

    玩转前端 Video 播放器

    随着5G网络的普及,直播行业的火热,在h5上多媒体的场景也越来越多。对于video标签的使用,前端需要考虑加载时长以及各终端兼容,这篇文章给出了流媒体的解决方案,从HLS、DASH概念,自适应比特率流技术及流媒体加密技术,FLV文件格式、MSE API、视频播放器原理、MP4 与 Fragmented MP4 封装格式的区别进行了介绍,文章末提供了video播放器示例,根据实际工作场景,可以自行选择媒体格式,同时通过canvas播放,可以探讨实现绿幕、弹幕等等更多的可能。

    图形编程

    Flash 终于进入倒计时,细数它犯下的四宗罪

    Adobe 宣布,将在2020年12月31日停止对 Flash 的支持。昔日火遍大街小巷,无论看视频还是玩游戏,处处都是它的身影。然而24年过去了,它已被用户、行业所唾弃,只因四宗罪。可人们怀念的「Flash 闪客文化」又是什么?那今天我们就一起来聊聊 Flash 的辉煌与没落。

    人工智能

    推荐算法的“五环之歌”

    这是一篇关于推荐系统算法介绍文章,梳理了推荐算法的发展脉络,非常形象地阐述推荐算法里面最重要的几个idea的核心思想,让大家理解推荐算法的基本套路。

    设计哲学

    命令行程序设计指南

    该文档在传统 UNIX 设计哲学基础上以现代软件开发的视角总结了一些命令行程序的最佳实践和设计规范,帮助你写出体验良好的命令行程序。

    工程化

    前端工程的性能优化导览

    前端性能优化已是老生常谈的事情,但真正在项目中落地又是一件略具挑战的任务,本文将罗列一些常用的性能优化方法,带大家重新拾回「前端用户体验」。

    工具推介

    无侵入的 REST/GraphQL API 模拟库——mswjs

    当我们在写前端测试用例时,不可避免的需要面对如何模拟后端接口数据的问题,本文介绍了几种处理方式,从测试用例代码的简洁性和接口数据的保障性上进行的比较说明。

    沧海拾遗

    沧海拾遗,积跬步以至千里

    游戏开发: “九亿”指尖的大冒险

    快来看,快来瞧,“九亿”指尖的梦想,看不了吃亏,看不了上当……好了不说笑了,在 SNS 游戏的开发过程中,会遇到什么问题呢?无限循环滚动?随机阶梯和障碍的生成和定位?物品掉落显示……来看这篇文章就足够咯~

    算法解析: 波动均分算法

    “波动”是一种常见的物质运动形式,“均分”指平均划分、分配,那么“波动均分”又是什么意思呢?波动均分算法该如何实现?这个算法有何应用场景?读完这篇文章,定会有所见解。

    「蒲公英」期刊,每周更新,我们专注于挖掘「基础技术工程化跨端框架技术图形编程服务端开发桌面开发人工智能设计哲学前端框架」等多个大方向的业界热点,并加以专业的解读;不仅如此,我们还会推介精选凹凸技术文章,向大家呈现团队内的研究技术方向。

    抬头仰望,蒲公英的种子会生根发芽,如夏花绚烂;格物致知,我们登高远眺、沧海拾遗,以求积硅步而至千里。

    蒲公英 · JELLY技术周刊贡献指南

    FOOTER

    欢迎关注凹凸实验室博客:aotu.io

    或者关注凹凸实验室公众号(AOTULabs),不定时推送文章。

    查看原文

    赞 0 收藏 0 评论 0

    凹凸实验室 发布了文章 · 2020-12-17

    Taro 周报 #7: 收获「e代驾」案例,发布 v2.2.16 和 v3.2.0-canary.2

    Taro 周报 2020 年 12 月 05 日 - 2020 年 12 月 12 日 ,更多的Taro周报点击

    Taro 大事件

    58 技术发布文章《开源 | Taro 3 支持 React Native》

    Taro 3 发布后暂不支持 React-Native 平台,于是我们向社区提交了一份实现草案,希望把 58 在 React-Native 上的技术积累分享到社区,同时也从社区对 Taro 的共建上获益。

    Taro 2 发布 v2.2.16

    • [修复] H5 路由地址替换错误
    • [修复] 修复插件中引用 taro-ui 组件路径错误

    Taro 3 发布 v3.2.0-canary.2

    快速修复了试用 Taro 3 React Native 的开发者提出的多个 issue。

    收获的案例

    本周小伙伴们分享了 3 个案例:

    e代驾 来自 eazdp 提交

    e代驾微信小程序

    e代驾支付宝小程序

    逃大拿 来自 王树立 提交

    逃大拿

    乐日Day自习室 来自 yun-cheng-yue 提交

    乐日Day自习室

    欢迎大家提交案例(名称 + 小程序码/二维码),和数万开发小伙伴分享您的成果,它将出现在 Taro 文档「案例」页和 「Taro 社区」公众号的周报中。

    案例提交地址:

    https://github.com/NervJS/taro-user-cases

    ISSUES

    上周有 48 个新 issue。
    其中 20 个 issue 已经被关闭,28 个 issue 仍然保持打开状态。

    OPEN ISSUES

    ??? #8253 [chore(deps): [security] bump ini from 1.3.5 to 1.3.8](https://github.com/NervJS/tar... by [dependabot-preview[bot]](https://github.com/apps/depen...

    ??? #8252 tabbar 希望支持跳转页面和跳转小程序等功能增强, by zhaoxu-me

    ??? #8251 chore(deps-dev): bump @types/node from 12.12.62 to 14.14.12, by [dependabot-preview[bot]](https://github.com/apps/depen...

    ??? #8250 chore(deps): bump mini-css-extract-plugin from 0.8.0 to 1.3.3, by [dependabot-preview[bot]](https://github.com/apps/depen...

    ??? #8249 chore(deps): bump @babel/register from 7.9.0 to 7.12.10, by [dependabot-preview[bot]](https://github.com/apps/depen...

    ??? #8248 Taro3.0.18 Scrollview的scrollIntoView设置无效, by darkfiredarkhalo

    ??? #8246 通过object类型传入的styles,无法删除某个属性, by rookie125

    ??? #8242 Vue3 使用 vant-weapp 微信小程序组件,@click 等事件无响应, by Mikasa33

    ??? #8241 调用Taro.redirectTo不能正常跳转, by gxsandzxl

    ??? #8239 Taro 组件使用 Enzyme 的 mount / render 方法做 UI 测试, by P233

    ??? #8238 componentDidShow钩子内调用Taro.redirectTo引起的bug, by gxsandzxl

    ??? #8237 Uncaught TypeError: Cannot read property 'componentProto' of undefined, by hao-li

    ??? #8236 fix(diff): view层级过多会导致栈溢出, by wyyxdgm

    ??? #8235 textarea在ios中使用表情maxlength有问题, by Asarua

    ??? #8228 Taro.pageScrollTo无法滚动到指定位置, by GoodbyeNJN

    ??? #8226 引用taro-ui,最后yarn run dev:weapp,运行小程序插件,提示组件路径错误, by antbrothers

    ??? #8225 Input组件focus会弹出两次键盘 #7014 未解决, by QingATech

    ??? #8222 Taro3.0组件在h5环境下的View支持 viewProps,类Image组件的imgProps, by heiazu

    ??? #8221 最外层的容器使用flex布局在safari浏览器中滚动时无法隐藏底部、顶部操作栏, by SyMind

    ??? #8220 默认初始化, by i-coder-robot

    ??? #8219 @tarojs/components Image组件在h5环境下缺少imgProps字段, by heiazu

    ??? #8218 Taro3 h5平台Taro.pageScrollTo失效, by Asarua

    ??? #8215 TypeError undefined is not an object (evaluating 'w.isProxied'), by GZWZC

    ??? #8213 是否支持全局生命周期钩子, by bibidu

    ??? #8211 taro3的列表页面 DOM数量提示超过1000,不支持#shadow-root,导致点击事件延迟, by xiaoice

    ??? #8210 taro/extend 字段返回错误, by zsymor

    ??? #8209 在自定义平台插件下 webpackConfig中的runtimePath 会解析错误 导致无法加载扩展的runtime文件, by leo-ran

    ??? #8207 API 中webpackChain option中没有publicpath 的选型, by LiyumingBen

    CLOSED ISSUES

    ?? #8247 canvasToTempFilePath 中 canvasId 不再是必传项, by Swordword

    ?? #8245 docs: 修复 readme 特别鸣谢中头像超链与本人不一致问题, by allenou

    ?? #8244 [chore(deps): [security] bump ini from 1.3.5 to 1.3.7](https://github.com/NervJS/tar... by [dependabot-preview[bot]](https://github.com/apps/depen...

    ?? #8243 canvasToTempFilePath 中 canvasId 不再是必传项, by Swordword

    ?? #8240 3.x vue版 如何再dist目录生成package.json文件,以此使用小程序里面的npm包功能??, by jigsaw-china

    ?? #8234 chore(deps): bump mini-css-extract-plugin from 0.8.0 to 1.3.2, by [dependabot-preview[bot]](https://github.com/apps/depen...

    ?? #8233 canvas hook 写法 draw is not a function, by Swordword

    ?? #8232 支付宝小程序设置title 无效Taro.setNavigationBarTitle({ title: '12312'}), by shenggen1987

    ?? #8231 v2.2.16 发布, by luckyadam

    ?? #8230 v2.2.16, by luckyadam

    ?? #8229 chore(cli): 调整 taro 支持的 node 最低版本, by luckyadam

    ?? #8227 v2.2.16 发布, by luckyadam

    ?? #8224 build:weapp报错, by xiaoai7904

    ?? #8217 迁移并更新文档:RN端开发前注意, by iChengbo

    ?? #8216 Parse errors in imported module, by Loomark

    ?? #8214 chore(release): publish 3.2.0-canary.2, by shinken008

    ?? #8212 taro3扩展编译平台 -> 模版,文档描述看起来是可以自定义一些功能,求个DEMO案例, by xiaoice

    ?? #8208 新建的taro3.0的项目 配置了组件和页面 但是提示渲染失败?, by yuxilins

    ?? #8206 Fix/command, by LaxusJie

    ?? #8205 项目周报 (2020 年 11 月 28 日 - 2020 年 12 月 5 日), by [taro-bot2[bot]](https://github.com/apps/taro-...

      • -

    PULL REQUESTS

    上周有 29 个 pull request 被创建、更新或 merge。

    UPDATED PULL REQUEST

    上周有 20 个 pull request 更新:

    ?? #8253 [chore(deps): [security] bump ini from 1.3.5 to 1.3.8](https://github.com/NervJS/tar... by [dependabot-preview[bot]](https://github.com/apps/depen...

    ?? #8251 chore(deps-dev): bump @types/node from 12.12.62 to 14.14.12, by [dependabot-preview[bot]](https://github.com/apps/depen...

    ?? #8250 chore(deps): bump mini-css-extract-plugin from 0.8.0 to 1.3.3, by [dependabot-preview[bot]](https://github.com/apps/depen...

    ?? #8249 chore(deps): bump @babel/register from 7.9.0 to 7.12.10, by [dependabot-preview[bot]](https://github.com/apps/depen...

    ?? #8236 fix(diff): view层级过多会导致栈溢出, by wyyxdgm

    ?? #8202 chore(deps): bump typescript from 3.9.7 to 4.1.2, by [dependabot-preview[bot]](https://github.com/apps/depen...

    ?? #8135 feat(mini-runner/mini-split-chunks): 添加小程序提取公共模块插件,主包没有引用的,且分包内引用的mod…, by huangcj99

    ?? #8123 chore(deps): bump sass-loader from 6.0.7 to 10.1.0, by [dependabot-preview[bot]](https://github.com/apps/depen...

    ?? #8115 chore(taro-mini-runner): upgrade less-loader version to support additionalData config (#7921), by ZeroTo0ne

    ?? #7706 chore(deps-dev): bump @types/autoprefixer from 9.7.0 to 9.7.2, by [dependabot-preview[bot]](https://github.com/apps/depen...

    ?? #7704 chore(deps-dev): bump @types/resolve from 1.14.0 to 1.17.1, by [dependabot-preview[bot]](https://github.com/apps/depen...

    ?? #7397 chore(deps-dev): bump @types/detect-port from 1.1.0 to 1.3.0, by [dependabot-preview[bot]](https://github.com/apps/depen...

    ?? #7326 fix: 解构 props 后,如果作用域中不包含 children, 其他 renderProps 可能识别失败 close #7315, by ivan-94

    ?? #7324 fix(tranformer-wx): taroize 转换后的组件不支持 对象 style, by ivan-94

    ?? #7292 fix(transformer-wx): 非实例方法 bind 应该转换为匿名回调, by ivan-94

    ?? #6951 fix(mini-runner): 开发模式修改文件会刷新所有json,导致开发工具加载过慢, by 0JARVIS0

    ?? #6444 feat(input): 添加输入事件延迟触发, by zgs225

    ?? #5779 Revert "fix(taro-h5): 响应体无数据时抛错进入reject (#4599)", by rsnzh

    ?? #5297 锁定版本, by zsirfs

    ?? #5153 feat(transformer-wx)增加TARO-UI侧的快应用转换支持,不支持部分组件默认支持为DIV,支持部分默认为原生组件名, by Issacpeng

    MERGED PULL REQUEST

    上周 merge 了 9 个 pull request:

    ?? #8247 canvasToTempFilePath 中 canvasId 不再是必传项, by Swordword

    ?? #8245 docs: 修复 readme 特别鸣谢中头像超链与本人不一致问题, by allenou

    ?? #8231 v2.2.16 发布, by luckyadam

    ?? #8230 v2.2.16, by luckyadam

    ?? #8229 chore(cli): 调整 taro 支持的 node 最低版本, by luckyadam

    ?? #8227 v2.2.16 发布, by luckyadam

    ?? #8217 迁移并更新文档:RN端开发前注意, by iChengbo

    ?? #8214 chore(release): publish 3.2.0-canary.2, by shinken008

    ?? #8105 feat(taro-runtime): consistent window object, by atzcl

      • -

    COMMITS

    上周共有 5 个 提交:

    ?? fix(h5): 修复h5下的pageScrollTo函数的selector参数支持问题 by no name

    ?? feat(taro-runtime): consistent window object (#8105) by atzcl

    ?? chore(cli): 调整 taro 支持的 node 最低版本 by luckyadam

    ?? docs: 修复 readme 特别鸣谢中头像超链与本人不一致问题 by allenou

    ?? canvasToTempFilePath 中 canvasId 不再是必传项 (#8247) by Swordword

      • -

    CONTRIBUTORS

    上周共有 5 名独立贡献者:

    ?? atzcl

    ?? luckyadam

    ?? allenou

    ?? Swordword

    感谢你们对开源事业做出的贡献。??

      • -

    STARGAZERS

    上周获得了 89 个 star。它们分别来自于:

    ? panlt123

    ? clyquan

    ? cxj-github

    ? LiyumingBen

    ? xuduogui

    ? rehmetjan

    ? rrr5t6y7

    ? LouisYLWang

    ? instkffff

    ? xuqiang521

    ? Joranson

    ? blacksola

    ? ShrinkLynn

    ? Wsmzh

    ? kunbowu

    ? tw19920521

    ? wuyanwei

    ? wranswer

    ? AmemiyaSigure

    ? yuanqichao514

    ? kgdkhntak

    ? xiaoice

    ? developer-os

    ? lvgit3mc

    ? lihai5566

    ? Jeekai

    ? qicunshang

    ? cobra180825

    ? bestshenggao

    ? Lock-And-Key

    ? Jiny3213

    ? chenyang351

    ? liyingkun1237

    ? HolenZhou

    ? datoulei

    ? looles

    ? joe-szmn

    ? charleyxie

    ? scott-leung

    ? yuzhuguan

    ? foolzhang

    ? ManiaciaChao

    ? KuangjuX

    ? season7

    ? helperAI

    ? sliverraven

    ? autoConfiguration

    ? pipiciweia

    ? Mrchen128

    ? nicett

    ? feixiao

    ? mickmetalholic

    ? geekspeng

    ? bearxsh

    ? cicizhao

    ? idea-zone

    ? yanmei122

    ? JorkeMooN

    ? zenblo

    ? ryanwang520

    ? kaclarpt

    ? Akatsuki-kurumi

    ? FFlainsF

    ? pgzhouyangyang

    ? LJYq

    ? BrooksWon

    ? wyyxdgm

    ? jutoukeji

    ? GMlc

    ? lx463785

    ? wozzup

    ? littlecxm

    ? Mavi

    ? lynxkor

    ? Ttou

    ? openideal

    ? ZeyanGuo

    ? rsq1259

    ? lideyang

    ? qige2016

    ? ioiioo

    ? rainame

    ? klxq

    ? ioth5

    ? xingangw

    ? maokty

    ? beipingdengni

    ? sevenseablue

    ? phamquangquy92vd

    You all are the stars! ?

      • -

    RELEASES

    上周有 2 个新版本发布。

    ?? v2.2.16 发布
    ?? v3.2.0-canary.2 发布

      • -

    以上就是本周的项目周报。你可以点击 weekly-digest 查看往期的项目周报。


    欢迎关注凹凸实验室博客:aotu.io

    或者关注凹凸实验室公众号(AOTULabs),不定时推送文章。

    查看原文

    赞 0 收藏 0 评论 0

    认证与成就

    • 获得 474 次点赞
    • 获得 1 枚徽章 获得 0 枚金徽章, 获得 0 枚银徽章, 获得 1 枚铜徽章

    擅长技能
    编辑

    (??? )
    暂时没有

    开源项目 & 著作
    编辑

    • Taro

      多端统一开发框架,支持用 React 的开发方式编写一次代码,生成能运行在微信/百度/支付宝/字节跳动/ QQ 小程序/快应用/H5/React Native 等的应用。

    注册于 2019-11-27
    个人主页被 7k 人浏览

    bt365体育投注