이 기사에서는 Android의 다중 라이브러리 프로젝트에 대해 이야기하겠습니다. 평범한 일은 아니지만, 평범하지 않은 일도 아니다.
귀하의 작업 분야에서 다중 라이브러리 프로젝트를 접했을 수도 있고, 더 나은 구조와 구성을 위해 라이브러리를 하위 모듈로 변환하려고 할 수도 있습니다. 어떤 경우든 뛰어들기 전에 앞에 무엇이 놓여 있는지 잘 알고 있어야 합니다.
Android에서 자신만의 라이브러리를 작성하는 것은 깔끔합니다. 다른 개발자(또는 자신)에게 도움이 될 수 있는 코드를 작성할 기회가 있습니다.
라이브러리는 그 자체로는 독립형 프로젝트가 될 수 없기 때문에 일반적으로 프로젝트와 애플리케이션이 함께 쌍을 이룹니다. 이를 통해 기능을 추가하거나 버그를 수정한 다음 프로젝트에 있는 애플리케이션으로 직접 테스트할 수 있는 간단한 프로세스로 라이브러리를 개발할 수 있습니다. 따라서 개발자가 라이브러리를 통합하는 방법을 (로컬 방식으로) 시뮬레이션합니다.
하지만 귀하의 라이브러리가 귀하가 개발 중인 다른 라이브러리에 의존한다면 어떻게 될까요?
이를 모르고 있다면 라이브러리(aar 읽기)가 그 안에 다른 로컬 라이브러리를 포함할 수 없다는 점을 알아야 합니다. 종속성을 통해 원격으로 라이브러리에 의존할 수 있지만 로컬에는 의존할 수 없습니다.
이는 Android에서는 지원되지 않으며 수년 동안 일부 솔루션(FatAar)이 등장했지만 이러한 솔루션이 항상 문제를 해결하지는 않았으며 최신 상태도 아닙니다. 이 기능을 요청하는 Google Issue Tracker도 꽤 오랫동안 공개되어 커뮤니티로부터 많은 관심을 받고 있습니다. 하지만 어떤 벽은 허물 수 있고 어떤 벽은 허물 수 없는지 알아보겠습니다.
프로젝트 계층 구조가 다음과 같다고 상상해 보세요:
-- App
|
-- OuterLib
|
--- InnerLib
그렇다면 InnerLib은 원래 프로젝트의 일부가 될 수 없으므로 어디에 상주할 수 있습니까? 그리고 InnerLib 내부에서 기능을 개발하면서 어떻게 로컬에서 작업할 수 있나요?
이 글에서 이러한 질문에 답해보겠습니다.
Git 하위 모듈
대부분의 기술적인 문제에는 항상 하나의 솔루션만 있는 것은 아닙니다. 일반적으로 더 많은 솔루션이 있지만 각 솔루션에는 단점이 있습니다. 결국 하루가 끝날 때 어떤 단점을 더 편안하게 받아들이느냐가 문제입니다.
InnerLib이 어디에 상주할 수 있는지에 대한 첫 번째 질문에 답하기 위해 몇 가지 옵션이 있습니다:
- InnerLib를 원래 프로젝트의 하위 모듈로 만들기
- InnerLib를 자체 원격 종속성으로 만들기
Git의 하위 모듈에 대해 잘 모르는 경우 Git 문서를 참조하여 해당 하위 모듈에 익숙해지는 것이 좋습니다. 인용(첫 번째 단락):
한 프로젝트에서 작업하는 동안 해당 프로젝트 내의 다른 프로젝트를 사용해야 하는 경우가 종종 있습니다. 👉 아마도 제3자가 개발한 라이브러리이거나 별도로 개발하여 여러 상위 프로젝트에서 사용하고 있는 라이브러리일 수 있습니다. 👈 이러한 시나리오에서는 일반적인 문제가 발생합니다. 두 프로젝트를 별도로 처리하면서도 다른 프로젝트 내에서 하나를 계속 사용할 수 있기를 원합니다.
이 단락은 이것이 바로 우리의 사용 사례임을 보여줍니다. 하위 모듈을 사용하면 이점이 있습니다. 모든 코드가 한 곳에 있고, 관리하기 쉽고, 로컬에서 쉽게 개발할 수 있습니다.
그러나 하위 모듈에는 몇 가지 약점이 있습니다. 하나는 서브모듈이 어느 분기를 가리키는지 항상 알고 있어야 한다는 사실입니다. 기본 저장소의 릴리스 분기에 있고 하위 모듈이 기능 분기에 있는 시나리오를 상상해 보세요. 눈치채지 못한다면 프로덕션 준비가 되지 않은 코드 버전을 릴리스하게 됩니다. 이런.
이제 개발자 팀 내에서 이에 대해 생각해보십시오. 한 번의 부주의한 실수는 큰 대가를 치르게 할 수 있습니다.
첫 번째 옵션이 문제가 된다고 생각되면 라이브러리를 다른 저장소에 호스팅하는 것이 두 번째 선택입니다. 저장소를 설정하는 것은 매우 간단합니다. 그런데 이제 로컬에서는 어떻게 작업합니까?
현지에서 일하기
이제 프로젝트가 올바르게 설정되었으므로 OuterLib build.gradle 파일에 다음과 유사한 줄이 있을 것입니다.
dependencies {
implementation 'url_to_remote_inner_lib_repository'
}
개발 주기를 효율적이고 쉽게 작업할 수 있도록 하려면 어떻게 해야 합니까? InnerLib에서 일부 기능을 개발하는 경우 OuterLib에서 어떻게 테스트하나요? 아니면 우리 애플리케이션에서?
나타날 수 있는 한 가지 해결책은 InnerLib 프로젝트에서 InnerLib .gitignor를 무시하면서 InnerLib을 OuterLib 프로젝트로 로컬로 가져오는 것입니다. Android Studio의 왼쪽 메뉴에서 프로젝트 이름을 마우스 오른쪽 버튼으로 클릭하고 New(새로 만들기) → Module(모듈)로 이동하면 쉽게 수행할 수 있습니다.
모듈을 가져오는 방법(1단계)
그런 다음 열리는 창에서 왼쪽 하단에 있는 가져오기 옵션을 선택할 수 있습니다:
모듈을 가져오는 방법(2단계)
지금까지는 쉽고 간단해 보이지만, 중요한 점은 무엇입니까?
InnerLib에 속한 파일을 수정할 때마다 변경 사항은 무시되므로 InnerLib 내부에 반영되지 않습니다. 따라서 수행하려는 각 변경 사항은 InnerLib 내부에서 발생해야 하며 그런 다음 변경 사항을 보려면 OuterLib 내부로 다시 가져와야 합니다.
이것은 옳지 않은 것 같습니다. 더 나은 방법이 있을 것입니다.
settings.gradle에 몇 줄만 입력하면 됩니다. 파일을 사용하면 InnerLib에서 변경 사항을 적용할 때 파일이 동기화 상태를 유지하는지 확인할 수 있습니다.
InnerLib를 프로젝트로 가져올 때 Android Studio는 InnerLib의 복사본을 만들어 캐시했습니다. 이것이 바로 우리가 라이브러리 내부에서 변경한 모든 사항에 대해 라이브러리를 다시 가져와야 하는 이유입니다. projectDir을 사용하여 Android Studio에서 파일을 참조할 위치를 알려줄 수 있습니다. 속성.
settings.gradle은 다음과 같습니다:
include ':outerLib', ':innerLib', ':app'
InnerLib을 로컬에서 참조하려면 settings.gradle을 다음과 같이 변경해야 합니다:
include ':outerLib', ':innerLib', ':app'
project('innerLib').projectDir = new File('PATH_TO_INNER_LIB')
이 접근 방식을 사용하면 InnerLib 파일이 작업 디렉터리에 연결되므로 모든 변경 사항이 즉시 반영됩니다.
그러나 우리는 InnerLib의 원격 버전을 사용하여 OuterLib에서 로컬로 작업할 때 유연성을 원합니다. 위에서 settings.gradle 파일에 작성한 내용은 로컬에서만 작업할 수 있도록 허용하며 그대로 커밋하고 싶지는 않습니다.
메이븐 로컬
위의 접근 방식이 귀하에게 적합하지 않다면 다른 방법을 취할 수 있습니다. Maven을 사용하여 라이브러리를 공개적으로 게시하는 것과 마찬가지로 Maven Local을 사용하여 로컬에서 동일한 작업을 수행할 수 있습니다. Maven 로컬은 컴퓨터에 로컬로 위치하는 저장소 세트입니다.
다음은 컴퓨터의 운영 체제에 따른 mavenLocal 경로입니다:
- 맥 → /Users/YOUR_USERNAME/.m2
- 리눅스 → /home/YOUR_USERNAME/.m2
- Windows → C:\Users\YOUR_USERNAME.m2
본질적으로 라이브러리를 로컬로 게시한 다음 프로젝트에 연결할 수 있습니다. 이런 식으로 프로젝트를 InnerLib에 연결할 수 있습니다.
프로젝트에서 이 구성을 허용하려면 다음 작업을 수행해야 합니다:
- mavenLocal() 추가 repositories 절 내의 저장소로 사용됩니다. 이는 우리 프로젝트가 로컬에서 저장소를 검색하는 기능을 허용하기 위한 것입니다.
buildscript {
repositories {
mavenLocal()
}
}
...
allprojects {
repositories {
mavenLocal()
}
}
-
InnerLib를 원격으로 참조하는 것처럼 참조하도록 종속성 절 내부의 구현 라인을 변경하세요.
-
InnerLib을 로컬로 게시하기 위해 다음을 포함하는PublishLocally.gradle이라는 파일을 생성합니다:
apply plugin: 'maven-publish'
project.afterEvaluate {
publishing {
publications {
library(MavenPublication) {
setGroupId groupId //your library package
setArtifactId artifactId
version versionName //I.E. 1.0
artifact bundleDebugAar
pom.withXml {
def dependenciesNode = asNode().appendNode('dependencies')
def dependencyNode = dependenciesNode.appendNode('dependency')
dependencyNode.appendNode('groupId', 'your_group_id')
dependencyNode.appendNode('artifactId', 'your_artificat_id')
dependencyNode.appendNode('version', 'your_version')
}
}
}
}
}
- 애플리케이션 수준 build.gradle 파일 내에 다음 줄을 추가하세요.
apply from: '/.publishingLocally.gradle
이 옵션이 사실이라고 믿기에는 너무 좋은 것 같다면 사실입니다 . 한편으로는 마치 원격 도서관에서 작업하는 것처럼 로컬에서 원활하게 개발할 수 있습니다. 반면에 로컬로 작업하는 동안 InnerLib 내부에서 변경 사항이 발생하면 다시 로컬로 게시해야 합니다. 비용이 많이 드는 작업은 아니지만 지루한 작업을 반복해서 수행해야 하는 필요성이 발생합니다.
로컬 및 원격 작업을 위한 솔루션
우리는 로컬에서 변경 사항이 있을 때마다 InnerLib 패키지를 계속 다시 게시해야 하는 필요성을 피하고 싶습니다. 우리는 프로젝트에서 이러한 변경 사항을 인식할 수 있는 방법을 찾아야 합니다.
로컬 작업 섹션에서 그 방법을 알아냈지만 settings.gradle 파일을 커밋하는 데 문제가 있었습니다. InnerLib을 사용하여 로컬 및 원격으로 작업할 수 있도록 이 문제를 해결하기 위해 gradle.properties에서 정의할 매개변수를 사용합니다. 파일입니다.
gradle.properties 파일은 개발 환경을 구성하는 프로젝트 수준 설정을 저장할 수 있는 장소입니다. 이는 팀의 모든 개발자가 일관된 개발 환경을 갖도록 하는 데 도움이 됩니다.
이 파일 내에 있는 익숙할 수 있는 일부 설정은 AndroidX 지원(android.useAndroidX=true) 또는 JVM 인수(org.gradle.jvmargs=-Xmx1536m)입니다.
상황을 해결하는 데 도움이 되도록 여기에 매개변수를 추가하여 로컬로 작업할지 여부를 나타낼 수 있습니다. 다음과 같은 내용이 있습니다:
workingLocally = false
이 매개변수를 사용하면 로컬 또는 프로덕션 코드로 작업 중인 설정을 구별할 수 있습니다. 먼저 매개변수가 true인지 확인하는 조건으로 래핑하여 settings.gradle 파일에 있는 내용을 변경해 보겠습니다.
include ':outerLib', ':innerLib', ':app'
if (workingLocally.booleanValue()) {
project('innerLib').projectDir = new File('PATH_TO_INNER_LIB')
}
이런 식으로 우리는 InnerLib용 파일을 우리 컴퓨터에서 로컬로 가져오도록 프로젝트에 지시합니다.
로직을 변경해야 하는 또 다른 곳은 build.gradle 파일입니다. 여기에서는 종속성 블록에서 코드를 원격으로 라이브러리에 가져오는 대신 로컬에서 의존하는지 여부를 나타낼 수 있습니다.
dependencies {
if (workingLocally.booleanValue()) {
implementation 'innerLib'
} else {
implementation 'url_to_remote_repository'
}
}
⚠️ 경고:로컬에서 작업할 때 gradle.properties 파일을 커밋해서는 안 됩니다.
여행은 길었고 꽤 지쳐 보였을 수도 있습니다. 하지만 이제 우리는 여러 도서관 프로젝트에서 로컬 및 원격으로 작업할 수 있는 완벽한 설정을 갖추고 있습니다.
문제가 발생하거나 이에 대한 의견을 제시하고 싶다면 언제든지 의견을 남겨주세요.
무료로 코딩을 배우세요. freeCodeCamp의 오픈 소스 커리큘럼은 40,000명 이상의 사람들이 개발자로 취업하는 데 도움을 주었습니다. 시작하세요