Godot: Android 수출의 미래에 대해

나는 제안 2에 투표합니다.

apk 내보내기 메커니즘을 리팩토링하는 것에 대해 이야기하고 있다면 Godot 엔진에 어떤 기능이 없는지 아는 것이 중요할 수 있습니다:

1. APK 동적 콘텐츠 : 더 가벼운 APK 생성 허용
2. Google Instant App : 사용자가 게임/앱을 설치하지 않고도 플레이할 수 있습니다.
3. 적응형 아이콘 : 최신 Android(Android P 및 일부 Android 7.1 이상)에는 적응형 아이콘이 필요합니다.
4. 충돌 처리기: Godot 엔진에 충돌 API가 없습니다. Godot 엔진이 충돌할 때 사용자가 선호하는 충돌 분석 응용 프로그램으로 보낼 수 있는 기능을 노출해야 함을 의미합니다
5. 이제 ANR이 충돌 하므로 게임이 시작될 때 UIThread 대신 AsyncTask를 사용해야 합니다.

내보내기 메커니즘을 리팩토링하는 동안 이러한 기능도 Godot 엔진에 추가해야 합니다.

내 투표 => 2

아마도 하이브리드?
디버그 모드에서 테스트할 SDK를 찾을 수 없지만 릴리스 패키지용 SDK를 설치해야 하는 경우 이전 접근 방식을 사용합니다. SDK가 발견되면 디버그 및 릴리스 모드에서 사용하십시오.
Android에서 작업하는 경우 항상 요구 사항이기 때문에 2에 투표합니다.

@xsellier 나는 이 주장의 요점이 OP에서 제안된 것을 넘어서지 않는다는 점에 감사하고 싶습니다. 누군가가 당신이 언급한 것을 구현하고자 한다면 괜찮지만 탈선하지 않도록 합시다.

@HeartoLazor 유지 관리할 코드가 적

나는 또한 제안 2에 투표합니다.

Android 도구를 설정하면 새 SDK 다운로드 및 외부 라이브러리 구축과 같은 많은 작업이 매우 수월해집니다.

또한 타사 라이브러리를 추가하는 것이 더 쉬울 것입니다.

나는 옵션 2에 투표합니다

옵션 2가 훨씬 더 편리하게 들립니다. Gradle은 라이브러리를 추가하고 빌드 프로세스를 관리하는 것이 현재 흐름보다 훨씬 쉬운 훌륭한 도구입니다.

내 투표는 제안 2에 대한 것입니다.

나는 한 번 2.x용 애드온으로 안드로이드 템플릿 생성기를 만든 적이 있습니다.
https://github.com/vinod8990/godot-addon-aetc

그러나 나는 제안 2에 투표합니다.
표준을 만들면 모듈에서 api도 제거해야 합니다. 네이티브 플러그인을 제거해야 할 때(Unity의 경우와 같이) 거대한 PIA입니다.

투표 -> 제안 2: 가장 논리적인 선택인 것 같습니다. Godot는 현재와 가까운 장래에 모바일 개발을 위한 최고의 게임 엔진이며 Android 및 모바일 플랫폼으로 내보낼 때 더 나은 admob/도구 통합이 필수입니다.

iOS 내보내기도 개선된다는 뜻인가요? 적어도 가까운 장래에.

소품 2에 투표: Firebase용 google-services.json 또는 facebook API용 strings.xml 사용자 지정과 같은 애플리케이션별 파일로 apk를 다시 빌드하려면 일부 라이브러리 통합이 필요합니다. Godot 2에서 SConstruct/SCsub/methods.py 패치와 일부 lib를 적절하게 통합하기 위한 템플릿 파일이 있었습니다.

여기엔 대부분 동의하는듯.. 그래서 APK 해킹은 없어져야 하고 내보내기 템플릿은 Gradle이 실행되기 전에 거의 Android 디렉토리가 되어야 합니다..

