Milliseconds Make Millions: วิธีการและทําไมจะเร่งแอปของคุณจาก Playbook ของ InDrive

สวัสดีทุกคนชื่อของฉันคือ Vladimir Pchelyakov ฉันเป็นวิศวกร iOS ที่ inDrive ในบทความนี้ฉันจะพูดคุยเกี่ยวกับวิธีการเริ่มต้นเวลาของแอปส่งผลกระทบต่อรายได้ของ บริษัท วิธีการเร่งแอปของเราและฉันจะครอบคลุมเครื่องมือวิธีการเช่นเดียวกับสถานการณ์จริงและแน่นอนผลลัพธ์ บทความนี้สามารถทําหน้าที่เป็นแผนสําหรับทีมใด ๆ ที่ต้องการเร่งเวลาในการเปิดใช้งานแอพและเส้นทางสําคัญของผู้ใช้เพราะปัญหาที่เราแก้ไขมากที่สุดอาจมีอยู่ในโครงการที่ไม่ดีที่สุด สําหรับบรรทัดฐานในแอป inDrive คุณสามารถสั่งซื้อรถแท็กซี่ในฐานะผู้โดยสารหรือคุณสามารถรับคําสั่งซื้อและเดินทางเป็นคนขับรถ ในบทความนี้ฉันจะครอบคลุม: เวลาเริ่มต้นมีผลต่อรายได้ของ บริษัท ประเภทการเปิดตัว app App Launch Time, TTI และ Hang Time ค่าเฉลี่ยและเปอร์เซ็นต์ สิ่งที่ส่งผลกระทบต่อเวลาเริ่มต้น App Acceleration วงจร วิธีที่มีประสิทธิภาพที่สุดในการเร่งความเร็ว เครื่องมือกระบวนการสถานการณ์ ผล เวลาเริ่มต้นมีอิทธิพลต่อรายได้ของ บริษัท คนส่วนใหญ่คิดว่านักพัฒนามีความมึนงใจเกินไปกับการเพิ่มประสิทธิภาพที่ไม่ได้มีค่าจริง แต่ข้อมูลแสดงให้เห็นว่าการเพิ่มความเร็วของสิ่งต่าง ๆ ในหลายร้อยมิลลิสวินาทีสามารถส่งผลกระทบต่อธุรกิจได้เกือบเท่ากับการเปิดตัวคุณลักษณะใหม่หรือเข้าสู่ตลาดใหม่ ได้อย่างง่ายดายถ้าแอปของคุณใช้เวลานานเกินไปในการเปิดใช้งานผู้ใช้บางคนจะไปหาคู่แข่งหรือเพียงแค่ทิ้งความต้องการของพวกเขา การวิจัย inDrive ภายใน บริษัท เราดําเนินการการศึกษาขนาดใหญ่ซึ่งแสดงให้เห็นว่าการเร่งเส้นทางสําคัญของผู้โดยสารด้วย 750 มม. เพิ่มจํานวนคําสั่งซื้อด้วย 1.5% หากแอปของคุณมีล้านคําสั่งซื้อเพียงเพราะแอปเริ่มแสดงอินเตอร์เฟซเร็วขึ้นคุณจะได้รับสิบหรือแม้กระทั่งหลายร้อยพันคําสั่งซื้อเพิ่มเติมต่อวัน! การวิจัย Deloitte Deloitte ได้เผยแพร่ตัวเลขที่น่าประทับใจมาก: การเร่งเว็บไซต์มือถือด้วย 100 มิลลิเมตรให้ +8.5% การแปลงในอีคอมเมิร์ซและ +10% ในการเดินทาง หมายเลขดูยอดเยี่ยม แต่นี่คือ Deloitte และไม่มีเหตุผลที่จะสงสัยเกี่ยวกับความเชี่ยวชาญของพวกเขา นอกจากนี้บาง บริษัท ได้ชะลอแอปพลิเคชันสําหรับกลุ่มผู้ใช้บางอย่างเพื่อพิสูจน์ข้อพิสูจน์: การเปิดตัวแอปพลิเคชันเร็วขึ้นผู้ใช้จะทําคําสั่งมากขึ้น และข้อพิสูจน์นี้ได้รับการยืนยัน หากคุณเคยต้องการทํางานเพื่อเร่งแอปพลิเคชัน แต่ไม่ได้มีข้อพิพากษาที่แข็งแกร่งตอนนี้คุณมีพวกเขา เวลาเริ่มต้นมีผลต่อรายได้ของ บริษัท โดยตรง ประเภทการเปิดตัว App ประเภทของการเปิดตัวแอปมีผลต่อเมตริกโดยตรงดังนั้นจึงเป็นสิ่งสําคัญที่จะบอกพวกเขาแยกต่างหาก แอปเปิ้ลไม่ได้ให้ API โดยตรงสําหรับการกําหนดประเภทการเปิดตัวดังนั้นแต่ละทีมทําตามวิธีของตัวเอง การเปิดตัวเย็น การโหลดแอพพลิเคชันอย่างเต็มที่จากจุดเริ่มต้นประเภทการเปิดตัวที่ช้าที่สุด กระบวนการแอพพลิเคชันไม่ได้มีแคชไม่มีทุกอย่างได้รับการเริ่มต้นจากจุดเริ่มต้น ตัวอย่างเช่นนี่คือการเปิดตัวครั้งแรกหลังจากดาวน์โหลดจากร้านค้าหรือหลังจากไม่กี่ชั่วโมงหรือมากกว่าหลังจากที่แอพพลิเคชันถูกดาวน์โหลดจากหน่วยความจํา Cold Launch เป็นตัวชี้วัดที่ซื่อสัตย์เท่านั้นที่สามารถเปรียบเทียบได้จากรุ่นต่อรุ่นเพื่อให้ได้ข้อสรุป ในบทความนี้การวัดทั้งหมดจะดําเนินการเฉพาะกับ Cold Launches การเปิดตัวความร้อน แอปพลิเคชันได้รับการยกเลิกเมื่อเร็ว ๆ นี้ดังนั้นจึงไม่มีกระบวนการ อย่างไรก็ตามบางส่วนของแอปพลิเคชันยังคงอยู่ในหน่วยความจํา - แชชชระบบและแคชตัวเชื่อมโยงแบบไดนามิกยังคงอบอุ่น ระบบต้องสร้างกระบวนการใหม่และรีไซเคิลระยะเวลาการทํางาน แต่ลืมส่วนใหญ่ของงาน I/O ที่จําเป็นในการเปิดตัวเย็นทําให้เร็วขึ้นอย่างเห็นได้ชัด นี้เกิดขึ้นเมื่อคุณดาวน์โหลดแอพจากหน่วยความจําและเปิดอีกครั้งเกือบทันทีมันจะเปิดได้เร็วขึ้นอย่างเห็นได้ชัด เมทริกี้ขึ้นอยู่กับปัจจัยจํานวนมากดังนั้นจึงไม่ทํางานสําหรับเรา การเปิดตัวร้อน แอปพลิเคชันถูกลดลงและเปิดอีกครั้ง ไม่มีอะไรที่จะวัดที่นี่แอปพลิเคชันจะเปิดทันทีและไม่ได้ผ่านทางใด ๆ มันอยู่แล้วในสถานที่ที่เหมาะสม ระบายความร้อน iOS ตัวเองเปิดตัวแอพพลิเคชันล่วงหน้า "ในพื้นหลัง" การคาดการณ์ว่าผู้ใช้จะเปิดแอพนี้เร็ว ๆ นี้ มันฟังดูเป็นประโยชน์ แต่ทําให้เกิดปัญหามากมาย: เรามี "การเปิดตัว" ของ 15 นาทีและ 10 ชั่วโมงเพราะ prewarm สร้างกระบวนการล่วงหน้าและเราคํานวณเวลาจากตัวแปรที่สร้างขึ้นในไฟล์หลักและผู้ใช้ไม่ได้เปิดตัวแอพพลิเคชันทันที แต่หลังจากหลายสิบชั่วโมง ในตอนแรกเราไม่สามารถเข้าใจว่าข้อผิดพลาดคือไหนและเวลาการเปิดตัวสามารถเท่ากับชั่วโมงได้อย่างไรและยังทําลายสถิติอย่างรุนแรงเนื่องจากข้อมูลอื่น ๆ จะวัดใน มิลลิเมตรและเมตริกที่มีชั่วโมงจริงๆทําลายภาพ ให้ความระมัดระวัง Prewarm สามารถทําลายสถิติอย่างสมบูรณ์ App Launch Time, TTI และ Hang Time เมื่อเราเริ่มทํางานเพื่อเร่งสิ่งต่าง ๆ มันปรากฏว่าแม้กระทั่งคําหลักจะเข้าใจแตกต่างกันโดยทุกคน ดังนั้นเราจึงต้องพัฒนาคําจํากัดความทั่วไป เวลาเปิดใช้งาน App เวลาตั้งแต่คลิกที่ไอคอนจนถึงการปรากฏตัวของกรอบแรกของตัวควบคุมการเปิดตัวของเรา สิ่งสําคัญ: นี่ไม่ใช่เรื่องหน้าจอการเปิดตัวของระบบซึ่งจะปรากฏทันที แต่เกี่ยวกับตัวควบคุมมุมมองรากของเรา - ขณะที่การเชื่อมโยงห้องสมุดเสร็จแล้ววิธีการ AppDelegate ได้เสร็จสิ้นตัวควบคุมมุมมองถูกสร้างขึ้นและวิธีการดูDidAppear ได้เปิดตัว TTI (Time To Interactive) เวลาตั้งแต่คลิกไอคอนแอพพลิเคชันจนถึงช่วงเวลาที่ผู้ใช้สามารถโต้ตอบกับแอพพลิเคชัน คุณยังสามารถเรียกได้ว่าเป็นเส้นทางที่สําคัญเพราะมันส่งผลกระทบต่อการเริ่มต้นการสร้างหรือประมวลผลคําสั่งซื้อและเป็นสิ่งที่ส่งผลต่อการวัดธุรกิจ เส้นทางนี้แตกต่างกันสําหรับแต่ละแอปเนื่องจากทุกคนมีจุดสิ้นสุดที่แตกต่างกันและได้รับการเลือกขึ้นอยู่กับผลกระทบของมันต่อธุรกิจ ตัวอย่างเช่นในกรณีของเรา: สําหรับผู้โดยสาร - เมื่อแผนที่ปรากฏและผู้ใช้สามารถคลิกที่ "ไปที่ที่ไหน" ยิ่งมันเกิดขึ้นผู้โดยสารจะสร้างคําสั่งซื้อมากขึ้น สําหรับคนขับรถ - เมื่อหน้าจอพร้อมคําสั่งผู้โดยสารจะปรากฏ ความเร็วที่เร็วขึ้นคนขับรถจะเห็นและดําเนินการตามคําสั่งในเวลา วางเวลา นี่คือช่วงเวลาที่อินเตอร์เฟซ "แช่แข็ง" - ปุ่มจะถูกกด แต่การกระทําไม่ได้เกิดขึ้นทันทีตัวอย่างเช่นมันใช้เวลาหนึ่งวินาที โดยปกติแล้วนี่เป็นผลมาจากการคํานวณหนักในหัวข้อหลัก และใช่เวลาแขวนส่งผลต่อ TTI โดยตรงเพราะการแช่แข็งปรากฏไม่เพียง แต่เมื่อผู้ใช้กดปุ่ม แต่ยังเมื่อบางสิ่งบางอย่างในเส้นทางที่สําคัญครอบครองหัวข้อหลักและอินเตอร์เฟซอินเทอร์เฟซแช่แข็งในระหว่างการ rendering ตัวอย่างเช่นหน้าจอเลื่อนออกไม่ใน 300 มิลลิเมตร แต่ในหนึ่งวินาที ค่าเฉลี่ยและเปอร์เซ็นต์ หลังจากเก็บรวบรวมข้อมูลจากผู้ใช้ล้านคุณต้องตีความตัวชี้วัดเหล่านี้และมีอย่างน้อย 2 ตัวเลือก: ค่าเฉลี่ยและเปอร์เซ็นต์ ทําไมค่าเฉลี่ยไม่ให้ภาพเต็มรูปแบบ อัตราเฉลี่ยดูเหมือนสะดวกและง่ายต่อการคํานวณ แต่บางครั้งมันเป็นเรื่องยากที่จะสรุปจากมัน นี่เป็นตัวอย่าง: เรามีผู้ใช้ 5 และเวลาเปิดตัวสําหรับผู้ใช้ 5 = 1, 2, 3, 9, 12 วินาที อัตราเฉลี่ย = 5.4 sec แต่สิ่งนี้ไม่สะท้อนถึงความเป็นจริง: 3 ใน 5 ผู้ใช้เปิดใช้งานแอพใน 3 วินาทีหรือเร็วขึ้น 2 ผู้ใช้มีความช้ามากและโค้งสถิติทั้งหมด และถ้าการเปิดตัวครั้งเดียวจะถูกบันทึกเป็น "1 ชั่วโมง" (หรือไม่มีที่สิ้นสุดเกิดขึ้นเนื่องจากข้อผิดพลาดเมตริก) อัตราเฉลี่ยจะกลายเป็นไม่มีความหมายอย่างสมบูรณ์ นี่คือที่เปอร์เซ็นต์มาเพื่อความช่วยเหลือ วิธีการทํางานของ Percentiles และทําไมพวกเขามีความแม่นยํามากขึ้น เปอร์เซ็นต์แสดงเวลาที่แอปพลิเคชันต้องใช้เพื่อให้ X เปอร์เซ็นต์ของผู้ใช้พอดีภายในเวลานี้ บน 5 ค่าเดียวกัน: 1, 2, 3, 9, 12 percentile 50 = 3 วินาที →ครึ่งหนึ่งของผู้ใช้เปิดใช้งานแอพใน 3 วินาทีหรือเร็วขึ้น percentile 80 = 9 วินาที → 80% ของผู้ใช้เห็นแอปพลิเคชันภายใน 9 วินาที percentile 99 = 12 วินาที → "หนักที่สุด" ผู้ใช้: อุปกรณ์ที่อ่อนแออินเทอร์เน็ตที่ไม่ดี เรามองไปที่ percentile 50th, 75th, 90th และ 95th นอกเหนือจากมวลผู้ใช้หลักเรามักจะพยายามเพิ่มความเร็วของ percentile 95th เพื่อปรับปรุงชีวิตสําหรับผู้ที่มีแอปโหลดเวลานานที่สุดซึ่งเป็นไปได้มากที่สุดเนื่องจากอุปกรณ์หรืออินเทอร์เน็ตที่ไม่ดีในประเทศของพวกเขา โดยวิธีการที่ฉันจะสังเกตเห็นว่าเรามีการดําเนินงานใน 47 ประเทศทั่วโลกและเรามีหลายประเทศที่มีผู้ใช้จํานวนมากมีอุปกรณ์ที่อ่อนแอและอินเทอร์เน็ตไม่เสถียร สิ่งที่ส่งผลกระทบต่อเวลาเริ่มต้น ลองดูพื้นที่หลักที่สามารถชะลอการใช้งานอย่างมีนัยสําคัญ เครือข่ายการร้องขอ จํานวนคําขอในโซ่ลําดับของคําขอความสามารถในการแคชความเร็วอินเทอร์เน็ต แอปพลิเคชันเริ่มต้น ในการเริ่มต้นการดําเนินงานจํานวนมากเกิดขึ้น: การเชื่อมโยงห้องสมุด, การเปิดตัว Objective-C Runtime, Swift Reflection, การเริ่มต้น SDK (การวิเคราะห์โฆษณา, Firebase), การโหลด dylib, dyld, rebase, การเชื่อมโยงสัญลักษณ์, การเริ่มต้นคอนเทนเนอร์ DI และทั้งหมดนี้เกิดขึ้นก่อนกรอบแรก ปัญหาหลัก การดําเนินงานที่หนักใด ๆ บนหัวข้อหลักเพิ่ม TTI: decoding JSON ของรุ่นขนาดใหญ่และซับซ้อนการโทรซิงโครนัสการคํานวณที่ไม่จําเป็น "เมื่อเริ่มต้น" เพราะมันสะดวกแม้ว่าพวกเขาสามารถย้ายไปยังที่อื่น คุณสมบัติของอุปกรณ์ เราไม่สามารถเร่งอุปกรณ์เก่าได้ แต่เราสามารถปรับความตรรกะให้เหมาะสมกับพวกเขาหรือลดปริมาณการโหลด ความจริงที่น่าสนใจ: สําหรับประเทศที่มีอุปกรณ์ที่อ่อนแอและอินเทอร์เน็ตช้า Meta ได้เปิดตัวแอพ Facebook Lite แอพ Facebook Lite ขนาดเล็กช่วยให้คุณประหยัดพื้นที่บนโทรศัพท์ของคุณและใช้ Facebook ในเงื่อนไข 2G App Acceleration วงจร เพื่อเพิ่มความเร็วในการใช้งานคุณต้องวัดและปรับปรุงอย่างมีระบบไม่ใช่“ แก้ไขสิ่งต่าง ๆ โดยตา” รอบของเราดูเหมือนนี้: Mark up the app for data collection App Launch Splash TTI of all verticals (critical paths) Steps of the critical path Collect and visualize data Raw telemetry data Long-term storage, Big Query จอภาพ Xcode Organizer Find places of slowdown Instruments: LaunchTime, Profile, Network, Hangs Timeline analysis Fix problems Restructure requests Cache Offload the main thread Remove everything unnecessary from startup การทดลอง เปรียบเทียบผลการตรวจสอบการคาดการณ์ Control startup time before a new release UI-performance tests on CI, alerts on degradations ด้วยวิธีนี้แอพพลิเคชันจะเร็วขึ้นมีเสถียรภาพและสามารถคาดการณ์ได้มากขึ้น โดยแน่นอนการทําเครื่องหมายและการแสดงผลไม่ได้ทําในแต่ละวงจร วิธีที่มีประสิทธิภาพที่สุดในการเพิ่มความเร็ว ผลที่ใหญ่ที่สุดมาจากการทําขั้นตอนที่ชัดเจน แต่เป็นระบบ: เปลี่ยนลําดับการร้องขอเครือข่าย คําขอเครือข่าย Caching ดาวน์โหลดหัวข้อหลัก การกําจัดการคํานวณหนักในสถานีเริ่มต้น นี่คือการเปลี่ยนแปลงที่ให้การปรับปรุง TTI สูงสุดด้วยความพยายามขั้นต่ําและความเสี่ยงในการทําลายบางสิ่งบางอย่าง ฉันขอแนะนําให้ทุกคนเริ่มต้นด้วยสิ่งนี้ Tools, Processes, Situations ในบทนี้ฉันจะบอกคุณเกี่ยวกับเครื่องมือของเราและเดินผ่านหลายตัวอย่างที่แท้จริงซึ่งฉันจะแสดงวิธีหนึ่งเครื่องมือเสริมอื่นและสิ่งที่แต่ละคนดูเหมือน การเพิ่มประสิทธิภาพเป็นไปไม่ได้โดยไม่มีการวัด ก่อนที่คุณต้องทําเครื่องหมายโครงการ ภายในแอปของเราขั้นตอนการเปิดตัวที่สําคัญจะถูกทําเครื่องหมาย: AppLaunchTracker – เปิดใช้งานแอพจนกว่าจะปรากฏตัวตัวควบคุมครั้งแรก SplashTracker - เวลาของขั้นตอนหน้าจอสเปรย์ที่แตกต่างกัน (ได้รับฟังก์ชั่นสลับโปรไฟล์การกําหนดตําแหน่ง) CriticalPathTracker – เส้นทางสําคัญของผู้ใช้พร้อมการแบ่งขั้นตอนและเวลาระหว่างพวกเขา VerticalsTTITracker - TTI สําหรับแต่ละผลิตภัณฑ์แนวตั้ง ข้อมูลทั้งหมดจะมองเห็นได้ในแผนภูมิและ dashboard (Kibana, Redash) นอกจากนี้เรายังได้สร้างกระบวนการ: การเปรียบเทียบรุ่นตามประสิทธิภาพ การทดสอบประสิทธิภาพ UI บน CI สัญญาณเตือนการลดลง การประชุมประจําสัปดาห์และแผนการทํางานเพื่อเร่งความเร็ว เราใช้เครื่องมือในประเทศ: Xcode Instruments — LaunchTime, โปรไฟล์, เครือข่าย, Hangs Xcode Organizer - Hangs, การเปิดตัวแอป ฉันยังขอแนะนําให้สร้างแผนที่เส้นทางเพื่อเข้าใจลําดับของการดําเนินการงาน ของเราดูดังนี้: ตอนนี้ให้ดูทุกอย่างในกิจกรรม การทํางานกับคําสั่งคําขอเครือข่าย หนึ่งในวิธีที่มีประสิทธิภาพที่สุดในการเร่ง TTI คือการจัดเรียงลําดับของคําขอเครือข่ายและเรียกใช้คําขออิสระใน paralel สําหรับการวิเคราะห์เราใช้ Xcode Instruments → เครือข่ายซึ่งคุณสามารถดูได้อย่างชัดเจนคําขอใดไปและความสัมพันธ์ของพวกเขา นี่คือเร็วกว่าการขุดผ่านรหัสฐาน สิ่งที่เราทํา: ran the specific flow จับติดตามการร้องขอเครือข่าย เคลือบช่วงเวลาที่หน้าจอปรากฏบนมัน ด้วยวิธีนี้มันกลายเป็นที่ชัดเจนว่าคําขอใดในความเป็นจริงบล็อกการแสดง UI จากนั้นเราไปที่ทีมผลิตภัณฑ์แสดงผลการพูดคุยเกี่ยวกับวิธีการเพิ่มลําดับของคําขอเครือข่ายแล้วสร้างงาน กรณีที่ง่าย คําขอที่หน้าจอแรกขึ้นอยู่กับถูกส่งมาช้าเกินไป มันสามารถเคลื่อนย้ายไปยังจุดเริ่มต้นของวงจรชีวิตหน้าจอเพราะมันไม่ได้มีความเสี่ยง ดังนั้นผู้ใช้จะเห็นอินเทอร์เฟซที่พร้อมใช้งานเร็วขึ้นซึ่งหมายความว่า TTI ได้เร็วขึ้น บน Android เราพบ "บันได" คลาสสิค: toggles → driver config → reasons → offers คําขอทั้งหมดไปอย่างเคร่งครัด เพียงหลังจากนั้นการโหลดคําสั่งเริ่มขึ้น การแก้ปัญหา: รวมคําขอหลายคําขอเป็นหนึ่งหรือเรียกใช้คําขอใน paralel ถ้าไม่มีความเสี่ยง วิธีที่ง่ายที่สุดและมีประสิทธิภาพที่สุดคือการลบลําดับเทียมที่มันไม่จําเป็น มีโอกาสที่นักพัฒนาเขียนลําดับนี้เป็นเวลานาน่อนเพื่อความสะดวกสบายหรือเหตุผลอื่น ๆ และก็ยังคงอยู่ดังนั้นเพราะมันไม่รบกวนใคร กรณีที่ซับซ้อนมากขึ้น: ไดรเวอร์ฟีด เริ่มต้นก่อนที่จะโหลดคําสั่งการดําเนินการของหลายคําขอ: การตั้งค่ารถแท็กซี่ทั่วไป การตั้งค่าผู้ขับรถแท็กซี่ การตั้งค่า Courier All of them went sequentially, and each request slowed down TTI, especially on slow internet this was noticeable, since each of the three requests increased the total path time. เราได้มาพร้อมกับทีมและทําให้แผนการง่ายขึ้นอย่างมีนัยสําคัญ: การร้องขออิสระได้รับการเปิดตัวใน paralel การรวมการตั้งค่าสองคําขอลงในคําขอเดียว การร้องขอการสั่งซื้อเริ่มทันทีหลังจากได้รับข้อมูลขั้นต่ําที่จําเป็น และเพียงในกรณีที่หายากเราจะต้องรอการร้องขอแบบสอดคล้องกัน แต่แม้กระทั่งจากนั้นก็ได้รับการเปิดตัวแบบสอดคล้องกับครั้งแรกไม่ใช่จากจุดเริ่มต้นหลังจากครั้งแรก As a result: แทนที่สามคําขอถัดไปมีหนึ่งในกรณีที่ดีที่สุด ในกรณีที่เลวร้ายที่สุด - คําขอน้อยกว่าก่อนหน้านี้ หลังจากนั้นเราได้ดําเนินการทดลอง ผลการทดลอง: การเร่ง TTI ของ 0.5–0.8 วินาทีโดยเฉลี่ย ที่ percentile 95 – สูงสุด 2 วินาที ช่วงเวลา Charts by version show that the app became faster or slower, but do not answer the question why. Without them we had to guess why we were getting such a result. เพื่อแก้ปัญหานี้เราใช้เส้นเวลา - การแบ่ง TTI โดยขั้นตอน นั่นคือเราเก็บรวบรวมทุกขั้นตอนหลักของเส้นทางที่สําคัญ: แอปเปิดตัว วิธีการส่งมอบ ได้รับ Toggles getting location รับโปรไฟล์ การนําทางไปยังโมดูล โมดูลเริ่มต้น หน้าจอ rendering นี้ช่วยให้เราเห็นอย่างแม่นยํา: ขั้นตอนที่เร่งขึ้น ที่เกิดการกู้คืน สิ่งที่ส่งผลกระทบต่อ TTI สุดท้าย นี่คือเส้นเวลาที่ช่วยให้เราสามารถเปลี่ยนแปลงขนาดใหญ่ได้อย่างปลอดภัยและเข้าใจผลกระทบของพวกเขา นอกจากนี้ยังกลายเป็นพื้นฐานสําหรับการตัดสินใจและหาการล้มเหลวหรือสถานที่สําหรับการเร่ง - ชิ้นส่วนที่ยาวที่สุดที่น่าสนใจเรามากที่สุด ฉันขอแนะนําให้คุณใช้ตารางเวลา นี่คือระดับความละเอียดที่ดีมาก แต่วางแผนให้ละเอียดและมีคุณภาพสูงทันทีเพราะการเปลี่ยนพวกเขาในภายหลังจะไม่สะดวกและไม่สามารถเปรียบเทียบกราฟที่มีการทําลายก่อนหน้านี้ได้ แอปพลิเคชันรายงานการเปิดตัวและการกําจัดไพ่ Xcode App Launch Report แสดงให้เห็นว่ารหัสใดชะลอการเปิดตัว In our case: คอนเทนเนอร์ DI Typhoon ใช้เวลาการเปิดตัว ~30% การเริ่มต้นของมันหลายครั้งปรากฏขึ้นอย่างสม่ําเสมอในสถานที่ที่ช้าที่สุด หลังจากกําจัดไต้หวัน: ขั้นตอนแรกของการเปิดตัวถูกลดลงเกือบ 3 ครั้ง จาก ~1.3 วินาทีถึง ~445 มิลลิเมตรในรุ่น 5.122 ในแถบเวลาคุณสามารถเห็นว่าขั้นตอนแรกเร่งขึ้น 3 ครั้ง แต่ TTI ทั้งหมดกลายเป็นใหญ่ขึ้น หากเราไม่ได้มีการแตกหักเราจะไม่เข้าใจสิ่งที่เกิดขึ้นและวิธีการลบ DI สามารถชะลอทุกอย่างเช่นนั้น แต่ก็ปรากฏว่าพร้อมกับความเร็วขึ้นข้อบกพร่องทําให้เป็นรุ่นนี้ ฉันจะพูดคุยเกี่ยวกับเรื่องนี้ในส่วนถัดไป Hang Rate ตอนนี้เราสามารถเห็นว่าเครื่องมือหนึ่งเสริมเครื่องมืออื่น ๆ - ช่วงเวลาให้ภาพวาดว่าการเปิดตัวเร่งขึ้น แต่สิ่งอื่น ๆ ทําลายและส่งผลกระทบต่อขั้นตอนเริ่มต้นหลายเครื่องมือถัดไปที่ช่วยเรา - Xcode Organizer Hangs มันแสดงให้เห็นว่ารุ่นใหม่ของแอพเริ่มชะลอลงอย่างมีนัยสําคัญ บางสิ่งบางอย่างถูกบล็อกหัวข้อหลัก เครื่องมือแสดงให้เห็นว่า 92% ของเวลาแขวนมาจาก SDK ของบุคคลที่สาม นอกจากนี้ยังเน้นเส้นทางที่เฉพาะเจาะจง เหตุผล - คําขอเครือข่ายจากห้องสมุดของบุคคลที่สามบนหัวข้อหลักที่มีการรอการตอบสนองของเซิร์ฟเวอร์ได้ถึง 10 วินาที ปัญหานี้ถูกทําซ้ําเฉพาะบนอินเทอร์เน็ตที่ช้าดังนั้นจึงไม่ได้สังเกตโดยนักทดสอบและนักพัฒนาของเราเนื่องจากทุกคนมีอินเทอร์เน็ตที่รวดเร็วบนแล็ปท็อปและอุปกรณ์ เราส่งปัญหากับห้องสมุดและหลังจากการแก้ไขอัตรา Hang Rate กลับไปเป็นปกติ การวิจัย From time to time we profile the main user path by running it on different devices, and it looks roughly like this. ที่นี่เราพบ micro-freezes และเราเห็นทันทีที่ขั้นตอนของเส้นทางที่สําคัญที่พวกเขาส่งผลกระทบ แสดงให้เห็นว่ารหัสบางอย่างสําหรับการทํางานกับตําแหน่งของผู้ใช้โหลดหัวข้อหลักอย่างหนัก เราแก้ไขปัญหาไมโครแช่สุ่มหายไปและอัตรา Hang ได้ลดลงยิ่งขึ้น นอกจากนี้ขั้นตอนการเก็บรวบรวมโปรไฟล์ลดลงจาก 480 ms → 21 ms การทดสอบประสิทธิภาพ UI บน CI ค้นหาปัญหาและแก้ปัญหาเป็นสิ่งที่ดี แต่ยังดีกว่าที่จะเรียนรู้เกี่ยวกับการชะลอตัวก่อนที่แอปจะไปที่ App Store และแม้กระทั่งก่อนที่จะเริ่มการก้าวหน้ารุ่น เราได้ทําการทดสอบ UI ธรรมชาติซึ่งผ่านสถานการณ์จริงบนเซิร์ฟเวอร์การผลิตและส่งค่าวัดเดียวกันกับรุ่นการผลิต มันทํางานดังนี้: ผ่านทางผู้ใช้จริงไปยังหน้าจอกุญแจ ขี่ตอนกลางคืน ดําเนินการหลายครั้งโดยไม่มีการรั่วไหลของเครือข่าย ส่งเมตริกไปยังโทรเมตริก หากเวลาเกินขอบเขต - การแจ้งเตือนมาถึง Slack นี้ให้ความสามารถในการจับปัญหาก่อนเปิดตัวซึ่งในขณะนี้เป็นองค์ประกอบที่สําคัญที่สุดของระบบทั้งหมด นอกจากนี้เรายังเห็นเวลาเดียวกันทั้งหมดและการทดสอบใกล้ที่สุดเท่าที่จะเป็นไปได้กับเงื่อนไขการใช้งานจริง นอกจากนี้เพื่อให้แน่ใจว่าการแคชของเราทํางานได้ดีเราได้เพิ่มการโจมตีอินเทอร์เน็ตบน CI - ครั้งแรกการทดสอบจะทํางานที่ความเร็วปกติทุกอย่างจะถูกแคชแล้วสิ่งเดียวกัน แต่บนอินเทอร์เน็ตช้า 3G ในความคิดของฉันนี่เป็นหนึ่งในองค์ประกอบที่สําคัญที่สุดในการทํางานเกี่ยวกับความเร็วในการเริ่มต้น - ไม่ปล่อยให้รุ่นดังกล่าวออก ต่อไปเราต้องการเรียกใช้นี้ในทุกคําขอดึงแบบไม่สอดคล้องกันเพื่อไม่บล็อกการผสมผสานเนื่องจากการทดสอบประสิทธิภาพทํางานบน Mac Mini ที่เดียวกันเพื่อให้การวัดเป็นจริงและมีทีมขนาดใหญ่จะมีตาราง แต่เราสามารถทําสิ่งนี้หลังจากการผสมผสานและเข้าใจว่า PR ใดทําลายเวลาเริ่มต้นเพื่อให้เราสามารถเปลี่ยนการเปลี่ยนแปลงได้อย่างรวดเร็ว การเปรียบเทียบรุ่น ก่อนที่จะเพิ่มการพึ่งพาใหม่ไปยังโครงการเรามีกระบวนการเปรียบเทียบเวอร์ชัน - คําแนะนําสําหรับนักพัฒนาเกี่ยวกับวิธีการเปรียบเทียบเวอร์ชันปัจจุบันของแอปและเวอร์ชันที่มีการพึ่งพาใหม่เพิ่ม เมื่อหนึ่งครั้งในระหว่างการเรียกใช้ดังกล่าวเราเห็นการเพิ่มขึ้น 250 มิลลิเมตรในการเริ่มต้นแอพและตัดสินใจที่จะเปิดใช้งานคุณลักษณะนี้เพียงชั่วคราวและเพียงส่วนหนึ่งของผู้ใช้เท่านั้นเพื่อไม่ชะลอแอพ กระบวนการนี้ยังช่วยให้เข้าใจเหตุผลของการชะลอรุ่นล่วงหน้า ติดต่อ Caching ลองดูกรณีสุดท้าย - มองไปที่ตารางเวลาหนึ่งในขั้นตอนที่ยาวที่สุดในเส้นทางของเราคือการได้รับฟังก์ชั่นสลับ (700 ms), บาร์สีดําบนแผนภูมิ เราได้นําไปใช้การแคชขั้นสูง: ถ้าการลากใหม่กว่าเวลาที่กําหนดเราใช้การแคช จากนั้นเราจะอัปเดตข้อมูลอย่างไม่สม่ําเสมอ แน่นอนเราจะดําเนินการทดลอง A / B ซึ่งแสดงให้เห็นถึงการปรับปรุง ผล : ขั้นตอนการเปลี่ยนจะถูกลดลงในรุ่น 126–127 TTI ได้กลายเป็นผู้ใช้ที่เร็วขึ้นอย่างเห็นได้ชัดซึ่งเปิดแอปพลิเคชันบ่อยและผู้ที่มีอินเทอร์เน็ตช้าได้รับประโยชน์มากที่สุด แผนภาพแสดงให้เห็นว่าคนขับขี่ถูกลายเป็นขนาดเล็กมากเพราะพวกเขาเปิดแอปพลิเคชันบ่อย ไฟจราจรและการควบคุมสถานะอย่างรวดเร็ว เมื่อมีเมตริกมากเกินไปคุณต้องรวม เราใช้ "ไฟจราจร" พวกเขาใช้สูตรการรวมที่ซับซ้อนต่อวันการประเมินอัตโนมัติของการปรับปรุงและการลดลง ฉันจะไม่อธิบายทั้งหมดนี้ในขณะนี้เนื่องจากจะใช้เวลานานมาก แต่ทั่วโลกมันเป็นทั้งหมดสําหรับการตอบคําถามที่รวดเร็ว: "สิ่งที่เกิดขึ้นกับรุ่น" ตัวอย่างเช่นในรุ่นหนึ่งมีการเพิ่มขึ้นที่โดดเด่นที่เห็นได้ชัดใน TTI - ผลของการโหลดลวดหลัก ผลเสร็จสิ้น ลองดูผลลัพธ์ของเราในช่วงครึ่งปีของการทํางาน จากจุดเริ่มต้นของปีจนถึงเดือนกันยายน (รุ่น 115 → 140): เวลาตั้งแต่การเปิดตัวแอปไปจนถึงการเปลี่ยนไปสู่ผลิตภัณฑ์แนวตั้ง (50 percentile) ได้ลดลงเกือบ 3 ครั้ง: 2.8 sec → 1 sec อัตราส่วนของผู้ใช้ที่มีการเปิดตัวเร็วกว่า 5 วินาที: 58% → 84% สําหรับ 75% ของผู้ใช้ app เปิดตัวใน 4 วินาทีและมันเป็น 6.2 วินาที ในขณะเดียวกันการปรับปรุงเกิดขึ้นอย่างค่อยๆจากรุ่นเป็นรุ่นยกเว้นข้อบกพร่องหนึ่งที่เรากําลังจับได้อย่างรวดเร็วเนื่องจากเครื่องมือ อัตราส่วนของผู้ใช้ที่เรียกใช้แอปพลิเคชันที่เย็นเริ่มต้นเร็วกว่า 5 วินาที ข้อสรุป การเพิ่มความเร็วของแอปไม่ใช่การเพิ่มประสิทธิภาพครั้งเดียว แต่เป็นกระบวนการอย่างต่อเนื่อง: เมตรที่ชัดเจน ช่วงเวลาที่เข้าใจได้ การควบคุมอัตโนมัติก่อนปล่อย การวิเคราะห์และทดลองปกติ และสิ่งสําคัญที่สุด - การเร่งความเร็วด้วยร้อยมิลลิสวินาทีมีผลต่อธุรกิจอย่างแท้จริง ไม่ใช่ทางทฤษฎี แต่ในเปอร์เซ็นต์ที่แท้จริงของคําสั่งซื้อ