前端如何实现业务解耦，携程酒店查询首页的 1.0 到 3.0

酒店查询首页，是用户使用携程 APP 进行酒店预订的第一个页面。它提供了各种类型的酒店筛选入口，让用户进行酒店选择。随着查询首页版本不断迭代，其对应业务，功能和样式经历了由简单到复杂，单一到丰富的过程。

为了更好的适应业务的快速迭代，查询首页的结构也经历了多个版本优化和重构。本文将分享携程酒店是如何根据查询首页自身业务需求特点，进行代码结构优化和重构的。

根据查询首页不同时期业务和代码结构特点，简单的把结构迭代版本划分为三个版本。分别对应简单的 1.0，头疼的 2.0，合适的 3.0。

1.0

1.0 版本是酒店查询首页最早期的一个版本，它所包含的业务可以简单的由上到下做垂直划分，顶部的标题模块，中间提供给用户进行输入的查询模块，以及酒店底部推荐模块。如下图所示：

根据这种业务特点，将不同业务模块抽象为不同的 Fragment。将这些 Fragment 统一放到 ScrollView 中进行布局，InuqireCacheBean 用来管理 Fragment 的数据，具体的结构如下图：

从上图看，1.0 采用的是典型的 MVC 模式。结构清晰明了，但是业务逻辑代码和样式布局全部耦合在相应的 Fragment 里。如果一直维持这个结构，那么随着业务不断迭代和增加，Fragment 里面的代码会越来越臃肿，业务的实现成本和排查问题的难度都会越来越大。

2.0

下面的三张贴图是 2.0 版本时期新增的一些业务所对应的样式。

2.0 版本查询页的功能和样式比 1.0 都要丰富和复杂很多。根据这种特点，对查询页进行了模块化拆分，把不同的业务抽象成对应的 Moudle，通过 Module 管理自身业务和 UI 布局。

上图是查询首页 2.0 的架构图，它的容器仍然是 HotelInquireActvity，通过 ScrollView 管理 TitleFragment, InquireCoreFragment，RecommendFragment 和 BottomFragment。

BottomFragment 是 2.0 新增的一个 Fragment，它目的是展示和管理查询首页底部新增的 Moudle。Module 的设计采用 MVP 模式， BizMoudle 代表 V 层，会向外暴露一个 getView 接口，用来展示该业务的样式，BizMoudlePresenter 代表 P 层，用于处理业务逻辑，BizMoudleRepositery 代表 M 层，用于处理数据。Module 的结构如下图：

InquireBizConfig 是各个业务 Module 配置管理器，用于管理加载不同业务对应 Module。InquireBizConfig 由两部分组成，一是 BizConfig，二是 BizManager。

BizConfig 内部核心是一个 Map 数据结构，用于注册查询首页需要用到的所有 Module，BizManager 内部核心是一个 List 数据结构，用于加载和定义各个业务 Moudle 的展示位置顺序。

当 BottomFragment 加载启动的时候，会调用 BizManager 里面的 startLoadMoudles()方法，这个方法会遍历 List,取出相应的 Moudle 加载到 BottomFragment 中，它的结构如下图所示。

从 2.0 架构图看，对查询首页业务进行了模块化拆分，可以方便团队中不同业务的开发 Owner 进行同时开发，减少了相互的干扰，提高了业务需求的交付效率，但美中不足的是结构没有做到统一。

有的业务以 Fragment 形式存在，有的业务以 Module 形式存在。该结构还会存在性能黑洞，当 BottomFragment 启动时，会加载所有配置的 Moudle，把所有 Moudle 的 View 加载到布局容器 ScrollView 中，无论这些 Moudle 是否在第一屏展示，影响查询首页的启动性能。

另外由于布局容器采用的 ScrollView，如果业务 Module 里面采用了 ListView 控件，EditText 控件等，那开发必须使用额外的逻辑去处理 ScrollView 和这些控件带来的兼容性问题。布局容器采用的 ScrollView，带来的交互实现成本也很高。

3.0

为了解决 2.0 结构存在的问题，我们又进行了 3.0 版本迭代。

3.0 版本主要围绕 2.0 版本存在的两个问题，一是根布局使用 ScrollView 带来的性能和兼容性问题；二是结构没有统一，业务分别以 Module 和 Fragment 形式存在的问题。

针对 ScrollView 产生的问题，分别选择了三种可替代 ScrollView 的方案。

第一种是使用 RecyclerView, 通过 Type 来区别各个业务对应的布局，这个方案是理论上行的通的，但是需要改造各个 Moudle 对应的数据结构，需要将不用业务的数据结构进行结构统一，改造成本太高，实现起来难度和风险较高。

第二种采用酒店内部控件 GroupListView 控件，该控件的核心是基于 ListView，它是将不同的 Adapter 融合到一个 Adapter 中。

第三种方案是使用开源组件 Vlayout，该控件的实质是异构的 RecylerView，原理和 GroupListView 相似。

对比第二种和第三种方案，RecyclerView 解决了 ListView 不能局部刷新的问题，另外 RecyclerView 设计上采用四级缓存，在性能上也比 ListView 更优，可为查询首页将来支持流畅性较高的复杂交互做好准备。

基于以上考虑，选择第三种方案替代 ScrollView。对之前 2.0 存在的 TitleFrament，InquireCoreFragment，ReCommendFragment 进行模块化改造，分别改成为 TitleModule，InquireCoreModule，ReCommendModule，移除 2.0 作为 Mudule 容器的 BottomFragment。经过改造后，3.0 的结构图如下：

经过了 3.0 版本的结构迭代和优化，所有的模块都统一抽象为了 Moudle，结构变得更加清晰简单。采用 Vlayout 替代 ScrollView，解决了 2.0 结构版本中潜在的性能黑洞问题，同时 Vlayout 提供了大量的 UI 模板，避免了前端重复造轮子，提高了业务交付效率。

小结

酒店查询首页经过三个版本迭代和优化，结构趋于稳定，为查询首页的未来业务快速交付和生产环境稳定打下了良好基础。

在对酒店查询首页优化和改造时，根据我们团队的特点，采用了渐进式的架构迭代思路，这样既保证了业务需求的交付，也避免了重构带来的风险。

同时也给前端如何实现业务解耦，如何在保证页面性能的前提条件下，承载大量不同的 UI 布局元素提供一种优化借鉴思路。

作者介绍：

何金，携程酒店研发部 Android 资深软件开发工程师，负责酒店代码性能优化、结构改造、疑难问题排查处理，以及 Kotlin 的推广和应用。

本文转载自公众号携程技术中心（ID：ctriptech）。

原文链接：

https://mp.weixin.qq.com/s/lSftYyTW5s009kSPUXeZBA