옵션 #2에 대한 제안이나 PR을 할 사람이 있습니까? :)

글쎄, 순간에 나는 공유 및 Admob 모듈을 추가하는 데 많은 고통을 겪었습니다. 왜냐하면 현재로서는 텍스처의 get_data 메소드에 버그가 있으므로 컴파일 후 손실되기 때문입니다.

또한 Java, gradle 및 기타 문제가 모두 함께 작동하도록 하려면 특정 구성이 있어야 하지만 어렵습니다.

또한 3.1에서 변경될 몇 가지 문제 때문에 Android에 대한 팁이 포함된 페이지를 갖는 것은 간단한 속도를 적용하는 대신 위치를 변경하기 위해 많은 것을 다시 작성해야 하기 때문에 어떤 셰이더 방법을 사용할 수 있고 보다 유동적인 물리학을 갖는 것이 좋을 것입니다. 또한 큰 걸음이 될 것입니다.

따라서 안드로이드에 최적화하기 위한 체크박스가 있는 #2는 훌륭할 것입니다.

물론 이 모든 수출 환경을 만드는 노력에 감사드립니다.

2번이 더 깔끔해 보이기 때문에 미래에 문제를 일으킬 수 있는 해킹 작업을 계속하는 것보다 낫다고 생각합니다.
내 유일한 걱정은 배포 시간입니다. 현재 Android에서 테스트하는 것은 정말 빠르며 기본적으로 자산의 크기에 따라 다릅니다. 옵션 2가 빌드 시간에 심각한 영향을 줍니까?
어쨌든 나는 여전히 그것이 갈 길이라고 생각합니다. 테스트를 위해 장면/스크립트 동기화에 더 의존하는 문제입니다.

Google Play에서는 항상 최신 Android SDK로 apk를 빌드해야 하므로 제안 2가 훨씬 좋습니다.

또한 GDnative는 Amazon, Leadbolt 등의 타사 IAP 및 광고와 통합하려고 할 때 고통스럽습니다.

제안 2는 확실합니다.

Cordova 및 Flutter 와 같은 일부 대규모 프로젝트에서는 이미 유사한 접근 방식을 사용하고 있습니다. 사용자가 APK 생성을 더 많이 제어하려는 경우 Android Studio에서 프로젝트를 열 수 있는 좋은 옵션이 있습니다.

옵션 2는 더 깨끗하고 Godot의 나머지 부분과 비슷해 보입니다... 즉, 제대로 수행되었습니다.

나는 방금 안드로이드 내보내기를 작동시키는 고통을 겪었습니다. 가장 고통스러운 것은 올바른(버전의) 도구를 설치하는 것이었습니다. Godot에서 설정하는 것은 쉬웠습니다.
제 책에서 올바른 작업을 수행하는 데 올바른 도구를 설치하는 것과 비슷한 정도의 고통이 수반된다면 여전히 올바른 방향으로 나아가는 단계이므로 #2에 투표합니다.
디버깅을 위해 Android에서 실행하는 속도에 대한 우려를 공유하지만 결국 스토어에 출시할 수 없다면 해결해야 할 큰 문제입니다. 출시할 준비가 되면 스토어를 사용할 수 있는지 알아야 합니다.

확실히 # 2 :)

저는 옵션 2를 지지합니다. Android sdk를 설치하는 것은 문제가 아니며 다른 많은 가능성을 열어줍니다.

