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, hãy
  • 0:03 - 0:08
    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:14
    hay đúng hơn là hiệu suất cao,
    như C, C ++,
  • 0:14 - 0:18
    và Fortran, 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:20
    Thực ra các lập trình viên
    chịu trách nhiệm cho việc
  • 0:20 - 0:25
    phân bổ một khối bộ nhớ và nhiều khi
    là giải phóng nó trong tương lai
  • 0:25 - 0:26
    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:36 - 0:39
    Và các lập trình viên thực tế không
    luôn làm tốt việc theo dõi
  • 0:40 - 0:42
    từng mảnh bộ nhớ như vậy.
  • 0:42 - 0:45
    Tôi muốn nói, hãy nghĩ rằng phát triển
    sản phẩm là quá trình
  • 0:45 - 0:49
    hỗn độn và rối loạn mà bộ nhớ kết thúc
    nhưng thường 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ớ, chúng nằm
  • 0:53 - 0:58
    quanh các tài nguyên bị tiêu hao 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:09
    Những thời gian chạy của các ngôn ngữ này
    sẽ theo dõi việc phân bổ bộ nhớ và
  • 1:09 - 1:12
    giải phóng bộ nhớ trở lại hệ thống
    khi nó không còn cần thiết với
  • 1:12 - 1:16
    chính ứng dụng đó, tất cả không cần tới
    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 của chương trình
    không thể truy cập trong tương lai,
  • 1:37 - 1:40
    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
    2 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, ý tôi là,
  • 1:53 - 1:57
    nếu bạn đã có khoảng 20.000 phân bổ
    trong chương trình của mình lúc này.
  • 1:57 - 1:58
    Cái nào không còn cần thiết nữa?
  • 1:58 - 2:01
    Hoặc thậm chí là khi nào bạn cần
    tiến hành một lệnh garbage collection để
  • 2:01 - 2:04
    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ó, và
  • 2:06 - 2:10
    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 Android's Runtime
  • 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:19
    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ổ và
  • 2:24 - 2:28
    cách tốt nhất mà 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:37
    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:39
    Và đây là một nội dung quan trọng.
  • 2:39 - 2:41
    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 và
  • 2:44 - 2:47
    khi một không gian bắt đầu phát triển,
    hệ thống sẽ phải thi hành lệnh
  • 2:47 - 2:52
    garbage collection 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:57
    tùy thuộc vào loại thời gian chạy
    Android mà 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:14
    vì nó sẽ ăn vào khung thời gian
    của bạn một cách đáng kể.
  • 3:14 - 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ã code 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 trong
  • 3:29 - 3:33
    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:33 - 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:47
    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 của bạn.
  • 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:02
    một vòng mã chạy trong một thời gian dài,
    sau đó bạn gây ô nhiễm vùng
  • 4:02 - 4:06
    bộ nhớ với rất nhiều đối tượng và bạn
    kết thúc 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:17
    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:24
    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:27 - 4:29
    Vì vậy, đó là một thỏa thuận, ý tôi là
  • 4:29 - 4:33
    nếu bạn muốn giảm số lượng các 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 độ mã code, có thể sẽ rất khó
    để theo dõi nơi mà các vấn đề
  • 4:39 - 4:41
    tương tự phát sinh, nhưng
  • 4:41 - 4:45
    thật may mắn, Android SDK đã có một 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