คุณสมบัติ Android N Java 8 (คอมไพเลอร์ Jack) และการทำงานร่วมกันของ Kotlin

ปรับปรุง 3. Kotlin IS NOW สนับสนุนอย่างเป็นทางการสำหรับการพัฒนา โดย GOOGLE อ๊าาาาาาาาา!

การปรับปรุงที่ 2 : ดูเหมือนว่าJetBrains มีความมุ่งมั่นมากที่จะสนับสนุน Kotlin สำหรับ Android ในระยะยาว ฉันเป็นผู้ใช้ kotlin ที่มีความสุข :)

อัปเดต : Hadi Hariri จาก JetBrains กล่าวว่าพวกเขากำลังจะเปิดเผยข้อมูลบางอย่างเกี่ยวกับหัวข้อนี้ ฉันจะอัปเดตโพสต์นี้เมื่อพวกเขาทำเสร็จแล้ว

=== สิ่งที่ถูกยกเลิกต่อไป ===

Google เปิดตัวเพียงภาพตัวอย่างที่จะเกิดขึ้นของ Android N ที่มีคุณสมบัติที่น่าสนใจบางอย่างที่เป็นอยู่บางส่วนที่โดดเด่นที่สุดJava 8 สนับสนุนภาษา สิ่งนี้เป็นไปได้เนื่องจากJack toolchainใหม่ที่Google กำลังทำงานอยู่

toolchain ปัจจุบันใช้javacหรือkotlinc :
javac ( .java-> .class) -> dx ( .class-> .dex)
kotlinc ( .kt-> .class) -> dx ( .class-> .dex)

New Jack toolchain:
แจ็ค ( .java-> .jack-> .dex)

ฉันสมมติว่า Google จะผลักดันให้Jackเป็นเครื่องมือเริ่มต้นสำหรับการพัฒนา Android ปรับปรุง: แจ็คตอนนี้เลิกใช้ ยาส.

คำถามของฉันคือ toolchain ใหม่นี้จะส่งผลต่อฉันอย่างไรในอนาคตในฐานะผู้ใช้kotlinสำหรับการพัฒนา Android ฉันจะ "จมปลักอยู่กับอดีต" หรือไม่?

ข้อจำกัดความรับผิดชอบ: ฉันทำงานกับแจ็ค

สิ่งนี้จะไม่ส่งผลกระทบต่อคุณ คอมไพเลอร์ของ Kotlin สร้าง Java 6 bytecode ซึ่ง Jack / Jill สามารถนำเข้าได้ดี

@ คุณปาเวลดุดคะ

แจ็ค - เป็นคอมไพเลอร์ คล้ายกับ javac แต่มันแตกต่างกันเล็กน้อย:

อย่างที่คุณเห็น Jack รวบรวมซอร์สโค้ด Java ลงในไฟล์ Dex โดยตรง! เราไม่มีไฟล์ระดับกลาง * .class อีกต่อไปดังนั้นจึงไม่จำเป็นต้องใช้เครื่องมือ dx!

แต่เดี๋ยวก่อน! จะเกิดอะไรขึ้นถ้าฉันรวมไลบรารีของบุคคลที่สามไว้ในโปรเจ็กต์ของฉัน (ซึ่งมาเป็นชุดของไฟล์. class)

และนั่นคือตอนที่จิลเข้ามาเล่น:

Jill สามารถประมวลผลไฟล์คลาสและแปลงเป็นรูปแบบ Jayce พิเศษซึ่งสามารถใช้เป็นอินพุตสำหรับคอมไพเลอร์ Jack

ตอนนี้เรามาดูกันสักวินาทีแล้วคิดว่า ... จะเกิดอะไรขึ้นกับปลั๊กอินเจ๋ง ๆ ทั้งหมดที่เราติดมาก? พวกเขาล้วนต้องการไฟล์. class และคอมไพเลอร์ Jack ก็ไม่มีอีกต่อไป ...

โชคดีที่แจ็คนำเสนอคุณสมบัติที่สำคัญสำหรับเราไว้ให้นอกกรอบ:

