Commit d323f7a9 authored by hex's avatar hex

optimize tcp weak-network handling and ocgcore performance baseline

parent 0f33a907
This diff is collapsed.
......@@ -64,9 +64,9 @@ public class MyCard : WindowServantSP
{
TerminateRequest();
}
if (TcpHelper.tcpClient != null && TcpHelper.tcpClient.Connected)
if (TcpHelper.tcpClient != null)
{
TcpHelper.tcpClient.Close();
TcpHelper.Disconnect(true);
}
}
......
This diff is collapsed.
......@@ -1592,7 +1592,7 @@ public class Program : MonoBehaviour
Running = false;
try
{
TcpHelper.tcpClient.Close();
TcpHelper.Disconnect(true);
}
catch (Exception e)
{
......
......@@ -291,10 +291,7 @@ public class SelectServer : WindowServantSP
Program.I().shiftToServant(Program.I().menu);
if (TcpHelper.tcpClient != null)
{
if (TcpHelper.tcpClient.Connected)
{
TcpHelper.tcpClient.Close();
}
TcpHelper.Disconnect(true);
}
}
......
# OCGCore 性能与稳定性问题记录(2026-02-07)
## 背景
- 项目:`ygopro2_unity2021`(Unity 2021)
- 目标平台重点:iOS 移动端
- 当前阶段:已完成一轮 TCP 弱网优化与 `Ocgcore.cs` 重点性能排查
## 已完成的优化(当前工作区)
### 1) TCP 弱网优化(不改服务端协议)
- 文件:`Assets/SibylSystem/MonoHelpers/TcpHelper.cs`
- 要点:
- 连接阶段参数更适配移动端(连接超时、KeepAlive 参数)
- 新增对局空闲期心跳(`CtosMessage_TimeConfirm`),避免“玩家思考无操作”期间误断线
- 发送失败增加短重试,提升瞬时抖动下的可用性
### 2) `realize()` 主流程降分配与降重复扫描
- 文件:`Assets/SibylSystem/Ocgcore/Ocgcore.cs`
- 要点:
- 将高频临时列表改为复用缓冲,减少 GC 压力
- 合并多处统计循环,单次遍历同时收集 deck/extra/grave/removed 计数
- 新增 overlay 映射缓存,避免反复 O(N²) 查找叠放素材
- 将库/额外/墓地/除外计数显示改为集中写入,减少重复调用
## 当前仍存在的主要性能热点
### P0:全量刷新触发频率高
- 位置:`Assets/SibylSystem/Ocgcore/Ocgcore.cs:7412`
- 现象:`realize()` 仍是全局大函数,且在消息处理中触发频繁。
- 风险:在移动端(尤其 iOS)高频对局消息下,主线程抖动明显。
### P0:按 GPS 查卡仍为线性扫描
- 位置:`Assets/SibylSystem/Ocgcore/Ocgcore.cs:8789`
- 现象:`GCS_cardGet()` 每次查找都遍历 `cards`,对高频消息处理放大开销。
- 风险:对局越长、卡越多,查找成本越高。
### P1:局部统计函数重复扫全表
- 位置:
- `Assets/SibylSystem/Ocgcore/Ocgcore.cs:2803``countLocation`
- `Assets/SibylSystem/Ocgcore/Ocgcore.cs:2822``countLocationSequence`
- 现象:多处消息处理和 UI 刷新仍依赖全表计数。
### P1:整理阶段全量排序成本高
- 位置:`Assets/SibylSystem/Ocgcore/Ocgcore.cs:9075`
- 现象:`arrangeCards()` 进行全量 `Sort + 重写 sequence`
- 风险:若触发频率高,会出现额外 CPU 开销与潜在映射时序问题。
### P1:特效对象频繁 Instantiate/Destroy
- 位置示例:`Assets/SibylSystem/Ocgcore/Ocgcore.cs:5722``Assets/SibylSystem/Ocgcore/Ocgcore.cs:5762`
- 现象:指示物增减等消息内循环创建销毁特效对象。
- 风险:高频时造成 GC 与帧时间尖刺。
### P2:部分辅助函数仍有短生命周期 List 分配
- 位置:`Assets/SibylSystem/Ocgcore/Ocgcore.cs:6397``Assets/SibylSystem/Ocgcore/Ocgcore.cs:6431`
- 现象:`MHS_getBundle` / `MHS_resizeBundle` 仍使用即时新建列表。
## 功能稳定性风险(与“确认卡片”相关)
### ConfirmDecktop 定位来源不一致风险
- 位置:
- `Assets/SibylSystem/Ocgcore/Ocgcore.cs:2471`
- `Assets/SibylSystem/Ocgcore/Ocgcore.cs:4811`
- 现象:读取了 `ReadShortGPS()`,但后续定位卡片时使用“本地重算 sequence / 固定 Deck”的方式。
- 风险:当本地状态与消息发送时状态不完全同步,或确认来源并非严格 Deck 语义时,可能出现“展示与确认不是同一卡”的体验。
## 建议的后续执行顺序
1. 先做 `GCS_cardGet` 的索引化(字典缓存 + 变更点增量维护)
2. 再做 `realize()` 的脏区刷新(按 location/owner 增量更新)
3. 为 Confirm 系列消息统一“以消息 GPS 为唯一定位源”
4. 最后处理特效对象池与细节内存分配
## 验证建议(iOS/弱网)
- 使用 Network Link Conditioner / Charles / `tc netem` 组合测试:
- 高延迟(150ms~500ms)、丢包(2%~10%)、抖动(50ms~150ms)
- 长时间“仅思考无操作”场景(5~10 分钟)
- 观察项:
- 是否误断线
- 心跳是否仅在对局空闲阶段触发
- `realize()` 相关帧时间峰值与 GC 分配是否下降
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment