김은석의 달콤한 IT이야기.

오늘 작업 중 Alert Facebook에서 선미씨의 글을 보고 저 또한 깊은 생각에 한번 빠져보게되었습니다.
글의 내용은 아래와 같았죠.
(아참, 혹 초상권에 문제가 있다면 페북 메시지 주세요 ㅠ 포샵이 없어 편집을 못했네요ㅜ)
(Alert Facebook은 제가 만든 간단한 알림 어플입니다~제가 받고 싶은 사람의 타임라인만 보여주죠!)

아무튼 곰곰히 생각해봤습니다.
UX와 UI의 명확하게 구분하는 사람이 있을까? 라고 말이죠.

개인적인 생각으로는 사전적인 의미에서 조차 UI와 UX는 정확하게 구별되어 있지 않은 것 같습니다.

아래는 위키피디아에서 발췌한 UI와 UX의 정의인데요.

■ UI(User Interface): 사람과 사물 또는 시스템, 특히 기계, 컴퓨터, 프로그램 등 사이에서 의사소통을 할 수 있도록
일시적 또는 영구적인 접근을 목적으로 만들어진 물리적, 가상적 매개체를 뜻한다.
사용자 인터페이스는 사람들이 컴퓨터와 상호 작용하는 시스템이다.
사용자 인터페이스는 물리적인 하드웨어와 논리적인 소프트웨어 요소를 포함한다.
사용자 인터페이스는 크게 다음과 같은 수단을 사용한다.

■ UX(User eXperience): 사용자가 어떤 시스템, 제품, 서비스를 직, 간접적으로 이용하면서 느끼고
생각하게 되는 총체적 경험을 말한다.
단순히 기능이나 절차상의 만족뿐 아니라 전반적인 지각 가능한 모든 면에서 사용자가 참여, 사용,
관찰하고 상호 교감을 통해서 알 수 있는 가치있는 경험이다. 긍정적인 사용자 경험의 창출은 산업 디자인,
소프트웨어 공학, 마케팅, 및 경영학의 중요 과제이며 이는 사용자의 니즈의 만족,
브랜드의 충성도 향상, 시장에서의 성공을 가져다 줄 수 있는 주요 사항이다.
부정적인 사용자 경험은 사용자가 원하는 목적을 이루지 못할 때나 목적을 이루더라도 감정적, 이성적으로나
경제적으로 편리하지 못하거나 부정적인 반응을 불러일으키는 경험을 하게 되는 경우 발생할 수 있다.
긍정적인 사용자 경험을 개발, 창출하기 위해서 학술적, 실무적으로 이를 만들어 내고자 하는 일을
사용자 경험 디자인이라고 하며 영역에 따라 제품 디자인, 상호작용 디자인, 사용자 인터페이스 디자인,
정보 아키텍처, 사용성 등의 분야에서 주로 연구 개발되고 있다.
그러나 사용자 경험은 다학제적이며 다분야의 총체적 시각에서 접근해나가야 하는 핵심적인 원리를 바탕으로 한다.

위에서 주목해야 할 점이 있다고 생각됩니다. (이탤릭체로 표기)

먼저 UI는 컴퓨터와 사람간의 상호작용을 위한 시스템이라면, UX는 사용자가 어떤 시스템과 제품을 사용하면서 느낀 경험을 말한다고 되어있습니다.  즉, 사용자가 어떤 시스템과 제품을 사용하면서 느끼게 되는 경험은 전적으로 UI에 의존된다고 볼 수도 있지 않겠습니까?

제가 생각하는 UX란 그런 것 입니다.
우리가 말하길 잘 만들어 진 UX는 “사용하기 편리한” 것을 말합니다. 이때 사용하기 편리하다는 것은 우리가 이미 그 환경에 익숙해져있고, 최초 접근성이 매우 뛰어난 제품들을 의미하죠. 스티브 옹이 가장 중요시 했던 부분도 이런 부분이고, 최근 다양한 기험에서 이런 “익숙함”을 중요시하고 있습니다.

