Các tính năng của Android N Java 8 (trình biên dịch Jack) và tương tác Kotlin

Cập nhật 3. KOTLIN BÂY GIỜ ĐƯỢC HỖ TRỢ CHÍNH THỨC CHO SỰ PHÁT TRIỂN CỦA ANDROID . BỞI GOOGLE. YAAAAAAAAS!

Cập nhật 2 : Có vẻ như JetBrains thực sự cam kết hỗ trợ Kotlin cho Android về lâu dài . Tôi là một người dùng kotlin hạnh phúc :).

Cập nhật : Hadi Hariri, từ JetBrains, cho biết họ sẽ phát hành một số thông tin về chủ đề này . Tôi sẽ cập nhật bài đăng này khi họ làm.

=== NHÂN VIÊN KHÔNG CÒN TIẾP THEO ===

Google vừa phát hành bản xem trước cho Android N sắp tới với một số tính năng thú vị, trong đó đáng chú ý nhất là hỗ trợ một phần ngôn ngữ Java 8 . Điều này có thể thực hiện được do chuỗi công cụ Jack mới mà Google đang phát triển.

Chuỗi công cụ hiện tại sử dụng javac hoặc kotlinc :
javac ( .java-> .class) -> dx ( .class-> .dex)
kotlinc ( .kt-> .class) -> dx ( .class-> .dex)

Chuỗi công cụ Jack mới:
Jack ( .java-> .jack-> .dex)

Tôi cho rằng Google sẽ thúc đẩy việc đưa Jack trở thành chuỗi công cụ mặc định để phát triển Android. Cập nhật: Jack hiện không được dùng nữa . Đúng vậy.

Câu hỏi của tôi là chuỗi công cụ mới này sẽ ảnh hưởng như thế nào đến tôi, trong tương lai, với tư cách là một người dùng kotlin để phát triển Android? Tôi sẽ bị "mắc kẹt trong quá khứ"?

tuyên bố từ chối trách nhiệm: Tôi làm việc trên Jack

Điều này sẽ không ảnh hưởng đến bạn. Trình biên dịch của Kotlin tạo ra mã bytecode của Java 6, mà Jack / Jill có thể nhập tốt.

@Pavel Dudka

Jack - là một trình biên dịch. Tương tự như javac, nhưng nó có một chút khác biệt:

Như bạn thấy, Jack biên dịch mã nguồn Java thẳng vào tệp Dex! Chúng tôi không có tệp * .class trung gian nữa, vì vậy công cụ dx là không cần thiết!

Nhưng đợi đã! Điều gì sẽ xảy ra nếu tôi bao gồm một thư viện của bên thứ ba trong dự án của mình (đi kèm dưới dạng một bộ sưu tập các tệp .class)?

Và đó là khi Jill vào vai:

Jill có thể xử lý các tệp lớp và chuyển đổi chúng thành định dạng Jayce đặc biệt có thể được sử dụng làm đầu vào cho trình biên dịch Jack.

Vì vậy, bây giờ chúng ta hãy bước sang một bên và suy nghĩ ... Điều gì sẽ xảy ra với tất cả những plugin thú vị mà chúng ta đã rất nghiện? Tất cả đều cần tệp .class và trình biên dịch Jack không có những tệp đó nữa ...

May mắn thay, Jack cung cấp một số tính năng quan trọng đối với chúng tôi:

• Retrolambda - sẽ không cần thiết. Jack có thể xử lý lambdas đúng cách
• Proguard - bây giờ nó đã được đưa vào Jack, vì vậy bạn vẫn có thể sử dụng tính năng làm mờ và thu nhỏ

Ưu điểm:

Jack hỗ trợ ngôn ngữ lập trình Java 1.7 và tích hợp các tính năng bổ sung được mô tả bên dưới.

• Lập trước

  Khi tạo tệp thư viện JACK, .dex của thư viện được tạo và lưu trữ bên trong tệp thư viện .jack dưới dạng pre-dex. Khi biên dịch, JACK sử dụng lại pre-dex từ mỗi thư viện. Tất cả các thư viện đều được dexed trước.

• Biên dịch tăng dần

  Biên dịch tăng dần có nghĩa là chỉ các thành phần đã được chạm vào kể từ lần biên dịch cuối cùng và các thành phần phụ thuộc của chúng, được biên dịch lại. Biên dịch tăng dần có thể nhanh hơn đáng kể so với biên dịch đầy đủ khi các thay đổi chỉ được giới hạn ở một nhóm thành phần hạn chế.

