4

私はいくつかの場所でこの質問をしましたが、まだ完全には理解していません。

プロジェクトでプレハブの深くネストされた階層を維持する最良の方法は何ですか? 小さい汎用コンポーネントで構成された GUI 画面がいくつかあるとします。簡単にするために、前者を「ビュー」、後者を「コンポーネント」と呼びましょう。ビューはセマンティクスを扱います (在庫ビュー、店舗ビューなど)。コンポーネントは構成可能ですが、ビジネス ロジックはまったく関連付けられていません (たとえば、ボタンはその OnTap コールバック/イベント ハンドラーのみを考慮します)。

ビューとコンポーネントの両方をネストできます。

GUI ビューは複数のシーンで再利用する必要があります。

Unity でのこのアプローチの主な問題は、ネストされた階層が一度プレハブに変換されると、次の (完全に作成されたがまだ有効な) 例のように、その子プレハブへの参照が失われるという事実です。

- storeView - UIViewHeader - UIHeaderLabel<Text> - UIList - UIListItem - UIThumbnail - UITitleLabel<Text> - UISubTitleLabel<Text> - UIPrimaryButton<Button> - ...

これらすべての小さな UI* コンポーネントを個別のプレハブに保持したいと考えていますが、別のシーンに簡単に追加できるように storeView プレハブも保持したいと考えています。残念ながら、storeView プレハブを作成するとすぐに、すべての UI* プレハブ参照が失われます。その場合、別のアプローチを試すことができます。コンテンツを含む storeView プレハブを用意する代わりに、空のままにして、次のいくつかのオプションのいずれかを選択します。

  1. 動作を storeView にアタッチし、実行時に子プレハブをロードする
    • 短所：デザイナーのワークフローがより複雑になり、スクリプトが複雑になり、開発者の観点からもエラーが発生しやすくなる可能性があります
    • 長所: シーン間での storeView の再利用が容易になり、コンポーネント プレハブのスタイル設定やグローバルな変更が可能
  2. storeView を空のプレハブとして保持し、それを必要とするすべてのシーンで再構築します
    • 短所: コンポーネントを手動で接続する必要があります。storeView 全体を誤って保存して、プレハブの参照を失うことは依然として簡単です。
    • 長所：コンポーネントのプレハブ参照が維持されることを保証し、ビュー間のわずかな違いを許容します（これらは構成レイヤーに属する必要があるため、実際には問題です）
  3. storeView 全体をプレハブとして保存する
    • 短所: 拡張性が非常に高く、新しい機能や小さな UX の変更の繰り返しに時間がかかります (追加の QA、受け入れテストなど...)。
    • 長所：小規模なプロジェクトでうまく機能する、迅速で汚いソリューションです
  4. Prefab Evolution などを使用する
    • 短所: パッケージは、ロードマップにある入れ子になったプレハブによって廃止されると思いますか? サードパーティのコードに依存する必要があり、十分な柔軟性がない可能性があります (意見はありますか?)
    • 長所：私が見た多くの（さまざまな）レビューから、いくつかは非常に肯定的でした. ただし、プロジェクトが複雑になるほど、これらのレビューは肯定的ではなくなります。
  5. 大量のカスタム エディター スクリプトを作成します。
    • 短所: 時間がかかります。また、主にゲームを扱っている場合でも、プラットフォームによって提供されるべきもののように思えます。
    • 長所: 動作を完全に制御でき、開発者がデザイナーのフィードバックを得て改善できます。機能要件として実装、テスト、および設計者にとって使いやすいツールを持つことについて規律を守ることは、優れた設計慣行のように聞こえると主張する人もいるかもしれません (結果として、技術的負債が少なくなり、保守が容易になります)。

これが私の個人的な対理想主義的で非現実的な解決策です*：

コンポーネント化されたアーキテクチャを使用します。デフォルトでは、子のプレハブ参照が複雑なプレハブに格納されます。内部的には、モバイル (Cocoa) の UIView とサブビュー、または React のコンポーネント クラスまたはそれ以上の機能コンポーネント (React/Cycle/Elm/FRP と相性の良いもの) と考えてください (はい、これらのアプローチが非常に多くの点で異なることはわかっています。しかし、重要なのは構成可能性であり、機能的構成、デコレータなどによって達成されます...)。

  • 短所：ここでの私の困難は、Unityの経験が不足していることに起因すると思います。より明白で、おそらく慣用的な解決策があります（親切にお願いしています:)）

  • 長所：新しい機能のテストと反復がはるかに簡単になり、プレハブがより強力になり、その利点を失うことはありません（間違っている場合は訂正してください。私はまだ Unity に慣れています）

  • Unity にすべてを期待しているとは思わないでください。ただし、その 1% が真実であっても、それは可能な方向性の 1 つです。

はっきりさせておきますが、これは Unity に関する暴言ではありません。以前にモバイル (ネイティブ) と Web で働いていた開発者として、Unity で解決できる問題の数と、これらのソリューションのいくつかが非常に単純であることに感銘を受けました。

4

1 に答える 1

1

おそらく、複合ビューを別の Scenes に維持するでしょう。これらのシーンは、指定されたクラスの単一のプロトタイプ オブジェクトのみを含むプレハブであると単純に考えてください。

SceneManager.LoadScenewithを使用するとLoadSceneMode.Additive、次のような静的ファクトリ メソッドを作成することもできます。

public class UIStoreView
{
    public static UIStoreView Instance()
    {
        SceneManager.LoadScene("UIStoreView", LoadSceneMode.Additive);
        return GameObject.Find("UIStoreView");
    }
}

いくつかの命名規則を使用すると、次のような単純なものを実現できますstoreView = UIStoreView.Instance();。

普遍的/スケーラブルなものではありませんが、少なくとも、ネストされたプレハブが展開されるまで、軽量/保守可能なものがあります (彼らが言うように、タイムラインは不確実です)。

于 2016-12-05T21:29:31.160 に答える