（所有项目的详细介绍，都可以在我公众号搜到相应的介绍文章）

纯AI底层原理项目

文章介绍链接：
https://mp.weixin.qq.com/s/cATjUcO2uoi8Knim6ZKb5w

通过此项目，一共可以衍生出三个子项目，含金量非常之高。大家可以看看简历书写，是否感兴趣

完整项目简历

子项目---MCP server部分

子项目---整体mcp开发

子项目---a2a开发

操作系统项目

在应届生校招面试中，对基础知识的拷打，系统知识部分占据了极其重要的一环。（校招面试基础知识，一般就是拷打语言、操作系统、计算机网络、还有自己写的额外学的东西）

那这个时候，如果操作系统学习的好，学的深入，远超同龄人，那面试基本已经成功三分之一了。

那怎么说明操作系统算学习的好呢，无非就是深入底层，深入内核。 学习内核源码，尝试改编。

针对这，星球里目前有两个项目：

协程框架

一个是协程框架项目（底层语言到寄存器，操作系统hook机制，内核模块编写）

同时有详细的学习路线、学习资料、学习代码、简历书写，以及面经

如下图：

Linux性能监控项目

（和星球同学一起整理的分享给大家）

目前大家都在强调自研，自研操作系统。尤其新能源，智能座舱都在自研操作系统。

那怎么自研的，从0到1，肯定是首先要借鉴下目前好的操作系统（安卓），以及对底层的模块熟悉，会编写内核模块。

并且既然是监控项目了，肯定要对底层的一些指标进行监控，监控内核。了解要学习的中间件

以及对一些性能怎么进行测试等等。通过此项目，将会让你对操作系统的掌握，更上一层楼

同时有详细的学习路线、学习资料、学习代码、简历书写，以及面经

如下图：

计算机网络项目

作为另一个面试中被拷打的重点。大多数人对于网络的学习都是停留在传输层、应用层上。你学，他学，大家都学了，那怎么突出你掌握的深度，实现对其他人的降维打击呢。

那就往深的学，往底层的学。是不是可以学学底层协议呢，学学底层内核网络协议栈呢。

通过这个学习，你会了解内核中对协议的一些实现、以及用户态怎么与内核网络协议栈进行交互，以及怎么监控内核网络协议栈。对网络部分实现对同龄人甚至面试官的降维打击。

并且此项目也融合了AI的东西，引起了RAG技术，进行了多种RAG的实现方式。与AI结合，符合潮流

同时有详细的学习路线、学习资料、学习代码、简历书写，以及面经

如下图：

项目介绍文章：

项目介绍视频

https://www.bilibili.com/video/BV1jbx2zgE7h/?spm_id_from=333....

后端项目（AI智能云存储）

很多学生学cpp，但是又要找后端岗位、服务端开发的工作。

这个时候就需要你有crud经验，作为一个cpp选手（cpp主要就是搞底层、 嵌入式的）。证明自己有后端经验，那最好的证明就是证明自己有个后端的项目

并且很多人学cpp，也是因为时间来不及，想速成。c++最大的优势就是可以学习较少的东西，就可以做出一份很不错的简历出来，投入到找工作行列中。（用少量的时间就可以达到找工作的要求）

但是简历项目必不可少，这个时候有个简单同时也有含金量的项目至关重要。

那就可以做个后端项目，比较简单。也有含金量，之前全程辅导23/24/25届的学生，单纯用这一个项目，并且用的还是基础版本（目前进行了一次迭代，新增了使用docker、k8s一键部署，以及也增加了AI的东西），就可以找到满意的工作。

同时有详细的学习路线、学习资料、学习代码、简历书写，以及面经

如下图：

游戏项目

（和星球同学一起整理的分享给大家）

很多人学cpp可能是为了想找游戏相关的工作，但是苦于没有合适的项目，这里 给大家介绍两个项目。

一个是框架类的项目

一个是落地的项目

分布式ECS游戏后端框架

实现了一个游戏开发框架，一个黑盒子，底层框架，供游戏开发者使用。复用了很多功能

