wechatVideoExample
1.0.0
ทดสอบซอร์สโค้ดสำหรับการเล่นวิดีโอบน WeChat: เนื่องจาก WeChat ใช้เบราว์เซอร์ X5 จึงเกิดปัญหาแปลก ๆ มากมายเมื่อใช้แท็กวิดีโอเพื่อเล่นวิดีโอ ซอร์สโค้ดนี้เป็นซอร์สโค้ดเบื้องต้นที่สร้างขึ้นในกระบวนการแก้ไขปัญหานี้ ประกอบด้วยกรณีทดสอบต่างๆ เช่น การใช้ Canvas ในการเล่นวิดีโอ การใช้รูปภาพในการเล่นวิดีโอ การใช้แท็ก x5 เป็นต้น ไลบรารีซอร์สโค้ดที่มีอยู่นี้สามารถเก็บรักษาไว้ได้ และนักเรียนที่สนใจสามารถดาวน์โหลดได้ด้วยตนเอง
###หลังจากดาวน์โหลดบทนำแล้ว ให้สร้างไดเร็กทอรีใหม่บนโฮสต์และคัดลอกซอร์สโค้ดทั้งหมดไปยังไดเร็กทอรีนี้ ใช้เบราว์เซอร์ WeChat เพื่อเข้าถึงหน้า html ภายในเพื่อทดสอบ
ผู้เขียน chenjsh36 Ant Financial Data Experience Technology Team
ด้วยการมาถึงของยุคการรับส่งข้อมูลและการปรับปรุงเทคโนโลยีฮาร์ดแวร์ เว็บไซต์จำนวนมากขึ้นหวังว่าจะเล่นวิดีโอของตนเองบนพีซีหรือเทอร์มินัลมือถือ การปรับปรุงความเข้ากันได้ของ <video> อย่างค่อยเป็นค่อยไปทำให้นักพัฒนาเต็มใจที่จะใช้งานวิดีโอมากขึ้น สถานการณ์การเล่น
บทความนี้แสดงรายการสถานการณ์ทั่วไปสำหรับการเล่นวิดีโอและข้อผิดพลาดที่พบในแต่ละสถานการณ์เป็นหลัก หวังว่าจะช่วยให้นักพัฒนาเลือกโซลูชันทางเทคนิคที่เหมาะสมได้รวดเร็วยิ่งขึ้น และลดข้อผิดพลาดเมื่อเผชิญกับการพัฒนาความต้องการ__
แอตทริบิวต์บูลีน เล่นอัตโนมัติ เมื่อระบุ วิดีโอจะเริ่มเล่นโดยอัตโนมัติทันทีและจะไม่หยุดรอการโหลดข้อมูล
การเล่นวิดีโออัตโนมัติสามารถเล่นวิดีโอโดยอัตโนมัติเมื่อเปิดเพจและมีการโหลดทรัพยากรเพียงพอ ซึ่งช่วยลดการโต้ตอบของการคลิกของผู้ใช้เพียงครั้งเดียว นอกจากนี้ยังสามารถนำไปใช้กับพื้นหลังแบบไดนามิกและฟังก์ชันการโทรวิดีโอเลียนแบบ H5 อย่างไรก็ตาม ด้วยเหตุผลหลายประการ การเล่นอัตโนมัติจึงมีระดับข้อจำกัดที่แตกต่างกันทั้งบนพีซีและเทอร์มินัลมือถือ
ในช่วงแรกๆ ต้องใช้แท็กวิดีโอท่าทางของผู้ใช้ในการเล่น โดย เริ่ม ตั้งแต่เวอร์ชัน 10 กฎวิดีโอได้รับการแก้ไข และ Apple ได้ผ่อนคลาย กลยุทธ์การเล่นแบบอินไลน์และอัตโนมัติดังนี้ (ใช้ได้กับเบราว์เซอร์ Safari เท่านั้น):
<video> จะได้รับอนุญาตให้ autoplay โดยไม่ต้องใช้ท่าทางของผู้ใช้หากสื่อต้นทางไม่มีแทร็กเสียง (องค์ประกอบวิดีโอที่ไม่มีแหล่งที่มาของเสียงอนุญาตให้เล่นอัตโนมัติ)<video muted> จะได้รับอนุญาตให้เล่นอัตโนมัติโดยไม่ต้องใช้ท่าทางของผู้ใช้<video> ได้รับแทร็กเสียงหรือเปิดเสียงโดยไม่มีท่าทางสัมผัสของผู้ใช้ การเล่นจะหยุดชั่วคราว<video autoplay> จะเริ่มเล่นเมื่อมองเห็นได้บนหน้าจอเท่านั้น เช่น เมื่อเลื่อนเข้าไปในวิวพอร์ต ทำให้มองเห็นได้ผ่าน CSS และแทรกลงใน DOM (องค์ประกอบวิดีโอจะเริ่มเล่นเมื่อมองเห็นได้บนหน้าจอเท่านั้น)<video autoplay> จะหยุดชั่วคราวหากมองไม่เห็น เช่น โดยการเลื่อนออกจากวิวพอร์ต __Early__ ต้องใช้ท่าทางสัมผัสของผู้ใช้ในการเล่น Chrome 53 ของ Android ได้ผ่อนปรนนโยบายการเล่นอัตโนมัติในภายหลัง นโยบายนี้แตกต่างจาก Safari ของ iOS จำเป็นต้องตั้งค่า การเล่นอัตโนมัติ และ ปิดเสียง (ไม่ว่าจะปิดเสียงอยู่) บนวิดีโอในเวลาเดียวกันเพื่อให้อนุญาตโดยอัตโนมัติ การเล่น __FireFox และ UC Browser ของ Android__ รองรับการเล่นอัตโนมัติไม่ว่าในกรณีใด ๆ สถานการณ์ของเบราว์เซอร์ Android อื่น ๆ ยังไม่ชัดเจน
ในช่วงแรกๆ รองรับการเล่นอัตโนมัติ แต่เมื่อเร็วๆ นี้ Safari และ Chrome ได้ปรับเปลี่ยนกลยุทธ์การเล่นอัตโนมัติอย่างต่อเนื่อง...
__Safari 10 และใหม่กว่า__วิดีโอและเสียงจะถูกปิดใช้งานโดยค่าเริ่มต้นจากการเล่นอัตโนมัติ สำหรับข้อมูลเพิ่มเติม โปรดดูที่บทความนี้
เล่นอัตโนมัติภายใต้ Chrome (เวอร์ชันเก่า):
Safari (โพสต์ 10) ไม่เล่นโดยอัตโนมัติ:
วิดีโอที่มีเสียงจะถูกเล่นโดยอัตโนมัติตาม __ดัชนีการมีส่วนร่วมของสื่อ__ แล้วดัชนีการมีส่วนร่วมของสื่อคืออะไร คำอธิบายอย่างเป็นทางการและมิติข้อมูลที่เกี่ยวข้องมีดังนี้:
MEI เป็นดัชนีที่ประเมินการมีส่วนร่วมของสื่อของผู้ใช้บนเว็บไซต์ปัจจุบัน โดยขึ้นอยู่กับมิติข้อมูลต่อไปนี้:
- ผู้ใช้อยู่บนสื่อนานกว่า 7 วินาที
- ต้องแสดงเสียงและไม่ปิดเสียง
- โต้ตอบกับวิดีโอ
- ขนาดของสื่อต้องไม่เล็กกว่า 200x140
หลังจากอ่านข้อความนี้แล้ว ความเห็นของผู้พัฒนามีดังนี้:
โชคดีที่ทั้ง Safari และ Chrome แม้จะจำกัดการเล่นอัตโนมัติ แต่ก็มีกลไกในการตรวจสอบว่าวิดีโอสามารถเล่นโดยอัตโนมัติได้หรือไม่ เพื่อให้นักพัฒนามีทางเลือกอื่นเมื่อพบว่าไม่สามารถเล่นอัตโนมัติได้:
var promise = document.querySelector('video').play();
if (promise !== undefined) {
promise.catch(error => {
// Auto-play was prevented
// Show a UI element to let the user manually start playback
}).then(() => {
// Auto-play started
});
}
เนื่องจากอาจก่อกวน หิวข้อมูล และผู้ใช้จำนวนมากไม่ชอบ ( เนื่องจากอาจก่อกวน หิวข้อมูล และผู้ใช้จำนวนมากไม่ชอบ)
ฉันพบว่า H5 ที่เล่นโดยอัตโนมัติมักจะเห็นได้บน WeChat อย่างไรก็ตาม ตัวอย่างการเล่นวิดีโอที่เขียนโดยผู้เขียนที่มีการเล่นอัตโนมัติและเล่นแบบอินไลน์ยังคงไม่สามารถเล่นได้โดยอัตโนมัติบน WeChat แต่สามารถเล่นได้โดยอัตโนมัติบน DingTalk
| ระบบ-เบราว์เซอร์ | พร้อมเสียง | โดยไม่มีเสียง |
|---|---|---|
| ไอโอเอส DingTalk | สนับสนุน | สนับสนุน |
| ไอโอเอส ซาฟารี | ห้าม | เล่นอัตโนมัติ |
| ไอโอเอส วีแชท | ห้าม | ห้าม |
จากการสืบค้นข้อมูล การพัฒนา IOS WebAPP จะขึ้นอยู่กับเคอร์เนลของเบราว์เซอร์ที่ IOS จัดเตรียมไว้ ดังนั้นประสิทธิภาพของการเล่นอัตโนมัติจึงสามารถแก้ไขได้ใน webview ของ WebAPP อย่างเห็นได้ชัด รองรับการเล่นอัตโนมัติ ในขณะที่ WeChat ห้ามการเล่นอัตโนมัติ แต่มีในตัว กิจกรรมที่รองรับการเล่นอัตโนมัติ:
เล่นอัตโนมัติผ่านเหตุการณ์ WeixinJSBridgeReady ภายใต้ WeChat:
document . addEventListener (
'WeixinJSBridgeReady' ,
function ( ) {
video . play ( ) ;
} ,
false
) ; ในเบราว์เซอร์มือถือ เมื่อผู้ใช้คลิกเพื่อเล่นหรือทริกเกอร์การเล่นผ่าน API video.play() วิดีโอจะถูกบังคับให้เล่นแบบเต็มหน้าจอที่ด้านบน ประสบการณ์การใช้งานที่ดีขึ้น แต่ก็มีบางครั้งนักพัฒนาที่ต้องการควบคุมว่าจะให้เต็มหน้าจอเพื่อตอบสนองความต้องการอื่นๆ หรือไม่
หากคุณต้องการเล่นแบบเต็มหน้าจอ เพียงเพิ่มแอตทริบิวต์ playinline ให้กับแท็กวิดีโอ โดยทั่วไปแล้วแอตทริบิวต์นี้จะไม่มีปัญหาในเบราว์เซอร์มือถือที่ใช้เคอร์เนล webkit หากไม่ได้ผล เพียงเพิ่ม webkit-playsinline :
< video
src = {videoUrl}
webkit-playsinline =" true "
playsinline =" true "
/>แล้วจะจัดการกับเบราว์เซอร์กับเคอร์เนลอื่นได้อย่างไร? ในเวลานี้ คุณต้องเข้าใจว่าปัจจุบันมีเบราว์เซอร์ใดบ้างในตลาด
ก่อนอื่น คุณต้องรู้คอร์เบราว์เซอร์สี่คอร์ในปัจจุบันในโลก:
ใน:
เบราว์เซอร์พีซีในประเทศทั่วไป เช่น UC Browser, QQ Browser, Baidu Mobile Browser, 360 Secure Browser, Google Chrome, Sogou Mobile Browser, Cheetah Browser และ UC, QQ, Baidu และเบราว์เซอร์มือถืออื่นๆ มีการแก้ไขเคอร์เนลตาม Webkit เราคิดว่าผู้ใช้มือถือในตลาดโดยทั่วไปใช้เคอร์เนลของ webkit หรือเบราว์เซอร์ที่ดัดแปลงตามเคอร์เนลของ webkit ดังนั้นความเข้ากันได้ของ playinline จึงดีมาก!
องค์ประกอบวิดีโอมีเหตุการณ์ด้านพฤติกรรมหลายอย่างสำหรับนักพัฒนาในการควบคุมการเล่นวิดีโอ เหตุการณ์ที่มีความเข้ากันได้ดี ได้แก่ onended , __ontimeupdate, onplay, onplaying ฯลฯ __เหตุการณ์บางอย่างทำงานไม่สอดคล้องกันในเบราว์เซอร์ที่แตกต่างกันและอุปกรณ์ที่แตกต่างกัน
ตัวอย่างเช่น: การตรวจสอบ ' canplay ' ภายใต้ iOS (ไม่ว่าจะมีข้อมูลเพียงพอสำหรับการเล่นที่ราบรื่นหรือไม่) จะไม่ถูกทริกเกอร์เมื่อโหลด แม้ว่า __preload="auto" __ จะไม่มีประโยชน์ แต่ใน Chrome debugger บนพีซี Next จะเป็น เกิดขึ้นในระหว่างขั้นตอนการโหลด ต้องเล่น ios ก่อนถึงจะรันได้
การโหลดเสร็จสมบูรณ์:
คลิกเพื่อเล่น:
การโหลดเสร็จสมบูรณ์:
คลิกเพื่อเล่น
การโหลดเสร็จสมบูรณ์:
คลิกเพื่อเล่น:
เหตุการณ์บางอย่างมีลักษณะการแสดงผลที่ไม่สอดคล้องกันภายใต้ระบบ อุปกรณ์ และเบราว์เซอร์ที่แตกต่างกัน ดังนั้นควรระมัดระวังในการใช้งาน
เมื่อเพิ่มการควบคุมให้กับแอตทริบิวต์นี้ Gecko จะให้การควบคุมแก่ผู้ใช้ โดยอนุญาตให้ผู้ใช้ควบคุมการเล่นวิดีโอ รวมถึงระดับเสียง การข้ามเฟรม และการหยุดชั่วคราว/เล่นต่อ
แอตทริบิวต์การควบคุมระบุว่าเบราว์เซอร์ควรมีการควบคุมการเล่นสำหรับวิดีโอ มิฉะนั้นการควบคุมการเล่นจะถูกซ่อนไว้ เพื่อให้นักพัฒนาสามารถปรับแต่งการควบคุมการเล่นของตนเองได้ การซ่อนการควบคุมการเล่นมีความเข้ากันได้ดีบน พีซีและเทอร์มินัลมือถือ IOS อย่างไรก็ตาม ไม่รองรับการควบคุมการซ่อนบนเทอร์มินัลมือถือ Android แต่ยังคงสามารถทำได้ผ่านวิธีการบางอย่าง
วิธีการแฮ็กที่มากกว่าคือการขยายวิดีโอและย้ายแถบควบคุมออกจากมุมมองเพื่อให้ได้เอฟเฟกต์ที่ซ่อนอยู่! ในความเป็นจริง องค์ประกอบวิดีโอถูกทำให้มีขนาดใหญ่กว่าคอนเทนเนอร์หลัก ดังนั้นแถบควบคุมด้านล่างจะอยู่นอกคอนเทนเนอร์หลัก จากนั้นคอนเทนเนอร์หลักจะถูกตั้งค่าเป็น: ล้น: ซ่อนไว้ วิธีการซ่อนตัวควบคุมการเล่น! ข้อเสียคือวิดีโอจะขยายใหญ่ขึ้น และคุณต้องเว้นที่ว่างไว้ล่วงหน้าเพื่อขยาย
ทีมงานเคอร์เนล x5 ของทีม Android ของ Tencent ได้ผ่อนคลายข้อจำกัดในการเล่นวิดีโอ วิดีโอไม่จำเป็นต้องเรียกโปรแกรมเล่นวิดีโอที่ได้รับการวิพากษ์วิจารณ์มากนัก พวกเขาใช้ แอตทริบิวต์ __x5-video-player-type="h5" เพื่อซ่อนองค์ประกอบการควบคุมและที่ ในเวลาเดียวกัน __ วิดีโอไม่ได้อยู่ด้านบนอีกต่อไป ทำให้องค์ประกอบอื่นๆ ลอยอยู่ด้านบนได้
หลังจากทำความเข้าใจสถานการณ์ทั่วไปและข้อผิดพลาดทั่วไปของการเล่นวิดีโอแล้ว เราก็สามารถปรับปรุงประสบการณ์ผู้ใช้ด้วยการจัดหาโซลูชันที่สอดคล้องกันสำหรับสถานการณ์ที่แตกต่างกัน ตัวอย่างเช่น หน้า H5 ที่เล่นบนเทอร์มินัลมือถือโดยอัตโนมัติสามารถกระตุ้นการเล่นวิดีโอโดยอ้อมโดยแนะนำให้ผู้ใช้คลิกหรือเลื่อน นี่เป็นแนวทางที่อนุรักษ์นิยมที่สุด ไม่มีข้อบกพร่อง! วิธีแก้ปัญหาที่ดีกว่าคือการเล่นโดยอัตโนมัติตามค่าเริ่มต้นและจับภาพสถานการณ์ที่ห้ามเล่น จากนั้นแนะนำให้ผู้ใช้โต้ตอบเพื่อให้ได้เล่นวิดีโอ
ใช้วิดีโอ ในช่วงแรกๆ การเล่นวิดีโอถูกจำกัดอย่างรุนแรงบนเทอร์มินัลมือถือ เนื่องจากเกี่ยวข้องกับการใช้ประสิทธิภาพสูง ปริมาณการใช้ข้อมูลสูง และการพิจารณาประสบการณ์ผู้ใช้ อย่างไรก็ตาม ด้วยการปรับปรุงประสิทธิภาพของโทรศัพท์มือถือ การมาถึงของยุคการรับส่งข้อมูล และฉากที่แข็งแกร่งยิ่งขึ้น ข้อกำหนด ข้อจำกัดต่างๆ ค่อยๆ ผ่อนคลาย ในขณะที่ฝั่งพีซีก็ค่อยๆ คลายลง จาก "รุ่นที่หลวม" ไปสู่ "รุ่นที่แน่นหนา" ทีละน้อย ทั้งสองจะอัปเดตกลยุทธ์อย่างต่อเนื่องเพื่อให้ผู้ใช้ได้รับประสบการณ์ที่ดีขึ้น ในอนาคต พวกเขาอาจกลายเป็นหนึ่งเดียวกัน และนักพัฒนาสามารถเริ่มต้นจากการปรับความเข้ากันได้พื้นฐาน . ปล่อยมันเพื่อให้คุณมีพลังงานมากขึ้นในการทำงานระดับสูงขึ้น
หากคุณสนใจทีมงานของเรา คุณสามารถติดตามคอลัมน์ ติดตาม github หรือส่งเรซูเม่ของคุณไปที่ 'tao.qit####alibaba-inc.com'.replace('####', '@') ใครมีอุดมคติสูงส่งก็เข้าร่วมได้นะ~
ที่อยู่เดิม: https://github.com/ProtoTeam/blog/blob/master/201806/1.md
