诺基亚S40系列是非智能手机时代出货量极大的功能机平台，它的内置浏览器基于Opera Mini的早期内核改造而来，JavaScript可用堆内存通常只有256KB到512KB之间，个别老机型甚至更低。在这样的硬件条件下跑完整的jQuery库并发起XHR请求，本身就是一场和内存的贴身搏斗。很多开发者第一次把PC端的代码直接移植到S40上时，发现页面刚加载就报错，或者第二次发起ajax请求时整个浏览器直接崩溃退出。这篇文章就来拆解这个看似冷门但极具代表性的问题：在极端内存限制下，jQuery的XHR请求链路到底哪里最吃内存，又该如何压缩到可用状态。
一、先搞清楚S40平台的内存特性
S40平台的浏览器运行时和现代浏览器完全不是一个量级的东西。它没有成熟的垃圾回收调度，字符串拼接会产生大量临时对象，而每次XHR请求返回的responseText又是一个完整的字符串，这些字符串在低堆内存环境下会迅速占满可用空间。理解这一点非常重要，因为在PC端我们习惯了先拿到完整响应再解析的思维，而在S40上，一个100KB的响应文本配合解析过程中产生的中间对象，实际内存峰值可能达到响应体积的三到五倍。
另一个关键特性是S40的浏览器对同时存活的XHR对象数量极其敏感。经验值是同时不要超过两个活跃请求，超过之后浏览器可能静默丢弃连接或者直接重启页面。jQuery的ajax模块默认会为每个请求创建完整的Deferred对象链、若干内部回调闭包以及一个包装的jqXHR对象，这些附加结构在PC端可以忽略不计，但在512KB的堆里就是实打实的开销。
还有一个容易被忽视的坑：S40的垃圾回收触发时机很不及时，对象失去引用后内存并不会立刻归还。这意味着即使你在代码里把请求相关的变量置为null，内存峰值依然可能维持在高位，直到浏览器主动触发GC。所以优化的核心思路不是“用完释放”，而是“从源头减少分配”。
二、jQuery.ajax在低内存下的吃内存环节
先看一个典型的反例代码，这是很多从PC端移植过来的项目里最常见的写法：
// S40上危险写法：一次性拉取大响应并整体解析
$.ajax({
url: '/api/feed/list',
dataType: 'json',
success: function(data) {
// data是完整解析后的JSON对象树
// 在S40上，解析过程会瞬时产生大量中间对象
var html = '';
for (var i = 0; i < data.items.length; i++) {
// 字符串拼接在S40上非常昂贵
html += '<li>' + data.items[i].title + '</li>';
}
$('#list').html(html);
}
});这段代码在PC端毫无问题，但在S40上会连续踩中三个内存雷区。第一个雷区是dataType设为json后，jQuery内部会用JSON.parse（或者更老环境下的eval）把整个responseText解析成对象树，解析过程中的中间对象开销是响应文本体积的好几倍。第二个雷区是循环里的字符串拼接，每一次+=都会创建一个新的字符串副本，1000条数据的列表拼接下来临时字符串对象会疯狂累积。第三个雷区是$('#list').html(html)，jQuery会把整段HTML字符串解析成DOM节点，如果列表很长，DOM树本身的内存占用可能比JSON对象还大。
除了业务代码的问题，jQuery内部流程中还有一个隐藏开销：jqXHR对象会挂载complete、success、error等多个回调列表，再加上Deferred机制产生的promise对象，单个请求的固定附加开销在S40上大约相当于几KB的堆内存。如果页面上存在轮询场景，比如每5秒请求一次服务器状态，这些jqXHR对象如果没有被正确释放，累积十几次请求后内存就会见底。
三、针对S40的实战优化方案
第一招是控制响应体积，这是收益最大的一步。服务端必须为S40这类低端终端提供精简接口，只返回必要字段，单次响应控制在10KB以内最为稳妥。同时用分页把大数据拆小，比如一次只拉20条记录。千万不要想着“一次拉完慢慢用”，在几百KB的堆内存里这种想法就是灾难。
第二招是改造客户端的解析和渲染方式，核心思路是避免大字符串操作，改用数组加一次性join，并且分批插入DOM：
// S40优化写法：数组拼接 + 分批渲染
$.ajax({
url: '/api/feed/list?page=1',
dataType: 'json',
cache: true, // S40缓存可减少重复请求开销
success: function(data) {
var buf = [];
var items = data.items;
for (var i = 0; i < items.length; i++) {
buf.push('<li>', items[i].t, '</li>');
}
// 一次性join，减少中间字符串
$('#list').html(buf.join(''));
// 及时断开引用，让GC有机会回收
buf = null;
items = null;
data = null;
},
complete: function() {
// 轮询场景下务必解绑，避免闭包累积
$(this).unbind && $(this).unbind();
}
});第三招是治理请求生命周期。轮询场景下不要用setInterval直接叠加请求，而是用请求完成后再调度下一次的方式，保证同一时刻只有一个活跃XHR对象。示例如下：
// 串行轮询：同一时刻只有一个XHR存活
var pollTimer = null;
function pollStatus() {
$.ajax({
url: '/api/status',
dataType: 'text', // 简单状态用text，避免JSON解析开销
timeout: 8000,
success: function(resp) {
$('#status').text(resp);
},
complete: function() {
pollTimer = setTimeout(pollStatus, 5000);
}
});
}
pollStatus();这种串行调度的好处是，上一个请求的jqXHR对象在complete回调执行完毕后就没有任何引用了，即使GC不及时，内存占用也是常数级别的，不会随时间累积。
四、精简jQuery还是直接用原生XHR
做完业务层优化后，还会面对一个架构层面的选择：继续用jQuery还是换原生XHR。完整的jQuery 1.x压缩后大约90KB，加载后运行时还要再消耗几十KB堆内存做初始化。如果项目只用到ajax和简单的DOM操作，可以考虑用自定义构建工具裁掉动画、Sizzle选择器引擎等模块，把体积压到30KB以内。当时的做法通常是下载jQuery源码后手动剔除不需要的模块，再重新压缩打包。
如果页面的DOM操作本身极简，那么彻底放弃jQuery、直接封装一个原生XHR的轻量请求函数反而是更优解。原生XHR在S40上的内存足迹比jqXHR小得多，没有Deferred和回调列表的额外结构。下面是一个经过多个S40项目验证的最小实现：
// S40极简XHR封装：内存足迹远小于jqXHR
function tinyGet(url, onDone) {
var xhr = new XMLHttpRequest();
xhr.open('GET', url, true);
xhr.onreadystatechange = function() {
if (xhr.readyState === 4) {
// 回调后立即断开引用
var text = xhr.responseText;
xhr.onreadystatechange = null;
xhr = null;
onDone(text);
}
};
xhr.send(null);
}两者怎么选的判断标准很简单：如果页面有复杂的DOM操作和事件委托，裁剪版jQuery带来的开发效率值得那部分内存开销；如果页面就是纯粹的“拉数据、展示文本”，原生封装配合手写的getElementById足以胜任，还能省下一大块内存留给业务数据本身。当时不少S40项目最终采取的是混合策略，核心列表页用原生实现，表单页等交互简单的页面保留精简版jQuery。
回头看这段历史，S40上的内存约束逼出来的这些技巧，本质上都是在回答同一个问题：如何在资源极度有限的环境里，让每一次分配都有明确的目的和归宿。这个思维方式在今天的低端安卓设备、嵌入式WebView乃至物联网浏览器场景中，依然是Web开发者最值得练的基本功。