Computer >> 컴퓨터 >  >> 시스템 >> Android

Android의 에너지 절약 잠금 해제:AOSP의 저전력 아일랜드에서 Bluetooth 소켓 설정의 역할

Android의 에너지 절약 잠금 해제:AOSP의 저전력 아일랜드에서 Bluetooth 소켓 설정의 역할

상상해 보십시오. 노트북을 열어 놓고 테이블 위에 전화기를 놓고 몇 분 간격으로 울리는 스마트워치와 음악을 재생하는 Bluetooth 이어버드를 들고 카페에 앉아 있습니다. 당신의 관점에서 보면 삶은 평화롭습니다. 휴대전화의 관점에서 보면 휴대전화는 항상 엄청나게 많은 수의 작은 블루투스 패킷을 저글링하고 있습니다.

시계가 걸음 수를 동기화할 때마다, 이어버드가 또 다른 오디오 덩어리를 수신할 때마다, 백그라운드 장치가 체크인할 때마다 휴대폰 내부의 주요 애플리케이션 프로세서가 강제로 깨어나 데이터를 살펴보고 무엇을 할지 결정한 다음 다시 절전 모드로 전환됩니다. 수천 번 반복하다 보면 갑자기 그 멋진 5000mAh 배터리가 의심스러울 정도로 작게 느껴지기 시작합니다.

Android 엔지니어들은 이 패턴을 보고 기본적으로 "모든 작은 Bluetooth 작업에 대해 큰 CPU를 깨우지 않으면 어떻게 될까요?"라고 말했습니다. 메인 CPU가 휴식을 취하는 동안 지루하고 반복적인 Bluetooth 트래픽을 처리하는 것이 전체 작업인 작은 도우미 두뇌가 있다면 어떨까요? 일반적으로 LPI로 축약되는 저전력 섬(Low Power Island) 개념이 바로 여기에 있습니다.

최신 Android Bluetooth 아키텍처, 특히 AOSP 16세대부터는 Bluetooth 작업의 상당 부분을 Bluetooth 무선 장치에 더 가까운 전용 저전력 프로세서로 오프로드할 수 있습니다. 이 작은 프로세서는 Bluetooth 컨트롤러 또는 SoC에 내장되어 있으며 매우 효율적으로 실행되도록 설계되었습니다. 이는 메인 CPU보다 훨씬 적은 전력을 소비하며 전체 애플리케이션 프로세서처럼 배터리를 소모하지 않고 깨어 있는 상태를 유지할 수 있습니다. Android의 임무는 어떤 트래픽이 이 섬에 존재할 수 있는지, 어떤 트래픽이 여전히 메인 CPU를 필요로 하는지 결정하는 것입니다.

하지만 Android는 실제로 어떻게 결정을 내릴까요? 여기가 Bluetooth 소켓과 BluetoothSocketSettings라는 항목이 스토리에 들어가는 곳입니다.

일반 앱에서 BluetoothSocket을 열면 바이트를 보내고 받을 수 있도록 파이프를 여는 것처럼 느껴집니다. 하지만 내부적으로 프레임워크는 훨씬 더 깊은 질문을 던지고 있습니다. 이 파이프가 메인 CPU를 깨우는 큰 고속도로를 통과해야 할까요, 아니면 이 파이프가 저전력 섬의 개인 도로 네트워크에 직접 연결될 수 있을까요?

최신 AOSP Bluetooth 스택에서 해당 질문에 대한 대답은 BluetoothSocketSettings라는 작은 구성 객체를 통해 표현됩니다. 이 클래스를 사용하면 시스템 수준 코드에서 소켓의 작동 방식을 설명할 수 있습니다. 데이터를 일반 호스트 경로에 보관해야 하는지 아니면 저전력 프로세서에서 끝나는 하드웨어 데이터 경로로 오프로드해야 하는지 지정할 수 있습니다.

내부에는 DATA_PATH_NO_OFFLOAD와 같은 필드가 있습니다. 그리고 DATA_PATH_HARDWARE_OFFLOAD , hubId 등의 추가 정보 , endpointId 및 requestedMaximumPacketSize 컨트롤러가 LPI 세계에서 패킷을 라우팅하는 방법을 이해하는 데 도움이 됩니다.