높은 수준에서 Flutter가 작업을 수행하는 방식과 유사해 보입니다( https://github.com/flutter/buildroot).

옵션 #2는 매번 각 프로젝트에 대한 Android apk 파일을 내보내려면 C++ 및 Java 코드를 포함하는 전체 엔진을 컴파일해야 한다는 것을 의미합니까?

그것은 재앙이 될 것입니다! Cocos Creator는 이러한 끔찍한 작업 흐름을 사용합니다.

@Geequlim 내가 올바르게 이해한다면 C++가 아니라 Java.

저는 옵션 #1에 찬성합니다. 어떤 실험이나 디버그 워크플로를 수행할 때입니다. 이러한 Android 번들이 작은 프로젝트를 디버그하는 것을 원하지 않습니다. 해킹 방식을 유지하십시오. 프로그래머가 SDK 워크플로를 수행하게 하십시오.

@Geequlim 네, 그것도 제 관심사입니다. 프로젝트를 다시 컴파일하고 apk로 압축해야 하는 경우 매번 시간이 많이 걸릴 것 같습니다.

@Geequlim @JFonS 전체 재컴파일이 필요하지 않습니다. Gradle에는 빌드 시간 최적화가 많이 있으므로 전체 컴파일(C++ 및 Java)은 처음에만 필요합니다. 또한 타사 플러그인을 적용하면 Java 코드가 수정되고 Gradle은 변경된 파일이 거의 없고 종속성이 하나 추가된 것을 확인하고 변경된 부분만 다시 컴파일합니다. 대부분의 경우 내보내기 프로그램은 프로젝트 리소스(장면, 스크립트 및 자산)를 Android 폴더에 복사합니다. Gradle은 캐시된 소스 파일과 이 리소스에서 APK를 압축하여 Android 기기에서 실행하므로 시간이 그렇게 많이 걸리지 않습니다.

@veloc1 우리는 여전히 asset lib에서 테스트 데모를 위해 각 프로젝트 이벤트에 대해 구멍 엔진을 컴파일해야 합니까?

Gradle 빌드 워크플로는 여러 가지 이유로 중단될 수 있습니다.

• 잘못된 버전의 SDK가 설치되었습니다.
• 네트워크 연결이 좋지 않으면 종속성을 다운로드할 수 없습니다(이는 실제로 중국에서 프록시 없이 자주 발생함).
• 시스템의 사용 가능한 메모리는 4GB 미만이지만 일부 타사 SDK는 multiDexEnabled true 를 컴파일할 수 있도록 설정해야 합니다.
• ...

그리고 gradle이 항상 예상대로 다시 컴파일되는 것은 아닙니다.

내가 틀릴 수도 있지만 # 1은 우유 한 잔이고 # 2는 젖소라고 생각합니다. 제가 맞습니까?

@Geequlim 상상할 수 있듯이 전체 엔진을 다시 컴파일할 필요가 없습니다. 모든 코드는 라이브러리에 패킹될 수 있습니다(따라서 각 Godot 릴리스는 Godot 엔진으로 안드로이드 라이브러리를 재구축해야 합니다). 프로젝트가 생성되면 Godot 편집기는 하나의 Java 클래스가 있는 "android" 폴더에 Android 템플릿의 압축을 풀 수 있고 maven의 Godot 엔진 Android 종속성이 포함된 Gradle 파일을 압축 해제할 수 있습니다(React Native는 내가 기억한 것과 동일한 방식으로 작동합니다).
이렇게 하면 빌드 시간, 메모리 사용량을 최소화하고 Android 프로젝트의 단순성을 개선할 수 있습니다.

하지만 맞습니다. 여기에는 많은 제한 사항도 포함됩니다.

고장 가능성이 있는 목록에 대한 몇 가지 의견:

• SDK는 Godot 엔진이 새로운 SDK의 많은 기능을 사용하지 않기 때문에 많은 역할을 하지 않습니다. 간단한 프로젝트의 경우 거의 모든 SDK가 괜찮습니다. 또한 적절한 SDK 다운로드를 자동화할 수 있습니다.
• 당신이 설명한 의존성 문제는 고통스러울 수 있습니다. maven의 링크로 종속성을 포함할 수 있지만 프로젝트 폴더에 라이브러리 파일(jar 또는 aar)을 넣고 종속성을 사용할 수 있으므로 네트워크 연결이 좋지 않으면 다른 위치에 있는 모든 종속성을 다운로드하고 USB 스틱에 넣고 이동할 수 있습니다. 프로젝트에. 그러나 이것은 수출 문서에 크게 설명되어야 합니다.
• Multidex와 메모리는 서로 영향을 미치지 않습니다. Multidex는 템플릿 프로젝트에서 항상 활성화할 수 있습니다. 메모리는 더 강력한 제한이 될 것입니다. 사용 가능한 메모리의 양을 정확히 말할 수는 없지만 2GB 이상이어야 합니다.

그리고 Godot에서 구현해야 하는 변경 사항에 대한 요약이 있습니다(위에서 설명한 방법에 따라):

• 엔진 및 플러그인 시스템이 포함된 Android 라이브러리를 만듭니다. (이것은 어렵다)
• 릴리스 시 Android 라이브러리 구축을 자동화하고 maven에 넣습니다.
• 안드로이드 프로젝트 템플릿을 만듭니다.
• 환경 검증을 위한 스크립트 세트 수집, Gradle, Java, Android SDK 다운로드
• Godot 엔진을 변경하여 사용자가 Android 기기에서 프로젝트를 실행할 때 엔진은 모든 리소스를 복사하고 Gradle 작업을 호출하여 프로젝트를 빌드하고 실행해야 합니다.
• 모든 것에 대한 문서.

@Geequlim

옵션 #2는 매번 각 프로젝트에 대한 Android apk 파일을 내보내려면 C++ 및 Java 코드를 포함하는 전체 엔진을 컴파일해야 한다는 것을 의미합니까?

아니.. 그럴 이유가 없어. 지금은 그렇습니다만, 새로운 워크플로는 안드로이드 프로젝트를 미리 빌드된 상태로 가져옵니다(Godot .so 파일 사용). 다른 디렉터리(예: Admob)에 다운로드한 외부 모듈을 추가하는 것은 Gradle을 사용하면 정말 쉽기 때문에 이론적으로 자산 라이브러리에서 해당 지원을 다운로드하면 마법처럼 작동합니다.

@veloc1

이미 Gradle 빌드를 수정하여 항목을 추가하는 플러그인 시스템이 _is_ 있습니다. 거의 변경이 필요하지 않거나 거의 필요하지 않을 것입니다.

새로운 "실행/내보내기" 워크플로는 다음으로 구성됩니다.
1) Gradle 빌드(변경 사항이 없으면 아무 것도 수행되지 않으며 매우 빠릅니다.
2) 현재 내보내기 로직을 ​​실행하여 APK의 압축을 풀고 파일, gdnative 플러그인 등을 추가하고 다시 압축합니다. 그래서 서명은 여전히 ​​Gradle이 아닌 Godot에서 수행될 것입니다.

