一、测试与性能分析
如题，笔者使用git上的工程 https://github.com/tomlooman/EpicSurvivalGameSeries/tree/Section-4
将其AI数量扩充至100，进行性能测试。
通过工程分析发现，在大量单位同时存在时，CharacterMovementCompoennt的移动开销变得很庞大，如图所示：
细查下发现主要开销在于移动模拟以及其中的物理、碰撞等消耗，如下所示：
代码细节查询（此处省略不少细节，感兴趣的童鞋可以自行查找）：
Char Simulated Time ------->
void UCharacterMovementComponent::SimulatedTick(float DeltaSeconds)
MovementComponent_ResolvePenetration ---->
bool UMovementComponent::ResolvePenetrationImpl(const FVector& ProposedAdjustment, const FHitResult& Hit, const FQuat& NewRotationQuat)
MoveComponent(Primitive) Time ------>
bool UPrimitiveComponent::MoveComponentImpl( const FVector& Delta, const FQuat& NewRotationQuat, bool bSweep, FHitResult* OutHit, EMoveComponentFlags MoveFlags, ETeleportType Teleport)
GeomSweepMultiple ---->
bool UWorld::ComponentSweepMulti(TArray<struct FHitResult>& OutHits, class UPrimitiveComponent* PrimComp, const FVector& Start, const FVector& End, const FQuat& Quat, const FComponentQueryParams& Params) const
SceneQueryTotal 和 GeomSweepMultiple ------->
bool /FPhysicsInterface::/GeomSweepMulti_PhysX(const UWorld* World, const PxGeometry& PGeom, const PxQuat& PGeomRot, TArray<FHitResult>& OutHits, FVector Start, FVector End, ECollisionChannel TraceChannel, const struct FCollisionQueryParams& Params, const struct FCollisionResponseParams& ResponseParams, const struct FCollisionObjectQueryParams& ObjectParams)
PrimComp DispatchBlockingHit ----->
void UPrimitiveComponent::DispatchBlockingHit(AActor& Owner, FHitResult const& BlockingHit)
二、优化思路
可以从降低碰撞（禁用或者有限启用GenerateOvelapEvent）、简化Client的移动模拟（重写SimulateMovement简化模拟移动）、同步相关性剪裁（添加自定义剪裁方法）等方面优化，此前笔者曾基于此问题向EPIC提问，下面结合笔者理解做简要说明。
服务器CPU使用率:
1.客户端默认情况下以相当高的速率向服务器发送移动，详见UCharacterMovementComponent::GetClientNetSendDeltaTime()。对于一些游戏，可以通过降低客户端发送频率，如20Hz-30Hz，这可以直接的降低CPU性能消耗。
2.考虑下服务器是否需要MeshAnimation（在大多情况下是不需要的）。ServerMove通常会继续Animation的更新，可以设置MeshComponentUpdate 为 OnlyUpdateWhenRendered，这样在不显示的情况下就不会继续更新（这样也可以避免蓝图开销）。如果在某些情况下仍需要更新pose，但是没有bone坐标，你可以参考bNoSkeletonUpdate设置或者其他选项。在这种情况下，如果需要进行蒙太奇播放，可以开/关CompoenntTick和Mesh的Flag。
3.不移动的Character设置bAlwaysCheckFloor = false，可以减少检测消耗。
4.降低 MaxSimulationIterations 和 MaxSimulationTimeStep，默认设置是针对非常高质量的模拟设置的，但是通常2到4次迭代既可以获得较长的timesteps，在网络或CPU峰值的情况下，这避免了双重模拟，以平滑较长时间增量的移动。
- 组件: 尝试获取附加在胶囊体和Mesh上的组件数量，因为在服务器上，如粒子、音频等组件是无效的，另外尽可能取消附加组件的碰撞（或者尽可能取消对于Pawn或者Player的碰撞）。
6.Overlap events: 尽可能的取消bGenerateOverlapEvents，通常只有Player的胶囊体才启用Overlap。
客户端CPU使用率:
1.为了降低在客户端的模拟移动成本，最好的办法就是重写UCharacterMovementComponent:: simulatemomovement()函数来避免胶囊体位置矫正中的各种物理、碰撞的计算。可以直接用差值的方法模拟移动的平滑过渡。当然，为了保证近距离角色的移动表现，也可以通过距离判断，距离近的玩家使用默认的移动模拟，距离远的角色直接启用差值。
2.下面是UCharacterMovementComponent: SimulateMovement（）的简化实现大纲（省略复杂的实现，但是不能省略 移动模式变更的处理）：
// Copy some Super::SimulateMovement()
if (bNetworkMovementModeChanged)
{
bNetworkMovementModeChanged = false;
ApplyNetworkMovementMode(GetCharacterOwner()->GetReplicatedMovementMode());
}
UpdateComponentVelocity();
bNetworkUpdateReceived = false;
bJustTeleported = false;
LastUpdateLocation = UpdatedComponent ? UpdatedComponent->GetComponentLocation() : FVector::ZeroVector;
LastUpdateRotation = UpdatedComponent ? UpdatedComponent->GetComponentQuat() : FQuat::Identity;
LastUpdateVelocity = Velocity;
3.在动画播放的某些情况下可能依然要使用FindFloor进行模拟（Root Montage？这一项没有进行专门测试）
4.同时，simulated proxies类型的模拟对象需要考虑是否启用bGenerateOverlapEvents，建议改成默认不启用，在需要时启用。
