Vấn đề về hiệu suất tự động iOS trong chế độ dọc. [NSISEngine tối ưu hóa]

Question

Tôi đã gặp phải một vấn đề rất lạ và tôi đã tự hỏi, nếu có ai có thể giúp tôi ở đây vì tôi hoàn toàn lạc mất.

Bối cảnh: Tôi đang phát triển một ứng dụng có cấu trúc phân cấp tương đối đơn giản. Chỉ cần một vài bộ điều khiển xem nhưng khá nhiều hình ảnh có độ phân giải cao. Chúng được trình bày trong một UIScrollView với một số văn bản, vv Trong khi thử nghiệm nó ở chế độ dọc, scrollview không di chuyển trơn tru cả. Dường như tốc độ khung hình giảm xuống còn khoảng 4-5 khung hình/giây. Đầu tiên tôi nghĩ đó là vì những hình ảnh có độ phân giải cao.

Nhưng sau đó tôi chuyển iPad sang chế độ ngang và mọi thứ diễn ra suôn sẻ. Kể từ khi tôi có một tập tin xib riêng biệt cho chân dung và phong cảnh, tôi nghĩ rằng có phải là một vấn đề trong bức chân dung-xib. Hóa ra là không có. Cả hai đều có cùng một lớp VC và do đó sử dụng cùng một mã và cả hai xibs gần như giống hệt nhau ngoại trừ kích thước và vị trí của các khung nhìn.

Để thu hẹp sự cố, tôi đã sử dụng TimeProfiler của Instrument để xem những gì gây ra sự cố. Khi nó bật ra, TimeProfiler cho thấy một số cuộc gọi đến [NSISEngine optimize] (được kích hoạt bởi NSLayoutConstraint). Ở chế độ dọc, có nhiều cuộc gọi hơn và các cuộc gọi đó mất nhiều thời gian hơn. Hơn nữa xuống cây tôi thấy rằng trong chế độ chân dung [NSISEngine optimize] được gọi là [NSISEngine fixupIntegralizationViolations] và trong cảnh quan nó không.

Tôi thậm chí đã xóa tất cả các bộ điều khiển của khung nhìn khỏi ứng dụng ngoại trừ rootVC và một khác được trình bày bởi rootVC. Các vc trình bày chỉ chứa một số hình ảnh, các nút và một số hình ảnh động. Nó chỉ có một xib cho cả hai định hướng và là (như tất cả những người khác quá) layed với autolayout.

Bố cục hoạt động như trong cả hai hướng và không có sự mơ hồ (theo như tôi có thể biết. Ít nhất po [[UIWindow keyWindow] _autolayoutTrace] không hiển thị bất kỳ).

Tôi đã đính kèm ảnh chụp màn hình của TimeProfile của quá trình trình bày vc. Một cho chân dung và một cho cảnh quan. Như bạn có thể thấy, trong cảnh quan, các cuộc gọi tới [NSISEngine optimize] chỉ mất một phần nghìn giây trong khi ở chế độ dọc, chúng chiếm hơn 3000 mili giây.

Có ai có thể cho tôi biết tại sao không? Hoặc có thể có bất kỳ ý tưởng gì tôi có thể làm để tìm ra vấn đề là gì?

Bất kỳ trợ giúp nào sẽ được đánh giá rất nhiều!

Thx

Liên kết đến một phiên bản lớn hơn của hình ảnh: link

Answer 1

tôi đã đệ đơn yêu cầu hỗ trợ kỹ thuật liên quan đến vấn đề này và cuối cùng đã câu trả lời, rằng nó rất có thể là một lỗi. Báo cáo lỗi được gửi. Hy vọng rằng họ sẽ sửa chữa nó sớm. Nếu có bất kỳ tin tức nào, tôi sẽ cập nhật câu trả lời này.

Answer 2

