ส่วนหน้าของมิดเดิลเอิร์ธ

คำแนะนำแบบทีละขั้นเกี่ยวกับการพัฒนาสำหรับหลายอุปกรณ์

Daniel Isaksson
Einar Öberg

ในบทความแรกเกี่ยวกับการพัฒนาการทดลอง A Journey Through Middle-earth ของ Chrome เรามุ่งเน้นที่การพัฒนา WebGL สำหรับอุปกรณ์เคลื่อนที่ ในบทความนี้ เราจะพูดถึงความท้าทาย ปัญหา และวิธีแก้ไขที่เราพบเมื่อสร้างส่วนหน้า HTML5 ที่เหลือ

เว็บไซต์เดียวกันทั้ง 3 เวอร์ชัน

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

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

เราสามารถดูหน้า Landing Page เป็นตัวอย่างของการปรับการออกแบบให้เหมาะกับขนาดต่างๆ

นกอินทรีเพิ่งมาส่งเราที่หน้า Landing Page
นกอินทรีเพิ่งมาส่งเราที่หน้า Landing Page

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

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

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

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

.loc-hobbit-logo {

  // Default values here.

  .desktop & {
     // Applies only in desktop mode.
  }

 .tablet &, .mobile & {
   
   // Different asset for mobile and tablets perhaps.

   @media screen and (max-height: 760px), (max-width: 760px) {
     // Breakpoint-specific styles.
   }

   @media screen and (max-height: 570px), (max-width: 400px) {
     // Breakpoint-specific styles.
   }
 }
}

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

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

เราใช้เครื่องมือจำลองใน DevTools อยู่บ่อยๆ ระหว่างการพัฒนา โดยเฉพาะใน Chrome Canary ซึ่งมีฟีเจอร์ที่ได้รับการปรับปรุงใหม่ๆ และค่าที่กำหนดล่วงหน้าจำนวนมาก เป็นวิธีที่ดีในการตรวจสอบการออกแบบได้อย่างรวดเร็ว เรายังจำเป็นต้องทดสอบในอุปกรณ์จริงเป็นประจำ สาเหตุหนึ่งคือเว็บไซต์ปรับให้เต็มหน้าจอ หน้าเว็บที่มีการเลื่อนในแนวตั้งจะซ่อน UI ของเบราว์เซอร์เมื่อเลื่อนในกรณีส่วนใหญ่ (Safari ใน iOS7 มีปัญหาในการใช้งานในปัจจุบัน) แต่เราต้องปรับให้เหมาะกับทุกอย่างโดยไม่เกี่ยวข้องกับสิ่งนั้น นอกจากนี้เรายังใช้ค่าที่กำหนดล่วงหน้าในโปรแกรมจำลองและเปลี่ยนการตั้งค่าขนาดหน้าจอเพื่อจำลองการสูญเสียพื้นที่ว่าง การทดสอบบนอุปกรณ์จริงก็มีความสำคัญต่อการตรวจสอบการใช้หน่วยความจำและประสิทธิภาพเช่นกัน

การจัดการรัฐ

หลังหน้า Landing Page เราลงจอดที่แผนที่ของมิดเดิลเอิร์ธ คุณสังเกตเห็น URL เปลี่ยนไปหรือไม่ เว็บไซต์นั้นเป็นแอปพลิเคชันหน้าเว็บเดียวที่ใช้ History API ในการจัดการการกำหนดเส้นทาง

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

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

แสดงตำแหน่งของสถานที่

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

ห้องโถงของธรันดูอิล
ไทม์ไลน์ของ Thranduil's Hall

ลำดับเวลา

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

โมดูลและองค์ประกอบลักษณะการทำงาน

โมดูลต่างๆ ที่เราเพิ่มการรองรับได้แก่ ลำดับรูปภาพ ภาพนิ่ง ฉากพารัลแลกซ์ ฉากโหมดโฟกัสชิฟท์ และข้อความ

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

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

เนื้อหาในโมดูลข้อความเปิดใช้การลากได้ด้วยปลั๊กอิน TweenMax ที่ชื่อว่า Draggable นอกจากนี้คุณยังใช้ล้อเลื่อนหรือการเลื่อน 2 นิ้วเพื่อเลื่อนในแนวตั้งได้ด้วย สังเกตthrow-props-plugin" ที่เพิ่มหลักฟิสิกส์แบบขว้างเมื่อคุณปัดแล้วปล่อย

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

เราสามารถสร้างตำแหน่งต่างๆ ได้ด้วยไฟล์การกำหนดค่าที่ระบุเนื้อหาที่จะโหลด และตั้งค่าโมดูลและคอมโพเนนต์ประเภทต่างๆ

ลำดับรูปภาพ

