<2020.04.06> Android_Weekly #408

안드로이드 위클리를 읽고 새로 알게된 개념에 대해 간단히 써놓는 카테고리

 

1. App Standby Buckets

https://medium.com/mindorks/app-standby-buckets-in-android-ada2d2929350

App Standby Buckets In Android

안드로이드 파이(Version 9 API LEVEL 28)에 소개된 Adaptive Battery를 위한 기능.

앱을  4가지 버킷으로 나눠서 관리한다.

1. Activity

- 현재 사용중인 앱, 매우 자주 사용되는 앱

- 시스템은 어플의 작업, 알람, FCM 메세지에 아무런 제약을 두지 않는다.

2. Working set

- 정기적으로 사용하는 앱인데 현재 사용하지 않는 맵.

- 작업 재개나 알람을 트리거하는데 약한 제약을 건다.

3. Frequent

- 종종 사용하나 매일까지는 사용안하는 맵

- 시스템은 이 순위부터 강한 제약을 걸기 시작한다.

4. Rare

-  자주 사용하지 않는 앱

 

+ Doze 허용 목록에 있는 앱은 App Standby Buckets 분류에서 제외된다.

 

+ 이밖에 파이에서 소개된 배터리를 위한 기능은 Background Restrictions(불필요한 백그라운드 사용을 유저가 제한할 수 있는 기능) , Android Vitals(백그라운드 작업 등 배터리를 많이 잡고 있는 것인지 아닌지 체크하는 기능)  가 있다.

 

- 시스템은 동적으로 앱을 적당한 버킷에 배정한다. 우선순위가 높은 버킷에 들어있는 앱이 많을수록 더 많은 시스템 리소스가 필요하다. 부분적으로, 버킷은 어플의 작동주기, 알람, FCM 메세지를 받는 우선순위 를 결정할 수 있다. 이 제약은 배터리를 소모하고 있을 때만 걸리며 시스템은 디바이스가 충전 중일 때는 이 제약을 허용하지 않는다.

시스템은 어플이 얼마나 많이 이용되었는가 판단하는 머신러닝을 사용하는 앱에 의존해서 버킷에 어플을 배정한다.

시스템은 기본적으로는 어플이 얼마나 많이 사용되었는가에 따라 배정한다.

나의 어플은 UsageStatsManager.getAppStandbyBucket(). 함수를 통해 어떤 버킷이 최근에 불렸는지 알 수 있다.

 

- 만약 어플이 런처 액티비티가 없다면, 그 어플은 절대 액티브 버켓으로 승격될 수 없다.

- 어플의 notification이 액셔너블하지 않다면, 유저는 절대 노티피케이션과의 상호작용을 통해 액티브 버켓으로 앱의 프로모션을 트리거할 수 없다.

- 왠만하면 앱을 어느 버킷에 넣을건지 조작하려고하지마라. 시스템의 버케팅 함수가 바뀔 수 있고, 모든 디바이스 관리자는 이것만의 알고리즘을 갖고 그들만의 버케팅 앱을 쓸 수 있다. 대신, 너의 앱은 어떤 버켓에 있던 잘 작동되게 해야한다.

 

2. Kotlin/Native

 

https://www.bignerdranch.com/

Home Page - Digital product development agency | Big Nerd Ranch

https://kotlinlang.org/docs/reference/native-overview.html#target-platforms

Kotlin/Native - Kotlin Programming Language

자바는 Write once, run everywhere이긴 하지만 JVM이 설치되지 않는 운영체제(IOS), 메모리 상 설치할 여건이 안되는 임베디드 시스템 등에는 사용할 수 없었다.

코틀린/네이티브를 사용하면 단일 코틀린 프로그램을 8가지 유형의 기본 바이너리로 컴파일할 수 있다.

생성된 각 바이너리 파일은 특정 대상 플랫폼에서 실행되며, 주의사항은 일부 대상에서는 기본 바이너리를 컴파일 하기위해 특정 유형의 호스트가 필요한 것이다. 따라서 지원되는 8개의 플랫폼 마다 하나씩 8개의 서로 다른 기본 바이너리를 컴파일 하려면 필요한 특정 하드웨어 플랫폼에서 각각 하나를 컴파일 해야한다. (맥에서 하고싶으면 맥용 바이너리를 만들고 맥에서 실행해야 한다)