我们一直在使用"滴灌"来尝试找出为什么其中包含UpdatePanels的页面倾向于使用大量客户端内存的原因。使用定期回发的页面，我们看到Drip检测到0个泄漏。但是，当我们向混合中添加一个更新面板时，更新面板内部的每个单个DOM对象似乎都会泄漏(根据Drip)。

我不确定Drip是否足以可靠地报告所报告的泄漏确实表明Drip正在稍微修改页面。

有人对这个有经验么？我应该惊慌并停止使用Microsoft Ajax吗？我毫不怀疑微软，但是对我来说似乎很糟糕。

另外，如果我们知道比Drip更好的工具，那也将有所帮助。

解决方案

回答

根据《 ASP.NET AJAX实战》，第38页。 257

Just before the old markup is replaced with the updated HTML, all the DOM elements in the panel are examined for Microsoft Ajax behaviours or controls attached to them. To avoid memory leaks, the components associated with DOM elements are disposed, and then destroyed when the HTMl is replaced.

据我所知，更新面板中的所有asp.net ajax组件都可以防止内存泄漏，但是其中的任何其他内容都将替换为接收到的html。

因此，如果我们在目标容器中没有用于响应的asp.net ajax组件，则其与使用其他js框架/ ajax请求进行的内部html替换基本相同，因此我想说的就是浏览器会处理此问题，而不是导致此问题的asp.net ajax。

同样，尽管它可能是"泄漏"的，但这可能是设计使然，这意味着浏览器可能尚未收回dom元素并释放它们。另外，滴水可能会导致滴漏，因为滴水会附着在这些dom元素上。

回答

那很有可能。这几乎就是我们所假设的(浏览器问题，不一定是Ajax)。

现在我们的问题是，许多人可以通过Citrix环境访问此应用程序，并且每个页面不断创建DOM对象而不释放它们，Citrix环境在使用后开始崩溃。我已经在网上看到过类似的投诉(尤其是我们愚蠢到可以通过Citrix访问Ajax网站的投诉)，但这并没有使我感觉好多了，这是预期的行为。

我想知道现在是否有人想出一个聪明的解决方法。我们也有一个客户端应用程序，我们在其中使用.NET BrowserControl来访问这些网站，而不仅仅是直接的IE7，因此，如果有人知道秘密的API调用(FreeStaleDomObjectsFTW())，我们可以从堆栈的那一端利用该应用程序，也是有用的。

回答

我们可以添加到PageRequestManager类的pageLoading事件，并通过面板的update属性并删除每个属性中的DOM元素。