技术与架构

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项目情况，推荐选择【方案三】，但是方案一、方案二可以在后续进行这方面的调研和准备工作，伺机而动。 ...

Zigbee协议 Zigbee协议是一种无线通信协议，专门设计用于低功耗、低数据速率、短距离的无线通信应用。它基于IEEE 802.15.4标准，并添加了网络和应用层的协议，用于构建低功耗无线传感器网络和物联网设备。 以下是Zigbee协议的主要特点和组成部分： 低功耗：Zigbee协议设计用于低功耗应用，节点可以进入睡眠状态以节省能量，并通过周期性唤醒来进行通信。 网络拓扑：Zigbee支持多种网络拓扑结构，包括星型、网状和混合结构。其中，协调器（Coordinator）负责网络的管理和协调，路由器（Router）用于中继数据，终端设备（End Device）作为最低级的节点。 自组织网络：Zigbee网络具有自组织和自愈能力，可动态调整网络拓扑结构，使网络具备容错性和鲁棒性。 低数据速率：Zigbee协议适用于低数据速率的应用，通常在10-100 kbps的范围内。 安全性：Zigbee协议提供多层安全机制，包括加密、认证和访问控制，以确保数据的安全性和网络的保密性。 应用层协议：Zigbee协议定义了一系列的应用层协议，用于特定的应用领域，如家庭自动化、智能能源管理、工业控制等。 Zigbee协议广泛应用于物联网领域，包括智能家居、智能建筑、工业自动化、农业监测等。它提供了一种低成本、低功耗、可靠且安全的无线通信解决方案。 Zigbee网关 Zigbee网关是连接Zigbee无线通信网络与其他网络（如以太网、Wi-Fi等）的设备。它充当一个桥梁，通过与Zigbee设备建立无线连接，将Zigbee设备的数据转发到其他网络，或将其他网络的命令传递给Zigbee设备。Zigbee网关通常具备数据转换和协议转换的功能，以适应不同网络之间的数据交互需求。 Zigbee组播 Zigbee组播是Zigbee网络中的一种通信方式，用于一对多的数据传输。在Zigbee网络中，多个设备可以加入同一个组播组，并通过组播组地址进行通信。当一个设备发送数据到组播组地址时，所有加入该组播组的设备都可以接收到该数据。Zigbee组播可以用于广播命令、控制多个设备或进行集群通信等场景。 Zigbee节点 Zigbee节点是指加入Zigbee无线通信网络的设备。每个Zigbee节点可以是传感器、执行器、控制器或其他类型的设备。Zigbee节点通过与Zigbee协调器通信，参与组网、数据传输和网络管理等操作。每个Zigbee节点具有唯一的64位或16位的节点地址，用于在Zigbee网络中进行标识和通信。 Zigbee设备 Zigbee设备是指采用Zigbee通信协议的终端设备，如智能灯泡、智能插座、传感器等。这些设备可以通过Zigbee协议进行通信和互联，构建起一个Zigbee网络。在Zigbee网络中，虽然Zigbee节点和Zigbee设备通常可以视为相同的概念，但有一些微妙的区别： 角色：Zigbee节点可以扮演不同的角色，例如协调器（Coordinator）、路由器（Router）和终端设备（End Device）。而Zigbee设备通常被视为终端设备，扮演终端设备角色。 能力：Zigbee节点通常具有更复杂的功能和能力，可以作为网络的核心，负责管理网络的拓扑结构、路由选择等。而Zigbee设备通常具有更简单的功能，执行特定的任务或提供特定的服务。 参与程度：Zigbee节点更强调对整个Zigbee网络的参与和管理，通常需要进行配置和设置。而Zigbee设备更强调作为终端设备的使用，通常不需要进行复杂的配置和管理。 需要注意的是，这些区别并不是严格的定义，而是对于Zigbee网络中的概念的一种常见理解。在实际应用中，节点和设备的概念可能会交叉使用，具体的区分可以根据具体的实际情况和需求来确定。

