Jak rozpoznać wolne urządzenia w mojej witrynie?

Podczas dostosowywania strony internetowej do urządzeń mobilnych zawsze polegam na zapytaniach mediów css.

Ostatnio nie martwię się już tylko o rozmiar ekranu, ale także silnik javascript wielu urządzeń mobilnych. Niektóre popularne efekty javascript, które polegają na przewijaniu okien lub szybkiej sekwencji transformacji DOM, działają naprawdę źle na wolnych urządzeniach.

Czy istnieje sposób odgadnięcia wydajności urządzenia, dzięki czemu mogę włączyć / wyłączyć elementy, które wyglądają źle na wolnych urządzeniach?

Do tej pory mogę myśleć tylko o złych rozwiązaniach:

rozmiar ekranu. wąski ekran „może” oznacza wolne urządzenieinformacje o agencie użytkownika. Mogę spojrzeć na urządzenie, przeglądarkę lub procesor, ale nie wydaje się to stabilnym rozwiązaniem długoterminowym ze względu na ilość urządzeń do rozważenia

AKTUALIZACJA: Naprawiono moje pytanie, aby skupić się na jednym problemie. W komentarzach jest dobre rozwiązanie problemu z interfejsem dotykowym.

 Gregor15 wrz 2012, 14:56
Co sądzisz o podejściu odwrotnym: znajdowanie szybkich przeglądarek i włączanie do nich efektów - można to zrobić za pomocą zapytania o agenta użytkownika w Webkit, Firefox i najnowszych Internet Explorers.
 SystematicFrank15 wrz 2012, 14:59
@ gabe Wyłączę niektóre elementy. Na przykład te dynamiczne paski nawigacyjne, które pojawiają się po przewinięciu obok nagłówka, wyglądają okropnie. Również galerie obrazów z animowanymi przejściami nie są płynne, wyłączę przejście obrazu.
 Matt Whipple15 wrz 2012, 15:19
Obejmuje to kwestię zawisu:stackoverflow.com/questions/4643443/…
 Gabe15 wrz 2012, 14:54
Co zrobisz inaczej, jeśli przeglądarka będzie zbyt wolna?
 Basic15 wrz 2012, 15:11
Możesz wykonać niektóre operacje DOM i czas je. Wiem, że nie jest doskonały i trzeba się upewnić, że nie wpłynie to nadmiernie na stronę, ale może dać dość dokładne wyobrażenie o szybkości klienta podczas manipulowania elementami
 SystematicFrank15 wrz 2012, 15:11
@ gabe Zaktualizowałem pytanie, aby było bardziej ogólne. Spójrz na sekcję AKTUALIZACJA. Twój pomysł na odwrotne podejście jest dziś dobry, ale w przyszłości pojawi się połączenie wolnych i strasznie szybkich urządzeń mobilnych. Dlatego nie wydaje się to dobrym, stabilnym rozwiązaniem długoterminowym.
 Basic15 wrz 2012, 15:09
Tylko obserwacja, ale natywna przeglądarka Android może wykonywać zdarzenia na zawisie. Wygląda na to, że ma koncepcję niewidzialnego kursora myszy, który jest umieszczony w ostatnim miejscu dotknięcia - więc najechanie kursorem można symulować, dotykając małym przeciągnięciem, aby zapobiec kliknięciu. Nie jest idealny i na pewno nie jest powszechnie wspierany, ale warty poznania

questionAnswers(3)

QuestionSolution

że nie ma szczególnie dobrego rozwiązania tego problemu (co miałoby sens, ponieważ zwykle tego typu rzeczy są typem rzeczy ukrytych). Myślę, że najlepiej, jeśli zaczniesz od wykrywania UA, aby zająć się tymi platformami, o których wiadomo, że należą do jednej lub innej kategorii. Wtedy będziesz miał 2 opcje elastycznego dostosowania się do nieznanych / niepewnych platform:

Progresywne ulepszanie: Rozpocznij od zubożonego testu i załaduj mały test wydajności lub testy, aby ocenić wydajność urządzenia, a następnie załaduj pliki dla odpowiednich ulepszeń. Test taki jak już dostarczony lub pod adresem:Pomiń kod, jeśli komputer działa wolno

Wdzięczna degradacja: Zawij te funkcje, które są kandydatami do powodowania niekorzystnego UX na wolniejszych urządzeniach, w funkcji wyższego rzędu, która zastępuje je, jeśli trwają zbyt długo przy pierwszym uruchomieniu. W tym przypadku prawdopodobnie dodam to doFunction.prototype a następnie pozwól, aby akceptowalny argument opóźnienia był powiązany z definicją funkcji. Po pierwszym przechowywaniu wywołań upłynął czas, a następnie przy drugim wywołaniu, jeśli upłynął czas opóźnienia, należy zamienić funkcję na rezerwową. Jeśli czas, który upłynął, jest akceptowalny, usuń kod profilowania, zamieniając funkcję standardową. Muszę usiąść i opracować przykładowy kod (może w ten weekend). Można to również dostosować za pomocą dodatkowych argumentów, takich jak profil wielokrotny przed zamianą.

Pierwsza opcja byłaby prawdopodobnie bardziej przyjazna, ale druga może być mniej inwazyjna dla istniejącego kodu. Pliki cookie lub zbieranie dalszych danych UA również pomogłyby kontynuować profilowanie po odzyskaniu informacji.

 SystematicFrank18 wrz 2012, 09:30
