Android Application Design Philosophy
안드로이드 애플리케이션 디자인 철학The process of learning how to build applications for a new API is pretty similar, even if the platforms themselves are wildly different. Generally, there are two phases: first, you learn how to use the APIs to do what you want to do; later, you learn the nuances of the platform. Put another way, first you learn how you can build applications; later, you learn how you should build them. 새로운 API를 위한 애플리케이션을 제작방법을 배우는 절차는, 심지어 플랫폼 자체가 많이 다를지라도 꽤 유사하다. 일반적으로 두가지 단계가 존재한다. 첫째는 여러분이 하길 원하는 것을 하기 위한 API를사용하는 방법을 배우고나서, 여러분이 플랫폼의 뉘앙스(미묘한 차이)를 배우는 것이다. 또 다른 방법은먼저 여러분이 어떻게 애플리케이션을 만들 수 있는가를 배우고 나서 애플리케이션을 만드는 것을 배우는것이다. That second phase — learning the right way to build applications — can often take a long time, and frequently means "paying your dues", making mistakes, and learning from them. Well, that's not a very efficient process, so this page and the links below aim to give you a helping hand.Before we dive into it, a quick word. Successful applications will offer an outstanding end-user experience. While the Android team has built a robust core system, the vast majority of the user experience will come from users interacting with your applications. As a result, we encourage you to take the time to build an outstanding user experience.
두번째 단계-애플리케이션을 만드는 올바른 방법을 배우는 것-는 종종 오랜 시간이 소요될 수 있다.그리고 자주 실수를 하고 그것으로 부터 배우는 "수업료 내기"를 의미한다. 그것은 매우 효율적인 절차는아니다. 그래서 이 페이지와 아래의 링크들은 여러분에게 도움의 손길을 주기 위함이다.우리가 그것에 착수하기 전에, "a quick word". 성공적인 애플리케이션들은 우수한 최종사용자 체험을제공할 것이다. 안드로이드 팀이 튼튼한 핵심 시스템을 만드는 동안, 사용자 체험에 대한 광범위한 주류가
여러분들의 애플리케이션과 상호작용하는 사용자들로 부터 올 것이다. 결과적으로, 우리는 우수한 사용자체험을 구축하기 위한 시간을 여러분이 할애할 것은 장려한다. An outstanding user experience has three key characteristics: it is fast; it is responsive; and it is seamless. Of course every platform since the dawn of computing has probably cited those same three qualities at one time or another. However, each platform achieves them in different ways; the information below explains how your apps can achieve them on Android. 우수한 사용자 체험은 세가지 핵심 특징을 가진다. 그것은 신속성이다. 그것은 응답성이다. 그리고 그것은무결절성이다. 물론 컴퓨팅의 여명이 밝은 이래로, 모든 플랫폼은 아마도 위와 같은 세가지 특징을 동시에또는 다르게든 열거했다. 그렇지만, 각각의 플랫폼은 다른 방법으로 그것을 달성한다; 아래의 정보는 여러분의애플리케이션이 안드로이드상에서 그것을 달성할 수 있는 방법을 설명한다.
Fast | 신속성An Android application should be fast. Well, it's probably more accurate to say that it should be efficient. There is a tendency in the computing world these days to assume that Moore's Law will solve all our problems — eventually. When it comes to embedded applications, though, Moore's Law is a bit more complicated.
안드로이드 애플리케이션은 빨라야 한다. 아마도 그것은 효율적이어야 한다고 말하는 것이 더 정확할것이다. 오늘날의 컴퓨팅 세계에서는 무어의 법칙이 결국에는 모든 우리들의 문제들을 해결해 줄 것이라고여기는 경향이 있다. 하지만, 임베디드 애플리케이션으로 오게되면, 무어의 법칙은 다소 더 복잡해진다.
Moore's Law doesn't really apply to mobile devices in the same way as to desktop and server applications. Moore's Law is actually a law about transistor density — that is, it says that you can pack more circuitry into a given chip size, over time. For desktop and server applications, this means you can pack more "speed" into a chip of roughly the same size, resulting in the well-known performance increases. For embedded applications like cell phones, however, Moore's Law is usually exploited to make chips smaller. That is, the tendency is to use the increased density to make the same chip smaller and consume less power, to make phones smaller and make batteries last longer. As a result, embedded devices like phones are increasing in actual, raw speed much more slowly than desktop systems. For embedded devices, Moore's Law means more features and better battery life; increased speed is only an afterthought. 무어의 법칙은 데스트탑이나 서버 애플리케이션에 대한 것과 동일한 방식으로 모바일 디바이스에 대해서는실제로 적용되지 않는다 무어의 법칙은 사실은 트랜지스터 집적에 대한 법칙이다. 그것은 시간이 지나면서주어진 칩 크그속에 더 많은 회로를 담을 수 있다는 것을 말하는 것이다. 데스트탑이나 서버 애플리케이션에대해서는 이것은 대충 같은 크기의 칩에 더 많은 속도를 담을 수 있음을 의미하며, 그 결과는 잘 알려진 성능향상이다. 하지만, 셀 폰과 같은 임베디드 애플리케이션에 대해서, 무어의 법칙은 통상적으로 칩을 더 작게만드는 것에 적용된다. 작게 한다는 것은, 폰을 더 작게 만들면서 더 오래 지속되는 배터리를 만들기 위해, 같은 칩을 더 작게하고 더 적은 전력을 소비하는 향상된 집적도를 사용할려는 경향이다. 그 결과, 폰과 같은 임베디드 디바이스는 데스크탑 시스템들 보다 더 천천히 속도가 증가하고 있다. 임베디드 디바이스에 대해서, 무어의 법칙은 더 많은 기능과 더 좋은 베터리 수명을 의미하며, 속도 개선은 단지 그 다음 고려사항일 뿐이다. That's why it's important to write efficient code: you can't assume that phones will see the same speed increases as desktops and servers. Generally speaking, writing fast code means keeping memory allocations to a minimum, writing tight code, and avoiding certain language and programming idioms that can subtly cripple performance. In object-oriented terms, most of this work takes place at the method level, on the order of actual lines of code, loops, and so on.The article on Writing Efficient Android Code will give you all the detail you need to write fast, efficient code for Android. 이것이 더 효율적인 코드를 만드는 것이 중요한 이유이다: 여러분은 데스크탑이나 서버같은 속도 향상을 폰에서볼 수 있을 것이라는 가정을 할 수 없다. 일반적으로 말하길, 빠른 코드를 만든다는 것은 메모리 사용을 최소로유지하는 것, 압축된 코드를 만드는것, 그리고 미세한 성능 하락이 있을 수 있는 어떤 언어나 프로그래밍 특색을피하는 것을 의미한다. 객체 지향 영역에서는, 대부분의 이러한 작업은 코드의 실적적인 라인의 순서와 루프,그리고 기타 등등에 대한 메쏘드 레벨에 존재한다."효율적인 안드로이드 코드"에 대한 글은 안드로이드에 대한 빠르고, 효율적적인 코드를 작성하기 위해 여러분이필요로 하는 모든 상세한 것을 제공할 것이다.
Responsive | 응답성It's possible to write code that wins every performance test in the world, but that still sends users in a fiery rage when they try to use it. These are the applications that aren't responsive enough — the ones that feel sluggish, hang or freeze for significant periods, or take too long to process input. In Android terms, applications that are insufficiently responsive will frequently cause the system to pop up the dreaded "Application Not Responding" (ANR) message. 세상에 있는 모든 성능 테스트를 통과하는 코드를 작성하는 것을 작성하는 것은 가능하다. 하지만, 사용자들이그것을 사용할려고 시도할 경우, 여전히 사용자들을 꽤나 불편하게 할 수 있다. 이것들은 응답성이 충분치 않는 애플리케이션들이다 - 둔하게 느껴지고, 중요한 시점들에서 죽거나 멈추고, 또는 입력을 처리하는데 너무오래 걸리는 것. 안드로이드 영역에서 애플리케이션이 응답할 수 없게 되면, 빈번하게 경고성의 "ApplicationNot Responding"(ANR) 메시지를 팝업시키도록 한다. Generally, this happens if your application cannot respond to user input. For example, if your application blocks on some I/O operation (frequently a network access), then the main application thread won't be able to process incoming user input events. After a time the system will conclude that your application has hung, and give the user the option to kill it. Similarly, if your application spends too much time building an elaborate in-memory structure, or perhaps computing the next move in a game, then again the system will conclude that your application has hung. It's always important to make sure these computations are efficient using the techniques above, but even the most efficient code still takes time to run. 일반적으로, 이것은 사용자 입력에 애플리케이션이 반응할 수 없을 때 발생한다. 예를들어, 여러분의 애플리케이션이 어떤 입/출력 작업(빈번하게 네트웍 접근)에서 멈추어 있다면, 그러면 메인 애플리케이션쓰레드는 사용자 입력 이벤트를 받아들일 수 없다. 잠시 후,시스템은 여러분의 애플리케이션이 멈춰 섰다고결론내릴 것이고, 그것을 종료하기 위한 선택권을 사용자에게 줄 것이다. 유사하게, 여러분의 애플리케이션이정교한 메모리내의 구조를 만들거나, 또는 아마 게임에서 다음으로 이동하동하기 위한 연산에 너무 많은시간을 소비한다면, 시스템은 또다시 여러분의 애플리케이션이 멈춰 섰다고 결론내릴 것이다. 이러한 연산이 위의 테크닉들을 사용하여 효율적으로 이루어지게 하는 것은 중요하다. 하지만 심지어 매우 효율적인코드도 여전히 실행 시간을 갖는다. In both of these cases, the fix is usually to create a child thread, and do most of your work there. This keeps the main thread (which drives the user interface event loop) running, and prevents the system from concluding your code has frozen. Since such threading usually is accomplished at the class level, you can think of responsiveness as a class problem. (Compare this with basic performance, which was described above as a method-level concern.)The article on Building Responsive Android Applications discusses responsiveness in detail. 이러한 경우들 둘 다에서, 해결방법은 통상적으로 자식 쓰레드를 생성해서 대부분의 여러분의 작업을 그것이 하는 것이다. 이것은 (사용자 인터페이스 이벤트 루프를 처리하는) 메인 쓰레드를 실행상태로 유지하고, 시스템이 여러분의 코드가 멈췄다고 결론내리는 것을 예방한다. 통상적으로 그러한 쓰레딩은 클래스 레벨에서이루어지기 때문에, 여러분은 응답성을 클래스 문제로 생각할 수 있다. (메쏘드 레벨의 고려로써 위에서 설명했던 기본적 성능과 이것을 비교해 보라)"응답성있는 안드로이드 애플리케이션 만들기"에 있는 글은 응답성에 대해 상세히 언급한다.
Seamless | 무결절성Even if your application is fast and responsive, it can still annoy users. A common example is a background process (such as an Android Service or IntentReceiver) that pops up a UI in response to some event. This may seem harmless, and frequently developers assume that this is okay because they spend most of their time testing and using their own application. However, Android's application model is constructed explicitly to allow users to fluidly switch between applications. This means that when your background process actually fires up that UI, the user could be way over in another part of the system, doing something else — such as taking a phone call. Imagine if the SMS service popped up a dialog box every time a text message came in; this would annoy users in no time. That's why the Android standard is to use Notifications for such events; this leaves the user in control. 여러분이 애플리케이션이 빠르고 응답성이 있다 하더라도, 여전이 사용자를 불편하게 할 수 있다. 하나의일반적인 예가 특정 이벤트에 반응하는 UI를 팝업하는 백그라운드 프로세스(안드로이드 Service 또는 IntentReceiver 같은)이다. 이것은 위험해 보이지 않을 수 있다. 그리고 빈번하게 개발자들은 자신 자신의애플리케이션을 테스트하고 사용하는데 대부분의 시간을 보내기 때문에 그것은 되었다고 여긴다. 하지만,안드로이드의 애플리케이션 모델은 명시적으로 사용자들이 애플리케이션들을 부드럽게 전환할 수 있도록만들어 졌다. 이것은 여러분의 백그라운드 프로세스가 실제로 UI를 보여줄 때, 그 사용자는 전화를 거는 것 같은 그밖의 어떤 것을 하는 시스템의 다른 영역에 있을 수 있다는 것을 의미한다. 문자 메시지가 도착할 때마다 항상 다이얼로그 박스를 팝업하는 SMS 서비스를 상상해 봐라; 이것은 시간이 없을 때에는 사용자에게불편할 수 있다. 그것이 안드로이드 표준이 그러한 이벤트에 대해 Notifications을 사용하는 이유이다; 이것은사용자를 제어 상태로 유지한다. That's just one example; there are many more. For example, if Activities don't correctly implement the onPause() and other life-cycle methods, this will frequently result in data loss. Or, if your application exposes data intended to be used by other applications, you should expose it via a ContentProvider, rather than (for example) using a world-readable raw file or database. 그것은 단지 하나의 예이다; 더 많은 것들이 있다. 예를 들어, 만약 Activity들이 onPause()와 다른 생명주기메쏘드들을 정확하게 구현하지 않는다면, 이것은 비번하게 데이타 손실을 일으킬 것이다. 또는 만약 여러분의애플리케이션이 다른 애플리케이션에 의해 사용될 수 있도록 확장된 데이타를 제시한다면, 여러분은 (예를
들자면) 어디서나 읽을 수 있는 원시파일 또는 데이타베이스를 사용하는 것 보다 차라리 ContentProvider를 통해 그것을 보여주어야 한다.
What those examples have in common is that they involve cooperating nicely with the system and other applications. The Android system is designed to treat applications as a sort of federation of loosely-coupled components, rather than chunks of black-box code. This allows you as the developer to view the entire system as just an even-larger federation of these components. This benefits you by allowing you to integrate cleanly and seamlessly with other applications, and so you should design your own code to return the favor. 이러한 예들이 보편적으로 가지고 있는 것은 그것들이 시스템 및 다른 애플리케이션들과 잘 상호협조하는 것을 포함하고 있다는 것이다. 안드로이드 시스템은 블랙박스 코드 덩어리보다는 느슨하게 결합된 컴포넌트의연합의 하나의 부류로써 애플리케이션들을 취급하도록 디자인 되었다. 이것은 여러분이 개발자로써 전체시스템을 이러한 컴포넌트들의 단지 더 큰 하나의 연합으로 볼 수 있게끔 한다. 이것은 여러분이 다른 애플리케이션과 쉽게 그리고 끊김없이 연동하는 것을 가능하게 하는 혜택을 준다. 그러므로 여러분은 그러한해택을 얻을 수 있도록 여러분 자신의 코드를 디자인 해야 한다. This is a component-level concept (as opposed to the class- and method-level concepts of performance and responsiveness, described above.) The article on Integrating with the System provides tips and best practices for writing code that cooperates nicely with the rest of the system. 이것은 하나의 컴포넌트 레벨 개념이다(위에서 설명한 성능과 응답성에 대한 클래스나 메쏘드 레벨 개념과는
대립되는). "시스템 연동하기" 글은 나머지 시스템 영역과 잘 협력하는 코드를 작성하는 것에 대한 팁과 좋은 사례를 제공한다.
|
Android Application Design Philosophy
