Показать сообщение отдельно
Старый 24.05.2010, 22:12   #1
odd
Мастер
 
Аватар для odd
 
Регистрация: 06.09.2007
Адрес: Донецк, ДНР
Сообщений: 1,023
Написано 298 полезных сообщений
(для 713 пользователей)
Сообщение Общие советы по оптимизации MIDlet Pascal / Java2me программ

Прежде всего определимся с направлениями оптимизации мидлета. Этих направлений несколько:

- оптимизация размера готового приложения (JAR файла)
- оптимизация использования памяти
- оптимизация скорости работы программы
- оптимизация переносимости программы

Кратко опишу основные советы и рекомендации по оптимизации для каждого направления:

1. Оптимизация по размеру
Зачем это нужно? В первую очередь потому, что на некоторых телефонах стоит
ограничение на максимальный размер исполнимого JAR файла, к примеру у некоторых моделей
телефонов Nokia (40 серии) это ограничение равняется 63 или 127 килобайтам. И эти телефоны
отнюдь не пережиток прошлого, они активно продолжают продаваться и распространяться среди
пользователей. И объясняй потом какой-нибудь блондинке, почему ваша мега-супер-пупер крутая
игра, размером в 150 кб, не пошла на её телефоне, который она покупала исключительно по
внешнему виду и низкой цене. К тому же размер важен при загрузке вашей программы из
Интернета, не исключено, что программу будут качать прямо на телефоне через мобильный браузер,
так что размер программы тут выльется в потраченные рубли и драгоценные секунды ожидания
потенциального пользователя вашего шедевра.

Самый простой и самый популярный метод уменьшения размеров программы - использование
обфускаторов. Таких программ много, вот только краткий список: ProGuard, RetroGuard, JODE...
Программы прекрасно справляются с этой функцией, помимо снижения размера повышают и защиту
вашего приложения.

Следующие методы уже потребуют изменения программы вручную.

- избавление от лишних модулей (MIDlet Pascal) или классов (Java2ME). Я понимаю,
что с использованием разветвленной системы классов/модулей программа становится короче и
понятнее. Увы, это отрицательно сказывается как на размерах готового JAR файла, так и занимаемой
оперативной памяти. Поэтому всегда старайтесь объединить несколько классов/модулей в один или
вообще отказаться от их использования. В идеале должен быть всего 1 класс/модуль - главный и всё.

- Совет чисто для MP - откажитесь от использования специальных типов данных (type), лучше храните
все данные в нескольких массивах, чем в одном массиве с особыми типизированными переменными.
Такие типизированные переменные занимают очень много оперативной памяти, да и требуется время
на извлечение определенного параметра из такой типизированной переменной, а это сказывается на
времени работы программы.

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

- удаление ненужных процедур. если у вас есть процедуры, которые выполняют второстепенную работу
(инициализация переменных, отладочный вывод на консоль и проч.) и вызываются только 1 раз - есть
смысл избавиться от них вообще, просто перенеся их непосредственный код на место откуда они вызывались.

- Если вы часто обращаетесь к какой-то переменной из массива есть смысл записать её значение в локальную
переменную и обращаться уже к локальной переменной. Казалось бы какая разница, но локальные переменные
читаются быстрее.

- не делайте инициализацию больших массивов непосредственно в коде программы. Часто оптимальнее будет
хранить значения в текстовом файле, а в коде просто прочитать этот файл и записать прочитанные данные в массив.

- Уменьшение размеров графики за счет программ оптимизации графики (pngout, pgcrush) и режимов сжатия.
При рисовании графики используйте как можно меньшее количество цветов и сохраняйте графику в сжатых форматах:
PNG, JPG, GIF, но не BMP и др.

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

- использовать оптимизированный запаковщик. Не секрет, что JAR файл это обычный ZIP архив, но не многие
знают, что параметрами сжатия можно управлять. Часто сжатие проходит по средним параметрам, обеспечивающим
быструю распаковку, но не самый маленький размер фала после запаковки. Имеет смысл распаковать содержимое
JAR файла и перепаковать его используя более экстремальные параметры сжатия или сторонние архиваторы
(к примеру, архиватор kZip сжимает на 5 - 10 килобайт сильнее, чем обычный Zip)

2. Оптимизация использования памяти

- Используйте как можно меньше переменных, если это возможно, то используйте другие переменные повторно
или временно храните в них какую-то промежуточную информацию

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

- Как можно реже делайте создание/удаление объектов. Старайтесь использовать то что уже есть повторно.

