页面管理

带大家深入了解下 Mobilebone 的页面管理机制。

初衷与现实

Mobilebone 设计的初衷,或者说推荐指南从一开始都是建议写预埋项目的各个骨架页,例如,首页、列表页、详情页就是3个独立的骨架:

<div id="pageHome" class="page out"></div>
<div id="pageList" class="page out"></div>
<div id="pageDetail" class="page out"></div>

然后通过 Mobilebone 提供的事件生命周期函数进行数据的请求、渲染与处理,就和目前常见的基于数据驱动的页面开发类似。

如果是基于上面这种策略开发,页面管理本身是不存在的,因为就算有1000个详情页,由于骨架页面就一个,里面内容总是在不断更新替换,因此,整个页面的容量可以一直保持很小,而再顶天的项目也不会超过100个骨架页,对于目前的Web性能而言,可以忽略不计。

但是实际上,根据 issues 反馈来看,绝大多数的开发者使用 Mobilebone 都是直接请求完整 HTML 代码作为页面的模式,类似于您正在看到的这个文档的使用模式,点击导航会去加载一个完整的 HTML 页面并显示出来。

由于一开始 Mobilebone 并没有设计专门的页面管理逻辑,因此,收到很多反馈,例如访问列表页中的 100 个详情页链接,页面中居然有 100 个 div.page 元素,希望最多只出现一个。倒不是性能带来了多大的影响,而是这 100 个详细页会有大量类似的结构和元素,甚至包含大量 id 一致的元素,这会导致很多基于 id 处理的 JavaScript 代码出现问题。

现实与预想的出入让我不得不开始让 Mobilebone 支持页面管理的能力。

默认的行为

Mobilebone 目前默认的管理行为是这样的。

通过 #somePageId 访问的页面元素永远存在文档树中,Mobilebone 不会进行任何删除。

通过 ./someUrl 访问的页面元素则表现为:

所以,不妨就以 Mobilebone 的 API 文档举例,按照 Mobilebone 的默认页面管理行为,整个文档中最多会出现 40 个几乎完整的文档页。

这种情况其实没有任何问题的,因为虽然页面中同时存在大量的 DOM 元素,但是,实际上,占据的体积不过 80K-90K,还没有一张图片的内存开销大,最多同时只有 1 个页面文档内容显示,对于渲染的开销也是可以忽略不计,因此,是没有任何问题的。

所以,Mobilebone 支持页面管理的原因不在于性能,而是需求、维护成本,以及满足开发者的洁癖心理。

设置

对应的效果可以访问相关的测试页面


发现错误?想参与编辑?在 GitHub 上编辑此页