자막제작: Stanleykou (http://stanleykou.tistory.com/)
자막제작: Stanleykou (http://stanleykou.tistory.com/) While I'm normally opposed to using puns in videos, 일반적으로, 제가 동영상에서 말장난을 할 때는
this one's pretty good, you gotta admit. 이건 괜찮은 겁니다. 그냥 그러려니 하세요.
Anyhow, my name is Colt McAnlis. 어쨌거나, 제 이름은 콜트 맥카닐스입니다.
And after posing a question to the Android Performance Android Performance Patterns 구글 플러스 커뮤니티에 질문을 몇 개 던져보았는데요,
Patterns Google+ Community, we realized that it might be 저희는 안드로이드 스튜디오에 포함된 유용한 기능을
beneficial to cover a very useful tool inside of Android 소개해 드리면 모두에게 유용할 것이라는 결론을 얻게 되었습니다.
Studio.
See, one of the biggest problems with fixing performance 성능향상 작업에서 제일 큰 문제가 되는 것은,
in your applications is that it's mostly a reactive process. 당신의 앱이 "반응을 해야 하는" 프로세스라는 것입니다.
You build an app, ship it to users, 당신을 앱을 만들고, 이용자에게 배포하고,
and only after they've started complaining about it do you 그러면 이용자들이 당신에게 불평을 하고,
know where the problems are. 그러면 어디가 문젠지 확인하겠죠.
It seems like it would be tons easier 수십배는 더 쉬운 방법이 있는데,
to identify the problems ahead of time 악플이 달리기 전에 어디가 문제인지
rather than having to wait for bad reviews to come in. 알아내는 것입니다.
Now historically, the Android toolchain 역사적으로도, 안드로이드 툴체인에서는
provided a tool named LINT, a static code analysis tool which LINT라는 이름의 static 분석 툴을 함께 제공했는데요,
checks your Android project source 안드로이드 프로젝트의 소스파일을
files for any potential bugs alongside 분석하여, 잠재적인 버그를 찾아내고
potential optimizations for correctness, security, 최적화, 오류수정, 보안성,
performance, usability, accessibility, 성능향상, 이용성 향상, 장애인을 위한 편의 향상,
and internationalization. 그리고 다국어 앱 개발에 도움을 줍니다.
For example, if you're allocating objects inside 예를 들어, 당신이 오브젝트를
of the onDraw function which, as we all know, onDraw 함수 내에서 할당했다면, 다들 알듯이,
can lead to excessive amounts of memory churn, 엄청난 메모리 파편화를 만들어내게 됩니다.
LINT can detect that and spit out a nice warning for you, LINT는 이런 것을 찾아서 친절한 경고를 뱉아냅니다.
pinpointing the exact line that the problem occurs at. 정확하게 어느 라인이 문제를 일으키고 있는지 말이죠.
Simply boot up your favorite command 그냥 커맨드 프롬프트를 열고,
prompt, run some commands, and LINT will do the rest. 커맨드 몇 개를 실행시키면, LINT가 나머지를 다 알아서 해줍니다.
Well, the good news is that this handy tool, by default, 좋은소식은, 이 유용한 툴이
is now integrated into Android Studio 1.0, 안드로이드 스튜디오 1.0에 기본탑재 됐다는 거지요.
and it's useful in a couple of ways. 이건 다양한 방법으로 써먹을 수 있습니다.
Firstly, anytime you want to kick off a release build, 먼저, 언제든 릴리즈 빌드를 찍어내고 싶다면
LINT will run a subset of its checks LINT가 그 검사목록 중 일부를
against your compiling code. 컴파일하는 코드에 대해 수행할 수 있습니다.
Secondly, if you want feedback on a more regular basis, 두 번째로, 좀 더 일상적으로 피드백을 받고싶다면
you can configure Gradle to run the full suite of LINT tests 그래이들 설정을 바꿔서 LINT의 모든 테스트를
during any various random build you may kick off 낮 동안에 어떤 종류의 빌드 릴리즈하고,
during the day. 밤에 테스트를 하도록 설정할 수 있습니다.
And thirdly, if having LINT run during your builds 세 번째로, 빌드하는 중에 LINT를 돌리는게 마음에 안드시면,
isn't really your thing, you can kick off manual builds 매뉴얼 빌드를 하도록
at your discretion. 설정하실 수 있습니다.
And just for the sake of introductions, 소개를 해드려야 되니까,
let's take a look at that third step for now. 그 세번째 과정을 지금 한 번 해보겠습니다.
To run LINT on your code inside of Android Studio, 안드로이드 스튜디오 안에서 LINT를 돌리시려면
open up your project, and select Analyze, Inspect 프로젝트를 열고, Analyze - Inspect Code를
Code from the menu. 메뉴에서 선택하세요.
This will kick off LINT and present a handy suite 이렇게 하면 LINT가 실행되고, 유용한 몇 가지 결과가
of results that manifest itself in a window 화면 하단의 윈도우에
at the bottom of the IDE. 표시되게 됩니다.
This bottom window has two main components. 하단 윈도우는 두 가지 컴포넌트를 가지고 있는데요,
On the left is a hierarchical grouping of various errors, 왼쪽 것은 에러의 계층구조,
warnings, and potential issues. warning, 그리고 잠재적인 이슈입니다.
And when you select one of the issues in that left pane, 왼쪽 창에서 이슈를 하나 선택하면
the right pane will be filled in with details 우측 창에 상세한 내용이 나옵니다.
about what that problem means, the line number that causes it, 그 오류가 무슨 의미인지, 오류가 일어난 라인이 어디인지,
information on the test, and how to potentially fix the problem. 테스트를 위한 정보, 어떻게 하면 이 오류를 수정할수 있는지 등등.
If you've noticed by running this tool, 이걸 한 번 해보셨다면,
there's a flood of tests that LINT checks for. LINT가 체크할 수 있는 항목이 산더미 같다는 걸 아실겁니다.
So if you want to control the tsunami of information 이 정보의 쓰나미를 헤쳐나오려면,
that LINT can spit out, you can configure what analysis LINT가 뱉아내는 이 정보를 걸러서 보기 위해서는
you're interested in by opening File, Other Settings, Default File, Other Settings, Default Settings
Settings, and then selecting Inspections. 거기서 Inspection을 설정하시면 됩니다.
This will list all-- and I mean all-- of the inspecting options 이러면 모든, 다시 말하지만 LINT의 모든 옵션을 켤 수 있습니다.
for LINT.
To specifically tune LINT to find performance issues, LINT가 성능향상 관련 이슈만 표시하게 설정하시려면
you can search for the "performance" keywords. "performance"라는 키워드를 찾아 보세요.
From there, you can click through 거기서 클릭을 몇 번 하시다 보면,
and get a better sense of what checks are being run, 어떤 체크를 돌려야 좋은지 깨닫게 되고,
enable them, disable them, and reassign their priority 이걸 켜 봤다가 저걸 꺼봤다가 우선순위도 조정해 볼 수도 있죠.
for performance. 성능향상 위주로요.
But even with that search, there's 근데 검색하시다 보면
lots of data that's being listed. 목록에 정보가 너무 많을 겁니다.
So here are Colt's personal suggestions on which 그래서 저 콜트의 개인적인 추천이 있는데요,
ones to keep an eye on. 이 항목을 켜 주면 좋습니다.
Firstly, make sure you set memory allocations 먼저, draw 코드에 메모리할당이
within drawing code to throw an error. 들어가 있으면 에러가 출력되게 하세요.
As we've seen with the Memory Churn videos, 메모리 파편화 비디오에서 말씀 드렸듯이,
this can quickly cause a problem. 이건 굉장히 빠르게 문제를 발생시킬 수 있습니다.
And it's worth keeping an eye on in order to avoid issues here 이 옵션을 켜시면, 여기있는 이슈가 발생하는 걸
in the future. 미래에는 더이상 안 보실 수도 있습니다.
The Layout Has Too Many Views and Layout Hierarchy "The Layout Has Too Many Views"와 "Layout Hierarchy Is Too Deep"도
Is Too Deep are good to keep an eye on. 켜놓으면 좋습니다.
Although if your users are running on modern devices, 또한 당신 앱의 이용자들이 최신 기기를 이용한다면,
this may be fine to just leave as a warning. 그냥 경고를 남기는 식으로 처리해도 괜찮겠지만요.
And finally, I like to leave the Overdraw check set 마지막으로, 저는 Overdraw check를 설정하는 것을 권하는데,
to a warning, if anything, just to keep an eye on what's 뭔가 빌드 간에 변경사항이 있으면
changed between builds. 체크해도 됩니다.
But remember, at the end of the day, 기억하세요.
these are suggestions based upon what the tooling team has 저희가 제안한 이것들이 툴 팀에서는
seen as common problems. 자주 보이는 문제들이니까요.
Your code may get flagged for a particular issue, 당신 코드에 특정 이슈가 있다고 나와도
but if it's not actually eating into your frame rate, 그게 정말 프레임 레이트를 떨어뜨리는 것이 아니라면,
don't actually worry about it. 걱정할 필요 없습니다.
So keep that in mind before you run off into the weeds 불필요하게 상세하게 접근하지 말고, 기억만 해 두었다가
and start refactoring things. 나중에 리팩토링을 하세요.
Now if you run this tool and end up 이제 이 툴을 돌렸는데 만약
with a flood of performance issues, 산더미 같은 성능관련 이슈가 나오다면
then make sure you check out the rest of the Android Performance 다른 "Android Performance Patterns" 동영상을 보시고
Patterns content for tips and tricks 팁과 노하우를 배워가셔서
on how to address these issues. 이슈 해결에 도움이 되시길 바랍니다.
And of course, don't hesitate to join our Google+ Community 그리고 저희 구글 플러스 커뮤니티에도 가입 해주세요.
to get more information on tips and tricks from people that are 거기서 주로 출몰하는 고수들이 팁과 노하우를
in the trenches. 알려드릴 겁니다.
So keep calm, profile your code, and always remember 그러니 차분하게, 코드를 프로파일링하고, 항상 기억하세요.
perf matters. 성능이 항상 중요합니다.
Không có nhận xét nào:
Đăng nhận xét