블로그 이미지
ssun++

카테고리

[전체] (73)
Android (7)
JavaScript (9)
CI (5)
Language (14)
ETC (38)
Total314,893
Today21
Yesterday23

'2014/05'에 해당되는 글 4건

  1. 2014.05.27 Registration
  2. 2014.05.27 Developers Guide
  3. 2014.05.26 Cast Your Content to the Big Screen
  4. 2014.05.25 Keeping Your App Responsive

Registration

Android/Cast / 2014.05.27 23:03

원문 : https://developers.google.com/cast/docs/registration


You must register your application if you are using the Styled Media Receiver or you are building a Custom Receiver. Once you've registered your application, you'll receive an app ID that your sender application must use to perform API calls such as to launch the receiver application.


Styled Media Receiver를 사용하거나 Custom Receiver를 만들 때 반드시 앱을 등록 해야한다. 앱을 등록하면 앱 ID를 받게되고, sender 앱이 API를 호출할 때 사용해야한다. (receiver 앱을 실행하는 등)


You must also register your Google Cast device so that it may access your receiver application before you publish it. Once you publish your receiver application, it will be available to all Google Cast devices.


또한 receiver 앱을 발행하기 전에 접근하려면 Google Cast 장치를 등록해야 한다. receiver 앱을 발행하면, 모든 Google Cast 장치에서 접근이 가능하다.


Register your application


You must register your Styled Media Receiver or Custom Receiver in order to receive an app ID that's used with API calls from the sender application.

To register your receiver app:

  1. Sign in to the Google Cast SDK Developer Console.
  2. From either the Overview page or Applications page, click Add New Application.
  3. Select the type of receiver app you will use:
    Custom Receiver
    Select this if your app requires user interface components or interaction patterns that are not provided by the Styled Media Receiver. Selecting Custom Receiver may also be necessary if your content type is not listed as one of Styled Media Receiver's supported media types.

    Be aware that this option requires that you build a complete web app for the receiver app.

    For details, read Custom Receiver Application.

    Styled Media Receiver
    Select this if your app streams video or audio content using one of the supported media types and you'd like to provide a user interface on the TV that uses either the default media player UI or a set of custom styles on top of the default media player UI.

    The custom styles you may provide allow you to define the look for various elements of the player UI (such as the splash screen and progress bar) simply by providing a CSS file—you do not need to build a receiver app.

    For details, read Styled Media Receiver.

  4. Fill in the details for you receiver app:
    1. Enter your app name.
    2. Specify the receiver app's appearance:
      • For a Custom Receiver, specify the app URL.

        Enter a URL that the Google Cast device should request when loading your receiver app. During development the URL can use HTTP but when the app is published it has to use HTTPS. The URL may be for an HTML page or other file type accessible from a web browser. It's okay for your receiver to be on an internal (NAT-registered) IP address, but not on localhost, as it is rarely a top level domain. Although the receiver app must be served over SSL (HTTPS) when published, the content loaded on the receiver app may be served over HTTP.

      • For a Styled Media Receiver, specify the app style.

        Select Default for the default media player UI. (You can later switch to Custom if you decide to provide your own UI styles.)

        Select Custom to provide your own CSS file that specifies the appearance for several elements of the media player UI. In the input field that appears, provide an HTTPS URL that points to your CSS file located on your own web site or onGoogle Drive.

        Click Preview at the bottom to view your receiver app's appearance using mock media content.

    3. Select whether the app should be published for end-users.

      Leave this set to No while developing and testing your app with a registered Google Cast device.

      When you're ready to publish your app for end-users, set this to Yes.

    4. Select the platforms on which your sender app will be available and provide the relevant identification information.
  5. Click Save.

In the list of Applications, your new app is listed with a unique Application ID. Copy this ID for use in the code for your sender app.

If you selected Styled Media Receiver, there's nothing else you need to do for the receiver app, other than provide optional CSS styling as described in the Styled Media Receiver guide.