具体内容可以看下面的图片：

游戏姿势识别项目

从游戏开发应用、中间框架层、底层硬件封装、sdk调用，一条龙自主实现。

主打对整体的一个流通，可通各个层级岗位，万金油

如下图：

一站式编程平台项目

此项目主要用于为大家编程学习，提供编程练习环境。带大家从小白一步一步蜕变成编程大牛，而不是一个只会背的八股选手

qt项目

正在研发中，争取年前上线

其他收集的开源免费的基础项目

免费开源给大家，不要被一些人忽悠，拿着这些开源项目说自研，忽悠大家，忽悠钱就算了。还忽哟大家把线程池、内存池当作项目，耽误大家前程。

等等其他项目在开发中

知识星球介绍（公认的cpp c++学习地）

星球名字：奔跑中的cpp / c++

专注cpp/c++相关求职领域的辅导

加入星球福利，后续如果有其他活动、服务，不收费，不收费，可以合理赚钱就收取下星球费用，但是不割韭菜，保持初心

感兴趣的微信扫下面的码，然后下载知识星球app登录即可

（1）高质量的项目合集

同时如果项目，遇到任何困惑也会第一时间进行解答的

（2）高质量精确性八股资料

（3）详细的学习路线

（4）活跃的学习氛围，星球打卡不只是一个形式，而是每天观看，针对同学们的学习情况提出合理化的建议，同时也有高质量的星球微信内部群

（5）星球提问简历修改，提供意见的同时，还会给安排一对一腾讯会议辅导

（6）星球同学offer情况，以及对应学习情况，给大家提供参考

（7）全网最全cpp相关面经整理

（8）编程实战能力提升平台（大家都可以使用的，免费的）

访问网址 cppagancoding.top

星球同学的评价

（9）每周也会进行直播答疑，同时有时也会给星球内部同学开一些知识、路线分享会。

具体可以看B站放的视频，up名字：cpp辅导的阿甘

（10）奖励金激励，会根据大家打卡学习/ 面经打卡整理情况，每个月每个季度发放奖励金。有的人陆陆续续已经获得了数千月的奖励金，是加入星球费用的数十倍了

等等，可能还有一些其他服务，目前没想起来的，以及后续也会增加的服务

本文由mdnice多平台发布

【Unity Shader Graph 使用与特效实现】专栏-直达

Billboard节点是UnityShaderGraph中一个功能强大的顶点变换工具，专门用于实现面向相机的渲染效果。在实时渲染中，Billboard技术被广泛应用于粒子系统、植被渲染、UI元素和特效制作等领域，能够确保特定物体始终面向摄像机，从而提供最佳的视觉效果。

Billboard技术概述

Billboard技术源于计算机图形学中的精灵渲染概念，其核心思想是通过动态调整物体的朝向，使其始终面对观察者。这种技术在游戏开发中具有重要价值：

• 在粒子系统中用于渲染烟雾、火焰、魔法效果等动态元素
• 在开放世界游戏中用于优化树木和植被的渲染性能
• 在UI系统中确保界面元素始终以正确角度显示
• 在特效制作中创建各种视觉欺骗效果

UnityShaderGraph中的Billboard节点封装了这一复杂技术，让开发者能够通过可视化方式轻松实现面向相机的渲染效果，无需编写复杂的着色器代码。

节点端口详解

Billboard节点包含多个输入和输出端口，每个端口都有特定的功能和用途。

输入端口

Position OS端口接收物体空间的顶点位置数据。这个端口是Billboard变换的基础，提供了需要进行旋转的原始顶点坐标信息。在实际应用中，这个端口通常直接连接到顶点着色器的位置输出，或者与其他位置变换节点相连。

Normal OS端口处理物体空间的法线向量。法线数据对于光照计算至关重要，Billboard节点会对法线进行相应的旋转，确保光照效果在物体旋转后仍然正确。如果忽略法线变换，可能会导致光照异常或材质表现不正确。