โมดูลที่ท้าทายที่สุดในด้านประสิทธิภาพและขนาดการดาวน์โหลดคือลำดับของรูปภาพ เรามีข้อมูลให้อ่านมากมายเกี่ยวกับหัวข้อนี้ ส่วนในอุปกรณ์เคลื่อนที่และแท็บเล็ต เราจะใช้ภาพนิ่งแทนรูปภาพ ข้อมูลมากเกินกว่าจะถอดรหัสและเก็บไว้ในหน่วยความจำหากเราต้องการคุณภาพที่ดีในอุปกรณ์เคลื่อนที่ เราได้ลองใช้โซลูชันทางเลือกหลายๆ ทางโดยใช้ภาพพื้นหลังและสไปรท์ชีตก่อน แต่ก็ทำให้เกิดปัญหาด้านหน่วยความจำและความล่าช้าเมื่อ GPU จำเป็นต้องสับเปลี่ยนระหว่างสไปรท์ชีต จากนั้นเราได้ลองสลับองค์ประกอบ img แต่ก็ช้าเกินไป การวาดกรอบจากภาพต่อเรียงไปยังผืนผ้าใบเป็นวิธีที่มีประสิทธิภาพมากที่สุด เราจึงเริ่มเพิ่มประสิทธิภาพองค์ประกอบนั้น เพื่อประหยัดเวลาในการคำนวณในแต่ละเฟรม ข้อมูลรูปภาพที่จะเขียนลงในผืนผ้าใบจะได้รับการประมวลผลล่วงหน้าผ่านผืนผ้าใบชั่วคราวและบันทึกด้วย PutImageData() ลงในอาร์เรย์ที่ถอดรหัสและพร้อมใช้งาน จากนั้นสไปรท์ชีตต้นฉบับอาจเป็นขยะที่รวบรวมได้ และเราจัดเก็บข้อมูลในหน่วยความจำตามจำนวนขั้นต่ำที่กำหนดเท่านั้น บางทีจริงๆ แล้วการจัดเก็บรูปภาพที่ไม่ได้ถอดรหัสอาจมีน้อยกว่า แต่เรามีประสิทธิภาพมากขึ้นเมื่อสครับลำดับด้วยวิธีนี้ เฟรมมีขนาดเล็กเพียง 640x400 แต่จะมองเห็นได้ระหว่างการสครับ เมื่อคุณหยุด ภาพที่มีความละเอียดสูงจะโหลดและค่อยๆ ปรากฏขึ้นอย่างรวดเร็ว

var canvas = document.createElement('canvas');
canvas.width = imageWidth;
canvas.height = imageHeight;

var ctx = canvas.getContext('2d');
ctx.drawImage(sheet, 0, 0);

var tilesX = imageWidth / tileWidth;
var tilesY = imageHeight / tileHeight;

var canvasPaste = canvas.cloneNode(false);
canvasPaste.width = tileWidth;
canvasPaste.height = tileHeight;

var i, j, canvasPasteTemp, imgData, 
var currentIndex = 0;
var startIndex = index * 16;
for (i = 0; i < tilesY; i++) {
  for (j = 0; j < tilesX; j++) {
    // Store the image data of each tile in the array.
    canvasPasteTemp = canvasPaste.cloneNode(false);
    imgData = ctx.getImageData(j * tileWidth, i * tileHeight, tileWidth, tileHeight);
    canvasPasteTemp.getContext('2d').putImageData(imgData, 0, 0);

    list[ startIndex + currentIndex ] = imgData;

    currentIndex++;
  }
}

ภาพต่อเรียงสร้างขึ้นด้วย Imagemagick ลองดูตัวอย่างง่ายๆ ใน GitHub ที่แสดงวิธีสร้างภาพต่อเรียงของรูปภาพทั้งหมดในโฟลเดอร์

การทำให้โมดูลเคลื่อนไหว

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

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

ประสิทธิภาพของหน้าเว็บ

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

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

ฉันชอบใช้ TweenMax จาก Greensock สำหรับคุณสมบัติ Tweening, การแปลง และ CSS นึกถึงคอนเทนเนอร์ ทำให้เห็นภาพโครงสร้างขณะที่คุณเพิ่มเลเยอร์ใหม่ๆ โปรดทราบว่าการเปลี่ยนรูปแบบใหม่สามารถเขียนทับการเปลี่ยนแปลงที่มีอยู่ได้ TranslateZ(0) ที่บังคับให้การเร่งฮาร์ดแวร์ในคลาส CSS ของคุณถูกแทนที่ด้วยเมทริกซ์ 2 มิติ หากคุณทวีค่า 2D เท่านั้น หากต้องการให้เลเยอร์อยู่ในโหมดเร่งในกรณีเหล่านั้น ให้ใช้คุณสมบัติ "force3D:true" ในทวีนเพื่อสร้างเมทริกซ์ 3 มิติแทนเมทริกซ์ 2 มิติ คุณอาจลืมไปได้ง่ายๆ เมื่อรวม CSS และ JavaScript Tween เพื่อกำหนดรูปแบบ

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

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

