风华正茂李师师本文介绍了资源包的概念及使用场景，同时对资源包的几种使用方案进行对比。通过本文，大家可以快速掌握资源包的使用方法，解决单一配置满足多场景、多样式的问题。

　　随着官网项目的业务深入发展，单纯的配置已经满足不了各种复杂场景的需求了，靠适配各种场景的需求只会让配置后台越来越复杂。而且有些特殊场景是需要在特殊时间触发，并且需要运营人员做到快速配置，无需发版，配置正确的地步。资源包的出现就是为了解决上述场景的。它能配置一次，无需发版，支持预览，并且适合所有特殊场景的样式。这种能力已经在我们官网运用的很好了。

　　包含网页、JS、CSS 和图片视频等静态资源的文件，并具有一定目录规则的压缩包，可以通过后台配置，快速上线更换，无需版本发布。下图所展示的是一个Demo的资源包目录。

　　最开始我们开发完一个功能，即使设计时考虑的比较通用，但是在一些特殊节日的时候总有样式上面的偏差，功能无法满足，紧急情况只能发版解决。所以出现了资源包的解决方案，这种方案只需要前端按照一定的规则开发一个完整的资源包，在后端进行资源包的解析。

　　前端能立马看到整个页面样式，做到配置一次，快速上线的目的。这种方式对大部分场景比较适用，但是对于需要动态获取数据、用户分流的页面不太适用，资源包大多都是静态页面。所以在使用资源包的前提下需要自己去评估下业务场景。

　　图一和图二是两种不同的资源包，图一是X50 Pro+的360度模型，图二是X50 Pro+的静态宣传页面，两种不同的资源包达到了给用户展示不同的效果目的，其实在后台就一个配置入口。

　　不同的资源包有不同的规则目录，解析规则也不一样，所以后台有统一的资源包解析适配器，对应到不同的解析方法，然后经过一系列的解析操作（主要是JS、CSS、图片、视频、JSon文件官网规则适配逻辑和相对路径的替换）之后把主页面内容入库和入缓存。最后把上传的资源包解压后上传到

　　静态资源服务器上面。资源压缩包上传到静态服务器我们这边尝试了三种方案，分别如下：

　　本地解压是在本机器完成资源包的解压工作，把资源包所有文件解压到本机的规定的目录，然后解析压缩完的主网页，替换网页中所有的引用静态资源的路径。

　　本地解压主要是把制作好的静态资源zip包上传上去，规定好解压路径，通过Zip的工具类对zip包进行解压，解压好的文件上传到本地，本地解析主要是对解压好的文件中主文件比如index.html进行解析，解析的主要工作是按照一定规则通过jsoup去操作HTML 文件，筛选一些我们需要的样式、页面并且替换静态资源的路径，改为上传到你本地路径。前端直接获取服务端返回的数据进行渲染成你资源包的页面。

　　本地解压如同第一种方案，之后会把解压后的所有文件上传到OSS服务器上面。同样去解析主文件index.html。后续步骤类似第一种方案。

　　如何确保资源包的整体性？思路：上传一个完成的资源包到云服务器，然后在线解压？

　　静态资源包会直接上传到文件服务系统，上传的这个动作是一个事件，触发了绑定该事件的函数进行在线解压，然后从文件系统拉取解压后的文件进行以上方案的解析。

　　每次请求都会触发一个解压云函数的事件驱动，解压函数会启动一个实例来执行脚本，完成本次请求的解压工作，具体的解压脚本代码本文暂不做阐述。

　　当用户上传zip包到规定的bucket目录下的时候会触发云函数，云函数会启动一个实例来执行脚本，帮用户完成压缩包的解压。

　　资源包这种方案在我们团队已经使用非常的成熟了，解决适配各种不同的样式配置，包括官网首页、官网产品详情页等不同的页面。现在系统运行比较稳定，我们这套解决方案也是比较成熟的。

　　运营同学只要在一个入口上传不同类型的资源包，能完成各种样式、各种规则的页面配置，真正达到单一配置，多套样式的功能的实现。

　　这套机制不仅提升了我们运营同学的50%的运营效率，更为我们解决了大促、节假日特殊样式的配置场景。

　　上述方案当然不是最优的方案，是这种场景下的的一种常用的解决方案，当然有更好的解决方案。未来我们考虑把常用配置项做成元组件形式，然后通过元组件之间的任意组合形成我们最终配置的页面。

　　运营只需要拖拽其中的元组件，自己想怎么组合就怎么组合，节日的组合成为一份页面，大促的组合也可以成为一份页面，很自由。这种随意组合的方式你可以称之为lowcode模式，这也是我们未来想做的东西。

　　本文讨论了使用资源包的大体思路以及一些关键技术点的解决方案，各种不同方案对比。目前官网正在应用第三种方案，但是需要具备Serverless这种能力，我们在探索期间寻求了运维同学的帮助，编写在线解压函数的脚本远远没有上述来的简单。由于本篇限制并没有对Serverless的技术进行详细介绍，有兴趣的同学可以深入了解这方面的知识。