Tangent OS端口管理物体空间的切线向量。切线主要用于法线贴图和某些高级着色效果，Billboard节点会同步旋转切线数据，保持与顶点和法线的一致性。在需要复杂材质表现的场景中，正确的切线变换尤为重要。

输出端口

Position输出端口提供旋转后的物体空间顶点位置。这是Billboard节点的核心输出，包含了经过相机对齐变换后的顶点坐标。这个输出通常直接连接到主节点的顶点位置输入，完成最终的顶点变换。

Normal输出端口返回旋转后的物体空间法线向量。变换后的法线确保了光照计算与物体新朝向的一致性，对于保持材质视觉真实性至关重要。

Tangent输出端口提供旋转后的物体空间切线向量。这个输出确保了法线贴图和其他依赖切线空间的着色效果能够正确工作。

控件参数解析

Billboard Mode是Billboard节点最重要的控制参数，决定了物体的对齐方式和旋转行为。

All Axis模式

All Axis模式实现完全相机对齐，物体的所有坐标轴都会与相机坐标系对齐。在这种模式下，物体会完全面向相机，类似于始终正对观察者的广告牌。

这种模式的特点包括：

• 物体完全面向相机，保持正面朝向观察者
• 所有轴向都会根据相机方向进行旋转
• 适用于需要完全正面展示的效果，如粒子特效、公告板文字等
• 在VR和AR应用中特别有用，确保UI元素始终面向用户

All Axis模式的一个典型应用场景是粒子系统中的精灵渲染。当相机移动时，每个粒子都会自动调整方向，始终以最佳角度面向观察者，从而保证视觉效果的一致性。

Around Y Axis模式

Around Y Axis模式提供受限的对齐方式，物体仅围绕Y轴旋转，保持Y轴方向不变。这种模式在保持物体部分方向稳定的同时，实现基本的面向相机效果。

这种模式的特点包括：

• 物体围绕世界空间或物体空间的Y轴旋转
• X轴和Z轴与相机对齐，但Y轴保持原有方向
• 适用于树木、路灯等需要保持垂直方向的物体
• 在开放世界游戏中广泛用于植被渲染优化

Around Y Axis模式在大型场景的性能优化中特别有用。通过将3D树木替换为Billboard四边形，可以大幅减少渲染负载，同时通过限制Y轴旋转保持视觉上的自然感。

技术实现原理

理解Billboard节点的内部工作原理有助于更好地使用和调试相关效果。

顶点变换矩阵

Billboard节点的核心是基于视图矩阵的逆向变换。本质上，它计算相机的旋转矩阵，然后将这个旋转应用于输入的顶点数据。在All Axis模式下，节点会提取相机的完整旋转矩阵；而在Around Y Axis模式下，则会提取并修改旋转矩阵，将Y轴分量重置为单位矩阵的Y轴。

数学上，这个过程可以表示为：

旋转矩阵 = 提取相机旋转矩阵
如果模式为Around Y Axis：
    旋转矩阵[1] = [0, 1, 0] // 重置Y轴
变换后位置 = 旋转矩阵 × 原始位置

法线和切线变换

法线和切线的变换遵循与位置数据相同的旋转逻辑，但由于它们是方向向量而非位置点，变换时不考虑平移分量。正确的法线和切线变换确保了光照和材质效果在Billboard变换后仍然保持视觉一致性。

法线变换需要特别注意，由于法线是协变向量，其变换矩阵通常为顶点变换矩阵的逆转置矩阵。但在Billboard这种纯旋转的情况下，由于旋转矩阵是正交矩阵，逆转置矩阵等于原矩阵，因此可以直接使用相同的旋转矩阵。

实际应用案例

Billboard节点在游戏开发中有多种实际应用，以下是一些典型场景。

粒子系统效果

在粒子系统中，Billboard技术是创建各种视觉特效的基础。

火焰和烟雾效果可以通过Billboard四边形配合透明度渐变纹理实现。每个粒子都是一个面向相机的四边形，使用噪声纹理和颜色渐变创建动态的火焰和烟雾外观。通过All Axis模式确保无论相机如何移动，效果都能正确显示。