외부에서 보면 여전히 일반적인 BluetoothSocket을 다루는 것처럼 보입니다. 하지만 블루투스 프레임워크 내에서 해당 소켓에는 이제 블루투스 스택에 조용히 알려주는 추가 메타데이터가 태그로 지정됩니다. 이 스택은 특별합니다. 섬으로 보내세요.

그런 다음 호스트 스택은 LPP 오프로드 관리자 및 소켓별 HAL(하드웨어 추상화 계층)이라는 Bluetooth 시스템의 새로운 코드 계층과 통신하여 소켓이 열리거나 닫힐 때마다 저전력 프로세서에 정보를 제공하고 데이터 처리에 대한 책임을 주장할 수 있습니다.

따라서 카페 비유를 따르면 이전에는 모든 Bluetooth 고객이 메인 바리스타에게 직접 주문을 외쳤습니다. Low Power Island 및 BluetoothSocketSettings를 통해 Android는 "이러한 일반 에스프레소 주문은 사이드 카운터에 있는 주니어 바리스타를 통해 전달될 수 있습니다. 여전히 이상한 맞춤형 음료만 메인 바리스타에게 전달됩니다."라고 말할 수 있습니다. 사용자에게 동일한 Bluetooth 환경을 제공하지만 카운터 뒤에서 혼란과 에너지 낭비가 훨씬 적습니다.

이 기사에서는 이 높은 수준의 이야기에서 실제 Android API를 확대해 보겠습니다. 프레임워크에서 BluetoothSocketSettings가 어떻게 정의되는지, 하드웨어 오프로드를 요청하는 방법, 그리고 HubId 및 EndpointId와 같이 무섭게 보이는 필드가 실제로 일반 영어로 무엇을 의미하는지 살펴보겠습니다.

목차

  1. BluetoothSocketSettings의 구조

  2. HAL 내부:Bluetooth 오프로드의 실제 작동 방식

  3. CPU는 절전 모드이지만 Bluetooth는 절전 모드가 아닌 경우:전원 관리 작동

  4. 개발자가 BluetoothSocketSettings를 활용하는 방법

  5. 그랜드 피날레:스마트하게 자는 것의 우아함

BluetoothSocketSettings의 분석

지금까지 우리는 BluetoothSocketSettings에 대해 휴대폰 내부 어딘가에 있는 햇볕이 잘 드는 저전력 섬으로 패킷을 보내는 마법의 티켓처럼 이야기해왔습니다. 이제 해당 티켓이 코드에서 어떻게 보이는지 실제로 살펴보겠습니다.

Android 오픈소스 프로젝트 트리를 열고 프레임워크 레이어로 이동하면 frameworks/base/core/java/android/bluetooth/BluetoothSocketSettings.java 아래에 숨어 있는 클래스 정의를 찾을 수 있습니다. . 언뜻 보면 배터리를 많이 절약하기에는 작고 너무 단순해 보입니다. 하지만 이 작은 클래스는 블루투스 스택에 소켓의 데이터가 어디로 흘러야 하는지 알려주는 비밀 지침을 전달합니다.

단순 버전은 다음과 같습니다:

public final class BluetoothSocketSettings implements Parcelable {
 public static final int DATA_PATH_NO_OFFLOAD = 0;
 public static final int DATA_PATH_HARDWARE_OFFLOAD = 1;
 private int mDataPath;
 private int mHubId;
 private int mEndpointId;
 private int mRequestedMaxPacketSize;
 public BluetoothSocketSettings(int dataPath, int hubId, int endpointId,
 int requestedMaxPacketSize) {
 mDataPath = dataPath;
 mHubId = hubId;
 mEndpointId = endpointId;
 mRequestedMaxPacketSize = requestedMaxPacketSize;
 }
 public int getDataPath() { return mDataPath; }
 public int getHubId() { return mHubId; }
 public int getEndpointId() { return mEndpointId; }
 public int getRequestedMaxPacketSize() { return mRequestedMaxPacketSize; }
}

Android Bluetooth에서 새 소켓이 생성되면 시스템 또는 권한 있는 서비스는 이러한 설정 개체 중 하나를 스택으로 전달할 수 있습니다. 키 라인은 DATA_PATH_HARDWARE_OFFLOAD입니다. . 이는 블루투스 시스템에 메인 CPU를 깨우기보다는 컨트롤러의 마이크로프로세서에서 이 트래픽을 유지하도록 노력하세요라고 알려주는 스위치입니다.

