แอพ iOS เร็วกว่าแอพสำหรับแอนดรอยด์หรือไม่เนื่องจากแอพ android ถูกตีความ?

แอพ Android ตีความมากกว่ารวบรวม สิ่งนี้ทำให้ช้ากว่าแอพ iOS ที่รันไทม์หรือไม่

applications ios

มันไม่ได้เป็นคำถามที่ดีเพราะแอป Android จะไม่ตีความเช่นเดียวกับที่ถูกต้องคำตอบจริงชี้ให้เห็น

— Aaronaught

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

— Selali Adobor

โปรดทราบว่า บริษัท ยักษ์ใหญ่บางแห่งซึ่งรวมถึง IBM กำลังเขียนแอปพลิเคชั่นที่สำคัญใน Java ในปัจจุบัน เมื่อพิจารณาจากคอมไพเลอร์ Just-In-Time (JIT) ซึ่งเป็นส่วนมาตรฐานของ Java VM ที่ทันสมัยประสิทธิภาพนั้นเทียบได้กับภาษาระดับสูงอื่น ๆ Java ไม่ได้เป็นเพียง "ภาษาตีความ" เป็นเวลาหลายปี

— keshlam

คอมไพเลอร์ JIT ไม่ได้เชื่อมโยงกับแนวคิดของ JVM เลย มี JVMs ที่ไม่ได้ใช้คอมไพเลอร์ JIT แม้แต่ในเชิงพาณิชย์ JVM ของ IBM รูปแบบบางอย่างไม่ได้เปิดใช้งาน JIT โดยค่าเริ่มต้นแทนที่จะใช้การรวบรวม AOT แทน นอกจากนี้โน้ตเล็ก ๆ "แอพพลิเคชั่นที่สำคัญใน Java วันนี้" อาจจะมีแนวโน้มมากขึ้นกว่าทศวรรษที่ผ่านมา (IBM ได้เพิ่ม Java ก่อนปี 1997)

— Selali Adobor

คำถามค่อนข้างทำให้เข้าใจผิด แอป iOS "ดั้งเดิม" เขียนขึ้นใน Objective-C (หรือ Swift) และเรียบเรียงในขณะที่แอป Android "มาตรฐาน" เขียนขึ้นใน Java และคอมไพล์ไปยัง bytecode ดูคำตอบของ @ DanHulme แต่มันเป็นไปได้ที่จะเขียนแอพสำหรับทั้งสองแพลตฟอร์มใน HTML & JavaScript โดยใช้เช่น PhoneGap / Cordova ปกติแล้วแอป HTML นั้นจะทำงานช้ากว่าแอปทั่วไปในแพลตฟอร์มเดียวกัน ดังนั้นหากแอพที่คล้ายกันสำหรับแพลตฟอร์ม "อื่น ๆ " ดูเหมือนช้าลงอาจเป็นเพราะมันถูกสร้างขึ้นโดยใช้เทคโนโลยีที่แตกต่างกัน

— David

คำตอบ:

Java ไม่ได้แปลความหมายบน Android แอพ Android รวบรวมโดยbytecodeโดยผู้พัฒนา Bytecode เป็นการนำเสนอแบบย่อของโปรแกรม: มีขนาดเล็กกว่าซอร์สโค้ดที่เขียนโดยโปรแกรมเมอร์ แต่ยังไม่สามารถเรียกใช้งานได้โดยตรงจาก CPU การปรับให้เหมาะสมบางอย่างเช่นการกำจัดรหัสที่ตายแล้วสามารถทำได้ในขั้นตอนนี้

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

มีข้อได้เปรียบด้านประสิทธิภาพบางประการในการทำเช่นนี้แทนการคอมไพล์ล่วงหน้าบนคอมพิวเตอร์ของผู้พัฒนา แอพสามารถรวบรวมสำหรับซีพียูเฉพาะบนโทรศัพท์โดยใช้ประโยชน์จากคุณสมบัติฮาร์ดแวร์และใช้คุณสมบัติด้านประสิทธิภาพ ตัวอย่างเช่นมันสามารถใช้การดำเนินการจุดลอยฮาร์ดแวร์ถ้า CPU รองรับ นอกจากนี้คอมไพเลอร์ JIT ที่ชาญฉลาด (เป็นที่ยอมรับว่า Dalvik ไม่ใช่คนฉลาดคนนี้) สามารถตรวจสอบวิธีการทำงานของโปรแกรมและดำเนินการปรับให้เหมาะสมตามวิธีการใช้งานจริงของโปรแกรม มันอาจคอมไพล์รหัสอีกครั้งด้วยคำใบ้สาขาที่ดีกว่าเมื่อเห็นว่ามีตัวเลือกใดบ้างที่เปิดและปิดตัวเลือกในสภาพแวดล้อมของคุณบนโทรศัพท์ของคุณ คอมไพเลอร์ด้านหน้าไม่มีข้อมูลนี้ให้ใช้

