Início / coding / Perguntas / 79543477
Accepted
lucidbrot
Asked: 2025-03-29 23:42:59 +0800 CST

Compreendendo os tempos de vida em consultas SystemParam do Bevy

  • 772

No bevy, podemos definir SystemParams personalizados como neste exemplo

/// The [`SystemParam`] struct can contain any types that can also be included in a
/// system function signature.
///
/// In this example, it includes a query and a mutable resource.
#[derive(SystemParam)]
struct PlayerCounter<'w, 's> {
    players: Query<'w, 's, &'static Player>,
    count: ResMut<'w, PlayerCount>,
}

A documentação do SystemParam explica que

Estruturas SystemParam derivadas podem ter dois tempos de vida: 'wpara dados armazenados no Mundo e 'spara dados armazenados no estado do parâmetro.

Considere a &staticvida toda Player...

Eu entenderia isso como "O Player deve existir durante toda a duração em que o programa estiver em execução", mas isso é claramente falso, pois a Querytambém pode ser usado sem nenhuma PlayerEntidade... em vez disso, parece mais que this 'staticlifetime se refere apenas ao tipo em si ter que existir. Mas essas são apenas suposições.

Qual é o significado do &'statictempo de vida Playeraqui e por que/quando ele é necessário?

rust

1 respostas

  1. Best Answer

    O uso de 'statichere é principalmente um espaço reservado. Não significa que Players você passa pela consulta ao vivo para sempre. Isso é específico para Querye não SystemParams como um todo - QueryDatatem mais exemplos com 'static.

    O &'static Playertipo acaba sendo usado como um WorldQuerypelo Querydentro do qual o Items que ele produz é &'w Playeronde 'wé o tempo de vida do mundo. Isso é feito dessa forma porque o QueryDatatraço que o tipo de consulta precisa satisfazer não está vinculado diretamente ao tempo de vida do mundo - ele só obtém esse tempo de vida quando necessário. Você não pode realmente expressar o tempo de vida real do Players que você obteria dessa posição, então 'staticé usado como um espaço reservado.

    Isso também pode ser feito para melhorar a ergonomia do sistema: a vida útil fn update_players(q: Query<&Player>)não precisa estar vinculada a nada específico (mas não tenho certeza se isso foi uma motivação).

    • 1

relate perguntas