企业官网建设流程全解析

先说个背景：前阵子接手一个老项目，里面所有移动端H5页面都是jQuery Mobile搭的，列表视图（listview）是撑起整个产品主线的核心组件——通讯录、订单列表、消息流、设置项，全是它。刚接手时我对这框架的印象还停留在“老、慢、没人用”，真正把代码翻完才发现，jQueryMobile的列表视图在设计上有很多顺手的地方，尤其适合快速原型、传统WebView壳子、以及旧系统维护这三类场景。

如果你正准备用jQueryMobile做列表页，或者正在维护一个用jQueryMobile做的老系统，这篇内容应该能帮你省下不少试错时间。我会从最基础的DOM结构讲到动态渲染、分组过滤、滚动加载、性能优化和那些文档里不会写的坑，尽量按实际项目里的真实处理方式来写。

1. 列表视图的定位与选型思路

1.1 为什么说它是移动端页面的基础组件

移动端页面和信息密集的桌面端不一样，屏幕就那么宽，用户没什么耐心。列表视图的本质，是把“一组同类的入口或数据”压缩成纵向可扫读的条目，每条只留最重要的信息区。jQueryMobile把这种形态封装成了listview组件：一个ul标签加><ul>var listHtml = ''; $.each(data, function(i, item) { listHtml += '<li><a href="' + item.url + '">' + item.title + '</a></li>'; }); $('#myList').append(listHtml).listview('refresh');

refresh()内部会做三件事：重新统计li数量、给新条目补上组件约定的CSS类、重新计算分割线位置。我见过不少人在动态加载列表上踩坑，最后解决问题的就是这一行代码。

注意一个版本细节：jQueryMobile 1.3以及更早的版本，初始化列表用的还是$("#myList").listview()这种老式调用；1.4之后组件整个搬到了jQuery UI Widget工厂的规范下，refresh()才是标准做法。动态列表里如果需要触发子页面里的组件增强，比如新插入的li里嵌了一个滑块，光refresh()还不够，要看下一节嵌套内容怎么处理。

2.3 缩略图、计数气泡、按钮位这些增强项怎么加

实际项目里的列表很少是纯文字。消息列表要有个头像，购物列表要显示价格和数量，任务列表后面还得跟上“完成”或“删除”的操作按钮。jQueryMobile这一点做得很轻：不需要额外初始化，只要按约定加对应结构和属性。

缩略图用li里的img标签，自动按列表高度裁剪显示：

<li> <a href="#msg-detail"> <img src="avatar.jpg" class="ui-li-thumb"> <h2>消息标题</h2> <p>这是消息摘要</p> </a> </li>

加了ui-li-thumb后图片会固定到列表条目的左边，jQueryMobile还会把旁边的标题文字自动做垂直居中，效率很高。想显示数字角标，给li加><li> <a href="#inbox"> 收件箱 <span class="ui-li-count">12</span> </a> </li>

