카테고리 보관물: Android

안드로이드 지원(support) 라이브러리 구글 메이븐 리파지토리

구글이 지원(support) 라이브러리 다운로드를 위해서 자체 메이븐 리파지토리를 구축해서 25.4.0 버전부터는 구글의 메이븐 리파지토리에서 다운로드 받을 수 있다. 주소는 maven.google.com 이다. 그래서 안드로이드 프로젝트 build.xml 파일에 아래와 같이 구글의 리파지토리도 추가한다.

allprojects {
  repositories {
  jcenter()
  maven { url "https://jitpack.io" }
  maven { url "https://maven.google.com" }
  }
}

https://maven.google.com에 접속하면 https://dl.google.com/dl/android/maven2/ 로 리다이렉트 된다. 구글 메이븐 리파지토리는 서버에서 리스팅 기능을 제공하지 않아서 호스팅 하는 전체 라이브러리를 볼 수 가 없다.

그래서 지원 라이브러리 중에 appcompat-v7 에 대해서 약간의 정보를 살펴봤다.

메타 데이터 정보
https://dl.google.com/dl/android/maven2/com/android/support/appcompat-v7/maven-metadata.xml

라이브러리 파일
https://dl.google.com/dl/android/maven2/com/android/support/appcompat-v7/25.4.0/appcompat-v7-25.4.0.aar

그리고, 구글 지원 라이브러리 종류는 아래에서 확인할 수 있고, 위의 패턴으로 개별 라이브러리를 확인할 수 있다.
https://developer.android.com/topic/libraries/support-library/packages.html

안드로이드 페브릭(Fabric) 그래들(Gradle) 플러그인 버전 지정하기

페브릭(Fabric)은 아주 유용한 기능을 모바일 플랫폼에 쉽게 적용할 수 있게 도와주는 서비스이다. Crashlytics도 페브릭에서 제공하는 크래시 리포트 서비스이다. Crashlytics을 안드로이드에서 사용하는 방법은 fabric.io/kits/android/crashlytics/install 에서 확인할 수 있다. 여기에서 아래의 아래의 코드를 추가하라고 한다.

buildscript {
repositories {
maven { url 'https://maven.fabric.io/public' }
}

dependencies {
// These docs use an open ended version so that our plugin
// can be updated quickly in response to Android tooling updates

// We recommend changing it to the latest version from our changelog:
// https://docs.fabric.io/android/changelog.html#fabric-gradle-plugin
classpath 'io.fabric.tools:gradle:1.+'
}
}

위 코드를 보면 알겠지만, 페브릭의 그래들 플러그인 버전이 ‘io.fabric.tools:gradle:1.+’로 선언되어 있다. 주석을 읽어보면 알겠지만, docs.fabric.io/android/changelog.html#fabric-gradle-plugin 에서 최신 버전으로 수정하라고 한다. 이 문서를 보면, 아래와 같이 최신 버전을 확인할 수 있고, 변경 내용도 확인할 수 있다.

2017년 6월 14일에 확인해 본 결과로 1.22.2 버전이 최신버전이다.

위 과정에 더불어, 페브릭 그래들 플러그인에 대한 메타 정보는 아래 URL에서 확인할 수 있다.
fabric-artifacts.s3.amazonaws.com/public/io/fabric/tools/gradle/maven-metadata.xml

위 이미지에서 최신 버전 릴리즈 시점이 2017년 05월 31일 이라는 것도 알 수 있다.

결론으로 app 모듈에서 build.gradle 파일의 맨 처음은 아래와 같은 모습이 될 것이다.

buildscript {
    repositories {
        jcenter()
        maven { url 'https://maven.fabric.io/public' }
    }

    dependencies {
        classpath 'com.android.tools.build:gradle:2.3.3'

        classpath 'io.fabric.tools:gradle:1.22.2'
    }
}

앱(APK) 크기를 줄이는 또 다른 방법