대부분의 기업이 소위 대박난 제품의 UI를 베이스로 하여 다음 제품을 만드는 이유도 여기에 있다고 보여집니다.
새로운 제품을 접하는 사람들이 기존에 가지고 있던 환경에 익숙함을 느낌으로써 더욱 편리한 제품이라는 인식을 가지게 되는 것이죠.

즉, UX를 극대화 하기 위해서 UI를 강화하는 것이지 상호간의 비교는 무의미 하지 않는가라는 것이 저의 생각입니다.
물론 사전적인 의미의 비교는 가능하겠지만, UX를 향상하기 위해서는 많은 조건들이 있지만, 그 중에서도 UI를 강화하는 것이 중요하고, 작은 변화로도 충분히 사용자로 하여금 편리한 제품이라는 인식을 줄 수 있는 방법이라고 생각하니까 말이죠.

물론, UI라는 것이 디자인만을 의미하는 것은 아니지만, 디자인(그래픽)적인 부분에서 UI라는 단어를 우리가 “디자인”을 대신하는 의미로 사용하는 이유도 여기에 있다고 생각됩니다. 가령 “아이폰”을 생각해보면 아이폰4와 그 이전 세대의 간단한 차이로 UX를 극대화한 사례가 있습니다.

혹시 아이폰4를 가지고 있다면 직접 확인해보셔도 좋습니다.
아이폰4의 메인화면을 보면, 이전 세대의 메인화면과는 다른 부분이 2가지 있습니다.

# 이전 UI(좌)와 최근 변경된 UI (우)

위에서 보이는 것이 아이폰 이전 버전의 UI입니다.
밀어서 잠금을 해제한다는 UX적인 부분은 변화가 없습니다만 현재의 UI를 확인해보시면,
위 날짜부분이 7월 1일 목요일에서 7월 1일 (목요일) 로 변경되어 있습니다.

단순히 (요일)로 변경했을 뿐인데 가독성은 상당히 발전했다는 느낌을 받을 수 있습니다.
또한, 잠금해제 부분의 화살표에 그라데이션이 들어가 있어서 쉽게 구분을 할 수 있도록 변경하기도 하였죠.
(갤럭시에는 적용되었는지 모르겠지만, 사소한 부분이지만 상당히 편리해 보이더군요)

사소한 예를 보더라도, UI와 UX를 따로 이야기하는 것은 무리가 있다고 보여지지 않나요?
저는 그렇게 생각하거든요.

그럼 다른 예로 웹을 한번 이야기 해보죠. 물론 여기서 느끼는 모든 감정(UX)들은 제 기준이라,
다른 분들은 또 다른 감정(UX)을 가질 수 있겠지요.  아래 보시는 페이지는 변경된 구글+의 UI입니다.

어떻게 생각하시나요? 사실 저는 위 페이지를 보고 상당히 당황스러웠습니다.
사실 이전의 Google+페이지는 상당히 직관적이였다고 생각됩니다. 단순한 텍스트와 몇 개의 아이콘으로 이루어져있었지만, 구글 다움이 있었고 쉽게 접근이 가능하다고 생각되기도 했죠. 물론 저는 구글 +를 애용하지는 않습니다만 오늘 어떤 데이터를 찾으로 들어갔다고 심각하게 충격을 받기도 했지만요.

먼저 제가 마음에 들지 않는 부분은 잘 안보일 수 도 있겠지만, 각 부분이 프레임으로 나누어져있어서 매우 산만한다는 느낌을 주더라구요. 또 좌측 메뉴바 아래 “더보기”라는 기능이 있는데 어떤 기능이 들어 있는 것이 아니라, 그 위의 아이콘 메뉴(탐색이나 페이지 등)를 드래그에서 넣을 수 있는 포켓같은 역할을 담당하는 버튼이였습니다.

그런데 이름을 왜 “더 보기”라고 정했을까요? 그리고 타임라인의 경우는 해상도에 따라 자동으로 늘어나지 않아 보시는 것과 같이 “모바일 앱 다운로드”말고는 텅빈 느낌을 준다고 생각됩니다. 또 오른쪽 행아웃 시작이라는 버튼이 있는데(행아웃은 제가 구플에서 가장 뛰어나다고 생각하는 기능) 왼쪽 메뉴바에도 행아웃이 있네요??

