- Класс File
- Методы класса File
- Каталог
- Список каталогов
- Метод listFiles()
- Как устроен билд APK файла внутри
- Процесс создания APK и компиляции кода
- Рассматриваемые темы
- Архитектура процессоров и зачем нужна виртуальная машина
- Понимание Java виртуальной машины
- Андроид виртуальная машина
- Комплияция в .dex файл
- ART против Dalvik
- Каждый этап описанного процесса
- Source Code (Исходный код)
- Resource Files
- AIDL Files
- Library Modules
- AAR Libraries
- JAR Libraries
- Android Asset Packaging Tool
- resources.arsc
- D8 и R8
- Dex and Multidex
- Understanding the Android Application Class
Класс File
В отличие от большинства классов ввода/вывода, класс File работает не с потоками, а непосредственно с файлами. Данный класс позволяет получить информацию о файле: права доступа, время и дата создания, путь к каталогу. А также осуществлять навигацию по иерархиям подкаталогов.
Класс java.io.File может представлять имя определённого файла, а также имена группы файлов, находящихся в каталоге. Если класс представляет каталог, то его метод list() возвращает массив строк с именами всех файлов.
Для создания объектов класса File можно использовать один из следующих конструкторов.
- File(File dir, String name) — указывается объекта класса File (каталог) и имя файла
- File(String path) — указывается путь к файлу без указания имени файла
- File(String dirPath, Sring name) — указывается путь к файлу и имя файла
- File(URI uri) — указывается объекта URI, описывающий файл
Методы класса File
Класс File может использоваться для создания каталога или дерева каталогов. Также можно узнать свойства файлов (размер, дату последнего изменения, режим чтения/записи), определить к какому типу (файл или каталог) относится объект File, удалить файл. У класса очень много методов, перечислим некоторые.
- getAbsolutePath() — абсолютный путь файла, начиная с корня системы. В Android корневым элементом является символ слеша (/)
- canRead() — доступно для чтения
- canWrite() — доступно для записи
- exists() — файл существует или нет
- getName() — возвращает имя файла
- getParent() — возвращает имя родительского каталога
- getPath() — путь
- lastModified() — дата последнего изменения
- isFile() — объект является файлом, а не каталогом
- isDirectory — объект является каталогом
- isAbsolute() — возвращает true, если файл имеет абсолютный путь
- renameTo(File newPath) — переименовывает файл. В параметре указывается имя нового имени файла. Если переименование прошло неудачно, то возвращается false
- delete() — удаляет файл. Также можно удалить пустой каталог
Каталог
Каталог — это объект класса File, который содержит список других файлов и каталогов. После создания объекта класса File, являющего каталогом, его метод isDirectory() вернёт значение true. И тогда вы можете вызывать метод list().
Для создания каталога можно использовать метод mkdir(), который вернёт true в успешном случае. Если указанный путь уже существует или каталог нельзя создать из-за отсутствия полного пути к нему, то вернётся false.
Метод mkdirs() создаёт сам каталог, так и всех его родителей.
Список каталогов
Если вы хотите получить содержимое каталога, то можно вызвать метод list() без аргументов. Вам вернётся полный список (массив) имён файлов и каталогов, содержащихся в данном каталоге. Есть ещё похожий метод listFiles(), который возвращает массив файлов (объектов, а не их имён), о котором поговорим отдельно.
Если вам нужен только список файлов с расширением .java, то можно использовать специальный фильтр-класс, который описывает критерии отбора объектов File с помощью интерфейса FilenameFilter.
Интерфейс FilenameFilter определяет единственный метод accept(), вызываемый по одному разу с каждым файлом в списке.
Метод возвращает true для файлов каталога, указанного в dir, которые должны быть включены в список, и false — для файлов, которые следует исключить.
Метод listFiles()
Метод имеет несколько перегруженных версий. Он возвращает список файлов в виде массива объектов класса File. Одна из версий метода также использует интерфейс FilenameFilter. Другая версия использует интерфейс FileFilter и возвращает те файлы, путевые имена которых соответствует интерфейсу.
Пример использования методов класса File показан в уроке Файловый менеджер и в других примерах.
Источник
Как устроен билд APK файла внутри
Процесс создания APK и компиляции кода
Рассматриваемые темы
- Архитектура процессоров и необходимость для виртуальной машины
- Понимание Java виртуальной машины
- Компиляция исходного кода
- Виртуальная машина Андроид
- Процесс компиляции в .dex файл
- ART против Dalvik
- Описание каждой части билд процесса
- Исходный код
- Файлы ресурсов
- AIDL файлы
- Модули библиотек
- AAR библиотеки
- JAR библиотеки
- Android Asset Packaging Tool
- resources.arsc
- D8 и R8
- Dex и Multidex
- Подписывание APK файла
- Ссылки
Понимание флоу процесса билда APK файла, среда исполнения и компиляция кода
Этот пост нацелен быть отправной точкой для разработчиков, чтобы они ближе познакомились с билд процессом и созданием APK файла.
Архитектура процессоров и зачем нужна виртуальная машина
Андроид после того как вышел в 2007 году претерпел множество изменений связанный с билд процессом, средой исполнения и улучшениями производительности.
У андроида много удивительных характеристик и одна из них разные архитектуры процессоров такие как ARM64 и x86
Невозможно скомпилировать код, который поддерживает каждую архитектуру. Вот именно поэтому используется Java виртуальная машина.
Понимание Java виртуальной машины
JVM это виртуальная машина, позволяющая устройству запускать код, который скомпилирован в Java байткод
Используя JVM, вы избавляетесь от проблемы с разной архитектурой процессоров.
JVM предоставляет переносимость и она позволяет запускать Java код в виртуальной среде, вместо того, чтобы запускать его сразу «на железе»
Но JVM была создана для систем с большими мощностями по ресурсам, а наш андроид имеет сравнительно мало памяти и заряда батареи.
По этой причине Google создал адаптированную под андроид виртуальную машину, которая называется Dalvik.
Компилируем исходный код
Наш исходный Java код для андроида компилируется в класс файл .class с байткодом с помощью javac компилятора и запускается на JVM
Для котлина есть kotlinc компилятор, который делает совместимый с Java байткод.
Байткод — это набор инструкций, который выполняется на целевом устройстве.
Java байткод — это набор инструкций для Java виртуальной машины.
Андроид виртуальная машина
Каждое андроид приложение работает на своей виртуальной машине. С версий 1.0 до 4.4, это был Dalvik. В андроид 4.4, вместе с Dalvik, Google представил в качестве эксперимента новый андроид runtime, который назывался ART
Сгенерированный класс файл .class содержит JVM Java байткод.
Но у андроида есть свой собственный оптимизированный формат байткода, который называется Dalvik bytecode — это просто инструкции машинного кода для процессора также как и JVM байткод.
Комплияция в .dex файл
Во время компиляции происходит конвертация .class класс файл и .jar библиотеки в один classes.dex файл, который содержит Dalvik байткод.
Команда dx превращает все .class и .jar файлы в один classes.dex файл, который написан с форматом Dalvik байткода.
Dex — это аббревиатура с английского — Dalvik Executable.
ART против Dalvik
C версии 4.4 андроид мигрировал на ART. ART также работает с .dex файлом.
Преимущество ART над Dalvik проявляется в том, что приложения запускаются быстрее, потому что весь DEX байткод транслируется в машинный код во время установки, не нужно дополнительного времени на компиляцию в рантайме.
ART и Dalvik совместимы, так что приложения разработанные для Dalvik должны работать и на ART.
Компиляция Dalvik (JIT- just in time) имела такие минусы как — быстрая трата батареи, лаги в приложениях и плохой перформанс. В Dalvik трансляция происходит только когда это нужно. Мы открываем новый экран и только в этот момент происходит трансляция, за счет этого установка происходит быстрее, но при этом проседает перформанс.
Это причина по которой Google сделал Android Runtime (ART).
ART — основан на AOT (ahead of time) компиляции, она происходит до того как приложение запустится.
В ART компиляция происходит во время установки приложения. Это ведет к более долгому времени установки, но уменьшает трату батареи и избавляет от лагов, которые были на Dalvik.
Несмотря на то, что Dalvik был заменен на ART, .dex формат файлов еще используется
В андроид 7.0 JIT вернулся. Гибридная среда сочетает фичи как от JIT компиляции так и
от ART
Среда запуска байткода это очень важная часть андроида и она вовлечена в процесс запуска и установки приложения
Каждый этап описанного процесса
Source Code (Исходный код)
Это Java и Kotlin файлы в src пакете.
Resource Files
Файлы находящиеся в директории с ресурсами
AIDL Files
AIDL — аббревиатура Android Interface Definition Language, позволяет вам описать интерфейс межпроцессорного взаимодействия.
AIDL — может использоваться между любыми процессами в андроиде.
Library Modules
Модули библиотек содержат Java или Kotlin классы, компоненты андроида и ресурсы.
Код и ресурсы бибилотеки компилируются и пакуются вместе с приложением.
Поэтому модуль библиотеки может считаться компайл тайм артефактом.
AAR Libraries
Андроид библиотеки компилируются в AAR — android archive файл, который вы можете использовать как зависимость для вашего android app модуля.
AAR файлы могут содержать андроид ресурсы и файл манифеста, что позволяет вам упаковать туда общие ресурсы такие как layouts и drawables в дополнение к Java или Kotlin классам и методам.
JAR Libraries
JAR это Java библиотека и в отличие от AAR она не может содержать андроид ресурсы и манифесты.
Android Asset Packaging Tool
AAPT2 — аббревиатура (Android Asset Packaging Tool) — компилирует манифест и файлы ресурсов в один APK.
Этот процесс разделен на два шага компиляцию и линковку Это улучшает производительность так как если вы поменяете один файл, вам нужно компилировать только его и прилинковать к остальным файлам командой ‘link’
AAPT2 может компилировать все типы андроид ресурсов, таких как drawables и XML файлы.
При вызове AAPT2 для компиляции, туда передается по одному ресурсному файлу на каждый вызов
Затем APPT2 парсит файл и генерирует промежуточный бинарный файл с расширением .flat
Фаза линковки склеивает все промежуточные файлы сгенерированные в фазе компиляции и дает нам на выход один .apk файл. Вы также можете сгенерировать R.java файл и правила для proguard в это же время.
resources.arsc
Полученный на выходе .apk файл не включает в себя DEX файл, APK не подписан и не может быть запущен на устройстве.
APK содержит AndroidManifest, бинарные XML файлы и resources.arsc
resource.arsc содержит всю мета информацию о ресурсах, такую как индексы всех ресурсов в пакете
Это бинарный файл и APK который может быть запущен. APK который вы обычно создаете и запускаете не сжат и может быть использован просто посредством размещения в памяти.
R.java файл это выходной файл вместе с APK ему назначен уникальный id, который позволяет Java коду использовать ресурсы во время компиляции.
arsc это индекс ресурса который используется во время запуска приложения
D8 и R8
Начиная с андроид студии 3.1 и далее, D8 был сделан дефолтным компилятором.
D8 производит более маленькие dex файлы с лучшей производительностью, если сравнивать со старым dx.
R8 используется для компиляции кода. R8 это оптимизированная версия D8
D8 играет роль конвертера класс файлов в Dex файлы, а также производит дешугаринг функций из Java 8 в байткод, который может быть запущен на андроиде
R8 оптимизирует dex байткод. Он предоставляет такие фичи как оптимизация, обфускация, удаление ненужных классов.
Обфускация уменьшает размер вашего приложения укорачивая названия классов, методов и полей.
Обфускация имеет и другие преимущества для предотвращения реверс инжиниринга, но основная цель уменьшить размер.
Оптимизация уменьшает размер Dex файла путем переписывания ненужных частей кода и инлайнинга.
С помощью дешугаринга мы можем использовать удобные фичи языка Java 8 на андроиде.
Dex and Multidex
R8 дает на выходе один DEX файл, который называется classes.dex
Если количество методов приложения переваливает за 65,536, включая подключенные библиотеки, то произойдет ошибка при билде
Источник
Understanding the Android Application Class
The Application class in Android is the base class within an Android app that contains all other components such as activities and services. The Application class, or any subclass of the Application class, is instantiated before any other class when the process for your application/package is created.
This class is primarily used for initialization of global state before the first Activity is displayed. Note that custom Application objects should be used carefully and are often not needed at all.
In many apps, there’s no need to work with an application class directly. However, there are a few acceptable uses of a custom application class:
- Specialized tasks that need to run before the creation of your first activity
- Global initialization that needs to be shared across all components (crash reporting, persistence)
- Static methods for easy access to static immutable data such as a shared network client object
Note that you should never store mutable shared data inside the Application object since that data might disappear or become invalid at any time. Instead, store any mutable shared data using persistence strategies such as files, SharedPreferences or SQLite .
If we do want a custom application class, we start by creating a new class which extends android.app.Application as follows:
And specify the android:name property in the the node in AndroidManifest.xml :
That’s all you should need to get started with your custom application.
There is always data and information that is needed in many places within your app. This might be a session token, the result of an expensive computation, etc. It might be tempting to use the application instance in order to avoid the overhead of passing objects between activities or keeping those in persistent storage.
However, you should never store mutable instance data inside the Application object because if you assume that your data will stay there, your application will inevitably crash at some point with a NullPointerException . The application object is not guaranteed to stay in memory forever, it will get killed. Contrary to popular belief, the app won’t be restarted from scratch. Android will create a new Application object and start the activity where the user was before to give the illusion that the application was never killed in the first place.
So how should we store shared application data? We should store shared data in one of the following ways:
- Explicitly pass the data to the Activity through the intent.
- Use one of the many ways to persist the data to disk.
Bottom Line: Storing data in the Application object is error-prone and can crash your app. Prefer storing your global data on disk if it is really needed later or explicitly pass to your activity in the intent’s extras.
Источник