마찬가지로, Godot는 빌드(이름 변경, 권한 및 기타 항목 추가), 아이콘 추가 등을 하기 전에 AndroidManifest.xml에 필요한 편집을 수행하여 매니페스트 작동 방식에 여전히 친숙하지 않은 사용자를 더 쉽게 만들 수 있다고 생각합니다. 좋은 점은 이것이 비파괴적인 방식으로 수행되므로 매니페스트에 자신의 항목을 계속 추가할 수 있다는 것입니다.

@reduz

서명이 Godot 측에서 이루어져야 하는지 확신하지 못했습니다. Gradle용 Android 플러그인에는 https://developer.android.com/studio/build/build-variants#signing 에 대한 훌륭한 기능이 있으므로 내보낼 때 키 저장소와 비밀번호만 확인하면 Gradle이 모든 작업을 수행합니다.

그리고 매니페스트를 위해. 내가 플러그인 시스템에 대해 말할 때 나는 정확히 그 것을 의미합니다. 각 플러그인은 권한을 선언하고 내보낼 때 포함된 모든 플러그인을 수집하고 AndroidManifest.xml을 생성합니다. 또한 이 방법으로 라이브러리 Services 및 BraodcastReceivers를 포함할 수 있습니다.

이름 및 아이콘과 같은 리소스의 경우 - 자리 표시자 리소스는 어떻습니까? 프로젝트 설정에서 구성할 때 자리 표시자를 프로젝트 설정의 값으로 바꾸세요? 따라서 최종 사용자는 이 끔찍한 안드로이드를 전혀 보지 못할 것입니다.

