Homo Selfiens | Kita's Soft Guts

이어지는 내용

iPad가 나오면서 "또 이번에도 Flash가 지원 안된다"란 불평을 하는 기사들이 있는데, 이 기사를 쓴 분들은 Flash를 과소평가 하는 모양이다.

Adobe Flash vs. iPhone SDK
한 번 만들면 웹과 모바일 양쪽에서 쓰일 수 있는 Flash.
Apple의 하드웨어를 사용해서만 만들고 Apple의 하드웨어에서만 돌아가는 iPhone SDK.

개발자나 기획자에게 이 둘 중 하나를 고르라면?
진입 장벽이 낮고 개발자가 많으며 범용성이 높은 Flash를 선택할 가능성이 높다.

10년이 넘은 기술인 Flash는 디자인학부 전공수업시간에도 가르칠 정도로 저변이 확대되어있다. Flash 창작물은 MS Windows+PC를 이용해 만들 수도 있고, AppStore라는 게이트키퍼를 거치지 않고 웹페이지를 통해 퍼져나갈 수 있다.

반면 AppStore에 app을 만들어 올리려면 Mac 하드웨어 + iPhone SDK 학습 + 개발자 등록 + App 심사 등등... 진입장벽도 높고, 평소에 관심도 없던 Apple의 주요 product line을 몽땅 구매하기 딱 좋다. AppStore쪽으로 방향을 틀려면 단단히 마음먹어야 한다.


Apple의 입장에서 어느쪽이 이익일까?

당연히 Adobe Flash가 안돌아가게 막아놓고, 대신 사람들이 Apple의 Mac을 사서 Apple device 전용 app을 개발하고 판매 이익의 30%를 내도록 만드는 쪽이다. iPhone이라는 세기의 걸작에 Flash를 비롯한 어떤 3rd party 플랫폼도 지원하지 않았기 때문에 AppStore 마켓이 형성되고, "App으로 대박친 소수의 사람들"을 선망하여 Apple 매장앞에 인디 개발자들이 줄서고, 14만개라는 엄청난 갯수의 앱도 만들어졌다.

'타 플랫폼을 허용하지 않는 전략'은 App Developer의 약관을 보면 명확히 나온다. 약관에는 "Interpreter를 등록할 수 없다"고 명시되어 있다. 이 말은, 모든 앱은 Apple의 하드웨어에서 "직접" 컴파일 되어 만들어져야 하고, AppStore를 "반드시" 거쳐야 한다는 것이다. 이것은 Apple이 애초부터 자체 생태계를 만들 생각이었고, Flash, Java, .NET 등의 Interpreter/VM은 의도적으로 막아놓은 것이다.

결론적으로, Mobile Safari에서 Flash가 안되니 동영상이나 메뉴표시가 안된다고 투덜거리는 것은 -애플의 귀에는- 실로 어린이 투정과 같은 것이다. Apple이 자기 황금밥그릇을 자기 손으로 내놓기 전까지, Apple의 Mobile Safari에서 Flash가 돌아가는 것을 볼 수는 없을 것이다.

'그럼 안되는 것을 그냥 놔두란 말이냐? 플래시가 돌아가면 더 좋은 것 아니냐? 불평도 못하나?' 라고 반박할 분들은 일찌기 Apple의 모바일 기기를 사지 말았어야 했다. 이분들을 위해 본문에서 내내 강조했던것을 다시 되풀이 한다:

애플 모바일 디바이스의 플랫폼 정책은 애플 맘이다. 3rd Party 플랫폼을 막아놓은 덕분에 바짝 재미를 본 애플이 무슨 이유로 Flash(만)을 허용하겠는가?


PS1. Adobe가 Flash 컨텐츠를 App으로 만들어주는 packager를 만든 모양인데, 결과물이 interpreter가 아니기 때문에 App Developer 약관에는 위배되지는 않지만 과연 Apple이 이런 타입의 App을 허용할까 의문이다.

PS2. Apple은 Flash를 지원하지 않는 이유를 대외적으로는 "Flash가 crash의 주범"이라고 하는 모양이다. 듣기에는 그럴싸 할 듯. "3rd party platform은 지원 안함"보다는 대중이 원하는 대답이다.

All I ask of you is one thing: please don't be cynical. I hate cynicalism - it's my least favorite quality and it doesn't lead anywhere. Nobody in life gets exactly what they thought they were going to get. But if you work really head, and you're kind, amazing things will happen.
- Conan O'Brien on his final show