hubId 그리고 endpointId 섬의 주소와 같습니다. 특정 소켓에 사용할 논리 포트 또는 대기열을 펌웨어에 알려줍니다. requestedMaxPacketSize 버퍼 할당을 조정하여 처리량과 전력 효율성의 균형을 맞출 수 있습니다.

이 시점에서 여러분은 이 작은 Java 개체가 실제로 어떻게 하드웨어로 전달되는지 궁금할 것입니다. 답은 HAL(하드웨어 추상화 계층)에 있습니다. BluetoothSocket.connect()과 같은 전화를 걸면 , 결국 btif_sock.cc와 같은 파일의 네이티브 코드를 통해 아래로 퍼널링됩니다. 및 btif_core.cc . 거기에서 다음과 같은 흔적을 볼 수 있습니다:

bt_status_t status = BTA_SockConnect(type, addr, channel, flags);
if (settings.data_path == DATA_PATH_HARDWARE_OFFLOAD) {
 BTIF_TRACE_DEBUG("Configuring socket for hardware offload path");
 BTA_SockSetOffloadParams(settings.hub_id, settings.endpoint_id);
}

이 스니펫은 단순해 보이지만 책임의 큰 변화를 나타냅니다. 모든 패킷을 호스트 스택으로 보내는 대신 Bluetooth 컨트롤러는 이제 데이터 경로의 소유권을 주장할 수 있습니다. 그런 다음 SoC 내부의 Bluetooth 펌웨어가 인계받아 기본 CPU를 계속 깨우지 않고 패킷 재전송, 승인 및 흐름 제어를 처리합니다.

이러한 연결 중에 장치의 커널 로그를 모니터링하면 다음과 같은 내용을 발견할 수도 있습니다.

bt_vendor: enabling LPI offload for handle 0x0041
bt_controller: lpi path active, cpu wakelocks released

해당 로그 라인은 데이터 경로가 저전력 섬으로 성공적으로 마이그레이션되었음을 조용히 확인시켜 줍니다.

인간의 관점에서 볼 때, 전화기는 이 블루투스 대화가 미니 프로세서에 의해 처리될 만큼 충분히 예측 가능하다고 판단하여 대형 CPU에 정중하게 "이제 낮잠을 자도 됩니다. 알겠습니다."라고 말했습니다.

다음 섹션에서는 HAL 및 펌웨어 경계까지 한 단계 더 깊이 들어가 이러한 소켓 설정이 컨트롤러 칩 내부의 실제 저전력 데이터 라우팅으로 어떻게 전환되는지 살펴보겠습니다. 이것이 바로 하드웨어의 진정한 마법이 일어나는 곳이며, 한 번에 밀리와트 단위로 절감 효과가 누적되기 시작하는 곳입니다.

HAL 내부:Bluetooth 오프로드의 실제 작동 방식

지금까지 우리는 프레임워크와 시스템 서비스가 있는 편안한 아파트인 Android의 Java 및 기본 레이어에 주로 머물렀습니다. 하지만 그 아래에는 영리한 기계로 가득 찬 지하실, 즉 하드웨어 추상화 계층이 있습니다. 또는 HAL. 여기가 Android가 '객체'로 대화하는 것을 멈추고 연산 코드와 버퍼로 말하기 시작하는 곳이며, 소프트웨어와 실리콘 사이의 다리 역할을 합니다.

BluetoothSocketSettings 플래그가 시스템에 "하드웨어 오프로드를 사용하십시오"라고 알리면 해당 요청이 마법처럼 칩으로 순간이동되지 않습니다. Bluetooth 스택을 단계별로 따라 내려가며 JNI(Java Native Interface)를 통해 C++로 이동한 다음 hardware/interfaces/bluetooth/ 내부에 정의된 HAL로 이동합니다. .

Android 14, 특히 AOSP 16부터 HAL은 더욱 스마트해졌습니다. 이제 LPI 기능을 이해하고 특정 소켓 트래픽을 HAL로 라우팅할 수 있습니다.

단순화된 HAL 함수를 살펴보겠습니다. 이것은 허구의 단편이 아닙니다. bluetooth_audio_hw.cc에서 찾을 수 있는 것과 비슷합니다. 또는 bluetooth_socket_hal.cc :

