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

9

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.

Katamaritaco
źródło
7
@gnat - ten post nie jest duplikatem Dlaczego konieczne jest przetestowanie mojej aplikacji na iPhone'a . Rozumiem, że istnieją ogromne różnice między używaniem symulatora a rzeczywistym urządzeniem ...
Katamaritaco

Odpowiedzi:

8

Ś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.


źródło
1
Tak, QA zawsze musi testować w środowisku użytkownika końcowego, a nie w środowisku programistycznym.
17 z 26
Kilka lat temu byłem zaangażowany w projekt polegający na opracowaniu dwóch zupełnie różnych płyt CPU. Inżynier sprzętu, który stworzył płytę, z którą byłem mocno zaangażowany, umieścił na swojej płycie kilka złącz testowych, wykupując ubezpieczenie na fazę debugowania, aby upewnić się, że możemy wszystko zbadać. Wiele marnował na marnowanie nieruchomości i pieniędzy. Drugi facet nie marnował takich pieniędzy i nieruchomości. Zabawne: nigdy nie potrzebowaliśmy złączy na naszej płycie. Zintegrowanie drugiej planszy było podobno koszmarem absolutnym, ponieważ NIC NIE MOGŁO BYĆ PROBIONE. Pomyśl o „ubezpieczeniu”.
John R. Strohm,
@ JohnR.Strohm W przypadku wersji rozwojowej sondowanie jest dobre. Wszystko, co próbuję powiedzieć, jeśli zostało zaprojektowane tak, aby mieć płytę produkcyjną inną niż płytka programistyczna, to trzeba by również ponownie przetestować płytę produkcyjną po sukcesie z płytą programistyczną (i sondować w razie potrzeby).
Ma to sens w przypadku typowego „zestawu deweloperskiego”. Z ciekawości w przypadku iOS każdy iDevice może być używany jako „urządzenie programistyczne”. Jaka może być różnica w przypadku dwóch elementów tego samego sprzętu?
Katamaritaco
1
@Katamaritaco tylko dlatego, że jest to samo urządzenie fizyczne, nie oznacza, że ​​aplikacja ma takie same uprawnienia w systemie iOS. Możliwość wykonywania takich czynności, jak zdalne debugowanie, może zmienić zasoby, do których aplikacja ma dostęp.
5

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.

maniak zapadkowy
źródło
1

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. :)

Robert Harvey
źródło
0

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.

hotpaw2
źródło