При кэшировании изображений и данных следует использовать внутреннее или внешнее хранилище?

Это зависит от типа данных, которые вы хотите хранить.

вы упоминаете, что это кэшированные данные, поэтому myassumption заключается в том, что не должно иметь значения, если по какой-то причине все это исчезает. Это заставляет меня поверить, что вы должны использовать getCacheDir(). В этом случае система удалит файлы, если кэш станет слишком большим, поэтому устройства с низким внутренним хранилищем не должны представлять проблемы (хотя рекомендуется управлять этим самостоятельно), это относительно безопасно, и это будет управляется приложением, поэтому, если есть удаление, оно будет удалено.

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

обновлено из комментария:

хотя это конкретный случай, когда это кэш...но я не хочу он будет удален, когда система захочет. Это своего рода тайник. что мне нужно приложение, чтобы решить, когда очистить. Что является главной проблемой хранения в "нормальном" внутреннем хранилище без нахождения в кэше Дира?

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

Если ваши данные имеют большое значение, я бы предложил попытаться определить конкретные данные, которые более важны, и управлять этим отдельно. Если эти данные, которые вы идентифицируете, должны быть безопасными, то внутреннее хранилище с использованием файлов или БД (в зависимости от типа данных) кажется вашим единственным реальным вариантом, но вы должны быть осторожны с этим созданием данных.

обновлено из комментария

что вы думаете об использовании SharedPreferences для сохранения строковых данных? Существует ли ограничение на сохраненный размер строки SharedPreference? Это (хорошо) возможность?

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