Лучшее Android-кодирование

Question

Что мне нужно, так это лучшее кодирование с такими параметрами, как управление памятью, более быстрая обработка и более чистое кодирование.Есть ли какой-нибудь набор Good Coding Guide для Android, с помощью которого мы можем создавать лучшие приложения.Например:

Какое из следующих соглашений лучше среди них:

ПРИМЕР - 1

TextView tv = (TextView) findViewById(R.id.sampleTextView);
tv.setText("Hello World");

- ИЛИ -

((TextView)  findViewById(R.id.sampleTextView)).setText("Hello World");

ПРИМЕР - 2

BroadcastReceiver br = new BroadcastReceiver() {
      ...
      ...
}

IntentFilter filter = new IntentFilter(...);
registerReceiver(filter, br);

- ИЛИ -

registerReceiver(new IntentFilter(), br);

- ИЛИ -

registerReceiver(new IntentFilter(), new BroadcastReceiver());

, что приведет к меньшему использованию памяти и помощив более быстрой сборке мусора.Я видел оба типа кодирования в Android Framework (как в Gingerbread, так и в Froyo).

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

Answer 1

Об этих видах микрооптимизаций не стоит беспокоиться, если только вы не столкнулись со значительным падением производительности в своем приложении. В любом случае, я бы предположил, что даже возможно, что компилятор сможет вывести этот Пример 1a = Пример 1b. Разница в производительности между ними в лучшем случае составит несколько сотен наносекунд, так как телевизор является эталоном и дешев в перемещении.

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

Answer 2

Спасибо за ответы. После прочтения я думаю, что полностью согласен со всеми вами, особенно с SapphireSun. Видя оба вида кодирования, мне стало интересно, есть ли у inline какие-либо плюсы или минусы по сравнению с другими типами кодирования.

Но, насколько мне кажется, лучше использовать такие объявления, как ((TextView) findViewById (R.id.sampleTextView)). SetText ("Hello World"); вместо того, чтобы выделять его во временную переменную, потому что это увеличит ссылку на объект, который будет собирать мусор, когда отмечен GC. Но с декларацией, как указано выше, я полагаю, что такой объект не будет оставлен для GC.

Пожалуйста, поправьте меня, если я ошибаюсь.

Answer 3

Я согласен со всеми, кто говорит, что этот тип оптимизации не будет делать ничего, что вы можете заметить.

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

В любом случае, перед оптимизацией всегда измеряйте.

Вы не можете оптимизировать то, что не можете измерить

Чтобы узнать, как профилировать ваше приложение, прочитайте это

http://www.jpct.net/wiki/index.php/Profiling_Android_Applications

Answer 4

Оба ваших примера просто ничего не значат в таких аспектах, как управление памятью или процессорное время. Компилятор встроит переменные в обоих примерах. И даже если бы он этого не сделал, это всего лишь одна ссылка на объект. Ни один тест не может показать вам такую ​​разницу.

В таких случаях предпочитают писать читаемый код.

Вы должны быть более обеспокоены преформанностью в тех местах, где она действительно стоит - при работе с базой данных или обработке изображений / видео.

AFAIK, особых рекомендаций для андроида нет. Все они - общие советы по работе с памятью, базами данных, сетью и так далее.

Чтение Эффективная Java от Джошуа Блока, этого будет достаточно.

Answer 5

В обоих приведенных вами примерах нет разницы между различными альтернативами, которые вы упоминаете.

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