Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 18
«скрутытх»
Мне бы статья очень понравилась, если бы вместо пучка ютубов был пучок текстовых статей. Искренне не понимаю, как можно тратить пол дня на просмотр видюшек, когда всю ту же информацию можно было прочитать за пол часа. Или я просто читаю быстрее, чем смотрю…
Мне бы статья очень понравилась, если бы вместо пучка ютубов был пучок текстовых статей. Искренне не понимаю, как можно тратить пол дня на просмотр видюшек, когда всю ту же информацию можно было прочитать за пол часа. Или я просто читаю быстрее, чем смотрю…
Вы знаете, я с Вами полностью согласен. Для нас, для кого английский не родной, текстовая информация воспринимается гораздо быстрее и лучше. А главное, всегда можно вернуться и посмотреть еще раз.
Но, увы, Google выкладывает свои Best practices в виде видео. И мне пришлось потратить гораздо больше, чем полня, на просмотр, учитывая, что у некоторых спикеров тяжкое произношение)
Поэтому собственно и появилась идея сделать набор кратких тезисов. И если читатель заинтересуется и захочет более глубоко понять тему, он сможет сам просмотреть указанные ссылки)
Но, увы, Google выкладывает свои Best practices в виде видео. И мне пришлось потратить гораздо больше, чем полня, на просмотр, учитывая, что у некоторых спикеров тяжкое произношение)
Поэтому собственно и появилась идея сделать набор кратких тезисов. И если читатель заинтересуется и захочет более глубоко понять тему, он сможет сам просмотреть указанные ссылки)
Да это не совсем к вам претензия, а ко всем этим спикерам. Каждый второй бежит делать канальчик на ютубе, насмотревшись на примеры Гуглов и прочих. С ужасом жду того дня, когда документация по Google API и MSDN будет в виде видеороликов. Маркетологи портят мой интернет.) Ролики нужны для презентаций и демонстраций. Всё, точка. А когда начинающие программисты ищут видеоуроки по С++, у меня аж где-то что-то сжимается и начинает пригорать…
1. Использование hardware accelaration. Позволяет улучшить плавность ui, анимации за счет предарительной отрисовки и хранения этих отрисовок в памяти (вместо динамической постоянной отрисовки и перерисовки)
Так и не разобрался как включается это ускорение. Обычная View.isHardwareAccelerated() всегда возвращает false. Как бы ты не прописывал это ускорение, я пробовал в манифесте
<application
android:hardwareAccelerated="true"
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
getWindow().setFlags(
WindowManager.LayoutParams.FLAG_HARDWARE_ACCELERATED,
WindowManager.LayoutParams.FLAG_HARDWARE_ACCELERATED);
У Гугла написано, что hardware accelaration для всех стандартных view включен по-умолчанию. Собственно ничего дополнительно выставлять не нужно)
Если же Вы делаете какую-нибудь кастомную view, или Вам нужно применить к элементу анимацию, то как раз применяете данный код:
Но в чем соль, как я понял. Посмотрим на вышеприведенный пример. Вы выставляете hardware accelaration перед анимацией:
То есть перед началом анимации Вы для данной view подключаете использование GPU, оптимизирующее прорисовку элемента. После завершения GPU для данной view не нужен, поэтому мы снимаем флаг hardware acceleration.
Соственно и поэтому View.isHardwareAccelerated() всегда возвращает false. Во время выполнения анимации по идее должен тогда возвращать true.
Я могу ошибаться, поэтому поправьте меня. Если честно, данная тема не очень хорошо и подробно раскрыта Гуглом. Скорее всего полный анализ hardware accelaration и создания качественный кастомных view рассмотрен в данном видео 2013 года еще — www.youtube.com/watch?v=NYtB6mlu7vA
Но у меня еще не дошли руки с этим видео и вообще вопросом качественно разобраться :)
Если же Вы делаете какую-нибудь кастомную view, или Вам нужно применить к элементу анимацию, то как раз применяете данный код:
View.setLayerType(View.LAYER_TYPE_HARDWARE, null);
ObjectAnimator animator = ObjectAnimator.ofFloat(view, "rotationY", 180);
animator.addListener(new AnimatorListenerAdapter() {
@Override
public void onAnimationEnd(Animator animation) {
view.setLayerType(View.LAYER_TYPE_NONE, null);
}
});
animator.start();
Но в чем соль, как я понял. Посмотрим на вышеприведенный пример. Вы выставляете hardware accelaration перед анимацией:
View.setLayerType(View.LAYER_TYPE_HARDWARE, null) View.setLayerType(View.LAYER_TYPE_NONE, null) То есть перед началом анимации Вы для данной view подключаете использование GPU, оптимизирующее прорисовку элемента. После завершения GPU для данной view не нужен, поэтому мы снимаем флаг hardware acceleration.
Соственно и поэтому View.isHardwareAccelerated() всегда возвращает false. Во время выполнения анимации по идее должен тогда возвращать true.
Я могу ошибаться, поэтому поправьте меня. Если честно, данная тема не очень хорошо и подробно раскрыта Гуглом. Скорее всего полный анализ hardware accelaration и создания качественный кастомных view рассмотрен в данном видео 2013 года еще — www.youtube.com/watch?v=NYtB6mlu7vA
Но у меня еще не дошли руки с этим видео и вообще вопросом качественно разобраться :)
У Гугла написано, что hardware accelaration для всех стандартных view включен по-умолчанию.
Тогда почему эти самые View возвращают false?
Там вообще как я понял, работать ускорение должно с 11 по 14 апи.
Немножко не ясно ответил я. В обычных ситуациях вьюшкам hardware acceleration не нужен. Только если появляется у этого элемента анимация, прозрачность (кстати прозрачность — это большое зло для производительности UI, как говорит Гугл), включается для них hardware acceleration. Анимация закончилась — hardware acceleration отключается, чтобы разгрузить GPU.
Но еще раз говорю, я тут могу ошибаться, так как тему еще не полностью изучил.
Но еще раз говорю, я тут могу ошибаться, так как тему еще не полностью изучил.
Что-то я не понял, из чего вы сделали вывод про
?
В совете на Android Developers говорится совсем о другом:
— для обычных массивов стоит использовать «enhanced for» (ф-ия two() в их примере)
— для ArrayList самым быстрым является вариант с «оптимизированным» for (ф-ия one()), и видео тоже это подтверждает
Но никто нигде не упоминал, что массивы надо конвертировать в ArrayList.
Если имеем обычный массив, то лучше перевести его в ArrayList, а затем весь перебрать.
?
В совете на Android Developers говорится совсем о другом:
— для обычных массивов стоит использовать «enhanced for» (ф-ия two() в их примере)
— для ArrayList самым быстрым является вариант с «оптимизированным» for (ф-ия one()), и видео тоже это подтверждает
Но никто нигде не упоминал, что массивы надо конвертировать в ArrayList.
6. External storage — no hard code!
Подскажите, что тут имеется ввиду. Нет внешней памяти или нет проблемам с внешним хранилищем (получение пути, установка на внешнюю флешку и т.п.)?
В целом статья вышла полезной, спасибо.
Это было бы слишком жестко)
Приведу пример того, что имел в виду
При создании файла мы можем использовать такой код:
где путь к директории, в которой должен храниться файл, задается вручную.
А нужно использовать такой код:
где путь к директории задается через специально предназначенный для этого метод Environment.getExternalStorageDirectory().getAbsolutePath()
Приведу пример того, что имел в виду
При создании файла мы можем использовать такой код:
myFile = new File("/sdcard/" + txtName.getText() + ".txt");
где путь к директории, в которой должен храниться файл, задается вручную.
А нужно использовать такой код:
myFile = new File(Environment.getExternalStorageDirectory().getAbsolutePath() + "/"+ txtName.getText() + ".txt");
где путь к директории задается через специально предназначенный для этого метод Environment.getExternalStorageDirectory().getAbsolutePath()
Так это всегда так было. Этот метод доступен с первой версии андроида. Пруф
Лучше-бы сперва время работы нормальное сделали на батарейке :( 5 версия вообще никуда :(
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Best practices от Google по разработке Android приложений