• Đóng gói lại

  JACK sử dụng các tệp cấu hình jarjar để thực hiện việc đóng gói lại.

• Hỗ trợ Multidex

  Vì tệp dex bị giới hạn ở 65 nghìn phương thức, nên các ứng dụng có hơn 65 nghìn phương thức phải được chia thành nhiều tệp dex. (Xem 'Xây dựng ứng dụng với hơn 65 nghìn phương pháp' để biết thêm thông tin về multidex.)

Nhược điểm:

• API chuyển đổi không được Jack hỗ trợ - không có mã bytecode Java trung gian nào mà bạn có thể sửa đổi, vì vậy một số plugin tôi không đề cập ở đây sẽ ngừng hoạt động
• Jack xử lý chú thích hiện không được hỗ trợ, vì vậy nếu bạn phụ thuộc nhiều vào các thư viện như Dagger, AutoValue, v.v., bạn nên suy nghĩ kỹ trước khi chuyển sang Jack. CHỈNH SỬA: Như đã chỉ ra bởi Jake Wharton, Jack in N Preview có hỗ trợ xử lý chú thích, nhưng nó vẫn chưa được hiển thị thông qua Gradle.
• Không hỗ trợ các trình phát hiện xơ mỡ hoạt động ở mức bytecode của Java.
• Jacoco không được hỗ trợ - tốt, cá nhân tôi thấy Jacoco có vấn đề (nó không thực sự hiển thị những gì bạn muốn xem), vì vậy hoàn toàn có thể sống mà không có nó
• Dexguard - phiên bản doanh nghiệp của Proguard hiện không được hỗ trợ

Google sẽ không đẩy Jack làm công cụ mặc định, nhưng Jack and Jill.
Biên dịch các tệp .class sang dex với Jill luôn sẵn sàng. Nếu không, bạn có thể nói lời tạm biệt với các thư viện jar / aar.

Liệu Jack hay Jill sẽ chậm hơn vẫn còn là điều cần tranh luận. Nhóm Android hy vọng rằng jack cắm sẽ nhanh hơn quá trình xây dựng hiện tại, nhưng đó không phải là trường hợp ngay bây giờ

Hơn nữa, Jack và Dex có sẵn ở chế độ mở, không có gì ngăn cản nhóm kotlin viết một công cụ tạo tệp .jack hoặc .dex từ mã nguồn kotlin.

CẬP NHẬT (16/03/2017)

May mắn thay, Jack đã chết và vì vậy nó sẽ không ảnh hưởng đến các nhà phát triển Kotlin.

Nếu Jack là tương lai thì bạn sẽ mắc kẹt trong quá khứ với Kotlin. Hiện tại Jack không hỗ trợ các plugin có thể biên dịch mã nguồn không phải Java thành mã bytecode Dalvik. Và ngay cả khi điều đó xảy ra thì JetBrains cũng cần thêm một phần phụ trợ mới vào trình biên dịch Kotlin, đây không phải là một nhiệm vụ tầm thường. Vì vậy, bạn sẽ phải sử dụng Kotlin với Jill và nó sẽ giống với chuỗi công cụ mà bạn sử dụng bây giờ.

Như bạn có thể thấy trong hình ảnh bên dưới, ngay cả khi không thể tắt Jack rõ ràng, bạn vẫn có thể chuyển đổi dự án thành dự án thư viện để sử dụng Jill. Và dự án ứng dụng sẽ chỉ tham chiếu dự án thư viện này.

Cách duy nhất tôi thấy cách Kotlin có thể làm việc với Jack, mà có thể sẽ không được triển khai, là thêm phần phụ trợ Java vào trình biên dịch Kotlin, tức là phần phụ trợ tạo ra mã Java như Xtend . Trong trường hợp này, mã do trình biên dịch Kotlin tạo ra có thể được Jack xử lý như bất kỳ mã Java nào khác.

Nhưng hiện tại chúng tôi không biết chính xác Jack sẽ hỗ trợ những gì khi nó được phát hành. Có thể điều gì đó sẽ thay đổi đáng kể và việc bổ sung hỗ trợ Kotlin cho Jack sẽ trở nên khả thi.

