1. 1. 整合 uniapp 项目和远程资源
   2. 埋点
      1. 分离埋点内容和页面逻辑
      2. 延迟埋点请求不阻碍业务请求
      3. 丢弃响应时间过长请求
      4. 单独为埋点提取一个请求函数
   3. 自定义导航栏
   4. 后台的配置跳转
   5. 提高页面的 LCP 性能指标
   6. 引用

下面的内容是工作时的一些记录，包括了原始项目里已有内容的好的设计的记录和自己在开发过程里遇到的问题的记录。

整合 uniapp 项目和远程资源

问题:

（uniapp）开发小程序时，小程序有体积限制，例如微信小程序的体积不能超过 20M，所以如果项目中需要使用许多静态资源，静态资源就不能放在小程序的产包中，必须放在存储静态资源的服务器中。可是，放在服务器中的资源不能体现在小程序项目结构里，代码只会硬编码引用这些资源的链接。如果队友误删了服务器中某个资源，代码里引用的该链接将失效，也不能复原；如果删除了代码里的引用链接，又忘了删除服务器资源，会让服务器资源冗余。所以需要一种方法来跟踪资源的变化，同步引用链接和服务器资源。

方案:

资源放在项目结构中，并且同步至服务器。在代码里，设置一个路径前缀，用于引用资源。在项目的打包阶段，检测产包的环境，如果产包用于生产环境，替换路径前缀为资源在服务器上的路径；如果产包用于开发环境（热重载环境），替换路径前缀为资源在本地项目中的路径。

解释：

同步本地资源和远程资源是为了 git 管理，为了可以跟踪文件变化，为了可以在远程资源被误删的时候还能从本地资源复制到服务器，达到还原的效果。

同步最简单的方法是，在需要添加资源的时候，把资源复制到项目里用于 git 管理，再把资源复制到服务器用于引用。当远程资源被误删的时候，就可以把本地 git 管理的所有资源完整复制到服务器。

但是在实际操作的时候这样执行还会遇到一个问题，不能保证不会在把资源传输到服务器之后忘记把资源同时也复制到项目中。这是因为

• 代码中实际引用的是远程资源，而本地项目资源只用于 git 管理，没有其它作用；
• 同步是人工的，如果要同步到 10 个服务器，很可能在同步的时候遗漏；
• 如果每次先上传远程资源，开发进度紧张，虽然遗漏了本地资源，但开发预览的时候还是正常，会造成更容易忽略复制本地资源的步骤。

这里通过让本地资源被运用到开发过程里的一环来解决上面的问题。

开发过程可以被分成“开发环境”和“生成环境”，生产环境定义为测试、验收和上线的环境，开发环境定义为正在本地开发时的环境。回到上面的问题，项目里需要引用资源，而在开发环境可以不依赖服务器上的资源，也就是可以不引用远程资源，因此可以在本地开发的时候，引用本地资源，在生产环境的时候，引用远程资源。

这样在开发环境顺利开发完成后，从开发环境切换到生成环境，如果服务器上没有和本地项目里对应的资源，生产环境的产包就不能正确加载资源，所以这时一定会把本地项目里的资源同步复制到服务器中。这就解决了两次复制造成冗余的问题。

这其中相比最简单的方法有两个变化：

• 测试环境使用本地资源进行引用；
• 强制首先复制到项目本地资源，最后统一同步复制到远程服务器。

至于怎样在开发的时候引用本地，在生产的时候引用服务器，一定不是全局手动替换，例如把所有“/assets/logo.png”替换为“https://demo.com/assets/logo.png”。可以利用代码打包工具，例如在打包阶段，设置遇到了“%img-path/”就根据当前的环境进行替换，如果是开发环境，就把“%img-path/assets/logo.png”替换为“/assets/logo.png”，如果是生产环境，就把“%img-path/assets/logo.png”替换为“https://demo.com/assets/logo.png”。

埋点

分离埋点内容和页面逻辑

问题：

埋点内容和页面逻辑无关，直接添加在逻辑代码的首行或者末行会让代码变得混乱，提高阅读维护复杂度。

方案：

埋点内容整理成单独的模块进行管理。用声明式的方式进行埋点，在埋点时只传递必要变量，不在埋点处进行逻辑计算。

解释：见数据埋点（二）。

延迟埋点请求不阻碍业务请求

已为此源打开六个 TCP 连接，这是限制。 仅适用于 HTTP/1.0 和 HTTP/1.1。 — 网络功能参考-计时细分阶段说明

问题：

HTTP1.1 有最大连接数限制，当超过了这个限制，请求会被挂起。如果有很多的埋点请求跑在了业务请求前面，当埋点请求长时间没响应，就阻塞了业务请求，会导致用户不能正常访问。

方案：

维护一个保存埋点数据的数组和一个计时器，每次检测到新的请求，就延迟计时器，当没有请求了，到达了计时器设定的时间，统一发送保存在数组里的埋点数据。

解释：可以设置计时器，3s 内没有新的请求就发送埋点请求。

丢弃响应时间过长请求

问题：埋点请求如果响应时间过长，会影响业务请求的加载。

方案：设置 2s 内如果请求不响应，就丢弃这条请求。

解释：如果埋点请求不要求一百分的正确响应，可以丢弃一些影响业务的埋点。

单独为埋点提取一个请求函数

问题：埋点和业务的请求有很多不同的地方，如果写在一起会造成混乱，阅读和维护会变得困难。

方案：埋点请求相关的代码封装进独立的文件中。

解释：

埋点请求在很短的时间内无响应就要丢弃，而业务则会一定等待响应完成；埋点不需要 cookie，而业务需要；业务会在响应时间过长展示全局 loading 图标，而埋点不需要……

自定义导航栏

问题：原生导航栏要在配置文件中注册，自定义导航栏是为了扩展原生导航栏的功能（例如是否需要登录，是否展示，节假日特殊图标等），这里的问题是扩展的方式，是在配置文件中扩展还是业务代码中扩展。

方案：在页面代码中扩展，首先获取配置文件中的原生导航栏配置，再在这个配置对象中添加自定义导航栏的信息。

解释：

如果在配置文件中扩展，会破坏配置文件的规范，队员看到陌生的配置后也不能从官方文档中查到，另外 uniapp 在运行项目前会进行一次编译，不能确定将来的版本在编译时会不会把不符合规范的配置删除。

后台的配置跳转

问题：

方案：

解释：

提高页面的 LCP 性能指标

其它：

HTTP1.1 的最大连接数：

1
2
3
4
5
6
7
8
9
10
11

Firefox 2:  2
Firefox 3+: 6
Opera 9.26: 4
Opera 12:   6
Safari 3:   4
Safari 5:   6
IE 7:       2
IE 8:       6
IE 10:      8
Edge:       6
Chrome:     6

引用

• Max parallel HTTP connections in a browser?：浏览器最多能打开多少连接？