วิเคราะห์และลดขนาดเฟรมเวิร์ก iOS

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

คุณไม่สามารถลดขนาดสิ่งที่ยังไม่ได้วัดได้ ตรวจสอบขนาดไฟล์ .framework ที่บิลด์แล้ว เพื่อให้การเปลี่ยนแปลงในภายหลังทุกครั้งมีตัวเลขไว้เปรียบเทียบ

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

ตารางสัญลักษณ์ช่วยในการดีบัก แต่ทำให้ไบนารีมีขนาดใหญ่ขึ้น การ ตัดสัญลักษณ์ เหล่านี้ออกสำหรับรุ่นใช้งานจริงจะลดขนาดเฟรมเวิร์กโดยไม่กระทบพฤติกรรม

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

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

กำหนดตัวช่วยภายในเป็น ภายใน แทนที่จะเป็นสาธารณะ การประกาศที่ส่งออกจะถูกลบไม่ได้ ดังนั้นการมีขอบเขตที่กระชับจึงทำให้ไบนารีมีขนาดเล็กลง

ขนาดเป็นเรื่องหนึ่ง ความเร็วก็เป็นอีกเรื่องหนึ่ง ใช้เครื่องมือ Instruments ของ Xcode เพื่อดูว่าการโหลดและการเริ่มต้นเฟรมเวิร์กใช้เวลาจริงเท่าใด

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

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

ขนาดมักเพิ่มขึ้นอย่างเงียบ ๆ บันทึก ขนาด เฟรมเวิร์กในระบบผสานรวมอย่างต่อเนื่อง เพื่อให้การเพิ่มขึ้นอย่างฉับพลันชี้ไปยังการเปลี่ยนแปลงที่ทำให้ขนาดเพิ่ม

คุณวัดขนาดเฟรมเวิร์กรุ่นเผยแพร่ ตัดสัญลักษณ์ ลดการพึ่งพาและส่วนติดต่อโปรแกรมประยุกต์สาธารณะ วัดประสิทธิภาพการเปิดใช้งานใน Instruments และติดตามขนาดในระบบผสานรวมอย่างต่อเนื่อง 📉