Чому пристрої для розробки дають більше ресурсів, ніж типові пристрої?

Я створив додаток, який працює на моєму iPod Touch 4-го покоління та iPod touch моєї компанії 5-го покоління.

Ми збиралися випустити, коли ми виявили збій, який виникає після того, як будь-який пристрій, який не розробник запускає додаток *.

З'явилося, що пристрій, зареєстрований як "пристрій розробника", дає додатку більше ресурсів для використання. Мені це не здається правильним, оскільки я не міг придумати будь-якої причини, яка існувала б - я вважаю, що це скоріше проблема зі складанням профілю чи надання послуг.

Однак це спонукало до дискусії. Чому в першу чергу існують такі пристрої, як набори для розвитку ігрової консолі, пристрої, які мають більше можливостей, ніж цільова платформа? Звичайно, приємно підкреслити тест на програму, але хіба більш точне представлення цільової платформи не має сенсу?

TL; DR - Чому набори для розробки мають більше ресурсів, ніж цільові платформи?

* Якщо будь-який пристрій, який не розробляє, будь-який> 3-й рід. Пристрій iOS, який завантажує додаток з нашого сервера, а не безпосередньо з комп’ютера, на якому встановлено додаток & xcode.

_{Зауважимо, є ще одне запитання, яке читає подібне, але воно насправді інше, тому що це інше запитання про симулятор, і я розумію, що між використанням тренажера та фактичним пристроєм існують великі відмінності.}

Середовище розробки (будь-що - будь то окремий додаток java, або мобільне середовище, або вбудований пристрій), як правило, має можливість робити віддалену налагодження, покращену реєстрацію та інші типи самоаналізу навколишнього середовища (типово не хочеться додати всі гачки для логічного аналізатора на виробничому вбудованому пристрої).

Ці додаткові речі потребують додаткових ресурсів. Відкриття віддаленого налагоджувача проти vm чи іншого віддаленого оточення потребує деяких ресурсів на іншому кінці. У жорстко обмеженій царині мобільних можливо, що ці додаткові ресурси переведуть її за ліміт, який надається стандартній програмі. Таким чином, більше середовищ надається середовищу розробки, щоб воно не досягало обмеження ресурсу, коли воно починає робити додаткові реєстрації чи налагодження.

Це йде далі до того, що завжди потрібно щось тестувати в дзеркалі виробничого середовища. Довіряючи, що він працює на машинах розробника з усіма їх перетвореннями та різними змінними, недостатньо, щоб переконатися, що він працює правильно у виробництві.

Це дозволяє створити жадібний до ресурсу концепт, який ви згодом можете оптимізувати.

Немає сенсу збивати додаток, оскільки це 5 байт за ліміт пам’яті (що можна вирішити, встановивши оптимізатор, щоб заощадити простір у випуску, але ви використовуєте версію налагодження),

наявність попередження у журналі, коли ви переходите ліміт споживачів під час тестування, тут буде приємно.

Частково це питання "довіри". Передбачається, що розробники знають, що вони роблять, і тому їм надається безперешкодний доступ до пристрою та всіх його ресурсів. Це може бути великою допомогою маленьким компаніям та командам девелопменту, де невикористані ресурси є марними ресурсами.

У більш широкому корпоративному середовищі, або особливо широкій громадськості, такий доступ стає відповідальністю через проблеми безпеки та необхідність добре грати з іншими програмами, які також потребують ресурсів.

Це насправді не нова ідея. У мене дві машини на роботі. На своїй машині розробника у мене є адміністративний доступ, але він ізольований від Інтернету. Мій інший апарат, який я використовую для електронної пошти, офісу та доступу до Інтернету, навіть не дає мені можливості встановлювати програми.

Ось чому вам доведеться протестувати свою програму на пристрої, який не розробник, перш ніж розгорнути її, щоб переконатися, що вона справна. :)

За допомогою iOS пристрій, увімкнутий для розробки, дозволяє безпосередньо запускати збірки налагодження, які можуть містити інший набір помилок компілятора, ніж збірка випуску, а також запускати програми під налагодженням налагодження, що може тонко змінювати терміни потоку та використання пам'яті, які також можуть показувати / приховувати різні помилки з потоком та протіканням пам’яті.

Пристрій розробки не мав би великої користі без налагодження, а користувальницький пристрій з можливістю налагодження представляв би (більш) серйозну проблему безпеки даних програм та додатків.