我正在开发一个基于HTML的iPad应用程序，它的UI大量使用JavaScript。 GUI将是类似杂志的，即切入用户然后在触摸事件和webkit转换之间导航的屏幕/视图中。所有这些都在iPad本地运行（通过PhoneGap等原生包装）。
让我们说应用程序将有50-100个屏幕 - 填充标准的Web元素，如文本，图像，表格和表单。
如何构建以获得最佳性能？以下哪两种方法更可取？为什么？
在DOM中只有3个直接（当前，上一个，下一个）视图/屏幕，然后在用户向前/向后导航时将新的（并删除旧的）视图添加到DOM中？
在开始时生成完整的50-100个HTML屏幕，然后隐藏（显示：无）所有这些屏幕，但以上3
所以基本上哪些内存/性能更好？从一方面来看，连续的DOM操作可能代价高昂（并且更糟糕的是使应用程序屏幕之间的转换变得不稳定） - 而另一方面 - 不知道在单个文档中预先生成多达100个HTML屏幕DOM不会让Mobile Safari窒息死亡。当然，即使这些屏幕在DOM中，大多数都是显示屏：大部分时间都没有 - 但是移动的safari垃圾收集器是好的吗？有人试过这个吗？
BTW请注意，这不是图像内存问题/泄漏类型问题。我知道这个问题，无论我走哪条路，都会通过小型虚拟图像卸载技巧处理它。这只是关于HTML视图 - 如果你愿意的话，那就是骷髅。
答案 0 :(得分：0)
如果内容全部将在发布时下载到设备，并且所有内容都在本地缓存，那么一定要使用第一种方法，因为它的内存占用量将大大减少。
如果动态下载内容，我会在1到2之间进行混合...可能预取并在任一方向渲染下两个或三个幻灯片，或者每个方向一个幻灯片，一个用于页面上的每个链接。