• Retrolambda - ไม่จำเป็น แจ็คสามารถจัดการกับ lambdas ได้อย่างเหมาะสม
• Proguard - มันถูกอบในแจ็คแล้วดังนั้นคุณยังสามารถใช้การทำให้ยุ่งเหยิงและการย่อขนาดได้

ข้อดี:

Jack รองรับภาษาการเขียนโปรแกรม Java 1.7 และรวมคุณสมบัติเพิ่มเติมที่อธิบายไว้ด้านล่าง

• การคาดการณ์ล่วงหน้า

  เมื่อสร้างไฟล์ไลบรารี JACK .dex ของไลบรารีจะถูกสร้างและเก็บไว้ในไฟล์ไลบรารี. jack เป็น pre-dex เมื่อทำการคอมไพล์ JACK จะนำ pre-dex จากแต่ละไลบรารีกลับมาใช้ใหม่ ไลบรารีทั้งหมดถูกเตรียมไว้ล่วงหน้า

• การรวบรวมส่วนเพิ่ม

  การคอมไพล์แบบเพิ่มหน่วยหมายถึงคอมโพเนนต์ที่ถูกแตะตั้งแต่การคอมไพล์ครั้งล่าสุดและการอ้างอิงเท่านั้นที่คอมไพล์ใหม่ การคอมไพล์ที่เพิ่มขึ้นสามารถทำได้เร็วกว่าการคอมไพล์แบบเต็มอย่างมากเมื่อการเปลี่ยนแปลงถูก จำกัด ไว้เพียงชุดคอมโพเนนต์ที่ จำกัด เท่านั้น

• การบรรจุใหม่

  JACK ใช้ไฟล์คอนฟิกูเรชัน jarjar เพื่อทำการรีแพ็กเกจ

• การสนับสนุน Multidex

  เนื่องจากไฟล์ dex ถูก จำกัด ไว้ที่ 65K เมธอดแอพที่มีเมธอดมากกว่า 65K จึงต้องแบ่งออกเป็นไฟล์ dex หลาย ๆ ไฟล์ (ดู 'การสร้างแอพที่มีวิธีการมากกว่า 65K' สำหรับข้อมูลเพิ่มเติมเกี่ยวกับ multidex)

ข้อเสีย:

• Jack ไม่รองรับ Transform API - ไม่มี bytecode Java ระดับกลางที่คุณสามารถแก้ไขได้ดังนั้นปลั๊กอินบางตัวที่ฉันไม่ได้พูดถึงที่นี่จะหยุดทำงาน
• ขณะนี้ Jack ไม่รองรับการประมวลผลคำอธิบายประกอบดังนั้นหากคุณต้องพึ่งพาไลบรารีเช่น Dagger, AutoValue และอื่น ๆ อย่างมากคุณควรคิดให้ดีก่อนที่จะเปลี่ยนไปใช้ Jack แก้ไข: ตามที่ Jake Wharton ชี้ให้เห็นว่า Jack in N Preview มีการรองรับการประมวลผลคำอธิบายประกอบ แต่ยังไม่ได้เปิดเผยผ่าน Gradle
• ไม่สนับสนุนเครื่องตรวจจับผ้าสำลีที่ทำงานบนระดับ bytecode ของ Java
• ไม่รองรับ Jacoco - โดยส่วนตัวแล้วฉันพบว่า Jacoco น่าสงสัย (มันไม่ได้แสดงสิ่งที่คุณต้องการเห็นจริงๆ) ดังนั้นสามารถอยู่ได้โดยไม่ต้องใช้มัน
• Dexguard - ปัจจุบันยังไม่รองรับ Proguard เวอร์ชันสำหรับองค์กร

Google จะไม่ผลักดันแจ็คเป็นเครื่องมือในการเริ่มต้น Jack and Jillแต่
การรวบรวมไฟล์. class เป็น dex ด้วย Jill อยู่ที่นี่ มิฉะนั้นคุณสามารถบอกลาห้องสมุด jar / aar ได้

