Vì các hoạt động tối ưu hoá của R8 sẽ cập nhật mã của ứng dụng, nên bạn cần kiểm thử kỹ lưỡng hành vi của ứng dụng để đảm bảo ứng dụng hoạt động như mong đợi. Trong trường hợp có hành vi không mong muốn, hãy sử dụng trang này làm hướng dẫn để khắc phục các vấn đề tiềm ẩn sau khi tối ưu hoá.
Khi khắc phục sự cố, hãy tập trung vào các trường hợp sau:
- Tối ưu hoá quá mức dẫn đến sự cố ứng dụng: Ứng dụng của bạn gặp sự cố vì R8 tối ưu hoá quá nhiều mã.
- Tối ưu hoá không rõ ràng hoặc không đủ: R8 không tối ưu hoá ứng dụng của bạn như bạn mong đợi hoặc bạn cần thêm thông tin giải thích về các hoạt động tối ưu hoá.
Ứng dụng gặp sự cố
Nếu ứng dụng của bạn gặp sự cố sau khi tối ưu hoá bằng R8, thì thường là do phản chiếu bị hỏng. Để xác định phản xạ bị hỏng, hãy làm theo các nguyên tắc sau:
- Bạn nhận thấy một số trường hợp ngoại lệ, điều này thường có nghĩa là lớp, phương thức hoặc trường được chỉ định đang được sử dụng thông qua đối tượng phản chiếu.
Những trường hợp ngoại lệ này thường là một trong các trường hợp sau:
ClassNotFoundException,NoSuchMethodException,NoSuchFieldException,NoClassDefFoundError,NoSuchMethodError,NoSuchFieldError. - Bạn thấy mã tham chiếu đến tính năng phản chiếu bằng
import kotlin.reflect.*hoặcimport java.lang.reflect.*. - Bạn thấy một hàm khởi tạo lớp được dùng như sau:
Something::class.constructors. - Bạn sẽ thấy
Class.forName(...).
Giải pháp: Thêm một quy tắc giữ lại.
Tối ưu hoá không rõ ràng hoặc không đầy đủ
Vì các quy tắc được áp dụng từ ứng dụng của bạn cũng như các thư viện đi kèm, nên bạn có thể cần thêm thông tin rõ ràng về các quy tắc được áp dụng hoặc cần lời giải thích cho lý do R8 giữ lại một số phần mã mà bạn dự kiến sẽ được tối ưu hoá.
Không rõ về các quy tắc được áp dụng: Vì các quy tắc trong thư viện đi kèm cũng áp dụng cho ứng dụng của bạn và các lựa chọn chung trong những thư viện này cũng truyền đến ứng dụng của bạn, nên bạn có thể không chắc chắn về những quy tắc được áp dụng.
Giải pháp: Kiểm tra những quy tắc được áp dụng bằng cách xem báo cáo về tất cả các quy tắc mà R8 áp dụng khi tạo dự án. Bạn có thể xem báo cáo này tại
./app/build/outputs/mapping/configuration.txt. Báo cáo này chứa tất cả các quy tắc đã hợp nhất từ mọi thư viện và mô-đun được dùng để định cấu hình R8, đồng thời có thể dùng để xác định các quy tắc không hiệu quả.Giữ lại quá nhiều mã: Quá trình tối ưu hoá của R8 có thể giữ lại mã mà bạn dự kiến sẽ bị xoá.
Giải pháp: Sử dụng lựa chọn cấu hình
-whyareyoukeepingđể giúp bạn hiểu lý do mã được giữ lại. Đầu ra chứa một đường dẫn từ mã được giữ đến một trong các điểm truy cập của ứng dụng. Để biết thêm thông tin, hãy xem-whyareyoukeeping.Khó hiểu dấu vết ngăn xếp ban đầu: R8 thay đổi mã theo nhiều cách, khiến dấu vết ngăn xếp không còn tham chiếu đến mã ban đầu. Ví dụ: số dòng và tên của các lớp và phương thức có thể thay đổi.
Giải pháp: Kể từ bản cập nhật tính năng Android Studio Otter 3 và AGP 9.0, Logcat sẽ tự động gỡ rối các dấu vết ngăn xếp. Tuy nhiên, nếu đang dùng phiên bản Android Studio cũ, bạn cần khôi phục dấu vết ngăn xếp ban đầu theo cách thủ công. Để khôi phục dấu vết ngăn xếp ban đầu, hãy sử dụng công cụ dòng lệnh
retraceđược đóng gói kèm theo gói công cụ dòng lệnh.Để sử dụng
retrace, hãy cung cấp cho lệnh đường dẫn đến một tệp ánh xạ và một tệp dấu vết ngăn xếp. Tệp ánh xạ (gọi làmapping.txt) sẽ tự động đi kèm với Android App Bundle (AAB). Để biết thêm thông tin chi tiết, hãy xem tài liệu về retrace và bài viết trên Trung tâm trợ giúp của Play Console về cách gỡ rối mã nguồn cho các dấu vết ngăn xếp sự cố. Khi sử dụng Play và Firebase Crashlytics, hãy dùng tệpmapping.txtcùng với các lỗi mà dịch vụ thu thập được từ người dùng ứng dụng. Lệnh sau đây cho biết cách bạn có thể chạyretracetừ gốc của dự án:$ANDROID_HOME/cmdline-tools/latest/bin/retrace app/build/outputs/mapping/$releaseVariant/mapping.txt trace.txt
Báo cáo lỗi
Nếu không giải quyết được vấn đề với R8, hãy gửi thông tin về lỗi.