Hiệu suất-khôn ngoan: Rất nhiều PNG nhỏ hoặc một PNG lớn?

Question

Phát triển một trò chơi đơn giản cho iPhone, điều gì mang lại hiệu suất tốt hơn?

1. Sử dụng rất nhiều nhỏ (10x10 đến 30x30 pixel) PNG cho hình nền UIViews của tôi.
2. Sử dụng một PNG lớn và cắt bớt các giới hạn của UIViews của tôi.

Suy nghĩ của tôi là kỹ thuật đầu tiên yêu cầu ít bộ nhớ hơn mỗi UIView cá nhân, nhưng phức tạp như thế nào iPhone xử lý số lượng lớn hình ảnh vì nó cố gắng kết hợp hình ảnh vào một kết cấu lớn hơn hoặc cố gắng chuyển đổi giữa tất cả các kết cấu nhỏ rất nhiều.

Kỹ thuật thứ hai, mặt khác, mang lại cho iPhone cơ hội để xử lý chỉ một PNG lớn, nhưng tăng một cách không đều trọng lượng hình ảnh mà mỗi UIView phải mang theo.

• Tôi có đúng về những nỗ lực của iPhone, xử lý hình ảnh theo cách tôi mô tả không?
• Vì vậy, con đường để đi là gì?

Nhìn thấy câu trả lời cho đến nay, vẫn còn nghi ngờ. Dường như có một sự cân bằng với hai tham số: Sự phức tạp và mã hóa CPU. Điểm bùng phát của tôi để quyết định kỹ thuật nào sẽ sử dụng?

Answer 1

Nếu bạn kết thúc tham chiếu trở lại cùng một CGImageRef (ví dụ bằng cách chia sẻ UIImage *), hình ảnh sẽ không được tải nhiều lần bởi các chế độ xem khác nhau. Đây là kỹ thuật được sử dụng bởi videowall Core Animation demo at the WWDC 07 keynote. Đó là mã OSX, nhưng UIViews rất giống với CALayers.

Cách đồ họa cốt lõi xử lý hình ảnh (từ quan sát của tôi) được tinh chỉnh rất nhiều để tải đúng thời gian và phát hành tích cực khi bộ nhớ bị chặt.

Sử dụng hình ảnh lớn, bạn có thể tải hình ảnh tại thời điểm vẽ nếu bộ nhớ cho hình ảnh đã giải mã mà CGImageRef trỏ tới đã được hệ thống thu hồi.

Điều gì tạo nên sự khác biệt không phải là bạn có bao nhiêu hình ảnh, nhưng tần suất UIKit truyền tải mã của bạn.

Cả UIViews và Core Animation CALayers sẽ chỉ vẽ lại nếu bạn yêu cầu (-setNeedsDisplay) và nút cổ chai thường là mã của bạn cộng với chuyển nội dung được hiển thị thành kết cấu cho chip đồ họa. Vì vậy, lời khuyên của tôi là để suy nghĩ bố trí UIView của bạn theo cách cho phép các phần thay đổi cùng nhau để được cập nhật tất cả cùng một lúc, mà biến thành một kết cấu tải lên duy nhất.

Answer 2

Một thứ lớn mang đến cho bạn hiệu suất tốt hơn. (Nguyên nhân nếu bạn vẫn nên hiển thị tất cả ảnh).

Answer 3

Một hình ảnh lớn sẽ loại bỏ mọi chi phí liên quan đến việc mở và thao tác nhiều hình ảnh trong bộ nhớ.

Answer 4

Một hình ảnh lớn chủ yếu cung cấp cho bạn nhiều công việc hơn và nhiều cơn đau đầu hơn. Nó khó duy trì nhưng có lẽ ít ram chuyên sâu hơn vì chỉ có một cấu trúc + dữ liệu trong bộ nhớ thay vì nhiều cấu trúc + dữ liệu. (mặc dù có lẽ không đủ để thông báo).

Nhìn vào nội dung của gói ứng dụng trên Mac OS thông thường, có vẻ như phương pháp lưu trữ được chấp thuận chung là một tệp/tài nguyên cho mỗi hình ảnh.

Tất nhiên, điều này giả định bạn không nhận được tài nguyên hình ảnh từ web, nơi nút cổ chai sẽ ở http và tối đa được chỉ định của hai yêu cầu đồng thời.

Answer 5

Tôi sẽ nói không có câu trả lời có thẩm quyền cho câu hỏi này. Một hình ảnh lớn duy nhất cắt giảm tốc độ truy cập flash (chậm) và giải mã chỉ trong một lần nhưng rất nhiều hình ảnh nhỏ hơn cho phép bạn kiểm soát tốt hơn quá trình xử lý xảy ra khi ... nhưng bộ nhớ đói và bạn phải cắt hình ảnh đó hoặc che giấu nó.

Bạn sẽ phải triển khai một giải pháp và kiểm tra nó. Nếu nó không đủ nhanh và bạn không thể tối ưu hóa, hãy triển khai cài đặt khác. Tôi khuyên bạn nên triển khai phiên bản mà cá nhân bạn thấy dễ dàng hơn để tưởng tượng việc triển khai vì điều đó sẽ dễ thực hiện nhất.