Почему устройства для разработки дают вам больше ресурсов, чем обычное устройство?

9

Я создал приложение, которое работает на моем iPod Touch 4-го поколения и iPod Touch 5-го поколения моей компании.

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

Появилась идея, что устройство, зарегистрированное как «устройство разработчика», дает вашему приложению больше ресурсов для использования. Мне это не кажется правильным, так как я не мог придумать ни одной существующей причины - я чувствую, что это скорее проблема с профилированием построения или предоставления.

Однако это вызвало дискуссию. Почему такие устройства, как наборы для разработки игровых приставок, устройства, которые имеют больше возможностей, чем целевая платформа, существуют в первую очередь? Конечно, приятно провести стресс-тестирование программы, но не будет ли более точным представление целевой платформы?

TL; DR. Почему наборы для разработки имеют больше ресурсов, чем целевые платформы?

* С устройством не разработчика, являющимся любым> 3-го поколения. Устройство iOS, которое загружает приложение с нашего сервера, а не напрямую с компьютера с установленным приложением и xcode.

_{Обратите внимание, что есть еще один вопрос, который звучит аналогично, но на самом деле он другой, потому что этот другой вопрос задает вопрос об симуляторе, и я понимаю, что существуют огромные различия между использованием симулятора и реального устройства.}

ios development

— Katamaritaco
источник

7

@gnat - Этот пост не является дубликатом того, почему необходимо протестировать мое приложение для iPhone . Я понимаю, что существуют огромные различия между использованием симулятора и реального устройства ...

— Katamaritaco

8

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

Эти дополнительные вещи требуют дополнительных ресурсов. Открытие удаленного отладчика для виртуальной машины или другой удаленной среды требует некоторых ресурсов на другом конце. В строго ограниченном мире мобильных устройств эти дополнительные ресурсы могут превысить ограничение, предоставленное стандартному приложению. Таким образом, больше ресурсов отводится среде разработки, чтобы она не превысила лимит ресурсов, когда она начнет делать дополнительные записи в журнал или отладку.

Это приводит к тому, что вам всегда нужно что-то тестировать в зеркале производственной среды. Полагать, что он работает на машинах разработчика со всеми его настройками и различными переменными, недостаточно для проверки его правильной работы в производственной среде.

1

Да, QA всегда нужно тестировать в среде конечного пользователя, а не в среде разработки.

— 17 из 26

Несколько лет назад я участвовал в проекте, который должен был разработать две совершенно разные платы процессора. Инженер по аппаратному обеспечению, который занимался созданием платы, с которой я был в большой степени вовлечен, поместил на его плате несколько тестовых разъемов, взяв страховку на фазу отладки, чтобы удостовериться, что мы сможем исследовать что угодно. Он потратил много сил на то, чтобы тратить недвижимость и деньги. Другой парень не тратил такие деньги и недвижимость. Забавно: нам никогда не нужны были разъемы на нашей плате. Интеграция другой платы, по сообщениям, была абсолютным кошмаром, потому что НИЧЕГО НЕ МОЖЕТ БЫТЬ ЗАПРОСЕНО. Подумайте "страхование".

— Джон Р. Штром

@ JohnR.Strohm Для разработки, исследование хорошо. Все, что я пытаюсь сказать, что, если бы он был разработан, чтобы иметь производственную плату, отличную от платы разработки, то также нужно было бы снова протестировать с производственной платой после успеха с разработкой (и пробовать при необходимости).

Это имеет большой смысл для типичного «комплекта разработчика». Из любопытства, в случае iOS любой iDevice можно использовать в качестве «устройства разработчика». Как может быть разница с двумя частями одного и того же оборудования?

— Katamaritaco

1

@ Katamaritaco только потому, что это одно и то же физическое устройство, не означает, что приложение имеет те же разрешения в iOS. Возможность выполнения таких действий, как удаленная отладка, может изменить ресурсы, к которым приложение имеет доступ.

5

Это позволяет вам создать жадное до ресурсов доказательство концепции, которое вы впоследствии сможете оптимизировать.

Не имеет смысла вылетать из-за сбоя приложения, так как его объем памяти превышает 5 байт (что можно решить, установив оптимизатор для экономии места в выпуске, но вы используете отладочную версию),

будет хорошо, если в журнале появится предупреждение, когда вы превысите лимит потребителя во время тестирования.

— чокнутый урод
источник

1

Отчасти это вопрос «доверия». Предполагается, что разработчики знают, что они делают, и поэтому им предоставляется беспрепятственный доступ к устройству и всем его ресурсам. Это может оказать большую помощь небольшим компаниям и командам разработчиков, где неиспользованные ресурсы являются потраченными впустую ресурсами.

В более крупной корпоративной среде, или особенно для широкой публики, такой доступ становится проблемой из-за проблем безопасности и необходимости хорошо играть с другими приложениями, которые также нуждаются в ресурсах.

Это не совсем новая идея. У меня есть две машины на работе. На моей машине разработчика у меня есть административный доступ, но он изолирован от Интернета. Моя другая машина, которую я использую для электронной почты, Office и доступа в Интернет, даже не дает мне возможности устанавливать программы.

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

— Роберт Харви
источник

0

В iOS устройство, включенное для разработки, позволяет вам напрямую запускать сборки отладки, которые могут содержать набор ошибок компиляции, отличных от сборки выпуска, а также запускать приложения под отладочным кусочком, который может незначительно изменять синхронизацию потоков и использование памяти, который также может показать / скрыть различные потоки и ошибки памяти.

Устройство разработки было бы бесполезным без возможности отладки, а пользовательское устройство с возможностью отладки представляло бы (более) серьезную проблему безопасности приложений и приложений.

— hotpaw2
источник