Các kiểu khác với các đối tượng sửa đổi theo thiết kế. Kiểu không thay thế đối tượng sửa đổi; thay vào đó, hai hệ thống này cùng tồn tại với các mục tiêu khác nhau. Về nội bộ, Kiểu là một đối tượng sửa đổi. Bạn có thể làm mọi thứ mà Kiểu có thể làm bằng các đối tượng sửa đổi, nhưng không phải tất cả chức năng trong đối tượng sửa đổi đều có trong Kiểu.
Sau đây là nội dung so sánh giữa Kiểu và đối tượng sửa đổi:
| Tính năng | Đối tượng sửa đổi | Kiểu |
|---|---|---|
| Mục tiêu chính | Xác định các hành vi, ngữ nghĩa và bố cục phức tạp. Đối tượng sửa đổi thao tác các phần tử riêng lẻ ngay lập tức cho một thành phần kết hợp cụ thể và không truyền xuống từ giao diện. | Xác định giao diện trực quan, kích thước của từng mục và các thuộc tính có thể điều chỉnh theo chủ đề. Kiểu hoạt động ở cấp độ giao diện và có thể ghi đè ở cấp độ thành phần. Các thành phần này sẽ lan toả và áp dụng kiểu cho nhiều thành phần kết hợp. |
| Logic | Cộng thêm – các đối tượng sửa đổi kết hợp với nhau để tạo thành một kết quả mới. | Có thể ghi đè – thuộc tính cuối cùng được đặt trong Kiểu sẽ thắng. Kiểu hoạt động như một lớp thuộc tính duy nhất ghi đè lẫn nhau dựa trên một hệ thống phân cấp mức độ ưu tiên đã xác định. |
| Tạo giao diện | Khó đưa vào một giao diện, thường được dùng riêng lẻ. | Theo thiết kế, Kiểu có thể được tạo chủ đề (có thể truy cập vào CompositionLocal) và có thể được xác định một lần và sử dụng trên các thành phần. |
| Hiệu suất | Các hoạt động cập nhật thường yêu cầu cả 3 giai đoạn của Compose: thành phần, bố cục và vẽ. Để đạt được hiệu suất ảnh động tốt của các đối tượng sửa đổi, bạn thường phải viết các phiên bản dựa trên lambda. | Bỏ qua giai đoạn thành phần, chỉ hoạt động trong giai đoạn bố cục và vẽ, giảm số lần kết hợp lại. Yêu cầu ít phân bổ đối tượng hơn. |
| Ảnh động | Yêu cầu sử dụng các thành phần ảnh động riêng biệt như animate*AsState |
Có API animate { } tích hợp sẵn giúp xử lý một số ảnh động cho bạn. |
Giới hạn của đối tượng sửa đổi
Đối tượng sửa đổi mang lại nhiều lợi ích trong bối cảnh Compose hiện tại. Tuy nhiên, Kiểu giải quyết một số hạn chế của đối tượng sửa đổi, được mô tả trong danh sách sau:
- Đối tượng sửa đổi thường được tạo trong giai đoạn Thành phần. Các bản cập nhật có thể buộc chạy lại toàn bộ Thành phần, Bố cục và Vẽ, ngay cả đối với những thay đổi nhỏ về hình ảnh như màu sắc, trừ phi bạn tạo đối tượng sửa đổi dựa trên lambda.
- Các đối tượng sửa đổi có điều kiện yêu cầu logic if-else gây gián đoạn trong các chuỗi trôi chảy. Việc tạo hiệu ứng cho các thành phần này đòi hỏi phải có trạng thái mặc định theo cách thủ công và thiếu cơ chế "tự động tạo hiệu ứng" hiệu suất cao.
- Các đối tượng sửa đổi xếp chồng lên nhau thay vì thay thế. Bạn không thể ghi đè đường viền mặc định của một thành phần; bạn chỉ có thể vẽ đường viền thứ hai lên trên.
- Khó trừu tượng hoá các đối tượng sửa đổi thành các giao diện chung. Do đó, các giao diện thường lưu trữ giá trị thô thay vì cấu hình công cụ sửa đổi có thể dùng lại.
Các hạn chế của Kiểu
Mặc dù Styles có thể lấp đầy một số khoảng trống mà các đối tượng sửa đổi có, nhưng chúng cũng có một số hạn chế, cho thấy cách chúng không thể thay thế hoàn toàn các đối tượng sửa đổi:
- Kiểu là các Sửa đổi chuyên biệt. Mặc dù một đối tượng sửa đổi có thể làm mọi việc mà một Kiểu có thể làm, nhưng điều ngược lại thì không đúng. Do đó, Kiểu có thể bổ sung nhưng không thể thay thế đối tượng sửa đổi.
- Kiểu chỉ giới hạn ở cấu hình trực quan (nền, khoảng đệm, đường viền). Chúng không thể xử lý các hành vi như logic nhấp chuột, phát hiện cử chỉ hoặc ngữ nghĩa hỗ trợ tiếp cận.
- Việc phân giải một Kiểu thành trạng thái cuối cùng sẽ tốn kém hơn so với việc áp dụng một bộ sửa đổi duy nhất. Hệ thống phải tạo một cấu trúc dữ liệu chứa tất cả các giá trị thuộc tính có thể có và việc tra cứu các thuộc tính được kế thừa sẽ làm phức tạp thêm quá trình này.
Trường hợp nên sử dụng Kiểu thay vì đối tượng sửa đổi
Mặc dù lựa chọn sử dụng Kiểu phụ thuộc phần lớn vào ứng dụng và các trường hợp sử dụng của bạn, nhưng hướng dẫn sau đây sẽ giúp xác định thời điểm nên ưu tiên kiểu hơn là đối tượng sửa đổi:
- Để đạt được tính nhất quán trên toàn bộ giao diện: Các kiểu được thiết kế để "nâng" vào một giao diện chung. Thay vì truyền các Modifier lặp lại cho mọi thành phần, bạn có thể xác định một Style duy nhất trong giao diện để tạo giao diện thống nhất trên toàn bộ ứng dụng.
- Khi thực hiện ảnh động thường xuyên: Các kiểu đánh giá trong giai đoạn Bố cục và Vẽ, cho phép các thuộc tính như màu sắc hoặc tỷ lệ hoạt hoạ trong khi bỏ qua hoàn toàn giai đoạn Thành phần. Điều này giúp giảm đáng kể mức hao tổn hiệu suất. Sử dụng Kiểu thay vì công cụ sửa đổi khi thực hiện ảnh động thuộc tính trực quan.
- Ghi đè so với xếp nhóm: Sử dụng Kiểu khi bạn cần thay thế một thuộc tính mặc định. Các đối tượng sửa đổi có tính cộng (thêm một đường viền sẽ xếp chồng đường viền thứ hai), trong khi các Kiểu sử dụng logic "ghi lần cuối sẽ thắng", giúp bạn dễ dàng thay thế hình nền hoặc khoảng đệm mà không gây rối mắt.
- Tuỳ chỉnh các thành phần Material: Nếu một thành phần Material cung cấp tham số Style, thì đây là phương pháp được đề xuất để tuỳ chỉnh. Các kiểu này cho phép bạn truy cập và sửa đổi các thuộc tính cụ thể trong cấu trúc nội bộ của thành phần kết hợp mà nếu không thì bạn không thể truy cập.