If you selected Custom Receiver, you must provide a web app as described in the Custom Receiver Application guide.


sender 앱에서 API 호출 시 사용할 앱 ID를 받기 위해서 Styled Media Receiver 또는 Custom Receiver를 반드시 등록해야 한다. 

앱을 등록하기 위해서는 :

  1. Google Cast SDK Developer Console에 로그인 한다.
  2. Overview 또는 Applications 페이지에서, click Add New Application을 클릭한다.
  3. receiver 앱의 타입을 선택한다.

    Custom Receiver

    Styled Media Receiver가 제공하지 않는 UI 컴포넌트나 인터랙션 패턴이 필요한 경우 선택한다. 콘텐트 타입이 Styled Media Receiver의 supported media types에 나타나지 않는 경우에도 Custom Receiver를 선택한다.

    이 옵션을 선택할 경우 receiver 앱을 위해 완전한 웹앱을 구축해야 함을 알아야 한다.

    자세한 사항은 Custom Receiver Application을 읽어보자.

    Styled Media Receiver

    앱이 supported media types에 리스팅 된 비디오나 오디오 콘텐트를 전송하고, TV에서 디폴트 미디어 플레이어 UI나 상단에 커스텀 스타일을 적용한 디폴트 미디어 플레이어 UI를 제공할 경우 선택한다.

    커스텀 스타일은 단순히 CSS 파일을 제공함으로써 플레이어 UI의 다양한 엘리먼트의 룩을 정의할 수 있다 (스플래시 화면, 프로그레스 바 등) - receiver 앱을 구축할 필요가 없다.

    자세한 사항은 Styled Media Receiver을 읽어보자.

  4. receiver 앱의 상세 사항을 채우자:

    1. 앱 이름을 넣고.
    2. receiver 앱의 외양을 정한다:

      • Custom Receiver의 경우, app의 URL을 정한다.

        Google Cast 장치가 receiver 앱을 로딩할 때 요청할 URL을 입력한다. 개발하는 동안 URL은 http를 사용할 수 있지만 발행되면 https를 사용해야 한다. URL은 HTML 페이지나 웹브라우저에서 접근 가능한 파일 타입이 되어야 한다. receiver가 내부 IP를 가지는 것은 상관없으나, localhost가 되어서는 안된다. receiver 앱은 발행시 SSL을 통해 제공되어야 하지만, receiver 앱에 로드되는 콘텐츠는 HTTP를 통해 제공되어야 한다.

      • Styled Media Receiver의 경우 앱 스타일을 정한다.

        디폴트 미디어 플레이어 UI를 적용하려면 Default를 선택한다.(자체 UI 스타일을 제공하려면 나중에 Custom으로 바꿀 수 있다.)

        자체 CSS 파일을 제공하여 미디어 플레이어 UI 엘리먼트의 외양을 정하려면 Custom을 선택한다. 입력 필드에는 CSS 파일이 위치한 웹사이트나 Google Drive의 HTTPS URL을 입력한다.

        mock media content를 사용하여 receiver 앱을 보기 위해서는 하단의 Preview를 클릭한다. 

    3. 최종 사용자에게 발행할지를 선택한다.

      등록된 Google Cast 장치로 개발과 테스팅을 하는 동안은 No로 둔다.

      최종 사용자에서 발행할 준비가 되면 Yes로 결정한다.

    4. sender 앱이 구동될 플랫폼을 선택하고, 적절한 정보를 제공한다.
  5. Save를 클릭한다.

앱 목록에서, 새로운 앱은 유니크한 앱 ID와 함께 리스트 되어있다.  sender app을 위해 이 ID를 복사하자.

Syled Media Receiver를 선택했다면, Styled Media Receiver 가이드에 설명된 것처럼 추가적인 CSS 제공하는 것 외에는 receiver 앱을 위해 해야할 것은 없다.

