Tôi đã đọc về hiệu suất mã và các tham số điều chỉnh trong một thời gian dài. Thực tế, các chương trình Android là một trong những trọng tâm của tôi.
Trước tiên, hãy giới thiệu các khái niệm cơ bản hoặc quan trọng nhất giúp chúng tôi đạt được giải pháp.
Như nhà phát triển Android đã tuyên bố
mô-đun có thể được xây dựng, thử nghiệm và gỡ lỗi độc lập
Do đó, các Mô-đun có Gradle & Dependencies của riêng họ . Và bạn có thể khám phá nó trong dự án Hierarchy Viewer.
Như một vấn đề thực tế, Modularization nhấn mạnh vào các vấn đề Bảo trì . Không giống như vấn đề hiệu suất. Bởi vì, Modularization có tác động quan trọng này:
Đây là một sơ đồ mà tôi đã vẽ nó để làm cho nó rõ ràng. Như bạn có thể thấy. Trong khi sử dụng mô-đun rời rạc, để gọi Phương thức A, có 2N micro secsso sánh với N micro secsmô-đun rời rạc.
Câu hỏi này tôi nghĩ rằng Phương thức được tham chiếu tính những gì liên quan đến Độ sâu của thừa kế?
Câu trả lời là: Mặc dù sử dụng mô-đun hóa tăng Khảo Methods.but, nó không thực sự ảnh hưởng đến hiệu quả hoạt động ứng dụng và vấn đề chính có thể là Depth thừa kế , trong đó ở hầu hết các trường hợp là có thể bỏ qua .
Tôi nhấn mạnh rằng các Phương thức tham chiếu tăng trong mô đun hóa là do mỗi Lớp và phụ thuộc mô-đun
Làm thế nào mô đun hóa ứng dụng có thể tăng số lượng phương thức tham chiếu rất cao?
Các điều kiện trong đó tác động đến phân tích APK quan trọng Phương thức được tham chiếu
Cũng lưu ý rằng việc thu nhỏ và thu nhỏ mã cũng có thể thay đổi đáng kể nội dung của tệp DEX sau khi mã nguồn được biên dịch.
Ngoài tuyên bố chính thức ở trên, tôi muốn thêm một điều kiện khác trong đó tác động đến trình phân tích APK đó là:
Nhà phát triển có kinh nghiệm trong việc mô đun hóa bao nhiêu?
mô đun hóa giống như một ngôi nhà mà kiến trúc (nhà phát triển) xác định nơi nào nên là nhà bếp và nơi nên là phòng nghỉ và nơi nên là WC.
Nếu kiến trúc quyết định kết hợp WC & Bếp thì sao? Phải đây là một thảm họa.
Điều này có thể xảy ra trong khi mô đun hóa nếu nhà phát triển không có nhiều kinh nghiệm.
Trả lời các câu hỏi của OP trong Bổ sung thêm thông tin
Ở đây tôi trả lời cho câu hỏi op trong các ý kiến
Tại sao phân tách Gradle thêm vào số phương thức được tham chiếu? Và đối với phụ thuộc riêng biệt, nếu kết quả cuối cùng là APK đơn thì tôi không nghĩ phụ thuộc trùng lặp trong 'ứng dụng' và mô-đun tính năng sẽ thêm vào số phương thức được tham chiếu.
Bởi vì các mô-đun có thể được xây dựng, thử nghiệm và gỡ lỗi, sau đó chúng PHẢI có Cấp độ & Phụ thuộc riêng.
Trong khi dự án đa mô-đun đang được tuân thủ, trình biên dịch tạo ra một số .dextệp bao gồm:
- một
.dextập tin cho các phụ thuộc tổng hợp
- mô-đun
.dexs
.dextập tin phụ thuộc là một sự tích hợp của tất cả các lớp mô-đun
Chúng ta hãy xem làm thế nào một lớp mô-đun tác động đến Đếm Mothods được tham chiếu cuối cùng?!
có 2 APK giây có cùng kết quả nhưng khác nhau về số lượng Phương thức được tham chiếu.
Cả hai đều là các hoạt động trống có 1.7ksự khác biệt về Số lượng phương thức được tham chiếu rất cao phụ thuộc vào chức năng của chúng. Sự khác biệt chính của chúng là trên Lớp của Mô-đun, một trong số chúng được cấu hình để
dependencies {
implementation fileTree(dir: 'libs', include: ['*.jar'])
implementation 'androidx.appcompat:appcompat:1.1.0'
implementation 'androidx.constraintlayout:constraintlayout:1.1.3'
}
Một cái khác được cấu hình để
dependencies {
implementation fileTree(dir: 'libs', include: ['*.jar'])
implementation 'androidx.appcompat:appcompat:1.2.0-alpha01'
implementation 'androidx.constraintlayout:constraintlayout:2.0.0-beta4'
}
Mặc dù chúng chỉ là các hoạt động trống rỗng nhưng sự khác biệt tối thiểu trong Gradle đã gây ra 1.7ksự khác biệt về Số lượng phương thức được tham chiếu.
Và ứng dụng Gradle là
dependencies {
implementation fileTree(dir: 'libs', include: ['*.jar'])
implementation 'androidx.appcompat:appcompat:1.1.0'
implementation 'androidx.constraintlayout:constraintlayout:1.1.3'
implementation project(path: ':module')
}
mối quan tâm chính là tại sao việc thêm số lượng phương thức được tham chiếu riêng lẻ lại khác với tổng số phương thức được tham chiếu trong Apk Phân tích?
Đây chỉ là bộ lọc IDE không có gì khác. chắc chắn, nếu bạn chỉ chọn một .dextệp Đếm phương thức tham chiếu bằng với SUM của mỗi hàng Đếm phương thức được tham chiếu nhưng nếu bạn chọn nhiều .dextệp, bạn sẽ thấy sự khác biệt về SUM và Đếm thực tế vì tính bằng nhau trong Tham chiếu mà Trình phân tích ưa thích lọc chúng.
trong ảnh chụp màn hình của bạn, bạn đã chọn nhiều .dextệp rồi phân tích bộ lọc bình đẳng.
trong dự án của chúng tôi, chúng tôi đang sử dụng tập tin phụ thuộc tập trung. Nâng cấp để không có cơ hội của phiên bản khác nhau. Vì vậy, bạn có nghĩ ngay cả khi chúng ta có tập hợp phụ thuộc giống hệt / chính xác và các phiên bản của chúng trong các mô-đun tính năng, nó sẽ tăng số lượng phương thức được tham chiếu không?
Về mặt lý thuyết, nó KHÔNG nên tăng số lượng phương thức tham chiếu. NHƯNG , như tôi đã giải thích, Trải nghiệm nhà phát triển tác động rất lớn đến kết quả cuối cùng.
Nhóm phân tích nên kiểm tra và khắc phục các sự cố về hiệu suất trước khi phát hành như
- quy tắc bảo vệ
- tài nguyên bị thu hẹp
- androidManifest.xml
- cài đặt lớp
Bây giờ tôi muốn làm rõ nó như thế nào Trải nghiệm nhà phát triển và bảo trì mã ảnh hưởng đến kết quả cuối cùng. NGAY CẢ nếu APK của bạn sử dụng Phụ thuộc tập trung
trong ví dụ trên, tôi đã tăng số lượng 5.1kPhương thức tham chiếu NGAY CẢ NẾU tôi có Phụ thuộc tập trung !!!!!
Làm thế nào nó có thể?
Câu trả lời là: tôi chỉ thêm một .jartập tin vô dụng và ẩn trong libsthư mục của dự án. chỉ cần dễ dàng như bạn có thể thấy tôi đã ảnh hưởng đến kết quả cuối cùng.
Như bạn có thể thấy Trải nghiệm của nhà phát triển ảnh hưởng đến kết quả cuối cùng. Như một kết quả, thực tế có thể các phương thức được tham chiếu sẽ được tăng lên mặc dù về mặt lý thuyết KHÔNG nên .
Và tại sao không có sự khác biệt về số lượng phương thức được tham chiếu khi tôi chỉ biên dịch mô-đun 'ứng dụng' bằng cách vô hiệu hóa biên dịch song song? Nó đáng lẽ đã giảm vì chỉ phụ thuộc mô-đun 'ứng dụng' sẽ được sử dụng, phải không?
việc biên dịch không có bất kỳ mối quan hệ nào với các phương thức được tham chiếu. Nó tuân thủ những gì nhà phát triển muốn tuân thủ.
Phần kết luận
Tôi đã bao gồm tất cả các khả năng xung quanh vấn đề. Thật vậy, nó có thể xuất hiện từ các tình huống khác nhau và một nhà phát triển bằng cách sử dụng hướng dẫn này có thể khắc phục vấn đề.
- Tôi hy vọng rằng bạn đã tìm thấy lý do tại sao Phương thức tham chiếu được tăng lên và tại sao trong một số trường hợp, nó có thể được tăng mạnh.
- Các mô-đun có Gradle & Dependencies và mô-đun tăng mô-đun. do đó, các tài liệu tham khảo phương pháp này.
- Modularization thực sự tác động đến hiệu suất ứng dụng không thể biết được nhưng làm cho Bảo trì ứng dụng của bạn tốt hơn rất nhiều.
- Kinh nghiệm của nhà phát triển trong việc mô đun hóa cũng tác động rất lớn đến kết quả cuối cùng.
LƯU Ý QUAN TRỌNG: gần như tất cả các tuyên bố là nghiên cứu & nghiên cứu của tôi. thật vậy, có thể có lỗi và lỗi và sẽ được cập nhật để thêm nhiều thông tin hơn trong tương lai.
