Чому потрібно перевірити додаток iPhone на фактичному пристрої iPhone

Я розробив один додаток для iPhone, і тепер я хочу його в App Store. Так що багато моїх друзів-iek iOS сказали мені перевірити його на фактичному пристрої, тобто на iPhone.

Тож мені цікаво, чому для цього потрібно перевірити додаток iPhone на фактичному пристрої iPhone, хоча вони (Apple) дали "симулятор", який приблизно такий же, як і мій пристрій?

Вам потрібно протестувати додаток на реальному пристрої, щоб принаймні подивитися, як воно поводиться:

• Справжнє обладнання обладнання
• Справжнє підключення до Інтернету (включаючи використання стільникової мережі проти WiFi)
• Ваші пальці замість миші
• Продуктивність з іншими програмами, що працюють у фоновому режимі
• Обмеження iPhone, як-от процесор, ємність диска та пам'ять ( Симулятор - це не емулятор ).
• Справжній контекст: чи легко користуватися додатком у поїзді чи ходити по вулиці? Як щодо яскравого сонячного світла чи під дощем?

Розробники iOS, продовжте цей список.

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

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

Можуть бути й інші речі, які просто недостатньо близькі на тренажері. Наприклад, гучність і баланс звуку - те, як воно звучить на вашому ноутбуці, може відрізнятися від того, яким воно буде на реальному телефоні. Вібрація - це ще один приклад, до якого навряд чи можна підійти з тренажером. Спосіб роботи гіроскопів у реальному телефоні. GPS / місця, пов'язані з місцеположенням. І т. Д. І т. Д. ...

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

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

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

З досвіду та зняття найкращої відповіді:

• Ваші пальці замість миші були найбільшою різницею, коли ми розробили Decimation X2 для Windows Phone 7. Він був закодований на емуляторі, оскільки у нас не було WP7, і це було до виходу WP7. Ми могли б отримати безкоштовну WP7 перед випуском, на випадок, якщо останнє речення для вас не мало сенсу, оскільки нас Microsoft запросив на свій телефон мати назву запуску. Виявилося, що те, що ми хотіли, щоб користувач робив їх пальцями, було дуже важко на реальному телефоні, але легко за допомогою миші. І це було пов'язано з крайніми шафами. На жаль, наша гра вимагала, щоб ваші пальці весь час були біля краю екрану, що деякі телефони зробили важко зробити через затоплений екран, а також товсті корпуси. Ми фактично виставили виправлення, щоб виправити це. Це означає, що всі наші користувачі, які вперше почали показувати себе погано і потенційно непридатні, версія нашої гри. :(

• Наступна найбільша різниця була різною швидкістю обладнання. Нам довелося буквально здогадатися за неточним методом прийняття нашої версії гри Xbox 360 та зменшення її відповідно до половини частоти кадрів (60 кадрів в секунду до 30 кадрів в секунду) і однієї третини ГГц (3,0 ГГц до 1,0 ГГц), і ми здогадалися неправильно. Звичайно, процесори були різними, і ми це знали. Без апаратних засобів ми залишилися кульгавими здогадами. Це був не наш вибір, оскільки у нас не було WP7, але ми засвоїли урок, яким я зараз ділюсь з вами. На деяких телефонах під час найінтенсивніших частин гри вона опускала кадри. :( Начебто ніхто не переймався тим, що вони вважали, що уповільнення придатне для таких інтенсивних частин. Тому це не було великою справою, але справа в тому: якби це було великою справою, "додаток" був би зламаний з наших кульгавих здогадок.

Тест на реальне обладнання. І коли ви кодуєте різні апаратні засоби для телефону, перевіряйте їх на нижньому кінці, якщо продуктивність не є проблемою.

IPhone Simulator реалізує деякі API, яких не має сам iPhone (Основним, що спадає на думку, є DOM XML API, де iPhone підтримує лише SAX, наскільки мені відомо, це могло б змінитися, хоча зараз.)

Це також дозволить вам "відчути" додаток, чи ваші кнопки потрібного розміру? Чи потрапляють правильні кнопки під великий палець? Чи iPhone готовий до запуску програми? Симулятор не є емулятором і працює, просто додавши Cocoa Touch на робочий стіл Mac для цього додатка. Ви повинні імітувати попередження пам'яті тощо.

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

EDIT: Щоразу, коли ви тестуєте додаток на тренажері (або емуляторі), ви використовуєте підроблений пристрій, який за визначенням не може бути 100% точним поданням реального. Емулятор може бути більш точним, ніж симулятор, але відмінності все ж будуть. Єдиний 100% точний емулятор - це сам пристрій.

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

Це може призвести до декількох питань. Серйозні проблеми, такі як помилки, збої, безумовно, є вашим головним пріоритетом. Але є й інші; наприклад, ергономіка. Спробуйте тримати симулятор в руці. Просто спробуйте. Елементи інтерфейсу відображаються на іншому екрані з можливим різним кольоровим відображенням і, безумовно, різними розмірами (проблема, що посилюється красивими дисплеями сітківки, не повністю вирішеною, наприклад, також із використанням сітківки macbook, наприклад). Чи однаково відрізняються ці вишукані відтінки сірого на пристрої на сонці?

Тонкі відмінності у швидкості та різної емуляції датчика (або їх відсутність) іноді можуть суттєво змінити досвід.

Якщо ваша програма покладається на підключення до Інтернету, ви не можете переключитися між LTE, 3G, EDGE або GPRS, протестувати різні сценарії або навіть перевірити різні оператори.

Ви збираєтесь підтримувати встроенні пристрої? Можливо, ви цього не зробите, але якщо є, ви, ймовірно, готові перевірити свій додаток одним із них. Або якщо ви цього не зробите, чи впевнені ви, що виявляєте невміле середовище?

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

Вам було б зручно сісти на літак, яким керував пілот, який ніколи фактично не вийшов із землі?

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

практична причина:

1) У вас немає функцій "надіслати пошту".

2) Не можна ставити пристрій догори дном ..

і звичайно вже сказана причина:

3) низька пропускна здатність

4) дуже мала обчислювальна потужність порівняно з тренажером

5) Відкриті дзвінки GL реалізуються дещо по-іншому в симуляторі

6) місце на диску / ОЗП ..

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

Крім того, є деякі незначні відмінності між програмними та апаратними реалізаціями Open GL ES, наприклад, підказки щодо точності шейдерів можуть мати різний вихід.

Коли ми реалізуємо речі для iOS (або Android, або Windows Phone), ми розробляємо не для робочого столу, а для пристрою. Для деяких програм для обчислення / важких для ресурсів це може означати нормальну поведінку на тренажері, АЛЕ проблеми на фактичному пристрої.

Тож подібні ситуації можуть виникати на пізніших етапах, якщо ми не тестуємо на пристрої спочатку: -

• Попередження / збої пам'яті
• Одноцифрова частота кадрів OpenGL

Є деякі функції, такі як PushNotification , використання камери тощо, які ми можемо протестувати лише на пристрої; це функції, які неможливо перевірити на тренажері.

А тестування вашої програми на фактичному пристрої перед подачею в App Store знижує шанси відхилення програми; іноді додаток працює в симуляторі, але він виходить з ладу на фактичному пристрої, що є основною причиною відхилень додатків.

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

Користувацька робота варіюється в залежності від різних пристроїв та інших пристроїв

технічні характеристики обладнання Отже, потрібно перевірити додаток iPhone на фактичне

пристрої - мобільні пристрої, на яких працюють різні версії iOS на ринку.

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

тестування програми на оригінальному пристрої допоможе у визначенні та вирішенні основних питань

проблеми користувача.