Vietnamese subtitles

← 04-02 Memory,_GC,_and_Performance

04-02 Memory,_GC,_and_Performance

Get Embed Code
13 Languages

Showing Revision 7 created 02/26/2016 by sp4.

  1. Vì tất cả mã code của chúng tôi đều
    chạy rất nhanh và tuyệt vời,
  2. hãy nói thêm một chút về bộ nhớ và cách nó
    ảnh hưởng đến hiệu suất trong hệ thống.
  3. Nhiều ngôn ngữ lập trình
    được biết đến là gần với phần cứng,
  4. hay đúng hơn là hiệu suất cao,
    như C, C ++, và Fortran,
  5. thông thường bản thân các
    lập trình viên tự quản lý các bộ nhớ.
  6. Thực ra lập trình viên chịu trách nhiệm
    phân bổ khối bộ nhớ
  7. và đôi khi giải phóng nó
  8. trong tương lai khi
    họ đã thực sự sử dụng xong.
  9. Vì bạn xác định khi nào và bao nhiêu
    bộ nhớ được phân bổ trống nên toàn bộ
  10. chất lượng quản lý bộ nhớ phụ thuộc
    vào kỹ năng và hiệu quả của bạn.
  11. Đó đúng là một trách nhiệm lớn.
  12. Trên thực tế các lập trình viên
    không luôn làm tốt
  13. việc theo dõi
    từng mảnhbộ nhớ như vậy.
  14. Tôi muốn nói, hãy nghĩ rằng
    phát triển sản phẩm
  15. là quá trình hỗn độn và rối loạn và thường
    bộ nhớ không giải phóng đúng cách.
  16. Những khối bộ nhớ chưa được giải phóng
    này gọi là các lỗ hổng bộ nhớ,
  17. chúng nằm quanh
    các tài nguyên bị tiêu hao
  18. nơi bạn có thể
    tận dụng tốt hơn hoặc ở đâu đó.
  19. Để giảm sự hỗn loạn, căng thẳng
    và đôi khi là tổn thất lớn về tiền bạc
  20. gây ra bởi lỗ hổng bộ nhớ, các ngôn ngữ
    bộ nhớ có quản lý đã được tạo ra.
  21. Những thời gian chạy của các ngôn ngữ này
    theo dõi việc phân bổ bộ nhớ
  22. và giải phóng bộ nhớ trở lại hệ thống
    khi nó không còn cần thiết
  23. với chính ứng dụng đó, tất cả không cần
    bất kỳ can thiệp nào của lập trình viên.
  24. Nghệ thuật, hay đúng hơn là khoa học dành
    lại bộ nhớ trong một môi trường bộ nhớ có
  25. quản lý được gọi là garbage collection,
  26. khái niệm được John McCarthy
    nghĩ ra vào năm 1959
  27. nhằm giải quyết các vấn đề
    trong ngôn ngữ lập trình lisp.
  28. Có các nguyên tắc cơ bản của
    garbage collection như sau, đầu tiên là
  29. Tìm đối tượng dữ liệu chương trình
    không thể truy cập trong tương lai,
  30. ví dụ bất kỳ bộ nhớ nào
    không còn được tham chiếu bởi bản mã.
  31. Và thứ hai là dành lại các tài nguyên
    được sử dụng bởi những đối tượng này.
  32. Khái niệm đơn giản về lý thuyết nhưng
    sẽ khá phức tạp khi bạn có tới
  33. hai triệu dòng mã code và
    bốn gigs worth phải phân bổ.
  34. Giờ hãy nghĩ về nó, garbage collection
    có thể rất nổi trội,
  35. ý tôi là nếu bạn đã có 20.000 phân bổ
    trong chương trình của mình lúc này.
  36. Cái nào không còn cần thiết nữa?
    Hoặc thậm chí,
  37. khi nào bạn cần
    tiến hành một lệnh garbage collection
  38. để giải phóng bộ nhớ
    không còn được sử dụng?
  39. Đây thực sự là những
    câu hỏi rất khó,
  40. và rất may mắn chúng tôi đã có khoảng
    50 năm đổi mới để cải thiện chúng,
  41. đó là lý do garbage collector
    trong Runtime của Android
  42. thực sự đã phức tạp hơn một chút
    so với đề xuất ban đầu của McCarthy.
  43. Nó được xây dựng để nhanh chóng và
    không thể xâm nhập hết mức có thể.
  44. Các khối bộ nhớ trong thời gian chạy của
    androids được chia khoảng hiệu quả
  45. dựa vào loại phân bổ
  46. và cách tốt nhất hệ thống có thể tổ chức
    phân bổ các sự kiện GC trong tương lai.
  47. Là một đối tượng mới được phân bổ,
  48. những đặc điểm đó được đưa vào sao cho
    phù hợp nhất với không gian dành cho nó
  49. tùy theo loại phiên bản thời gian chạy
    của android mà bạn đang sử dụng.
  50. Và đây là nội dung quan trọng.
  51. Dù mỗi khoảng có một kích thước cài đặt,
  52. khi đối tượng được phân bổ, chúng tôi vẫn
    theo dõi các kích thước tổng hợp
  53. và khi một không gian bắt đầu phát triển,
    hệ thống phải thi hành garbage collection
  54. nhằm nỗ lực giải phóng
    bộ nhớ cho các phân bổ tương lai.
  55. Giờ thì có thể đưa ra rằng các
    sự kiện GC sẽ xử lý khác nhau
  56. tùy vào loại thời gian chạy
    Android bạn đang sử dụng.
  57. Ví dụ trong Dalvik, nhiều sự kiện GC
    sẽ chặn các sự kiện của toàn hệ thống,
  58. nghĩa là bất kỳ mã quản lý nào đang chạy
    đều sẽ dừng lại đến khi nó thi hành xong.
  59. Điều này sẽ trở thành vấn đề nếu các GC
    này mất nhiều thời gian hơn bình thường
  60. hoặc cả tấn của chúng đang chạy cùng lúc,
  61. vì nó sẽ ăn vào khung thời gian
    của bạn một cách đáng kể.
  62. Và cần biết rằng,
  63. các kỹ sư Android đã dành rất nhiều
    thời gian đảm bảo các sự kiện này
  64. chạy nhanh hết mức có thể nhằm giảm
    thiểu gián đoạn, điều này được cho là
  65. vẫn có thể gây ra một số vấn đề về
    hiệu suất ứng dụng trong mã của bạn.
  66. Thứ nhất, phải hiểu rằng ứng dụng của bạn
    càng mất nhiều thời gian với các GC
  67. trong một khung nhất định thì nó càng mất ít
    thời gian cho phần logic còn lại
  68. cần có để giữ bạn trong
    hàng rào 16 mili giây.
  69. Vì vậy, nếu bạn có rất nhiều GC
    hoặc một vài cái rất dài diễn ra kế tiếp,
  70. nó có thể khiến thời gian xử lý khung
    của bạn vượt qua 16 mili giây.
  71. việc dựng hàng rào sẽ gây ra những
    ràng buộc hoặc bất lợi cho người dùng.
  72. Thứ hai, cần hiểu dòng mã của bạn
    có thể đang hoạt động khiến các GC
  73. xảy ra thường xuyên hơn, hoặc khiến chúng
    kéo dài lâu hơn thời gian thông thường.
  74. Chẳng hạn nếu bạn đang phân bổ một
    kho đối tượng tại phần trong cùng của
  75. một vòng mã chạy trong thời gian dài,
  76. sau đó bạn gây ô nhiễm vùng
    bộ nhớ với rất nhiều đối tượng
  77. và bạn sẽ kết thúc
    bằng việc khởi động rất nhiều GC
  78. một cách nhanh chóng, do áp lực
    bộ nhớ bổ sung này.
  79. Và mặc dù chúng ta đang ở trong
    một môi trường bộ nhớ có quản lý,
  80. các lỗ hổng bộ nhớ vẫn có thể xảy ra.
  81. Mặc dù chúng không dễ dàng được
    tạo như những ngôn ngữ khác.
  82. Những lỗ hổng này làm ô nhiễm trung tâm
    của bạn với các đối tượng không được
  83. giải phóng trong một sự kiện, làm giảm
    đáng kể không gian mà bạn được sử dụng
  84. khiến nhiều sự kiện GC khác khởi động
    theo cách thông thường do kết quả của nó.
  85. Vì vậy, đó là thỏa thuận,
  86. ý tôi là nếu muốn giảm số lượng sự kiện GC
    xảy ra trong một khung nhất định,
  87. bạn cần tập trung vào tối ưu hóa việc
    sử dụng bộ nhớ cho các ứng dụng của mình.
  88. Từ góc độ bản mã, có thể sẽ rất khó
    để theo dõi nơi mà các vấn đề
  89. tương tự phát sinh,
  90. nhưng thật may mắn, Android SDK
    bộ công cụ mạnh mẽ theo ý bạn.
  91. Hãy cùng xem nhé.