Custom Receiver를 선택했다면, Custom Receiver Application 가이드에 에 설명된 것처럼 웹앱을 제공해야 한다.


Register your Google Cast device


By default, Google Cast devices (such as a Chromecast) are not enabled for development and testing. To turn your device into a development device and gain access to your receiver app while it is not yet published, you must register the device. Registering also makes the receiver app accessible from a remote browser window for debugging (see Debugging).


기본적으로, Google Cast 장치는 개발과 테스팅이 가능하지 않다. 장치를 개발 가능하게 하고 발행되지 않은 receiver 앱에 접근하기 위해서, 장치를 등록해야 한다. 등록을 통하여 receiver 앱을 원격 브라우저 창에서 접근 할 수 있게된다.


To register your Google Cast device:

  1. Sign in to the Google Cast SDK Developer Console.
  2. From either the Overview page or Devices page, click Add New Device.
  3. Enter the serial number of your development device. This is a 12-digit alphanumeric string printed on the device.

    The serial number on a Chromecast is laser-etched (not printed) and begins with a 3, 4 or 5. It may be easier to read if you take a picture of the serial number then enlarge it.

  4. Enter a description. This is just a friendly name for your device (it does not need to match the name you gave to the device during user setup).
  5. Click OK.

    It may take several minutes for the device to become registered and available as your development device. Once registration is complete, the Status for the device will say "Ready for Testing."

  6. Restart the Google Cast device that you have registered. Check whether you can access http://<cast-device-ip>:9222 from a chrome browser on the same WiFi network; if you can, then your device is ready for development.

Google Cast 장치 등록하기

  1. Google Cast SDK Developer Console에 로그인한다.
  2. Overview 페이지나 Devices 페이지에서 Add New Device를 선택한다.
  3. 개발 장치의 일련번호를 입력한다. 12자리의 알파벳과 숫자로 되어 장치에 프린트 되어있다.

    Chromecast의 일련번호는 레이저 각인되어 3, 4, 5로 시작한다. 사진을 찍어서 확대하면 읽기 쉬울 것이다.

  4. 설명을 입력한다. 장치를 위한 친근한 이름이다. (setup 시 입력한 이름과 일치할 필요는 없다.)
  5. OK를 클릭한다.

    장치가 등록되어 개발 장비로 사용할 수 있기 까지는 몇 분이 걸린다. 등록이 완료되면 장치의 상태가 "Ready for Testing"이 된다.

  6. 등록된 Google Cast 장치를 재시작한다. 동일한 WiFi network의 chrome browser에서 http://<cast-device-ip>:9222 로 접근이 가능한지 확인한다 : 가능하다면 장치는 개발 가능한 상태이다.


Posted by ssun++

댓글을 달아 주세요

Developers Guide

Android/Cast / 2014.05.27 21:34

원문 : https://developers.google.com/cast/docs/developers


The Google Cast SDK includes API libraries and sample application code to help you cast your applications to the big screen. These APIs are documented in the API references, and the sample code is discussed in the Sender Applications and Receiver Applications overviews.


Google Cast SDK는 API 라이브러리와 큰 화면으로 앱을 cast 할 수 있도록 도와주는 샘플 앱 코드를 포함한다. API는 API references에 문서화 되어있고, 샘플 코드는 Sender ApplicationsReceiver Applications overview에서 논의된다.


Components


Here's what you need to build a Cast app.Here's what you need to build a Cast app.

  • A sender application, written for the Android, iOS, or Chrome platform which uses the following Cast APIs:
  • A receiver application that handles communication between the sender app and the receiver device. You have the following options:
    • The Default Media Receiver presented with the Google Cast branding and styling.
    • The Styled Media Receiver for which you can develop the styles and branding. See Styled Media Receiver.
    • A custom receiver, as described in Custom receiver that implements the Receiver API and handles custom messages from your sender app; it may also interface with the media player types provided through the Media Player Library.