การออกจากส่วนด้วยฟังก์ชันการกำจัดที่ล้มเหลว
การออกจากส่วนด้วยฟังก์ชันการกำจัดที่ล้มเหลว
ดีขึ้นมาก
ดีขึ้นมาก

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

มีการอ้างอิงฉากใน Effect Composer
มีการอ้างถึงฉากใน Effect Composer

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

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

เต็มหน้าจอ

(หากมี) คุณจะมีตัวเลือกในการทำให้เว็บไซต์อยู่ในโหมดเต็มหน้าจอในเมนูผ่าน API เต็มหน้าจอ แต่บนอุปกรณ์ เบราว์เซอร์ก็มีการตัดสินใจว่าจะแสดงเนื้อหาแบบเต็มหน้าจอหรือไม่ ก่อนหน้านี้ Safari ใน iOS เคยมีการแฮ็กที่ให้คุณควบคุมได้ แต่ฟีเจอร์นี้ไม่มีให้บริการแล้ว คุณจึงต้องเตรียมการออกแบบให้ทำงานได้ตรงที่แม้จะสร้างหน้าแบบเลื่อนไม่ได้ เราอาจคาดหวังการอัปเดตเกี่ยวกับเรื่องนี้สำหรับการอัปเดตในอนาคต เนื่องจากแอปนี้ทำให้เว็บแอปจำนวนมากพังทลายลง

ชิ้นงาน

วิธีการแบบภาพเคลื่อนไหวสำหรับการทดสอบ
วิธีการแบบภาพเคลื่อนไหวสำหรับการทดสอบ

ในเว็บไซต์ของเรามีเนื้อหาประเภทต่างๆ มากมาย เราใช้รูปภาพ (PNG และ JPEG), SVG (ในบรรทัดและพื้นหลัง), ภาพต่อเรียง (PNG), แบบอักษรไอคอนที่กำหนดเอง และภาพเคลื่อนไหวของ Adobe Edge เราใช้ PNG สำหรับเนื้อหาและภาพเคลื่อนไหว (spritesheet) ซึ่งไม่สามารถใช้เวกเตอร์ตามองค์ประกอบ ไม่เช่นนั้นเราจะพยายามใช้ SVG ให้มากที่สุด

รูปแบบเวกเตอร์จะทำให้คุณภาพไม่ลดลง แม้ว่าเราจะปรับขนาดก็ตาม 1 ไฟล์สำหรับอุปกรณ์ทั้งหมด

  • ไฟล์มีขนาดเล็ก
  • เราสามารถทำให้แต่ละส่วนเคลื่อนไหวแยกกันได้ (เหมาะกับภาพเคลื่อนไหวขั้นสูง) ตัวอย่างเช่น เราซ่อน "ชื่อรอง" ของโลโก้ฮอบบิท (ดินแดนเปลี่ยวร้างของสม็อก) เมื่อมีการปรับขนาดโลโก้
  • โดยคุณสามารถฝังเป็นแท็ก SVG HTML หรือใช้เป็นภาพพื้นหลังได้โดยไม่ต้องโหลดเพิ่มเติม (โดยจะโหลดพร้อมกับหน้า HTML)

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

ภาพเคลื่อนไหว

ในบางกรณี การสร้างภาพเคลื่อนไหวขององค์ประกอบ SVG โดยใช้โค้ดอาจใช้เวลานานมาก โดยเฉพาะอย่างยิ่งเมื่อต้องเปลี่ยนแปลงภาพเคลื่อนไหวอย่างมากระหว่างขั้นตอนการออกแบบ เพื่อปรับปรุงเวิร์กโฟลว์ระหว่างนักออกแบบและนักพัฒนาซอฟต์แวร์ เราจะใช้ Adobe Edge สำหรับภาพเคลื่อนไหวบางอย่าง (วิธีการก่อนเล่นเกม) เวิร์กโฟลว์ของภาพเคลื่อนไหวนั้นใกล้เคียงกับ Flash มากและสามารถช่วยทีมได้ แต่มีข้อเสียบางประการ โดยเฉพาะอย่างยิ่งในการผสานรวมภาพเคลื่อนไหว Edge ในกระบวนการโหลดเนื้อหาของเรา เนื่องจากวิธีนี้มาพร้อมกับตัวโหลดและตรรกะการติดตั้งใช้งานของตัวเอง

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

บทสรุป

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