앱 크기를 줄이는 팁으로 사용하지 않는 이미지, Proguard 사용 등의 여러 가지 방법이 있다. 이 방법들 모두는 결국 zip 포맷으로 패키징되는 파일을 개수나 크기를 줄여서 .apk 파일의 크기를 줄이는 것이다. 이 글에서는 .apk 파일이 포함하는 또 다른 파일인 텍스트 파일을 제거해서 앱의 크기를 줄이는 방법을 살펴보자. 텍스트 파일이라서 앱 크기에 큰 영향을 미치지는 않지만, 그래도 약간의 크기를 줄일 수 있는 또 다른 방법으로 알아두면 좋겠다.

이 방법은 안드로이드 스튜디오에서 빌드와 패키징을 담당하는 툴인 그레들의 빌드파일(build.gradle)에 packagingOptions{} 영역에 패키징시에 제외할 파일을 기술하는 것이다. 이 설정은 아래와 같이 동일 파일의 중복으로 인한 에러를 해결하는데 또한 사용한다.

Error:Execution failed for task ':app:transformResourcesWithMergeJavaResForDebug'.
> com.android.build.api.transform.TransformException: com.android.builder.packaging.DuplicateFileException: Duplicate files copied in APK META-INF/DEPENDENCIES

그래서, 위 에러를 해결하기 위한 최소의 설정은 다음과 같다.

android {
    packagingOptions {
        exclude 'META-INF/DEPENDENCIES'
        exclude 'META-INF/LICENSE'
    }
}

컴파일한 앱의 크기를 확인해 보면, 크기가 9,154,124 바이트이다.

다음으로 어느 파일을 제외할 수 있는지 살펴보자. 안드로이드 스튜디오에서 Build > Analyze Apk 로 위의 파일을 선택하면 아래의 화면을 볼 수 있다.

위 화면에서 체크한 파일들을 앱 패키징시에 제외시키도록 packageOptions에 추가하자. 그리고 일반적으로 많이 사용하는 텍스트 파일도 역시 미리 포함시켜 넣어서 아래와 같이 설정한다.

android {
	packagingOptions {
	    exclude 'META-INF/DEPENDENCIES.txt'
	    exclude 'META-INF/DEPENDENCIES'
	    exclude 'META-INF/dependencies.txt'
	    exclude 'META-INF/LICENSE.txt'
	    exclude 'META-INF/LICENSE'
	    exclude 'META-INF/license.txt'
	    exclude 'META-INF/LGPL2.1'
	    exclude 'META-INF/ASL2.0'
	    exclude 'META-INF/NOTICE.txt'
	    exclude 'META-INF/NOTICE'
	    exclude 'META-INF/notice.txt'
	    exclude 'META-INF/MANIFEST.MF'
	    exclude 'META-INF/manifest.mf'
	    exclude 'META-INF/MANIFEST'
	    exclude 'META-INF/manifest'

	    exclude 'META-INF/CHANGES'
	    exclude 'META-INF/README'
	    exclude 'META-INF/NOTES.TXT'

	    exclude 'licenses/thoughtworks.TXT'
	    exclude 'licenses/extreme.indiana.edu.license.TXT'
	    exclude 'licenses/javolution.license.TXT'
	}
}

이제 다시 패키징한 파일을 살펴보자. 필요 없는 텍스트 파일들을 제외하고, 컴파일한 파일의 크기는 9,137,085 바이트이다.

이 과정으로 앱의 크기가 17,000 바이트를 줄일 수 있다. 이 과정으로 메가 바이트 단위로 앱의 크기를 줄이기는 힘들겠지만, 약간이나마 크기를 줄이는데 기여할 수 있다.

멀티 dex 사용하기

안드로이드(Android) 앱(APK) 파일은 DEX(Dalvik Executable) 파일 형식의 실행 가능 바이트코드 파일을 포함하고 있다. 개별 .dex파일은 사용할 수 있는 메서드의 총 개수가 65,536로 제한되어 있다. 그래서 이 제한을 보통 ’64K 참조 제한’이라고 한다.

