Давайте разберем ваши заявленные недостатки:
- Когда приложение запускается в первый раз, оно будет очень медленным, потому что байт-коды будут интерпретироваться, а JIT-компилятор выполнит много анализа, чтобы найти хорошие оптимизации. Приложения не могут использовать максимум мощности оборудования.
JIT-компиляция является проблемой реализации. Не все платформы делают это. Действительно, платформу Android можно было бы изменить на 1) выполнять предварительную компиляцию или 2) кэшировать собственный код, созданный JIT, чтобы ускорить запуск при следующем запуске приложения.
Интересно, что различные поставщики Java пробовали эти стратегии в разное время, и все же эмпирические данные свидетельствуют о том, что простой JIT является лучшей стратегией.
- Java проверяет, не выходит ли индекс массива за пределы, и проверяет, не являются ли указатели нулевыми. Это добавит несколько внутренних «если» к сгенерированному коду.
JIT-компилятор может оптимизировать многие из этих тестов. В остальном накладные расходы имеют тенденцию быть относительно небольшими; например разница в несколько процентов ... не в 2 раза.
Обратите внимание, что альтернативой проверке является риск того, что типичные ошибки приложения могут привести к сбою платформы Android. Конечно, сборка мусора становится проблематичной, если приложения могут загружать память.
- Все объекты используют сборщик мусора, включая объекты, которые очень легко удалить вручную.
Обратной стороной является то, что легко забыть удалить объекты, удалить объекты дважды, использовать их после того, как они были удалены, и так далее. Все эти ошибки приводят к ошибкам, которые трудно отследить.
- Все экземпляры объектов создаются с динамическим распределением памяти, включая объекты, которые могут легко использовать стек. Если итерация цикла начинает создавать экземпляр класса и завершает удаление созданного объекта, динамическое распределение памяти будет неэффективным.
Динамическое выделение памяти Java и создание объектов - БЫСТРО. Например, быстрее, чем в C ++.
- Сборщик мусора должен остановить приложение, пока он очищает память, и это очень нежелательно для игр, приложений с графическим интерфейсом и приложений в реальном времени.
Тогда используйте параллельный сборщик мусора с низкой паузой. Другой подход заключается в том, чтобы ваше приложение не создавало много мусора ... и редко запускало сборку мусора.
- Подсчет ссылок идет медленно и не может обрабатывать циклические ссылки.
Нет достойного Java GC использует подсчет ссылок. (С другой стороны, многие схемы управления памятью на C / C ++ подходят. Например, так называемые схемы интеллектуальных указателей в C ++.)
- Многопоточный сборщик мусора работает медленнее и требует большего использования процессора.
Вы на самом деле имеете в виду одновременную коллекцию, я думаю. Да, это так, но это штраф, который вы платите за дополнительную отзывчивость, которую вы требуете для интерактивных игр / приложений реального времени.