Return<void> BluetoothHci::createSocketChannel(
 const hidl_string& device, const BluetoothSocketSettings& settings,
 createSocketChannel_cb _hidl_cb) {
 int fd = -1;
 if (settings.data_path == DATA_PATH_HARDWARE_OFFLOAD) {
 ALOGI("LPI offload requested for socket on hub %d endpoint %d",
 settings.hub_id, settings.endpoint_id);
 fd = controller->allocateLpiChannel(settings.hub_id, settings.endpoint_id);
 } else {
 fd = controller->allocateHostChannel();
 }
 _hidl_cb(Status::SUCCESS, fd);
 return void();
}

쉽게 말하면 이 방법은 블루투스 교차로의 교통경찰관과 같습니다. 소켓 설정을 살펴보고 데이터를 전송할 경로를 결정합니다. DATA_PATH_HARDWARE_OFFLOAD인 경우 설정되면 데이터 경로는 일반 호스트 측 버퍼 대신 컨트롤러의 내부 MCU에 연결됩니다.

controller->allocateLpiChannel()에 대한 호출 HAL이 "알겠습니다. 칩, 저전력 프로세서 내부에 완전히 존재하는 대기열을 생성해 주십시오."라고 말하는 곳입니다. 이 마이크로컨트롤러는 Bluetooth 라디오에 물리적으로 더 가깝습니다. 일반적으로 메인 CPU를 깨워야 하는 승인, 소규모 데이터 버스트, 일부 프로토콜 타이밍까지 자체적으로 처리할 수 있습니다.

이 채널이 생성되면 Android 프레임워크와 앱은 마치 소켓이 완전히 로컬인 것처럼 여전히 일반 파일 설명자를 볼 수 있습니다. 놀라운 점은 이 설명자가 Linux 커널 버퍼가 아닌 펌웨어 관리 메모리 및 DMA 경로의 지원을 받는다는 사실입니다.

디버거를 연결하거나 컨트롤러에서 로그를 덤프하려는 경우 다음과 같은 내용이 표시될 수 있습니다.

bt_lpi_mcu: channel 0x03 opened for handle 0x0041
bt_hci: diverting ACL packets to LPI path
bt_lpi_mcu: sleeping host processor

세 번째 줄, sleeping host processor , 모든 전력 엔지니어의 꿈이 실현되는 것입니다. 전화기는 말 그대로 블루투스를 활성화하면서 CPU 하위 시스템의 큰 부분을 끕니다.

Qualcomm이나 Broadcom과 같은 공급업체가 특별한 소스를 추가하는 곳이기도 합니다. HAL에는 '연결 유지' 타이머, '병합 간격' 및 '펌웨어 기반 재전송'을 위한 추가 후크가 포함되는 경우가 많습니다. 이를 통해 메인 프로세서가 작동하지 않는 경우에도 연결이 원활하게 느껴집니다.

높은 수준의 관점에서 파이프라인은 이제 다음과 같습니다:

App -> Bluetooth Framework -> JNI -> btif_sock -> HAL -> Controller MCU (LPI)

모든 계층은 다음 단계로 배턴을 깨끗하게 전달할 만큼만 이해합니다. HAL은 번역기 역할을 하여 높은 수준의 설정을 칩 펌웨어가 실행할 수 있는 낮은 수준의 명령으로 변환합니다.

스마트워치가 패킷을 보내거나 이어버드가 오디오 청크를 요청할 때쯤이면 메인 CPU는 깜박거리지도 않습니다. 전체 트랜잭션은 블루투스 컨트롤러의 작은 영역 내에서 살다가 죽으며, 전력을 소비하는 것이 아니라 조금씩 마시게 됩니다.

다음 섹션에서는 이 오프로드 아키텍처가 wakelock, 잠자기 모드, 커널 조정을 포함하여 Android의 전원 관리 시스템과 통합되는 방법과 기본 CPU가 절전 모드인 경우에도 연결이 한 순간도 놓치지 않도록 보장하는 방법을 살펴보겠습니다.

CPU는 절전 모드이지만 Bluetooth는 절전 모드가 아닌 경우:전원 관리 작동