Như đã nói trong bài đăng trên blog ( Lộ trình Android của Kotlin ) xuất hiện ngày hôm nay:

Hiện tại, có một số vấn đề ngăn Jack xử lý mã bytecode do Kotlin tạo một cách chính xác ( 196084 và 203531 ), nhưng chúng tôi dự định làm việc cùng với nhóm Google để giải quyết vấn đề hoặc đưa ra các giải pháp thay thế cho phía chúng tôi. Khi điều này được thực hiện, chúng tôi sẽ chỉ có thể dịch các tệp lớp đã thay đổi bằng cách sử dụng Jill trong quá trình biên dịch gia tăng, trái ngược với việc dịch tất cả các tệp lớp mọi lúc (đây là hành vi duy nhất có thể xảy ra trong công cụ Android cũ).

Vì vậy, Kotlin cuối cùng sẽ hỗ trợ Jack & Jill và nhận được lợi ích từ nó.

Theo thông báo mới nhất của google -

Chúng tôi đã quyết định thêm hỗ trợ cho các tính năng của ngôn ngữ Java 8 trực tiếp vào bộ công cụ javac và dx hiện tại, đồng thời ngừng sử dụng chuỗi công cụ Jack. Với hướng mới này, các công cụ và plugin hiện có phụ thuộc vào định dạng tệp lớp Java sẽ tiếp tục hoạt động. Trong tương lai, các tính năng của ngôn ngữ Java 8 sẽ được hỗ trợ bởi hệ thống xây dựng Android. Chúng tôi dự định ra mắt tính năng này như một phần của Android Studio trong những tuần tới và chúng tôi muốn chia sẻ quyết định này sớm với bạn.

Ban đầu, chúng tôi đã thử nghiệm thêm hỗ trợ Java 8 thông qua chuỗi công cụ Jack. Theo thời gian, chúng tôi nhận ra rằng chi phí chuyển sang Jack là quá cao đối với cộng đồng của chúng tôi khi chúng tôi coi bộ xử lý chú thích, bộ phân tích bytecode và trình viết lại bị ảnh hưởng. Cảm ơn bạn đã dùng thử chuỗi công cụ Jack và phản hồi tuyệt vời cho chúng tôi. Bạn có thể tiếp tục sử dụng Jack để xây dựng mã Java 8 của mình cho đến khi chúng tôi phát hành hỗ trợ mới. Di chuyển từ Jack sẽ cần ít hoặc không cần công việc.

Vì vậy, chúng ta không cần lo lắng về việc jack toolchain trở thành toolchain mặc định để phát triển Android. Bạn có thể tiếp tục sử dụng kotlin hoặc sử dụng bộ công cụ javac / dx bình thường.

Nguồn: Tương lai của hỗ trợ tính năng ngôn ngữ Java 8 trên Android

Tôi đã tìm thấy bài đăng blog này từ blog chính thức của Kotlin:: Lộ trình Android của Kotlin

Ở đó, bạn sẽ tìm thấy một phần nói rằng:

Điều tiếp theo chúng tôi dự định làm để cải thiện hiệu suất xây dựng Android là cung cấp tích hợp với chuỗi công cụ Jack và Jill mới của Android . Hiện tại, có một số vấn đề ngăn Jack xử lý mã bytecode do Kotlin tạo một cách chính xác ( 196084 và 203531 ), nhưng chúng tôi dự định làm việc cùng với nhóm Google để giải quyết vấn đề hoặc đưa ra các giải pháp thay thế cho phía chúng tôi. Khi điều này được thực hiện, chúng tôi sẽ chỉ có thể dịch các tệp lớp đã thay đổi bằng cách sử dụng Jill trong quá trình biên dịch gia tăng, trái ngược với việc dịch tất cả các tệp lớp mọi lúc (đây là hành vi duy nhất có thể xảy ra trong công cụ Android cũ).

Vì vậy, như @LukasBergstrom đã nói, sẽ không có bất kỳ vấn đề gì với "quá khứ từng tồn tại" ;-)

Bạn cũng có thể kiểm tra Redditthảo luận được liên kết với chủ đề này: Tình trạng của Kotlin với Jack và Jill là gì?

Chúc bạn viết mã vui vẻ.

Theo blog Kotlin , phát hành phần Tính năng mới 1.1-beta2:

Hỗ trợ xây dựng các dự án Android khi chuỗi công cụ Jack được bật (jackOptions {true});