合创汽车卡片式代码配置平台探索与实践

如果无法正常显示,请先停止浏览器的去广告插件。
分享至:
1. 合创汽⻋ 卡片式代码 配置平台探索与实践 合创汽⻋ 数字化大前端负责人 / 李明
2.
3. 李明 合创汽⻋ 信息与数字化部 大前端负责人 负责公司数字化C端社区、营销、用⻋业务和大前端团队, 主要研究前端效能、多端统一,数字化大前端方向。曾主导 合创汽⻋C端前端从0到1的搭建,目前支持百万级别的用户 规模和数千辆的汽⻋月销量规模支撑。多年移动互联网从业 经验,从多平台到跨平台,从传统智能制造到新能源汽⻋。
4. 大纲 业务背景概述 ● • 业务特性 • 开发模式 • 技术栈分析 行业运用指引 ● • 行业解决方案 • 可行性探索分析 ● 卡片式配置平台实践 ● 技术难点攻关 ● 后配置化时代的思考 ● 成功案例与展望
5. 业务背景概述
6. 业务背景概述 :业务特性差异 ➢ 技术部⻔一对多支撑多部⻔业务,不同部⻔侧重点不一样, 如何快速支持不同部⻔的需求? 部⻔A 部⻔A 部⻔B 部⻔C 部⻔D 部⻔E 其他 部⻔B 部⻔C 部⻔E 关注社区运营,运 关注整⻋营销,销 关注整⻋质量和服 关注产品稳定和性 营时效性高。 售政策多变。 务快速响应。 能快速修复。
7. 业务背景概述 :开发模式分析 ➢ 传统开发链条⻓,效率低,周期⻓,中间环节存在大量的沟 通成本。 业务部⻔ 部⻔A 产品部⻔ 需求 解析 部⻔B 部⻔D 后端 开发 产品 方案 耗时1天 发布上线 部署 发布 连调 测试 产品文档 需求提交 部⻔C 技术部⻔ 产品 验收 前端 开发 功能 测试 耗时4天 传统合计 耗时6天 目前策略:根据业务性质划分3条业务线并行。 优点:提高业务吞吐率。 缺点:每个环节看似很完整,其实链条极⻓,往往不能满足业务期望。 代码服务 上线 运维 耗时1天
8. 业务背景概述 :技术栈收敛 ➢ 多端技术并存,数据互联互通困难,存在技术壁垒,企业用 人成本高,牵一发而动全身。 保 持 技 术 更 新 技 术 辅 助 业 务 配置平台 合创汽⻋大前端 Android kotlin ios 小程序 web 客户端 技 术 栈 收 敛 web
9. 业务痛点总结 业务特性 工作模式 时效性高、政策多变、需求差异 NO.2 效率低、周期⻓、投入高 NO.3 技术体系 团队结构 开发资源与需求不匹配 NO.1 传统 数字化模式 PROBLEM NO.4 数据互通成本高
10. 行业运用指引
11. 行业解决方案一览 ➢ 由人工编码到机器编码的变化。 ➢ 由固定化到配置化的转变。 ➢ 由通用领域到差异化领域的变化。 化 零代码 异 差 置 配 低代码 纯代码 业务逻辑完全靠工程师编码。 应 响 度 速 慢 需要跟少量代码相结合,并进行 系统化的编排管理。 无需任何的代码新增,即可完成 业务系统的搭建。
12. 方案分析 01 原子配置型 02 卡片配置型 03 业务配置型 描述:通过按钮、图标、文本原子 描述:提供原子化控件组合成组合 描述:业务驱动,以快上线为目的 化控件自由组合,形成⻚面,直接 控件,操作组合控件,无需对子控 无可视化,无预览,基于业务数据 操作原子化控件。 优点:拓展性强、自定义性高。 件设置。 优点:拓展性中等、插拔式。 的配置。 优点:实现快。 缺点:复杂度高、接受成本高。 缺点:业务变更、需要升级控件。 缺点:与业务强绑定,无法拓展。 推荐度:不推荐 推荐度:强烈推荐 推荐度:推荐
13. 探索分析结果 行为 每个组件的行为不通,公共行 数据 分为动态数据和静态数 为抽象化,差异行为在组件中 定义实现? 协议 如果使不通平台能够识别到 据,前者直接调用接口提 同一种配置,统一化的协议 供,后者直接编辑上传。 语言打通上层配置壁垒。 组件 渲染 组件的丰富程度和自定 各平台根据渲染规则个自实 义程度直接决定着平台 现一套还是直接使用跨平台 的能力范围。 防止只实现一套环境。
14. 卡片式配置平台实践
15. 卡片式配置思路 高效率 低成本 开发成本、培训成本、协作成本 近业务 贴近业务、解决业务痛点 可复用、简化流程 可持续 可持续迭代、功能叠加优化
16. 卡片式配置系统架构 ➢ 完整的配置平台应该具备怎样的模块和能力? 消费者 1. 拖拽组件到预览面板,配置属性和 参数数据,面板即时预览效果。 2. 读取⻚面参数进行bool判断配置。 3. 配置路由、保存、预览。 4. 保存⻚面、生成⻚面ID。 5. 客户端解析渲染生成⻚面。 生产者 1. JSON Schema设计器快速生成组 件描述语言 2. 根据描述语言,代码实现组件逻辑 3. 组件上传到组件库 4. 补充组件文档
17. 组件运行时 初 始 运 行 onCreate onPause 取 值 getValue 同步、异步 ⻚面载入时,进 行初始化渲染工 作。 销 毁 onDestroy 同步 初始化完成之 后,可以进行组 件事件操作。 组件对外输出的 唯一的,对应的 数据。 ⻚面销毁之后, 完成数据的回 收,防止 crash。
18. API编排模型 组件 Inputs API 编辑器 编辑保存API ProgressDatas 开始执行 Outputs Action 数据源 API编排 API 执行器 顺序执行 Action API配置储存 递归类型执行 Action Action 第三方服务接口
19. 平台运作流程 2、⻚面搭建 3、逻辑支撑 面板解析 ➢ 完整的配置平台应该具备怎样运作? 组件实现 可视化 解析 JSON Schema 生成 可视化构建 属性名版 态 可视化拖拽 组件属性 组件库物料 Component.json Json+vue 组件实现 1、组件生成 据 数 动 数据源 逻 辑 组件实现 解 析 逻辑表达式 生成page.json ⻚面存储 组件实现 Android/ios 版本号增量下发 Component.vue ⻚面下发 4、渲染展示 统一渲染 客户 端渲 染 小程序 其他
20. 卡片式配置的阶段 04 跨平台卡片配置 支持跨平台卡片配置,只维护一套组件库。 03 卡片配置 02 卡片式组件拖拽,构建⻚面,组件与数据分离,可自由搭配数据。 组件配置 01 纵向排列的组件配置,可复用,多端各自维护组件库。 场景配置 固定业务场景下的数据可配置,不可移植、不可复用。
21. 阶段1 场景配置 ⻋型配置 ⻋系配置 选配配置 卖点配置 参数配置 不可移植 不可复用
22. 阶段2:组件配置 组件选型 制定协议 设计出图 { { "bannerPic": "http://xxx.xxx.xx/xx.png", "bannerLink": {...}, "bannerNote":"", "bannerWidth":980, "bannerHeight":300, } "showAuthor":true,//开启后显示文章作 者头像、用户名、标签 "topicId":514,//对应的专题链接,可以获取 专题列表 "topicName":"自动化【Online】-周年庆 话题" } 开发实现 { "carCover":"http://xxx.xx.xx/",//⻋型封 面 "carCoverVideo": "http://xxx.xx.xx/",// 封面视频 }
23. 阶段3:卡片式配置-前端视觉 1 2 避免 布局 差异 1 3 5 2 3 10 4 5 卡片式 4 8 6 7 8 9 10 11 面对 组件 开发 7 11 6 9
24. 阶段4:跨平台卡片式配置 配置平台 技术中台 跨平台 业务终端 Android note.js 构建 微服务 混编 引擎 ios 小程序 其他
25. 技术难点攻关
26. 技术难点攻关 多端显示 1. 优先考虑的是组件简单好维护。 • 本平台主要应用在客户端上,客户端平台主要分为 Android、ios、小程序、h5四个端。如果每个端都写 一份代码,产生一系列问题:代码管理问题、效率低 2. 配置平台的产物是json文件,用于描述⻚ 面的渲染。 3. 统一渲染引擎实现,使得组件通信和⻚面 路由代码大大减少。 逻辑数据 • 缺少逻辑判断,少很多应用场景。例如监听订单状 态,⻋控状态,来显示某些组件,以及把当前数据状 态传递到组件中。 如何 解决 1. 数据源的导入方式,必须简单,作导入后 都作为数据层进行统一管理,管理数值, 管理字段。 2. MVVM 架构监听、获取数据层的数据。 1. 提供类似 js方法 eval,在渲染层实际用 动态代码 • 配置无法解决全部的业务场景,API链路的出入参逻 辑、前置逻辑,一些操作还是需要编写在线js代码。 jsc 作为js-core。支持在运行时中,再执 行js代码。
27. 后配置化时代的思考
28. 工作流思考 ➢ 配置化加速上线过程。 ➢ 配置化无需功能测试。 开发 测试 技术部⻔ 需求 提出 业务部⻔ 产品 方案 产品部⻔ ⻚面 配置 业务部⻔ 上线 运维 技术部⻔
29. 协作思考 ➢ 沟通协作,技术部⻔与业务部⻔最大化贡献。 技 术 掌 握 旧态:纯代码开发阶段 自动开发 • 处于纯代码开发阶段,完全依赖代码实现业务场 自驱智能开发 景,应对能力差,牵一发动全身,系统化程度 低,业务完全依赖工程师操作。 • 工程师的价值无法最大化。 零代码开发 完全拖拽方式开发 低代码开发 可视化开发为主、 少代码开发为辅 专业工程师主动赋能, 业务方直接按照需求场 开发合创自主的开发配 景、拖拽配置出符合业 置平台,一次开发,持 务业务场景的应用,快 续迭代打磨。 速上线。 纯代码开发 完全靠写代码实现业务 现状:配置化开发阶段 需求掌握 专业开发工程师 • 工程师的价值最大化,按照能力梯队划分为专 业开发工程师和业务开发工程师。 业务开发工程师 业务需求人员 • 减少业务到技术的翻译过程,降低沟通成本, 缩短上线周期,快速上线。
30. 管理视觉思考 产品化 个性化 体验化 沉淀公司数据资产 个性化配置差异 提升用户体验 解决业务系统灵活性、动态可变的问 用户分层,标签化,支撑个性运营, 快速响应上线用户需求,降低容错 题,沉淀公司数据资产,减少因人员 把核心资源投资在有价值的用户,提 率,建立企业与用户的信任感,提高 流动造成的数据丢失。 高订单转化率。 用户忠诚度,提高涟漪传播程度。 2018 Q1 节约成本 提高人效 2018 Q2 2018 Q3
31. 成功案例和展望
32. 成功案例 社区产品线 • 首⻚信息流banner位自由摆放营销组件,应对营销动作。 • 首⻚精华⻚自由摆放九宫格组件和轮播组件。 • 商城首⻚自由摆放商品组件,自由展示价格与积分。 营销产品线 • Z03⻋型可自由上架新款⻋型,无需开发支持。 • Z03⻋系⻚面可自由搭配组件,满足卖点的不同方式支持。 • 爱⻋⻚可自由搭配内容组件、360外观旋转组件、单图/多图banner展示。 用⻋产品线 • ⻋控⻚面功能集合可搭配九宫格组件展示和单图/多图banner展示。 • 权益⻚可根据营销策略配置不同的权益组合。
33. 未来展望 深入平台完整性和自定义能力,提高产品易用性和灵活性。 低代码平台在各种组件和模块实现无代码的基础上发展起来,随着引擎类型和交付模块数 量的增加,低代码平台将覆盖更多的应用场景,实现更广泛的业务价值。 产品由组件演变为平台,嫁接高级能力提供综合服务。 随着RPA和人工智能技术能力的普及,企业应用将有更多的泛自动化和智能能力,帮助 平台用户做出业务决策,实现为客户提供综合服务的能力。 一般平台竞争大于垂直场景,产业链生态强者更强。 垂直制造商在细分领域的优势逐渐显现,用户对低代码制造商的依赖程度高,品牌效应明 显,早期知名度高、产品能力强的一般制造商将走出优势,市场集中度将大大提高。
34. 问题Q&A
35.
36.

trang chủ - Wiki
Copyright © 2011-2024 iteam. Current version is 2.132.1. UTC+08:00, 2024-09-22 15:31
浙ICP备14020137号-1 $bản đồ khách truy cập$