How you implement your receiver may depend upon which media types your application needs to support.


  • receiver 앱은 sender 앱과 receiver 장치 간 커뮤니케이션을 다룬다. 아래와 같은 옵션이 있다.
    • Google Cast 브랜딩과 스타일의 Default Media Receiver
    • Custom receiver에 설명된 것처럼 Receiver API를 구현하고 sender 앱으로부터의 custom 메세지를 다루는 Custom receiver; 또한 Media Player Library를 통해 제공되는 media player type을 인터페이스 할 수 있다.

receiver를 어떻게 구현하는지는 앱이 지원해야 할 media type에 따라 달라진다.


Get Started


  1. First, get set up for development:
    1. Install your Chromecast device and run through the Chromecast Setup instructions.
    2. Run the Chromecast app on your sender device, following the prompts as directed.
    3. Under Privacy, check the box to Send this Chromecast's serial number when checking for updates.
    4. You must select this option in order to enable your receiver device for development.
  2. Review the User Experience Guidelines showing you how to implement a UI that is consistent with other Cast apps.
  3. Download the API libraries and sample apps.
  4. Register your application.
  5. You will receive an app ID to include with your API calls.
  6. Develop your app.
    • Check out the Google Cast app development overviews:
      • Android sender
      • iOS sender
      • Chrome sender
      • Receiver
    • Peruse the API references.


  1. 먼저, 개발을 위한 준비를 한다.
    1. Chromecast 장치를 설치하고 Chromecast Setup 을 따라 한다.
    2. sender 장치에서 Chromecast 앱을 실행시키고, 하라는대로 따라 하자
    3. 개인 정보에서, "업데이트를 확인할 때 Chromecast의 일련번호를 전송" 박스를 체크한다. 
    receiver 장치에서 개발이 가능하게 하기 위해서 이 옵션을 꼭 선택해야 한다.
  2. 다른 Cast 앱들과 일관성 있는 UI를 어떻게 개발하는지 보여주는 User Experience Guidelines 를 확인한다.
  3. API 라이브러리와 샘플 앱을 Download 한다.
  4. 앱을 등록한다.
  5. API 호출 시 필요한 app ID를 받을 것이다.
  6. 앱을 개발한다.
    • Check out the Google Cast app development overviews:


Posted by ssun++

댓글을 달아 주세요

원문 : https://developers.google.com/cast/


Google Cast is a technology that enables multi-screen experiences and lets a user send and control content like video from a small computing device like a phone, tablet, or laptop to a large display device like a television.


Google Cast는 멀티 스크린 경험을 가능하게 하고, 사용자가 폰이나 태블릿 같은 작은 장치의 콘텐트를 TV와 같이 큰 장치로 보내거나 컨트롤 할 수 있게 해주는 기술이다.


The sender may be a phone or tablet running on Android or iOS, or it may be a laptop computer running Chrome OS, Mac OS, or Windows. A sender application running on the sender device uses the Google Cast API appropriate to its operating system to discover and transmit to the receiver application running on the receiver device. You can use the sender APIs to enable your Android, iOS, or Chrome app to send content to a large display.


sender는 Android나 iOS가 탑재된 폰이나 태블릿, 또는 Chrome OS, Mac OS, Windows가 탑재된 랩탑이 될 수 있다. sender 장치의 sender 앱은 Google Cast API를 적절하게 사용하여 OS가 발견하고 receiver 장치의 receiver 앱으로 보낼 수 있도록 한다. sender API를 사용하여 Android, iOS, Chrome 앱이 큰 디스플레이로 콘텐트를 전송 할 수 있다.


The receiver device is optimized for video playback with a receiver application that receives data over Internet Protocol and transmits it to the television. The receiver API lets you customize the messaging between the sender and receiver applications for authentication and other scenarios.