좋습니다. 소켓 오프로드가 앱 계층에서 HAL로 이동하여 마침내 Bluetooth 칩 내부에 있는 작은 MCU에 도달하는 방법을 살펴보았습니다. 하지만 다음에 무슨 일이 일어날까요? 파일 전송이나 오디오 스트림이 계속 진행되는 동안 휴대폰의 메인 CPU가 낮잠을 자기로 결정하면 어떻게 될까요? 블루투스 연결이 끊어질 위험은 없나요?

여기가 Android의 전원 관리 안무입니다. 들어옵니다. Power HAL 세 명의 연주자 사이의 춤입니다. , 블루투스 스택 및 커널 wakelock 시스템 .

Bluetooth 소켓이 Low Power Island용으로 구성되면 Android의 Bluetooth 스택은 메인 CPU의 도움 없이도 이 연결을 유지할 수 있다는 신호를 커널에 보냅니다. 내부적으로는 일반적으로 Bluetooth 트래픽 중에 프로세서를 깨운 상태로 유지하는 wakelock 타이머를 지우거나 축소합니다. 커널 로그에서 다음과 같은 내용을 볼 수 있습니다:

wakelock: release "bt_wake" (LPI mode active)
bt_controller: firmware handling link supervision locally

이 메시지는 시스템 엔지니어에게 금과 같습니다. 이는 컨트롤러가 연결에 대한 완전한 소유권을 갖게 되었음을 알려줍니다. 이제 Bluetooth 펌웨어는 감독 시간 초과를 모니터링하고 재전송을 처리하며 암호화 카운터를 유지 관리합니다.

전원 관리자의 관점에서 보면 Bluetooth 장치는 메인 CPU에 대한 인터럽트가 생성되지 않기 때문에 "유휴" 상태로 보입니다. 한편 컨트롤러 MCU는 자체 저전력 클록 도메인을 사용하여 이어버드 또는 스마트워치와 조용히 패킷을 교환합니다.

이를 조정하기 위해 블루투스 HAL은 트래픽 수준이 변경될 때마다 Power HAL에 알리는 작은 콜백을 노출합니다. bt_vendor_qcom.cc에서 이와 같은 스니펫을 찾을 수 있습니다. :

void bt_lpi_activity_update(bool active) {
 if (active)
 power_hint(POWER_HINT_LPI_ACTIVITY, 1);
 else
 power_hint(POWER_HINT_LPI_ACTIVITY, 0);
}

active일 때 0이 되면 Bluetooth가 자체적으로 작동을 유지하므로 Power HAL은 더 깊은 시스템 절전 상태(예:RAM 정지)를 허용할 수 있다는 것을 알고 있습니다.

진짜 마법은 사용자가 이 중 어떤 것도 알아차리지 못한다는 것입니다. 휴대전화는 '잠자기' 상태로 표시되고, 디스플레이는 꺼지고, CPU 코어는 게이트 상태로 표시될 수 있지만 Bluetooth 오디오는 계속 재생되고, 스마트워치는 계속 동기화되며, 휴대전화는 계속 검색 가능합니다.

거의 시적이에요. 메인 프로세서는 꿈을 꾸고 있고 컨트롤러는 부드럽게 웅웅거리며 아무 일도 없었던 것처럼 재생목록이 계속 재생됩니다.

실제 Android 기기에서 이를 확인하려면 다음 명령을 사용하세요.

adb shell cat /sys/kernel/debug/wakeup_sources | grep bt

bt_wake이 보이면 스트리밍 중에도 카운터가 낮게 유지됩니다. 축하합니다! 저전력 섬 오프로드가 제 역할을 훌륭하게 수행하고 있습니다.

다음 섹션에서는 펌웨어 깊이에서 다시 올라가 이 모든 것이 일상적인 개발자의 세계에 어떻게 적용되는지 살펴보겠습니다. 앱 또는 시스템 개발자로서 실제로 이러한 소켓 설정을 직접 제어하거나 이점을 얻을 수 있습니까? 그리고 이를 이해하는 것이 전력 소모가 아닌 한 모금 마시는 Bluetooth 앱을 구축하는 데 어떻게 도움이 될 수 있습니까?

개발자가 BluetoothSocketSettings를 활용하는 방법

이제 Bluetooth 스택의 핵심을 자세히 살펴보았으므로 여러분과 제가 실제로 살고 있는 개발자 계층으로 다시 올라가겠습니다. "그렇습니다. 하드웨어의 마법은 모두 멋지지만 실제로 무엇을 할 수 있습니까?"라고 궁금해하실 수도 있습니다. 그걸로?”

