10.03fблин, это все интернет, это тоже не поможет

Раз вы так уперлись в память, расскажу ка вам одну историю. Есть у Гугла такая штука как GoogleGoggles. Владельцы Андроид-фонов наверное ею пользовались. Суть ее в том что по фото она определяет что же изображено- картина (название, автор и так далее), текст (и предлагает перевести), историческая достопримечательность (и короткое ее описание). Ну вообщем вы поняли. Открытого АПИ конечно же у него нет. Но можно найти примеры как его реверснули и раскусили. В основном там код на С. Передача данных идет через протокол Протобуфер. Найдете всё сами если интересно.
Так вот, начал я делать реализацию на ж2ми. Методом проб и ошибок было выяснено что сервер принимает исключительно жпег с разрешением 640 на 480. Реализовав отправку и чтение, я прикинул что на телефонах не всегда есть именно такого формата изображения и с таким расширением. Поискав немного, нашел хороший жпг-кодек, который спокойно работал с такими относительно большими размерами фото. Дальше наступил самый интересный момент. Все помнят что размер хип-памяти на телефонах ограничен. На Нокиа к примеру это 2 мегабайта. Итак, мы знаеш что если загрузить картинку размером 320 на 240, она в памяти примерно займет 320*240*4*2 байт. Немало. А теперь пересчитайте сколько будет 640 на 480? А теперь во время ресайза нам надо получить аргб и потом создать новый для заполнения. Опа. А памяти не хватает. Отказаться от всей затеи? Не вариант. Давайте посмотрим что можно сделать. Начнем с перебора всех реализаций ресайза. Везде не хватает памяти. Берем самый быстрый и начинаем экспериментировать. Обнулление изображения и очистка мусора не решают проблему. Выясняем что два массива с ргб, исходный 320 на 240 и 640 на 480 ОДНОВРЕМЕННО не помещаются в память. Варианты? Можно получить первый, записать данные в файлы и потом читать из файла и производить ресайз. Минусы: запросы в фс, геммор с смещением позиции чтения и так далее. Варианты есть? К примеру рмс. В одну РекордСторе можно записать 65535 записей общим размером около 240 кб. Делаем запись и восстановление. Работает, но дико медленно. Еще идеи? Логично сократить количество записей в Сторе. К примеру не попиксельно, а по несколько рядов сразу, к примеру от у=0 до у=100. Реализовываем. Вот. Работает как положено. Не забываем удаление рабочих рмс. В итоге получаем ресайз изображений вплоть до 640 на 480, который в обычных условиях просто выбивал бы программу.
Что я хотел этим сказать. Не ищите проблемы там где их нет. Сборщик мусора может немного вылечить симптомы болезни, но не причину. Большинство проблем с АутОфМемори были связаны с неправильно написаным кодом. Обычно после оптимизации всё начинало прекрасно работать. И будьте внимательны, возможно вы просто забыли где то точку с запятой или запустили рекурсию. Я после многих лет и то могу наступать на такие грабли. И это нормально. Удачи вам в разработке

кирил, попрбуй Math.ceil((10.03-10)*1000) вернет 30.0

Я и хочу сделать так, чтоб потребляло меньше памяти, но не знаю, как это сделать при переходе с класса на класс(

только если так сделать Math.ceil(10.03-10) вернет 1.0

Verlitry, А как ты экраны переключаеш? Вообще то не должна смена содержимого экрана как то сильно влиять на память

Verlitry, Разве класс много потребляет памяти ?

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

еще можно Math.round() но оно оно от 0.29 вернет 0, а от 0.50 - 1. можно было бы как - то отпарсить 10.03 то есть разделить на 10 и 03 потом отнимать целые и дробные

Salat-Cx65, Переключаю с помощью
Main.m.display.setCurrent(new Class());

Magatino, я уже советовал так делать