왼쪽 메뉴 버튼과는 무엇이 다른건가요???
(왼쪽 버튼을 클릭했을 때 뭔가 많은 정보를 보여주긴 했지만, 어째뜬 제 입장에선 행아웃을 하려고 했던 것 아닙니까?)

물론, 저는 UX나 UI의 전문가는 아니지만, 사용자 입장에서 첫 진입은 매우 “불편해!”라는 느낌을 받았습니다.

하지만!

중요한건 제가 받은 “불편함”이 아닙니다.

이 부분이 제가 말하고 싶은 부분입니다. 단지 제가 느끼는 UI의 불편함으로 UX 역시 어렵게 느껴졌지만( 페이스북이나 트위터에 익숙해져있다 보니 ) 계속 사용하다 보면 이 페이지조차 익숙해 져버리게 되고, 이렇게 익숙해진 뒤에는 오히려 페이스북이나 트위터가 불편하게 느껴지게 될 것 입니다.

컴퓨터도 처음의 UI는 매우 힘들었지만, 조금만 익숙해지면 누구나 편하게 사용하지 않나요?
스마트폰, 메신저, 인터넷…그 모든 것들이 말입니다.

물론 초기 접속자를 재방문하게 한다거나, 충성적인 고객으로 만들 수 있을 지는 모르겠지만 말이죠.
이렇게 UI에 불편함을 느낀 제가 과연 Google+를 사용할까요? 아마 특별한 경우를 제외하고는 접속조차 하지 않을 것 같다는 생각이 듭니다.
그리고 저는 아이폰보다 오히려 갤럭시 시리즈가 더 사용하기 편리하다라고 생각되기도 합니다.
(물론 몇 가지 부러운 점도 있죠)
이런 점을 보았을 때 최초 UI의 접근 용이성이 얼마나 중요한지를 증명하는 것이라고 할 수 있습니다. 그만큼 보편화된 환경이 UX로써 지속될 가능성이 높다는 것 입니다.
어쩌면 이런 보편화된 환경을 만들기 위해 보편화된 UI를 사용하면서 여러 특허 분쟁이 일어나는 것일 수 도 있다는 생각이 들기도 하구요.

글이 상당히 길어졌지만, 결론을 이야기하자면 저는 “UI와 UX”를 분리해서 정의하는 것을 좋아하는 편은 아닙니다.
사전적 의미차이는 있겠지만, 그 의미 역시 애매모호할 뿐 더러, 지금까지 풀어 쓴 이야기를 종합해본다면 UI와 UX는 상호작용하는 부분이 상당히 많습니다.

그 크기를 이야기 하자면, UX 내부에 UI가 포함되어 있는 형태라고 할 수 있고, 실제로 수 많은 기업이 UX와 UI의 Relationship을 강조하고 있습니다. 그 들 역시 UX와 UI를 따로 구별하는 것이 아니라, UX 내부에 아주 조그마한 일부로 UI를 채택하고 있죠.

[ UX is not UI! - SlideShare ]

저 또한 이처럼, 뛰어난 UX를 구성하기 위해서는 접근이 용이하고, 보편화 되어있는 UI를 채택하는 것이 사용자로 하여금 편리한 사용을 유도한다라는 마인드를 가지고 있어서 그런지 이 두 가지의 의미를 따로 보기보다는 어느 한 분야에 종속되어있고, 이를 구현하고 있는 체제라고 늘 생각하고 있습니다.

계속해서 결론을 이야기 하고 있지만 UI와 UX는 분명히 다른 개념입니다.
하지만, 궁극적으로 서로 상호관계를 유지하며 서비스 혹은 제품에 적용될 때만이 고객이 만족하는 서비스로 발전할 수 있다는 것 입니다.

다양한 블로그 , 국내 뿐 아니라 해외에서도 UX와 UI의 차이라는 주제로 많은 토론이 오가고 있습니다. 또 모든 글들이 저와 마찬가지로 개인적인 생각들이 많이 포함되어 있지요. 하지만 적어도 IT기업에서 만큼은 저와 동일한 생각을 많이 하는 것 같습니다. 1pixel을 가지고 1~2시간식 고민하는 디자이너, 기획자 그리고 개발자들까지…