前言 之前也算研究过”高效学习“这方面的书籍和课程，总的来说，无非就是意识和实践，意识是指明白以教代学是什么，实际上就是以终为始——先假设你想得到的结果，然后再倒逼我们从源头去规划应该怎么去做这个事情。如果你打算教别人东西，为了怕被别人问住，你不得不把相关知识都弄明白了，这无形之中，就给你施加了学习的压力，有处于你全面掌握这个知识点。实践，也就是毛泽东《实践论》里的观点，实践与理论反复验证，只有动手了人才会更加专注，也才会真正感受得到所要学的东西到底是什么？如果只停留在书籍上面，因为都是一些理论的东西，注意力很容易分散，学习效果大大折扣。 比如，如果要学习Flutter开发，我不会一字不漏地看完官网文档才动手敲代码，我会立马开始敲代码，是的，啥都不知道，完全凭感觉去做这个事情，然后呢，如果要实现一个按钮，我就去看按钮的部分，动手实现了，如果要实现一个弹窗，我就去看弹窗的部分，把弹窗实现了，一步一步，慢慢先把用到的东西学起来，在这个过程中，你一定是带着问题去查看文档的，这无形之中，就会加深了印象。 这个方法其实也是可以用在学校的，我就先做练习本或者试卷，根本就没学过这个知识，凭感觉去做，不知道就记下来，猜测应该是什么意思，然后再去找答案，再去收集，总结，再去做题。 我们通常都会说，人心不足蛇吞象，想什么都学，结果什么都学不会。这个道理没错，但是，人这一生本来就很短暂，不可能看完古今中外所有的书，学到所有的知识，我只打算享受过程，哪怕最后都是半桶水也没有关系，我希望自己能成为一个有点知识的人，一方面我无法忍受自身知识的匮乏和认知的浅薄；另一个方面，我想学很多很多东西，将来可以给村里小朋友教点东西也行，或者其他地方的，很小的时候，就已经想过，将来要在二楼弄个书房，全都堆满书，然后可以借给很多人看，再有个房间，学习乐器什么的。乡下教育，一直以来的问题，其实不一定都是经济，经济当然是很大的原因，但其实更多的是缺少引路人，引路人一般都是父母，父母的知识面，眼界，信息差其实很大程度决定了小朋友的命运，他们不知道外面世界是什么样子的，每个人看到的世界有好坏之分，但是世界自身没有好坏之分，你看到什么是你个人主观投射而成，这就是引路人的价值所在，怎么去给小朋友搭建一个符合他们自身个性的世界，让他们看得到，摸得着，至于他们怎么选择，就完全看他们自己了，但是现在的情况是，很多大人没有什么知识面和眼界，那么搭建能力也就无从说起了。 希望能以身践行，学习每一个技能，从实践总结成理论，将理论整理为教程。 怎么学 怎么减肥？ 怎么增肌？ 怎么跑步？ 怎么游泳？ 怎么早睡早起？ 怎么学Vue开发？ 怎么学Flutter开发？ 怎么学Android开发？ 怎么学Nodejs开发？ 怎么学Java开发？ 怎么学ToB产品设计 怎么学市场营销？ 怎么学项目管理？ 怎么学团队管理？ 怎么徒步？ 怎么学吉他？ 怎么学钢琴？ 怎么学英语？ 怎么学普通话？ 怎么学习画画？ 怎么做饭？ 怎么护肤？ 怎么穿搭？ 怎么阅读？ 怎么写读书笔记？ 怎么写电影日志？ 怎么写诗词？ 怎么创作歌词？ 怎么写小说？ 怎么写日记？ 怎么摄影？ 怎么创业？

2025 年 Web 响应式开发解决方案（基于 Vue3 生态） 随着移动设备碎片化加剧和跨端需求增长，2025 年的响应式开发已从单纯的 “适配多屏幕” 升级为 “全场景体验一致性”。结合当前技术演进，针对 PC、平板、手机多端适配需求，推荐以下增强方案： 一、核心技术栈升级 1. 基础框架：Vue 3 + Vite 6 + TypeScript 5 Vite 6 优势：新增的responsive-plugin可自动识别设备类型并注入环境变量，配合import.meta.env.DEVICE_TYPE在编译时优化条件渲染 TypeScript 5：借助const type特性强化响应式断点类型定义，避免运行时类型错误 // 设备类型类型定义示例 type DeviceType = 'mobile' | 'tablet' | 'desktop' | 'large-screen' const deviceType: DeviceType = import.meta.env.DEVICE_TYPE as DeviceType 2. 响应式引擎：Tailwind CSS 4 + Bootstrap 6 混合方案 Tailwind CSS 4：通过@container查询实现组件级响应式，比传统@media更精准控制元素布局 Bootstrap 6：新增responsive-propsAPI，支持在组件上直接声明多端样式 <!-- Bootstrap 6 响应式属性示例 --> <button class="btn" :responsive="{ mobile: 'btn-sm w-full', tablet: 'btn-md w-1/2', desktop: 'btn-lg w-auto' }" > 多端适配按钮 </button> 3. 跨端状态管理：Pinia + 设备传感器 API 利用Pinia存储设备状态（如屏幕方向、分辨率），结合ScreenOrientationAPI 实现动态适配 // 设备状态Store示例 import { defineStore } from 'pinia' export const useDeviceStore = defineStore('device', { state: () => ({ orientation: ScreenOrientation?.type || 'portrait-primary', breakpoint: 'mobile' }), actions: { init() { window.addEventListener('orientationchange', () => { this.orientation = ScreenOrientation.type }) } } }) 二、组件层优化方案 1. 自适应布局组件库：PrimeVue 4 + VueUse PrimeVue 4：所有组件默认支持responsive属性，内置 30 + 种设备预设 ...