재미있는 부분은 다음과 같습니다. Low Power Island는 대부분 시스템 수준 기능이지만 작동 방식을 이해하면 더욱 전력 친화적이고 예측 가능한 Bluetooth 앱을 설계하는 데 도움이 됩니다.

프레임워크 수준에서는 앱에서 LPI를 직접 켜거나 끌 수 없습니다. 이러한 스위치는 BluetoothService 및 BluetoothSocketManagerService와 같은 시스템 구성 요소 깊은 곳에 있습니다. 하지만 BluetoothSocket을 사용할 때마다 또는 BluetoothServerSocket , 데이터는 LPI 오프로드가 가능한지 확인하는 레이어를 통해 자동으로 흐릅니다.

즉, CPU가 불필요하게 활성 상태를 유지하도록 하는 어떠한 조치도 취하지 않는 한 앱이 자동으로 혜택을 받습니다. . 예를 들어, 적절한 스레드 절전을 사용하고, 사용 중인 루프를 피하고, Android 자체 Bluetooth I/O 스트림이 버퍼링을 처리하도록 하면 오프로드 논리의 장점을 유지할 수 있습니다.

Bluetooth 소켓을 연결하는 동안 AOSP의 시스템 서버 로그를 자세히 살펴보면 다음과 같은 내용을 확인할 수 있습니다.

BluetoothSocketManager: Offload eligible socket detected, enabling LPI mode
Bluetooth HAL: LPI channel activated for fd=42

이 작은 선은 사용자가 손가락 하나 까딱하지 않고도 소켓이 섬을 통해 조용히 경로가 변경되었음을 나타냅니다.

그 아래에서 프레임워크는 BluetoothSocketSettings을 생성했습니다. 소켓이 열릴 때 개체를 체인 아래로 전달했습니다. 의사 자바에서는 다음과 같습니다:

BluetoothSocketSettings settings =
 new BluetoothSocketSettings(
 BluetoothSocketSettings.DATA_PATH_HARDWARE_OFFLOAD,
 /* hubId */ 1,
 /* endpointId */ 2,
 /* maxPacketSize */ 512);
BluetoothSocket socket = adapter.createSocket(device, settings);
socket.connect();

물론 이는 아직 공개 SDK의 일부는 아니지만 시스템 앱이나 권한 있는 프레임워크는 유사한 호출을 사용하여 트래픽을 처리하는 방법을 설명합니다.

그렇다면 개발자인 당신이 왜 관심을 가져야 할까요? 그러한 경로가 존재한다는 것을 알면 이를 염두에 두고 설계할 수 있기 때문입니다. . 예를 들어 다음과 같은 작업을 할 수 있습니다:

  • 소규모 BLE 쓰기를 하나씩 전송하는 대신 일괄 처리하므로 컨트롤러가 오프로드 버퍼 내에서 효율적으로 처리할 수 있습니다.

  • 스택이 메인 CPU를 반복적으로 깨우게 만드는 빈번한 연결/연결 해제 주기를 피하세요.

  • 저전력 버퍼의 한계 내에 깔끔하게 맞도록 백그라운드 전송을 구성하세요(청크는 더 작고 간격은 더 길게 생각하세요).

기본적으로 데이터 패턴이 예측 가능할수록 호스트를 깨우지 않고 섬에 머물 가능성이 높아집니다.

맞춤형 Android 기기나 내장형 제품과 같은 시스템 소프트웨어를 구축하는 경우에는 훨씬 더 발전할 수 있습니다. HAL 동작을 조정하고, 사용자 정의 허브 또는 엔드포인트 ID를 할당하고, 펌웨어가 DMA 전송에 사용하는 최대 패킷 크기를 조정할 수도 있습니다. 이를 통해 저에너지 원격 측정 스트리밍이나 웨어러블 센서 동기화와 같이 거의 완전히 오프로드로 실행되는 Bluetooth 기능을 구축할 수 있습니다.

그 시점에서 Bluetooth 칩은 메인 OS가 절전 모드인 동안에도 계속 작동하여 놀라운 배터리 수명과 빠른 재연결을 제공하는 미니 서버가 됩니다.

