1. 背景 公司有部门使用VuePress 1.0搭建平台的帮助文档，前期文档不是很多，所以没有暴露出特别明显的问题。但随着文档的逐步迭代和内容的增多，出现了大量的并发请求，总共有218个请求，导致服务器带宽耗尽、响应速度下降，进而影响了文档的使用。 2. 问题分析 VuePress 1.0是基于Vue 2和webpack实现的，其模块化方式使用的是CommonJS。这意味着，当项目打包部署在服务器并进行访问时，需要将源码全部加载完成后才能进行渲染，即同步加载。随着项目持续迭代，内容增多，性能问题逐渐显现。 3. 解决方案 考虑到向服务器发起了200多个请求，但查看那些.js文件，整个js文件夹大小才10.3MB，是否可以将10.3MB分为10个.js文件，减少请求至10次呢？ 3.1 方案一：替换成showDoc 使用showDoc在线文档系统，相比vuepress基于vue.js的静态站点生成器，除了操作便利，对于解决并发请求200次这个问题，还是有帮助的，毕竟showDoc初始化的时候，是从服务器获取文档目录，再通过文档ID，去请求文档详情，通常来说，不会有那么多文档目录，不太可能出现并发请求200次这个问题，只是将vuepress迁移至showDoc，花费的成本很高，文档格式需要调整，图片需要上传，想想这个工作量就头大，再者，作为平台的帮助文档，本身带有宣传的作用，很难醒目地在showDoc中体现平台的公司名和Logo，所以这个方案不推荐。 3.2 方案二：研究webpack如何合并打包 如果请求过多是因为文件太分散导致的，那么，能够在当前基础上，也就是webpack里，找到，当打包时，将各个文件合并，减少请求次数呢？ VuePress 1.0 支持通过 webpack-chain 链式操作来修改内部的 webpack 配置，如下所示： module.exports = { chainWebpack (config, isServer) { // config 是一个 ChainableConfig 的实例 } } 那在 webpack 中，如何对打包的体积、文件等进行处理呢？在 webpack 官方文档中，有推荐使用 SplitChunksPlugin 插件，是为了代码分割，减少包的体积，然后优化加载效率，感觉和自己的初衷背道而驰，最终没达到自己想要的效果。还有就是研究了下 ModuleConcatenationPlugin 插件，其作用是将所有模块的作用域“提升”或合并到一个闭包中，从而使得代码在浏览器中执行速度更快。但是因为要在使用 webpack-chain 去调研 webpack 的配置，尝试使用后也没达到预期，加上再花精力投入到 VuePress 1.0 和 webpack-chain 感觉有点不值。所以，就再想想其他方案。 3.3 方案三：替换成VitePress【推荐】 说到减少并发请求次数，实际上，Vite就在做这样的工作。Vite采用的JavaScript模块化方式是ESM（ECMAScript Modules）。与CommonJS相比，ESM支持按需加载，并且是异步执行的，不会阻塞浏览器的其他事件处理。这意味着在首次加载时，我们无需加载所有资源，仅需加载首页所需的资源即可。这样就能减少了并发请求次数，解决当前遇到的问题。 而VitePress，正是基于Vue 3和Vite构建的。 5. 方案验证 以下是两个文档框架的对比，内容基本为空，可忽略不计。可以看到VuePress 1.0初始化请求的就有26个请求，大部分都是.js文件，而VitePress 1.0只有9个请求，.js文件的请求才4个。 5.1 VuePress 1.0 5.2 VitePress 1.0 ...

1. 背景 由于当前部门使用Flutter框架进行开发，支持生成Android和iOS两端的App应用。现在鸿蒙系统计划完全去掉AOSP核心代码，将无法支持Android应用。因此，鸿蒙手机接下来只能安装鸿蒙App应用。鉴于此，从长远来看，部门App后续也需要支持鸿蒙系统。那么，如何从成本和可维护性方面考虑后续的开发模式？可以兼顾到Android、iOS和鸿蒙系统，同时老项目又能支持在鸿蒙手机上运行？重新开发鸿蒙版本？显然不切实际。 2. 解决方案 2.1 方案一：Flutter for OpenHarmony https://gitee.com/openharmony-sig/flutter_flutter 鸿蒙官方计划对Flutter进行反向适配，即基于Flutter SDK的稳定版本进行拓展，使其能够在鸿蒙DevEco Studio上构建和生成鸿蒙App应用。 2.1.1 优势 官方支持。 Flutter源码直接可用，只需简单适配，成本低。 2.1.2 劣势 因使用Flutter版本为3.7，与当前最新3.24版本相差过大，加上Flutter迭代特别频繁，很多开发方式、组件都在不断变化，后续要使用新的Flutter特性，可能不会那么容易。 Flutter正在考虑使用自研的图形渲染引擎Impeller替换掉Skia，这无疑又加大了更多的变数。最后，可能会变成多个分支进行维护。 部门已有项目，使用的Flutter版本都是最新的，可能是没办法兼容的。除非新项目统一使用这个3.7版本的Flutter SDK来开发。 2.2 方案二：ArkUI-X 跨平台框架 https://gitee.com/arkui-x ArkUI-X扩展ArkUI开发框架到多个OS平台，让开发者基于一套主代码，就可以构建支持多平台的精美、高性能应用。目前支持OpenHarmony、HarmonyOS、Android、iOS，后续会逐步增加更多平台支持，可以简单理解为鸿蒙版的Flutter。 2.2.1 优势 官方支持。 鸿蒙版的Flutter。 2.2.2 劣势 有学习成本，虽然鸿蒙和Flutter是有一些共性的，学习成本相比之下不会太高，但是毕竟是新的开发模式，各种各样的知识和问题都是需要积累和时间的。 有开发成本，已有的Flutter项目需要重新开发。 生态各方面还处于初期，还未成熟和完善，也不适合立马接入商业项目应用。 2.3 方案三：Flutter Web【推荐】 http://192.168.24.10/appweb/index.html 通过Flutter Web可以部署在网页上，然后在手机浏览器上使用，并设置为全屏，则可以达到和App一样的使用效果。 2.3.1 优势 无开发成本。 使用时无需安装。 与系统无关，只要有浏览器就可使用。 2.3.2 劣势 需要说服使用鸿蒙手机的客户接受这种使用方式。 各手机浏览器需要支持全屏功能，不过可以代码实现，检测到当前是手机访问，则自动全屏即可。 考虑到毕竟是在网页上使用，体验可能不如App，但是现在手机性能、网络访问各方面发展都很不错，这方面应该不会特别明显。 不联网的项目怎么办？可以基于鸿蒙开发一个基于WebView的简单手机浏览器，并加载本地Flutter Web部署的包，打开这个应用就可访问。 额外多一些适配的工作，但不会很多，Flutter项目开发，需同时考虑兼容Web端。 2.4 方案四：Flutter 官方支持 HarmonyOS Flutter官方暂没有支持HarmonyOS的计划，但是这个问答 《HarmonyOS Support》 毕竟是几年前了，以后的发展并不好说，如果鸿蒙系统大规模发展起来，发展到可以倒逼Flutter官方支持也不是没有可能。 3. 结论 到底选哪个方案，不是绝对的，只能是阶段性的，因为很多方案都还存在变数。考虑到部门的App项目情况，推荐选择【方案三】，但是方案一、方案二可以在后续进行这方面的调研和准备工作，伺机而动。 ...

饮食 不记得了 无氧 无 有氧 总结 计划再好，不执行等于零。

饮食 早餐：炒河粉、排骨粥、鸡蛋 午餐：农家小炒肉、米饭、炖汤 晚餐：两包汤达人泡面、生椰拿铁+冰块、2鸡蛋、火腿肠、无糖可乐、椰奶饮料 无氧 无 有氧 总结 运动计划重启后第四天，继续加油。 本来打算晚上0点前睡觉，结果还是没达成。 早点去健身房，吃掉最大的那只青蛙。

饮食 早餐：无 午餐：大盘鸡+面 晚餐：新疆羊肉串、无糖可乐、百香多益菌、珍珠奶茶 无氧 无 有氧 总结 运动计划重启后第三天，继续加油。 什么都不用想，先保持习惯，比如一个小时看完一部电影，也是很不错的。