序言

结语

反反复复看下下列四个难题。

倘若你有，那你的标准答案在哪。

他们先来深入探讨两件事，两个后端工程项目怎样从构想不到破冰

比如整座京东主页。标准答案有很多种不同，你看一看有木有你想的那种。

以内，有投弹你的某一点吗？ 无论有木有规矩，这是你想不到的点吗？呢总觉得好似少了点甚么？

本篇该文Gerb讲其它内容。 但到这了就得提一嘴，留个印象。

系统层设计两个新系统留20%来满足当前已有业务。 剩下80% 用来系统演进。可以思考下，京东主页一直变，却依然能保证操控性达标。

业务层设计已有业务是否与其它业务产生了耦合，是否存在前置业务，假如有那前置业务的权限又在哪里。已有业务是否能根据系统演进程度不断兼容新业务？

应用层设计比如微后端，比如模块库，比如npm installwebpack强化骨架屏路有动态按需读取

代码层设计写好高操控性React 代码？怎样利用好Vue3 时间切片？不说了。太初级的浪费慢慢积累就好。

所以，你假如发现了“总觉得好似少了点甚么” 是少在哪里了。对，后端操控性强化不仅仅是应用层面、代码层的强化，更重要的是系统层、业务层的强化。

看了以内的心理预设，那接下来就进入正式进入主题吧。

操控性强化流程

尝试着走完下面这个流程：

小结

现在，你对后端操控性强化有了两个完整的认知了吗？很多时候谈论到操控性强化首先需要谈到怎样对操控性进行“确诊”。虽然大部分情况，你不会被人问到是怎样对操控性进行监控的。（说话声音越来越小。。。）

接下来就细谈强化手段

首屏秒开的多种不同强化手段

1. 懒读取

最常见的强化手段之一。

懒读取是指在长页面读取过程时，先读取关键内容，延迟读取非关键内容。比如当他们打开两个页面，它的内容超过了下载器的可视区口大小，他们可以先读取前端的可视区域内容，剩下的内容等它进入可视区域后再按需读取。

举个栗子。 京东主页精选。上图。

正好是京东618活动。这个IOS版的京东主页精选。假如你经常访问京东主页精选，你会发现它已经几乎做到了科婷下载。懒读取在这就被运用的很好，当然，这里不仅仅是做了懒读取才达到这样的效果。

那只说懒读取，京东主页精选做了甚么呢？ 猜猜看。

懒读取图片懒读取图片是native做过缓存的。在可视区域出现才会读取卡片预先读取（懒读取的时机改变）并不是进入可视区域才读取卡片的。而是当上一张卡片进入可视区域就预先读取下一张卡片。 即使相对于图片，读取卡片UI会快得多。

这也是科婷下载的保障之一。动画懒读取倘若你快速的进行划屏滚动，List慢速高度发生很大变化，那请求数据最后还是会敌不过你的高速滑动。

也就是说，在没有新的数据之前你看不到下一张卡片了，这是你必须等待了。这时候就会有两个loading的动画显示，接着等拿到了新数据，新卡片就会出现并且自动完全滑入可视区域。

这里会有人说了，IOS的阻尼本来就会使得动画、慢速效果更加顺畅。在这里为想说的是，Android也一样可以。

2. 缓存

假如说懒读取本质是提供首屏后请求非关键内容的能力，那么缓存则是赋予二次访问不需要重复请求的能力。在首屏强化方案中，接口缓存和静态资源缓存起到中流砥柱的作用。

回到刚才懒读取提到的那个难题，为甚么你要快速划屏一段时间才会遇见没有新数据的情况？

原因就是缓存的数据已经用完了，所以只能让服务器给予最新的数据。

而假如使用 H5 请求数据，必须等 WebView 初始化之后才能请求（也就是串行请求），而 Native 请求时，可以在 WebView 调用之前就开始请求数据（也就是并行请求），这样能有效节省时间。

那么，怎样通过 Native 进行接口缓存呢？他们可以借助 SDK 封装来实现，即修改原来的数据接口请求方法，实现类似 Axios 的请求方法。具体来说就是，把包括 post、Get 和 Request 功能的接口，封装进 SDK 中。

这样，客户端发 App 缓存中。

91 requests，113 kB transferred, 2.2 MB resources,Finish: 2.93 s,DOMContentLoaded: 177 ms. 2.2M的资源，达到秒开。看一看Size那一列，你就假如好似领悟到甚么了。

