สิ่งที่นักพัฒนาจำเป็นต้องรู้เกี่ยวกับการวิเคราะห์ประสิทธิภาพ HTML5

ความคิดเห็น: บทความต่อไปนี้เขียนโดยช่างเทคนิคไอทีชื่อจางลิมิงและเผยแพร่บนเว็บเพจ InfoQ เวลานี้เขาวิเคราะห์ประสิทธิภาพของ HTML5 จาก 9 ด้านที่แตกต่างกันในข้อความเต็มซึ่งยังคงคุ้มค่าที่จะอ่านโดยนักพัฒนาที่เกี่ยวข้อง

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

ประการที่สองการประกาศการเข้ารหัสเอกสารนั้นง่ายมากถ้าอยู่ใน HTML5 หลายคนถามว่า HTML5 คืออะไร? เราบอกว่าวิธีที่เราสามารถใช้ HTML5 ก่อนคือการเปลี่ยน doctype ก่อนเพราะหลายหน้ายังคงอยู่ในแบบดั้งเดิม วิธี HTML5 เข้ากันได้กับเบราว์เซอร์ IE และสามารถใช้งานได้จาก IE6 ถึง IE10 และสามารถรองรับได้โดยเบราว์เซอร์ขั้นสูง ดังนั้นวิธีที่ง่ายที่สุดในการยอมรับ HTML5 คือการเปลี่ยน Doctype

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

การประกาศแอตทริบิวต์แท็ก HTML5 รองรับสามวิธี: วงเล็บเดี่ยววงเล็บคู่และวงเล็บที่ไม่ได้รับการรับรอง เพื่อลดขนาดของเอกสารฉันเลือกวิธีการที่ไม่มีคำพูดสองเท่าหรือราคาเดียว อย่างไรก็ตามควรสังเกตว่าสมมติว่าเป็นการประกาศของแอตทริบิวต์คลาสเนื่องจากแอตทริบิวต์อาจรวมถึงหลายคลาสและเมื่อหลายชั้นเรียนพวกเขาจะต้องปิดล้อมในวงเล็บ ในเรื่องนี้ให้ฉันแสดงให้คุณเห็นถึงการฝึกฝนของ Google Google เองมีหน้าเว็บที่ปฏิบัติอย่างสมบูรณ์ข้างต้นลดขนาดของเอกสารลง 20%ลดการถ่ายโอนเอกสาร HTML ลง 20% หากมีการฝึกฝนทั้งหมดมันสามารถลดลงระหว่าง 5% ถึง 20% นี่เป็นขั้นตอนแรกลดขนาดของเอกสาร HTML

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

อีกแนวคิดหนึ่งของการเพิ่มประสิทธิภาพภาพคือ: ไม่มีภาพ ละทิ้งรูปภาพและโอบกอด CSS3 ในขั้นต้นฉันต้องตั้งค่าภาพที่มีเอฟเฟกต์มุมโค้งมน แต่ตอนนี้ฉันใช้แบล็กเรดิอุสใน CSS3; ฉันใช้รูปภาพที่มีเอฟเฟกต์เงา แต่ตอนนี้ฉันใช้ Box-Shadow ใน CSS3; ฉันเคยตั้งค่าภาพพื้นหลังการไล่ระดับสี แต่ตอนนี้ฉันใช้การไล่ระดับสีใน CSS3

3. ก่อนดึงข้อมูล

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

มีสองส่วนสำหรับการดึงข้อมูลล่วงหน้า: หนึ่งคือการดึงทรัพยากรล่วงหน้าและอีกส่วนหนึ่งคือการแก้ปัญหาก่อนของ DNS

มีหลายจุดที่ควรทราบเมื่อทรัพยากรล่วงหน้า:

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

Chrome ไม่รองรับการโหลดทรัพยากร HTTPS ล่วงหน้า ตัวอย่างเช่น Alipay เป็นหน้า HTTPS, Chrome จะไม่ดึงล่วงหน้า

แม้ว่าหน้าเว็บที่ถูกดึงออกมาไม่สามารถมองเห็นได้หลังจากที่มันมีอยู่ แต่ก็สามารถแยกวิเคราะห์ได้ตามปกติ หากฉันดึงหน้าเข้าสู่ระบบล่วงหน้าหน้าเข้าสู่ระบบมีทรัพยากรมากมายเช่นรูปภาพไฟล์ CSS และไฟล์ JS มันจะถูกแยกวิเคราะห์จากบนลงล่างตามปกติ ในระหว่างกระบวนการแยกวิเคราะห์หน้านี้ไม่ปรากฏ แต่มีอยู่จริง ใน HTML5 คุณสามารถรับสถานะหน้าปัจจุบันผ่าน document.visibilityState โดยปกติแล้วหน้าจะมีสองรัฐที่มองเห็นได้และมองไม่เห็น แต่ตอนนี้มีสถานะใหม่ที่เรียกว่าสถานะการเรนเดอร์ก่อน คุณสามารถตรวจสอบได้โดยตรงว่าหน้านั้นอยู่ในสถานะ PRERENDER หรือไม่โดย Document.VisibilityState เท่ากับ PRERENDER หรือไม่