이 글이 본 블로그의 최고 인기글이네요.
너무 어렵게 써놓은 글인 듯 하여 좀 읽기 쉽게 요약한 글을 앞부분에 추가했습니다.

-----------------------------------------------------------------------------------------------

탈옥시킨 아이폰(jail-broken iPhone)에 필수로 설치하라는 추천 app들이 있다.

• SBSettings
  
• Five icon Dock
• Backgrounder
  
• WinterBoard (본인 생각에 WinterBoard는 필수가 아님)
  
• 등등...

걱정스러운 것은 이런 앱들을 설치하면서 혹시 배터리가 더 빨리 닳게되지는 않을까 하는 것이다. 배터리 잡아먹는 귀신이 아이폰인데, 어떤 app이든 배터리 퍼포먼스에 영향을 준다면 설치를 재고해야 하는 것이니까. 그래서 위 app들의 배터리 소모와 관련하여 Google해본 결과 '배터리가 더 빨리 닳지 않는다'는 결론에 도달했다.

그 이유는 위에 언급된 앱들(WinterBoard, SBSettings, Five icon Dock, Backgrounder)은 Mobile Substrate라는 라이브러리를 사용하기 때문이다(사실 Mobile Substrate를 썼다는 것 보다, 이것을 통해 app hooking을 하기 때문).

Mobile Substrate 라이브러리는, 비유하자면 어떤 app이 다른 app에 쉽게 '기생'할 수 있도록 해준다. (기생이라는 단어 자체의 어감은 좋지 않으나, 그냥 '얹혀 산다' 정도로 이해하면 되겠다.)

편의상 A와 B라는 app이 있고, A가 B에 기생한다고 하자. 사용자가 B app을 터치하면, B에 기생중이던 A app도 그 터치를 '볼 수 있게'고 저 나름의 처리할 수 있게 된다. 만약 A가 '기생' 방식을 쓰지 않는 경우, A는 사용자 명령을 감지하기 위해 백그라운드에서 상시 실행중이어야 하므로 배터리를 지속적으로 소모하게 된다. '기생'을 해서 얻는 이득은 이처럼 상시 실행중일 필요가 없도록 만드는 것, 그래서 CPU/배터리를 소모하지 않도록 하는 것이다.

많은 프로그램들이 기생하는 대표적인 프로그램은 스프링보드(아이콘이 배열되어있는 화면)다. 홈(ㅁ) 버튼을 누르면 항상 나오는, 윈도의 탐색기와 같은 존재다. 주요한 사용자 인터랙션이 이 프로그램에서 이뤄지기 때문에 이 스프링보드에 기생하는 app들은 아이폰에 여러가지 기능을 추가하면서도 배터리는 소모하지 않게 되는 것이다.

결론은, Mobile Substrate를 쓰는 app들은 상시 돌아가는 것이 아니기 때문에 배터리 소모량은 극히 미미할 것으로 예상한다.


Mobile Substrate에 대한 필요 이상으로 복잡한 내용을 읽고싶은 분은 클릭

예전부터 Hyper-threading에 대해 의문이 있었다. Hyper-threading을 켜놓고 single threaded app을 돌리면서 작업관리자를 보면 logical CPU의 한쪽만 50%가 올라가고 나머지 한쪽은 idle로 나오는데, 이게 실제로 CPU의 50%만을 쓴다는것인가? 만약 50%만 쓰게 만드는 거라면 전반적으로 성능에 도움이 될리가 없잖아.

그래서 한참을 구글링 해본 결과 http://www.hardforum.com/showthread.php?t=1450106 에서 누군가가 다음과 같이 써놓은 글을 발견했다.

When a CPU with HT is loaded on only one core, all of the CPU's resources will be allocated to that core and you'll get the CPU's full speed. It will only show as 50% in Task Manager because it's only using one logical core, but that logical core will be running just as fast as if you disabled HT and were running on the entire CPU.

즉, 작업관리자에는 50%만 쓰는걸로 나와도 100% 쓰인단다. HT에 대해서 Wikipedia 항목을 보니 원리는

When execution resources would not be used by the current task in a processor without hyper-threading, and especially when the processor is stalled, a hyper-threading equipped processor can use those execution resources to execute another scheduled task.

어느 process가 stall상태일 때 다른 process가 execution resource를 쓸 수 있도록 하는 원리인가보다. 작업관리자의 CPU usage graph는 'single thread가 50%만 쓰는 것'으로 오해하기 딱 좋다.