Fragment A의 ArrayList a를 참조하는 스레드 B가 있다할때
B를 돌림 -> B가 돌아가던중에 A가 Destory되고 다시 Create됨
이때 B가 참조하는 A의 ArrayList랑 현재 활성화된 Fragment A의 ArrayList는 다른 객체로 취급되서
가령 getCount(){return a.Size();}라는 메소드가 있다하면
B 스레드에서 실행한 getCount 는 1000이 넘는 숫자를 반환하는데 UI 쓰레드에서 실행한 getCount는 0을 반환함
무식하게 ArrayList를 static으로 만들면 일단 이 이슈야 막을수있지만 이런식의 문제가 한둘이 아님 씨발...
히토미 다운로더 하나 만드는게 이렇게 빡센거였나
이해가 안가는건
정말로 두개의 참조가 달라서 문제가 터지는거면 Detory될때 Bundle에 현재 ArrayList담아두고, Create될때 Bundle에서 복구된 ArrayList 받아오면 정상적으로 되야할거같은데 그렇지가 않더라...?
흠
뭘로 짜는데 히토미 다운로더 짜는데 저런걸 하냐
안드로이드
갤러리 검색돌리는데 애초에 UI쓰레드론 검색도 못돌리고 AsyncTask는 너무 느림
글쿤
ui 스레드에서 데이터 수집 가공하면 안되지 않나?
걍 외국이라 느린거 아닌감..
js 인덱서만 내려받아서 지지고 복고 하는 건데 그렇게 느릴까
오래전에 해서 기억 안나는데.. 거기서 내려받은 한글로 된거... 아직도 다 소모가 안됐다 ㅜ
Asynctask가 체감상으로는 두배가량 느린거같음. 툭하면 병렬 실행 한계에요 징징대기도 하고
먼가 잘못 짠 느낌이 강하게 든다
1. 코틀린 쓰면 어싱크태스크 쓸 필요 없이 람다로 되고
2. 회전됐을 때도 남아 있어야 하는 데이터는 맨날 번들에 저장했다 꺼냈다 하면서 보존하든가 UI 없는 프래그먼트(a fragment without UI)에 넣어서 코드로 액티비티에 붙였다 뗐다 하면서 보존하는 거임
ㄴ 매번 고맙다
솔직히 그냥 매니페스트에 configChanges에 오리엔테이션이랑 기타 등등 추가해서 회전시켜도 리셋 안 되게 하는 게 몇 배는 더 편함
액티비티에 웹뷰 들어가면 회전 후에 뷰 살리고 데이터 보존하기 존나 어려워지니까 configChanges에 orientation이랑 screenSize 넣고 신경 끄는 경우가 많은데
keyboard랑 keyboardHidden도 넣는 게 좋겠네 어쨌든 공식 문서에는 비추천하는데 특히 초보한테는 그걸 직접 처리해서 나오는 이득이 코드 짜는 데 고생하는 손실보다 너무 큼. 그걸 직접 처리하면 강제 종료시에 앱 상태 복구 가능하지만