魔法和能量场效果利用Billboard节点创建环绕角色的魔法光环或能量屏障。结合扭曲效果和发光着色器，可以制作出视觉上吸引人的魔法特效。Billboard确保这些效果始终面向玩家，提供最佳的视觉体验。

环境装饰优化

在大型开放世界游戏中，Billboard技术是性能优化的重要手段。

树木和植被渲染使用Around Y Axis模式的Billboard技术，将复杂的3D树木模型替换为简单的四边形，大幅减少三角形数量。当玩家距离较远时，使用Billboard树木；当玩家靠近时，逐渐淡入完整的3D模型。这种LOD（层次细节）策略在保持视觉质量的同时显著提升性能。

远处山脉和云层可以通过Billboard技术创建。使用多层Billboard平面配合透明度混合，可以模拟出具有深度感的远景效果。这种方法比使用完整3D模型更加高效，特别适合移动平台或性能受限的场景。

UI和交互元素

在用户界面和交互设计中，Billboard技术确保重要信息始终可见。

世界空间UI元素使用Billboard技术创建始终面向玩家的对话框、任务提示或交互图标。这在3D游戏中特别有用，玩家可以从任何角度都能清晰看到UI内容。

AR和VR应用中的界面元素通过Billboard技术确保虚拟界面始终面向用户，提供自然的交互体验。无论是信息面板、控制菜单还是虚拟标签，Billboard都能保证最佳的可读性和可用性。

性能优化考虑

使用Billboard节点时需要考虑性能影响，特别是在大量使用的情况下。

渲染性能

Billboard技术通过减少几何复杂度来提升性能，但顶点着色器的计算负载会增加。在移动设备或低端硬件上，需要平衡视觉质量和性能消耗。

优化策略包括：

• 控制Billboard物体的数量，避免在同一帧中渲染过多Billboard
• 使用LOD系统，根据距离动态切换Billboard和完整模型
• 合并多个Billboard物体，减少绘制调用
• 在性能敏感的区域使用更简单的Billboard效果

内存和带宽

Billboard通常使用简单的四边形几何体，这有助于减少内存占用和顶点数据传输带宽。但在使用高质量纹理时，需要注意纹理内存的消耗。

优化建议：

• 使用纹理图集将多个Billboard纹理合并为一张大图
• 根据距离使用不同分辨率的纹理
• 压缩纹理格式以减少内存占用
• 合理管理纹理的加载和卸载，避免内存峰值

常见问题与解决方案

在使用Billboard节点时可能会遇到一些常见问题，以下是相应的解决方案。

光照异常

问题描述：Billboard物体上的光照显示不正确，高光或阴影位置异常。

解决方案：

• 确保正确连接Normal OS端口，并提供准确的法线数据
• 检查Billboard模式是否适合场景需求
• 在复杂光照环境下，考虑使用自定义光照模型或简化光照计算
• 验证法线贴图是否正确应用，确保切线数据正确变换

深度排序问题

问题描述：Billboard物体与其他物体的深度排序错误，出现穿透或遮挡异常。

解决方案：

• 调整渲染队列顺序，确保Billboard物体在正确的渲染阶段绘制
• 使用Alpha混合时，注意透明物体的渲染顺序问题
• 在粒子系统中使用软粒子技术缓解深度冲突
• 考虑使用自定义深度偏移解决特定的排序问题

运动模糊和抗锯齿

问题描述：快速移动的Billboard物体可能出现运动模糊异常或抗锯齿效果不佳。

解决方案：

• 在运动剧烈的Billboard物体上禁用运动模糊，或使用自定义运动向量
• 调整抗锯齿设置，确保Billboard边缘平滑
• 对于特别敏感的视觉效果，考虑使用更高分辨率的纹理
• 在后期处理中应用特定的抗锯齿技术，如TAA（时间性抗锯齿）

高级应用技巧

掌握了Billboard节点的基本用法后，可以探索一些高级应用技巧。

自定义Billboard效果