ไม่ว่าแจ็คหรือจิลจะช้าลงก็ยังคงเป็นเรื่องที่ถกเถียงกันอยู่ ทีม Android หวังว่าแจ็คจะเร็วกว่าขั้นตอนการสร้างปัจจุบัน แต่ตอนนี้ยังไม่เป็นเช่นนั้น

นอกจากนี้ Jack และ Dex ยังมีให้ใช้งานแบบเปิดไม่มีอะไรป้องกันไม่ให้ทีม kotlin เขียนเครื่องมือที่ปล่อยไฟล์. jack หรือ. debx จากรหัสแหล่ง kotlin

อัพเดท (16 มีนาคม 2560)

โชคดีที่แจ็คตายไปแล้วดังนั้นจึงไม่ส่งผลกระทบต่อนักพัฒนา Kotlin

ถ้าแจ็คคืออนาคตคุณจะจมปลักอยู่กับอดีตกับ Kotlin ปัจจุบัน Jack ไม่รองรับปลั๊กอินที่สามารถรวบรวมซอร์สที่ไม่ใช่ Java ลงใน Dalvik bytecode และแม้ว่า JetBrains จะต้องเพิ่มแบ็กเอนด์ใหม่ให้กับคอมไพเลอร์ Kotlin ซึ่งไม่ใช่งานเล็กน้อย ดังนั้นคุณจะต้องใช้ Kotlin กับ Jill และมันจะคล้ายกับ toolchain ที่คุณใช้อยู่ตอนนี้

ดังที่คุณเห็นในภาพด้านล่างแม้ว่าจะไม่สามารถปิด Jack ได้อย่างชัดเจนคุณก็ยังสามารถแปลงโครงการเป็นโครงการห้องสมุดเพื่อใช้ Jill ได้ และโครงการแอปพลิเคชันจะอ้างอิงโครงการห้องสมุดนี้

วิธีเดียวที่ผมเห็นว่า Kotlin สามารถทำงานร่วมกับแจ็คซึ่งอาจจะไม่ได้รับการดำเนินการคือการเพิ่มแบ็กเอนด์ Java เพื่อรวบรวม Kotlin คือแบ็กเอนด์ที่สร้างรหัส Java เช่นเอ็กซ์เท็นด์ ในกรณีนี้รหัสที่สร้างโดยคอมไพเลอร์ Kotlin สามารถประมวลผลโดย Jack เป็นรหัส Java อื่น ๆ

แต่ในขณะนี้เรายังไม่รู้แน่ชัดว่าแจ็คจะสนับสนุนอะไรเมื่อเปิดตัว บางทีบางสิ่งบางอย่างอาจเปลี่ยนแปลงไปอย่างมากและการเพิ่มการสนับสนุน Kotlin ให้กับ Jack ก็เป็นไปได้

ดังที่กล่าวไว้ในบล็อกโพสต์ ( Roadmap ของ Android ของ Kotlin ) ที่ปรากฏในวันนี้:

ขณะนี้มีปัญหาบางอย่างที่ทำให้ Jack ไม่สามารถจัดการ bytecode ที่สร้างโดย Kotlin ได้อย่างถูกต้อง ( 196084และ203531 ) แต่เราวางแผนที่จะทำงานร่วมกับทีม Google เพื่อแก้ไขปัญหาหรือให้วิธีแก้ไขปัญหาในฝั่งของเรา เมื่อเสร็จแล้วเราจะสามารถแปลเฉพาะไฟล์คลาสที่เปลี่ยนแปลงโดยใช้ Jillในระหว่างการคอมไพล์ที่เพิ่มขึ้นซึ่งต่างจากการแปลไฟล์คลาสทั้งหมดทุกครั้ง (ซึ่งเป็นพฤติกรรมเดียวที่เป็นไปได้ในเครื่องมือ Android รุ่นเก่า)

ดังนั้นในที่สุด Kotlin ก็จะสนับสนุน Jack & Jill และได้รับประโยชน์จากมัน

ตามประกาศล่าสุดของ Google -

