Szybka odpowiedź: Resmon to monitor zasobów klienta FiveM. Otwórz konsolę F8 i uruchom resmon true aby sprawdzić koszt zasobów na kliencie. Użyj go, aby znaleźć kosztowne skrypty, mapy, HUD i zasoby UI, zanim zaczniesz zgadywać, co powoduje niskie FPS.
Ostatnia aktualizacja: 25 czerwca 2026
Otwórz Resmon
- Dołącz do swojego serwera.
- Naciśnij
F8. - Uruchom:
resmon trueJeśli dostęp jest zabroniony, dokumentacja Cfx.re informuje, że tryb deweloperski może być wymagany dla niektórych diagnostyk. Przetestuj na kliencie deweloperskim lub użyj profilera do głębszego debugowania.
Co mówi Ci Resmon
| Kolumna/sygnał | Znaczenie |
|---|---|
| CPU msec | Ile czasu procesora klienta zużywa zasób. |
| Pamięć | Ile pamięci zasób zużywa na kliencie. |
| Skoki | Krótkie impulsy, które mogą wystąpić podczas UI, streamingu lub pętli. |
| Stały wysoki koszt | Zasób, który prawdopodobnie wymaga pracy nad kodem lub zasobami. |
Praktyczna metoda testowania
- Stań w cichym miejscu i zanotuj najdroższe zasoby.
- Przejdź do ruchliwego obszaru miasta, MLO lub miejsca z dużą liczbą pojazdów.
- Otwieraj menu, ekwipunek, telefon, HUD i zadania UI pojedynczo.
- Zanotuj, który zasób skacze i jaka akcja go spowodowała.
- Wyłącz jeden podejrzany zasób w środowisku testowym i powtórz ten sam test.
Kiedy używać profilera
Użyj Resmon do szybkiej oceny. Użyj profilera Cfx.re, gdy potrzebujesz debugowania na poziomie linii lub głębszego debugowania zasobów. Profiler jest lepszy, gdy zasób jest stale kosztowny, ale przyczyna nie jest oczywista z rozgrywki.
Typowe przyczyny wysokich wartości Resmon
- Pętle bez wystarczającej ilości
Wait()czasu. - Skrypty NUI aktualizujące każdą klatkę.
- Duże mapy lub paczki ubrań w pobliżu gęsto zaludnionych obszarów.
- HUDs sprawdzające zbyt wiele stanów graczy zbyt często.
- Zdarzenia klienckie wykonujące pracę serwerową.
Powiązane przewodniki optymalizacji
- Optymalizacja serwera FiveM
- Jak wyświetlić FPS w FiveM
- Napraw ostrzeżenia o zacięciach wątków FiveM
- Oficjalny przewodnik po profilerze Cfx.re
Jak odczytywać Resmon bez nadmiernej reakcji
Krótki skok nie zawsze jest błędem. Otwarcie telefonu, ekwipunku, menu ubrań lub mapy może chwilowo zwiększyć użycie CPU. Problemem jest zasób, który pozostaje kosztowny w stanie bezczynności lub skacze co kilka sekund podczas normalnej gry.
Przydatne uwagi dotyczące testowania
- Testuj tę samą trasę przez miasto za każdym razem.
- Zapisz trzy najbardziej obciążające zasoby przed zmianą czegokolwiek.
- Wyłącz jeden podejrzany zasób na raz.
- Przetestuj ponownie po pełnym restarcie, nie tylko po gorącym przeładowaniu.
- Sprawdź zarówno niską liczbę graczy, jak i wysoką liczbę graczy.
Poprawki programistyczne, które zwykle działają
Zwiększ oczekiwania w pętlach, unikaj stałych aktualizacji NUI, cache'uj powtarzane wyszukiwania, przenieś pracę tylko serwerową z kodu klienckiego i przestań sprawdzać każdy stan gracza w każdej klatce. Jeśli skrypt musi reagować na zdarzenia, używaj zdarzeń zamiast odpytywania, gdy to możliwe.
Jak zdecydować, co naprawić najpierw
Nie usuwaj przypadkowych zasobów tylko dlatego, że jedna liczba przez chwilę wygląda na wysoką. Najpierw przetestuj tę samą trasę przez miasto, zapisz trzy najbardziej obciążające zasoby, a następnie zmieniaj jedną rzecz na raz. Telefon, ekwipunek lub menu ubrań mogą skakać tylko podczas otwarcia; to różni się od skryptu, który pozostaje kosztowny, gdy gracz jest bezczynny.
Typowe poprawki, które deweloperzy powinni sprawdzić
- Zwiększ opóźnienia w pętlach, które nie wymagają sprawdzania co klatkę.
- Zachowuj wyniki wielokrotnych wyszukiwań graczy, pojazdów lub jednostek.
- Zmniejsz liczbę stałych komunikatów NUI pochodzących z zasobów HUD i telefonów.
- Przenieś walidację serwerową poza pętle klienckie.
- Używaj zdarzeń, gdy sondowanie jest tylko wygodą.
Czego Resmon nie może udowodnić
Resmon działa po stronie klienta. Pomaga zidentyfikować zasoby obciążające czas klatki gracza, ale nie zastępuje logów serwera, profilowania bazy danych ani monitorowania txAdmin. Zasób może wyglądać na tani po stronie klienta, a mimo to generować obciążenie bazy danych po stronie serwera. Używaj Resmona dla odczuć klienta, a narzędzi serwerowych do problemów backendowych.
Notatki przed i po
Zrób zrzut ekranu lub zapisz wartości msec przed zmianą kodu. Po każdej poprawce przetestuj tę samą trasę z tą samą liczbą graczy, jeśli to możliwe. Bez powtarzalnego testu optymalizacja staje się zgadywaniem.
Gdy problem występuje sporadycznie, zapisz czas, liczbę graczy i lokalizację. Pomoże to porównać dane z Resmona z logami txAdmin i ostatnimi zmianami w zasobach.
Dla zespołów współdzielonych prowadź jeden krótki dziennik wydajności, aby deweloperzy widzieli, co zmieniło się przed pojawieniem się skoku.
Dobre notatki przyspieszają optymalizację szybciej niż zgadywanie.
Ułatwiają także wycofanie dokładnej aktualizacji zasobu, która spowodowała regresję.
Prowadź notatki na tyle krótkie, aby personel rzeczywiście z nich korzystał.