Return to Video

04-02 Memory,_GC,_and_Performance

  • 0:00 - 0:03
    Vì tất cả mã code của chúng tôi đều
    chạy rất nhanh và tuyệt vời,
  • 0:03 - 0:08
    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.
  • 0:08 - 0:12
    Nhiều ngôn ngữ lập trình
    được biết đến là gần với phần cứng,
  • 0:12 - 0:15
    hay đúng hơn là hiệu suất cao,
    như C, C ++, và Fortran,
  • 0:15 - 0:18
    thông thường bản thân các
    lập trình viên tự quản lý các bộ nhớ.
  • 0:18 - 0:22
    Thực ra lập trình viên chịu trách nhiệm
    phân bổ khối bộ nhớ
  • 0:22 - 0:23
    và đôi khi giải phóng nó
  • 0:23 - 0:26
    trong tương lai khi
    họ đã thực sự sử dụng xong.
  • 0:26 - 0:30
    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ộ
  • 0:30 - 0:35
    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.
  • 0:35 - 0:36
    Đó đúng là một trách nhiệm lớn.
  • 0:37 - 0:39
    Trên thực tế các lập trình viên
    không luôn làm tốt
  • 0:39 - 0:42
    việc theo dõi
    từng mảnhbộ nhớ như vậy.
  • 0:42 - 0:44
    Tôi muốn nói, hãy nghĩ rằng
    phát triển sản phẩm
  • 0:44 - 0:49
    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.
  • 0:49 - 0:53
    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ớ,
  • 0:53 - 0:55
    chúng nằm quanh
    các tài nguyên bị tiêu hao
  • 0:55 - 0:57
    nơi bạn có thể
    tận dụng tốt hơn hoặc ở đâu đó.
  • 0:58 - 1:01
    Để 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
  • 1:01 - 1:05
    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.
  • 1:05 - 1:08
    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ớ
  • 1:08 - 1:11
    và giải phóng bộ nhớ trở lại hệ thống
    khi nó không còn cần thiết
  • 1:11 - 1:15
    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.
  • 1:16 - 1:20
    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ó
  • 1:20 - 1:22
    quản lý được gọi là garbage collection,
  • 1:24 - 1:26
    khái niệm được John McCarthy
    nghĩ ra vào năm 1959
  • 1:27 - 1:30
    nhằm giải quyết các vấn đề
    trong ngôn ngữ lập trình lisp.
  • 1:30 - 1:33
    Có các nguyên tắc cơ bản của
    garbage collection như sau, đầu tiên là
  • 1:33 - 1:37
    Tìm đối tượng dữ liệu chương trình
    không thể truy cập trong tương lai,
  • 1:37 - 1:40
    ví dụ bất kỳ bộ nhớ nào
    không còn được tham chiếu bởi bản mã.
  • 1:40 - 1:44
    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.
  • 1:44 - 1:47
    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
  • 1:47 - 1:51
    hai triệu dòng mã code và
    bốn gigs worth phải phân bổ.
  • 1:51 - 1:53
    Giờ hãy nghĩ về nó, garbage collection
    có thể rất nổi trội,
  • 1:53 - 1:57
    ý 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.
  • 1:57 - 1:59
    Cái nào không còn cần thiết nữa?
    Hoặc thậm chí,
  • 1:59 - 2:01
    khi nào bạn cần
    tiến hành một lệnh garbage collection
  • 2:01 - 2:03
    để giải phóng bộ nhớ
    không còn được sử dụng?
  • 2:04 - 2:06
    Đây thực sự là những
    câu hỏi rất khó,
  • 2:06 - 2:10
    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,
  • 2:10 - 2:12
    đó là lý do garbage collector
    trong Runtime của Android
  • 2:12 - 2:15
    thực sự đã phức tạp hơn một chút
    so với đề xuất ban đầu của McCarthy.
  • 2:15 - 2:18
    Nó được xây dựng để nhanh chóng và
    không thể xâm nhập hết mức có thể.
  • 2:19 - 2:23
    Các khối bộ nhớ trong thời gian chạy của
    androids được chia khoảng hiệu quả
  • 2:23 - 2:24
    dựa vào loại phân bổ
  • 2:24 - 2:28
    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.
  • 2:28 - 2:30
    Là một đối tượng mới được phân bổ,
  • 2:30 - 2:33
    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ó
  • 2:33 - 2:36
    tùy theo loại phiên bản thời gian chạy
    của android mà bạn đang sử dụng.
  • 2:37 - 2:38
    Và đây là nội dung quan trọng.
  • 2:39 - 2:40
    Dù mỗi khoảng có một kích thước cài đặt,
  • 2:41 - 2:44
    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
  • 2:44 - 2:48
    và khi một không gian bắt đầu phát triển,
    hệ thống phải thi hành garbage collection
  • 2:48 - 2:51
    nhằm nỗ lực giải phóng
    bộ nhớ cho các phân bổ tương lai.
  • 2:52 - 2:54
    Giờ thì có thể đưa ra rằng các
    sự kiện GC sẽ xử lý khác nhau
  • 2:54 - 2:56
    tùy vào loại thời gian chạy
    Android bạn đang sử dụng.
  • 2:57 - 3:01
    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,
  • 3:01 - 3:05
    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.
  • 3:05 - 3:09
    Đ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
  • 3:09 - 3:11
    hoặc cả tấn của chúng đang chạy cùng lúc,
  • 3:11 - 3:13
    vì nó sẽ ăn vào khung thời gian
    của bạn một cách đáng kể.
  • 3:13 - 3:14
    Và cần biết rằng,
  • 3:14 - 3:18
    các kỹ sư Android đã dành rất nhiều
    thời gian đảm bảo các sự kiện này
  • 3:18 - 3:21
    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à
  • 3:21 - 3:25
    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.
  • 3:25 - 3:29
    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
  • 3:29 - 3:32
    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
  • 3:32 - 3:35
    cần có để giữ bạn trong
    hàng rào 16 mili giây.
  • 3:35 - 3:38
    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,
  • 3:38 - 3:42
    nó có thể khiến thời gian xử lý khung
    của bạn vượt qua 16 mili giây.
  • 3:42 - 3:46
    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.
  • 3:47 - 3:50
    Thứ hai, cần hiểu dòng mã của bạn
    có thể đang hoạt động khiến các GC
  • 3:50 - 3:55
    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.
  • 3:55 - 3:59
    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
  • 3:59 - 4:00
    một vòng mã chạy trong thời gian dài,
  • 4:00 - 4:03
    sau đó bạn gây ô nhiễm vùng
    bộ nhớ với rất nhiều đối tượng
  • 4:03 - 4:06
    và bạn sẽ kết thúc
    bằng việc khởi động rất nhiều GC
  • 4:06 - 4:09
    một cách nhanh chóng, do áp lực
    bộ nhớ bổ sung này.
  • 4:09 - 4:12
    Và mặc dù chúng ta đang ở trong
    một môi trường bộ nhớ có quản lý,
  • 4:12 - 4:14
    các lỗ hổng bộ nhớ vẫn có thể xảy ra.
  • 4:14 - 4:16
    Mặc dù chúng không dễ dàng được
    tạo như những ngôn ngữ khác.
  • 4:17 - 4:20
    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
  • 4:20 - 4:23
    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
  • 4:24 - 4:27
    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ó.
  • 4:28 - 4:29
    Vì vậy, đó là thỏa thuận,
  • 4:29 - 4:33
    ý 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,
  • 4:33 - 4:36
    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.
  • 4:36 - 4:39
    Từ góc độ bản mã, có thể sẽ rất khó
    để theo dõi nơi mà các vấn đề
  • 4:39 - 4:40
    tương tự phát sinh,
  • 4:40 - 4:45
    nhưng thật may mắn, Android SDK
    bộ công cụ mạnh mẽ theo ý bạn.
  • 4:45 - 4:46
    Hãy cùng xem nhé.
Title:
04-02 Memory,_GC,_and_Performance
Description:

04-02 Memory,_GC,_and_Performance

more » « less
Video Language:
English
Team:
Udacity
Project:
ud825 - Android Performance
Duration:
04:47

Vietnamese subtitles

Revisions Compare revisions