通过组合Billboard节点与其他ShaderGraph节点，可以创建独特的视觉效果。

倾斜Billboard效果通过修改旋转矩阵，使Billboard物体以特定角度倾斜，而不是完全面向相机。这种效果可以用于创建更有动态感的粒子特效或风格化的视觉元素。

动态朝向Billboard根据游戏逻辑或玩家输入动态调整Billboard的朝向，而不是始终面向主相机。这种技术可以用于创建始终面向特定目标的效果，如追踪导弹的尾焰或指向任务目标的导航标记。

与其他系统的集成

Billboard节点可以与Unity的其他系统集成，创建更复杂的效果。

与VFX Graph集成，在视觉特效图中使用Billboard技术创建高性能的粒子效果。VFX Graph提供了更强大的粒子系统功能，结合Billboard可以实现电影级的视觉效果。

与Shader Graph高级特性结合，如曲面细分、几何着色器或光线追踪，创建更复杂的Billboard效果。这些高级技术可以增强Billboard的视觉质量，提供更逼真或更风格化的外观。

【Unity Shader Graph 使用与特效实现】专栏-直达
（欢迎

点赞留言

探讨，更多人加入进来能更加完善这个探索的过程，🙏）

摘要

这两年，跨屏协作在鸿蒙生态里出现得越来越频繁。
从最早的文件互传、多屏办公，到现在的教育课堂、车机联动，设备之间已经不再是“各干各的”。

在游戏领域，这个变化更明显：

• 一块屏幕已经不够玩
• 玩家希望多设备一起参与
• 大屏负责画面，小屏负责操作

但很多开发者一提“跨屏游戏”，第一反应还是投屏、远程控制、镜像显示。
实际上，鸿蒙给的不是投屏方案，而是一整套分布式游戏协作能力。

这篇文章就从游戏开发者的真实视角，讲清楚鸿蒙是如何把多设备变成“一个游戏系统”的。

引言

在传统系统里，如果你想做多设备协作游戏，通常意味着：

• 自己写网络协议
• 自己做设备发现
• 自己处理数据一致性
• 自己兜底各种异常情况

而在 HarmonyOS 里，这些事情被系统层直接兜住了：

• 设备发现靠软总线
• 状态同步靠分布式数据
• UI 跨屏靠 Ability 调度

你要做的事情更偏向游戏逻辑设计本身，而不是重复造轮子。

接下来我们一步一步拆。

什么是鸿蒙里的跨屏游戏协作

跨屏不是投屏

先说一个很重要的点：

鸿蒙的跨屏游戏 ≠ 投屏

投屏的特点是：

• 一端渲染
• 另一端只是显示
• 没有真正的协作逻辑

而鸿蒙的跨屏游戏，更像是：

• 多设备同时运行
• 各自承担不同功能
• 通过系统级分布式能力协同

比如：

• 手机只负责操作和技能
• 平板或智慧屏负责主战场渲染
• 游戏状态在多设备之间自动同步

一个最常见的跨屏游戏形态

手机（控制器）
  │
  │ 操作指令
  ▼
平板 / 智慧屏（主画面）
  │
  │ 游戏状态同步
  ▼
分布式数据中心

支撑跨屏游戏的三大核心能力

分布式软总线：设备能“找到彼此”

在游戏里，你最关心的不是网络协议，而是：

• 能不能快速发现附近设备
• 延迟够不够低
• 掉线能不能感知

鸿蒙的分布式软总线解决的正是这些问题。

你不需要关心设备是：

• Wi-Fi
• 蓝牙
• 局域网
• 点对点

系统会自动选最优链路。

分布式数据管理：状态天然同步

跨屏游戏最怕的几个问题：

• 状态不一致
• 数据打架
• 玩家看到的画面不同步

鸿蒙提供的分布式 KV 数据，天生适合游戏里的：

• 玩家位置
• 血量
• 技能状态
• 回合阶段

而且是系统级同步，不是你自己发包。

分布式 UI：屏幕不是绑死的

在鸿蒙里：

