Korean subtitles

← 04-02 Memory,_GC,_and_Performance

04-02 Memory,_GC,_and_Performance

Get Embed Code
13 Languages

Showing Revision 5 created 05/20/2016 by nc_translator1.

  1. 이제 저희 코드가 빨라졌으니
  2. 메모리에 대해 조금 더 얘기해봐요
  3. 특히 메모리가 시스템 성능에 어떤 영향을 미치는지 말이에요
  4. 하드웨어에 친숙한 고성능 언어로 알려진
  5. C, C++, Fortran 같은 프로그래밍 언어는
  6. 프로그래머가 메모리를 직접 관리하도록 해요
  7. 메모리를 할당하는 건 프로그래머의 몫이죠
  8. 메모리 사용이 끝나면 반납하는 것도 마찬가지입니다
  9. 메모리를 언제, 얼마만큼 할당할지를 직접 결정하니
  10. 메모리 관리의 효율성은 여러분의 능력에 달려있어요
  11. 책임이 막중하죠
  12. 게다가 대부분의 프로그래머들은
  13. 그 많은 메모리 조각들을 잘 관리하지도 못해요
  14. 생각해보세요
    제품 개발은 지저분하고 정신없는 작업이에요
  15. 그래서 메모리 반납은 제대로 이루어지지 않죠
  16. 이런 반납되지 않은 메모리 조각을 메모리 누수라고 해요
  17. 가만히 앉아서 리소스만 잡아먹게 됩니다
  18. 더 좋은 용도로 쓰일 수 있는 리소스를 말이죠
  19. 메모리 누수로 인한 문제, 스트레스, 그리고 금전적 손해를 줄이기 위해
  20. 메모리 관리 언어가 생겼어요
  21. 메모리 관리 언어의 런타임은 할당된 메모리를 추적하고
  22. 애플리케이션이 더 이상 필요하지 않은 메모리는
    다시 시스템으로 반납합니다
  23. 프로그래머가 건드리지 않아도 말이죠
  24. 메모리 관리 환경에서 메모리를 회수하는 예술, 아니 기술은
  25. Garbage collection(GC)이라고 불러요
  26. GC의 개념은 1959년에 존 맥카시가
  27. LISP 프로그래밍 언어의 문제를 해결하기 위해 만들었어요
  28. GC의 기본적 원칙은 다음과 같아요
  29. 첫째, 프로그램에서 더 이상 접근할 수 없는 데이터 객체 찾기
  30. 코드에서 더 이상 참조하지 않는 메모리 주소 같은 것 말이죠
  31. 둘째, 이런 객체가 사용하던 리소스 회수하기
  32. 이론적으론 간단하지만 순식간에 많이 복잡해집니다
  33. 2백만 줄의 코드와 4GB만큼의 메모리 주소 할당이 있다면 말이죠
  34. 생각해보세요 GC는 정말 복잡할 수 있어요
  35. 지금 당장 여러분의 프로그램에서 2만 개의 메모리 할당이 있다면
  36. 필요하지 않은 메모리들은 어떤 건가요?
  37. 아니면 필요하지 않은 메모리를 수거하기 위한
    GC 이벤트는 언제 실행해야 하나요?
  38. 이것들은 실제로 매우 어려운 문제들입니다
  39. 다행히도 GC 기술이 50년에 걸쳐 개선되고 보완된 덕분에
  40. 안드로이드 런타임의 GC는
    McCarthy의 기존 아이디어보다 더 세련된 기능을 수행합니다
  41. 최대한 거슬리지 않고 빠르게 수행되도록 제작되었어요
  42. 안드로이드 런타임의 메모리 힙은
  43. 스페이스라는 단위로 나누어져 있습니다
  44. 메모리 할당의 종류와
  45. 시스템이 메모리를 정리할 수 있는 가장 효율적인 방법으로 나눕니다
  46. 추후에 발생할 GC 이벤트에 대해서 말이죠
  47. 새로운 객체가 메모리에 할당되면
  48. 객체의 특징을 고려해 가장 적절한 스페이스로 배정해요
  49. 배정 방법은 안드로이드 런타임 버전에 따라 달라요
  50. 자 이제 중요한 부분을 말씀드릴게요
  51. 각 스페이스는 크기가 정해져있어요
  52. 객체가 추가적으로 메모리를 할당받으면
  53. 스페이스의 총 크기를 기록해요
  54. 스페이스가 커지면 시스템은 추후의 메모리 할당을 위해 GC를 실행해요
  55. 하지만 GC 이벤트 진행 방식은 바뀌어요
  56. 안드로이드 런타임 버전에 따라 말이죠
  57. 예를 들어 Dalvik에서의 GC 이벤트는
    stop-the-world(앱 정지) 이벤트에요
  58. 즉 GC 이벤트가 완료되기 전까지 다른 작업도 멈추는 거죠
  59. 하지만 이 방법은 문제가 발생할 수 있어요
  60. GC의 실행 시간이 길어지거나
    여러 GC 이벤트가 연이어 발생하면 말이죠
  61. 기기의 프레임 타임을 많이 사용하게 되니까요
  62. 안드로이드 개발자들은 GC 이벤트를 최대한 빠르도록
    설계하는데 심혈을 기울였어요
  63. 성능에 대한 영향을 최소화하기 위해 말이죠
  64. 이런 노력에도 불구하고 애플리케이션 성능에
    문제를 일으킬 수 있습니다
  65. 우선 애플리케이션이 한 프레임에서 GC를 수행하는 시간이 길수록
  66. 다른 로직 계산들이 사용할 수 있는 시간이 줄어들어요
  67. 16ms의 총 렌더링 시간 중 말이죠
  68. 그렇기 때문에 하나의 긴 GC나 여러개의 연속적인 GC가 있다면
  69. 프레임 처리 속도가 16ms를 넘어갈 수 있어요
  70. 그러면 사용자는 렉이나 튀는 현상을 경험하죠
  71. 두 번째로 여러분의 코드 흐름이
  72. 보다 자주 GC를 일으킬 수 있고
  73. 혹은 너무 긴 GC를 일으킬 수도 있다는 점을 기억하세요
  74. 예를 들어 루프의 깊숙한 곳에서 객체를 대량으로 할당하면
  75. 객체들이 메모리 힙을 오염시키고
  76. 짧은 시간 내에 많은 GC들을 쳐내야 할 거예요
  77. 이 과도한 메모리 압박으로 말이죠
  78. 그리고 메모리 관리가 잘 된 환경에 있다 하더라도
  79. 메모리 누수는 일어날 수 있어요
  80. 물론 다른 언어보단 발생하기 어렵지만요
  81. 이런 메모리 누수는 힙에서 자리를 차지하고
  82. GC 이벤트에서도 반납되지 않아
  83. 다른 자료가 사용할 수 있는 메모리가 줄어
  84. GC가 더 자주 발생하게 됩니다
  85. 이게 현실이에요
  86. 한 프레임에서 발생하는 GC 이벤트의 개수를 줄이시려면
  87. 여러분 애플리케이션의 메모리 사용을 최적화해야 해요
  88. 코드를 보면 메모리 문제가 어디서 발생하는지 찾기 어렵지만
  89. 안드로이드 SDK는 이 문제를 해결하기 위한
    강력한 툴 몇 가지를 제공하죠
  90. 한번 볼까요