Где правильно инициализировать обьекты?
Меня учили, что все переменные и обьекты нужно инициализировать в onCreate() , ну в смысле глобальные (как правило).
Но уже несколько раз встречаю в коде опытных разработчиков когда например листы инициализируются прям там где обьявляются переменные
Не сколько это правильно и ничему ли это не мешает? Например быстродействию программы или еще что то?
Где правильно инициализировать обьекты?
Согласно документации, к инициализации объектов есть только одно требование: Поля и переменные должны быть инициализированны до того как они будут использоваться. Так что ответ будет - в любом месте.
Меня учили, что все переменные и обьекты нужно инициализировать в onCreate().
Я так понимаю что вопрос больше про андроид. OnCreate() - это метод который предназначен для инициализации Activity и он будет вызван как только вы запустите Activity с интентом. Это нормально и общепринято, инициализировать поля в onCreate методе. Я думаю что главная идея сделать инициализацию Activity в onCreate это сократить время старта приложения. Когда ваше приложение запускается, андроид создает экземпляры всех классов (не уверен на счет всех) и если что-то долгое выполняется в конструкторе, то это замедлит старт приложения. Это также относится к выделению памяти для полей класса. Хотя конечно, это мизерное время. Но стоит помннить, что если вы попытаетесь использовать Activity как
тогда, onCreate() метод вызыван не будет.
В общем, касательно вопроса где инициализировать, наиболее распростороненны два способа: - там где переменная объявлена - в конструкторе
оба правильные, я предпочитаю констркторы. В любом случае старайтесь следовать одному стилю.
Для полноты ответа отмечу, что вы также можете инициализировать поля в инициализационном блоке
Можно прострелить ногу при наследовании. Псевдокод:
Если инициализацию перенести в месте объявления (или в нестатическом блоке, или в конструкторе), поведение программы станет более предсказуемым и вариантов сломать базовый класс будет меньше.
Нашел интересную статью, в которой описано пять советов по оптимизации кода.
Совет №1. Всегда, когда возможно, используйте локальные переменные вместо общедоступных полей класса
Ограничивая область видимости переменных, вы не только улучшите читаемость кода и уменьшите число потенциальных ошибок, но и сделаете его лучше подходящим для оптимизации.
В блоке неоптимизированного кода, который показан ниже, значение переменной v вычисляется во время исполнения приложения. Это происходит из-за того, что данная переменная доступна за пределами метода m() и может быть изменена в любом участке кода. Поэтому значение переменной неизвестно на этапе компиляции. Компилятор не знает, изменит ли вызов метода some_global_call() значение этой переменной, или нет, так как переменную v, повторимся, может изменить любой код за пределами метода.
В оптимизированном варианте этого примера v – это локальная переменная. А значит, её значение может быть вычислено на этапе компиляции. Как результат – компилятор может поместить значение переменной в код, который он генерирует, что поможет избежать вычисления значения переменной во время выполнения.
Неоптимизированный код:
Оптимизированный код:
Совет №2. Используйте ключевое слово final для того, чтобы подсказать компилятору то, что значение поля – константа
Ключевое слово final можно использовать для того, чтобы защитить код от случайного изменения переменных, которые должны быть константами. Однако оно позволяет улучшить производительность, так как подсказывает компилятору, что перед ним именно константа.
Во фрагменте неоптимизированного кода значение v*v*v должно вычисляться во время выполнения программы, так как значение v может измениться. В оптимизированном варианте использование ключевого слова final при объявлении переменной и присвоении ей значения, говорит компилятору о том, что значение переменной меняться не будет. Таким образом, вычисление значения можно произвести на этапе компиляции и в выходной код будет добавлено значение, а не команды для его вычисления во время выполнения программы.
Неоптимизированный код:
Оптимизированный код:
Совет №3. Используйте ключевое слово final при объявлении классов и методов
Так как любой метод в Java может оказаться полиморфными, объявление метода или класса с ключевым словом final указывает компилятору на то, что метод не переопределён ни в одном из подклассов.
В неоптимизированном варианте кода перед вызовом функции m() нужно произвести её разрешение. В оптимизированном коде, из-за использования при объявлении метода m() ключевого слова final , компилятор знает, какая именно версия метода будет вызвана. Поэтому он может избежать поиска метода и заменить вызов метода m() его содержимым, встроив его в необходимое место программы. В результате получаем увеличение производительности.
Неоптимизированный код:
Оптимизированный код:
Совет №4. Избегайте вызывать маленькие методы через JNI
Существуют веские причины использования JNI-вызовов. Например, если у вас есть код или библиотеки на C/C++, которые вы хотите повторно использовать в Java-приложениях. Возможно, вы создаёте кросс-платформенное приложение, или ваша цель – увеличение производительности за счет использования низкоуровневых механизмов. Однако, важно свести количество JNI-вызовов к минимуму, так как каждый из них создаёт значительную нагрузку на систему. Когда JNI используют для оптимизации производительности, эта дополнительная нагрузка может свести на нет ожидаемую выгоду. В частности, частые вызовы коротких, не производящих значительной вычислительной работы JNI-методов, способны производительность ухудшить. А если такие вызовы поместить в цикл, то ненужная нагрузка на систему лишь увеличится.
Пример кода:
Совет №5. Используйте стандартные библиотеки вместо реализации той же функциональности в собственном коде