저는 ICS 업그레이드도 안되는 태블릿을 쓰고 있는데 젤리빈이 훨씬 더 좋아졌다고 들었습니다. 기능상으로는 iOS를 많이 따라잡았다고 하던데 그게 아닌가 봅니다.

저도 거기에 동의합니다.

중국산 기기의 경우 특히 그렇구요. 11월쯤에나 쓸만한게 나오고 12월이나 1월쯤 되서야 안정적이 될겁니다.

현재 P85쌍핵 쓰는데, 큰 문제는 없는데 아직 어플호환이 많이 안되는 모냥이더군요. 노바3 플레이스토어에서는 다운 안되는데 막상 티타늄으로 복원하니 실행 멀쩡..-0-

결국은 젤리빈 자체의 문제가 아니라 중국 타블렛의 경우에는 최적화가 아직 안 되었다는 말씀이신가요?

잘 보았습니다. 잠재적으로 문제가 많네요. 

갤럭시의 경우에는 ICS 유출롬이 나올 때부터 이미 삼성에서는 ICS 자체 터치 스크롤이 아닌 진저브레드 코드를 수정해서 쓴다고 하는 얘기를 들었습니다. 

프로젝트 버터 시연 동영상을 보면 홈화면 - 앱 서랍으로 넘어갈 때, 그리고 "최근 사용 앱" 키를 사용할 때 어느 정도 눈에 띄는 속도 개선이 있었던 기억이 나는데, 그게 메모리 관리 방식이 바뀐 것과 연관이 있는지 백그라운드 앱 (카톡 등등)에 문제를 일으키는 건가요?

... 쓰고 보니 며칠 전에 Songza라고 하는 인터넷 라디오 앱 듣다가 갑자기 음악이 죽었던 기억이 나네요. 정말 뭔가 문제...아니면 최소한 변화(?)가 있는 것은 사실인가보네요. 

...

어째든 제 마음대로 멋대로 결론은....넥서스 시리즈를 가거나 아예 CM 등 AOSP 기반의 커스텀 롬의 세계에 살자...입니다. 근데 한국에서는 그러기기 쉽지 않겠더군요.(한국 토종 전용 갤스3를 17만원에 풀어버리는 미친(?) 시장...)

음... 역시 다음 폰도 그냥 아이폰으로 가야겠네요; 아이폰이 이런 저런 편의성 면에서 막혀 있는 부분은 많지만 저런 버그는 상대적으로 적어서 ㅎㅎ...

젤리빈의 프로젝트버터를 함축적으로 표현하면...

1) 커널의 프로세스 클럭을 UI 프레임워크에서 유기적으로 변화시키게 한 것

2) UI 프레임워크 최상단의 EDT가 호출하는 저수준 드로잉 부분이 GPU 가속, VSync, 트리플 버퍼링을 적용해도 UI가 정상적인 디스패칭과 스레드 세이프 가능하도록 개선한 것

3) VM에서 드로링 오버헤더를 제거하고 스레드 세이프를 유지하면서 표출 중인 UI 외의 VM이 관리하는 스레드들을 일시정지 시키도록 최적화한 것 

들이라고 이해하고 있습니다. - 제 이해가 틀렸을 수도 있습니다. 원체 무지하다보니;;; -

이런 상태라면 각 제조사는 Dalvik과 그에 기반한 API 소스를 수정하는 작업은 앱의 호환성 등을 고려할 때 피할 것이고, Dalvik의 커널 레벨 프로세스 클럭 컨트롤과 저수준 드로잉 등에 대하여 허위 콜백을 회신하면서 기존 유지하던 가속화 방법을 유지할 개연성이 높습니다. 다만 문제는 과연 삼성, LG, HTC, 소니 등과 같은 선도 업체들이 어느 정도까지 고유 코드를 가지고 있었는가 인데... 극히 개인적인 의견으로는 그들의 최적화라는게 고런처 등과 다름 아닌 런처 레벨이 대부분이고 로우레벨 관련 코드는 이를 지원하기 위한 트윅 수준이 아니었을까 하는 짐작을 해봅니다. 이유는 그들의 제품 라인업 전개가 굉장히 방만했으며 다양한 하드웨어 플랫폼과 안드로이드 버전을 복잡다난하게 적용하고 있는데다 레퍼런스 코드는 스마트폰 제조사가 아닌 AP 제조사가 제공하기 때문입니다. 이러한 혼돈에서 로우레벨에 깊게 관여하는 품질이 보증되는 표준화된 코드를 레퍼런스 코드를 무시한체 스마트폰 제조사가 생성했었다고는 쉽게 수긍이 가지 않습니다. 