저 역시 이 포스팅에서 어떠한 결론을 내릴 생각이 없습니다. 제가 이 분야의 전문가도 아니고 어떻게 단정할 수 있을까요?
지극히 개인적인 이야기들과 간단한 몇 가지 예를 제시했을 뿐 입니다.

이 긴 글을 읽고 느끼는 감정이 바로 여러분들이 생각하고 있는 UI냐, UX냐의 차이겠지요.
이런 이야기들은 상당히 재미있는 이야기들 입니다. 개발 외 다양한 생각을 만들 수 있는 장이기도 하고 이런 기회에서야 외국 블로그도 가서 영어공부도 하니 말이죠.^^

무튼 좋은 토론거리를 제공해준 선미씨에게 다시 한번 감사의 인사를 올립니다!^^

사실 이 부분은 개인적으로 봤을 때 아샌으로 넘어오면서 상당히 안드로이드 부분이 많이 발전을 했습니다.
기본적인 랜더링 구조 방식을  완전히 변경했기 때문이죠. 하지만 근본적인 문제들이 몇 가지 있다고 생각됩니다.

이것은 지극히 개인적인 이야기라 강의 때는 어떻게 설명해주실지는 모르겠습니다.

그럼 “제 기준”의 이야기를 한번 털어놓겠습니다.

첫 번째는, 계층별 스레드의 문제입니다.
부산 멤버십에 있는 동기들은 늘 제가 “계층”별 쓰레드에 불편한 점으로 투덜거리는 것을 들은 적이 있을 것 입니다.

이때 GC(가비지컬렉터)가 제대로 동작하지 않아서 느린 것이 아니냐, 안드로이드가 바이트코드를 돌리는 반면 iOS가 네이티브 코드를 돌려서 그렇것이 아니냐
라는 문이 계십니다만, 실제 구글팀에서 일했던 분의 이야기로는 이로 인한 차이는 없다는 것 입니다.

그러면, 차이가 생기는 이유는 UI처리 시 쓰레드가 어떻게 돌아가는가에 주목해야 된다고 생각됩니다.

먼저 iOS는 모든 UI 렌더링을 전용 UI 쓰레드에 실시간처리 권한을 부여합니다.
반면 안드로이드는 전통적인 PC 모델을 따라서, UI를 메인 쓰레드에서 보통 권한을 부여하죠.

즉, 타 쓰레드보다 우선순위 밖에 있는 안드로이드는 렌더링 과정이 느릴 수 밖에 업습니다.

예를 들어서 아이폰으로 인터넷을 사용하다 로딩이 다되지 않은 상태에서 스크롤바나 다른 행위를 하면 모든 렌더링이 멈춥니다.
이 말은 UI쓰레드가 최우선적으로 처리되고 있고, 이 쓰레드를 통해서 다른 일을 중단한다는 것을 의미하죠.

하지만 안드로이드는 UI쓰레드 보다는 사용자 처리 관련 부분이 상위계층에 존재합니다.
즉, 렌더링이 멈추지 않은 상태에서 다른 처리가 발생하면 해당 처리를 먼저 수행하고 그 뒤에 렌더링을 하기 때문에 느릴 수 밖에 없다는 것이 제 생각입니다.

하지만,  갤럭시S2나 노트 등 갤럭시 시리즈의 경우 듀얼코어의 성능이 매우 뛰어나서 이 부분에서는 다른 차이를 찾기 어려울 것 입니다.

그럼 다른 이야기를 조금 해보겠습니다.

흠…이와 같은 행위를 한번 해보세요.

갤러리 어플을 실행하고 계속 스크롤을 내리거나 올려보세요. 그러면 안드로이드 폰은 프레임이 급격하게 떨어집니다.
왜냐하면 스크롤 하면서 즉시 썸네일들을 그려내려고 하기 때문인데, iOS는 스크롤 후에서야 느긋이 섬네일을 띄워버리죠.

결국 우선순위의 차이라고 생각됩니다.

