同步笔记
This commit is contained in:
Build Bot
@@ -1,164 +0,0 @@
|
||||
一个常驻 Editor 监控端 + 一个 Development Player + 一个外部 AI 分析进程。
|
||||
|
||||
Player 侧尽量不动，只保留 Unity 自带远程 Profiler 能力；尖峰检测、抓帧、解析、调用 AI 全放在 Editor 侧。
|
||||
|
||||
可行性判断
|
||||
|
||||
可行，前提是：
|
||||
|
||||
- Player 必须是 Development Build
|
||||
- 关闭 Autoconnect Profiler，改成手动 Attach to Player
|
||||
- 不开 Deep Profiling Support
|
||||
- 监控期间必须有一个 Unity Editor 进程连着这个 Player
|
||||
|
||||
Unity 2022.3 官方文档明确：
|
||||
|
||||
- 手动 Attach to Player 只有在 Autoconnect Profiler 关闭时才可用
|
||||
- 远程 profiling 的前提是目标在运行 Development Build
|
||||
- ProfilerWindow / RawFrameDataView / HierarchyFrameDataView 都是 Editor 侧能力
|
||||
|
||||
来源：
|
||||
|
||||
- https://docs.unity3d.com/cn/2022.3/Manual/profiler-profiling-applications.html
|
||||
- https://docs.unity3d.com/cn/2022.1/ScriptReference/ProfilerWindow.html
|
||||
- https://docs.unity3d.com/ja/2022.3/ScriptReference/Profiling.RawFrameDataView.html
|
||||
|
||||
推荐架构
|
||||
|
||||
1. 构建层
|
||||
|
||||
- 只开 Development Build
|
||||
- 不开 Autoconnect Profiler
|
||||
- 不开 Deep Profiling Support
|
||||
|
||||
这样 Player 侵入最低，也保留手动远程 attach 能力。
|
||||
你们现有入口里，client/Assets/Scripts/Editor/Builder/AndroidAppBuilder.cs:92 和 client/Assets/Scripts/Editor/Builder/WindowAppBuilder.cs:43 都可以拆一个专门的
|
||||
ProfileBuild 配置。
|
||||
|
||||
2. 连接层
|
||||
|
||||
- 启动 Player
|
||||
- 在常驻 Editor 中手动 Attach to Player
|
||||
- 一旦连上，后面监控逻辑自动跑
|
||||
|
||||
这里我建议第一版不要做“自动 attach”。
|
||||
原因是“编程方式切换 Active Profiler 连接”公开 API 很弱，强行自动化通常要碰 UnityEditorInternal / 反射，升级风险高。
|
||||
第一版只要求人工选一次连接，后面全部自动。
|
||||
|
||||
3. 监控层
|
||||
|
||||
- Editor 里做一个 EditorWindow 或 [InitializeOnLoad] 服务
|
||||
- 持续盯 ProfilerWindow.lastAvailableFrameIndex
|
||||
- 每来一个新 frame，就读该 frame 的 CPU 时间
|
||||
- 超过阈值就进入分析流程
|
||||
|
||||
这里可以直接基于 ProfilerWindow 的最新帧索引做，不需要 Player 回传 frameIndex。
|
||||
ProfilerWindow 提供 lastAvailableFrameIndex 和 selectedFrameIndex。
|
||||
来源：https://docs.unity3d.com/cn/2022.1/ScriptReference/ProfilerWindow.html
|
||||
|
||||
4. 解析层
|
||||
|
||||
- 对触发帧用 HierarchyFrameDataView 拿主线程/渲染线程热点树
|
||||
- 取 Top N 热点 sample
|
||||
- 对重点 sample 再用 RawFrameDataView 深挖
|
||||
- 抽：
|
||||
- frameTimeMs
|
||||
- frameGpuTimeMs
|
||||
- 主线程 Top N
|
||||
- RenderThread Top N
|
||||
- GC.Alloc
|
||||
- Unity Object 信息
|
||||
- 可用 callstack
|
||||
|
||||
FrameDataView 里直接有 frameTimeMs / frameGpuTimeMs 等帧级信息。
|
||||
RawFrameDataView 官方示例也明确支持遍历样本和查 GC.Alloc。
|
||||
来源：
|
||||
|
||||
- https://docs.unity3d.com/cn/2022.1/ScriptReference/Profiling.FrameDataView.html
|
||||
- https://docs.unity3d.com/ja/2022.3/ScriptReference/Profiling.RawFrameDataView.html
|
||||
- https://docs.unity3d.com/cn/2022.3/ScriptReference/Profiling.FrameDataView.GetUnityObjectInfo.html
|
||||
|
||||
5. AI 输入层
|
||||
不要把整帧原始数据直接扔给 AI。先整理成一个紧凑 JSON，例如：
|
||||
|
||||
{
|
||||
"session": {
|
||||
"platform": "Android",
|
||||
"device": "xxx",
|
||||
"build": "development"
|
||||
},
|
||||
"frame": {
|
||||
"index": 12345,
|
||||
"cpuFrameMs": 68.4,
|
||||
"gpuFrameMs": 41.2
|
||||
},
|
||||
"threads": [
|
||||
{
|
||||
"name": "Main Thread",
|
||||
"topSamples": [
|
||||
{
|
||||
"name": "Canvas.SendWillRenderCanvases",
|
||||
"totalMs": 23.1,
|
||||
"selfMs": 4.2,
|
||||
"calls": 1
|
||||
}
|
||||
]
|
||||
}
|
||||
],
|
||||
"gc": {
|
||||
"allocBytes": 524288
|
||||
},
|
||||
"unityObjects": [
|
||||
{
|
||||
"type": "Texture2D",
|
||||
"name": "xxx"
|
||||
}
|
||||
]
|
||||
}
|
||||
|
||||
然后再补两类上下文给 AI：
|
||||
|
||||
- 设备、场景、操作步骤、网络状态
|
||||
- 根据热点 marker 名在仓库里 rg 出来的候选代码文件
|
||||
|
||||
这样 AI 才能给“代码级建议”，不是只说“UI 很慢”。
|
||||
|
||||
第一版建议的最小闭环
|
||||
|
||||
我建议你先只做这条链：
|
||||
|
||||
1. Development Build 运行
|
||||
2. Editor 手动 attach
|
||||
3. Editor 自动监控最新帧
|
||||
4. CPU 帧时间超阈值
|
||||
5. 解析主线程 Top 10 + RenderThread Top 5 + GC.Alloc
|
||||
6. 生成 spike-report.json
|
||||
7. 拉起外部 AI CLI 分析
|
||||
先不要做：
|
||||
|
||||
- 自动 attach
|
||||
- 全模块分析
|
||||
- Deep Profiling
|
||||
- Player 侧埋点改造
|
||||
- 自动改代码
|
||||
|
||||
关键风险
|
||||
|
||||
- 远程 attach 本身就有开销，所以阈值要留冗余，不能拿它当“最终真实性能数据”。
|
||||
- 不开 Deep Profiling 时，很多热点只能看到 Unity marker，看不到足够细的业务方法。
|
||||
- 如果没有你们自己的 ProfilerMarker，AI 很可能只能把建议停留在“怀疑某个 UI 刷新或资源加载链路”。
|
||||
|
||||
所以这套方案第一阶段的价值更像：
|
||||
|
||||
- 自动发现尖峰
|
||||
- 自动归档证据
|
||||
- 自动把“热点帧 -> 代码候选 -> 优化建议”串起来
|
||||
|
||||
不是一步到位做根因精确定位。
|
||||
|
||||
我对落地顺序的建议
|
||||
|
||||
1. 先做 Editor 监控器
|
||||
2. 再做帧解析导出 JSON
|
||||
3. 再接 AI CLI
|
||||
4. 最后再考虑自动 attach 和自定义 marker
|
||||
@@ -1,13 +0,0 @@
|
||||
|
||||
## 思路
|
||||
- 检测git diff代码，经过LLM分析需要测试哪些模块，如果diff的代码是修改，已经有相应的案例的话，直接跑，没有的话，添加新案例。把跑出来的报错发到报告错误频道。
|
||||
## need to do
|
||||
- git push webhook(已实现)
|
||||
- diff代码经过AI Agent分析对应的AirTest案例
|
||||
- 如果是新的模块，编写AirTest案例
|
||||
- 拉起对应的AirTest案例运行
|
||||
- 报告发到对应频道
|
||||
## 细节
|
||||
- 如何mock数据？
|
||||
- 如何识别出改动的地方的不同伪造数据的表现？
|
||||
- 检测中需要检测某某位置是否出现了正确的图标
|
||||
@@ -1,2 +0,0 @@
|
||||
|
||||
## 客户端的单元测试可处理范围
|
||||
@@ -1,38 +0,0 @@
|
||||
完成！我为你创建了完整的 **Jenkins + Claude Code 自动代码审查** 方案。
|
||||
|
||||
## 创建的文件
|
||||
|
||||
| 文件 | 说明 |
|
||||
| ----------------------------------- | --------------------------------- |
|
||||
| `scripts/ci/claude_code_review.sh` | Bash 版本审查脚本（生成提示文件） |
|
||||
| `scripts/ci/claude_code_review.bat` | Windows 版本审查脚本 |
|
||||
| `scripts/ci/claude_api_review.py` | Claude API 自动审查（Python） |
|
||||
| `docs/jenkins-claude-review.md` | 完整配置文档 |
|
||||
| 修改 `Jenkinsfile` | 新增 `Claude Code Review` stage |
|
||||
|
||||
## 工作流程
|
||||
|
||||
```
|
||||
Git Push ──► Jenkins ──► Unity Build ──► Airtest ──► Claude Review ──► 归档报告
|
||||
```
|
||||
|
||||
## 使用方式
|
||||
|
||||
### 方式一：手动审查（无需 API Key）
|
||||
构建完成后下载 `Logs/ci/reviews/*-review-prompt.md`，然后在 Claude Code 中打开：
|
||||
```bash
|
||||
claude < review-prompt.md
|
||||
```
|
||||
|
||||
### 方式二：API 自动审查
|
||||
1. Jenkins 安装 Python 依赖：`pip install anthropic`
|
||||
2. Jenkins 配置凭据 ID 为 `anthropic-api-key` 的 Secret text
|
||||
3. 构建完成后自动调用 Claude API 生成审查报告
|
||||
|
||||
## Jenkinsfile 关键修改
|
||||
|
||||
- **新增 stage**: `Claude Code Review`（在 `Publish Project Build` 之后）
|
||||
- **权限更新**: 添加了 `claude_code_review.sh` 和 `claude_api_review.py` 的执行权限
|
||||
- **产物归档**: 包含 `Logs/ci/reviews/**` 中的所有审查文件
|
||||
|
||||
需要我帮你配置 Jenkins 凭据或测试这个流程吗？
|
||||
@@ -1 +0,0 @@
|
||||
- 图片需要的format为RGBA格式，但是文字只需要灰度图，所以需要两种不同的处理方式，但需要在一个shader中处理
|
||||
@@ -1,10 +0,0 @@
|
||||
---
|
||||
tags:
|
||||
- 图文合批
|
||||
- 目录
|
||||
- MOC
|
||||
---
|
||||
|
||||
- [[图文使用不同的Tex2DArr]]
|
||||
- [[字体字形图片申请]]
|
||||
|
||||
@@ -1,6 +0,0 @@
|
||||
### TMP字体
|
||||
- 通过`TMP_FontAsset.characterLookupTable.TryGetValue(char, out charInfo);`获得字符串信息
|
||||
- 通过charInfo.glyph.glyphRect获得TMP_FontAsset.atlasTextures中的uv
|
||||
|
||||
### 传统字体
|
||||
- TODO
|
||||
@@ -1,46 +0,0 @@
|
||||
### 蒙皮动画原理
|
||||
- 网格顶点可以绑定多根骨骼
|
||||
- 所以网格顶点在运行时就可以确定为根骨骼的**空间矩阵** * **骨骼混合权重** * **网格空间坐标**
|
||||
- 世界坐标系下 RootTRS * 骨骼混合TRS * ResetPoseTRS
|
||||
|
||||
### 为什么要升级到蒙皮动画
|
||||
- 可以做动画混合
|
||||
- IK
|
||||
- 动态挂点
|
||||
- 节省贴图
|
||||
- 只需要渲染一张所有网格的顶点，不再需要每个clip都渲染全顶点贴图
|
||||
|
||||
### 混合架构：近处用 GPU Skinning，远处用顶点动画
|
||||
|
||||
这是很多项目最终的策略：
|
||||
|
||||
- Camera 近处：角色很重要 → GPU Skinning（可以混合、IK、物理）
|
||||
|
||||
- Camera 中远距离：角色只占几像素 → 提前烘成顶点动画、帧数降采样或干脆用 BillBoard
|
||||
|
||||
|
||||
你的当前顶点动画管线可以直接作为“LOD 动画层”保留，不与 GPU Skinning 冲突，只要切换 Renderer/Material 即可。
|
||||
#### 蒙皮动画需要记录的数据有哪些？
|
||||
- 一张原始网格的Vector3数据贴图
|
||||
- 收集[[bindpose]]
|
||||
- 收集全局骨骼索引
|
||||
- 根据不同的蒙皮组件需要的骨骼，重新映射索引
|
||||
- 为什么需要这个？
|
||||
- 身体的骨骼索引，索引分别是1、2、3、4
|
||||
- 腰
|
||||
- 肩膀
|
||||
- 手臂
|
||||
- 手掌
|
||||
- 而手臂为，索引为3、4
|
||||
- 手臂
|
||||
- 手掌
|
||||
- 该动作中每个网格的顶点计算：
|
||||
- Root在世界空间坐标的TRS
|
||||
- 每根骨骼还原[[bindpose]]
|
||||
- **混合骨骼**后的TRS * 原始网格的TRS
|
||||
|
||||
#### 蒙皮动画不同部位索引的问题
|
||||
- 蒙皮的骨骼索引在cpu中无问题，在gpu中有问题
|
||||
- Unity在创建骨骼的时候会检查骨骼**bindpose**和骨骼**索引**,如果索引超出，无法创建
|
||||
|
||||
---
|
||||
@@ -1,7 +0,0 @@
|
||||
### 顶点动画原理
|
||||
- 将蒙皮**网格**基于根骨骼的相对位移Vector3都写进一张图片中
|
||||
- 在运行时，在Shader中根据根骨骼空间矩阵，算出每个顶点
|
||||
### 烘焙阶段
|
||||
- 采样Clip在根骨骼的GameObject上的动画
|
||||
- 将采样到的每一帧网格顶点Vector3写进图片里
|
||||
- 另外烘焙一份uv1进网格，用来存储顶点索引
|
||||
@@ -1,5 +0,0 @@
|
||||
动作文件在导入Unity后会将网格顶点绑定在**蒙皮节点空间**下的坐标储存在bindpose中。
|
||||
- 例如：如果根节点在(0,0,0)，骨骼在(0,0,10)，网格顶点在骨骼空间坐标为(0,0,1)，在导入之后，顶点坐标会被保存为(0,0,11);
|
||||
|
||||
|
||||
- GPU蒙皮动作中，需要将顶点还原为**骨骼节点空间下**坐标后再重新从root开始算
|
||||
@@ -1,9 +0,0 @@
|
||||
---
|
||||
原文发布链接: https://zhuanlan.zhihu.com/p/18503608013
|
||||
tags:
|
||||
- GPU动画
|
||||
- ComputeShader
|
||||
- 顶点动画
|
||||
---
|
||||
- GPU蒙皮动画 https://zhuanlan.zhihu.com/p/574550709
|
||||
- Unity实现GPU动画 https://zhuanlan.zhihu.com/p/690695496
|
||||
@@ -1,8 +0,0 @@
|
||||
---
|
||||
tags:
|
||||
- GPU蒙皮动画
|
||||
- Spine
|
||||
原文发布链接: "[[基于GPU动画和ComputeShader的大批量动画渲染Demo（一）之GPU顶点动画]]"
|
||||
---
|
||||
|
||||
|
||||
@@ -1,13 +0,0 @@
|
||||
---
|
||||
tags:
|
||||
- gpu动画
|
||||
---
|
||||
|
||||
|
||||
- 通过[[GPU动画]]，将Clip（每个顶点每帧的位置）烘焙到一张图片上去。
|
||||
- 用shader做顶点偏移，片元着色还是原来物体上的
|
||||
|
||||
### QA
|
||||
- Q：如何保留原来shader的片元着色？
|
||||
- Q：需要烘焙些什么信息，它们分别用在什么地方？
|
||||
- Q：如果本身一个clip由多个不同的蒙皮动画来实现，每个蒙皮又对应不同的骨骼，该怎么处理？
|
||||
@@ -1,12 +0,0 @@
|
||||
---
|
||||
tags:
|
||||
- 海量渲染战斗
|
||||
- 目录
|
||||
- MOC
|
||||
---
|
||||
|
||||
- [[GPU动画]]
|
||||
- [[批量渲染gpu动画]]
|
||||
- [[基于GPU蒙皮动画的Spine实现]]
|
||||
- [[基于GPU动画和ComputeShader的大批量动画渲染Demo（一）之GPU顶点动画]]
|
||||
|
||||
2
1Project/独游-大富翁/遗物.md
Normal file
2
1Project/独游-大富翁/遗物.md
Normal file
@@ -0,0 +1,2 @@
|
||||
- 遗物激活飘名 测试
|
||||
- 每个遗物效果测试
|
||||
@@ -1,16 +0,0 @@
|
||||
|
||||
- 整理
|
||||
- 每个月的计划
|
||||
- 收入
|
||||
- 主动收入：工作
|
||||
- 被动收入：投资基金等收入
|
||||
- 支出
|
||||
- 固定支出：吃住行
|
||||
- 弹性支出：娱乐开销等
|
||||
- 做两张借记卡，一张存固定支出的钱，一张存弹性支出的钱，剩下的钱拿去理财
|
||||
|
||||
- 信用卡每月需要做
|
||||
-
|
||||
|
||||
- 股票怎么玩
|
||||
-
|
||||
@@ -1,17 +0,0 @@
|
||||
---
|
||||
tags:
|
||||
- 项目
|
||||
- 目录
|
||||
- MOC
|
||||
---
|
||||
|
||||
## 入口
|
||||
- [[GPU地形/GPU地形-目录]]
|
||||
- [[图文合批/图文合批-目录]]
|
||||
- [[海量渲染战斗/海量渲染战斗-目录]]
|
||||
- [[构建新框架/MVVM/MVVM-目录]]
|
||||
- [[外包/Project_城堡/城堡-目录]]
|
||||
|
||||
## 单页
|
||||
- [[理财]]
|
||||
|
||||
Reference in New Issue
Block a user