这个气泡会吸附在条目右侧，颜色位置都替你算好了，适合做待办数量、未读消息数这类场景。需要右侧操作按钮时，一个li里放两个a，第二个加><li> <a href="#order-detail"><h2>订单号12345</h2><p>状态：待发货</p></a> <a href="#order-delete"><div><ul>$.mobile.listview.prototype.options.autodividersSelector = function(li) { var text = $(li).text(); var pinyin = convertToPinyin(text.charAt(0)); // 自定义拼音转换函数 return pinyin.toUpperCase(); };

这个配置在1.4里依然有效，重写选择器可以完全控制分隔条文案。拼音转换函数建议自己封装或引入成熟的拼音库，但注意老项目的运行环境，库的体积和兼容性得衡量一下。

3.3 过滤功能与动态数据组合的细节

列表长了以后，分组还不够，最好能搜索。jQueryMobile自带过滤，ul上加一个><ul>var allData = getDataFromServer(); var start = 0; var batchSize = 100; function appendBatch() { var end = Math.min(start + batchSize, allData.length); var html = ''; for (var i = start; i < end; i++) { html += buildListItemHtml(allData[i]); } $('#myList').append(html); $('#myList').listview('refresh'); start = end; if (start < allData.length) { setTimeout(appendBatch, 0); } } appendBatch();

用setTimeout分批插入，每轮只渲染100条，一轮一轮往后走，能极大减少单次布局计算量。实测下来，2000条数据大概是45秒，但至少页面一直是活着的，用户能看到列表逐渐变长，体验比一次性卡死好得多。

4.2 滚动加载与分页的完整做法

数据量再大，分批渲染也会把全部数据推进DOM，内存和滚动性能依然会崩。正确姿势是做滚动加载：用户滚到接近底部时才去请求下一页数据，只把当前需要的条目渲染出来。

基础判断逻辑：

$(window).on('scroll', function() { var scrollTop = $(window).scrollTop(); var viewportHeight = $(window).height(); var documentHeight = $(document).height(); if (scrollTop + viewportHeight >= documentHeight - 100) { loadNextPage(); } });

注意几个细节：

• -100是触发阈值，别等滚到底才加载，不然用户会感觉停顿。
• loadNextPage()里要维护一个loading标志位，防止滚动事件连续触发导致同一页数据被请求两次：

var isLoading = false; function loadNextPage() { if (isLoading) return; isLoading = true; $.ajax({ url: '/api/list?page=' + pageNum, dataType: 'json', success: function(res) { appendData(res.data); pageNum++; isLoading = false; }, error: function() { isLoading = false; } }); }

加载完新数据后同样要refresh()，否则新条目没有列表样式。有些项目还会在底部插一个“正在加载”图标，这个可以直接用jQueryMobile自带加载器：

$.mobile.loading('show', { theme: 'b', text: '加载中...' });

但注意，加载器一开，DOM事件可能被劫持，ajax回调里要记得$.mobile.loading('hide')。

4.3 低端机上的动画与阴影开销

就算做了分批和分页，低端WebView上还有一个隐性问题：jQueryMobile默认的列表卡片带阴影、圆角、渐变色，这些视觉细节在低配设备上会显著拖慢滚动帧率。项目里如果明确跑在工控平板或者老安卓机上，建议做一些精简。

最直接的办法是动态切换主题，或者用一个自定义样式覆盖掉阴影和圆角：

.ui-listview > .ui-li { border-radius: 0 !important; box-shadow: none !important; text-shadow: none !important; }

实测在低端安卓WebView上，去掉阴影和渐变后滚动流畅度能提升一个台阶，肉眼可见。列表条目里的图片也要控制尺寸，别让img加载原始大图，统一处理成缩略图再塞进列表，体积能少一个量级。

另外，jQueryMobile的页面切换默认带过渡动画，列表页如果频繁切换，把动画关掉会更快。页面绑定处加上：

$.mobile.defaultPageTransition = 'none';

这行代码在很多老项目里非常管用，能让整个应用手感瞬间快起来，代价只是少了点视觉过渡而已。

5. 交互事件与最典型的几个坑

5.1 tap、click、vclick：移动端点击事件怎么选

移动端老场景里，点击事件有很多讲究。原生click在移动浏览器上有300毫秒左右的延迟，因为浏览器要判断你是不是在双击缩放。jQueryMobile为了解决这个问题提供了tap和vclick事件。

tap是jQueryMobile自定义的触摸事件，响应快，但有个毛病：用户手指在列表上轻轻滑动时，如果滑动距离很小，也会被判定成tap，导致误触发点击。这在列表滚动操作里很烦人。vclick是虚拟click，试图在触摸和click之间做桥接，可它在某些版本上存在事件冒泡和触发两次的bug，踩过的人不少。

我的实际经验是：如果你的列表项是一个a链接，那就直接用默认的click行为，别自定义事件，jQueryMobile自己用tap做了处理，跳转逻辑交给框架就好。如果是要做“点击这个条目后标记已读”“点赞”“展开收起”这类自定义交互，比较稳的是绑定click然后自己preventDefault，并配合touchstart这一类原生事件来消除延迟感：

$('#myList').on('click', '.list-item-action', function(e) { e.preventDefault(); // 这里做你的自定义逻辑 });

在jQueryMobile 1.4里面，移动浏览器很多已经消除了点击延迟，直接用click问题不大，反而避免了一堆tap误触和vclick重复触发的疑难杂症。

5.2 refresh以后为什么样式还是不对

动态追加数据后调了refresh()，样式还是有问题，这是高频问题。我排查过很多次后发现，大多是下面几种原因。

第一种：追加的HTML里li结构不完整。比如少了<a>标签，或者图片没有class="ui-li-thumb"，refresh只能重新计算样式，补不了缺失的结构类。检查生成的HTML是否符合预期再调函数。

第二种：在页面还没完成初始化时提前调refresh()。jQueryMobile的增强流程比较特殊，如果你的脚本在组件初始化之前就想操作列表，经常拿不到对应的widget实例。做法是把动态加载逻辑放到pageinit或pageshow事件之后：

$(document).on('pageinit', '#listPage', function() { loadDataAndRefresh(); });

第三种：图片还没加载完成就调refresh()，导致高度计算错位。列表条目高度取决于图片加载完后的实际大小，图片没ready时refresh算出的是默认高度。解决方法是图片load事件后再refresh一次：

$('#myList img.ui-li-thumb').on('load', function() { $('#myList').listview('refresh'); });

这种细节在文档里基本找不到，都是实际调试时才能发现。

5.3 拆分按钮与事件冒泡

拆分按钮（一个条目里两个a）的功能键非常容易出问题。我遇到过一个bug：点击右边“删除”按钮，结果页面跳到了左边的主链接地址。原因就是两个链接都在同一个li内部，点击右边的按钮时事件冒泡到了父节点，被列表默认的点击处理逻辑截获。

解决思路比较直接：在分拆按钮的处理函数里阻止事件继续冒泡，并调用preventDefault：

$(document).on('click', '[data-split-icon="delete"]', function(e) { e.preventDefault(); e.stopPropagation(); // 执行删除操作 });

注意必须两个方法都调用。只preventDefault不stopPropagation，jQueryMobile的列表点击增强还是会触发主链接跳转；只stopPropagation不preventDefault，浏览器默认的链接跳转也可能发生。同时建议把事件绑定在document上做事件代理，因为列表条目经常是动态生成的，直接给a绑事件的话新条目根本没有监听。

6. 常见问题排查实录与速查表

6.1 几个高频问题的排查流

动态列表样式失效、过滤搜不到新数据、滚动加载重复请求……这些问题反复出现时，我总结出了一个固定排查顺序。

第一步，确认refresh()调用时机对不对。原则是：必须在插入DOM之后、并且列表widget已经初始化成功之后再调用。可以打开浏览器控制台执行$('#myList').data('mobile-listview')，看返回是不是undefined。如果是undefined，说明列表还没被增强，得先检查页面有没有正确加载jQueryMobile脚本和><ul>$('#parentList').listview('refresh'); $('#parentList').enhanceWithin();

不加这行，子级ul可能显示成一坨无样式的普通列表。这个问题我遇到时排查了很久，最后是在控制台里一层层展开DOM才发现子ul的class不对。

6.3 问题速查表

我把项目里实际遇到过的高频问题整理成一张表，方便对照：

这张表不一定覆盖所有诡异场景，但能覆盖百分之八十。剩下的疑难杂症，建议先在控制台里把列表的DOM结构完整展开一遍，再决定到底是在样式层还是事件层去调整。

关于这套列表视图，我个人最大的体会是：它并不是一个性能怪兽，但在老项目的维护场景里，它的稳定性和低门槛非常值钱。你不需要重新学一套渲染框架，只要掌握ul、li、>