그리고 또 많은 사람들은 하드웨어 가속을 이야기 하기도 합니다만, 하드웨어 가속이라는 것이 부드러운 UI를 만들어내는 키는 아닙니다.

오히려 안드로이드 측에서는 보다 부드러운 UI 처리를 하기 위한 방법을 오래 전부터 연구했었다고 합니다.

실제로 1.6에서 등장한 개선된 현재실행 상태냐 백그라운드 스케쥴링이냐에 따른 차이라던지,
2.3에서 등장한 입력장치 재구성 방법,  Strict Mode, 확실히 변화된 GC(이전 포스팅을 참고하세요, 제 블로그 어딘가에 GC에 대한 이야기를 적어둔 게시물이 있습니다) 등이 있습니다.

보통 3D게임을 하면 60fps정도 나와야 “아 밀리지 않는구나”라는 느낌을 받으시면서 게임을 하셨을껍니다.

사실 60fps를 달성하려면, 매 프레임을 20m/s 안에 처리해야 하는데, 이는 그렇게 긴 시간이 아닙니다.

UI가 사용할 데이터를 플래시 스토리지에서 가져와야하고, 이를 할당해야하고 렌더링까지하는데 20m/s만에 처리하기는 힘들지요.
이번 아이스크림 샌드위치에서 변경대 렌더링 방식이더라도 플래시 스토리지에서 불러들이는 경우에 딜레이가 발생됩니다.

특히 스토리지를 다른데 쓰고 있다면 더 그렇습니다!

그래서 어쩌면 우리가 안드로이드 렌더링은 너무 느리다라는 느낌을 받을 수 있는 것 이라 생각하구요.

또한, 기기 해상도들이 올라가면서 60fps UI의 달성은 GPU 성능과 밀접하게 연관되게 됐고, 특히 GPU의 메모리 대역폭에 의존하게 되었습니다.
결국은 하드웨어의 성능차에 따라 그 변화가 커진다는 것인데 이를 확인하려면 메모리 대역폭을 눈여겨 보시면 됩니다.

메모리 대역폭보다 CPU가 몇배(몇 십배???) 는 빠르기 때문이죠~왜 GPU, GPU하는지 알게 됩니다.

물론 아이스크림 샌드위치에서는 변경되었지만, 그 이전 버전의 경우 각 창별로 별도로 렌더링을 했었고, 하나가 경신되게 되면,
예를 들어 메뉴의 버튼들을 누른다든가 하면 그 창의 내용을 새로 그렸습니다. 그러니 더 느릴 수 밖에 없었죠.

이 부분은 초기부터 이슈가 되었고, 현재는 멀티 뷰 방식으로 변경되어 있습니다
이것도 제 블로그 검색을 하시면 관련 글이 존재합니다!

또, 개발자 역량의 차이도 하나의 영향을 미치고 있다고 생각합니다.

보통 iOS의 렌더링은  미리 짜여진 애니메이션들 혹은 코어 애니메이션 렌더링 레이어 트리에 연관되는 것들은 여러분도 알지 못하는 사이에 백그라운드 쓰레드에서 돌아갑니다.
또, 코어 애니메이션 레이어에 새로 그리는 것과 애니메이션을 구현하는 부분의 경우는 메인 쓰레드에서 구동되구요.

이것은 단순히 구동에 관한 것이지 렌더링을 처리하는 부분은 아니라는 의미입니다.
그러니까 보통의 개발자들이 쓴 코드들은 메인 쓰레드에서 돌아가는 것이라고 생각하면 됩니다. 개발자가 변경하지 않는 이상은 말이죠.

하지만 애플은 백그라운드 쓰레드로 데이터를 옮길 수 있는 아주 쉬운 API(Grand Central Dispatch와 NSOperation)를 제공합니다.
iOS5에서는 심지어 코어 데이터가 꼭 메인 쓰레드에 있을 필요도 없습니다.

즉, 이것은 개발자의 문화적 차이라고 생각합니다.
쉽게 설명하자면 애플 개발자들은 60fps에 근접하고, 터치 관련 이벤트가 모두 정상적으로 작동이 되야만, 출시를 하는 문화를 가지고 있다는 소리입니다.
물론, 뛰어난 안드로이드 개발자분들의 경우는 애플보다 뛰어난 성능으로 출시하기도 하지요.