- Правильно объявляйте массивы. Вы удивитесь, но массив [1..2, 1...1000] займет гораздо меньше памяти, чем
массив [1..1000, 1..2]. Просто так происходит из-за выравнивания (alignment) данных в памяти.

- Оптимально читайте ресурсы. Для чего используйте специальные библиотеки типа Lib_resload и прочие.
Прочитав какую-то информацию тут же закрывайте файл. Дело в том, что на некоторых телефонах при чтении
ресурса он сразу весь считывается в оперативную память и занимает её пока вы там что-то читаете построчно
или побайтно из файла. То же относится и к сетевым потокам. Не забывайте их закрывать.

- Учитывайте особенности некоторых телефонов. К примеру, на некоторых телефонах картинки с прозрачностью
занимают памяти намного больше, чем непрозрачные.

3. Оптимизация скорости выполнения программы

- используйте более оптимальные алгоритмы.

- повыбрасывайте из цикла ненужные повторные действия.

- сделайте замеры работы различных процедур и функций, сколько времени выполняется каждая из них.
Может быть стОит обращаться к каким-то функциям или процедурам немножко реже?

- Грамотно перерисовывайте дисплей. Используйте перерисовку когда она действительно нужна.
Если изменилась только какая-то маленькая область, то сделайте перерисовку только этой области, а не
всего дисплея.

- Как можно реже обращайтесь к RMS. Если у вас в Хранилище Записей хранится какая-то важная для
программы информация, то считайте её в переменную, а не обращайтесь каждый раз в RMS, чтобы узнать
её значение.

- Как можно реже читайте ресурсы. Операции с файлами даже если это внутренние ресурсы программ
всегда происходят очень медленно. Лучше сразу считать все ресурсы в переменные в самом начале программы
и больше к ресурсам не обращаться вообще. Также вместо того чтобы открывать/закрывать файл каждый
раз чтобы что-то там прочитать лучше откройте файл один раз, пометьте его начало (mark) и не закрывайте файл.
При последующем обращении к файлу вместо открытия файла просто делайте сброс (reset). Это сэкономит вам
много времени.

- Используйте многопоточность. Если у вас какая-то процедура часто вызывается может имеет смысл перевести
её работу в отдельный поток?

4. Оптимизация переносимости программы
Не секрет, что современный парк уже существующих моделей телефонов очень большой и он растет каждую
неделю. Поэтому чтобы ваша программа одинаково хорошо работала на большинстве телефонов учитывайте
следующее:

- учитывайте то, что у всех телефонов разные размеры дисплеев. Поэтому весь вывод графики и работа
программы должна идти исходя из полученных программно значений высоты и ширины экрана, а не просто
статичных чисел. Пример: FillRect(0, 0, 176, 220) лучше заменить на FillRect(0, 0, GetWidth, GetHeight).

- Используйте рисованные шрифты (Lib_font). Их размер и вид вам уже заранее известен, а при использовании
стандартных шрифтов не известно какой высоты и ширины будет полученная надпись, да и есть ли данный
шрифт в телефоне вообще - на некоторых телефонах есть только 1 шрифт или телефон не имеет поддержки
нужных букв (попробуйте запустить программу с русскими надписями на китайском телефоне, скорее всего
вы увидите непонятные иероглифы вместо ожидаемых букв).

- последнее время появились телефоны с возможностью поворота дисплея сразу во время работы вашей
программы. Это тоже нужно учитывать иначе программа будет работать некорректно при повороте и выводить
графику не на весь дисплей, а только на часть.

- храните все тексты программы в текстовом файле в ресурсах. Если понадобится перевести вашу программу
на другой язык нужно будет только перевести 1 файл, а не переделывать всю программу.
Вложения
Тип файла: zip kzip.zip (13.0 Кб, 763 просмотров)

Последний раз редактировалось odd, 25.05.2010 в 14:16. Причина: дополнения
(Offline)
 
Ответить с цитированием
Эти 15 пользователя(ей) сказали Спасибо odd за это полезное сообщение:
abcdef (27.05.2010), cherepets (24.05.2010), demon112 (31.05.2010), dmitriy-dim (10.09.2010), DUDAKOV.RU (10.02.2011), Fred-boy (10.07.2013), Igor (25.05.2010), leonid (03.11.2011), nil0q (01.09.2011), Phantom (25.05.2010), Rock2roll (29.05.2010), Romanzes (01.06.2010), Trazzy (25.05.2010), ViNT (24.05.2010), Жека (28.05.2010)