4.Dns ความละเอียด

ถัดไปคือความละเอียดของ DNS บางครั้งเมื่อเราเข้าสู่หน้าเว็บมันค่อนข้างยากที่จะตรวจพบตำแหน่งที่ผู้ใช้อาจคลิก แน่นอนว่าบางครั้งเราจะทำคะแนนฝังเพื่อค้นหาว่าพฤติกรรมต่อไปของผู้ใช้ส่วนใหญ่จะเข้ามา แต่ในบางกรณีเราไม่ทราบว่าหน้าใดที่ผู้ใช้จะไปต่อไป แต่เรารู้ว่าเขาจะไปโดเมนใด ในเวลานี้ฉันสามารถ pre-parse DNS ได้ เพราะในความเป็นจริงมีกระบวนการแก้ไข DNS ที่ยาวนานในกระบวนการขอหน้าทั้งหมด หากเราทำสิ่งนี้ล่วงหน้าเราสามารถให้ผู้ใช้ดูหน้านี้เพิ่มเติมได้

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

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

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

ถัดไปพูดคุยเกี่ยวกับประโยชน์ของการจัดเก็บออฟไลน์กับผู้ใช้ในแง่ของประสิทธิภาพ ก่อนอื่นไฟล์นิยามจะถูกป้อนที่เก็บข้อมูลออฟไลน์ โมดูลระบบทั้งหมดใน Q+ มีการสนับสนุนออฟไลน์นิยาม กล่าวคือหากแอปพลิเคชันทั้งหมดถูกตัดการเชื่อมต่อพวกเขายังสามารถใช้งานได้ เพิ่มไฟล์รายการลงในเอกสาร Manifest เป็นไฟล์นิยามที่ประกาศว่าต้องจัดเก็บหน้าเว็บใดในเครื่อง? คนไหนไม่จำเป็นต้องเก็บไว้? ควรเปลี่ยนคนไหนหากคำขอล้มเหลว? สิ่งนี้แบ่งออกเป็นสามส่วน:

อันดับแรกแคชซึ่งจำเป็นต้องจัดเก็บในพื้นที่

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

ประการที่สามทางเลือก หากรูปภาพล้มเหลวมันคือ 404 ดังนั้นควรใช้รูปภาพอะไรแทน? ฉันคิดว่ามันสนุกกว่า

จะตั้งค่า maeifest ได้อย่างไร? มีสามสิ่งที่ควรทราบเกี่ยวกับรายการ:

ข้อ จำกัด ที่คล้ายคลึงกันอย่างชัดเจน;

ประเภท MIME จะต้องเป็นข้อความ/แคช-manifest ซึ่งเป็นมาตรฐานและจะไม่มีผลถ้ามันอยู่ในรูปแบบอื่น

Chrome หากคุณต้องการดูว่าสิ่งนี้มีผลหรือไม่คุณสามารถป้อนในเบราว์เซอร์ผ่าน Chrome Pseudo-Protocol, Chrome: // AppCache-internals

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

ผู้ใช้สามารถล้างแคชของเบราว์เซอร์ด้วยตนเองและที่เก็บข้อมูลท้องถิ่นจะถูกล้างโดยอัตโนมัติในเวลานี้

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

ดำเนินการผ่านโปรแกรมและโปรแกรมคือ window.applicationcache.update () หมายความว่าฉันต้องการใช้ที่เก็บข้อมูลออฟไลน์ ในความเป็นจริงบางครั้งฉันเรียกมันว่าที่เก็บข้อมูลแอปพลิเคชันเพราะความหมายของมันคือที่เก็บข้อมูลแอปพลิเคชัน เราไปอัปเดตที่เก็บแอปพลิเคชันด้วยตนเอง

6. Web Worker

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

ก่อนอื่นให้ฉันแนะนำการทำงานทางเว็บคืออะไร? มันเป็นเธรดระดับปฏิบัติการ ก่อนหน้านี้เราเลียนแบบมัลติเธรด แต่ในความเป็นจริงเราเปิดหน้าต่างอีกหนึ่งหน้าต่าง แต่ตอนนี้เบราว์เซอร์นั้นให้บริการซึ่งจะนำมาซึ่งความสะดวกในการดำเนินการและเป็นวิธีที่จะทำให้เอกสารทั้งหมดของเราหนักขึ้นและไม่แนะนำ

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

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

8. แบตเตอรี่

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

9.Canvas

ถัดไปคือผ้าใบ มาพูดคุยเกี่ยวกับจุดเพิ่มประสิทธิภาพการทำงานหลายจุดของผืนผ้าใบ หากคุณใช้สิ่งเหล่านี้ประสิทธิภาพจะได้รับการปรับปรุง 10 ครั้ง

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

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

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