一、问题背景
该我的项目提供友盟+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下载和主动集成形式。
重构前后下载效率晋升数倍，使得用户体验感迅速晋升。同时友盟+也会更加器重相干文档的输入，从性能形容到技术实现以及用户体验等等维度，更好地帮忙用户疾速精确地解决问题。