เราได้ตัดสินใจเพิ่มการรองรับคุณลักษณะภาษา Java 8 ลงในชุดเครื่องมือ javac และ dx ปัจจุบันโดยตรงและเลิกใช้งาน Jack toolchain ด้วยแนวทางใหม่นี้เครื่องมือและปลั๊กอินที่มีอยู่ซึ่งขึ้นอยู่กับรูปแบบไฟล์คลาส Java ควรจะยังคงทำงานต่อไป ในอนาคตคุณลักษณะภาษา Java 8 จะได้รับการสนับสนุนโดยระบบสร้าง Android เรามีเป้าหมายที่จะเปิดตัวสิ่งนี้เป็นส่วนหนึ่งของ Android Studio ในอีกไม่กี่สัปดาห์ข้างหน้าและเราต้องการแบ่งปันการตัดสินใจนี้กับคุณโดยเร็ว

ในตอนแรกเราได้ทดสอบการเพิ่มการรองรับ Java 8 ผ่าน Jack toolchain เมื่อเวลาผ่านไปเราตระหนักว่าค่าใช้จ่ายในการเปลี่ยนมาใช้ Jack นั้นสูงเกินไปสำหรับชุมชนของเราเมื่อเราพิจารณาตัวประมวลผลคำอธิบายประกอบตัววิเคราะห์ไบต์โค้ดและตัวเขียนซ้ำได้รับผลกระทบ ขอบคุณที่ลองใช้ Jack toolchain และให้ข้อเสนอแนะที่ดีแก่เรา คุณสามารถใช้ Jack เพื่อสร้างโค้ด Java 8 ของคุณต่อไปได้จนกว่าเราจะออกการสนับสนุนใหม่ การย้ายข้อมูลจากแจ็คควรต้องใช้งานเพียงเล็กน้อยหรือไม่มีเลย

ดังนั้นเราไม่จำเป็นต้องกังวลว่า jack toolchain จะกลายเป็น toolchain เริ่มต้นสำหรับการพัฒนา Android คุณสามารถใช้ kotlin ต่อไปหรือใช้ชุดเครื่องมือ javac / dx ปกติ

ที่มา: อนาคตของการสนับสนุนคุณลักษณะภาษา Java 8 บน Android

ฉันพบโพสต์บล็อกนี้แล้วจากบล็อกอย่างเป็นทางการของ Kotlin: Roadmap Android ของ Kotlin

คุณจะพบส่วนที่บอกว่า:

สิ่งต่อไปที่เราวางแผนที่จะทำอะไรเพื่อปรับปรุง Android สร้างประสิทธิภาพการทำงานให้บูรณาการกับ Android ของใหม่แจ็คและจิลล์ toolchain ขณะนี้มีปัญหาบางอย่างที่ทำให้ Jack ไม่สามารถจัดการ bytecode ที่สร้างโดย Kotlin ได้อย่างถูกต้อง ( 196084และ203531 ) แต่เราวางแผนที่จะทำงานร่วมกับทีม Google เพื่อแก้ไขปัญหาหรือให้วิธีแก้ไขปัญหาในฝั่งของเรา เมื่อเสร็จแล้วเราจะสามารถแปลเฉพาะไฟล์คลาสที่เปลี่ยนแปลงโดยใช้ Jill ในระหว่างการคอมไพล์ที่เพิ่มขึ้นซึ่งต่างจากการแปลไฟล์คลาสทั้งหมดทุกครั้ง (ซึ่งเป็นพฤติกรรมเดียวที่เป็นไปได้ในเครื่องมือ Android รุ่นเก่า)

ดังที่ @LukasBergstrom กล่าวว่าจะไม่มีปัญหาใด ๆ กับการ "จมปลักอยู่กับอดีต" ;-)

คุณยังสามารถตรวจสอบRedditการสนทนาที่เชื่อมโยงกับหัวข้อนี้: สถานะของ Kotlin กับ Jack and Jill คืออะไร?

มีความสุขในการเขียนโค้ด

ตามบล็อกของ Kotlinปล่อย 1.1-beta2 ส่วนคุณสมบัติใหม่:

รองรับการสร้างโครงการ Android เมื่อเปิดใช้งาน Jack toolchain (jackOptions {true})