前言

相信随着前端职业的兴起，有不少后端或者项目经理觉得前端不就那么回事么？甚至于有些时候，后端一看这么个简单的东西也要做一天？那么本文就带大家了解一下一个还算正常的手机列表页需要那些工作量。

入口

分析列表页首先要看入口，因为一个好的列表页肯定是可复用的，入口的不同将导致列表的数据展示不同以及处理的不同。

做过不止一次从不同入口到同一个列表页，但展示却是不同的，这里可能是因为业务不同，可能是因为权限不同，可能是因为历史操作不同。那么你的入口逻辑就要区分下了，区分不同的入口导致的差别，以及首次和非首次进入的区别。

也有一种特殊处理，就是当是列表页进入详情再返回列表的时候，需要记忆上一步列表的状态。对于app是很简单的事情也许，但对于前端就需要记录比较多的关键点了。可能包括：用户的过滤选择，关键字，请求到的分页信息，请求到的缓存数据，滚动到的位置。对，很明确行业是有明确的方案的，但注意我这里是说的工作量，有这部分需求就需要去实现，去细化，以及测试的。

返回

列表进来了，我不想看，返回了我的入口页面。这里也有很重要的逻辑判断。大部分人觉得返回不就是返回上一个页面么。有时候的确可以如此考虑，但要看你的页面流是什么。

相信很多人知道页面历史记录，在pc端你可以通过多入口很方便的进入到任何一个可操作性的业务入口，但是手机端只能通过返回、关闭以及指定的主页或者其他按钮脱离本页面。

曾经深度研究过网易云音乐app的播放页。它可以是很多页面点击进来的，每种不同渠道的进入，在音乐播放页返回都要返回指定的页而不是简单的历史记录页。所以不要简单的认为手机端的返回就和浏览器的返回前进是一样的。当你的应用需要的时候，这个返回逻辑可以包含不同的业务判断。

也有些逻辑是借助于返回进行的，比如离开页面的风险提示，让你确认操作然后再离开。而有的返回只是当前页某些展示的去掉。

常规列表支持的交互

全量列表 && 分页列表

虽然都是列表，但实际上有很多时候我们的列表数据却可能是总量确定的，可能涉及到某个人某个业务的数据量的时候，就只有不到一屏，或者最多两页，那这种时候，其实全量列表对于用户来说是最合适最友好的，而对于全量列表也就不存在加载更多或者没有更多的情况了。

底部上拉加载 && 无限滚动加载

底部上拉是比较常规的交互方式，现在比较常用的是无限滚动加载直到没有数据可加载。

下拉刷新 && 顶部双击刷新

下拉刷新是比较常规的交互方式，不过已经越来越少用了。现在更多的是顶部双击可以同时达到快速回到顶部并且刷新的作用，对微信朋友圈的交互就是这样的。

没有数据 && 没有更多数据

这两点是完全不同的页面展示，而对于没有数据在特定场景下都有特定的含义。

比如有些情况下，产品需要做一些指引，需要在没有数据的时候引导用户，你可以通过新建数据从而有数据，或者是因为你缺少某些操作、资质之类的原因导致你没有数据可以看。

也有意外情况是因为你的弱网，断网环境导致了你的没有数据。还有一些异常情况也会导致，而针对异常情况是否做单独说明也是需要和产品确认的点。比如服务器网关报错引起的或者程序员开小差了。

而没有更多数据，其展示也越来越趋于简单，正经的文案可能是写，没有更多数据了，调皮一点的会写我是有底线的。

当没有更多数据的时候，作为性能交互优化的角度，也需要在逻辑判断上取消其请求数据的部分，甚至取消上拉本身的逻辑操作。

分页的页数

作为分页的常规逻辑，需要清除的知道每次请求的准确页数。我可以简单分享下自己的逻辑，假设用户是初始状态进入的，那么默认pageNo是1，当触发的时候去请求第二页么？不，不是这样的。

在你请求有数据拿到第一页的时候，其实你就知道总条数以及总页数了。所以在每一次数据请求之前，就可以通过比较pageNo与pageTotal的关系来决定加载触发操作的时候是否有必要请求下一页的数据，其是否还有下一页。

实际上，当我们的当前的pageNo == pageTotal的时候，已经不用请求了；

小于的时候，就需要请求，对应的加载动画，请求接口，取消动画。然后将页数加1 之后，进行重新的判断，如果发现此时，等于了就要下面显示没有更多数据；如果还是小于就可以仍然触发其加载操作。

特别的是，需要大家注意当本来就只有一页数据的时候，你就要显示出没有更多数据了。这种情况基本都会被忽略，因为一般情况下好像生产环境的列表数据不会这么少，而导致测试或者开发测不到这种异常情况的。

加载动画

就是我们常说的loading图，很多交互会认为你不加这个就交互不好呢。我自己的观点是看你接口的请求时间以及对应的操作内是否有数据可看。

