7.1 技能批处理 - Ability Batching
GameplayAbilities的激活，发送TargetData到服务器（可选），并且结束这一切，如果这些都是在一帧内完成的话就可以将两到三个RPC合并成一个。这些类型的技能常用于处理霰弹枪。
7.2 游戏反馈批处理 - Gameplay Cue Batching
如果你要在同一时间发出许多个的GameplayCues，可以考虑将他们合批到一个RPC中。这样可以有效减少RPC的数量（GameplayCues是unreliable的多播NetMulticasts），从而尽量发送少一些数据。
7.3 技能系统组件的复制模式 - AbilitySystemComponent Replication Mode
默认情况下，ASC是处于Full Replication Mode模式。这会默认将所有的GameplayEffects复制到每个客户端（单人游戏来说没有任何问题）。在多人游戏中，将玩家拥有的ASCs设置为Mixed Replication Mode，将AI控制的角色设置为Minimal Replication Mode。这会把玩家角色上应用的GEs只复制给角色的拥有者，AI控制的角色将永远不会复制其GEs给客户端。GameplayTags将会复制并且GameplayCues依然会不可靠得广播给所有得客户端，而不管其Replication Mode是什么。当所有得客户端都不需要看到这些GEs时，这种做法能够有效减少复制的数据的量。
7.4 属性代理的复制 - Attribute Proxy Replication
像Fortnite Battle Royale（FNBR）这样的有很多玩家的大型游戏，将会有很多的ASCs存在于对应的PlayerStates，并且会有大量要复制的Attributes。为了应对这个瓶颈，Fortnite的做法是在 模拟的玩家控制端的PlayerState::ReplicateSubobjects()中禁用了 ASC 及其 AttributeSets 的复制。主控端代理和AI控制的 Pawns 依然会根据其具体的 Replication Mode 去进行各自的复制。相对的，在抛弃复制PlayerStates 对应的 ASC 上的Attributes 的做法后，FNBR在玩家的 Pawn 上使用了一个复制代理结构体。当服务器上的ASC上的 Attributes 改变时，其代理结构体也会随之发生改变。客户端从代理结构体中接收到复制的 Attributes，并且将其中包含的属性修改推到本地 ASC 中。这就可以令 Attribute 的复制利用到 Pawn 的相关机制以及 NetUpdateFrequency。这个代理结构体也可以使用位掩码复制一个小的GameplayTags的白名单组。这个做法可以减少网络上传递的数据的量，并且让我们能够利用到 pawn的相关内容。AI控制 Pawns 的 ASC 的位置是在 Pawn 上，其本身就已经用到这个机制，所以也不需要单独为他们去做这个优化。
I’m not sure if it is still necessary with other server side optimizations that have been done since then (Replication Graph, etc) and it is not the most maintainable pattern.
Epic的Dave Ratti针对 community questions #3 的回答
7.5 技能系统组件的延迟加载 - ASC Lazy Loading
Fortnite Battle Royale（FNBR）的世界中有非常多的可以伤害的AActors（树，建筑等等），他们身上都会挂有ASC。这将增加内存的消耗。FNBR的策略是延迟加载这些ASCs，只在需要他们的时候才去加载（当这些物体被玩家施加伤害时）。这可以整体上减少相当可观的内存消耗，因为可能有些AActors在整局游戏中都不会被碰一下。