Tôi đã gặp sự cố tương tự với chế độ xem phức tạp vừa phải, nơi nó hoạt động tốt trên iPad không phải của Retina hoặc iPad Retina ở chế độ dọc. Ở chế độ ngang trên thiết bị Retina, phải mất hơn 10 lần để hiển thị cửa sổ bật lên hoặc đẩy chế độ xem khác trên ngăn xếp chế độ xem. Tôi đã kết thúc thay thế tệp XIB bằng một loadView được mã hóa bằng tay trong trình điều khiển chế độ xem. Điều đó dường như đã loại bỏ vấn đề. Trình xây dựng giao diện có xu hướng tạo ra các ràng buộc quá mức, do đó, việc kiểm soát đó là chìa khóa cho hiệu suất bố cục tự động tốt.

Tôi cũng đã mở một vé hỗ trợ về vấn đề này.

Cập nhật:

Tôi đã tìm ra nguyên nhân trong tình huống của mình. Đó là tập hợp các ràng buộc sau:

NSArray *constraints = [NSLayoutConstraint 
         constraintsWithVisualFormat : @"|[sunLabel][monLabel(==sunLabel)][tueLabel(==sunLabel)][wedLabel(==sunLabel)][thuLabel(==sunLabel)][friLabel(==sunLabel)][satLabel(==sunLabel)]|" 
         options : 0 
         metrics : nil 
         views : labelViewsDictionary]; 

Nó chỉ định rằng 7 nhãn trong chế độ xem gốc đều có cùng kích thước và tất cả mở rộng chiều rộng của chế độ xem gốc. Tôi tin rằng bản chất quan hệ quá mức của bố cục đã tạo ra bố cục tự động phù hợp, đặc biệt vì chiều rộng của chế độ xem gốc không thể chia đều cho 7.

Để giải quyết, tôi đã tạo ra một loạt các ràng buộc chỉ định chiều rộng của mỗi nhãn và áp dụng những hạn chế đó. Khi thiết bị quay chiều rộng của phụ huynh thay đổi, vì vậy tôi quay trở lại và điều chỉnh hằng số trên các ràng buộc bằng 1/7 chiều rộng của chế độ xem gốc. Điều này bây giờ thực hiện tốt, quá trình tải một cửa sổ bật lên hiện nay mất ít hơn 300ms thay vì 2000 mili giây.

Answer 3

Tôi đã gặp sự cố tương tự hôm qua trong thiết bị iOS6.1 Ipad. Dụng cụ ứng dụng phát hiện ra rằng phương pháp fixupIntegralizationViolations đã mất khoảng 300 ms mỗi lần được gọi (khoảng 20 lần, rất nhiều) khiến cho ứng dụng hoàn toàn vô dụng.

Sự cố của tôi rất giống với nhận xét của Jack Cox, nhưng tôi đã giải quyết nó khác đi. Ràng buộc của tôi là:

@ "H: | [allButton] [inStoreButton (== allButton)] [trực tuyếnButton (== allButton)] [sortButton (50)] |"

Vấn đề là parentView ở đây là chiều rộng toàn cảnh của iPad, do đó, tính toán của sự hạn chế này đã cho mỗi nút chiều rộng này: (1024-50)/3 = 324,6666667. Điều này thường không phải là một vấn đề trong autolayout vì nó sẽ chăm sóc các số phao lớn và làm tròn chúng một cách chính xác, nhưng có vẻ như trong iPad iOS6 Landscape làm tròn số này gây ra một lỗi chặn giao diện người dùng. Để đi xung quanh nó tất cả tôi phải làm là thay đổi sortButton với để có 52, do đó, mỗi chiều rộng nút bây giờ là: (1024-52)/3 = 324. Đó là tất cả. Bây giờ phương thức fixupIntegralizationViolations mất khoảng 1ms mỗi lần được gọi.

Điều thú vị là sử dụng 52 cho chiều rộng không thập phân trong khổ ngang, nhưng nó cung cấp số thập phân theo chiều dọc: (768-52)/3 = 238.666667. Tuy nhiên, chân dung dường như không có bất kỳ lỗi và autolayout làm tròn số chính xác.