receiver 장치는 재생에 최적화 되어있어서 인터넷 프로토콜을 통하여 데이터를 받아서, TV로 전달한다. receiver API를 사용하여 sender와 receiver 간의 메시징을 커스터마이징 할 수 있다.


While content is playing on a TV, a user can multitask on their device without interrupting the video playback. For example, a user can search for a video on their phone’s YouTube application and then send the video to their TV via a Google Cast device. The user can play, pause, seek, and control volume using their phone, they can search for other videos to watch, and even check their email while the content keeps playing on the TV.


TV에서 콘텐트가 재생되고 있는 동안, 사용자는 비디오 재생을 방해하지 않고 멀티 태스킹을 할 수 있다. 예를 들어, 사용자는 유튜브 앱에서 영상을 검색하고 Google Cast 장치를 통해 TV로 영상을 전송할 수 있다. 사용자는 폰을 사용하여 재생, 멈춤, seek, 볼륨 조절 등을 할 수 있고, 다른 영상을 검색하거나, 이메일을 확인 할 수 도 있다.

Posted by ssun++

댓글을 달아 주세요

원문 : http://developer.android.com/training/articles/perf-anr.html


It's possible to write code that wins every performance test in the world, but still feels sluggish, hang or freeze for significant periods, or take too long to process input. The worst thing that can happen to your app's responsiveness is an "Application Not Responding" (ANR) dialog.


성능 테스트 코드를 작성하는 것은 가능하지만, 느리거나, 특정 구간에서 멈추거나, 입력을 처리함에 매우 오랜 시간이 걸릴 수 있다. 앱의 반응에 있어서 발생할 수 있는 최악은 ANR 다이얼로그 이다.


In Android, the system guards against applications that are insufficiently responsive for a period of time by displaying a dialog that says your app has stopped responding, such as the dialog in Figure 1. At this point, your app has been unresponsive for a considerable period of time so the system offers the user an option to quit the app. It's critical to design responsiveness into your application so the system never displays an ANR dialog to the user.


안드로이드에서, 시스템은 일정 시간동안 응답이 불충분할 때, 앱의 응답이 멈추었다는 다이얼로그를 보여준다. 이 때, 앱은 일정 시간동안 응답이 없었고 시스템은 앱을 종료할 수 있도록 한다. 시스템이 ANR 다이얼로그를 보여주지 않도록 응답성을 설계하는 것은 매우 중요하다.


This document describes how the Android system determines whether an application is not responding and provides guidelines for ensuring that your application stays responsive.


이 문서는 안드로이드 시스템이 응답하지 않는 앱을 어떻게 결정하는지를 설명하고, 앱이 항상 응답하도록 보장하는 가이드라인을 제공한다.


What Triggers ANR


Generally, the system displays an ANR if an application cannot respond to user input. For example, if an application blocks on some I/O operation (frequently a network access) on the UI thread so the system can't process incoming user input events. Or perhaps the app spends too much time building an elaborate in-memory structure or computing the next move in a game on the UI thread. It's always important to make sure these computations are efficient, but even the most efficient code still takes time to run.


일반적으로, 앱이 사용자의 입력에 응답할 수 없을 대 시스템은 ANR을 출력한다. 예를 들어, 앱이 UI thread에서 어떤 IO 동작을 막아서 시스템이 사용자의 입력을 처리할 수 없는 경우이다. 또는 앱이 메모리 구조를 구축하는데 많은 시간을 사용하거나, UI thread에서 게임의 다음 동작을 계산할 때이다. 이런 연산들이 효과적으로 수행되도록 하는 것은 항상 중요하지만, 아무리 효율적인 코드라도 실행하는데 시간은 소요된다.


In any situation in which your app performs a potentially lengthy operation, you should not perform the work on the UI thread, but instead create a worker thread and do most of the work there. This keeps the UI thread (which drives the user interface event loop) running and prevents the system from concluding that your code has frozen. Because such threading usually is accomplished at the class level, you can think of responsiveness as a class problem. (Compare this with basic code performance, which is a method-level concern.)


