让 Instagram.com 变得更快

  • 让 Instagram.com 变得更快已关闭评论
  • A+
所属分类:Instagram Followers

先缓存
经过上一篇文章提到的优化,将数据推送到客户端的时间已经尽可能提前了。怎样才能让页面更快的获取数据?唯一的想法是不通过网络请求和推送数据。我们可以使用缓存优先的渲染机制。当然,“缓存”也意味着用户在一定时间内会看到上一页的数据。在这个实现中,一旦页面被加载,我们将立即向用户显示以前的提要和故事的副本缓存,并在新数据可用时覆盖旧缓存。
Instagram.com使用Redux来管理前端状态,所以我们的实现方式是将Redux Store的一个子集存储在更高级别的indexedDB的表中,然后在页面初始化和呈现时将indexedDB缓存的数据状态再水合回存储。但是由于indexedDB操作、服务器数据请求和用户交互是异步的,无法判断它们的顺序。所以当用户操作影响缓存数据时,就会出现问题:我们希望确保对缓存数据的这些更改也应用于服务器返回的数据。
:复水直译为“注水”,不太准确,这里不翻译。有关更多信息,请参考: react中“水合物”一词的含义。
例如,如果以原始方式直接处理缓存的状态数据,我们会遇到这样的问题:首先,我们同时从缓存和网络加载数据,并且由于缓存优先级策略,缓存的数据会首先呈现给用户。然后,用户对某个提要进行“喜欢”操作。之后,一旦这个feed的最新web请求返回,就会覆盖这个feed的状态,被覆盖后,这个feed不包含用户刚才对feed操作的“喜欢”(见下图)。
为了解决这个问题,我们需要一种新的方法,不仅缓存状态,还缓存这些对状态的处理操作,然后在服务器返回的数据中再次执行这些操作。如果你有Git或者其他版本控制工具的经验,看起来熟悉吗?如果把缓存的提要看作一个特征分支,把服务器返回的提要看作一个主分支,那么我们实际需要做的就是在主分支上执行rebase操作,并应用commit (like,comment等)。)上的特征分支到主分支。这给出了以下设计:
页面加载时我们发送请求获取新数据(或者等待服务器主动推送新数据,参考【2285】让Instagram.com更快:提前刷新和渐进式HTML)
创建临时还原状态子集
当请求/推送未完成时,存储所有调度操作
当请求/推送请求完成时,新数据会覆盖临时状态下的数据。此时,这些存储的动作和要在临时状态下执行的其他动作被应用于最新数据
当提交临时状态时,我们直接用临时状态替换当前状态
通过维护一个临时状态,可以重用所有现有的减速器行为,并将临时状态与最新状态分离。另外,我们使用Redux实现临时存储,可以直接使用调度动作,非常方便。
分段API主要包括两种方法:分段动作分段提交(当然也有一些恢复状态的方法和处理边界条件的代码,这里不展开)
暂停操作功能接收一个承诺,该承诺决定将一个操作分派到临时状态。它在初始化期间临时存储状态,然后保存所有已调度的操作。在Git的概念中,我们可以把这个操作看作是创建一个本地分支,因为在新数据到达之前,任何操作都将依次应用于临时状态。
stagingCommit函数用于将暂存状态提交到当前状态。如果临时状态中还有其他未执行的异步动作,它会一直等待。这与Git中的rebase操作:非常类似,它将所有本地更改(来自缓存的特性分支的更改)应用到主节点的前端(服务器返回的新数据),这样本地主节点就可以同时应用远程更改和本地更改,从而更新到最新。
为了更方便地使用临时状态,我们在根级缩减器上封装了一个缩减器增强器,它处理所有要临时存储的动作,并将所有已经临时存储的动作应用到新状态。这样我们只需要调度相关的动作,增强器已经处理了所有其他的事情。例如,如果我们想要请求一个新的提要并将其应用于临时存储的状态,我们将执行以下逻辑:我们对Feed和Story都使用缓存优先渲染,分别缩短了2.5%和11%的页面渲染时间,使页面更接近原生iOS和android的浏览体验。

Instagram买刷粉丝,点赞,观看量,评论,加微信ins1520

weinxin
买粉丝刷赞请加微信:ins1520
专注全球社交数据维护,微博,抖音,Instagram,Facebook,tiktok,YouTube等。