Чи має додатки примусового закриття якісь переваги на пристроях iOS?


8

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

Питання в тому, чи примушує закриття додатків (тобто подвійне клацання кнопки додому, а потім переведення їх по екрану) має користь для акумулятора або загальної продуктивності iPhone чи будь-якого іншого пристрою iOS?


1
@Tetsujin Якщо у вас є відповідь, напишіть її нижче, дякую. У коментарях немає можливостей редагувати чи перевіряти "відповідь" як правильну (чи ні).
Роберт Картенто

Відповіді:


6

Навколо цієї теми було багато дискусій та дискусій. Я вважаю, що це було вигідно для iOS ще за версії V3 та V4, але зараз це не так.

Крейг Федерігі навіть нещодавно вийшов, заявивши, що це не потрібно, і це не збільшує час автономної роботи. Apple вбудувала в своє управління пам’яттю належний час, щоб призупинити та / або вбити додаток за потреби. Єдиний раз, коли ви повинні змусити закрити програму, це якщо вона не реагує.


4

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

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

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

  • З точки зору продуктивності - примусове закриття програм робить iOS та додаток гіршими - у багатьох випадках помірно гіршими.
  • Що стосується тривалості роботи акумулятора - сила виходу з програм робить iOS, а термін служби акумулятора також значно гірший .

Подумай про це як про операцію - ти завдаєш явної шкоди за короткий термін, - якщо ти не впевнений, що операція потрібна, не сприймай успішності та не примушуй кидати роботу.


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

@patrix Я не можу говорити про Facebook конкретно, але якщо програма зареєстрована для запуску фонових служб, iOS запускає їх відразу ж після резервного копіювання, тому якщо додаток не кодується та не запускається при автоматичному запуску. Вихід із сили фактично не перешкоджає відновленню фонових ниток / завдань - він просто перериває їх, очищає і потім вони запускаються знову.
bmike

3

Останнім часом ця тема знову є гарячою темою. Я впевнений, що змушувати виходити з програм на пристроях iOS марно. Корисно лише перезапустити програми, коли вони вийшли з ладу. Ось додаткова інформація.

9to5Mac:

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

Раніше на тижні користувач iPhone вирішив надіслати електронний лист генеральному директору Apple Тіму Куку, щоб вирішити проблему спати раз і назавжди, і натомість отримав відповідь від Крейга Федерігі, старшого віце-президента Apple Software Software (через 9to5Mac).

Розмова електронною поштою

 

Ось, з офіційного документа підтримки щодо примушення закриття програм, є власна порада Apple щодо використання цієї функції:

Якщо двічі натиснути кнопку «Головна», з’являться нещодавно використані програми. Програми не відкриваються, але вони знаходяться в режимі очікування, щоб допомогти вам орієнтуватися та робити багатозадачність. Ви повинні змусити програму закриватися лише тоді, коли вона не реагує.

 

MacDailyNews цитує електронний лист 2010 року від Стіва Джобса:

Просто використовуйте [iOS багатозадачність] як задумано, і ви будете раді. Ніколи не потрібно закривати програми.

 

На випадок, якщо ви не вірите старшому віце-президенту Apple із програмного забезпечення, власної офіційної документації Apple, або Стіву Джобсу, ось деякі інші статті, які вказують на те, як ця звичка насправді згубна для акумулятора iPhone:


0

Теоретично так. Програми, що працюють у фоновому режимі, споживають пам'ять (їхні потоки все ще існують, і тому ви можете бачити їх у списку, коли двічі натискаєте кнопку «Головна»), і таким чином вони споживають акумулятор.

Але практично, не дуже. iOS робить досить непогану роботу з управління пам’яттю, а додатки, що працюють на тлі, споживають лише невелику кількість пам’яті. І якщо іншим програмам, що працюють на передньому плані (активно запущені та користувачі взаємодіють з ними), потрібно більше пам’яті, система iOS може припинити фонові програми та очистити пам'ять. Причиною того, що іноді примусове закриття програми дозволяє економити пам’ять / час роботи акумулятора, полягає в тому, що деякі додатки можуть вимагати виконання тривалих завдань, навіть запущених у фоновому режимі, наприклад, для фонового отримання, періодичної синхронізації даних, тощо (зауважте, що не кожен додаток робить це). Але ви можете вимкнути їх, налаштувавши фонове оновлення програми в Налаштуваннях -> Загальне.

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


3
"Програми, що працюють у фоновому режимі, споживають пам'ять (їхні потоки все ще існують, і тому ви можете бачити їх у списку, коли двічі натискаєте кнопку" Головна "), і таким чином вони споживають акумулятор." Це технічно не правильно. Що ви бачите при подвійному натисканні кнопки "Головна" - це знімок (в пам'яті) програми, коли він був закритий. Тільки тому, що ви це бачите, це не означає, що нитки все ще існують. iOS зупиняє додаток від запуску та видаляє його з пам’яті, якщо йому не дозволено запускатись у фоновому режимі І активно обробляє.
fsb

@fbara Я не згоден. За даними документа розробника Apple , програми переходять у стан, який викликається Suspendedнезабаром після переходу до фонового режиму , і "призупинившись, додаток залишається в пам'яті, але не виконує жодного коду". Процес застосування все ще існує, якщо його не припиняють iOS. Якщо у вас є XCode (інструмент для розробників додатків для iOS), ви можете фактично використовувати Debug-> Attach to Process і переглянути список процесів на вашому телефоні, навіть якщо на передньому плані нічого не працює
Stephenye

Цей самий документ також зазначає: "Незабаром після applicationDidEnterBackground:повернення методу делегата програми система робить знімок вікон програми . Аналогічно, коли додаток прокидається для виконання фонових завдань, система може зробити новий знімок, щоб відобразити будь-які відповідні зміни Наприклад, коли програма пробуджує обробку завантажених елементів, система робить новий знімок, який може відображати будь-які зміни, спричинені включенням елементів. Система використовує ці знімки в багатозадачному інтерфейсі, щоб показати стан свого додаток. " Це те, про що я мав на увазі.
fsb

@fbara Це правда: знімки використовуються багатозадачним інтерфейсом, особливо для того, щоб не відображати конфіденційні дані під час введення фону (наприклад, деякі банківські програми). Але я думаю, процес все ще існує. Але давайте не будемо занадто зосереджуватися на технічних деталях, незалежно від того, що він все-таки споживає деяку пам’ять (знімки все ще споживають пам'ять правильно).
Stephenye

-1

Я виявив, що закінчення програми Facebook, зокрема, може врятувати час автономної роботи. Перевіривши його використання в розділі акумулятора (Налаштування> Акумулятор> Час), я не можу не переконатися, що це не дуже добре.


Це тому, що він реєструється як клієнт VoIP, і закриття програми це не змінить.
Ендрю Ларссон
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.