새로운 내보내기 워크플로를 사용하면 게임 팩을 다시 압축하는 대신(폴더 또는 .pck) APK 외부에 둘 수 있습니까?

@LinuxUserGD 는 Apk Expansion (.obb)이 아닌가요?
그것은 이미 거기에 있습니다.

우리가 무엇을 하든 유연해야 하며 통일의 방식이 아님을 확인해야 합니다. 동일한 종속성을 가진 여러 플러그인을 혼합하고 일치시키는 것은 엉망입니다.

매니페스트에 관해서도 수동으로 편집 가능한 상태로 유지하고 싶습니다.

현재 빌드는 매우 유연하여 템플릿을 편집하고 원하는 대로 추가/삭제할 수 있으며 템플릿을 빌드할 때 아무 것도 방해하지 않습니다.

하이브리드 시스템과 같은 것이 작동할 것이라고 생각합니까?

의심할 여지 없이 제안 2는 더 좋고 깨끗하며 더 "적절"하게 들립니다.
@reduz 제안 2의 단점? 빠른 인터넷을 사용할 수 없을 때만 번거롭다고 생각합니다.
Android Studio와 같은 Godot는 https://developer.android.com/studio/command-line/sdkmanager 를 다운로드하는 데 필요한 패키지 목록을 sdkmanager에 매우 쉽게 전달할 수 있습니다(텍스트 파일로?)

제안 2, 확실합니다.

제안 #2. 요즘 안드로이드 SDK 설치는 아주 쉽습니다!

@reduz , 저는 제안 2에 투표합니다. 하지만 #18141을 잊지 마세요.

제안 2. Gradle도 문서화되어 있으므로 더 많은 리소스를 확보할 수 있습니다. 대부분의 모바일 개발자는 어쨌든 시스템 어딘가에 Android SDK를 설치합니다.

제안 2

이것이 언제 구현될 예정인지, 어떤 정보나 무엇이든
@akien-mga 아직 3.1의 이정표인가요?

2018년 11월 23일의 godotengine.org/news의 이 블로그 포스트 에 따르면:

Godot 3.1은 사용자가 기대하는 것의 훨씬 더 넓은 표면적을 다루는 릴리스가 될 것이므로 더 이상 새로운 기능이 필요하지 않습니다. 3.1 이후에 계획된 정말 큰 기능은 렌더링을 Vulkan으로 이식하는 것뿐입니다...

글쎄요, 이번 이슈의 특징은 3.2에서 고려될 만큼 충분히 주목을 받은 것 같습니다. 블로그 포스트에서 다루지 않은 이유가 있나요?

Android 내보내기의 대규모 리팩터링을 위한 시간이 부족하여 3.2용이 될 것입니다.