Google +에 나온 글을 살펴보더라고 UI가 느린 것은 인정하지만, 그 이유에 대해서는 확실히 다른 방향으로 이야기 하고 있습니다.

제가 이야기 했듯이 안드로이드의 UI가 버벅이는 근본적인 이유는 쓰레드와 우선권 때문일껍니다.
하지만 그것이 전부는 아니죠. 위에서 설명한 이야기들은 근본적인 이유들입니다.

왜 UI쓰레드와 우선권을 그렇게 설정했는지, 꼭 그렇게 해야했는지에 대한 이야기말이죠.

하지만, 근본적인 이유뿐 아니라, 어쩌면 더 위험한(?) 이슈들도 존재합니다.
이 이슈들은 차차 나아지고, 허니컴부터는 엄청나게 성능이 향상되기도 했습니다!
(구글 측도 아마 이 렌더링에 대한 부분에 엄청 신경쓰는 것 같습니다.)

아무튼, 몇 가지를 더 살펴보죠.

ICS에서 갤러리 앱을 써봤다면, 어째서 프레임이 이렇게 떨어지는지 궁금했을 수도 있습니다.
결과적으로 말하자면 이것은 “제한”입니다.

아시는 분들도 계시겠지만, 갤러리는 30fps로 제한이 걸려있습니다.
이유가 무엇일까요?

뛰어난 하드웨어를 장착한 스마트폰의 경우 충분히 60fps로 돌아갈 것 입니다.
하지만, 60fps로 제한을 풀어두면 이놈의 GC가 멈춰서 메모리가 토하는 경우가 발생할 수 있습니다.

결국은 이 문제를 해결하기 위해 30fps로 합의 본 것이라고 생각하시면 되겠습니다.
(지금은 어떤지 모르겠네요..하지만 제 폰은 여전히 느립니다)

마지막으로 JVM의 차이도 한 몫을 합니다.

Dalvik은 JVM 만큼 뛰어난 성능을 가지고 있지 않습니다.
네이티브 API들 위에 크로스 플랫폼 레이어가 올라가 있기 때문인데, 윈7에서도 처음 실버라이트를 채택했다가
이러한 문제들 때문에 네이티브로 변경한 것으로 알고 있습니다.

물론 이런 문제들은 계속 수정해나가려고 노력하고 있고, 그 결과가 조금씩 보여지는 것 같습니다.
결론은 무엇이냐구요?

안드로이드는 위에서 설명한 한계가 존재하는 한 더 이상 부드러워질 수 없다가 아닌가 합니다.
뭐 개인적이지만, Google+에서도 공개되었고 몇 가지 공감하는 내용들이기도 하니 어느정도는 정확하다고 생각합니다.

어떤 방식으로 개선되고 있고, 각 기업별로 처리하는 방식이 다를 수도 있다고 생각하지만, 이런 부분까지는 알지 못합니다만,
아무튼 다른 것은 몰라도, Android UI Thread 처리 부분은 반드시 뜯어 고쳐야 할 문제가 아닌가라는 것이 갠적인 결론입니다.

글이 길어졌네요;

위와 비슷한 글은 google+에서도 확인 할 수 있습니다!
그리고 다른 것은 몰라도 UI 쓰레드 우선순위에 대한 문제는 인정을 하고 있구요!

안드로이드 NDK는 안드로이드 애플 리케이션에서 네이티브 코드의 구성요소들을 포함할 수있는 도구 모음을 말합니다.

많은 분들이 알고 계시겠지만, 안드로이드 어플 리케이션은 Dalvik 가상 머신에서 실행됩니다.
NDK는 C나 C++같은 네이티브 코드 언어를 사용하여 응용 프로그램의 일부를 구현할 수 있도록 하고, 기존 코드를 재사욧 할 수 있도록 제공하는 하나의 개발 툴 킷입니다.

구글에서 소개하는 NDK는 아래와 같은 기능을 제공하고 있습니다!!|

NDK에서 지원하는 것들 :

