58同城同城iOS客户端搜索模块组件化实践客户端搜索模块组件化实践
引言
58 同城的搜索功能支撑了近一半的用户流量,所以搜索是一个很重要的模块。众所周知,iPhone 的搜索是通过 Spotlight 来
实现的,那么在 App 内部是如何实现搜索呢?首先了解一下 58 同城的搜索需求:
1.58 同城首页,提供搜索功能,称为全站搜。
2.58 同城有二手物品、房产、二手车、招聘、黄页几大业务线,这是粗粒度的业务线。细分一下,二手可以拆分出二手物
品、宠物等类别;房产拆分出租房、二手房等类别;招聘拆分出全职招聘、兼职等类别;黄页拆分出家政、本地服务等类别。
拆分出的这些较细的类别的页面称之为大类页,这些大类页也提供搜索功能,称为大类搜。
3.大类页提供更细粒度的类别,如进入二手房大类页后会看到二手房、新房、商铺、厂房等入口,再次进入后是列表页,这些
列表页也提供搜索功能,称为列表搜。
图 1 是旧的搜索框架,虽然看上去比较清晰,但实际上存在着很多问题,比如代码冗余、耦合度高、不易复用等。这些也是
一些大型模块经过多次升级,到了后期经常存在的问题。接下来具体问题具体分析。
存在的问题
从最开始的 1.0 版本,就在首页实现了搜索功能。随着业务的扩展,58 的业务线也在逐渐成型和完善,每个业务线的大类页
接入搜索功能也存在先后。业务线内部的列表页,更是多种多样,比如 Native 的类别页、Web 列表页,还有特殊的列表页
(如简历库列表页、地图搜房页等),这些列表页后来也都一一实现了搜索功能。不过也正是因为实现的时间有先后,逐渐积
累产生了一些历史遗留问题。
代码冗余
不同的业务页面对搜索功能的支持有先后之别,后实现搜索的页面都是先拷贝一份先实现搜索的代码,然后把其中的业务代码
删除,加入自己的。旧版的业务入口页面各自实现了一套搜索逻辑(如图 2 所示),重复的代码超过一万行。
图 2 业务页面各自实现搜索页面
耦合度高
从图 1 可以看出,搜索页面是由业务入口页面管理和加载的。搜索页面要处理数据,包括热词和搜索历史的本地获取、服务
器获取;要处理网络请求,包括关键词的联想请求、搜索请求;还要实现视图的协议方法。这些大量的逻辑都是在业务页面文
件中实现的。
在代码管理上,尽管已经把搜索相关的代码剥离出来,单独放到了一个 Category 类别文件中,但实际上还是无法避免地跟业
务页面逻辑耦合在一起。