这是一个只有统计答案才能准确和全面的问题。
为什么
适当的公式是这样的，其中 N 是节点数，bytesN 是在 DOM 中表示它们所需的总字节数，节点索引 n ∈ [0, N)。
字节N = ∑N (bytesContentn + bytesOverheadn)
问题中要求的值是在最坏情况下手持设备、操作系统、浏览器和操作条件下 N 的最大值。为每个排列求解 N 并非易事。上面的等式揭示了三个依赖项，每个依赖项都可能彻底改变答案。
- 节点的平均大小取决于每个节点用于保存内容的平均字节数，例如 UTF-8 文本、属性名称和值或缓存信息。
- DOM 对象的平均开销取决于管理每个文档的 DOM 表示的 HTTP 用户代理。 W3C 的Document Object Model FAQ 指出，“虽然所有 DOM 实现都应该是可互操作的，但它们在代码大小、内存需求和单个操作的性能方面可能会有很大差异。”
- 可用于 DOM 表示的内存取决于默认使用的浏览器（取决于手持设备供应商或用户喜欢的浏览器）、用户对默认浏览器的覆盖、操作系统版本、内存容量手持设备、常见后台任务和其他内存消耗。
严谨的解决方案
可以运行测试来确定手持设备上使用的每个常见 http 用户代理的 (1) 和 (2)。任何给定站点的用户代理分布可以通过配置 Web 服务器的日志机制来获得 HTTP_USER_AGENT 如果默认情况下不存在，然后在日志中剥离除该字段之外的所有字段并计算每个值的实例.
需要针对属性值和 UTF-8 内部文本（或任何编码）测试每个字符的字节数，以获得用于计算 (1) 的明确因素对。
可用内存也需要在各种常见条件下进行测试，这本身就是一个重大的研究项目。
所选择的 N 的特定值必须为零才能处理实际的最坏情况，因此人们会选择一定百分比的内容、节点结构和运行时间条件的典型情况。例如，可以使用某种形式的随机原位（在正常环境条件下）研究对案例进行抽样，并找到满足 95% 的案例的 N。
也许可以通过上述方式对一组案例进行测试，并将结果放在一个表格中。这样可以直接回答您的问题。
我猜想，要想获得合理的结果，需要一名具有良好数学背景的优秀移动软件工程师和一名统计专家全职工作，并且预算充足，大约需要 4 周时间。
更实际的估计
人们可以猜测最坏的情况。经过一整天的研究和一些概念验证应用程序，这个提议可以得到改进。没有时间这样做，这是一个很好的初步猜测。
考虑一个允许 1 GB 用于 DOM 的手机，因为正常操作条件使用 4 GB 中的 3 GB 用于上述目的。人们可能会假设一个节点的平均内存消耗如下，以获得一个大概的数字。
- 每个字符 2 个字节，每个节点 40 个字符的内部文本
- 每个字符 2 个字节，用于 4 个属性值，每个属性值 10 个字符
- 4 个属性名称每个字符 1 个字节，每个属性名称 4 个字符
- 160 字节的 C/C++ 节点开销
在这种情况下，Nworst_case，最坏情况的最大节点数，
= 1,024 X 1,024 X 1,024
/ (2 X 40 + 2 X 4 X 10 + 1 X 4 X 4 + 160)
= 3,195,660 . 190,476.
但是，如果可以避免的话，我不会在具有 300 万个 DOM 节点的浏览器中构建文档。考虑采用以下更常见的做法。
常见做法
最好的解决方案是远低于 N 可能的值，并使用标准 HTTP 设计技术将节点总数减少到可能的程度。
- 减少任何给定页面上显示的内容的大小和复杂性，这也提高了视觉和概念上的清晰度。
- 从服务器请求最少量的数据，使用窗口技术推迟尚不可见的内容，或以精心策划的方式平衡响应时间和内存消耗。
- 使用异步调用来协助实现上述极简主义。