共计 2292 个字符，预计需要花费 6 分钟才能阅读完成。
一、问题背景
该我的项目提供友盟 +SDK 下载、相干辅助工具、集成 demo 等相干性能。
因原有 SDK 版本升级配置文件较简单，须要在 java 端通过多个文件查问整合失去前端界面勾选内容数据，且降级 SDK 均须要手动拉取 oss 文件到服务端本地缓存，导致保护老本较高，且工夫悠久无相干产品及开发文档阐明，因而在本次业务降级中重构改利用。
二、革新指标
● 新版体验：SDK_开发者核心 - 友盟 +
● 满足降级性能迭代包含新增多端整合性能等，以及视觉全新体验。
● java 端迁徙到 node，直连 oss 简化配置文件，节约”人工智能“的降级保护老本。
● 下载由后端转到 oss 直连下载，大大提高下载效率。
● SDK 端各原文件对立格局为 zip，文件存储与服务端拆散，进步后续维护性。
● 应用 SSR 服务端渲染，进步 SEO 优化。
三、下载计划
1. 原下载计划
由页面勾选，到后端进行文件的拷贝获取（原始文件已在后端缓存），创立对应目录，进行 merge 后压缩为最终 zip 文件，压缩实现后端间接流式返回 zip。下载速度迟缓。且缓存的原始文件需每次手动拉取。
毛病：后端下载速度较慢。服务端存储过多过大文件的合理性。
2. 新下载计划
将原始文件在编译部署时从 OSS 拉取到服务端，且放弃缓存文件门路层级与 OSS 统一。依据页面勾选，先查问 OSS 是否有缓存，若无缓存则在后端进行各个 SDK 压缩包的原始文件复制，复制到生成对应的各层级文件夹中，在各文件夹内解压、merge、整合后造成最终文件夹，将最终文件夹压缩为 zip 后上传到 OSS，失去 OSS 分享链接间接下载。
四、技术选型比照
1. 缓存原始文件形式比照
原始 SDK 存储在 OSS 且对立 zip 格局，全副原始文件压缩包大概 1.5G。依据页面操作拉取整合各 SDK 到一个文件中。
● 不举荐！直连 OSS 拉取对应 SDK。
OSS 提供将读取文件夹及内容 api，可将该文件夹内递归全副文件为二维列表，若要实现需把须要的原始各个 zip 解压在读取内容，解压后原始文件比 zip 格局大了约 3 倍，明显降低整体速度。
● 举荐！每次利用部署时，在 app.js 中拉取 OSS 原始文件到服务端缓存，当缓存实现后则在缓存复制，当无缓存时则 oss 拉取兜底。
2. 文件夹压缩 / 解压 zip 工具比照
因原始文件中有软链接，在 merge 中须要留神！
2.1、zlib 模块
● 劣势：
- 可对数据进行压缩和解压解决，减小数据体积，放慢传输速度。
- 对文件进行压缩 / 解压。
● 毛病：不可压缩 / 解压缩文件夹。
// 如 HTTP 申请头部设置 Accept-Encoding: gzip,deflate // 压缩 / 解压缩文件 let lib = require(‘zlib’) let gzip = zlib.createGzip() let rs = fs.createReadStream(‘./a.js’) let ws = fs.createWriteStream(‘./a.js.gz’) rs.pipe(gzip).pipe(ws)
2.2、node-stream-zip
● 劣势：zip 文件压缩 / 解压库，使用方便，可操作文件 / 文件夹。
● 毛病：不辨认解压后文件中的软链接，导致软链接打不开谬误。
// 解压 zip 文件 const StreamZip = require(‘node-stream-zip’); const zip = new StreamZip.async({file: ‘./common.zip’}); await zip.extract(null, ‘./’); await zip.close();
2.3、compressing
● 长处：可同步 / 异步压缩或解压文件 / 文件夹，相干文档简略清晰。
● 毛病：不辨认解压后文件中的软链接，导致软链接打不开谬误。
2.4、adm-zip
● 劣势：
- 将 zip 文件间接解压缩到磁盘或内存缓冲区中。
- 压缩文件并将它们以 .zip 格局或压缩缓冲区存储到磁盘。
- 从现有 .zip 更新 / 增加新文件 / 删除文件的内容。
● 毛病：只能针对以后 zip 包进行操作整顿，或者将文件逐个复制进去。但理论业务需要依据页面勾选将多个 SDK 压缩包解压生成新的对应目录层级后整合为一个压缩包。
2.5、archive
● 毛病：较长时间未更新，且解压后外部文件有软链会反复生成实在文件。
五、对于 SSR 服务端渲染
为更好优化 SEO，我的项目革新采纳 react ssr 服务端渲染，框架结构 Node + Um-Egg + React + AndD + yk-cli。
实用于偏动态的页面展现利用。
5.1 SSR 过程实现
5.2 initProps 与 state 留神点
● 页面首屏渲染只会渲染 Component.initProps 数据。
● 在 state 定义的数据首屏不会渲染，而在前端组件中渲染。
5.3 SSR 劣势
● 有利于 SEO
浏览器爬虫不会期待页面异步数据全副加载实现后再去抓取页面信息。而服务端渲染返回到前端页面是获取全副首屏数据并生成 html，即拜访路由时获取。
● 有利于首屏渲染
通过路由申请 node 中 html 全部内容，缩小加载 js 文件过程耗时，进步用户拜访页面工夫。
5.4 SSR 毛病
● 服务端压力增大
本来是客户端渲染，现改为 node 层解决生成 html，当并发量较大时占用服务端资源也更大。
● 保护老本绝对变大
如上文 5.2. 中介绍，
要分外留神首屏数据处理以及我的项目援用第三方库解决数据状况！
【文章作者：友盟 + 技术团队】
⭐️开发者核心重构将友盟 SDK 对立输入，蕴含 APP 端、网页端、小程序 / 小游戏、H5 各端，以及相干 SDK 下载和主动集成形式。
重构前后下载效率晋升数倍，使得用户体验感迅速晋升。同时友盟 + 也会更加器重相干文档的输入，从性能形容到技术实现以及用户体验等等维度，更好地帮忙用户疾速精确地解决问题。