안드로이드 스튜디오의 메뉴에서 Build > Analyze APK… 를 선택하면 .apk 파일을 구성하는 것들을 자세히 살펴볼 수 있고, 이 제한을 넘어서 더 많은 메서드등을 사용하는데는 2개 이상의 .dex 파일이 필요하다. 그래서 2개 이상의 .dex 파일을 생성하도록 앱 빌드 프로세스를 구성해야 하며, 이것을 multidex 구성이라고 한다. 아래 이미지를 보면, classes.dex와 classes2.dex파일로 .dex 파일이 2개 있는 것을 알 수 있다. 

안드로이드 앱에서 멀티 dex를 사용하는 방법은 3가지의 형태가 있을 수 있다. 첫번째가 Application 클래스를 사용하지 않는 경우, 두번째는 Application 클래스를 사용하는 경우, 그리고 마지막은 MultiDexApplication 클래스를 사용하는 경우이다.

멀티 dex를 사용하는데 필요한 과정의 기본은 build.gradle 파일에 multidex 라이브러리를 추가하고, multidexEnabled 옵션을 true로 설정하는 것이다.

android {
	defaultConfig {
		multiDexEnabled true
	}
}

dependencies {
	compile 'com.android.support:multidex:1.0.1'
}

이제 위 설정이 완료됐으면, 멀티 dex를 사용하는 3가지 형태에 대해서 살펴보자.

1. Application을 사용하지 않는 경우

이 경우에는 아래의 코드를 AndroidManifest.xml 파일에 아래처럼 Application을 설정해야 한다.



    
        ...
    

2. Application을 사용하는 경우

프로젝트의 AppApplication 클래스가 Application을 상속해서 구현하고 있다고 가정한다. 이 경우에는 아래와 같은 코드가 AndroidManifest.xml 파일에 설정해야 한다.



    
        ...
    

그리고, AppApplication 에 아래의 코드를 추가한다.

@Override
protected void attachBaseContext(Context base) {
	super.attachBaseContext(base);
	MultiDex.install(this);
}

3. MultiDexApplication을 사용하는 경우

이 경우가 가장 간단하게 사용할 수 있다. AndroidManifest.xml은 위 2.와 동일하게 설정한다. 그리고, 아래처럼 Application 클래스가 MultiDexApplication을 상속하면 된다.

public class AppApplication extends MultiDexApplication {
}

어떻게 MultidexApplication만 상속하면 돼는지, 이 클래스의 소스를 살펴보면 다음과 같다.

package android.support.multidex;

import android.app.Application;
import android.content.Context;
import android.support.multidex.MultiDex;

public class MultiDexApplication extends Application {
	public MultiDexApplication() { 
	}

	protected void attachBaseContext(Context base) {
		super.attachBaseContext(base);
		MultiDex.install(this);
	}
}

이 소스를 보면, Application에서 사용하는 코드를 제공하는 래퍼 클래스임을 알 수 있다. 결론으로, Application 클래스를 사용하는 것은 꽤 유용하므로, 개인적으로 3번째 방법을 사용해서 멀티 dex를 제공하는 것이 좋겠다.

안드로이드 7.0 AsyncTask 개선점

안드로이드 7.0 누가(NOUGAT)에서 AsyncTask의 개선 점을 살펴보자. 안드로이드 6.0 AsyncTask 소스와 7.0 소스의 차이를 확인(Diff)해 보면, 아래 화면에서 보는 2가지 정도의 차이가 있다. 차이를 살펴보면 다음과 같다.

1. 작업을 처리하는 스레드의 상수 수정.

코드를 살펴보면, CORE_POOL_SIZE와 KEEP_ALIVE의 값이 수정된 것을 확인할 수 있다. CORE_POOL_SIZE가 주석에서 보다시피 2~4개 유지하게 변경했고, 작업 처리 스레드의 종료시기를 늦추는 것을 알 수 있다.

2. ThreadPoolExecutor 수정.

ThreadPoolExecutor는 작업을 처리하는 여러 스레드를 유지하고, 작업을 큐로 유지하는 디스패처이다. 아래는 위에서 변경한 상수로 ThreadPoolExecutor를 생성하는 예제로, 작업이 추가되지 않는다면 30초 뒤에 스레드 풀의 스레드를 종료시킨다.