Podoba mi się pomysł pełnej wdzięku degradacji, ponieważ uważam, że sam „ciężki” widget może być testem prędkości. Zapytałem o wykrycie wolnych urządzeń, gdy naprawdę chciałem wykryć, czy jakiś widget działa zbyt wolno na kliencie. Problem z innymi rozwiązaniami do testowania prędkości polega na tym, że po uzyskaniu wyniku numerycznego należy znaleźć próg akceptowalnego lub nieakceptowalnego.
 Matt Whipple18 wrz 2012, 14:34
Byłby to jeden z minusów, w zależności od tego, jakie ulepszenia interfejsu użytkownika (i od tego, co zostało wywołane przez pierwszy), nie może być żadnego zauważalnego skoku. Powiedziałbym po prostu, że dodam wiadomość, która krótko przejdzie od góry lub od dołu, mówiąc coś w rodzaju „optymalizacja ustawień urządzenia”, aby użytkownik wiedział, że jest to funkcja, a nie jeden lub więcej błędów.
 SystematicFrank18 wrz 2012, 14:23
nie martwię się, mam bardzo jasne, jak to wdrożyć. Dla mnie jest to skomplikowany szczegół każdego przypadku i jak zareagować wystarczająco szybko, w przeciwnym razie użytkownik musi doświadczyć przynajmniej raz usterki interfejsu użytkownika
 Matt Whipple18 wrz 2012, 14:16
Gdybyś chciał przykład kodu, mógłbym napisać coś dzisiaj.

Jedynym sposobem, w jaki mogłem pomyśleć, byłoby przeprowadzenie pewnego rodzaju testu prędkości w JS w tle przed lub podczas używania efektów. Powinno to wychwytywać urządzenia, które są wolne ze względu na szybkość procesora lub odwrotnie, urządzenia przechwytujące, które są dokładne / szybkie. Jeśli jednak urządzenia mają optymalizację, co oznacza, że ​​używają różnych procesorów do obliczania efektów graficznych, to nie zadziała.

var speedtest = function(){
  /// record when we start
  var target = new Date().getTime(), count = 0, slow = 0;
  /// trigger a set interval to keep a constant eye on things
  var iid = setInterval(function(){
    /// get where we actually are in time
    var actual = new Date().getTime();
    /// calculate where we expect time to be
    target += 100;
    /// 100 value here would need to be tested to find the best sensitivity
    if ( (actual - target) > 100 ) {
      /// make sure we aren't firing on a one off slow down, wait until this
      /// has happened a few times in a row. 5 could be too much / too little.
      if ( (++slow) > 5 ) {
        /// finally if we are slow, stop the interval
        clearInterval(iid);
        /// and disable our fancy resource-hogging things
        turnOffFancyAnimations();
      }
    }
    else if ( slow > 0 ){
      /// decrease slow each time we pass a speedtest
      slow--;
    }
    /// update target to take into account browsers not being exactly accurate
    target = actual;
    /// use interval of 100, any lower than this might be unreliable
  },100);
}

Oczywiście uruchamiając to, wpłyniesz również na szybkość urządzenia, więc nie jest to najlepsze rozwiązanie. Z reguły wyłączam animacje i inne zbędne rzeczy po prostu, gdy ekran jest mały.

Inną wadą tej metody - której doświadczyłem wcześniej - jest to, że niektóre przeglądarki, które implementują środowiska z wieloma kartami setIntervals, są automatycznie ograniczane do określonej prędkości, gdy karta nie jest wyświetlana. Oznaczałoby to, że przeglądanie stron w przeglądarkach automatycznie obniżyłoby ich doświadczenie - o ile ta narzucona prędkość nie mogłaby zostać wykryta w jakiś sposób.

 Pebbl15 wrz 2012, 20:35
Tak, nie martw się, sam nie używałbym tego podejścia w produkcji, po prostu lubię eksperymentować z JS. Z drugiej strony zawsze masz alternatywę ... Możesz zapytać użytkownika, a przynajmniej ujawnić pewien rodzaj kontroli, który pozwoli im wyłączyć fantazyjne części, jeśli ich nie chcą. Znam wielu użytkowników, którzy chcieliby wyłączyć graficzne dodatki, nawet podczas oglądania na komputerze.
 SystematicFrank15 wrz 2012, 15:51
Podoba mi się twój kod, ale jak powiedziałeś, ma pewne wady. Nie jestem też przekonany do stosowania testów prędkości jako dobrego podejścia do projektowania. Z drugiej strony wygląda na to, że nie ma czegoś takiego jak dobre rozwiązanie :(

Możesz stworzyć swój własny mini benchmark. Wykonaj wymagające obliczenia i czas na wynik. Jeśli jest wolniejszy niż urządzenie, które uważasz za najwolniejsze obsługiwane urządzenie, przejdź do mniej intensywnej wersji witryny.

Można również po prostu udostępnić łatwo dostępny link, aby przejść do bardziej podstawowej witryny, jeśli użytkownik doświadcza problemów z wydajnością.

Wyłączenie rozmiaru ekranu nie jest dobrym pomysłem. Wiele nowoczesnych telefonów ma małe ekrany z szybkimi procesorami.

 Pebbl15 wrz 2012, 20:39
Imo w rozmiarze ekranu jest akceptowalne, jeśli wszystko, co robisz, to zgrabna degradacja zbędnych zbędnych „magii” :) - ale tak, za cokolwiek innego utrudnisz użytkownikom korzystanie z telefonu i tabletów z czasem.

yourAnswerToTheQuestion