没错。HTTP缓存。 数据接口的请求一般来说较少，只有几个，而静态资源（如 JS、CSS、图片和字体等）的请求就太多了。以京东主页为例，91 个请求中除了少数script外，其余都是静态资源请求。

那么，怎样做静态缓存方案呢？这里有两种情况，一种是静态资源长期不需要修改，还有一种是静态资源修改频繁的。你可以尝试多刷新几次页面看一看。

资源长期不变的话，比如 1 年都不怎么变化，他们可以使用强缓存，如 Cache-Control 来实现。具体来说可以通过设置 Cache-Control:max-age=31536000，来让下载器在一年内直接使用本地缓存文档，而不是向服务端发出请求。

至于第二种，假如资源本身随时会发生改动的，可以通过设置 Etag 实现协商缓存。具体来说，在初次请求资源时，设置 Etag（比如使用资源的 md5 作为 Etag），并且返回 200 的状态码。

之后请求时带上 If-none-match 字段，来询问服务器当前版本是否可用。假如服务端数据没有变化，会返回两个 304 的状态码给客户端，说客户端不需要请求数据，直接使用之前缓存的数据即可。当然，这里还涉及 WebView相关的东西，先Gerb讲。。。

3. 离线化处理

离线化是指线上实时变动的资源数据静态化到本地，访问时走的是本地文档的方案。

离线包就是一是离线化的一种方案，是将静态资源存储到 App 本地的方案，这里先Gerb讲。

但更繁杂的另一种离线化方案：把页面内容静态化到本地。离线化一般适合主页或者列表页等不需要登录页面的场景，同时能够支持 SEO 功能。

那么，怎样实现离线化呢？在装箱构建时预图形页面，后端请求落到 index.html 上时，已经是图形过的内容。此时，可以通过 Webpack 的 prerender-spa-plugin 来实现预图形，进而实现离线化。

Webpack 实现预图形的代码示比如下：

4. 并行化

假如说懒读取、缓存和离线化都是在请求本身搞事，想尽办法减少请求或者推迟请求，那并行化则是在请求通道上强化难题，解决请求阻塞难题，进而减少首屏时间。

比如广州打疫苗排队，新闻上报道是怎样怎样阻塞。 那除了让群众错开打疫苗的时间，还可以增加打疫苗的医生数量。他们在处理请求阻塞时，也可以加大请求通道数量——借助于HTTP 2.0 的多路复用方案来解决。

HTTP 1.1时代，有两个操控性瓶颈点，串行的文档传输和同域名的连接数限制（6个）。到了HTTP 2.0时代，即使提供了多路复用的功能，传输数据不再使用文本传输（文本传输必须按顺序传输，否则接收端不晓得字符的顺序），而是采用二进制数据帧和流的方式进行传输。

其中，帧是数据接收的最小单位，流是连接中的两个虚拟通道，它可以承载双向信息。每个流都会有两个唯一的整数 ID 对数据顺序进行标识，这样接收端收到数据后，可以按照顺序对数据进行合并，不会出现顺序出错的情况。所以，在使用流的情况下，不论多少个资源请求，只要建立两个连接即可。

文档传输环节难题解决后，同域名连接数限制难题怎么解决呢？以 Nginx 服务器为例，原先即使每个域名有6个连接数限制，最大并发就是 100 个请求，采用 HTTP 2.0 之后，现在则可以做到 600，提升了 6倍。

你一定会问，这不是运维侧要做的事吗，他们后端开发需要做甚么？他们要改变静态文档合并（JS、CSS、图片文档）和静态资源服务器做域名散列这两种开发方式。

具体来说，使用 HTTP 2.0多路复用之后，单个文档可以单独上架，不需要再做 JS 文档合并了。这里提两个保留难题，用过阿里系的Antd模块库吧？库每次更新都不是全部更新，可能这次只更新两个Button模块，再次只更新两个Card模块。那是怎样做到单独模块单独发版的呢？

为了解决静态域名阻塞（这是个操控性瓶颈点），需要将静态域名分为 pic0-pic5，这样能提升请求并行能力。 虽然通过静态资源域名散列的办法解决了难题，但DNS 解析时间会变长很多，同时还需要额外的服务器来满足。HTTP 2.0 多路复用解决了这个难题。

最后我还整理整理许多Android 开发相关的学习文档、面试题，希望能帮助到大家学习提升，如有需要参考的可以直接私信“1”找我参考。