Поскольку вы хотите выяснить, почему вы используете связующее, вам необходимо понять роль связующего.
Роль связующего на уровне java - это средство связи. Затем нам нужно понять, какую проблему решает связующее, и каковы недостатки исходного механизма связи IPC.
1. Существующие типы механизмов IPC в Linux
1. Общая память
2. Трубы
3. Очередь сообщений
4.socket
1.1 Аспекты производительности
Давайте посмотрим на коммуникацию, сколько раз нужно скопировать память для каждого из этих методов.Чем больше раз копируется память, тем ниже эффективность связи.
Счетчик копий памяти Binder равен 1, что меньше, чем в общей памяти, и больше, чем у других методов.
1.2 Аспекты безопасности
Традиционный метод IPC вообще не имеет никакой безопасности, что и понятно, ведь на платформе Android будет сталкиваться большое количество приложений, и необходимо различать вредоносные приложения и предотвращать их доступ. Традиционный метод IPC не может получить UID соответствующего процесса (UID — это уникальный идентификатор, предоставляемый системой Android каждому приложению, который можно использовать для проверки авторизации), и авторизация не может быть проверена.
2. Каковы преимущества Binder? как решить другие виды проблем
Связь Binder может получить UID, что обеспечивает безопасность. КПД хоть и не самый высокий, но приемлемый.
3. Принцип связующего
Почему Binder может завершить общение, скопировав память один раз? Сначала вам нужно понять концепции Linux.
3.1 Изоляция процесса
В Linux используется технология изоляции процессов, то есть память между каждым процессом не делится друг с другом. Играйте с собственной памятью, чтобы обеспечить безопасность данных. Следовательно, если требуется связь между процессами, для обработки требуется соответствующий механизм IPC.
Технология изоляции процессов использует концепцию виртуальной памяти. Виртуальная память — это технология улучшения использования физической памяти. Это сопоставление физической памяти, благодаря которому программа может видеть непрерывную память. Для понимания этого можно использовать режим прокси. Это прокси физической памяти. физическая память может быть фрагментирована на фрагменты памяти, а также на диск. Он может обменивать часть редко используемой памяти на диск для повышения эффективности использования памяти.
3.2 Пространство процесса: пространство пользователя и пространство ядра
Код ядра и данные хранятся в пространстве ядра, а код и данные пользовательской программы хранятся в пространстве пользователя процесса.
Чтобы быть более конкретным, предположим, что операционная система 32-разрядная, возможность адресации равна 2 в 32-й степени, что равно 4G, а старшие байты размером 1 ГБ используются ядром, которое называется пространством ядра. Остальные 3 ГБ используются пользовательскими процессами и называются пользовательским пространством.
Все они работают на виртуальных адресах, но изолированы друг от друга.
Если пространство пользователя хочет получить доступ к ресурсам пространства ядра (поскольку пространство ядра занимает системные ресурсы, такие как чтение и запись файлов, доступ к сети), ему необходимо обмениваться данными между ними. В это время системное ядро может предоставить интерфейс для вызова пользователями, что обеспечивает безопасность и стабильность системы. Другими словами, традиционное межпроцессное взаимодействие IPC осуществляется через системное ядро.
3.3 Режим пользователя и режим системы
Когда процесс выполняет пользовательский код, он находится в пользовательском режиме. Когда процесс выполняет код ядра, он находится в состоянии ядра.
3.4 Модули ядра и драйверы
Традиционный метод IPC завершается через системное ядро, то же самое верно и для Binder, в ядре есть драйвер связывателя.
4. Принцип связи традиционного механизма IPC
Волна воровства здесьrushjsбольшая фигура бога
Обычно следующие два шага (механизм неразделяемой памяти):
- Процесс-отправитель копирует данные для отправки в буфер ядра через системный вызов (copy_from_user).
- Получатель открывает область памяти, и ядро копирует данные из буфера ядра в буфер памяти получателя с помощью системного вызова (copy_to_user).
У этого традиционного механизма IPC есть две проблемы:
- Требуются две копии данных, первая — из пользовательского пространства отправителя в буфер ядра, а вторая — из буфера ядра в пользовательское пространство получателя.
- Процесс-получатель заранее не знает, сколько места нужно выделить для получения данных, и это может быть пустой тратой места.
5. Основной принцип Binder
Традиционный механизм IPC требует двойного копирования памяти Как Binder реализует межпроцессное взаимодействие только с одной копией памяти? Ранее мы уже узнали, что Linux использует режим адресации виртуальной памяти. Адрес виртуальной памяти пользовательского пространства сопоставляется с физической памятью. Чтение и запись виртуальной памяти на самом деле является чтением и записью физической памяти. Этот процесскарта памяти, этот процесс отображения памяти достигается с помощью системного вызова mmap().
Биндер использует метод отображения памяти, чтобы выполнить слой отображения памяти между пространством ядра и областью буфера данных пользовательского пространства получателя. Таким образом, данные, скопированные из пользовательского пространства отправителя в буфер пространства ядра, эквивалентны прямому копированию в буфер данных пользовательского пространства получателя, что сокращает одну копию данных.
6. Процесс вызова Binder
Вызов связывателя представляет собой архитектуру C/S, а клиент и сервер находятся в разных процессах. Тогда наша первая мысль состоит в том, что базовый драйвер, должно быть, вызвал системные ресурсы, чтобы помочь нам выполнить передачу ссылки на объект.
Участниками всего процесса являются ServerManager, Нижний драйвер Binder, Сервер, Клиент. Роль этих ролей очень похожа на доставку сетевого запроса.
ServerManager действует как сервер разрешения DNS, а базовый драйвер Binder эквивалентен маршрутизатору, инициатору запроса клиента и получателю запроса сервера.
Проще говоря.
1. Клиент инициирует запрос и вводит доменное имя. (например, введите www.juejin.im в браузере)
2.ServerManager, верните мне соответствующий объект Binder. (DNS разрешает реальный IP раскопа)
3. Драйвер Binder помогает передать ссылку на объект Binder. (передается через послойную маршрутизацию)
4.Сервер получает Биндер. (приходит запрос)
По сути, его можно сравнить с семиуровневым стеком сетевых протоколов, и он очень нагляден.
Оглядываясь назад, можно сказать, что, поскольку соответствующий объект Binder можно найти в ServerManager, должен быть процесс ранней регистрации. И ServerManager, и Client, и Server определенно находятся в разных процессах, и связь между ними также передается связующим звеном. Другими словами, будет ServerManager, который предоставит концепцию, аналогичную глобальному связующему, которое Клиент может получить напрямую, чтобы общаться с ServerManager.
7. Механизм прокси связующего
Использование связующего верхнего слоя фактически не знает об агенте, что также является ролью агента, так что верхний слой не знает. Фактически, клиент получает ссылку на объект Binder Сервера, который на самом деле является уровнем прокси, управляемым Binder. Предположим, что RPC на стороне клиента вызывает метод сервера, который фактически работает с прокси-сервером, управляемым Binder, а затем драйвер передает эту операцию на сторону сервера, а затем вызывает метод на стороне сервера.
В частности, посмотрите на исходный код класса, сгенерированный файлом AIDL, чтобы все было ясно. В нем определен прокси, и прокси содержит методы всех файлов AIDL.
Я вот думаю, стоит ли рисовать здесь? ~~
8. Резюме
Весь процесс работы с Binder выглядит следующим образом: я лично считаю, что углубленное изучение одной вещи может объединить множество ваших разрозненных знаний.