同程艺龙Android平台化架构设计及自动化解决方案

如果无法正常显示,请先停止浏览器的去广告插件。
分享至:
1.
2. 同程艺龙Android平台化架构设计 及自动化解决方案 赵相宇
3. 目录 • 背景 • 背景介绍 • 业务对比 • 目标 • 平台化架构演进 • 过程及挑战 • 规划及目标 • 组件管理平台 • 背景介绍 • 平台介绍
4. 背景篇
5. 背景介绍 • 前提:存在多个相同业务,相同业务的流程基本一致。 • 困难:同程旅行、艺龙旅行,原本从框架、组件到各个业务都是 有各自的团队在维护,代码差异较大,甚至技术栈都不同。 • 契机:随着同程艺龙的合并,业务团队的融合,一套代码运行在 同程、艺龙两侧,成为刚需。
6. 业务对比 艺龙旅行 同程旅行
7.
8. 目标 • 业务方面,支持一套代码运行在两侧App中,做到业务最小改动 • 组件方面,支持不同侧多业务调用 • 框架方面,支持各业务、组件独立开发、调试、发布
9. 平台化架构演进篇
10. 过程及挑战 整个平台化架构改造,大体可以分为三个阶段:
11. 阶段一:跑起来 • 挑战: • 时间紧,任务重 • 业务无感知 • 方案: • 通过平台层,抹平组件差异
12. 修改前两端架构
13. 修改过程
14. 优势: • 通过平台层抹平业务在两端的 api差异,几乎做到业务无感知 • 不改动原有组件,最大化保证稳 定性,降低测试回归成本 缺陷: • 平台层过于复杂,维护成本高 • 相同功能组件,两端还是要维护 两套 • 组件api有任何变动,平台层需 同步修改,容错率低 问题: 平台层包含TE两侧的组件及Api, 与原有App所依赖的组件、Api会发 生编译冲突,如何解决?
15. 编译冲突解决方案 • Api冲突可以通过sourceSets,做到不同侧参与编译的代码不同。
16. 编译冲突解决方案 • 组件依赖冲突可通过flavor + gradle插件 + 组件管理平台解决。 组件管理平台 dependencies.gradle (自动生成,统一的依赖管理)
17. 阶段二:组件融合 • 挑战: • • • • 路由协议不统一,兼容成本过高。 两侧的组件管理(发布、依赖)方式不同。 H5/Hybrid两侧JS交互协议不同。 业务交互层组件(登录、分享等)存在交互流程差异。 • 方案: • • • • 统一路由。 组件管理方式统一,完善组件管理平台。 通过FlexBridge(自研统一桥接SDK)进行协议抹平。 平台层提供统一接口服务,两侧组件分别注册具体实现。
18. 统一路由 • 统一路由组件及规则。 • 协助业务修改路由定义。 • 对老的路由协议需兼容(H5、外部投放依然会有调用)。 • 相同页面、事件两侧路由规则统一,可直接通过路由抹平两侧实 现差异。
19. 统一路由 // 调用路由组件
20. 组件发布流程
21. 组件发布流程 • 艺龙侧: • 合并代码自动触发Jenkins任务,打包发布 • 发布成功后回写配置文件,打包时通过配置文件拉取组件 优势:开发无需关注发布细节,提升效率 缺陷:灵活性较差,不满足定制化发布 • 同程侧 • 开发统一在组件管理平台进行发布,release版本只能基于master分支发 布 • 发布成功后需在平台手动修改依赖,打包时通过平台接口拉取组件 • 打发布包时会校验组件,发布包不可以依赖snapshot组件 优势:灵活度高,可进行组件的定制化依赖; 缺陷:发布流程较长
22. FlexBridge-统一桥接SDK FlexBridge是同程艺龙统一桥接JS-SDK。为混合应用H5页面提供与 原生App交互的桥接能力。目前支持T/E-APP、H5移动端主流浏览 器、微信端/小程序、手Q端等环境。
23. 平台层统一接口服务 • 定义统一接口,提供给业 务调用 • 两侧组件分别实现 • App初始化时向平台层注 册接口服务
24. 基础组件融合 策略:合并核心功能,保留open api,做到业务最小改动量
25. 优势: • 通过路由解决大部分页面跳转、 事件触发的差异问题。 • 通过FlexBridge解决JS协议差异。 • 相同功能组件只需维护一套。 • 无法融合组件通过统一接口服务, 注册具体实现,与平台层解耦。 • 平台层逻辑单一,易于维护。 • 组件数量缩减,包体积变小。 不足: • 基础组件包含两套open api,存 在冗余。 • 业务交互层核心功能基本相同, 只存在交互层面差异,存在冗余。
26. 阶段三:去平台化 前面提到目前很多无法合并的组件,核心功能大致都相同,只是交互流程有 差异。已合并的组件,为了保证业务最小改动量,依然保留了两套对外接口。 去平台化阶段主要针对以上问题,进行进一步的“组件融合”。 • 目的: • 合并同类项,降低维护成本。 • 为自动化集成打好基础。
27. 阶段三:架构示意
28. 组件管理平台篇
29. 背景介绍 • 前世 • 同程侧组件发布管理,依赖控制。 • 今生 • 组件发布、依赖管理、热修复补丁、快速构建App等。 • 未来 • 合并至移动研发平台,实现一站式全周期管控。
30. 平台概览
31. 新建组件
32. 组件概览
33. 组件管理 • 版本记录可视化,做到历史 版本可追溯。 • 发布记录可查询,定位问题 事半功倍。 • 依赖关系清晰可见,改动影 响一目了然。
34. App依赖管理
35. 业务依赖管理 • 不同业务依赖隔离 • 定制化依赖,可根据 flavor、build、依赖类型 进行定制化依赖
36. 依赖审核平台
37. 组件健康检查 • 趋势可查询,方便管控 • 关联release版本发布,检 测不通过则发布失败
38. 检查报告详情
39. 打包流程概览
40. 优势与规划 • 优势 • • • • 依赖关系、组件列表、操作记录,历史版本全流程可追溯。 定制化依赖,可应对全场景下的特殊依赖需求。 完善的权限、审批流程,保证线上稳定性。 一键新建App,已有业务、组件勾选直接可用。 • 规划 合并至移动研发平台,实现一站式全流程自动化平台。
41. 移动研发平台
42.

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