Dlaczego urządzenia programistyczne zapewniają więcej zasobów niż typowe urządzenie?

Stworzyłem aplikację, która działa na moim iPodzie Touch 4. generacji i iPodzie touch 5. generacji mojej firmy.

Już mieliśmy wydać, gdy znaleźliśmy awarię, która występuje po uruchomieniu aplikacji przez urządzenie inne niż programista *.

Pojawiło się pojęcie, że urządzenie zarejestrowane jako „urządzenie programistyczne” daje Twojej aplikacji więcej zasobów do wykorzystania. Nie wydaje mi się to właściwe, ponieważ nie mogłem wymyślić żadnego powodu, który by istniał - wydaje mi się, że jest to bardziej problem z budowaniem lub profilowaniem usług.

To skłoniło jednak do dyskusji. Dlaczego w pierwszej kolejności istnieją urządzenia, takie jak zestawy programistyczne do konsoli do gier, urządzenia o większych możliwościach niż platforma docelowa? Oczywiście miło jest przetestować program, ale czy dokładniejsza reprezentacja platformy docelowej nie miałaby większego sensu?

TL; DR - Dlaczego zestawy programistyczne mają więcej zasobów niż platformy docelowe?

* W przypadku urządzenia, które nie jest programistą, należy do dowolnej> trzeciej generacji. Urządzenie z systemem iOS, które pobiera aplikację z naszego serwera, a nie bezpośrednio z komputera z zainstalowaną aplikacją i kodem xcode.

_{Zauważ, że istnieje inne pytanie, które brzmi podobnie, ale w rzeczywistości jest inne, ponieważ to inne pytanie dotyczy symulatora, i rozumiem, że istnieją ogromne różnice między używaniem symulatora a rzeczywistym urządzeniem.}

Środowisko programistyczne (niezależnie od tego, czy jest to samodzielna aplikacja Java, środowisko mobilne, czy urządzenie wbudowane) zazwyczaj ma możliwość zdalnego debugowania, ulepszonego rejestrowania i innych rodzajów introspekcji środowiska (zwykle nie chce się tego robić) aby dodać wszystkie zaczepy dla analizatora logicznego na wbudowanym urządzeniu produkcyjnym).

Te dodatkowe rzeczy wymagają dodatkowych zasobów. Otwarcie zdalnego debuggera przeciwko vm lub innemu zdalnemu środowisku wymaga trochę zasobów na drugim końcu. W bardzo ograniczonym zakresie urządzeń mobilnych możliwe jest, że te dodatkowe zasoby przekroczą limit przyznany standardowej aplikacji. W ten sposób środowisko programistyczne otrzymuje więcej zasobów, aby nie przekroczyło limitu zasobów, gdy rozpocznie dodatkowe rejestrowanie lub debugowanie.

To idzie dalej do tego, że zawsze musisz przetestować coś w lustrze środowiska produkcyjnego. Zaufanie, że działa na komputerach programistów ze wszystkimi ich poprawkami i różnymi zmiennymi, nie wystarcza do zweryfikowania, czy działa poprawnie w środowisku produkcyjnym.

Pozwala stworzyć chciwą weryfikację koncepcji, którą można później zoptymalizować.

Awaria aplikacji nie ma sensu, ponieważ przekracza 5 bajtów limitu pamięci (co można rozwiązać, ustawiając optymalizator w celu zaoszczędzenia miejsca w wydaniu, ale uruchomiona jest wersja debugująca),

pojawienie się ostrzeżenia w dzienniku, gdy przekroczysz limit konsumenta podczas testowania, będzie tutaj miłe.

Częściowo jest to kwestia „zaufania”. Zakłada się, że programiści wiedzą, co robią, i dlatego mają nieograniczony dostęp do urządzenia i wszystkich jego zasobów. Może to stanowić dużą pomoc dla małych firm i zespołów programistycznych, w których niewykorzystane zasoby są marnowane.

W większym środowisku korporacyjnym, a zwłaszcza wśród ogółu społeczeństwa, ten rodzaj dostępu staje się obowiązkiem ze względu na obawy związane z bezpieczeństwem i potrzebę dobrej zabawy z innymi aplikacjami, które również potrzebują zasobów.

To nie jest tak naprawdę nowy pomysł. Mam dwie maszyny w pracy. Na moim komputerze programisty mam dostęp administracyjny, ale jest on odizolowany od Internetu. Moja druga maszyna, której używam do obsługi poczty e-mail, pakietu Office i dostępu do Internetu, nawet nie daje mi możliwości instalowania programów.

Dlatego przed wdrożeniem musisz przetestować aplikację na urządzeniu innym niż programista, aby upewnić się, że jest dobrze zachowana. :)

W systemie iOS urządzenie obsługujące programowanie pozwala bezpośrednio uruchamiać kompilacje debugowania, które mogą zawierać inny zestaw błędów kompilatora niż kompilacja wydania, a także uruchamiać aplikacje pod węzłem debugowania, które mogą subtelnie zmieniać synchronizację wątków i zużycie pamięci, które mogą również pokazywać / ukrywać różne błędy związane z wątkami i wyciekami pamięci.

Urządzenie programistyczne nie byłoby zbyt przydatne bez możliwości debugowania, a urządzenie użytkownika z funkcją debugowania stanowiłoby (bardziej) poważny problem z bezpieczeństwem danych aplikacji i aplikacji.