В чем разница между commit () и apply () в SharedPreferences

Я использую SharedPreferencesв моем приложении для Android. Я использую оба commit()и apply()метод из общих предпочтений. Когда я использую AVD 2.3, это не показывает ошибку, но когда я запускаю код в AVD 2.1, apply()метод показывает ошибку.

Так в чем же разница между этими двумя? И с помощью только commit()я могу сохранить значение предпочтения без каких-либо проблем?

apply()был добавлен в 2.3, он фиксирует без возврата логического значения, указывающего на успех или неудачу.

commit()возвращает true, если сохранение работает, иначе false .

apply() была добавлена, так как команда разработчиков Android заметила, что почти никто не обратил внимания на возвращаемое значение, поэтому применять быстрее, поскольку оно асинхронно.

http://developer.android.com/reference/android/content/SharedPreferences.Editor.html#apply ()

ТЛ; др:

• commit()записывает данные синхронно (блокируя поток, из которого они вызваны). Затем он информирует вас об успехе операции.
• apply()планирует данные для записи асинхронно . Он не информирует вас об успешности операции.
• Если вы сохраните apply()и сразу прочитаете с помощью любого метода getX, новое значение будет возвращено!
• Если вы позвонили apply()в какой-то момент и он все еще выполняется, любые вызовы commit()блокируются до тех пор, пока не завершатся все прошлые вызовы apply и текущий commit-вызов.

Более подробная информация из документации SharedPreferences.Editor :

В отличие от commit (), который синхронно записывает свои предпочтения в постоянное хранилище , apply () немедленно фиксирует свои изменения в SharedPreferences в памяти, но запускает асинхронную фиксацию на диск, и вы не будете уведомлены о каких-либо сбоях . Если другой редактор в этой SharedPreferences выполняет обычную commit (), а apply () еще не выполнено, commit () будет блокироваться до тех пор, пока не будут выполнены все асинхронные коммиты, а также сам коммит.

Поскольку экземпляры SharedPreferences являются одиночными внутри процесса, любой экземпляр commit () можно безопасно заменить на apply (), если вы уже игнорировали возвращаемое значение.

Ожидается, что интерфейс SharedPreferences.Editor не будет реализован напрямую. Однако, если вы ранее реализовали это и теперь получаете ошибки об отсутствии apply (), вы можете просто вызвать commit () из apply ().

У меня возникают некоторые проблемы с использованием apply () вместо commit (). Как указано ранее в других ответах, apply () является асинхронным. Я получаю проблему, что изменения, сформированные в предпочтении "набора строк", никогда не записываются в постоянную память.

Это происходит, если вы «принудительно задерживаете» программу или в ПЗУ, которое я установил на моем устройстве с Android 4.1, когда процесс прерывается системой из-за необходимости в памяти.

Я рекомендую использовать «commit ()» вместо «apply ()», если вы хотите, чтобы ваши настройки были активными.

Используйте apply ().

Он немедленно записывает изменения в ОЗУ, а затем ожидает и записывает их во внутреннее хранилище (файл фактических настроек). Коммит записывает изменения синхронно и напрямую в файл.

• commit()синхронно, apply()асинхронно

• apply() является пустой функцией.

• commit() возвращает true, если новые значения были успешно записаны в постоянное хранилище.

• apply() перед переключением состояний гарантия завершена, вам не нужно беспокоиться о жизненных циклах компонентов Android

Если вы не используете значение, возвращаемое из, commit()и используете commit()из основного потока, используйте apply()вместо commit()

Документы дают довольно хорошее объяснение разницы между apply()и commit():

В отличие от этого commit(), который записывает свои предпочтения в постоянное хранилище синхронно, немедленно apply()фиксирует свои изменения в оперативной памяти, SharedPreferencesно запускает асинхронную фиксацию на диск, и вы не будете уведомлены о каких-либо сбоях. Если другой редактор SharedPreferencesделает это регулярно, в commit()то время как a apply()все еще не выполнено, он commit()будет блокироваться до тех пор, пока не будут выполнены все асинхронные коммиты, а также сам коммит. Как SharedPreferencesэкземпляры одноэлементны внутри процесса, это безопасно заменить любой экземпляр commit()с , apply()если вы уже не обращая внимания на возвращаемое значение.

Из Javadoc:

В отличие от commit (), который синхронно записывает свои предпочтения в постоянное хранилище, apply () немедленно фиксирует свои изменения в SharedPreferences в памяти, но запускает асинхронную фиксацию на диск, и вы не будете уведомлены о каких-либо сбоях. Если другой редактор в этой SharedPreferences выполняет обычную commit (), в то время как a> apply () все еще не завершен, commit () будет блокироваться до тех пор, пока не будут выполнены все асинхронные коммиты, а также сам коммит

Разница между commit () и apply ()

Мы можем быть смущены этими двумя терминами, когда мы используем SharedPreference. В основном они, вероятно, одинаковы, поэтому давайте выясним различия в commit () и apply ().

1. Возврат стоимости:

apply()фиксирует без возврата логического значения, указывающего на успех или неудачу. commit() возвращает true, если сохранение работает, иначе false.

2. Скорость:

apply()быстрее. commit()медленнее.

3. Асинхронный против Синхронного:

apply(): Асинхронный commit(): синхронный

4. Atomic:

apply(): атомная commit(): атомная

5. Уведомление об ошибке:

apply(): Нет commit(): да