따라서 결국 프로젝트 버터의 적용 유무는 AP 제조사가 레퍼런스에 적용하느냐가 핵심이 될 것으로 보이고 제조사는 그를 따르는 것이 단기의 혼란 이후에는 정리되는 과정이 아닐까 싶습니다. 특히 자체 AP를 가지고 있어 묘한 위치에 있는 삼성의 경우 자신있게 젤리빈을 제시하고 있는 현실이고 보면 오히려 삼성이 가장 앞서 있는게 아닌가도 싶고요. 

젤리빈의 안정성과 호환성에 대해서는... 

DRM 버그의 경우 구글도 이미 '다음 번에~'라고 인정한 사항이고, 앱 호환성, 백그라운드 서비스 등의 문제는 스레드 분배 구조가 커널, Dalvik, API 등에서 반응성 향상에 맞추어지면서 변경되어 컨커런트 관련한 이슈가 대부분이라 짐작됩니다. 이는 일면은 버그일테지만 또 다른 면에서는 부득 새로운 가이드라인을 앱 개발사가 맞추어야할 문제로도 보입니다. 이유는 얼마간 구글이 의도했다고도 보이기 때문인데 시장의 60% 이상을 차지하는 진저브레드로 상징되는 레가시 버전과 NDK로 상징되는 호환성 저해 요인을 오랜 기간 압박의 원인이었던 반응성을 무기로 해 강제적으로라도 걷겠다는 의도로 읽혀 집니다. 

따라서 대략 이후의 수순을 짐작해보면... - 어디까지나 짐작입니다... 역시 잘 모르다 보니;;; -

1단계 - 젤리빈 배포, 환호 받음

2단계 - 호환성 관련 원성 수용, 호환성 레이어 추가한 패치 제공, 그러나 레가시 앱 성능은 억제됨

3단계 - 신규 및 업데이트 앱 등록에 대하여 강력하게 젤리빈에서 새로 확립된 가이드라인 준수를 요구함

4단계 - 레가시 앱을 별도로 분류하여 리스팅하거나 아예 보여주지 않는 식으로 앱 개발사와 사용자를 점진 리드

5단계 - 젤리빈을 제2의 진저브레드로 자리매김하게 함

정도가 되지 않을까 싶습니다. 

흥미로운 것은 이러한 시장 변화는 '레퍼런스 받아다 찍고 본다'는 특성으로 가장 기민하게 대응하는 중국계 기업들이 더욱 성장할 수 있는 발판이 될 수도 있으리라는 점입니다. 메이저 제조사들도 어차피 OS 자원이 없는 상태에서 삽질하느니 모토로라라가 ICS에서 보여주었던 것처럼 제조사 특성을 억제하면서 구글에 맞추어가는 쪽으로 흐름이 잡히지 않을까 싶구요.  

리플이 장문이 되었습니다. 무지한 내용이 있더라도 너그러운 양해를 부탁드리며 마칩니다. - 요즘은 사용자도 참 힘들군요. 만드는 사람만 믿고 사면 되던 때가 문득 그리운데요;;; - 

지금 안드로이드 4.1.1 기계(즉, Galaxy Nexus의 해외롬 버전)를 쓰고 있습니다. 버터 프로젝트의 산물인 반응 속도에 대해서는 ICS에 비해 획기적으로 나아졌다고 보기는 어렵습니다. 굳이 말하자면 '억지로 높인 속도'라는 느낌에 가깝습니다. 또한 호환성 문제에 대해서는 매우 공감하고 있습니다. 실제로 레거시 앱쪽에서는 문제가 꽤 보이고 있습니다.(그 때문에 저도 쓰던 앱 가운데 두세개를 교체해야 했습니다.) 또한 이건 느낌상의 문제이기는 하나 ICS보다 JB가 메모리 누수가 더 심해 보입니다.

ICS가 4.0.4에서 안정화되었듯이, JB도 시간이 좀 걸릴 모양이군요.

프로젝트 버터는 크게 두가지입니다.

1. 트리플 버퍼링과 Vsync로 인한 티어링의 제거

2. 배치 작업으로 처리하던 인풋 이벤트를 실시간 처리로 변경하여 응답성 향상.

이 두가지는 SurfaceFlinger와 EventHub 수준의 변경이고 어떤 벤더나 커스텀 롬에서도 이와 같은 수준을 얻은 적이 없습니다.

무엇이 변경된지 모르고 기존의 벤더가 무엇을 변경하였는지 모르시고 이야기를 하시면 곤란합니다.