• Ability 可以被拉起到其他设备
• 游戏不用重新启动
• 状态不需要你手动迁移

这对游戏来说很重要，因为你可以自由设计：

• 哪个屏幕显示什么
• 玩家如何参与
• 随时切换设备角色

跨屏游戏的整体架构设计

一个可落地的结构示例

┌────────────┐
│ 手机端     │
│ 操作输入   │
│ 技能按钮   │
└─────┬──────┘
      │
      │ 分布式 KV 数据
      ▼
┌────────────┐
│ 平板端     │
│ 游戏主画面 │
│ 渲染逻辑   │
└────────────┘

手机不负责画面，平板不负责输入，各司其职。

实战核心：跨屏游戏状态同步 Demo

创建分布式 KV Store

import distributedData from '@ohos.data.distributedData';

const kvManager = distributedData.createKVManager({
  bundleName: 'com.example.crossgame',
  context: getContext()
});

const store = await kvManager.getKVStore('gameStore', {
  kvStoreType: distributedData.KVStoreType.SINGLE_VERSION,
  securityLevel: distributedData.SecurityLevel.S1
});

这个 store 在多设备之间是共享的。

手机端发送操作指令

// 模拟摇杆方向
async function sendMove(x: number, y: number) {
  await store.put('player_move', JSON.stringify({
    x,
    y,
    time: Date.now()
  }));
}

这里同步的是“操作”，而不是最终坐标。

平板端监听并更新角色

store.on('dataChange', (data) => {
  data.insertedEntries.forEach(entry => {
    if (entry.key === 'player_move') {
      const move = JSON.parse(entry.value as string);
      updatePlayer(move.x, move.y);
    }
  });
});

跨屏 UI：把主画面拉到大屏

从手机拉起平板的游戏界面

import featureAbility from '@ohos.ability.featureAbility';

featureAbility.startAbility({
  want: {
    bundleName: 'com.example.crossgame',
    abilityName: 'GameMainAbility',
    deviceId: 'remoteDeviceId'
  }
});

前提是：

• 游戏状态已经存在分布式数据中
• 新设备启动后直接读取即可

为什么这个能力对游戏很重要

你不需要：

• 手动传进度
• 重新初始化状态
• 处理复杂的恢复逻辑

系统已经帮你兜底。

真实应用场景拆解

场景一：手机当手柄，大屏玩游戏

适合类型

• 派对游戏
• 本地多人
• 家庭娱乐

逻辑示例

// 手机端：技能释放
await store.put('skill_cast', {
  skillId: 2,
  playerId: 'p1'
});

// 大屏端：技能响应
store.on('dataChange', (data) => {
  data.insertedEntries.forEach(e => {
    if (e.key === 'skill_cast') {
      castSkill(e.value);
    }
  });
});

场景二：非对称协作游戏

比如：

• 一个人当指挥
• 一个人实际操作

// 指挥端下达命令
await store.put('command', {
  type: 'attack',
  target: 'boss'
});

操作端只负责执行，不做决策。

场景三：教育 + 游戏化互动

老师平板控制节奏，学生手机参与。

// 教师端切换关卡
await store.put('game_stage', 'level_2');

学生端监听并同步切换界面。

常见问题 QA

Q1：分布式 KV 会不会太慢？

不会。
它适合的是：

• 低频状态
• 操作指令
• 游戏阶段

高频帧同步需要更底层方案。

Q2：能不能用在竞技类游戏？

可以，但不建议直接用 KV 同步帧数据。
更适合：

• 操作同步
• 客户端预测
• 状态校正

Q3：设备掉线怎么办？

KV 会自动触发变更事件，你可以监听：

• 玩家退出
• 状态回收
• AI 接管

总结

从游戏开发角度看，鸿蒙的跨屏协作并不是噱头，而是一套真正能落地的系统能力。

核心就一句话：

多设备在鸿蒙里，不是多个客户端，而是一个分布式游戏系统。

• 软总线解决连接
• 分布式数据解决同步
• Ability 解决跨屏 UI
• ArkTS 足够把 Demo 跑起来