Dalvik ใช้แคช Dalvikและเทคนิคอื่น ๆ เพื่อลดข้อเสียของการรวบรวม JIT JVM ที่ใหม่สำหรับ Android L และหลังจากนั้น ART แทนที่ JIT ทั้งหมดที่มีไปข้างหน้าของเวลาคอมไพเลอร์ วิธีนี้จะรวมรหัสไบต์เพื่อประมวลผลดั้งเดิมเมื่อติดตั้งแอพเพื่อรับประโยชน์ส่วนใหญ่ของ JIT โดยไม่ล่าช้าในการโหลดแอป

อย่าลืมว่าแอพ Android ไม่ได้ประกอบด้วยจาวาทั้งหมด นักพัฒนามีNDK ที่จะเขียนแอพทั้งหมดหรือบางส่วนใน C หรือ C ++ สำหรับส่วนที่สำคัญต่อประสิทธิภาพของแอพโดยเฉพาะอย่างยิ่งสำหรับเกม อินเตอร์เฟสวัตถุประสงค์พิเศษเช่น OpenGL และ Renderscript ให้โปรแกรมเมอร์ใช้ประโยชน์จากฮาร์ดแวร์พิเศษเช่น GPU และตัวประมวลผลร่วม SIMD สำหรับการคำนวณบางประเภท

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

— แดนฮัลมี
แหล่งที่มา

+1 สำหรับคำอธิบายที่ดี จริง ๆ แล้วฉันกำลังรอคำตอบเช่นนี้

— มานี

ไม่แตกต่างจากการอภิปราย ".NET / Java vs. C ++" เก่าที่เหนื่อยล้าบนพีซีจริงๆ มันคือแอปเปิ้ลและส้ม

— Aaronaught

@ ArmonSafai ค่อนข้างเป็นเช่นนั้น

— Dan Hulme

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

— Aaronaught

ปัญหาหลักของที่นี่ก็คือ Dalvik กำลังถูกมองว่าเป็น "ปกติ" JVM ระหว่างการลงทะเบียนโดยไม่ใช้สแต็กอย่าง HotSpot (เนื่องจากลักษณะของโปรเซสเซอร์ ARM เทียบกับ HotSpot นั้นคือการกำหนดเป้าหมาย [เช่น IA32]) การใช้ Zygote และแนวคิดของไฟล์ odex (เช่นความคิดทั้งหมดของ ไม่ใช่ [มากหรือน้อย] จะตรงจากคลาสไฟล์ไปยังคลาสโหลดเดอร์) ทำให้ Dalvik เหมือนกับ JVM ปกติที่ถูกผูกไว้เพื่อนำไปสู่ความเข้าใจผิดบางประการ โดยเฉพาะอย่างยิ่งเนื่องจากรายละเอียดจำนวนมากของการติดตั้ง HotSpot มักจะเกี่ยวข้องกับ JVM โดยทั่วไป (เช่นคอมไพเลอร์ JIT)

— Selali Adobor

เนื่องจากนี่เป็นคำถามที่กว้างขวางนี่คือคำตอบที่กว้าง

"แอป iOS เร็วกว่าแอพ Android เนื่องจากแอพ Android ตีความหรือไม่"

แอป iOS อันดับแรกไม่ใช่แอปแอนดรอยด์ที่ "เร็วกว่า"

ประการที่สองเกี่ยวกับปัญหา "แอพ Android ถูกตีความ" นี่คือสิ่งที่คุณจะพูดเกี่ยวกับการคำนวณเช่น "15 ปีก่อน": อย่างที่คุณเห็นจากการสนทนาข้างบนสถานการณ์ในปัจจุบันมีความซับซ้อนมากขึ้น เทคโนโลยีใหม่ทั้งหมดมาก่อน แนวคิด "คอมไพล์เร็วกว่าตีความ!" มีความเกี่ยวข้องกันเมื่อเปรียบเทียบกับรหัสเครื่องเมื่อ 20 ปีที่แล้ว สิ่งต่าง ๆ เคลื่อนไปมากจนไม่สามารถนำไปประยุกต์ใช้กับ "iOS V Android" ได้อย่างชัดเจนในปัจจุบัน

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

