Vietnamese 字幕

← 04-06 Spotting_Leaks_In_Memory_Monitor

04-06 Spotting_Leaks_In_Memory_Monitor

埋め込みコードを取得する
13言語

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

  1. Được rồi, giờ chúng ta
    hãy nói về các lỗ hổng bộ nhớ.
  2. lỗ hổng bộ nhớ rất thầm lặng.
  3. Chúng có thể từ từ và ngấm ngầm,
    đôi khi phải mất nhiều ngày
  4. hoặc nhiều tuần trước khi bạn
    phát hiện ra mình đã mắc phải nó.
  5. Trên thực tế, bạn có thể chỉ nhận ra một
    vấn đề về bộ nhớ khi người dùng bắt đầu
  6. phàn nàn về sự chậm chạp bí ẩn
    xảy ra sau khi chạy ứng dụng của bạn.
  7. Đừng để điều đó xảy ra với mình.
  8. Nhưng rất may, với một chút kiên nhẫn,
    một tư duy tốt và các công cụ phù hợp,
  9. bạn sẽ có cơ hội loại bỏ những lỗ hổng
    này khỏi ứng dụng của mình.
  10. Ta sẽ dùng Memory Monitor theo dõi
    hành vi của lỗ hổng đang hoạt động,
  11. sau đó trong video tiếp theo, ta sẽ dùng
    Heap Viewer để có được xác nhận ban đầu.
  12. Giờ hãy theo dõi một ví dụ nhỏ để xem
    một lỗ hổng trông thế nào
  13. và xem cách các công cụ SDK có thể giúp
    chúng ta xác định một lỗ hổng như vậy.
  14. Trong ví dụ này chúng ta sẽ
    đi tiếp và xoay thiết bị trong
  15. một vài phút, rồi cấu hình nó với
    Màn hình bộ nhớ.
  16. Chi tiết đó được thiết kế để giới thiệu
    một tình huống lỗ hổng phổ biến phát sinh
  17. trong quá trình tạo lập và phá hủy
    của một hành động.
  18. Chúng ta có thể cố ý kích hoạt chu kỳ này
    bằng cách đổi hướng của thiết bị.
  19. Vâng tôi biết, có vẻ làm như vậy
    là một điều rất kỳ quặc,
  20. nhưng chúng ta làm như vậy để
    chứng minh lỗ hổng có thể được tạo ra và
  21. chúng trở nên chậm chạp
    và âm ỉ như thế nào.
  22. Trong lần trước,
  23. lỗ hổng từ từ chiếm lĩnh
    bộ nhớ trống dành cho ứng dụng của bạn
  24. cho đến khi cuối cùng nó tạo ra
    một sự kiện garbage collection hay GC.
  25. Quan trọng hơn nữa, điều chủ yếu cần
    lưu ý đó là bộ garbage collector
  26. không thể dành lại rất nhiều năng lượng
    do lỗ hổng tại các ứng dụng.
  27. Và sau đó, cuối cùng là,
  28. một sự kiện GC thứ hai sẽ xảy ra sớm hơn
    rất nhiều, khoảng 30 giây sau đó.
  29. Giờ hãy chú ý khi lỗ hổng chiếm hết
    tất cả bộ nhớ trống,
  30. Android sẽ tiến hành điều chỉnh và cấp cho
    ứng dụng đó một trần bộ nhớ cao hơn.
  31. Trong khi đó là một điều chỉnh tốt của hệ
    thống, nếu lỗ hổng không được khắc phục,
  32. nó sẽ tiếp tục dành hết bộ nhớ đến khi
    hệ thống không thể phân bổ thêm được nữa.
  33. Điều này sẽ làm chậm hiệu suất
    của thiết bị và
  34. cuối cùng khiến ứng dụng của bạn sụp đổ.
  35. Bạn có thể đợi thêm một chút,
    GC thứ ba sẽ diễn ra.
  36. Và sau đó là lần thứ tư khá
    giống hai lần đầu tiên.
  37. Giờ bạn có thể thấy
    mô hình vẫn tiếp tục, và
  38. thêm nhiều bộ nhớ được hệ thống phân bổ.
  39. Bạn cũng có thể phát hiện hành vi này
    bằng Heap Viewer.