머리말
바인더는 기본 원칙은 시스템의 초석 원리이다 또한 수석 엔지니어의 필수 고급 지식 파악, 너무 많은 바인더 원리를 도입하지 않지만 바인더가 필요하기 전에 지식 포인트를 마스터 할 수있는 연구를 설명하기 위해이 문서.
IPC 메커니즘 1.Linux 종과 안드로이드
프로세스 간 통신을 의미 IPC 성명 프로세스 간 통신은, 두 개의 프로세스 사이의 데이터를 교환하는 과정을 말한다. 안드로이드와 리눅스가에서 자신의 IPC 메커니즘은 다음을 소개 여기에 있습니다.
1.1 리눅스의 IPC 메커니즘의 종류
리눅스 프로세스 간 통신 메커니즘을 많이 제공하고, 메인 파이프 (배관), 신호 (Sinal), 세마포어 (semophore), 메시지 큐 (메시지), 공유 메모리 (공유 메모리), 소켓 (소켓) 등을들 수있다.
관로
파이프 라인은 중요한 초기 유닉스 통신 메커니즘 사이에 거기에 리눅스 유닉스 프로세스에 의해 상속 통신 메커니즘입니다. 파이프 라인의 주요 아이디어는 양 당사자가 정보를 전송하는 공유 파일을 사용하여 통신 있도록 메모리에 공유 파일을 만드는 것입니다. 공유 파일이 오히려 특별하다, 파일 시스템에 속하고 전용 메모리에 존재하지 않습니다. 또 다른 점은, 배관 반이중 통신 방식으로 사용되며, 데이터는 한 방향으로 만 흐를 수있다.
도에서와 같이 단순 모델.
신호
소프트웨어 레벨에서기구를 방해하는 아날로그 신호이며, 비동기 통신 방법이 신호가 어떤 동작에 의해 도달 기다리지 않아도된다. 신호가 사용자 공간 프로세스와 커널 사이의 직접적인 상호 작용이 될 수 있으며, 사용자 공간 프로세스는 신호를 발생한 시스템 이벤트를 통지 할 수있다. 신호 처리 인터럽트 제어에 더 적합한 정보 교환에 적용되지 않는다.
신호기
세마포어는 공유 리소스에 여러 프로세스 액세스를 제어하는 데 사용되는 카운터입니다. 그것은 종종 공유 리소스에 대한 액세스를 방지하기 위해 잠금 장치로 사용되는 것은 다른 프로세스는 자원에 액세스 할 수 있습니다 과정이다. 주로 간 공정과 동일한 프로세스 내에서 상이한 스레드 간의 동기화의 수단으로서.
메시지 큐
메시지 큐는 메모리, 하나 개 이상의 프로세스에 저장된 메세지 큐 식별자에 의해 식별되는 특정 포맷을 구비하고 쓰고 메시지를 읽을 수 있도록 메시지의 링크 된리스트이다. 정보 두 번 복사, 너무 자주 여부 통신 많은 양의 정보에 대한 메시지 큐를 사용하고 있습니다.
공유 메모리
여러 프로세스가 직접 판독 및 하부 작업 효율과 디자인을위한 메모리 공간을 다른 통신 장치의 블록을 쓸 수있다.
여러 프로세스간에 정보를 교환하기 위해 커널이 프로세스가 액세스 할 수있는 메모리 영역의 조각을 곁에는 자신의 개인 주소 공간에 매핑 될 필요가있다. 이 과정은 직접 읽고 따라서 크게 효율성을 개선, 데이터의 사본을위한 필요없이 메모리를 쓸 수 있습니다.
소켓
소켓은 소켓은 서로 다른 시스템간에 프로세스 간 통신에 사용될 수있는 다른 방법은 상이한 근본적인 처리 통신 메커니즘들이다.
1.2 안드로이드의 IPC 메커니즘
안드로이드 시스템은 리눅스 커널, 리눅스 커널의 기준에 따라, 그리고 IPC 메커니즘의 수를 확장한다. 안드로이드 시스템에 추가하여 소켓을 지원에서, 또한 직렬화를 지원, 메신저, AIDL, 번들, 파일 공유, 컨텐트 프로, 등등 바인더와. 바인더는 IPC 메커니즘을 이해하는 첫 번째 앞, 뒷면에 도입됩니다.
직렬화
직렬화 직렬화 / Parcelable, 직렬화가 제공되는 자바 직렬화 인터페이스는 표준 직렬화 및 역 직렬화 작업 개체를 제공하는 빈 인터페이스입니다 의미합니다. 안드로이드 Parcelable 인터페이스는 너무 많은 문제, 매우 높은 효율, 안드로이드 플랫폼에서 사용하기에 더 적합한 방식으로 직렬화된다.
전령
안드로이드 애플리케이션 개발에 사용 메신저 주파수는 우리가 프로세스 간의 데이터 전달 될 메시지를 전달하고자하는 데이터를 추가, 메시지가 다른 프로세스에서 개체를 전달할 수 높지 않다. 메신저 경량 IPC 프로그램입니다 AIDL은 캡슐화됩니다.
AIDL
안드로이드 인터페이스 정의 언어, 즉 안드로이드 인터페이스 정의 언어의 AIDL 이름. 메신저 서버로 전송 된 메시지가 많은 경우, 서버는 여전히 처리하고 다음 클라이언트에 대한 응답이 분명히 부적절, 클라이언트에서 보낸 정보를 처리하기 위해 일련의 방법입니다. 또 다른 점, 메신저 데이터 전송뿐만 프로세스 사이의 프로세스 간 메서드 호출, 당신은 AIDL을 사용하기 위해 필요한이 시간을 충족하지 않았다.
묶음
번들 Parcelable 인터페이스를 구현하므로 쉽게 다른 프로세스 사이에서 전송 될 수있다. Acitivity는 서비스, 수신기의 데이터 전송은 의도 번들에 의해 수행된다.
파일 공유
읽기와 같은 파일을 작성하여 데이터를 공유하는 두 프로세스, 파일은 JOSN, XML 텍스트를 공유 할 수 있습니다. 파일 공유 데이터 통신 프로세스 간의 동기화 덜 요구에 적합하다.
컨텐트 프로
컨텐트 프로 저장하고 다른 애플리케이션 사이에서 데이터를 공유 할 수있는 통일 된 인터페이스를 제공하기 위해 데이터를 검색하기 위해 자체 프로세스 간 통신에 적합하다. 컨텐트 프로 기본이되는 구현은 바인더이지만, 많은 AIDL보다 사용하기 쉽다. 대부분의 운영 체제는 연락처, 오디오 및 비디오, 이러한 작업 스스로 프로세스 간 통신으로, 컨텐트 프로를 채택했다.
IPC 통신 이론 및 2.Linux의 바인더
리눅스는 통신 이론의 과정에 대해 이야기하기 전에, 우리는 Liunx의 몇 가지 개념을 이해할 필요가있다.
커널 공간과 사용자 공간
우리는 Liunx에 노출되면, 필연적으로 두 단어, 사용자 공간 (사용자 공간) 및 커널 공간 (커널 공간)을 듣고, 그들은 그것이 무엇을 의미합니까?
직접 커널을 조작하는 커널의 안전을 보장 할 수없는 사용자 프로세스를 보호하기 위해, 운영 시스템은 논리적으로 사용자 공간과 커널 공간에 가상 공간에서 나눈. 커널라는 커널 공간, 각 프로세스에 대한 3기가바이트 낮은 바이트, 사용자 공간이라고 사용합니다 1기가바이트 가장 높은 바이트 Linux 운영 체제.
커널 공간은 리눅스 커널 공간이 실행되고, 사용자 공간 프로그램을 실행하는 사용자의 공간입니다. 안전을 위해, 그들은 사용자 프로그램이 충돌하는 경우에도, 커널이 영향을받지 않습니다, 격리됩니다. 커널 공간 데이터는 프로세스간에 공유 할 수 있으며, 사용자 공간은 할 수 없습니다. 예를 들어,도 공간 사용자 프로세스 A와 사용자 B에 공간 처리를 공유하지 않는다.
프로세스 격리
프로세스 격리 프로세스가 직접 운영 또는 다른 프로세스에 액세스 할 수 있다는 것을 의미한다. B. 직접 프로세스의 데이터에 액세스되지 않는 방법
시스템 호출
사용자 공간 커널 공간에 액세스 할 수 있어야합니다, 당신은 시스템의 도움을 달성하기 위해 호출해야합니다. 시스템 호출은 사용자 공간 커널 공간에 액세스 할 수있는 유일한 방법은 모든 리소스 액세스가 커널, 시스템 리소스에 대한 무단 액세스를 방지 시스템 보안과 안정성을 개선하기 위해 사용자 프로그램의 제어하에 수행되도록합니다.
사용자 공간은을 처리하고 B는 다음과 같은 시스템 기능 및 커널 공간을 통해 상호 작용할 수 있습니다.
- copy_from_user 나 : 데이터 복사 사용자 공간은 공간을 커널합니다.
- copy_to_user라는 사용자 공간에 데이터를 커널 공간을 복사합니다.
메모리 맵
애플리케이션은 직접 장치의 하드웨어 주소를 조작 할 수 있기 때문에 운영 시스템 메커니즘을 제공한다 : 메모리 맵핑 매핑 디바이스 어드레스는 가상 메모리 영역을 처리하기.
사용자의 디스크 공간이 메모리 매핑 사용하지 않는 경우, 파일을 읽을 필요가있는 경우 예를 들어, 페이지 캐시에서 커널 공간, 디스크에 파일을 복사 할 수있는 페이지 캐시를 설정 한 다음, 사용자 공간 페이지를 캐시 파일을 복사해야하는 우리는 두 개의 사본이 필요합니다.
도에 도시 된 바와 같이, 메모리 맵핑.
때문에 새로운 가상 메모리 영역에, 디스크 파일 및 가상 메모리 영역을 직접 한 적은 사본을 매핑 할 수 있습니다.
메모리 맵 메모리 맵의 전체 이름은, 메모리 매핑 리눅스에서의 mmap 시스템 호출 기능에 의해 달성했다. 메모리 매핑 사용자 공간의 영역은 커널 공간입니다. 매핑 관계 후, 사용자는 그 반대의 경우도 마찬가지 커널 공간에 직접이 메모리 영역에 응답을 수정할 수 있습니다. 메모리 매핑 데이터를 복사, 사용자 공간과 커널 공간 사이의 효율적인 상호 작용의 수를 줄일 수 있습니다.
2.1 리눅스 IPC 통신 원리
아래 그림과 같이 당신이 리눅스의 IPC 통신의 원리를 배울 수의 개념 Liunx을 이해합니다.
커널 메모리 커널 공간의 버퍼로 데이터를 복사하는 과정 copy_from_user 나 기능을 전송하여, 커널 공간 커널 버퍼 개방 할당. 마찬가지로, 상기 수신 프로세스는 메모리 버퍼를 열어 사용자 공간에서 데이터를 수신하고, 그 커널이 수신 처리 커널 버퍼로부터 데이터를 복사 copy_to_user라는 () 함수를 호출한다. 이러한 데이터 송신 방법 및 수신 처리 데이터, 즉 프로세스 간 통신이 데이터 전송을 완료했다.
리눅스 IPC 통신 이론, 두 가지 질문이있다 :
- 一次数据传递需要经历：用户空间 –> 内核缓存区 –> 用户空间，需要2次数据拷贝，这样效率不高。
- 接收数据的缓存区由数据接收进程提供，但是接收进程并不知道需要多大的空间来存放将要传递过来的数据，因此只能开辟尽可能大的内存空间或者先调用API接收消息头来获取消息体的大小，浪费了空间或者时间。
2.2 Binder的通信原理
Binder是基于开源的OpenBinder实现的，OpenBinder最早并不是由Google公司开发的，而是Be Inc公司开发的，接着由Palm, Inc.公司负责开发。后来OpenBinder的作者Dianne Hackborn加入了Google公司，并负责Android平台的开发工作，顺便把这项技术也带进了Android。
Binder是基于内存映射来实现的，在前面我们知道内存映射通常是用在有物理介质的文件系统上的，Binder没有物理介质，它使用内存映射是为了跨进程传递数据。
Binder通信的步骤如下所示：
1.Binder驱动在内核空间创建一个数据接收缓存区。
2.在内核空间开辟一块内核缓存区，建立内核缓存区和数据接收缓存区之间的映射关系，以及数据接收缓存区和接收进程用户空间地址的映射关系。
3.发送方进程通过copy_from_user()函数将数据拷贝 到内核中的内核缓存区，由于内核缓存区和接收进程的用户空间存在内存映射，因此也就相当于把数据发送到了接收进程的用户空间，这样便完成了一次进程间的通信。
整个过程只使用了1次拷贝，不会因为不知道数据的大小而浪费空间或者时间，效率更高。
3.为什么要使用Binder
Android是基于Linux内核的 ，Linux提供了很多IPC机制，而Android却自己设计了Binder来进行通信，主要是因为以下几点。
性能方面
性能方面主要影响的因素是拷贝次数，管道、消息队列、Socket的拷贝次书都是两次，性能不是很好，共享内存不需要拷贝，性能最好，Binder的拷贝次书为1次，性能仅次于内存拷贝。
稳定性方面
Binder是基于C/S架构的，这个架构通常采用两层结构，在技术上已经很成熟了，稳定性是没有问题的。共享内存没有分层，难以控制，并发同步访问临界资源时，可能还会产生死锁。从稳定性的角度讲，Binder是优于共享内存的。
安全方面
Android是一个开源的系统，并且拥有开放性的平台，市场上应用来源很广，因此安全性对于Android 平台而言极其重要。
传统的IPC接收方无法获得对方可靠的进程用户ID/进程ID（UID/PID），无法鉴别对方身份。Android 为每个安装好的APP分配了自己的UID，通过进程的UID来鉴别进程身份。另外，Android系统中的Server端会判断UID/PID是否满足访问权限，而对外只暴露Client端，加强了系统的安全性。
语言方面
Linux是基于C语言，C语言是面向过程的，Android应用层和Java Framework是基于Java语言，Java语言是面向对象的。Binder本身符合面向对象的思想，因此作为Android的通信机制更合适不过。
从这四方面来看，Linux提供的大部分IPC机制根本无法和Binder相比较，而共享内存只在性能方面优于Binder，其他方面都劣于Binder，这些就是为什么Android要使用Binder来进行进程间通信，当然系统中并不是所有的进程通信都是采用了Binder，而是根据场景选择最合适的，比如Zygote进程与AMS通信使用的是Socket，Kill Process采用的是信号。
4.为什么要学习Binder?
Binder机制在Android中的地位举足轻重，我们需要掌握的很多原理都和Binder有关：
- 系统中的各个进程是如何通信的？
- Android系统启动过程
- AMS、PMS的原理
- 이러한 활동 등의 원리 네 가지 구성 요소는 어떻게 시작하는 것입니다?
- 플러그 지향 원칙
- 클라이언트 측과 서버 측 서비스 시스템은 어떻게 의사 소통을하는 것입니다? (예 MediaPlayer를 MeidaPlayerService와 같은)
SystemServer 프로세스가 목적이 SystemServer 과정에서 서비스가 다른 프로세스와 통신 할 수있게 바인더에 의해 달성된다 바인더는 스레드 풀을 생성 시작한 후 위의이 같은 부팅시 시스템으로, 단순히 말한다, 컬럼의 단지 작은 부분이다. 또 다른 예를 들어, 우리는 종종, AMS, PMS는 바인더가와 DefaultContainerService 통신 (검사 및 복사 시스템 및 서비스에 대한 파일을 이동할 수 있습니다)하고자하는 경우, 그것을 가지고 PMS, PMS는 SystemServer 프로세스에서 실행 달성을 기반으로 말한다 DefaultContainerService가 com.android.defcontainer 프로세스를 실행하기 때문에 우리는, 바인더가 필요합니다.
프로세스에서 실행되지 MeidaPlayerService 클라이언트 및 MediaPlayer가의 서버 측 끝 사이의 통신의 일반적인 C / S 구조의 문제도있다, 바인더도 의사 소통을 할 필요가있다.
바인더 메커니즘은 시스템의 기본 원리는 초석 파악라고 할 수 있습니다. 계층화 안드로이드 시스템은, 바인더 메커니즘은 다음 섹션으로 나누어 져 있습니다.
그림은 구체적인 세부 사항을 바인더 메커니즘을 제공하지 못했지만, 첫 번째는 계층 적 시스템 안드로이드 시스템을 기반으로, 개념을 제공, I 것이다 자바 바인더, 기본 바인더, 커널 바인더, 바인더의 사실에 바인더 메커니즘 내용이 매우 큰, 당신은 완전히 원래의 도입을 쓸 수 있지만,이 시리즈는 주요 자바 바인더 및 기본 바인더를 설명 할 수 있도록 응용 프로그램 개발, 너무 많은 지식이 필요하지 않습니다.
당신이 문서는 매우 유용 느낀다면 글쎄, 기사 친구에게 추천 할 수 있습니다, 여기에 종료합니다.