ประการที่สี่อีกหนึ่งปัญหาที่ท่วมท้นในโทรศัพท์มือถือคือปัญหาของชิปเซ็ตกราฟิกและความสัมพันธ์ที่ซับซ้อนต่าง ๆ ของซอฟต์แวร์กับ OpenGL และอื่น ๆ ตัวอย่างเช่น Apple กำลังออกมาพร้อมกับระบบที่พวกเขาเรียกว่า "โลหะ" ที่เกี่ยวข้องกับปัญหาเหล่านี้และ Android กำลังออกมาพร้อมกับ "thingy" ของตัวเองในฟิลด์นี้ ปัญหาเหล่านี้รอบท่อกราฟิกมีความสำคัญอย่างมากต่อวิธีที่แอพ "รู้สึก" ในมือของคุณ

คำตอบสั้น ๆ สำหรับคำถามของคุณคือ "compiled V. ตีความ" เป็นจุดอภิปรายที่ล้าสมัยที่คุณรู้หรือไม่?

(นอกจากนี้ฉันไม่พบ Note3 "ช้ากว่า" โดยเฉพาะอย่างยิ่งของ iPhone นอกจากนี้บางส่วนยังเป็นสิ่งประดิษฐ์บริสุทธิ์ - มีโทรศัพท์ Android ราคาถูกอยู่: มี iPhone ที่มีประสิทธิภาพต่ำไม่ได้ดังนั้นบางคนอาจไม่ถูกต้อง แนวคิดจากสิ่งนี้)

— Fattie
แหล่งที่มา

-3

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

อย่างไรก็ตาม Java (ภาษาการเขียนโปรแกรมของ Android) ไม่ได้ถูกตีความ แต่ถูกรวบรวมโดย JIT นั่นหมายความว่าโปรแกรม Android รวบรวมก่อนที่คุณจะเรียกใช้ให้ประสิทธิภาพคล้ายกับ iOS 'Objective C

อีกไม่นานกรอบ ART ของ Android จะรวบรวมแอพไว้ล่วงหน้าเพื่อให้แอพนั้นทำงานในลักษณะเดียวกับแอพ iOS กล่าวอีกนัยหนึ่งว่า Android เวอร์ชั่นต่อไปน่าจะเร็วเท่ากับ iOS

ปรับปรุง

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

— See-ชาร์ป
แหล่งที่มา

คุณหมายถึง "ครั้งหนึ่งสามารถเปลี่ยนลำดับของการดำเนินการสุ่มได้อย่างไรและพวกมันมีพลังและไดนามิกมากขึ้นอย่างไรนอกจากนี้ฉันยังไม่ได้บอกว่าพวกมันช้าเพียงแค่ว่าพวกเขาจะช้าลงแม้แต่น้อย

— Armon Safai

สิ่งนี้ไม่เป็นความจริงทั้งหมด มันทำให้เข้าใจผิดที่จะบอกว่าไม่ต้องคอมไพล์ซ้ำเป็นข้อได้เปรียบเนื่องจากคุณยังต้องสร้างไฟล์ APK และปรับใช้กับอุปกรณ์ทดสอบ Google ไม่ได้ตัดสินใจที่จะใช้ Java: Android นั้นใช้ Java อยู่แล้วก่อนที่ Google จะซื้อ ไฟล์ APK ไม่มีรหัส "ในรูปแบบเดียวกับที่ [โปรแกรมเมอร์] ป้อน"

— Dan Hulme

Microsoft .NET ถูกคอมไพล์ลงเป็นรหัส IL ซึ่งตีความได้เช่นเดียวกับจาวาที่ถูกคอมไพล์ลงไปเป็น bytecode

— Esben Skov Pedersen

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

— Aza

Java โดยทั่วไปไม่ใช่ภาษาที่ตีความเว้นแต่คุณจะจัดการกับการใช้ JVM ที่ผิดปกติ การรวบรวม JIT ไม่ใช่สิ่งเดียวกับล่ามดังนั้นคำตอบส่วนใหญ่จึงค่อนข้างไม่เกี่ยวข้องกับบริบทของประสิทธิภาพการทำงานของ Android เนื่องจากใช้ JIT

— eldarerathis