앱이 잠재적으로 오랜시간이 걸릴 수 있는 작업을 수행할 때, 그 작업을 UI thread에서 수행해서는 안되고, 대신 worker thread를 생성하여 수행할 수 있도록 해야한다. 이것은 UI thread가 동작될 수 있게하고, 코드가 멈추는 것을 막는다. 이러한 쓰레딩은 클래스 레벨에서 행해지기 때문에, 응답성은 클래스의 문제로 생각할 수 있다.


In Android, application responsiveness is monitored by the Activity Manager and Window Manager system services. Android will display the ANR dialog for a particular application when it detects one of the following conditions:

  • No response to an input event (such as key press or screen touch events) within 5 seconds.
  • A BroadcastReceiver hasn't finished executing within 10 seconds


안드로이드에서, Activity Manager와 Window Manager가 앱의 응답성을 관찰한다. 안드로이드는 아래의 조건이 발견될 때 ANR 다이얼로그를 출력한다.

  • 입력 이벤트에 대해서 응답이 5초간 없음
  • BroadcastReceiver가 10초 내에 실행을 완료하지 않음


How to Avoid ANRs


Android applications normally run entirely on a single thread (by default the "UI thread" or "main thread"). This means anything your application is doing in the UI thread that takes a long time to complete can trigger the ANR dialog because your application is not giving itself a chance to handle the input event or intent broadcasts.


안드로이드 앱은 일반적으로 하나의 쓰레드에서 실행된다. UI thread에서 시간이 오래 걸리는 작업을 할 경우 앱이 입력을 처리하거나 intent broadcast(?) 할 수 없어서 ANR 다이얼로그를 발생시킬 수 있다.


Therefore, any method that runs in the UI thread should do as little work as possible on that thread. In particular, activities should do as little as possible to set up in key life-cycle methods such as onCreate() and onResume(). Potentially long running operations such as network or database operations, or computationally expensive calculations such as resizing bitmaps should be done in a worker thread (or in the case of databases operations, via an asynchronous request).


따라서, UI thread에서 수행되는 메소드는 가능한 작은 작업을 수행해야 한다. 구체적으로, 액티비티는 onCreate()나 onResume()같은 생명주기 메소드에서 작은 작업을 수행해야 한다. 네트워크나 데이터베이스처럼 잠재적으로 오래 걸릴 수 있는 작업, 비트맵 리사이징처럼 계산 비용이 큰 작업은 worker thread에서 수행되어야 한다.


The most effecive way to create a worker thread for longer operations is with the AsyncTask class. Simply extend AsyncTask and implement the doInBackground() method to perform the work. To post progress changes to the user, you can call publishProgress(), which invokes the onProgressUpdate() callback method. From your implementation of onProgressUpdate() (which runs on the UI thread), you can notify the user.


오래 걸리는 작업을 위해서 worker thread를 생성하는 가장 효율적인 방법은 AsyncTask 클래스를 이용하는 것이다. AsyncTask를 상속하고 doInBackground() 메소드를 구현하면 된다. 사용자에게 진행률을 알려주기 위해서는 onProgressUpdate() 콜백을 호출하는, publishProgress()를 호출한다. onProgressUpdate()의 구현에서 사용자에게 알려줄 수 있다. (예시는 생략)


Although it's more complicated than AsyncTask, you might want to instead create your own Thread or HandlerThread class. If you do, you should set the thread priority to "background" priority by calling Process.setThreadPriority() and passing THREAD_PRIORITY_BACKGROUND. If you don't set the thread to a lower priority this way, then the thread could still slow down your app because it operates at the same priority as the UI thread by default.


