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

• В формате Bitmap и byte[]
• Уменьшенное с сохранением пропорций
• Уменьшенное с вырезанием (crop) до заданного размера width x height
• Оптимизированное для 2g
• Всегда в правильной ориентации (учитывая EXIF orientation)

ImageManager im = new ImageManager(ctx, 100, 100);
Bitmap bm = im.setIsScale(true)
              .setIsResize(true)
              .setIsCrop(true)
              .getFromFile(myUri.toString());

Интро

for (A a : arrayListA) { 
    // do something
    for (B b : arrayListB) {
        // do something
        for (C c : arrayListC) {
            // do something
        }
    }
}

-XX:+DoEscapeAnalysis

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

• GlobalEscape — объект доступен из других потоков и из других методов, например статическое поле.
• ArgEscape — объект был передан как аргумент или на него есть ссылка из объекта аргумента, но сам он не выходит из области видимости потока в котором был создан.
• NoEscape — объект не покидает область видимости метода и его создание может быть вынесено на стек.

    for (int i = 0; i < 1000*1000*1000; i++) {
        Foo foo = new Foo();
    }

Содержание

1. (Простой) Каков результат работы этого кода?
   

   switch(5){
   default: System.out.print(0);
   case 1: System.out.print(1); break;
   case 4: System.out.print(4);
   case 2: System.out.print(2);
   }

   
   
2. Следующие 2 варианта практически одинаковы. Немного отличаются литералами.
   

   //Вариант 1 switch("BBBBBB"){ case "AaAaAa": break; case "AaAaBB": break; case "AaBBAa": break; case "AaBBBB": break; case "BBAaAa": break; case "BBAaBB": break; case "BBBBAa": break; case "BBBBBB": break; }

   //Вариант 2 switch("BBBBBB_8"){ case "AaAaAa_1": break; case "AaAaBB_2": break; case "AaBBAa_3": break; case "AaBBBB_4": break; case "BBAaAa_5": break; case "BBAaBB_6": break; case "BBBBAa_7": break; case "BBBBBB_8": break; }

   Почему первый switch выполняется в несколько раз медленнее, по крайней мере, с отключенным JIT (-Djava.compiler=NONE)? Сами проверьте в цикле! JIT таким кодом не проведешь, но если немного пошаманить, то небольшая разница будет заметна.
3. Какова вычислительная сложность алгоритма нахождения совпадающего значения среди n case-ов (по крайней мере, в JDK 7)?