이번 iOS 심사를 넣고 2번 리젝이 되었다.

이유는 네트워크 통신이 불가능한 상태..

리뷰어가 심사시 테스트한 환경과 맞추기 위해 IPV6를 로컬로 테스트할수 있는 환경을 만든후

iOS14.0.1 OS가 설치된 디바이스를 해당 WIFI에 물려본 결과..

전혀 네트워크 통신이 안되는 상황 발생 (앱뿐만이 아니라 SAFARI에서도 웹페이지 접근 불가)

iOS13까지는 무리 없이 테스트가능한 방법이었으나, 14로 올라오면서 네트워크와 관련된 변경점때문인지 위와 같은 방법으로는 테스트가 불가능했다.

최초 리젝된 이유는 앱이 크래시가 발생한다는 것이었는데, 이 문제는 네트워크 라인은 물린 상태에서 송신후 수신을

무한히 대기할 경우 프로젝트에서 쓰고있는 보안솔루션과 문제가 발생되어 크래시가 나는 것을 확인하여 이부분은 수정을 했다.

두번째 리젝은 말 그대로 크래시는 아니나 네트워크 통신이 불가능한 현상이었는데,

이때 게임 서버와의 프로토콜 통신이 일반 HTTP 였다.. SSL이 적용된 주소로 변경 후 재심사를 넣었고,

통과되었다..

의문점은 물리적으로 동일한 라이브러리를 쓰고 있는 다른 앱의 경우 SSL이 적용되지 않았음에도

무리없이 한방에 통과됬다는거다...

간혹 우리가 볼때는 문제가 없으나, 애플이 볼때, 그것도 원인을 찾기 매우 어려운 이슈일 경우

스트레스가 어마어마하다...

해결되었으니 일단 한숨돌리고..

https://stackoverflow.com/questions/50689859/download-large-file

https://forum.unity.com/threads/uwp-memory-leak-when-downloading-large-files.765122/#post-5103632

위 두 링크의 내용을 축약하면..

UnityWebRequest를 사용하여 텍스쳐를 다운로드를 한 후, 다운로드된 리소스를 처리하기 위해 직접 www.downloadHandler.data에 Access 하게 되면, 리턴을 위해 내부에서 새로운 바이트 배열이 생성되므로 메모리 관리에 매우 취약하다는 내용.

첫 번째 링크처럼 만약 다운로드한 리소스를 파일로 저장하거나 특정 목적으로 사용할 경우 그에 맞는 downloadHandler를 전송 전에 할당하여 처리할 수 있도록 해야 함.

안드로이드에서는 WRITE_EXTERNAL_STORAGE 권한이 있느냐 없느냐에 따라, Application.persistentDataPath의 경로가 달라진다.

오늘 해당 권한이 없는 상태에서 앱 진입후 런타임 퍼미션을 통해 해당 권한을 얻었음에도 Application.persistentDataPath의 경로가 올바르게 리턴되지 않는 현상, 즉 권한을 획득하기 이전의 경로로 리턴되는 현상이 발생되었다.

이럴 경우 처음 앱을 실행한 상태에서 Application.persistentDataPath을 사용하여 파일을 쓰거나 리소스를 저장하게 되는데, 두번째로 앱을 실행하면 권한을 이미 획득한 상태에서 올바른 Path를 획득하게 되므로 첫번째 실행시 저장된 파일을 찾지 못하는 현상이 발생하게 된다.

테스트 조건은 갤럭시S10.

클라이언트단에서는 처리가 어려운 문제라 골치 아팠는데 마침 알림으로 소프트웨어 업데이트가 떠있길래 업데이트 후 재테스트한 결과 위와 같은 현상이 사라짐...

망할 커펌.....

코루틴을 이해하고 있는지 알아보는 문제.

만들었던 나조차 한번 틀렸다-_-...

아래와 같은 코드가 있다고 가정하고

콘솔에 찍히는 숫자를 순서대로 나열하면? (당연히 머리로만 계산해서+_+)

NDK의 addr2line.exe 파일을 사용해서 에러난 스택의 메모리값을 통해 소스코드의 어느 부분에서 에러가 나는지 추적할수 있음.

역시 NDC가 꿀이네 ㄷㄷㄷ

http://www.inven.co.kr/webzine/news/?news=198239&sclass=0&page=2

R, G, B의 평균값(float)를 Albedo(또는 Emission)에 할당하면 됨.

RGB to YIQ 변환방식

GrayScale = 0.2989 * R + 0.5870 * G + 0.1140 * B

void surf (Input IN, inout SurfaceOutputStandard o) {

fixed4 c = tex2D (_MainTex, IN.uv_MainTex);

fixed4 d = tex2D (_MainTex2, IN.uv_MainTex2);

// float temp = (c.r + c.g + c.b)/3;

// float3 grey = float3 (temp, temp, temp);

// float3 grey = 0.2989 * c.r + 0.5870 * c.g + 0.1140 * c.b;

// float3 grey = (c.r + c.g + c.b)/3;

o.Albedo = grey;

o.Alpha = c.a;

}

프로젝트 작업중에 순차적으로 처리할 코드를 줄이다 보니 아래의 테스트코드를 작성하게 되었음.

왜 싱글턴을 사용했는지가 중요한게 아니므로 넘어가고 흐름만 보도록 하자.

using System.Collections;
using System.Collections.Generic;
using UnityEngine;
public class Test : MonoBehaviour
{
    IEnumerator Start()
    {
        yield return null;
        bool checkSum = false;
        for (int i = 0; i < 10; i++)
        {
            checkSum = false;
            Test1.Instance.CallBackTest((success) => { checkSum = success; });
            
            yield return new WaitUntil(()=>checkSum);
        }
    }
}
public class Test1 : MonoBehaviour
{
    #region singleton
    private static volatile Test1 instance;
    private Test1() { }
    public static Test1 Instance
    {
        get
        {
            if (instance == null)
            {
                GameObject go = new GameObject();
                instance = go.AddComponent<Test1>();
            }
            return instance;
        }
    }
    #endregion
    Action<bool> mCB;
    public void CallBackTest(Action<bool> _cb)
    {
        mCB = _cb;
        StopCoroutine("StartCallBack");
        StartCoroutine("StartCallBack");
    }
    IEnumerator StartCallBack()
    {
        yield return new WaitForSeconds(UnityEngine.Random.Range(0.5f, 3f));
        if (mCB != null)
            mCB.Invoke(true);
    }
}

흐름은 Test 클래스 Start 함수에서 반복문으로 시작.

이후 지역변수 checkSum을 이용해 Test1쪽 콜백을 받으면 true로 변경되기 전까지 waituntil에서 대기하고,

checksum이 true로 되면 다음으로 진행되는 구조.

뭐 팁이랄것도 없이 아주 간단한 구조이긴한데, 눈으로 봐야 직성이 풀리는 성격이기도 하고 생존기록으로 남기고자..'ㅅ';