마지막 섹션에서는 모든 것을 마무리하고 BluetoothSocketSettings와 Low Power Island가 함께 Android의 "보이지 않는 엔지니어링"의 가장 우아한 예 중 하나를 나타내는 이유에 대해 큰 그림을 되돌아볼 것입니다. 이는 기조연설에서는 거의 볼 수 없지만 자정에도 휴대전화에 여전히 활력이 남아 있을 때 매일 느끼는 조용한 승리 중 하나입니다.

그랜드 피날레:스마트하게 자는 것의 우아함

잠시 한 발 뒤로 물러서 봅시다. 우리는 과로에 시달리는 바리스타와 함께 커피숍에서 일을 시작했습니다. 그러다가 메인 바리스타가 자리를 비운 후에도 조용히 카페를 운영하는 숨겨진 조수인 저전력 아일랜드(Low Power Island)를 발견했습니다.

우리는 겸손한 Bluetooth 소켓의 경로를 따라가며 BluetoothSocketSettings로 래핑되는 것을 보았습니다. , HAL을 여행하고 마침내 큰 CPU가 꿈을 꾸는 동안 윙윙거리는 컨트롤러 내부의 소형 프로세서에 착륙했습니다.

이것이 바로 장점입니다. Android의 Bluetooth 오프로드 메커니즘은 눈에 보이지 않는 엔지니어링의 가장 우아한 예 중 하나입니다. 새로운 API나 멋진 애니메이션을 발표하지 않습니다. 사용자가 스마트폰이 있는지도 모르는 사이에 조용히 배터리 수명을 연장하고 Bluetooth의 안정성을 높이며 휴대전화의 사용감을 더욱 부드럽게 만들어줍니다.

기술적인 관점에서 볼 때 가장 뛰어난 점은 균형에 있습니다. 시스템은 필요할 때 모든 기능을 갖춘 소켓과 풍부한 프로토콜 처리를 허용하지만 일반적인 데이터 흐름, 오디오, 원격 측정, 알림 또는 심박수 스트리밍의 경우 저전력 컨트롤러가 제어할 수 있습니다. Android가 위임하는 법을 배운 것과 같습니다.

휴대전화 화면이 꺼진 상태에서 스마트워치가 동기화하거나 장거리 비행 중에 배터리를 소모하지 않고 이어폰이 연결된 상태를 유지할 때마다 BluetoothSocketSettings가 표시됩니다. 그리고 저전력 섬(Low Power Island) 프레임워크가 작동 중입니다. 이는 현대 Android 디자인의 더 큰 철학의 일부로서 지능을 하드웨어에 더 가깝게 이동시킵니다. 자율 작업을 처리하도록 칩을 더 많이 가르칠수록 메인 프로세서를 더 많이 쉬게 할 수 있습니다.

개발자나 시스템 엔지니어라면 이 아키텍처를 이해하는 것이 학문적인 것만은 아닙니다. 이는 자신만의 기능을 디자인하는 방법에 영감을 줄 수 있습니다. 맞춤형 Android ROM을 구축하든, 웨어러블용 펌웨어를 최적화하든, Bluetooth 칩이 포함된 IoT 장치를 생성하든 교훈은 분명합니다. 메인 CPU가 모든 패킷을 관리하도록 만들지 마세요. 가능할 때 짐을 내리고, 필요할 때 잠을 자면 기기 가동 시간이 몇 시간 더 늘어납니다.

따라서 다음번에 이어버드를 연결했는데 휴대폰이 시원하게 유지되고 배터리 비율이 거의 움직이지 않는 것을 발견하게 되면 메인 CPU가 저전력 해먹에서 낮잠을 자는 동안 내부 깊은 곳에서 작은 Bluetooth MCU가 모든 무거운 작업을 수행하고 있다는 점을 기억하십시오.

이것이 Android의 Low Power Island 및 BluetoothSocketSettings의 조용한 천재성입니다. 블루투스만의 문제가 아닙니다. 우리의 장치가 더 바쁘지 않고 더 똑똑해지도록 가르치는 것입니다. 그리고 아마도 그것은 우리 자신에게도 기억할 가치가 있는 교훈일 것입니다.

무료로 코딩을 배우세요. freeCodeCamp의 오픈 소스 커리큘럼은 40,000명 이상의 사람들이 개발자로 취업하는 데 도움을 주었습니다. 시작하세요