Android는 다양한 타사 플러그인 및 데이터베이스(Firebase, Cloud, ML)를 제공하므로 지속적인 개발을 위해 Android sdk/jdk/ndk를 설치하는 것이 좋습니다. 그 이유는 Android 라이브러리가 버전에 따라 변경되기 때문일 수 있습니다. 내보낼 때 누락된 일부 종속성 라이브러리는 적절한 버전의 sdk가 설치되지 않은 상태에서 수행됩니다. 그러나 이 접근 방식은 반대로 사용자 또는 최종 개발자가 테스트를 위해 전체 제품을 Android 플랫폼으로 배송해야 하므로 시간 오버헤드가 발생합니다. .다른 접근 방식은 테스트를 위해 장치에서 android studio sdk 및 jdk를 사용하는 Android용 응용 프로그램을 만드는 것과 같이 수행할 수 있습니다. 사용자는 단순히 응용 프로그램을 케이블 포트로 컴퓨터에 연결한 다음 실행할 수 있습니다. godot 편집기 자체에서 변경 사항을 전화 또는 모바일에서 확인합니다. 모바일은 포트를 통해 컴퓨터의 Android SDK를 사용하며 Proposal1에 관한 한 시간 오버헤드가 거의 없습니다. 또한 거의 투명하며 해킹이 필요하지 않습니다.
Android 커널 코드에 특정 라이브러리가 있기 때문에 설치하지 않으면 런타임 충돌이 대부분 java.lang.io.exceptions와 함께 발생합니다. 제안 1이 우선적으로 적용되는 경우 별도의 해킹을 의미한다는 문제도 해결해야 합니다. Android 버전은 각각 이전 버전보다 종속성이 더 많습니다. 제안 2는 컴퓨터에 Android SDK를 설치하고 개발자가 Android 앱(구축 예정)을 사용하여 모바일에서 즉시 게임을 확인하여 만들 수 있습니다. 리모컨과 비슷합니다. 앱의 전체 빌드 또는 일반화된 접근 방식 내보내기 2를 취할 수 있습니다.
템플릿 문제에 관한 한 android8+ 적응 템플릿을 사용할 수 있습니다. sdk를 사용하여 응용 프로그램을 빌드하는 시간을 단축하기 위해 가비지 수집기를 향상시키는 것과 같은 엔진 최적화 및 구조체 기반 접근 방식과 같은 최적화도 가능합니다. 사용 된.
이것은 전적으로 내 관점입니다. 괜찮다면 응용 프로그램 게임의 즉각적인 구축을 위해 장치의 sdk를 사용하는 응용 프로그램(안드로이드)과 관련하여 몇 가지 계획을 세웠습니다.

이제 Google Play에서 새로운 AAB(Android App Bundle) 형식으로 업로드된 앱을 허용합니다.

이 형식을 통해 Google Play는 다양한 기기 유형에 대한 APK를 동적으로 생성할 수 있으며 Godot에서 만든 게임에 직접적인 영향을 미치는 기능 중 하나는 특정 CPU 아키텍처용으로 만들어진 기본 라이브러리만 포함하는 APK를 패키징하는 것입니다.

이것은 x86 장치에서 다운로드한 APK에 x86 라이브러리만 포함하고 arm64에서 다운로드한 APK에는 arm64 라이브러리만 포함하는 식으로 다운로드 크기를 크게 향상시킬 수 있음을 의미합니다.

Godot가 취하는 접근 방식이 무엇이든 이 새로운 패키징 형식을 지원해야 한다고 생각하지만 기본적으로 ZIP 파일인 APK 패키지와 대조적으로 AAB 패키지를 "해킹"하는 것이 얼마나 쉬운지 모르겠습니다.

이것은 x86 장치에서 다운로드한 APK에 x86 라이브러리만 포함하고 arm64에서 다운로드한 APK에는 arm64 라이브러리만 포함하는 식으로 다운로드 크기를 크게 향상시킬 수 있음을 의미합니다.

이것은 이미 가능하지만 아키텍처당 하나의 APK를 만든 다음 다중 APK 지원을 사용하여 Google Play에 업로드하는 수동 작업이 필요합니다.

이것은 기본적으로 1과 2의 혼합을 구현하는 #27781에 의해 수정되었습니다. 이전 시스템은 클릭 한 번으로 배포할 수 있도록 유지되지만 릴리스는 이제 사용자 정의 모듈이 있는 새 APK에서 다시 컴파일할 수 있는 미리 컴파일된 템플릿 소스와 함께 제공됩니다. /manifest 변경 사항/등. gradle을 사용하여.