AsyncTask 보다 복잡할 수 있지만, Thread나 HandlerThread를 만들 수도 있다. 이 경우, Process.setThreadPriority()를 호출하고 THREAD_PRIORITY_BACKGROUND를 전달하여 "background" priority를 set해야 한다. 이런 방식으로 쓰레드에 낮은 priority를 적용하지 않을 경우, UI thread와 동일한 priority에서 수행되어 thread가 앱을 느리게 할 수 있다.


If you implement Thread or HandlerThread, be sure that your UI thread does not block while waiting for the worker thread to complete—do not call Thread.wait() or Thread.sleep(). Instead of blocking while waiting for a worker thread to complete, your main thread should provide a Handler for the other threads to post back to upon completion. Designing your application in this way will allow your app's UI thread to remain responsive to input and thus avoid ANR dialogs caused by the 5 second input event timeout.


Thread나 HandlerThread를 구현할 때, UI thread가 worker thread를 기다리면서 block되지 않도록 해야한다. Thread.wait()나 Thread.sleep()을 호출하지 않아야한다. worker thread를 기다리면서 block되도록 하는 대신, main thread가 Handler를 제공하여 작업 완료 시 사용할 수 있도록 해야한다. 이러한 앱 디자인은 UI thread가 사용자의 입력에 응답하고 ANR을 막을 수 있도록 한다.


The specific constraint on BroadcastReceiver execution time emphasizes what broadcast receivers are meant to do: small, discrete amounts of work in the background such as saving a setting or registering a Notification. So as with other methods called in the UI thread, applications should avoid potentially long-running operations or calculations in a broadcast receiver. But instead of doing intensive tasks via worker threads, your application should start an IntentService if a potentially long running action needs to be taken in response to an intent broadcast.


BroadcastReceiver 실행 시간에 대한 제약사항은 broadcast receiver가 해야할 것들을 강조한다 : 설정의 저장이나 Notification의 등록과 같은 background에서 작고, 분산된 양의 작업. UI thread에서 다른 메소드들이 불리는 것처럼,  앱은 잠재적으로 오랜시간이 걸릴 수 있는 연산이나 계산을 피해야한다. 하지만  intent broadcast의 응답에 잠재적으로 오래 걸리는 작업을 해야한다면, worker thread에서 집중적인 작업을 하는 대신, IntentService를 시작해야한다.


Tip: You can use StrictMode to help find potentially long running operations such as network or database operations that you might accidentally be doing your main thread


Reinforce Responsiveness


Generally, 100 to 200ms is the threshold beyond which users will perceive slowness in an application. As such, here are some additional tips beyond what you should do to avoid ANR and make your application seem responsive to users:

  • If your application is doing work in the background in response to user input, show that progress is being made (such as with a ProgressBar in your UI).
  • For games specifically, do calculations for moves in a worker thread.
  • If your application has a time-consuming initial setup phase, consider showing a splash screen or rendering the main view as quickly as possible, indicate that loading is in progress and fill the information asynchronously. In either case, you should indicate somehow that progress is being made, lest the user perceive that the application is frozen.
  • Use performance tools such as Systrace and Traceview to determine bottlenecks in your app's responsiveness.


일반적으로 100~200ms가 사용자가 느림을 인식하는 경계이다. ANR을 방지하고 사용자에게 응답성을 보여주기위한 추가적인 팁이다.

  • 사용자 입력에 반응하기 위해 background에서 작업하는 경우 progress를 보여주기
  • 게임인 경우, worker thread에서 연산
  • 초기 셋업에 시간이 소요되는 경우, 스플래시를 보여주거나 메인 뷰를 가능한 빨리 보여주고, 로딩이 진행중임을 보여주고 비동기로 정보를 보여주기. 어떤 경우든 프로그레스를 보여주어서 사용자가 block 상태를 알 수 없도록 해야한다.
  • 앱의 반응성에서 병목 구간을 결정하기 위해서 Systrace나 Traceview같은 성능 도구를 사용한다.

Posted by ssun++

댓글을 달아 주세요

최근에 달린 댓글

최근에 받은 트랙백

글 보관함