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

1. Title:
   04-04 Memory_Leaks
2. Description:

   04-04 Memory_Leaks

3. 280 0:00 - 0:03
   Một trong những điều tốt về ngôn ngữ
   Java của Android là
4. 3290 0:03 - 0:06
   môi trường bộ nhớ được quản lý của nó,
5. 5840 0:06 - 0:08
   nghĩa là bạn không cần
   quá quan tâm về việc phải xử lý
6. 8470 0:08 - 0:11
   khi các đối tượng hình thành hay phá hủy.
7. 11060 0:11 - 0:13
   Mặc dù điều này nhìn chung rất tuyệt,
8. 12620 0:13 - 0:17
   nhưng vẫn có một số vấn đề được
   che giấu ẩn dưới bề mặt này.
9. 17330 0:17 - 0:20
   Bây giờ hãy nhớ các vùng bộ nhớ
   trong thời gian chạy Android
10. 20330 0:20 - 0:24
    được chia thành các khoảng,
    dựa vào loại phân bổ và
11. 23610 0:24 - 0: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.
12. 27980 0:28 - 0:31
    Mỗi không gian có kích thước
    bộ nhớ dành riêng cho nó.
13. 30580 0:31 - 0:35
    Khi kích thước kết hợp của đối tượng
    trong vùng bắt đầu đạt cận trên,
14. 34780 0:35 - 0:38
    một sự kiện garbage collection sẽ
    được kích hoạt để giải phóng không gian
15. 37730 0:38 - 0:40
    và loại các đối tượng không cần thiết.
16. 39612 0:40 - 0:44
    Các sự kiện GC này nói chung không phải
    vấn đề đáng lưu ý với hiệu suất của bạn.
17. 43935 0:44 - 0:46
    Tuy nhiên, rất nhiều trong số đó
    định kỳ và lặp đi lặp lại mãi
18. 46369 0:46 - 0:49
    có thể nhanh chóng chiếm lĩnh
    thời gian khung của bạn.
19. 48915 0:49 - 0:51
    Bạn càng mất nhiều
    thời gian với các GC
20. 50725 0:51 - 0:54
    thì càng có ít thời gian làm những việc
    như cung cấp và truyền tải audio.
21. 54390 0:54 - 0:57
    Một tình trạng các nhà phát triển
    triển hay gặp phải
22. 57632 0:58 - 1:01
    gây ra rất nhiều GC diễn ra được gọi là
    lỗ hổng bộ nhớ.
23. 60792 1:01 - 1:04
    Lỗ hổng bộ nhớ là các đối tượng mà
    ứng dụng không còn sử dụng tới, nhưng
24. 64090 1:04 - 1:07
    bộ Garbage Collector không nhận ra
    rằng chúng không được sử dụng.
25. 67402 1:07 - 1:10
    Kết quả là chúng cư trú lại
    trong vùng của bạn,
26. 69502 1:10 - 1:13
    chiếm đi không gian giá trị và không bao
    giờ giải phóng cho các đối tượng khác.
27. 73282 1:13 - 1:15
    Khi tiếp tục bị rò rỉ bộ nhớ,
28. 74542 1:15 - 1:17
    không gian có sẵn trong nguồn của
    vùng tiếp tục
29. 76910 1:17 - 1:22
    trở nên càng ngày càng nhỏ hơn, nghĩa là
    nhiều GC được thi hành thường xuyên hơn
30. 82230 1:22 - 1:25
    để cố gắng giải phóng không gian để
    thực thi các chương trình thường.
31. 85490 1:25 - 1:29
    Phát hiện và sửa chữa
    các lỗ hổng là một công việc khó khăn.
32. 88530 1:29 - 1:30
    Có những lỗ hổng rất dễ sinh ra,
33. 90040 1:30 - 1:34
    giống như tạo tham chiếu vòng tròn tới
    đối tượng mà chương trình không sử dụng.
34. 93790 1:34 - 1:35
    Các loại khác thì
    không đơn giản như vậy,
35. 95410 1:35 - 1:40
    giống như giữ tay cầm tới những đối tượng
    class-loader khi chúng đang được tải.
36. 99680 1:40 - 1:42
    Trong cả hai trường hợp, một ứng dụng
    nhanh chóng,
37. 102290 1:42 - 1:46
    chạy ổn định cần có nhận thức và nhạy cảm
    về các lỗ hổng bộ nhớ có thể tồn tại.
38. 105640 1:46 - 1:47
    Ý tôi là, mã của bạn sẽ chạy trên
39. 107030 1:47 - 1:49
    một liên kết thiết bị
    và loại hình khác nhau,
40. 108990 1:49 - 1:52
    và không phải tất cả trong đó sẽ có
    dấu vết và kích thước bộ nhớ tương tự.
41. 112150 1:52 - 1:55
    Thật may mắn, có một công cụ đơn giản
    có sẵn sẽ giúp chúng ta tìm ra nơi mà
42. 115420 1:55 - 1:58
    những lỗ hổng này có thể
    tồn tại trong Android SDK.
43. 118210 1:58 - 1:59
    Hãy cũng tìm hiểu nhé.