Ưu điểm của việc thiết lập bigHeap thành true?

Question

Tôi có một Ứng dụng với gần 50 lớp học tôi đang thiết lập android:largeHeap="true", như có thể xem bên dưới. Đây có phải là một thực hành tốt?

<application 
     android:name=".MyApplication" 
     android:allowBackup="true" 
     android:icon="@drawable/ic_launcher" 
     android:label="Mall" 
     android:largeHeap="true" 
     android:logo="@drawable/logo_for_up" 
     android:screenOrientation="portrait" 
     android:theme="@style/AppTheme" > 
</application> 

Vui lòng đề xuất ưu và nhược điểm khi sử dụng.

Tôi gặp vấn đề về bộ nhớ đó là lý do tôi hỏi câu hỏi này.

Answer 1

Liệu các quy trình của ứng dụng của bạn có nên được tạo bằng một vùng Dalvik lớn hay không. Điều này áp dụng cho tất cả các quy trình được tạo cho ứng dụng. Nó chỉ áp dụng cho ứng dụng đầu tiên được nạp vào một quá trình; nếu bạn đang sử dụng ID người dùng được chia sẻ để cho phép nhiều ứng dụng sử dụng quy trình, tất cả họ phải sử dụng tùy chọn này một cách nhất quán hoặc họ sẽ có kết quả không thể đoán trước.

Hầu hết các ứng dụng không cần điều này và thay vào đó nên tập trung vào việc giảm mức sử dụng bộ nhớ tổng thể để cải thiện hiệu suất. Việc kích hoạt tính năng này cũng không đảm bảo sự gia tăng cố định trong bộ nhớ có sẵn, bởi vì một số thiết bị bị hạn chế bởi tổng bộ nhớ có sẵn của chúng.

Answer 2

Trên thực tế android:largeHeap là công cụ để tăng bộ nhớ được phân bổ cho ứng dụng của bạn.

Không có định nghĩa rõ ràng về nhu cầu sử dụng cờ này. Nếu bạn cần thêm bộ nhớ - Android cung cấp cho bạn một công cụ để tăng bộ nhớ. Nhưng cần thiết phải sử dụng, bạn tự xác định.

Answer 3

Tôi có một ứng dụng với gần 50 lớp

Tôi không nghĩ rằng điều này làm cho nhiều vấn đề. Lý do tại sao bạn có lỗi OutOfMemory thường tải lên nhiều hình ảnh trong ứng dụng hoặc một cái gì đó tương tự. Nếu bạn không hài lòng khi sử dụng đống lớn, bạn phải tìm cách tối ưu hóa bộ nhớ.

Bạn cũng có thể sử dụng Thư viện tải hình ảnh như Picasso, UIL hoặc Glide. Tất cả đều có tính năng lưu hình ảnh trong bộ nhớ và/hoặc trên đĩa.

Answer 4

Quá muộn cho bữa tiệc ở đây, nhưng tôi sẽ cung cấp 0,02 đô la cho tôi.
Nó không phải là một ý tưởng tốt để sử dụngandroid:largeHeap="true" đây là trích từ google giải thích nó,

Tuy nhiên, khả năng để yêu cầu một đống lớn chỉ dành cho một nhóm nhỏ của ứng dụng có thể biện minh cho việc cần tiêu thụ nhiều RAM hơn (chẳng hạn làm ứng dụng chỉnh sửa ảnh lớn). Không bao giờ yêu cầu một đống lớn chỉ đơn giản là vì bạn đã hết bộ nhớ và bạn cần sửa chữa nhanh — bạn chỉ nên sử dụng nó khi bạn biết chính xác nơi tất cả bộ nhớ của bạn đang được phân bổ và lý do tại sao nó phải được giữ lại. Tuy nhiên, ngay cả khi bạn tự tin ứng dụng của bạn có thể biện minh cho đống lớn, bạn nên tránh yêu cầu nó đến bất kỳ mức độ nào có thể. Việc sử dụng bộ nhớ bổ sung sẽ càng ngày càng trở nên gây tổn hại cho trải nghiệm người dùng tổng thể vì bộ sưu tập rác sẽ mất nhiều thời gian hơn và hiệu năng hệ thống có thể chậm hơn khi chuyển đổi hoặc thực hiện các tác vụ phổ biến khác.

đây là liên kết hoàn chỉnh các tài liệu https://developer.android.com/training/articles/memory.html

CẬP NHẬT

Sau khi làm việc excrutiatingly với out of memory errors tôi sẽ nói thêm này để biểu hiện để tránh những vấn đề oom không phải là một tội lỗi , cũng như @Milad chỉ ra bên dưới nó không ảnh hưởng đến hoạt động bình thường của ứng dụng

CẬP NHẬT 2

Dưới đây là một vài lời khuyên để đối phó với out of memory errors

1) Sử dụng các callback mà android cho onLowMemory, onTrimMemory(int) và xóa bộ nhớ cache của hình ảnh tương tự (picasso, glide, fresco ....) bạn có thể đọc thêm về chúng here và here
2) nén tệp của bạn (hình ảnh, pdf)
3) đọc về cách xử lý bitmap hiệu quả hơn here
4) Sử dụng lint thường xuyên trước khi sản xuất đẩy để đảm bảo mã là kiểu dáng đẹp và không cồng kềnh

Answer 5

Tôi nghĩ rằng đây là một câu hỏi rất hiệu quả, và cho tôi thêm một số chi tiết về lợi thế và bất lợi của việc sử dụng tùy chọn này.

What You Get:

• Rõ ràng, bạn sẽ có đống lớn, có nghĩa là giảm nguy cơ OutOfMemoryError.

gì Bạn Lose:

• Bạn có thể mất một số khung hình, mà có thể gây ra một hitching nhìn thấy. Heap lớn hơn làm cho các bộ sưu tập rác mất nhiều thời gian hơn. Bởi vì bộ thu gom rác về cơ bản phải đi qua toàn bộ các đối tượng trực tiếp của bạn. Thông thường, thời gian tạm dừng thu gom rác là khoảng 5ms và bạn có thể nghĩ rằng vài mili giây không phải là vấn đề lớn. Nhưng mỗi mili giây đều tính. Thiết bị Android phải cập nhật màn hình của nó sau mỗi 16 ms và thời gian GC lâu hơn có thể đẩy thời gian xử lý khung của bạn lên hàng rào 16 mili giây, điều này có thể gây ra hiện tượng giật gân rõ ràng.

• Ngoài ra, việc chuyển đổi ứng dụng sẽ trở nên chậm hơn. Hệ thống Android có thể giết chết các quá trình trong bộ nhớ cache LRU bắt đầu bằng quá trình ít được sử dụng gần đây nhất, nhưng cũng đưa ra một số xem xét về những quy trình nào có nhiều bộ nhớ nhất. Vì vậy, nếu bạn sử dụng heap lớn hơn, quá trình của bạn sẽ có nhiều khả năng bị giết khi được tạo nền, có nghĩa là có thể mất nhiều thời gian hơn khi người dùng muốn chuyển từ các ứng dụng khác sang ứng dụng của bạn. Ngoài ra các quá trình nền khác sẽ có nhiều khả năng được khởi động khi quá trình của bạn là tiền cảnh, bởi vì ứng dụng của bạn yêu cầu bộ nhớ lớn hơn. Điều đó có nghĩa là việc chuyển từ ứng dụng của bạn sang các ứng dụng khác cũng mất nhiều thời gian hơn.

Kết luận:

Tránh sử dụng largeHeap tùy chọn càng nhiều càng tốt. Điều này có thể khiến bạn giảm hiệu suất và trải nghiệm người dùng kém.