小程序优化:第三方SDK过大解决方案

【前言】

小程序开发中,有时会遇到下面这种情况,项目目录中存放过大的js包,会被警告影响手机端性能,同时让开发编译启动变得很慢。慢是其次,单是影响性能这一点,就需要解决一下。

【云资源】

将项目js包放入公司的oss、obs之类的云存储上,通过https链接来访问。

https链接不能使用node的require加载,会抛错,但是可以通过其他两种方式进行访问:

**  1. request请求**

**  2. fileSystemManager文件管理器**

方法1简单,但是不可取,原因如下:

  1. 获得的文件信息,没有较好的保存方法,既不能存在store中,也不能存在local中,不仅是数据存储格式问题,更重要的同样会造成性能缺点,总不能解决了一个问题,又创造新的问题

  2. 由于1)描述的那样,如果不能存储文件,那么每次需要依赖这个文件时,就需要每次请求接口,这就造成了资源浪费

故此,基于以上两点,只能负重前行,选择较为麻烦和让人头疼的方案2(fileSystemManager文件管理器),虽然麻烦,但是却可以一劳永逸,并且可以抽离逻辑封装成一套方法,可以在以后复用。

【前期准备】

实现方案前,有几个注意事项:

**1.**首先要将存放云资源的oss或obs的域名配置在白名单中,这里就需要配置request合法域名和downloadFile合法域名。

2. 需要勾选"不校验合法域名...",不勾选的话,真机会遇到意想不到的问题。

**3.**将js文件转成json文件,如果没办法,就自行抽离js包,拆出一个json文件,因为微信fileSystemManager不支持读取js文件,js文件会变成string文本,但是支持json。

当然,如果你觉得可以使用JavaScript 解释器来破这个局,那么你又一次要碰壁了,微信官方对此做了限制,禁止eval5、estime、evil-eval等动态执行代码的js解释器。

原文地址: 关于禁止小程序JavaScript解释器使用规范要求

【方案思考】

fileSystemManager,它是getFileSystemManager返回的对象,给我们暴露出了多个方法,下面为部分截图

原文地址: FileSystemManager

为保证性能和可靠性,这里我们采用下面这种方案:

首次:下载 + 保存 + 读取,非首次:直接读取

流程图如下:

【方法封装】

我这里提供了两种封装写法:

  1. 链式写法,方便回调处理,不需要回调可以采用写法2
  2. 解耦式写法,降低了函数颗粒度,每个方法独立,更加灵活,可以单独使用某一个函数

千言万语,前面的铺垫已完成,直接上代码:

链式写法

解耦式写法

到此,就封装完成了,后面使用看具体场景,来选择链式、解耦式写法。

相关推荐
胡哈1 小时前
React Compiler:让开发者忘掉 memo 这件事
前端·react.js
xiyueyezibile1 小时前
“自迭代” Skill 的 team-pitfalls 的演进
前端·后端·ai编程
林恒smileZAZ1 小时前
`Array(100).map(() => 1)` 为什么全为空?
前端·javascript
小巧的砖头1 小时前
C#会重蹈覆辙吗?系列之2:反射及元数据的性能问题
开发语言·前端·c#
KaMeidebaby2 小时前
卡梅德生物技术快报|蛋白的叠氮基修饰:实操解析:核酸模板耦合蛋白的叠氮基修饰实现靶蛋白定点共价标记
前端·人工智能·物联网·算法·百度
濮水大叔2 小时前
在大型 Vue 项目中,如何有效管理复杂的状态?“散装版” vs “套装版”
前端·vue.js·typescript
玄星啊2 小时前
可修改:代码的生存底线
前端·ai编程
没落英雄3 小时前
3. DeepAgents 实战 - Memory Skills 与上下文工程
前端·人工智能·架构
Bigger3 小时前
对不起!我错怪你了,UnoCSS:一次和 AI 一起排查 DevTools 卡顿的经历
前端·css·人工智能
laowang3573 小时前
依赖故障时,日志体系需要埋哪些关键节点才能快速定位是安装失败、解析失败还是运行时缺失?
前端·javascript·vue.js·webpack·node.js