統一架構——優酷主客的標準化開發之路5優酷統一播放器業務框架演進之路23徹底解決動效開發痛點問題，優酷跨平臺方案來了30讓頁面滑動流暢得飛起：Android組件渲染輕量化淘票票iOS應用啟動階段性能優化性能優化之老生新談：飛一般的iPad68優酷暗黑模式系列：技術支撐篇77優酷暗黑模式系列：業務改造篇95詳解優酷最新交互技術：隔空手勢操作、智能護眼模式1292序序作為一個泛娛樂視頻平臺，優酷APP是向用戶提供高質量視頻服務的最重要入口。通過APP，優酷為用戶提供了點播、直播、導看、搜索、社區、互動、會員等服務，而在每一類服可分為OGC、PGC、UGC視頻；按視頻播放比例可分為橫版視頻、豎方式又可分為普通視頻、VR視頻、互動視頻等。這些劃分方式并不是獨立的，一個視頻往往兼具多種屬性，需要有對應的播放、交互，和信息服務。同時，這些大的服務門類也不是獨立客戶端性能優化跨平臺動效解決方案標準化開發模式如此多樣的服務匯集在一個APP中，無論從業務還是技術上，優酷都是名符其實的超級團隊一方面要保持很高的迭代速度，快速地消化大量的產品需求，盡早把新功能和變化送到用戶手中。另一方面要和不同的團隊緊密配合，確保在大規模的開發中保證產品交付的質量；對外，團隊面對的是海量的用戶群體，在移動用戶增量紅利逐漸消退的情況下，如何讓不同設備條件、不同網絡環境的用戶都盡可能地享受到高質量的使用體驗，是業務增長的重中之重。這就需要研發團隊在技術上持續打磨和創新，把效率、質量和體驗做到極致。優酷移動研發團隊經過多年的探索和實踐，沉淀了大量的技術經驗，包括解決方案、研發模式、技術架構、客戶端性能優化跨平臺動效解決方案標準化開發模式Android組件渲染輕量化Android組件渲染輕量化小視頻秒播優化小視頻秒播優化播放互動基于AI人臉識別的彈幕跟隨基于AI人臉識別的彈幕跟隨基礎架構優酷統一播放器架構優酷統一播放器架構插件化頁面框架插件化頁面框架本章從基礎架構、組件化解決方案、播放互動技術、客戶端性能優化、工具提效等方面介紹了優酷移動研發團隊的經驗心得。這些技術雖然分屬不同模塊，但又有相互組合、層層依賴的關系。如插件化頁面框架設計是建設標準化開發模式的基礎，暗黑模式又是標準化開發模式的一個典型應用；統一的播放器架構規范了播放業務的開發模式，在其上又擴展出酷看、互動4455一、超級APP的標準化在技術領域，標準化有很多很好的實踐案例。比如服務端容器的出現，應用的構建、分發一個業務需求通?？梢圆鸾鉃楣δ苄枨?，設計需求，體驗需求，數據需求和運營需求，而通過對每一類開發工作進行分析研究，我們得出了一個結論，客戶端開發的標準化是運行時環境一致，視覺效果統一，遵守相同的數據協議，用相同的方法搭建，投放和獲得用戶反饋661．渲染架構標準化數據模型是業務模型的抽象化產物，是頁面的里，它的結構來源于業務的需要，影響著組節流傳輸到客戶端，客戶端下載，解析，轉換成對象，或統一保存，或組織分發給每一個顯示而刷洗數據，轉化格式又會帶來效率上的降低。而對統一架構和標準化組件來說，我們又希望我們從兩個方向進行了嘗試，一個是在頁面搭建方向上，推進了服務端的數據協議的標準營同學在搭建頁面時，從整體到局部到細節的設計思路和操作行為。我們的標準化思路就是虛層級關系的名稱作為節點tag，而是統一為Node。這樣原本有層級關系的結構，約束接口定義。這樣三類模塊都可以進行不同實現的組的布局混排能力，在配置上通過文件配置進行布局樣式組件間的通信能力。這些標準化接口的提供，統一了組件的使用環境，大大降低了組件的UI域內服務指的是頁面范圍的視覺動作，比如組件的插入，刪除，刷新，加載更多等，這部分能77力我們在數據域對象提供了內置的方法，而域外服務則是指對業務中間件和應用基礎能力的調在渲染架構標準化的設計中，我們強調了解耦，而這對配置化的實現也帶來了便利。通過對頁面布局能力的拆解，對組件MVP的結構設計，組件的容器，容器的adapter，組件的MVP部件，組代理可以拿到頁面的上下文，監聽業務的消息進行響應，不同的使用場景都遵2.設計體系標準化客戶端用戶界面一致性是設計體系標準化需要關注的核心問題，保證一致性和體驗品質，并實現設計開發的工作提效，是“設計語言標準化管理體系”的建設的核心訴求。為此，我們聯合設計一起，從零創立了優酷自己的設計體系。我們為設計體系設定了核心目標：建立設計為了完成這個目標，我們進行了很多工作。設計同學對全站的現有設計進行了盤點，統一設計和技術對界面元素的認知體系，定義了設計規范。開發同學建立了標準化組件庫，以視覺規范為基礎，把設計側的規范文檔及組件庫，通過一種協作語言形成設計與技術的映射關系，標志著標準化的工作的具象，從根本改變了之前設以往開發實現過程中，研發代碼中會寫原始屬性值，而這個寫的過程一的研發組件庫，各業務線可以直接調用，收攏了散落各處的代碼。Token最終會對應什么樣883.服務能力標準化不同業務模塊，一般都會依賴不同的中間件，按照之前的服務和渲染耦合的設計，相同的服務能力在不同業務模塊間往往實現多次，這既增加了學習成本，形成技術壁壘，也使代碼結構脆弱和臃腫。而且服務的接入成本高，迭代成本也高，冗余的代碼既影響了編譯速度，更影為此，我們設計了標準化的服務接口和服務中間層，每個模塊都通過調用服務中間層的標準化接口，來獲得或者觸發服務。這既使渲染和服務解耦，也完成了中間件之間的接耦，形成99這是標準化前后的對比圖，從圖上我們可以看到，標準化之后，上層業務依賴的不再是具有某一套服務接口和實現，而是可以根據實際的情況，靈活配置服務?；A的服務和業務中間完成了這些標準化工作之后，目前優酷的整體通過一系列的標準化工作，實際上改變了業務需件開發上，有公共組件庫提供從屬性到布局多個維護的標準化實現，而且由于在框架層面的隔產品的業務邏輯實現。而且組件是自我獨立的，和外部容器之間沒有直接引用，所以可以在任對于能力的調用我們也提供了標準化的調用接口，開發同學不再需要關注最終具體的實現，只人力，研發效率提高了40%。我們的用戶體驗優化的項目中，比如過標準化快速落地到了每一個業務場景，將之前兩三個月的落地周期縮短到了兩個迭代。再如設計標準化，為暗黑模式的快速完成，提供了技術基礎，使之前一個月全員投入的需求在兩周備注：一一對應的映射關系，如果持久層是關系型數據庫，那么，數據表中的每個字段（或若干個）VO（ViewObject視圖對象，用于展示層，它的DO（DomainObject領域對象，就是從現實世界中抽象優酷iOS插件化頁面架構方案有鑒于此，我們需要尋找一種能夠進一步降低通用能力接入門檻，提升單個組件的開發效}}}}}}}}}}NavigationBar大模塊由若干個小模塊組合而成，將這些大大小小模塊用線段來連成一體，則可以得到一個龐大的樹狀結構，每個模塊相當于樹里面的個節點。功能單元則是跟這里的每個節點有著聯系，將一個功能單元對應一個或多個插件。模塊的功能單元代碼由插件承載，模塊內外的功能使用上也非常頻繁，如數據的讀取、消息的傳遞、實體之間的引入了ModuleProtocol，如果其他一般類也遵守這個協議，那么我們就可以把這樣的實例對象方便各層級下不同模塊之間的使用。歸納起來Context類五、Key-Value化數據存儲（NSArray/NSMutableArray/NSDictionary/NSMutableDictionary）和其他系統提供的數據類型這是保證不同模塊數據不串擾又同時保證同一模塊內數據共享。同一模塊下只需字段名參數便用ViewController來舉例，在野蠻生長iOS開發時代，把列表邏輯、網絡請求邏輯、Navigationbar邏輯等諸多功能單元都攤開在ViewCo各樣的協議，以至于ViewContr功能單元插件化目標是進一步降低功能單元之間的耦合。插件化思路和原則需要保證上述1.事件機制-更靈活的通信方式閱事件來接收并處理信息。信息收發雙方按事前約定的事件名進行通信，事件處理中樞負責事EventManager擔當起事件處理中樞的角色，發布者通過EventManager發布事件，EventManger以訂閱優先級從高到低把事件分發到訂閱者。高優先級訂閱者處理完事件后將返{}{}2.在插件中使用事件機制在插件間的通信上，除了事件機制協議外，就只有事件名的依賴（事件參數中不推薦使用用插件來承載業務邏輯的實現上具有非常靈活的特性，開發者可根據自己的判斷來決定插件的規模，插件的粒度可大可小，插件內部實現也可隨時中止使用事件機制并轉回其他一般的在插件的使用上具有非常靈活的特性，因此我們約定插件邊界必須清晰，必須做到單一職責原則，輸入輸出明確并足夠簡單，如果不滿足以上條件，則表示該插件有拆解細分的可能性3.插件與模塊的結合把與之關聯的插件進行初始化和綁定，插件訂閱具體事件并開始運作事件機制，直到模塊被注本章節用圖來說明如何使用插件化來編寫一個按鈕功能。一個頁面上有一個按鈕并支持點大得到了提升。若遇到產品提出新的點擊需求，如跳轉前必須檢查是否登錄狀態，未登錄者需要先登錄再繼續后續的操作。那么我們在現有基礎上只需要多開發體驗，增加了開發者學習成本，編譯器也無法幫助開發因此，我們充分發揮它的面向切面編程能力，在開發過程中，我們通過插件的形式加入調試類和監控類邏輯來緩解架構的不足，另一方面則建立標準化插件管理平臺對所有插件進行系統化管理。與此同時，標準化事件的開發方式使得存在統一的在搭建新頁面時，將上述各系列插件通過以配置加調參的形式即可快速接入和實現已有功能。同時也得益于越來越完善的列表布局插件，使得在開發如橫滑、瀑布流、輪播等復雜布局組件與開發平鋪組件時效一致。據粗略的測算，組件的開發插件化頁面架構是一個很好的起點，我們將會持續地完善和深挖它的能力，最終讓其更穩定且優酷播放器早期的架構是普通的單工程分層結構，隨著時間推進，播放器容器數量不斷增多，陸續支撐了播放頁、發現頁、自頻道、頻道頁、直播等幾大場景，可以說這段時間里原有然而隨著代碼的繼續膨脹，一些問題開始突顯出來。工程一直處于不斷膨脹的狀態。如上有容器無法復用，開發人員只能繼承基礎容器創建新的容器。同時開發人員要維護所有的播放舉一個最簡單的視覺升級的例子來說，在老架構的前提下，假如需求是要改變進度條的樣式，幾乎每一個播放容器都需要按照標注圖進行一遍樣式修改，對團隊來說，這既是一種資源架構之外，優酷由多個業務團隊維護各自的業務場景，這些業務場景最終都對接到播放器使得業務方團隊往往排著隊等待完成與播放器團隊播放容器不易復用、對多團隊并行開發的支持不夠友好等原有架構的缺陷愈發明顯，為此1．確定新架構的核心需求2．新架構設計的核心思路將播放器的最小集能力抽象成若干基礎能力插件，將其他業務抽象成若干擴展插件，拆分插件工程的插件內，插件之間彼此獨立。不同插件之間只依賴于新的架構框架進行編譯，而框架作動呢？新架構做了基于消息的事件驅動機制，即做出事件總線，插件之間通過事件總線實現互置化能力其實就是插件的編排能力，這和容器技術的思想類似，根據業務場景需求開發者從插件庫中選出對應插件傳遞給播放器框架進行安裝使用，通過不同的配置既可以實現不同業務場景的播放器支撐，又大大提高了插件的復用率。最終把不同的插件配置列表生成配置文件，也發標準以后，留給業務方團隊的就是一道填空題，團隊根據自身業務，把原有業務代碼稍加重構就能放到插件內。當新的業務場景無法找到滿足需求的插件時，也可以根據開發標準創建新3．統一播放器業務框架其中插件管理器、布局管理器、事件管理器、配置管理器、數據源管理器作為統一播放器插件管理器主要負責插件的配置、初始化、安裝、運行等一系列生命周期管控，將插件內布局管理器將統一標準里制定的Layer層抽象成控制器，接收插件發送的布局模型，尋找對應布局組的布局控制器進布局管理，布局控制器根事件管理器創建事件總線供插件間通信使用，維護事件發布者和事件訂閱者之間的關系以數據源管理器管理著眾多數據源的生命周期，數據源是為了給多插件之間讀寫共享數據而提出的概念，舉例來說，根據播放器和視頻應有的屬性與方法，分別抽象出播放器數據源、播最終，整個框架的運行生命周期如下圖所示，當播放器初始化完成以后即可進入工作狀態4.核心特性支持從配置文件加載層和插件的配置信息，各個業務方在接入業務框架時以搭積木的方式框架會提供一批功能豐富的標準插件，插件可分組管理，業務方可根據自己的需求定制插5．輔助工具相對于老的單工程架構而言，新架構的多工程插件解耦事件驅動在一定程度上使得方法調用鏈路變長不易調試，為了彌補調試困難需要開發出一些面向開發者使用的調試工具，如視圖對團隊收益而言，它適應了復雜的播放業務場景，支持著眾多圍繞播放業務的團隊并行開發。通過技術架構的解耦帶來與之相關的技術還記得開篇那個視覺升級的例子嗎？現在用播放器新架構來代入問題看看，假如需求是要通過插件的配置組合，新播放器支撐了播放頁、互動劇、少兒播放、預覽播放、首頁廣告業務場景，同時也為業務創新帶來了很好的支持，基于統一播放器業務框架，我們在短時間內開發并上線了酷看、互動視頻等創新功能，未來播放器團隊也將繼續朝著平臺化、配置化的方由于要進行大量的參數配置及調優，面對動效開發工作，大多數動效設計需求產出后，在與研發對接過程中，2）同一動畫，iOS端和Android端實現的效為了徹底解決上述痛點問題，優酷應用心中開發團隊與設計團隊共同研發推出了優酷跨平臺動效解決方案——畫眉，目的是從設計標準化、研發組件化、配置工具化三個方向，使得動優酷跨平臺動效方案，底層基于算法策略，后續會陸續開放源代碼，對于廣大的客戶端場1.架構路線2.技術實現SDK接口層采用Category方案，通過AOP思想來簡化調用復雜度。為了降低java調用C的性能損耗，Android端采用差值器Interpo3.可視化動效編輯工具最大的提效點在于：動效可視化預覽、簡化參數調優、動效代碼導出。設計師在確認動效參數1.優酷APP內場景落地2.近期規劃擁抱Swift！優酷Mac遷移Swift實踐1．安全編程3）更多安全的關鍵字。`guard`讓我們在執行接下來的代碼前保證某一個條件的成立，并2．編程范式的豐富3．其它另外，從穩定性的角度來看，從上到下的遷移也更安全。如果我們從下層的一些中間件或基礎庫開始遷移的話，由于上層的大多數業務模塊都對中間件或者基礎庫有依賴，我們對下層模塊的修改就會影響多個業務模塊，而且通常不知道這些下層模塊到底被上層的哪些模塊所調用。如果修改出現問題就會影響到非常多的模塊，更糟的是，如果是一些使用頻率比較少的業2.如何使用Swift的值類型}}}}3.混編問題}}}visible@interfacefor'CMSFilterViewController'錯誤。解決方法也很簡單，在所需要使用到的前添加`@objc`即}}必須說明的一點是，標記為@objc并不意味著這用。如果想要運行時相關的特性，必須使用`4.在Swift那些消失的東西在性能要求不是太高的情況下，我們通常會使用`@synchr`@synchronized`本質上來講是一個互斥鎖，背后其實是調用了`objc_sync_enter`和}}}}沒有dispatch_once這個方法了，那如果}}}}模塊，根據工作量來進行一部分的遷移；另一方面就是考慮到項目的穩定性，也不會直接把所讓頁面滑動流暢得飛起：Android組件渲染輕量化隨著互聯網視頻行業的持續發展，視頻行業的競爭已經進入了下半場。高中端機的用戶已1.機型問題（數據來自：Geekbench、GFXBe2.原生Native的問題原生Native開發的UI卡片，在布局以及渲染過程中，都是在主線程中執行的，尤其是RecyclerView在滾動過程中，執行了大量3.代碼實現的問題Image控件，輕量化組件由這些輕量化控件組合而成，可以在異步線程中進行預渲染，預布局1.異步預渲染（CPU優化）2.異步預布局（CPU優化）經過預渲染的輕量化控件，在異步線程中，進行寬高測量以及坐標位置計算，獲取到輕量3.異步圖層合并（GPU優化）在異步線程中，把之前經過異步預渲染，預布局的輕量化虛擬控件，統一繪制到圖片上，（數據來自：Graphics調試工具GAPID）通過輕量化的控件與圖層合并的結合，既達到了流暢度優化的目標，也在業務指標上有了正向的提升，同時還沉淀出一整套可復用的輕量化技術方案。尤其是在復雜的業務場景上，追求極致的性能體驗，后續也會提供更便捷的接入方式，進一步擴大應用場景，讓更多的用戶能挖掘低端機性能極限：優酷iPhone首頁性能優化啟動了iPhone首頁頻道頁性能優化項1.性能問題分析iPhone6plus優酷首頁queryiPhone6plus優酷首頁reuseview方法主線程耗時布局變換、文本size計算、圖層混合、圖片文本渲染2.性能解決方案對于卡片初始化的耗時可以通過預創建卡片的方式優化，在啟動后閑時創建頁面主要卡片線程復用結合異步渲染的方式，將復用任務分拆到子線程當中，減少主線程擁塞。為此我們開1.ModelUI簡介程安全的UIModel，如LabelModel、ImageModel等，以封裝渲染參數、渲染內容，供ModelContainer管理、渲染，UIiOS系統在底層硬件之上提供了三層渲染API，分別封裝為CoreGraphics、QuartzCore（CoreAnimation、LayerKit）和UIKit三個庫，其他常見的第三方UI庫主要是YYKit、AsyncDisplayKit（TextureYYKit對UIKit部分控件進行了優化，AsyncDisplayKit是Facebook基于CoreGraphics開發的異步渲染框架，幾種渲染方式對比如下：的輕量級異步渲染，以更好的配合UIM于需要交互動畫但不需響應事件的UIModelYYKit渲染使用開源項目YYKit控件渲染UI，YYKit較UIKit性能有所提升，結合子線程張圖片，最后由GPU直接渲染結果圖片到屏幕上，不需要GPU渲染每個控件，渲染結束后數據時可直接復用上次渲染結果，進一步減少渲染耗時，同時解決了刷新閃爍問題。異步渲染ModelUI維護了一個線程池用以布局和渲染，減少新線經過任務拆分、渲染方式優化后，主線程擁塞基本解決，GPU負擔大幅減少，從而降低2.不足要等待，導致卡片延時顯示，但相比于卡頓，延新，需要在數據更新時清除上次渲染結果，結合渲染復用可以解決此問題，需要業務層處理相1.GPU渲染負擔大幅減少iPhone6plus首頁接入ModelUI后圖層混合、離屏渲染2.Instrument測試幀率顯著提升iPhone6plus優酷首頁接入Mo3.性能測試平臺測試整體效果較好優酷自動化測試平臺iPhone6上優酷首頁優碼習慣也不同，難以形成有效的性能機制，而Mo淘票票iOS應用啟動階段性能優化應用的啟動性能，作為和用戶體驗直接關聯的重要指標，一直是各大技術團隊花時間花精淘票票團隊經過啟動優化專項治理，將啟動時間降低了3）ApplicationDidFinish：iOS系統回調，通知應用以完成啟動加載，可以開始界面繪制；4）界面繪制完成：首界面完全展現在用戶設備屏這里的階段范圍，涉及到我們這次分享的主要是Pre-考慮是對Pre-Main階段進行優化，實際上這里不太涉及對于代碼的處理，因為在這個階到虛擬內存中。這部分的優化，我們更多地需要去理解系統行為，在編譯這個層說到理解系統行為，能夠去看的東西很多也很少。iOS操作系統本身是很復雜的，雖然其是一個閉源系統，但iOS底層使用的是Unix，我們可以通過類Unix系統，也就是開源的二、PageFaultPageFault是什么？回答這個問題，我們先要1.早期的內存機制在計算機發展早期，操作系統對于內存處理機制都是有多少內存用多少內存，系統本身的內存地址和操作系統中應用的內存地址在物理內存上都是一一對應的。當你寫了一個軟件并運行，其中一個變量的地址打印出來是0x000FF1，那么這個變量的實際儲存地址就是物理內存了很多可能。程序員想要把其他應用在內存中的片段給引用到自己的軟件中運行，直接將對應內容地址加載即可。實際上當年很多應用都是這么做的，通過這種手段避免了重復加載運行庫當然，這么做除了容易導致崩潰之外，還存在另一個比較嚴重的問題：在計算機蠻荒的時2.虛擬內存操作系統開發者發現，當一個應用加載進內存之后，并不是所有的內存內容都會隨時被應用使用到。包括操作系統本身在內的應用，被完全加載進內存之后，也不是所有內容都會在同一時間被完全用上。那么是不是可以將部分暫時不用的內存內容，從內存移到硬盤上，等到需在Windows系統中如果打開系統設置，也能找到虛擬內存的對應調整選項。這里的Swap和自此，應用程序真正能訪問到的內存地址，和3.In，Out操作系統加載一段內容之后，突然發現物理內存不夠繼續加載更多內容了，這時候就需要釋放一部分內存，也就是把之前的一部分內存里內容移動到虛擬內存上，這個過程我們稱之為止這種操作，也就是在Binary加載時盡量將足夠多的內容加載到內存中。當然系統是不知道Binary里面哪些是需要使用，哪些是不需要使用的，所以系統實際上是盡量保證Binary頭部的內容被加載到內存中，而剩下沒有辦法加載4.PageFault現在我們應用的Binary被加載完了，其中一部分在內存里，一部分在虛擬內存里，當然我們應用自己是不知道那些在內存里那些在虛擬內存里的，對于我們來說這都是一樣的。然后我們應用開始運行，這時我們向操作系統請求內存里的內容，如果這個內容剛好在內存里，一切順利；如果這個內容實際山并不是在內存里，而是在虛擬內存里，操作系統就需要把請求的內容從硬盤加載到內存中。就算是在現在，內存的I/O速度和硬盤I/O速度依舊存在數量級這種應用訪問了在虛擬內存內容的情況，我們稱之為Pa進入現代之后，隨著人們對電腦的使用量增加，大眾對于操作系統穩定性、安全性的要求內容放到內存中時，會再次進行簽名驗證防止出現非法代碼注入，所以PageFault的開銷就比5.PageFault解決這里我們做一個設想：我們假設啟動階段并不會用到全部Binary內容，如果我們能夠獲取足夠的內存空間，把所有啟動階段的內容都放到內存里，那么是不是可以做到在啟動階段完這個設想是美好的，但實際上我們運行的設備可能本身就沒有足夠的內存，所以我們只能通過優化來盡量實現這個目標，盡可能的減少Pa那么，應該如何優化我們的應用Binary使得PageFault盡量減少呢？這里就要用到我們而那個年代的前輩開發者們已經在探索優化這個問題的方法。為了實現我們前面的設想，編譯如果你學習過編譯器原理，了解過編譯器的Binary編譯過程，你會記得在編譯的最后階段，Linker會將之前生成的Mach-O文件合并成我們最終可以運行的通過這種操作，我們可以盡量把啟動階段需要使用到的方法寫在Binary前面，就像我之前說的那樣，由于操作系統并不知道我們Binary中那些部分是需要一直在內存中的，所以系統會優先保證Binary頭部內容是存在內存中的，如果我們應用啟動只訪問了這些寫在Binary現在我們優化的手段有了，那么我們怎么知道哪些方法是需要優化的呢？當然我們可以手動去編輯OrderFile，但我們淘票票這個級別的應用，啟動階段可能涉及到的方法實在是太多了，光是我們自己的類中能夠確定的就有好幾十個，更不用提沒有源代碼的二方庫和各種系統1.抖音的方案C++的方法處理抖音這邊做的不是很好，他們的做法是通過分析LinkerMap拿到C++數方法，拿到block地址，之后通過Link2.Facebook的方案抖音之后，我們了解了Facebook分果生成一份OrderFile。所以他們開始通過改造llvm，通過參數使llvm在編譯中加入插樁，使用Facebook的這種方法，首先需要保證整個項目都是通過源代碼的進行編譯的，如果你的項目不是通過源代碼編譯的，而是引用了一些二方庫，由于沒有編譯過程，所以llvm插在研究Facebook的方法中間，通過llvm郵件組的公開郵件，我們發現了一個更加官方五、Profile-GuidedOptimizations師在處理完代碼覆蓋率之后，想到了可以通過代碼覆蓋率檢查的方法將啟動階段中使用到的方下面是一個模擬的PGO文件，可以看到這里不僅記錄了方法，還記錄了方法中關聯的方In有了非常明顯的減少，數值下降了23%左右。之后我們在新版中配置了Profile文件，通過線上數據統計，僅通過PGO這項優化，就帶來了18%左右的啟動時間下降，如果可以的話，我們可以找到二方庫和三方庫的源代碼，整個項目通過完整的源代碼方式進行編譯，通過這種方式生成的profile但是集團現在內部的狀態，要實現將所有二方庫的代碼湊齊，是一件不太可能的事情。不僅僅是我們團隊，就算是手淘團隊也沒有辦法做到完全源代碼編譯，該引用的編譯之后的二方之前說到的抖音的那種內存分析似乎可以用在這個方面，但一定要做的那么繁瑣么？還是在PGO方案中，我們無法觸及的主要是各種靜態的二方庫和三方庫，這些庫已經提前打根據手淘的方案，我們可以針對二方庫生成的Binary進行匯編處理，在二方庫沒有簽名的情況下，我們可以向二方庫的方法中注入記錄方法，在每個方法調用啟示節點進行插樁，這實際上我們并不需要輸出對應方法的名字，只需要輸出執行時的內存地址，然后通過內存這種方法比起抖音的不斷查詢內存的方式更加簡單，但是在操作上需要有一定的匯編和反匯編知識，要能夠修改對應二方庫的Bin發組的PPT里面寫的那樣，提供數好在OrderFile可以通過添加在Xcode配置中和PGO進行混編。我們沒有細致的去測試生成出來的Binary是否是最完美的，但從結果來看，添加上OrderFile也許通過結合手淘靜態庫插樁加上PGO是一個極致的方案，也許換用源代碼編譯出來的滿足我們的需求，之后的二方庫相關內容，我們會通過PGO和OrderF優化處理。由于我們整個項目在啟動階段使用的二方庫并沒有我們想象中那么多，而且由于二方庫的不確定性，我們在前期優化中就將很多二方庫的初始化從啟動階段移動到了后續進行，所以靜態庫插針這種方式給我們帶來的提升并不是很明顯，比起啟用PGO插樁添加到Mach-O文件中，使得我們的二方庫的方法順序也可以直接生成到PGO文件中。針對這塊我們也會持續跟蹤跟進，再出現更好的方案時，盡快把方案應用到我們的項目上，把[2]/atscaleevents/videos/[3]/pipermail/llvm-dev/2019-[4]/devmtg/2013-11/slides/Carrut[5]/library/archive/documenprofile_guided_optimization/Introduction/Introduction.html[6]https://mp.weix性能優化之老生新談：飛一般的iPad播間，優酷iPad端除了能看“簡潔”的直播和簡單的文字評論外，還不能參與其他直播互動。個場景分析性能痛點，搜集性能指標。然后根據時間安排、人力投入等篩選出一級指標、二級2）行業分析：確定技術指標后，與同類APP進行指標的性7）糾偏補漏：根據灰度后的數據分析，糾偏優化手段。步驟4~7反復進行8）數據分析：完成各項指標，并留意和分析性能優性能指標因機型差異而制定相應的目標值，根據優化基線和目標值應該選出不同分級的代1.機型分級2.實驗室測試設備3.統計口徑和優化基線4.性能工具和平臺平臺接入：CTM代碼覆蓋平臺、baymax平臺、APM數據平5.目標制定6.人力安排和規劃1.啟動耗時優化啟動優化宏觀層面有三大抓手：pre-main階段->啟動項階段->首屏渲染階段；微觀層），耗時優化：基于instrument定位耗時方法（閾值2.播放頁加載優化3.頻道、熱點加載優化4.幀率優化1.啟動/加載耗時優化前后對比通過上圖，優化前后各類耗時都有明顯提升，尤其是播放頁的熱啟動耗時。優化后的低端2.幀率優化前后對比通過上圖，優化前后低端機型各頁面的幀率有明顯提升，接近中、高端機型幀率，且遠超3.APM大盤數據（優化前、后）優化后，啟動耗時占比分布整體大幅前移，說明線上用戶的啟動優化后，播放頁加載耗時占比分布整體大幅前移，說明線上用戶的播放頁加載耗時大幅下4.高活用戶占比暗黑模式本質上是一個視覺模式，而視覺模式的酷推廣了視覺語言標準化體系，并以此為基礎實現了下面我們來看看，在設計標準化體系建立之前，優酷1.各自為戰：前“設計標準化”時代的視覺還原工作第一種：通過服務端下發視覺模式標記，客戶端通過解析該標記的配置，轉化成對每一個視圖的代碼設置。一個視圖在某個視覺模式對應的代碼設置在開橫向對比來看，方案一的設計最簡單，完全取決于需求，典型的推一下走一步。方案二落地成本最高，需要對每一個視圖增加響應配置的能力實現，開發的自由度最低，每個業務的開處是變更成本較低，可以動態的修改服務端模版并下對于方案三，則最符合原生開發習慣，也有最全面的開發工具支持，在編寫布局文件時就2.最簡即最優–“設計標準化”的設計原則同，極具差異性，所以希望技術方案貼近系統原生實現，清晰且簡單，才不會和不同團隊的的一地把控總體的效果，不在落地的過程中發生變異，就需要等動態頁面，未來還可能有Flutter，小程序4）動態性是考慮到可能需要服務端下發設計配置信息，或的標注進行溝通。開發不對設計效果負責，設計往往都要在開發工作完成之后才能看到設計效割裂，同樣的設計在不同的應用場景要重復循環，而不同的設計和開發可能在最終的效果上有3.“設計標準化”時代的視覺還原工作我們和設計同學一起對線上的產品進行了摸底，歸納抽象出了其中具有共性的設計，把影設計與開發團隊共同維護一套可擴展的視覺屬性。視覺屬性與框架布局分離，并與開發邏輯相模式色板。而研發同學則不再像以往一樣，根據視覺稿上具體的數值進行開發，改為根據另外，我們考慮到語義化名字在設計和開發之間的自然流轉，還修改和增強了設計開發工下面，我們從開發的角度介紹一下設計標準化體系的具體實現，以及設計標準化體系上線在代碼的工程結構上，也體現了設計標準化體系的分層思想，分為了屬性，控件，組件和首先，得益于優酷設計標準化體系的落地，我們已經提煉出公共資源庫，構建了多層的義，直接添加對暗黑模式的支持，零成本完成適配。另一部分則是擴大設計標準化體系的覆蓋其次，我們還對于暗黑模式進行了色彩分層，靜態色層是全站使用的基礎色值，它直接對應著一個具體的值。它不會隨著視覺模式的變化而變化。在它之上的是動態色層，動態色在不同的視覺模式下，對應不同的靜態色。這是通過Android原生的資源加載機制完在動態色層之上，是代碼編寫的色彩管理器，它在合適的時間會去獲取當前的所有靜態/動態色值。設計這一層有兩個原因:一個是提高性能，提前緩存一份給更上層調用，另一個是在色彩管理器之上，是公共的控件和組件層。有了這樣的層次關系，使最終的業務設計可以通過搭建完成，完全不需要從零寫起，也不需要關注設計標注的細節，開發再也不用逐個元素的調整，設計也不需要逐個像素的校對。只要在第一次納入的時候進行一次就可以完成，大ColorConfigureManager.getInstance()此外，我們在適配暗黑的過程中，還遇到了很多具體的問題，比如：1.低版本Android系統如何支持暗黑模式系統版本中已經預埋了對暗黑資源文件夾的加載能力;而且有一部分廠商所以對于低版本的用戶，我們也提供了適配方案。具體來說，我們來觸發模式切換的。需要特別注意的是，使用這個函數是有一些坑的。比如，在使用它之2.如何監視暗黑模式的切換可以通過onConfigurationChange一種是活動需要監聽它，來進行手動刷新，這能夠監聽到系統回調。另一種是某個控件或組件，或者我們的全局狀態，可能需要獨立監聽，}}3.系統刷新和手動刷新另一種，則是自己監聽onConfigurationCha4.設計體系未覆蓋的老舊頁面如何適配在眾多的頁面中，有一些老舊的頁面改造成本過高，甚如果不作任何處理的話，這些頁面會因為同時使用已改造組件和未改造組件而造成不同視覺模式同時出現。為了了避免這種情況的發生，我們會在頁面進入時，強制指定頁面的視覺模1.前期實踐2.暗黑SDK在APP中的運作3.暗黑SDK更新界面的工作流程4.暗黑SDK在視圖鏈中搜尋標記了動態屬性的節點5.暗黑SDK的開關以及支持的類型6.和蘋果官方的暗黑切換的調用過程的對比通過蘋果官方提供的接口分析，當系統的暗黑模式變化時，任何層級的UIView的主要是對老的業務代碼進行修改。如果沿用現有代碼邏輯中的刷新邏輯的話，假如刷新中包含數據請求，會導致同時觸發了不必要的代碼和邏輯。如果刷新導致用戶當前的操作現場丟失，另外，不是所有代碼都存在刷新邏輯，比如一個普通的彈窗，創建的時候數據是固定的，顯示后不存在刷新的必要。對于這樣的控件，如果為了接入暗黑模式需要新增一個專門的刷新考慮到這些特殊情況，為了達到暗黑切換的效果且不影響到業務邏輯，最直接和高效的辦1.上圖中的暗黑模式切換涉及到以下兩種情況：2）容器的背景色，淺色模式下是白色，深色模式下是黑色，其他按鈕2.解決方案：1.上圖中的暗黑切換涉及到以下兩種情況：從上面的兩個例子可以看出，適配暗黑只需要將現有代碼中的顏色和圖片替換成帶Token2.Token的設計123451.CGColor的暗黑適配}}}無需監聽，直接賦值，CGColor也是動態顏色，可以適應2.支持自定義屬性}3.支持自定義類：}如NSObject則不支持暗黑。如果需要完成暗黑的適配，需要在與MyObject有關聯的UIView、4.iOS系統的動態顏色只在iOS13以上被支持，iOS13以下無法直接使用：}5.支持iOS13以下系統這對于大規模的業務快速接入的優勢是顯而易見的。另外，在業務代碼加入大量的監聽代碼，第二類是獨立業務方開發的二級頁，這些二級頁由垂直業務團隊維護。由于優酷客戶端已完成架構統一和組件標準化的工作，各個業務團隊適配暗黑模式都是基于同一套技術方案，適配就變成了一個標準化的工作。業務團隊只需按統一的方式適配即可，極大第三類是一些歷史遺留的一些老頁面，這些頁面沒有固定的入口，入口分散在各個頁面和頁面展現分幾種狀態：轉場態，加載態（Loading展現態，異常態。暗黑模式適配的主要工作是適配頁面的展現態；轉場態和加載態的生命周期雖然很短，但是不能忽略，否則很容1.頁面級別頂部導航支持換背景色；底部導航支持換圖片資源、文字顏色、背景顏色；容器支持背景}}}}優酷分發場景支持換膚、氛圍和暗黑模式，優先級為氛圍>換膚>a）頁面同時存在氛圍+暗黑2.組件級別分發場景有幾十種組件，大部分組件接入非常便捷，只需將引用的資源字段改為色b）iOS（/articl優酷有些組件展示的主體是服務端下發的圖片，但是服務端暫時不支持下發視頻暗黑模式的圖片。針對這種組件就需要有個降級策略，盡量保證暗黑模式的整體顯示效果，這種屬1.Android由于資源（color，drawable）是通用的，對于那些沒有適配暗黑的頁面要進具體方式是:在暗黑模式下進入沒有適配暗黑的頁面，需要關閉暗黑模式來保證頁面可以尋址}}2.iOSiOS上漸變色無法自動切換暗黑樣式，只能通過監聽暗黑模式變化通知，手動設置暗黑漸覺標準化，即將屬性值符號化。開發只需要知道某個色值對應的符號，然后開發直接在代碼中將會是一件繁重且容易出錯的工作，所以需要一種方案能夠解決這個問題，讓設計和開發溝通所以，我們需要一套新的簡單高效的協作方式，在新的協作方式中，不僅僅要解決上述問1.DesignToken信息的標注數據Token文件，新的DesignToken文件包括單屬性對應的DesignToken的定義、多屬性對應一個2.標注模板文件1）設計師手動按照特定格式命名視覺稿中時在技術上也是一次將客戶端、前端、Sketch能力融合在一起的很好的實踐也具備為每個設計團隊提供建立設計標準的能力，目前包括了組件庫、樣式庫、頁面庫、圖標庫等功能，以便讓設計團隊都可以建立起自己道子母屏和多路流同步播放是酷看模式在端側的核心能力，能夠做到多路流、多機位視頻幀級同步播放。本文接下來要講一講和《長安》相關的背優酷的播放器業務框架以一個簡單而優雅的模型解構了所有的播放器業務，在該框架下播放業務是由一組彼此獨立的插件組合實現的。它適應了復雜的播放業務場景，支持著眾多圍繞播放業務的團隊并行開發。通過技術架構的解耦帶來與之相關的技術團隊的1.播放器視圖模型2.核心特性該框架在設計之初就確定了一系列的優良特性作為設計目標支持從xml配置文件加載層和插件的配置信息框架會提供一批功能豐富的標準插件，插件可分組管理，業務方可根據自己的需求定制插3.為業務開發帶來的變化以插件的形式隔離和封裝不同的業務，清除業務之間的顯式依賴。基另一方面可以自定義新插件替換默認實現或者添加新業務插件，技術框架層面上支持業務團隊在該播放器框架下，業務插件的頂層設計是統一的、標準化的。包括一致的構造函數、一致的創建過程、一致的生命周期、一致的播放器事件響應機制等。對于不同團隊業務代碼之間的相互理解和跨團隊統一作戰都有優勢。在標準化的過程中，更容易產出一些通用插件被更多通過引入中間層，播放服務與播放業務邊界逐漸清晰，徹底結束業務代碼與播放能力代碼酷看百科主要是在視頻播放過程中給出一些類似百科的，輔助用戶觀看的介紹性內容。技一方面面向運營，運營希望有一個常態化的運營工具，簡單的通過運營后臺修改配置就完【圖片】劇中關于不良人的解釋即為一處百科的投放核心技術點對于問題1，在播放器業務框架下我們將百科相關的業務也作為一組插件來實現，并且對播放器的業務插件進行分組，利用框架中插件管理器的插件熱拔插能力動態的啟用和禁用不同對于問題2，我們采用了阿里開源的Weex化布局，再結合后端的定投能力，就能夠實現按照不同樣式模版所謂子母屏就是將設備區域劃分為兩大部分，同時投放多屏內容。占據主視頻焦點的區域稱為母屏，一般用來播放正片；側邊較小的區域稱為子屏，一般用來投放與正片內容相關的輔助或者互動性內容。類似于直播比賽時，在畫面中引入場邊教練采訪傳統做法是直接將“要在副屏展示的內容”通過后期制作，以合流方式直接壓入正片視頻2）對制作不友好，互動資源和正片資源直無視觀眾的偏好；同樣也忽略了多層次精細化的運營需求，這種基于媒體資源的強綁定關系使基于此，我們將母屏和子屏的資源解耦。即不在制作時合流，而是讓正片內容和運營內容嚴格分離，分開存儲和投放。副屏的內容投放將完全交由運營同學，運營同學從模版庫中選擇我們這里只講一個較為核心的點即播放器雙屏容器，雙屏的內容投放是彼此分離的，它是1.播放器雙屏容器首先要解決的是子母屏容器的搭建問題。對于雙屏容器2）子屏同母屏一樣具有交互性，能夠響應用戶設計師給出了母屏和子屏可以相互交錯疊壓的酷炫方案，甚至還有延伸至背景的異形遮罩我們寫了一套自適應的容器布局算法，基本的思路是對母屏的布局按照統一規則進行劃分，將子屏嵌入到母屏的某一層中，能夠基于服務端下發的配置和視頻的尺寸計算出最終子母屏容器雙屏想要具備交互性響應用戶手勢主要的阻礙在于Z軸上有覆其他的遮罩層會攔截掉系統的觸屏事件，為此我們設計了手勢插件作為觸屏事件的代理，由這在解決了子母屏的自動布局和交互性問題之后，用子母屏來承載雙路流的視頻同步播放則雙路流的觀影體驗設計較為超前的，在當前的硬件條件下，能夠讓配置不是很高的用戶也《長安十二時辰》雙流投放效果，母屏為正片，副屏為張小敬服飾介紹4.主要的困難點：從視頻生產開始，視頻剪輯工具可能就具有1錨點，如果運營工具做不到幀對齊級別的錨點自動計算，那么最終對齊的效果也會受人工計算是不確定的，調用這些Api實現40ms級別2.兩個播放器同步的解決思路：一個“調節-反饋-修正”的遞歸過程，雖然模型相對簡單，但是需要達到想要的效果具體實現響。例如，為了適應網絡狀態的隨機性，實現全局統一的緩存策略；為了平抑個體性能差異，我們引入了部分統計學的方法來做追幀補償，統計當前設備最近幾次追幀差值的方差和標準差通過架構設計、工程優化、算法升級和有針對性適配，打出全鏈路的組合拳，最終實現了《這就是街舞2》中的同步效果互動視頻介于視頻與游戲之間，圍繞劇情，兼顧游戲性。核心是通過互動，讓用戶有能力優酷正在搭建支撐互動劇生產與播放的技術平臺。客戶端作為呈現互動視頻的重要載體，核心職責就是定義一套協議標準，并基于此搭建互動引擎，以便快速而靈活地支持互動劇的播1.概念與模型的建立針對傳統的視頻內容，優酷內部實質上已經有了一套在行的概念，包括?。╯how）、集（video/episode）等，然而面對互動視頻這種新的業務形式，僅有個業務上下游能夠順暢的溝通，優酷需要基于原有概念模型，擴展出一套互動視頻的領域概念模型。2）概念術語需要簡單明了，讓參與的各方角色達成一致3）需要避免與已有概念沖突，最好能夠復用或首先我們梳理了互動視頻業務涉及到的各方角色。這些角色不僅包含內容生產者、內容消其次我們協同各個參與角色，討論確定了互動視頻中的概念及術語，并建立起與普通視頻2互動視頻）片段與（普通視頻）集在視頻實體上是一致的，可接受播放器的播2.優酷端側工程的兼容性考量已有的基礎設施，包括播控、分享、評論、倍速、清晰度等一系列功能，鑒于播放頁上已經實現了這些功能，所以我們決定在已有的播放頁上做擴展，充分利用已有的輪子，使用優酷播放以不去理解“互動視頻”這樣一個新概念，在進入播放頁之前，用戶在形式上可以不知道某個中，但是如果新版本的用戶分享視頻到了老的App上，就會產生異常。一般做法是，當互動App在進入播放頁后，且在真正播放是，則加載互動引擎，驅動互動視頻播放。在老版本的App中，代碼并不會判斷播放服務中3.互動視頻端側的交互性考量上展示沒有太大問題，然而對于強劇情交互的互動視頻而言，小屏會降低用戶的使用體驗。為了給互動視頻帶來沉浸式的體驗，我們在播放頁小屏狀態時，會中斷視頻的自動播放，并通過何支持互動視頻需要的特殊功能？如何保證這些功能需要具備的擴展性？這些，就是上文中提1.互動引擎（InteractiveEngine）為確定互動引擎需要支持的功能模塊，我們結合整個技術體系，從端側角度，梳理了如下雙虛線上面是內容平臺與服務端，下方藍底區域為互動引擎及其模塊?；右婕軜嬙诮y一播放器業務框架之上，關于統一播放器業務框架，可以簡單地理解為播放器上面的業務插件2.劇情主軸:節點與事件上文描述了引擎在功能模塊上的垂直劃分，這些功能模塊通過統一調度運行在時序上。為劇情主軸由節點橫向鋪滿，節點的生命周期由互動引擎控制。為了兼容后續可能的變化，能夠管理視頻狀態之外，還能夠觸發產生互動界面。互動界面是承載用戶行為的主要形式，它中的Weex頁面往往與視頻內容相關，所以其實現中還包含UI適配邏輯以及用于調試的3.大圖設計:模型與調試劇情大圖是為了避免用戶在互動視頻中迷失所設計的視頻片段關系展示形式。模版化的劇將劇情節點全部展示的好處是，所有視頻節點一覽無余，不會有隱藏的節點，用戶擁有更劇情圖數據結構的本質是有向無環圖。為簡化圖的處理，我們抽象出了專門處理圖的抽象為降低當前路徑劇情圖開發過程中調試的難度，我們開發了相應的可視化工具，能夠在4.其他技術與功能點在技術設計上：我們從概念出發，逐步落地到優酷工程及代碼上；從需求出發，逐步落實到模塊及功能的拆分上。業務架構的設計，降低了后續一系列技術迭代的實現成本，如支持橫一個互動章里可能會多次更新播放的視頻片段，為不打斷用戶的觀影體驗，視頻的預加載作為視頻平臺，優酷天然地與用戶有非常多的潛在互動場景。從去年開始，我們加快了在上的思考總結，希望對大家有啟發。1.背景介紹當用戶使用移動端設備，選擇一個綜藝或劇集后，會處于一個長時間的靜止觀看狀態，雙手自然地被釋放出來，且距離屏幕如此地近，隔空手勢操作就成為一個很好的切入點。因為既然用戶不需要經常性的操作設備，用戶就更有動機不會長時間地接觸設備，從而釋放雙手去同動設備，因此不能帶來設備的耗電量加劇、設備過熱發燙等影響，最終我們與阿里達摩院的2.實現方案：的圖像數據。并且，由于回流的數據屬于敏感的用戶隱私數據，我們對回流的數據執行嚴格的3.線上效果：識別的成功率達到了97.4%，并且還在持續提高。從媒體和渠道的反饋看，用戶對用的互動功能，接受度很高，比如有用戶就給了“吃飯時看1.背景介紹自從蘋果的iPhoneX和2018年的i相關信息，實現人臉識別解鎖等功能。這部分能力已開放，可以以幀為單位實時獲取識別到的2.實施方案放畫面會給出護眼提示，同時暫停播放內容。當眼睛3.分享一個技術實現細節距離，而實際上我們需要獲取的是“人眼距離屏幕中心點”的距離，兩者存在一定誤差，我們幕中心點相對于攝像頭的變換矩陣即可，因為處于同一坐標系，且距離單位相同，通過計算就這里屏幕中心點距離攝像頭的距離即x軸分量如何應用現有的技術，小步快跑地提升用戶體驗？我的一點經驗是：一是基于對技術的需求，以合作實現最終目的，二是依賴系統提供的現有能力找到適合自己業務場景的應用。三是要提升用戶體驗，不一定要覆蓋全部用戶。我們在交互方式上的兩種探索，都是以極低成本，View的異步Inflate+全局緩存：加速你的頁面種類很豐富的場景下，inflate次數相對較AsyncLayoutInflater類。但都存在一個問題，里面直接有newHandler()（原本想新建一個主線程Handler用于UI操1.異步Inflater的時候，View中newHandler導致的安全問題解決方案使調用post方法發消息，并不會正在執行，導致U第二種，雖然newHandler能正常工作，但所以Handlerhander=newHandler(線程newHandler()方式也能把消息拋到主線程2.全局緩存，View的context問題解決方案導致的內存泄露問題，對Context做封裝：新建了ViewConte1.基本架構2.實施思路4）內存管理策略--應用低內存自動釋放緩存。通過context取到APPlication注冊一個5）緩存優先級策略--可設置緩存釋放優先級2.實施3.注意事項t傳入的是APPlication且沒有設置相關Theme，就會報錯；選擇異步Inflate，應根據需要，合理的選擇。如只需activity級別的，選擇原生因為inflate所需的context不一2）在啟動方面，結合各業務端提前做一些預加載任務，整體帶來了20%左右的提升。別放走了那只啄幕鳥：iOS開發提效好幫手題，Debug依賴電腦聯調，缺少獨立便捷的Debug工具。1.啄幕鳥架構啄幕鳥使用插件化架構，每個工具作為插件接入到啄幕鳥基礎服務當中，各個插件相互獨立，同時支持外部插件注冊、定制等，啄幕鳥還提供了一些2.基礎服務3.公共模塊支持日志顯示、用戶輸入、搜索、正則表達式過濾等功能，系統信息工具直接使用了屏幕日志顯示信息：1.UI檢查工具2.In-APP-Debug工具能的開發工具，如方法監聽既可以用于定位Bug，也可象開始，可以利用運行時特性獲取連通圖里任一個對象的屬性、成員變量，獲取運行時數據，以定位問題。雙擊控件拾取的信息區即可打開對象查看，對象查看會顯示拾取對象的屬性、成員變量列表，點擊對象即可查看它的屬性，層層查找即可查看到每一個相關的對象，并可以通查看某UILabel對象、使用k命令獲監聽命令即可監聽任意OC方法的調用，輸出在ykwoodpecker_forwardInvocation:方法中收到封裝了被監聽方法調用參數和返回值的值，輸出日志。3）po命令4）JSON抓包使用方法監聽抓包略有不便，數據量較大時3）Defaults：查看、新增、刪除User4）清除數據：清除所有沙盒數據，包括UserDe啄幕鳥使用插件化架構，新插件擴展方便，部分插件也支持功能擴展。一個類只需實現插件協議方法即可注冊為插件，可定制插件分組、分組顯示位置、插件名稱、icon、插件顯示位置等，簡單方便，高可定制。控件拾取、系統信息等插件也支持功能擴展，通過監聽相關啄幕鳥Github地址：/alibaba/youk這兩個項目在開源界無論從應用范圍、設計模式、技術深度等都是出類拔萃的項目。通過閱讀這些優秀的源碼，摘錄出一些優秀的代碼片段和編碼技巧。最近兩年把這些“片段”放到應用層的開發工作上，不僅在代碼細節上有些許的性能提高，也能讓項目的代碼風格向這些頂尖項目靠近。同時，熟悉這些編碼風格后，當我們在翻閱這些開源項目源碼時，也能在一定程度上下面分享幾個摘錄出來的代碼片段，再結合著這些代碼在優酷項目上的使用，進行一一說參的合法性，使用注解的方式來完成是個很好的解決方式，也可以減少不同模塊開發人員間的1.先來看看chromium使用注解的實際案例}}}（/chromium/src/content/public/android/java/src/org/chromium/content/browse r/webcontents/WebContentsObserverPr}}對于viewportFitChanged()這個方法}}2.再來看看github上的一個項目對注解的使用}}}用注解去修飾方法參數.}}setPosition這個方法，通過注解來限制參數取值范圍的作用很清晰了，不再贅述.3.注解在優酷上的使用計給UC方調用的API時，就使用到了注解修飾參數的方法來避免集成方對API的調用錯誤。}}}*@throwsIllegalArgumentExceptionif*@throwsIllegalArgumentExceptionifthespecifiedinitialcapacity*isnegativeprivatevoidinitAliComicSdk()privatevoidinitAliComicSdk(){AliComicSDKEngine.getInstance().init(instance,ConfigManager.KEY_YK,newIAppConfigAdapterImpl(),newIUiAdapterImpl(),newINetAdapterImpl(),newIPayViewAdapterImpl(),null,newIUserAdapterImpl(),newIWebViewAdapterImpl(),newIComicImageAdapterImpl());}以ArrayList為例，通常我們創建對象時，使用newArrayList<>()是最常用的方式.當我們閱讀chromium或是像okhttp這些開源代碼時會發現它們在構建Ar1.還是以chromium為例,摘取一段它的源碼.protectedstaticList<String>processLogcat(List<StrinprotectedstaticList<String>processLogcat(List<String>rawLogcat){List<String>out=newArrayList<String>(rawLogcat.size());for(Stringln:rawLogcat){ln=elideEmail(ln);ln=elideUrl(ln);ln=elideIp(ln);ln=elideMac(ln);ln=elideConsole(ln);out.add(ln);}returnout;}再直接看ArrayList兩種構造方法的源碼,無參方/***Constructsanemptylistwiththespecifiedinitialcapacity.**@paraminitialCapacitytheinitialcapacityofthelistnewCapacity=hugeCapacity(minCapacinewCapacity=hugeCapacity(minCapacity);//minCapacityisusuallyclosetosize,sothisisawin:*/*/publicArrayList(intinitialCapacity){super();if(initialCapacity<0)thrownewIllegalArgumentException("IllegalCapacity:"+initialCapacity);this.elementData=newObject[initialCapacity];}/***Constructsanemptylistwithaninitialcapacityoften.*/publicArrayList(){super();this.elementData=EMPTY_ELEMENTDATA;}方法來擴容。grow()內部會以之前容量為基準，擴大一倍容量，并發生一次“耗時”的數組拷/**/***Increasesthecapacitytoensurethatitcanholdatleastthe*numberofelementsspecifiedbytheminimumcapacityargument.**@paramminCapacitythedesiredminimumcapacity*/privatevoidgrow(intminCapacity){//overflow-consciouscodeintoldCapacity=elementData.length;intnewCapacity=oldCapacity+(oldCapacity>>1);if(newCapacity-minCapacity<0)newCapacity=minCapacity;if(newCapacity-MAX_ARRAY_SIZE>0)}2.再來看一下okhttp中的例子細節的調優都是有可觀收益的，同時也體現出作者}}}}對這些編碼細節上的考究，很難對業務性能指標產生可量化的提升。更有意義的點在于，我們在實際開發時，避免不了要經常參考開源項目對一些功能的實現。如果不了解這些實現細如果我充分了解了這些細節，當讀到它們的時候，往往會泯然一笑，心說我知道作者為什么要優酷的視頻互動是在播放頁橫豎屏彈出的互動浮層，旨針對這些大量的投放活動，為了衡量活動曝光的質量，我們定義了通過添加技術埋點，我們統計了現有互動平均曝光1.超時問題出互動時，基本無法命中zcache，而在沒有zcache時，頁面加載超時的問題就很明顯，不解決本兼容問題，操作麻煩，而且會增大apk大解決了部分用戶的超時問題，也解決了所有用戶首次渲染時間問題，現有預加載能力，可以保證互動準時彈出，但是也有一個很明顯的缺陷，有時間限制，超時即認為加載失敗，針對部分不需要準時彈出的互動，超時就認定加載失敗，是不太合理的，因為這里大部分還是可以加載成功。于是我們在預加載邏輯里新增一個策略，如果超過一定時2.錯誤問題新業務上線時，往往存在很多js錯誤，這期跟進核心互動評分、ti存在少量的白屏錯誤，后續待繼續優化這種容器層的js錯誤。插件生命周期。我在新版本解決了這些警告。只有數量無法分析某個版本的好壞，于是參考崩存在設備不在線、數據丟失問題，使用不很方便，后面考慮把錯誤文件名、行號同時上傳到統計后臺，方便快速定位問題。其他業務如互動這邊彈幕、評論等業務以此為參考，重點治理下3.互動容器bug及數據統計校準針對曝光成率統計，雙端統計分子實際曝光數沒有問題，但是在統計分母應該曝光數時，都存在統計不準的問題，為此我們雙端討論并約定分母中，去除了無網導致的預加載問題、音同時解決了分母重復統計問題，跟進播放器解決推薦廣告導致的首次不彈bug，確保雙端數據通過此次優化，從互動平臺角度解決了現有的互動曝光率問題，完善平臺化能力，確定了近幾年，短視頻一直處于流量的風口，各大平臺紛紛涉足。不同的業務形態對技術有不同為什么短視頻關注的是秒播？一是因為短視頻通常只有十幾秒，一是短視頻的消費帶有很大的探索性和隨機性。如果用戶花幾秒鐘等待十幾秒的視頻，很有可能起播后還不是用戶喜歡看的，這個代價對用戶來說太大了，久而久之，就是短視頻播放相關的核心技術指標有兩個：緩存命中率和秒播率。通常情況，緩存命中率越高，響應的秒播率也就越高。短視頻秒播專項優化項目啟動時，關于緩存命中率和秒播率，結首先，我們是短視頻分發消費場，屬于上層業務，底層播放器鏈路和預加載模塊對我們都其次，短視頻分發消費場，用戶訴求是隨機的，當用戶滑到不感興趣的視頻時，會立即滑載下一個視頻的時間，造成滑出來的視頻大概率在線起播，如果恰逢網絡不穩定，很容易造成再次，優酷的長視頻和短視頻共用一個播放器。長視頻場景下，更關注的是起播之后的流載任務搶網絡帶寬，此時會暫停所有的預加載任務，以優先保證起播。起播之后，在當前播放播放器以上