具体例子说明下：比如上面提到的无限滚动加载，其实大多数时候，我们是看不到其无限滚动加载的触发动画的，因为其会定义在当你举例底部还有50-100px的时候，就已经去请求数据了，其加载交互在你没看到的底部位置，快的话1s-2s就把下面的数据请求并渲染好了，这样反而是体验好的。但如果你的设置是让其闪现1s出现加载框然后消失那才尴尬呢。那么，为什么开始进来的时候需要加载动画是中央的loading呢，因为此时你没有数据可看。

类似的例子还出现在列表项上支持的某些操作，当你点击请求服务器进行功能的时候，其实你关注点是功能的执行结果，而不是继续看数据，也不想丢失这部分的操作，而在产品设计的角度，也会尽量减少此时其他的不必要操作，所以才会有这样一个交互，告知用户我在处理你的请求里，请稍等。一则是友好，二则避免用户重复点击，造成服务器不必要的负担，以及一些后端逻辑处理上多高并发的问题瓶颈，还有就是多请求多返回的冲突提示。

列表项骚操作

左滑 && 右滑

项目的滑动可以展示更多操作或者信息。也有一些列表在切换类型的tab部分是通过滑动的，而也有列表是通过页面滑动切换列表的。慢慢的这种切换列表的方式会变为主流。

拖拽

很多时候会遇到列表的拖拽来调整顺序，从而达到来调整你的优先级或者喜欢程度等。

双击

双击进行的操作会比较少，但慢慢的也会充当为手机手势常用的一种。

搜索功能

搜索范围

目前的搜索有很多种类型，有本地搜索，有远程搜索。本地搜索指的是以显示的列表中进行关键字过滤，不用请求接口；而远程搜索则是根据关键字进行远程搜索。

搜索触发条件

随着前端交互的增加，触发条件也增加了很多，简单分为以下几种：

• 动态搜索，每当输入发生变化的时候
• 离开焦点的时候
• 输入法回车的时候
• 点击其后面的搜索按钮
• 搜索图标

搜索帮助

做的好的产品会针对之前搜索过的结果进行搜素记录提示，这个提示是个性化的，动态根据历史记录更新的。可以输入部分后再提供的联想搜索结果中进行选择从而搜索。

搜索与常规展示矛盾点

这里简单讲下搜索与常规展示的逻辑处理，以搜索页和常规列表页为一个页面考虑。

搜索列表与常规列表关系

如果你的搜索请求接口和常规列表接口是同一个，一般情况下都是同一个，当进行搜索的时候，得到有效关键字之后，请求数据，需要将页数重置为1，需要提供关键字， 得到搜索结果之后，需要判断其是否有数据，其展示的没有数据和常规列表的没有数据提示是不一样的，不一样在你需要告诉用户：1 搜索的关键字是什么 2 是搜索无结果，区别于常规的无结果。

而当你将关键字去掉，切换为常规列表的时候，需要把关键字去空，页数也重置为1 。这里也延伸的拓展下，如果你还涉及到多个tab列表的切换，那么你的tab可能就是对应到不同的type值的传参，这部分也需要根据对应的部分进行重置。甚至于你可能需要同时进行几种状态的记忆管理，这是很常见的需求。

搜索列表是否和常规列表作为同一个页面

对于这种交互是打问号的，自从有第一个产品在搜索框点击打开新页面之后，搜索页单独打开页面就变成了app交互的一种不成文的习惯。

列表中的懒加载

小谈图片

列表中的图片现在都要支持一定的懒加载，在云音乐的处理中都是开始是默认图，然后是实际缩略图代替。

缩略图规则，一般都是按照比例排版的缩略图。不知道大家有没有研究过微信的缩略图，它可不是简单的把原图尺寸用那么小的尺寸显示那样简单。缩略图涉及到的点这里稍微列举下：

1 缩略图的列表占比，主要作用
2 缩略图一般不是原图，但有一定的转换关系。在阿里的图床中会根据你穿的图片提供至少3中规格的正方形缩略图让你进行选择规格。
3 显示的内容，一般情况下都是原图内容的100%展现，但如果原图宽比不符合缩略图的长宽比，很常见的把，那么就会把原图中间的百分之多少截图作为缩略图展示的部分。
4 控制原图的比例，当然更多时候为了保证产品的统一，可能会控制原图的比例。但如果业务本身是控制不了的，或者本来就不希望控制，也不用控制的。

小谈骨架屏

第一次感受到骨架屏是简书的用户体验，初次感觉没特别的，再反过来对比的时候，发现这样的体验好很多。相信骨架屏会是页面懒加载技术之后，前端体验优化又一个必备必现的技术点。

其核心体验是：先出轮廓，再详细渲染。

总结

其实这里仅仅列举了一个手机列表页的部分逻辑，还没有列举完整，到这里你还觉得做一个列表是很简单的事情么，其实如果从没有很成熟的经验开始做的话，也没有那么容易，需要考虑比较多的事情吧，毕竟列表页是承载很多业务展现形式的载体。

如果你觉得本文还不错，加个喜欢，没有主讲代码技术，但满满的前端逻辑。