PUN Classic(PUN1とも呼ばれます)はPUNのはじめの主要バージョンです。         現在は、リファクタリングおよび機能拡張されたPUN2に切り替わっています。         新しいプロジェクトはPUN2をご利用いただき、また可能であれば既存のプロジェクトについてもPUN1からPUN2へ移行していただくよう強く推奨しています。 こちらをご参照ください: "移行情報". PUN Cloassicは今後数か月メンテナンスされます。       重要なバグの修正や新しいUnityバージョンのサポートは行いますが、新機能の追加はPUN2のみとなります。

最適化のヒント

制限とキャッシュコールバックターゲット

便宜上、PUNコールバックは任意のMonoBehaviourおよび任意のGameObjectで実装することができます。 これらのコールバックの頻度は低いため、通常は問題にはなりません(カスタムプロパティの更新を除く)。

内部的にはUnityのSendMessageはコールバックをディスパッチに使用され、それがパフォーマンスに影響する可能性があります。 さらに大きな問題としては、コンポーネントを見つけるためにFindObjectsOfType()が必要であるということです(これはコールバックを実装、または実装しない可能性があります)。

PhotonNetwork.SendMonoMessageTargetsを使用すると、どのGameObjectが呼び出されるかを定義できます。 PhotonNetwork.CacheSendMonoMessageTargets(Type t)では、どのタイプのコンポーネントをターゲットにするかを定義することでSendMonoMessageTargetsを設定できます。

必要に応じてSendMonoMessageTargetsを更新することができます。 デフォルトの強引なアプローチよりも高速に処理がおこなえます。

Back To Top

OnPhotonSerializeViewとIPunObservable

デフォルトでは、PhotonViewはリフレクションとキャッシングを使用して、コンポーネント上のOnPhotonSerializeView実装を見つけて呼び出します。

MonoBehavioursで IPunObservableインタフェースを実装することで、OnPhotonSerializeViewの呼び出しを最適化できます。

Back To Top

RPCターゲットをキャッシュ

場合によっては、ゲームで多くのRPCを使用することがあります。 ターゲットGameObject上のどのコンポーネントもRPCを実装できるため、PUNはリフレクションを使用して適切なメソッドを見つけます。 もちろんコンポーネントが変更されない場合には、これは負荷がかかり無駄なことになります。

デフォルトでは、PUNはスクリプトのタイプごとにMethodInfoリストをキャッシュします。 PUNは、GameObject上で潜在的なターゲットであるMonoBehavioursはキャッシュしません。

PhotonNetwork.UseRpcMonoBehaviourCache = trueを設定して、RPC用のPhotonViewごとのMonoBehavioursをキャッシュすることができます。 これにより、呼び出すコンポーネントの検索が高速化されます。 GameObjectのスクリプトが変更された場合は、必要に応じてphotonView.RefreshRpcMonoBehaviourCache()を呼び出して必要に応じて更新してください。

Back To Top

RaiseEventのローカルログを回避

RaiseEventを呼び出す場合、データは即時でソケットには書き込まれません。その代わりに、SendOutgoingCommands()が呼び出されるまでデータは待ち行列に入れられます。

ローカルラグを回避するには、RaiseEventをトリガーにしてLateUpdate()SendOutgoingCommands()を呼び出します。 これは、必要に応じて実行すれば十分です。

ドキュメントのトップへ戻る