• C 및 C + + 소스로부터 네이티브 코드 라이브러리를 생성하는 데 사용되는 파일을 빌드할 수 있다.
• 응용 프로그램 패키지 파일에 해당 네이티브 라이브러리를 포함 할 수 있습니다.
• Android 1.5부터는 다 쓸 수 있지요!

NDK의 최신 릴리즈 버전에는 다음과 같은 명령어 세트를 지원합니다 :

• ARMv5TE, including Thumb-1 instructions
• ARMv7-A, including Thumb-2 and VFPv3-D16 instructions, with optional support for NEON/VFPv3-D32 instructions (see docs/CPU-ARM-NEON.html for more information)
• x86 명령
• MIPS 지침

ARMv5TE 기계 코드는 모든 ARM 기반 안드로이드 디바이스에서 실행됩니다. (알고 있는 부분이라 생각됩니다!)

ARMv7-A와 같은 버라이존 Droid 또는 호환 CPU를 가지고 하나의 장치에서 실행시킬 수 도 있습니다.
5와 7 두 명령ㅇ의 주요 차이점은 ARMv7-A는 FPU을 지원한다는 것입니다. 또  명령 집합 중 하나 또는 모두를 타겟팅할 수 있습니다.

물론, 5가 디폴드로 지원되고 있습니다. 이 정보들은 기억은 잘 나지 않지만,  CPU-ARCH-ABIS.HTML라는 이름으로
NDK 패키지 내에 포함되어 있을껍니다..(아마도…)

이 NDK로 제가 해봤던 것은 OpenGL을 사용해봤고, 그 외에도 libc (the C library), libm (the Math library), JNI등을 이용할 수 있습니다.

가장 많이 사용되는 것은 흔히 알고 있는 JNI가 되겠지요!
(JNI를 사용하기 위해서는 Cgwin이 필요합니다~~이건 검색하면 나와요~)

기계어 코드로 개발하는 경우

솔직히 개인적인 의견으로는 NDK는 대부분의 어플리케이션에 필요없는 것 같스빈다.
단지 개발자가 C나 C++를 선호하기 때문에 NDK를 사용하는 것은 심각하게 잘못된 방법이라고 생각하구요!
(원시 코드를 사용하면 자동으로 성능 향상을 초래하지 않지만 항상 응용 프로그램의 복잡성을 증가시킵니다. 이론 시간에 배워요!)

NDK를 사용 할 만한 좋은 예는 신호 처리, 물리 시뮬레이션, 비할당 메모리를 처리하는 집약적인 작업에 사용하기 좋습니다~
(물론 갠적인 생각입니다…)

아 물론, 기존의 C / C + + 코드의 대규모 코퍼스를 재사용 한다면 매우 유용한 방법으로 NDK를 사용하는 것이라고 할 수 있죠!

마지막으로, NDK는 리눅스, OS X 및 Windows (Cygwin 포함) 플랫폼에서 네이티브 ARM 바이너리를 생성할 수 있습니다 Cross toolchains이 가능하다는 소리죠!

(컴파일러, linkers 등.)

지원하는 헤더들은 아래와 같습니다. 또 이 외에도 추가로 헤더를 추가할 수도 있는 것으로 압니다. 진저브레드에서 추가된 기능으로 알고 있는데
그 버전부터는 해본 적이 없네요….아무튼…

• libc (C 라이브러리) 헤더
• libm (수학 라이브러리) 헤더
• JNI 인터페이스 헤더
• libz (Zlib 압축) 헤더
• liblog (안드로이드 로깅) 헤더
• OpenGL은 ES 1.1 및 OpenGL을 ES 2.0 (3D 그래픽 라이브러리) 헤더
• libjnigraphics (픽셀 버퍼 액세스 헤더 안드로이드 2.2 이상의 경우).
• C + + 지원에 대한 헤더의 최소 집합
• OpenSL ES 고유의 오디오 라이브러리
• 안드로이드 네이티브 응용 프로그램 API를

도움이 되셨나요? 저도 아는 것이 많이 없어서 도움 되실까 작성해봤습니다!
사내교육 받으신 분들은 꼭 좀 알려주셔서 서로 정보를 공유했으면 좋겠네요!