大淘寶技術：2022技術人的百寶黑皮書-阿里大淘寶技術2022技術年貨（1276頁）.pdf

《大淘寶技術：2022技術人的百寶黑皮書-阿里大淘寶技術2022技術年貨（1276頁）.pdf》由會員分享，可在線閱讀，更多相關《大淘寶技術：2022技術人的百寶黑皮書-阿里大淘寶技術2022技術年貨（1276頁）.pdf（1276頁珍藏版）》請在三個皮匠報告上搜索。

1、技術經典總結內存優化:紋理壓縮技術移動域全鏈路可觀測架構和關鍵技術性能優化之接口優化APM 頁面加載耗時校準19條跨端cpp開發有效經驗總結下一代響應式Web設計：組件驅動式Web設計Flutter 新一代圖形渲染器 ImpellerHTTPS的原理淺析與本地開發實踐無代碼生產新模式探索HTTP3 RFC標準正式發布，QUIC會成為傳輸技術的新一代顛覆者嗎？相關業務實踐淘寶購物車5年客戶端技術升級與沉淀淘寶長輩模式客戶端技術實踐萬字總結打造淘寶極簡包的輕量化框架CONTENTS目錄第一部分年度精選技術棧內容021334435867126139158167173209229終端技術篇我在淘寶做彈

2、窗，2022 年初的回顧與展望年度經典專題跨全端SDK技術演進跨桌面端Web容器演進跨桌面端之組件化實踐服務端技術篇技術經典總結合理使用線程池以及線程變量mysql鎖機制的再研究數據庫存儲選型經驗總結開發規約的意義與細則如何避免寫重復代碼：善用抽象和組合MapStruct，降低無用代碼的神器一個搞定責任鏈的注解stream的實用方法和注意事項響應式編程的復雜度和簡化一種可灰度的接口遷移方案相關業務實踐談一談湊單頁的那些優雅系統設計大淘寶用戶平臺技術團隊單元測試建設淘寶IOS掃一掃架構升級-設計模式的應用年度經典專題淺析設計模式3 裝飾者模式淺析設計模式2 策略模式淺析設計模式1 工廠模式239

3、2692812913083353463563713814004214304424544804875055185295455585745906096176826937007117216286406496636733DXR技術篇技術經典總結進入 WebXR 的世界虛擬數字人行業現狀和技術研究 MNN2.0 發布移動端推理引擎到通用深度學習引擎相關業務實踐3D技術在數字藏品中的應用 商品 3D 建模的視覺定位和前景分割方法 因果推斷實戰:淘寶 3D化價值分析小結數據算法篇技術經典總結因果推斷:效應估計的常用方法及工具變量討論傾向得分匹配(PSM)的原理以及應用 ODPS SQL優化總結 大淘寶技術數

4、據模型治理階段性分享 SIGIR2022 流行度偏差如何利用?探索解耦域適應無偏召回模型相關業務實踐多模態技術在淘寶主搜召回場景的探索 淘寶逛逛ODL模型優化總結 淘寶Push智能文案生成年度經典專題冷啟動系統優化與內容潛力預估實踐基于特征全埋點的精排ODL實踐總結733745753760767782849870878887899905914917795832841生成式重排在內容推薦中的應用實踐無盡流場景優化總結音視頻與圖像技術篇技術經典總結CVPR2022|開源:基于間距自適應查找表的實時圖像增強方法ACL2022|自監督文本表示新框架ArcCSE大淘寶技術斬獲NTIRE視頻增強和超分比賽

5、冠軍(內含奪冠方案)短視頻無盡流前端開發指南相關業務實踐全景封面視頻生成技術在淘寶的應用移動端人臉風格化技術的應用基于機器學習的帶寬估計在淘寶直播中的探索與實踐技術質量篇淘寶直播端到端音視頻評測方案首次公開我在阿里做測試，入職5個月的回顧與總結前端質量之灰度監控的有效實踐驅動頁面性能優化的3個有效策略大淘寶技術2022資訊重點 第14個天貓雙11，技術創新帶來消費新體驗淘寶自研標準化協議庫XQUIC正式開源!上海交大牽手淘寶成立媒體計算實驗室:推動視頻超分等關鍵技術發展國際頂會OSDI首度收錄淘寶系統論文，端云協同智能獲大會主旨演講推薦92697899399399393994695095996

6、9電商直播高畫質開播指南正式發布，6步快速搭建一個高清直播間技術人的經驗總結新手項目經理入坑指南前端架構師的一些思考和總結在阿里做前端程序員，我是這樣規劃的如何快速理解復雜業務，系統思考問題?關于程序員的職業操守，從匠藝整潔之道談起技術人的金句系列“從幼稚到成熟，是從不負責任到承擔責任的過程”|技術人金句系列終端技術篇項目：mobx項目：xstate項目：d3第二部分技術人生與學習成長系列第三部分GitHub上的推薦學習項目995995995995995995995996996996996996996996993993993993994994994994994994994項目：VScode項目

7、：ice項目：koajs項目：nextjs項目：vue-element-admin項目：Android studio項目：openstf項目：BetterCodable項目：SwiftDate項目：SwifterSwift項目：mirai Auto.js服務端技術篇項目：yolov3項目：CS-Notes項目：jeecg項目：rocketmq項目：Spring Framework項目：Apache VFS項目：spring-framework項目：Netty項目：nocalhost項目：istio項目：transmittable-thread-local項目：resilience4j項目：sp

8、ring項目：guava9979979979979979979979989989999999999999999999991000100010001000100010001000音視頻技術篇項目：Urho3D項目：Cocos2dx項目：x265項目：HM項目：vlc、Ijkplayer、exoplayer項目：videojs項目：flvjs項目：transfer_learning_music項目：music-audio-tagging-at-scale-models數據與算法篇項目：FastText項目：Deep-photo-styletransfer項目：ranking項目：deepctr項目

9、：opencv項目：mmf項目：detectron2項目：openpose項目：chainer項目：pix2pixHD項目：stylegan項目：StyleGAN2項目：tensorflow項目：caffe100110011001100110011001100110021003100310031003100310053DXR技術篇項目：filament項目：cocos2d-x項目：taichi項目：glumpy項目：raytracing項目：計算幾何庫項目：Threejs項目：mmcv技術質量篇項目：pytorch-handbook項目：ChromeDriver項目：Jvm-Sandbox:項

10、目：skywalking項目：jacocoOSDI 2022Walle:An End-to-End,General-Purpose,and Large-Scale Production System for Device-Cloud Collaborative Machine Learning第四部分 2022大淘寶技術A類頂會論文精選104110621086111011321151SIGKDD 2022SGGG:Self-adaption Generative Gating Graph model for Personalized Micro-video RecommendationTIP

11、2022Progressive Language-customized Visual Feature Learning for One-stage Visual GroundingACM MM 2022CoHOZ:Contrastive Multimodal Prompt Tuning for Hierarchical Open-set Zero-shot RecognitionACL 2022A Contrastive Framework for Learning Sentence Representations from Pairwise and Triple-wise Perspecti

12、ve in Angular SpaceCVPR 2022Ray Priors through Reprojection:Improving Neural Radiance Fields for Novel View ExtrapolationGEN-VLKT:Simplify Association and Enhance Interaction Understanding for HOI Detection 1169123411881211AdaInt:Learning Adaptive Intervals for 3D Lookup Tables on Real-time Image En

13、hancementSIGIR 2022User-Aware Multi-Interest Learning for Candidate Matching in RecommendersCo-training Disentangled Domain Adaptation Network for Leveraging Popularity Bias in RecommendersICIS 2022Short-Video Marketing in E-commerce:Analyzing and Predicting Consumer Response年度精選技術棧內容第一部分技術人的百寶黑皮書20

14、22版大淘寶技術出品01第一部分年度精選技術棧內容伴隨著時代和商業的快速發展，天貓淘寶的底層技術基礎設施得到了深厚的積累，同時也支撐了云計算的大規模發展。未來，大淘寶技術將通過持續的技術創新和突破，讓商家更好的做生意，讓用戶享受更好買、好逛、好玩的線上體驗。本篇章將分享我們基于淘寶等真實的消費場景，在終端技術、服務端技術、3DXR技術、算法技術等多個技術棧的實踐經驗，包含點點滴滴的細節技術改變，以及完完整整的技術解決方案，期望與大家真誠交流和共同進步，一起探討未來技術與消費的新形態。101年度精選技術棧內容終端技術篇/技術經典總結技術人的百寶黑皮書2022版大淘寶技術出品內存優化:紋理壓縮技術

15、作者：楚奕出品：大淘寶技術終端技術篇相比普通格式圖片，紋理壓縮可以節省大量顯存和 CPU 解碼時間，且對 GPU 友好。背景游戲開發中紋理是內存占用大戶，移動設備因為內存有限，問題更加明顯。據統計，淘寶互動小程序性能卡口 70%以上都是因為內存超標，而內存超標的主要原因則是圖片素材過多、過大等。我們知道傳統的圖片文件格式有 PNG、JPEG 等，這種類型的圖片格式無法直接被 GPU 讀取，需要先經過 CPU 解碼后再上傳到 GPU 使用，解碼后的數據以 RGB(A)形式存儲，無壓縮。推薦語:今年淘寶在終端技術上做了三個很重要的探索:一、前端和移動端在技術上開始融合，例如技術架構、工具體系的設計

16、上都進行了貫通設計。二、基于Web的研發模式+增強的跨平臺容器/引擎+原子化能力的Native原生架構，使前端和移動端在業務迭代上具備同等交付能力，提升效率。三、前端技術深入到業務領域，打破過去局限于技術本身(多樣性和深入度)的探索上，使技術能夠真正給業務帶來價值。期待這些嘗試能夠為終端領域帶來新的變化。阿里巴巴資深技術專家 舒文推薦語:過去的一年里，淘寶用戶時長及瀏覽深度增長對性能體驗的訴求愈發強烈，業務加速創新對交付效率的要求提升，對既有有研發模式的挑戰更大，都推動了淘寶終端技術體系不斷演進。本篇重點分享在用戶體驗改善、研發效能破障、架構體系演進等方面的背后思考與創新實踐，希望為大家帶來一

17、定啟發與幫助。阿里巴巴資深技術專家 弘禹201年度精選技術棧內容終端技術篇/技術經典總結技術人的百寶黑皮書2022版大淘寶技術出品而紋理壓縮顧名思義是一種壓縮的紋理格式，它通常會將紋理劃分為固定大小的塊(block)或者瓦片(tile)，每個塊單3簡介WebGL擴展名格式ETC1WEBGL_compressed_-texture_etc1ETC1WEBGL_compressed_-texture_etc1ASTCPVRTCS3TCWEBGL_compressed_-texture_astcWEBGL_compressed_-texture_pvrtcWEBGL_compressed_-text

18、ure_s3tcASTC(Adaptive Scalable Texture Compression)是目前最強大的紋理壓縮格式，由ARM&AMD研發。ASTC同樣是基于block的壓縮方式，但塊的大小卻較支持多種尺寸，比如從基本的4x4到12x12；每個塊內的內容用128bits來進行存儲，因而不同的塊就對應著不同的壓縮率；相比ETC，ASTC不要求長寬是2的冪次方。PVRTC(PowerVR Texture Compression)，專為 PowerVR 圖形核心系列設計，IOS平臺都支持，它使用2張雙線性放大的低分辨率圖，根據精度和每個像素的權重，融合到一起來呈現紋理；PVRTC 2-b

19、pp把一個84的像素單元組壓成一個64位的數據塊，壓縮效果比較差；PVRTC 4-bpp把一個44的像素單元組壓成一個64位的數據塊；PVRTC壓縮要求圖片的大小必需是正方形而且邊長必需是2的冪次方。S3TC(S3 Texture Compression)基本思想是把4x4的像素塊壓縮成一個64或128位的數據塊，有損壓縮。S3TC算法有五種變化DXT1-DXT5，一般在桌面設備上面使用，詳見wiki。ETC(Ericsson Texture Compression)是Khronos 開放標準，專利來自于瑞典愛立信公司，它在移動平臺中廣泛采用，是一種為感知質量設計的有損算法，它基于人眼對亮度而

20、不是色度更敏感這一事實，在每個block定義四種不同的亮度偏移，即四種不同的顏色可用，可以認為這些顏色就是一個局部調色板，ETC會把4x4的像素塊壓縮成一個64或128位的數據塊。ETC有兩種壓縮格式：ETC1和ETC2。紋理長寬必須是2的冪次方；ETC1基本所有Android機型都支持，但是缺陷是不支持Alpha通道；ETC2是ETC1的擴展，向下兼容ETC1。支持Alpha，但是需要開啟OpenGL ES 3.x。01年度精選技術棧內容終端技術篇/技術經典總結技術人的百寶黑皮書2022版大淘寶技術出品4壓縮紋理素材生產如上所示，設計師產出png/jpeg等素材后，可以通過工具生成.ktx格

21、式的壓縮紋理素材，隨后就可以在項目中直接使用了。不同格式的壓縮紋理生產工具也不一樣(PVETextTool、Adreno Texture Tool、.)，而為了在各個平臺中都能使用，通常需要生成不同格式的壓縮紋理，社區有一些工具做了二次封裝，可以生成多種格式的壓縮紋理，如texture-compressor等。KTX文件格式KTX(Khronos texture)是一種通用的紋理壓縮存儲格式，OpenGL(ES)、Vulkan等均支持，KTX文件中包含了紋理加載所需的所有參數及數據，比如format、type、寬高等等，更多信息見wiki。如下是一個ktx文件的內容：01年度精選技術棧內容終端

22、技術篇/技術經典總結技術人的百寶黑皮書2022版大淘寶技術出品5基于這個格式，可以實現KTX Loader，用于解析KTX資源，生成紋理(通常游戲引擎會自帶)。如下所示，讀取KTX文件到ArrayBuffer然后解析拿到元信息:/KhronosTextureContainerconstructor(arrayBuffer,facesExpected,baseOffset=0)this.arrayBuffer=arrayBuffer;this.baseOffset=baseOffset;/Test that it is a ktx formatted file,based on the firs

23、t 12 bytes,character representation is:/,K,T,X,1,1,r,n,x1A,n /0 xAB,0 x4B,0 x54,0 x58,0 x20,0 x31,0 x31,0 xBB,0 x0D,0 x0A,0 x1A,0 x0A const identifier=new Uint8Array(this.arrayBuffer,this.baseOffset,12);if(identifier0!=0 xAB|identifier1!=0 x4B|identifier2!=0 x54|identifier3!=0 x58|identifier4!=0 x20

24、|identifier5!=0 x31|identifier6!=0 x31|identifier7!=0 xBB|identifier8!=0 x0D|identifier9!=0 x0A|identifier10!=0 x1A|identifier11!=0 x0A)return;/load the reset of the header in native 32 bit uint const dataSize=Uint32Array.BYTES_PER_ELEMENT;const headerDataView=new DataView(this.arrayBuffer,this.base

25、Offset+12,13*dataSize);const endianness=headerDataView.getUint32(0,true);const littleEndian=endianness=0 x04030201;this.glType=headerDataView.getUint32(1*dataSize,littleEndian);/must be 0 for compressed texturesthis.glTypeSize=headerDataView.getUint32(2*dataSize,littleEndian);/must be 1 for compress

26、ed texturesthis.glFormat=headerDataView.getUint32(3*dataSize,littleEndian);/must be 0 for compressed texturesthis.glInternalFormat=headerDataView.getUint32(4*dataSize,littleEndian);/the value of arg passed to pressedTexImage2D(,x,)this.glBaseInternalFormat=headerDataView.getUint32(5*dataSize,littleE

27、ndian);/specify GL_RG-B,space after the header for meta-data123456789101112131415161718192021222324252627282930313233343501年度精選技術棧內容終端技術篇/技術經典總結技術人的百寶黑皮書2022版大淘寶技術出品6this.pixelWidth=headerDataView.getUint32(6*dataSize,littleEndian);/level 0 value of arg passed to pressedTexImage2D(,x,)this.pixelHeig

28、ht=headerDataView.getUint32(7*dataSize,littleEndian);/level 0 value of arg passed to pressedTexImage2D(,x,)this.pixelDepth=headerDataView.getUint32(8*dataSize,littleEndian);/level 0 value of arg passed to pressedTexImage3D(,x,)this.numberOfArrayElements=headerDataView.getUint32(9*dataSize,littleEndi

29、an);/used for texture arraysthis.numberOfFaces=headerDataView.getUint32(10*dataSize,littleEndian);/used for cubemap textures,should either be 1 or 6this.numberOfMipmapLevels=headerDataView.getUint32(11*dataSize,littleEndian);/number of levels;disregard possibility of 0 for compressed texturesthis.by

30、tesOfKeyValueData=headerDataView.getUint32(12*dataSize,littleEndian);/the amount of space after the header for meta-data .36373839404142434445var ext=gl.getExtension(WEBGL_compressed_texture_etc);var texture=gl.createTexture();gl.bindTexture(gl.TEXTURE_2D,texture);pressedTexImage2D(gl.TEXTURE_2D,0,e

31、xt.COMPRESSED_RGBA8_ETC2_EAC,512,512,0,textureData);12345601年度精選技術棧內容終端技術篇/技術經典總結技術人的百寶黑皮書2022版大淘寶技術出品7技術人的百寶黑皮書2022版大淘寶技術出品01年度精選技術棧內容終端技術篇/技術經典總結8結論：1.相比jpeg等圖片格式，紋理壓縮通常體積會更大，這會導致IO時間變長；2.不同格式的紋理壓縮體積也不一樣，壓縮率高體積雖然降下來，但是素材質量會降低，使用時需要權衡；3.紋理壓縮格式GZip壓縮效果不明顯；素材大小1024x1024：技術人的百寶黑皮書2022版大淘寶技術出品01年度精選技術棧

32、內容終端技術篇/技術經典總結9技術人的百寶黑皮書2022版大淘寶技術出品01年度精選技術棧內容終端技術篇/技術經典總結下載時間&內存測試機型:pixel4、iPhone11ProMax游戲引擎:pixi.js壓縮紋理在小程序實際場景中的性能表現批量加載JPEG紋理內存增長情況1001年度精選技術棧內容終端技術篇/技術經典總結技術人的百寶黑皮書2022版大淘寶技術出品批量加載ASTC紋理內存增長情況不同紋理格式GPU上傳時間結論：紋理壓縮格式相比普通紋理內存優勢巨大，可以減少50%以上內存占用，但與此同時，素材下載時間會延長；結論：紋理壓縮格式GPU上傳時間幾乎可以忽略不記，相比普通紋理具有巨大

33、的優勢，也可以抵消一部分壓縮紋理下載的耗時；紋理上傳GPU時間11小程序Canvas紋理壓縮實現方案小程序下，我們是基于 OpenGL ES API 封裝 WebGL API，紋理壓縮也不例外，由于WebGL擴展中支持的紋理壓縮格式在OpenGL ES中都有對應實現，比如 WEBGL_compressed_texture_astc擴展對應到GL的擴展名為 GL_KHR_texture_compression_astc_ldr等，因此只需要根據擴展名稱映射到OpenGLES實現即可，比較簡單，這里不再展開?？偨Y紋理壓縮在現代計算機圖形中占據重要定位，現如今主流移動設備GPU都已支持紋理壓縮，在實

34、際場景中可以充分利用此能力優化游戲應用以帶來更好的用戶體驗。參考1.http:/sv-journal.org/2014-1/06/en/index.php?lang=en#82.https:/ -mobile-graphics-world/5.https:/ in無線到如今，集團移動技術發展十余年，歷經幾個關鍵階段，第一階段，解決大規模業務并發研發的痛點，定義了Atlas（容器化框架,提供組件解耦、動態性等支持）架構；第二階段，建設ACCS（淘寶無線全雙工、低延時、高安全的通道服務）長連雙工加密網絡能力，補齊端到端互 操作移動服務能力追趕行業；第三階段，面向業務特性建設Weex、小程序等動態化

35、研發框架，移動技術進入動態化跨平臺時期。中后期通過移動小組機制進行各BU拉通和能力共建。自此，移動基礎設施基本成型，各個領域各自沉淀若干組做到能力復用，App基本形成上層業務、中間研發框架或容器、基礎能力三層的架構。我們團隊作為無線端側基礎設施的承建方，過去重點是負責集團移動端的基礎能力建設，近年來，團隊重點深入淘寶業務場景展開性能優化，通過體驗優化項目橫向剖析App架構和及相關調用鏈路，感受到集團App普遍存在如下共性問題：(圖1 淘寶App架構挑戰)13以上是從APP結構的角度對當前客戶端在運維排查、度量監控、全鏈路優化等方面的不足進行的一些思考，也是我們后續的發力方向?？捎^測體系監控到可

36、觀測性的演變可觀測性是一套理念系統，沒有對技術實現的具體要求，重點是通過引入該理念，將理念應用到我們的業務迭代和問題洞察中。傳統的運維可能只能給我們帶來最頂層的告警和異常的概況，當需要更深層次的錯誤信息定位的時候，往往會通過建群拉人，然后先通過人肉找尋問題的特征，甚至是某個模塊的開發承擔起分析各個模塊的依賴關系等的工作，問題處理基本涉及3個角色以上（業務、測試、開發、架構、平臺等）。01年度精選技術棧內容終端技術篇/技術經典總結技術人的百寶黑皮書2022版大淘寶技術出品運維排查效率低下：首先是監控階段，多數問題無監控或者監控上報后的信息無法支撐更有效的分析，需要依賴日志進行問題排查；其次是沒有

37、日志的問題，發生異常時并不會主動上傳日志，需要手動撈取，用戶不在線更是拉取不到日志；拉取到日志后，還會繼續遇到日志讀不懂的問題問題；跟服務端有關的鏈路，還會遇到服務端鷹眼日志只保存5分鐘的問題，經過這樣一輪下來，基本時間已經過去半天.端到端追蹤不完整：一個完整的業務鏈路，流量會穿越端到端多層，以一次下單為例，通過客戶端所觸發的網絡請求到達服務器之后，會經過若干客戶端模塊處理、觸發N次后端應用調用以及歷經移動網絡的不穩定性，試想一下，這些調用中有哪些出問題會影響這次下單交易，有哪些步驟會拖慢整個處理流程、請求沒返回不清楚是服務端問題還是網絡問題，假如各調用全鏈路性能定義不清，意味著各層問題得不到

38、充分暴露，這些因素都是需要考慮的，加上端側天然異步調用，導致各階段度量和全鏈路打通存在重大挑戰，目前現狀就是客戶端各層沒有統一調用規范，并且缺乏拓撲結構，無法還原調用鏈路，導致端到端無法追蹤。優化缺少統一口徑：過去因為各研發框架性能口徑自閉環，不管是客戶端原生技術，還是跨平臺技術都是面向技術視角統一采集通用的技術口徑，這種情況會天然導致各業務實現和表現差異巨大，通俗說就是不接近用戶體感，會導致線上的數據難以反應真實情況及優劣趨勢，長久以來，淘寶的體驗也一直在劣化，每年基本都要靠運動式方式來搞體驗優化，無法常態化保持。移動Paas流程賦能成本：大量的SDK組件輸出集團各BU后，基礎能力嵌入到不同

39、的App宿主環境后，同樣會遇到上面提到的幾類問題，對各BU同學來說，基礎設施更是黑盒，如果問題涉及到基礎設施，排查過程更加艱辛，加上沒有現有的工具可以自助診斷問題在哪，遇到問題只能過來咨詢，各種拉群拉人，導致答疑成本居高不下。1401年度精選技術棧內容終端技術篇/技術經典總結技術人的百寶黑皮書2022版大淘寶技術出品相比傳統的監控，可觀測性能夠通過結合數據，并且將數據有機聯系在一起，產生更好的連接，幫助我們更好的觀察系統的運行狀況，快速定位和解決問題。監控告訴我們系統的哪些部分是工作的，而可觀測性告訴我們那里為什么不工作了，下圖2說明了兩者之間的關系，監控側重宏觀大盤展現，而可觀測性包含了傳統

40、監控的范疇。從上圖來看，核心還是觀察各個模塊以及關鍵調用和依賴等的輸出，基于這些輸出來判斷整體的工作狀態，業界通常會把這些關鍵點總結為Traces、Loggings、Metrics?？捎^測性關鍵數據(圖2 監控和可觀測的關系)(圖3 可觀測性關鍵數據)1501年度精選技術棧內容終端技術篇/技術經典總結技術人的百寶黑皮書2022版大淘寶技術出品結合Traces、Loggings、Metrics的定義和淘寶現有情況，做了一些解讀：因此，我們需要圍繞以上這些問題對移動技術領域全鏈路進行定義，并建立起相關領域級的分析能力和好的評價標準，才能更深刻的洞察移動端的問題所在，才能在問題排查和性能度量領域持續

41、服務好集團各App以及跨域的問題。全鏈路可觀測性架構上述可觀測體系理念在后端有一些實踐落地，但回歸到移動領域的特性和現狀，有種種問題如下：Loggings（日志）：基于現有TLOG（無線端到端日志系統）日志通道，展現的是App運行時產生的事件或者程序在執行的過程中間產生的一些日志，可以詳細解釋系統的運行狀態，如頁面跳轉、請求日志、全局CPU、內存使用等信息，多數日志是沒有實現串聯的，現在引入結構化的調用鏈路日志后，日志在調用鏈場景結構化后其實可以轉變為Trace，支撐單機排查。Metrics（指標）：是聚合后的數值，偏宏觀大盤使用，對于問題定位缺乏細節展示，一般有各種維度、指標，Metrics

42、數據量一般很大，需要針對場景做一些采樣控制。Traces（追蹤）：是最標準的調用日志，除了定義了調用的父子關系外（一般通過TraceID、SpanID），一般還會定義操作的服務、方法、屬性、狀態、耗時等詳細信息，通過Trace能夠代替一部分Logs的功能，長期看通過Trace的聚合也能得到每個模塊、方法的Metrics度量指標，但日志存儲大，成本高。調用規范的問題：與云端的差異是端側完全異步，異步API極其豐富，且沒有統一調用規范。多技術域的問題：研發框架數量眾多，能力對外黑盒，如何串聯存在大量難以感知的成本。端云差異的問題：端側的海量分布式設備，意味著可觀測模式的挑戰與服務端也有本質差異，l

43、ogging與metrics在服務端可以基于一套體系完全上報實現，但單機埋點和日志量差異極大，這也是端側埋點系統和日志系統分離的原因，端側則需要實現如何兼顧海量設備的單機問題排查和大數據下的指標趨勢定義。端云關聯的問題：端到端現實一直是割裂狀態，以端側為視角如何更好感知后端狀態，如何做關聯，如怎么持續推進serverRT（后端請求調用耗時）從IDC（互聯網數據中心）到CDN覆蓋，端側全鏈路標識如何讓后端也感知。1601年度精選技術棧內容終端技術篇/技術經典總結技術人的百寶黑皮書2022版大淘寶技術出品(圖4 全鏈路可觀測架構定義設想)數據層：定義指標規范和采集方案，基于Opentracing（

44、分布式跟蹤規范）數據上報。領域層：圍繞問題發現到問題定位、性能持續優化體系、技術升級沉淀幾方面演進。平臺層：沉淀集團&競對視角的比對，結合線上線下指標，引入廠商視角，驅動App性能提升。業務層：全鏈路視角，打通端到端，除了客戶端同學，還可以服務不同技術?？缬虻难邪l人員?；仡櫲溌房捎^測項目的目標，我們設定為“打造全鏈路可觀測體系，改善性能并驅動業務體驗改善，提升問題定位效率”，后續章節會重點講解每一層的實踐。移動端opentracing可觀測架構全鏈路構成1701年度精選技術棧內容終端技術篇/技術經典總結技術人的百寶黑皮書2022版大淘寶技術出品(圖5 端到端情況、詳情場景分層圖)場景定義：一

45、次用戶操作為一個場景，如點擊、滑動都是單獨的場景，場景也可以是多個單個場景的組合。能力分層：不同場景，有業務類，框架類、容器類、請求類的調用，可以對每個領域進行分層。階段定義：不同分層有各自的階段。如框架類有4個本地階段，而請求類可以包含后端服務端處理階段。用戶動線：一次動線由若干場景組成。單場景+單階段的組合全鏈路單場景+若干分層+若干階段組合的全鏈路若干場景+若干分層+若干階段組合的全鏈路 .端到端現有鏈路長，端側存在各類研發框架和能力，雖然后端調用鏈路明確，但從全鏈路視角看，并沒有與端側打通。以用戶瀏覽詳情動線為例，一次首屏打開，會觸發奧創、MTOP（無線網關）、DX三個模塊不同的調用時

46、序，不同的模塊有各自的處理過程，不同階段有不同的耗時和狀態（成功、失敗等）；接著繼續看滑動，可以看到模塊的調用時序組合又不一樣，因此不同場景下可以由若干要素隨機組合，需要根據用戶實際場景，劃分若干維度來定義全鏈路：全鏈路，就是把復雜的大調用分解為有限個結構化的小調用，并且可以衍生出各種case：Falco-基于OpenTracing模型全鏈路為了支持Logs+Metrics+Tracing 行業標準，引入分布式調用規范opentracing協議，在上述的客戶端架構上進行二次建模（后續簡稱為Falco）。OpenTracing 規范是 Falco 的模型基礎，以下不再列舉，完整可參考OpenTr

47、acing設計規范，https:/opentracing.io/docs/overview/。Falco定義了端側領域的調用鏈追蹤模型，主要表結構如下：1801年度精選技術棧內容終端技術篇/技術經典總結技術人的百寶黑皮書2022版大淘寶技術出品(圖6 Falco數據表模型)(圖7 Falco關鍵實現)span公共頭：黃色部分，對應OpenTracing規范的Span基礎屬性。scene：對應OpenTracing的baggage部分，會從根span往下透傳，存放業務場景，命名規則為業務標識_行為。比如詳情首屏為ProductDetail_FirstScreen、詳情刷新為ProductDeta

48、il_Refresh。layer:對應OpenTracing的Tags部分，定義了層的概念，目前劃分為業務層、容器層和能力層。處理業務邏輯的模塊歸屬業務層，命名為business；提供視圖容器歸屬容器&框架層，如DX、Weex都是，命名為frame-workContainer；僅提供一個原子能力的模塊，歸屬能力層，命名為ability，如mtop、picture，層可應用于對同層同能力的不同模塊進行橫向性能對比。stages：對應OpenTracing的Tags部分，表示一次模塊調用包含的階段。每一層基于領域模型劃分了關鍵階段，目的是讓同層的不同模塊具備一致的對比口徑，如DX和TNode對比，

49、可以從預處理耗時、解析耗時、渲染耗時衡量彼此優劣。比如預處理階段名為preProcessStart，也可以自定義。module：對應OpenTracing的Tags部分，更多的是邏輯模塊。比如 DX、mtop、圖片庫、網絡庫。Logs：對應OpenTracing的Logs部分，日志僅記錄到TLog，不輸出到UT埋點。Falco-關鍵要點19技術人的百寶黑皮書2022版大淘寶技術出品01年度精選技術棧內容終端技術篇/技術經典總結(圖8 Falco領域問題模型)端側traceID：滿足唯一性、生成快、可擴展、可讀、長度短等原則生成。調用&還原抽象：由traceID和span多級序列號一路透傳，明確

50、上下游關系。端到端串聯：核心解決云端串聯的問題，端側ID透傳到服務端，服務端存放和鷹眼ID的映射關系；接入層返回鷹眼ID，端側全鏈路模型存在鷹眼ID，通過這樣的雙向映射關系，我們能知道一個未返回的請求究竟是因為在網絡階段沒有成功、還是沒有到達接入層、或者是業務服務沒有返回，從而將耳熟能詳、粗粒度的網絡問題變得可定義和可解釋分層度量：核心目的是讓同層的不同模塊具備一致的對比口徑，支撐框架升級后的性能橫向對比，思路為抽象客戶端領域模型，如以框架類為例子，雖然框架不同，但一些關鍵調用和解析是一致的，因此可以抽象成為標準階段，其它類似。結構化埋點：首先采用列式存儲，利于大數據集的數據聚合操作和數據壓縮

51、，減少數據量；其次，業務+場景+階段沉淀到一張表中，方便關聯查詢?；贔alco的領域問題沉淀：包括復雜問題的關鍵定義、追蹤問題的線索型日志、某些特殊訴求的埋點。所有領域問題的信息被結構化沉淀到Falco，領域技術開發者也可以基于沉淀的領域信息持續開展分析能力的建設，只有實現數據的有效性供給和領域性解釋合一，才能定義和解決更深層次的問題。1.2.3.4.5.6.基于Falco的運維實踐運維的范疇極為廣泛，圍繞問題發現、問題接手、定位分析、問題修復關鍵流程，從海量設備的指標觀測、告警，到單機排查、日志分析等，大家都知道要這么做，里面每個流程都涉及很多能力的建設，但實際執行起來很難做，各方也不認可

52、，淘寶客戶端一直以來存在指標準確性和日志拉取效率低下的問題。如APM性能指標為例，淘寶App過去很多指標不準，業務同學不認可，不能指導實際優化。本章節會從重點分享下淘寶App在指標準確性和日志拉取效率方面的相關優化實踐。20技術人的百寶黑皮書2022版大淘寶技術出品01年度精選技術棧內容終端技術篇/技術經典總結(圖9 問題扭轉用戶動線以及運維系統)宏觀指標體系以端性能橫向戰役為契機，基于用戶體感的體驗，APM開啟了相關升級工作，核心涉及啟動、外鏈以及各業務場景下的可視可交互指標，如何做到讓指標對應的終點更貼近用戶體感，主要有以下一些工作：以啟動為例，APM 在 校準后，包含了圖片上屏等階段后，

53、數據雖然上漲了，但更符合業務方訴求8060算法的升級：視覺有用的元素提取出來計算（如圖片和文字），剔除用戶不能感知的元素（空白控件、兜底圖），如制定視圖可視規范，滿足圖片庫、魚骨圖等自定義控件打標H5領域：支持UC 頁面元素可視可交互以及前端 JSTracker（事件埋點框架）回溯算法，與H5頁面可視算法打通深入復雜的場景：制定自定義框架可視規范，打通 Flutter、TNode（動態化研發框架）并校準等各類研發框架，8060算法交由各研發框架來實現。外鏈領域：打通H5頁面口徑，重新定義外鏈離開等負向動作。21技術人的百寶黑皮書2022版大淘寶技術出品01年度精選技術棧內容終端技術篇/技術經典

54、總結(圖10 校準后啟動數據趨勢)(圖11 校準后外鏈前后口徑數據對比)(圖12 單機排查問題定位核心功能)單機排查體系對于問題排查，目前核心還是基于TLOG，本次僅圍繞用戶問題排查動線中日志上報、日志分析、定位診斷關鍵環節遇到的問題(無日志、日志看不懂、定位難等)，介紹運維排查體系為提升問題定位效率做的努力。以外鏈為例，打通H5后，新口徑也出現了上漲，但更符合體感基于此戰役，已實現打通若干研發框架可視指標和校正工作。2201年度精選技術棧內容終端技術篇/技術經典總結技術人的百寶黑皮書2022版大淘寶技術出品提升日志上傳成功率，從幾個方面保障在排查問題時有日志供應過來，一是內置日志主動上傳能力

55、，在核心場景或問題反饋多時機觸發，提高日志觸達率，如輿情反饋、新功能上線發生異常時；二對TLOG能力進行升級，涉及到分片策略、重試、日志治理等優化，解決以往用戶反饋較多日志上傳的時效問題；最后是收集各類異常信息，作為快照，通過MTOP鏈路旁路上報，輔助還原現場。提升日志的定位效率，首先對日志做分類，如區分出頁面日志、全鏈路日志支持快速篩選過濾；接著是打通各個場景的全鏈路調用拓撲結構，目的是可以快速看出問題發生在哪個節點，以便快速分發處理；最后結構化錯誤、慢、UI卡等問題，原則是將領域問題的解釋權交給領域，比如卡頓日志有幾類，如APM凍幀、ANR、主線程卡頓等；業務類有請求失敗、請求RT大于xx

56、時間、頁面白屏等，通過各領域的能力 對接來提升問題的快速診斷定位能力。全鏈路追蹤能力建設，鷹眼（分布式跟蹤系統在阿里后端的實現）接入業務眾多，日志量大，不可避免要做日志的采樣，對于沒有命中采樣的調用，緩存只有5分鐘，需要想辦法在5分鐘內通知鷹眼保持更久的時間。第一階段，后端解析服務會解析出調用鏈的鷹眼ID，通知鷹眼服務存儲對應的trace日志，成功通知后可以存3天；第二階段感知網關發生異常，取出鷹眼ID，通知鷹眼存儲將存儲前置；第三階段，類似場景追蹤，獲取核心場景的鷹眼trace日志，嘗試放在摩天輪平臺上存儲。第一階段已經上線，可以做到關聯跳轉鷹眼平臺，一般從問題發生到排查都過了5分鐘，因此成

57、功率不高，還需要結合2、3階段進一步提升成功率，正在規劃開發中。平臺能力的建設，基于端側全鏈路日志做解析，在可視化方面，通過結構化展示全鏈路日志內容，方便快速部分節點的異常；還有就是基于結構化日志，對全鏈路日志中的耗時異常、接口報錯、數據大小異常等問題進行快速診斷。通過“全鏈路可視化”功能(圖10)，可以看到H5頁面spanID為0.1的network狀態為“失敗”，導致頁面打不開。通過“全鏈路診斷”耗時異常功能（圖11），可以看到大量network耗時分布在2s、3s+，有的甚至8s+，network階段發生在請求調用階段(傳輸)，與海外用戶訪問到阿里的CDN節點慢相關。以上是今年在運維做的

58、一些嘗試，目的是希望可以通過技術升級，在排查領域用技術賦能代替流程賦能。下面接著繼續給大家展示下淘寶的實踐和集團其它app接入的效果。全鏈路運維實踐淘寶卡頓問題排查內部同事反饋在海外用淘寶App，出現卡、部分頁面打不開等現象，經過上訴排查過程，提取到TLOG日志后。23技術人的百寶黑皮書2022版大淘寶技術出品01年度精選技術棧內容終端技術篇/技術經典總結(圖13 全鏈路可視化功能)(圖14 全鏈路卡頓診斷功能)24(圖15 餓了么全鏈路視圖-冷啟全鏈路)(圖16 餓了么全鏈路視圖-店鋪全鏈路)01年度精選技術棧內容終端技術篇/技術經典總結技術人的百寶黑皮書2022版大淘寶技術出品餓了么主鏈路

59、接入冷啟全鏈路店鋪全鏈路25(圖17 App性能指標體系)01年度精選技術棧內容終端技術篇/技術經典總結技術人的百寶黑皮書2022版大淘寶技術出品指標定義和規范：貼近用戶的感受，圍繞用戶點擊到內容呈現到滑動頁面的操作動線來定義相關指標，重點采集頁面打開、內容上屏、點擊響應、滑動等技術場景，如內容展現有頁面可視可交互、圖片上屏指標，滑動有滑動幀率(手指)、凍幀等指標來衡量。指標度量方案：原則是不同領域的指標交由對應領域負責，以卡頓指標為例，可以是廠商的口徑(蘋果MetricK-it)、也可以是自建的口徑(APM的主線程卡頓/ANR等)、還可以是不同業務域的自定義指標（場景全鏈路），如MTOP請求

60、失敗、詳情頭圖上屏等。指標組成：由線上集合指標和線下集合指標組成，基于線上和線下數據和相關規范，立足用戶視角和競對情況牽引APP體驗優化?；贔alco的優化實踐新指標體系現在重點介紹下我們怎么圍繞Falco可觀測模型，從端到端全鏈路視角構建線上性能基線，用數據驅動淘寶App體驗持續改善，首先就是數據指標體系的構建，主要有如下幾點：26(圖18 APM相關指標定義方案)(圖19 場景全鏈路-詳情首屏定義)01年度精選技術棧內容終端技術篇/技術經典總結技術人的百寶黑皮書2022版大淘寶技術出品APM為例定義了滑動相關的指標如下：場景全鏈路為例某個具體業務下，對于用戶的一次交互行為，從發起響應到結

61、束響應，從前端到服務端到客戶端的完整調用鏈路，詳情基于場景全鏈路下的詳情首屏指標：還有其他等等.可以看到，整個數據體系是多元化的，后續整個性能體驗數據會有一個標準的輸出，敬請期待。27(圖20 淘寶App全鏈路優化技術方案)01年度精選技術棧內容終端技術篇/技術經典總結技術人的百寶黑皮書2022版大淘寶技術出品數據拷貝多：現有網絡層機制，網絡庫存在hook攔截處理，基于NSURLConnection+URL Loading System 轉發到網絡庫進行網絡傳輸，涉及多次數據拷貝，中轉攔截處理非常耗時。線程切換多：線程模型過于復雜，完成一次請求頻繁切換線程。異步轉同步：原有請求使用一個隊列 N

62、SOperationQueue 來處理任務，底層維護的這個隊列把請求和響應綁在一起，使得發送之后要等待響應結果回來才會釋放，HTTP Operation 占住完整的一個HTTP收發過程的全部IO，違背了網絡請求的并行性，operation queue容易打滿阻塞。新指標體系下的優化FY22 平臺技術圍繞全鏈路視角，以體驗為出口，深入業務開展摸排優化，圍繞指標定義并拆解問題域，面向用戶真實體感開展各大專項優化。我們自底向上一一介紹，通用的網絡層策略優化，如何圍繞請求周期，從連通性-傳輸層-超時策略提升；面向用戶體感的有技術策略升級，如網關和圖片的優化；面向業務場景的技術改造，會場框架的預處理預加

63、載、安全保鏢的輕量化實踐，甚至是業務上的體驗分級，如首頁信息流低端機下不啟用端智能，下面會重點介紹相關實踐。請求精簡提速-極簡調用實踐以MTOP請求作為一個場景，鏈路主要涉及MTOP到網絡庫的交互，通過對全鏈路線程模型現狀分析，從MTOP發起到網絡層接收到會幾點會導致請求慢：28(圖21 線程模型優化前后-極簡調用)(圖22 極簡調用AB優化幅度)01年度精選技術棧內容終端技術篇/技術經典總結技術人的百寶黑皮書2022版大淘寶技術出品簡化線程模型:跳過系統URL Loading System hook機制，完成收發數據線程切換，減少線程切換。避免弱網阻塞：數據包Sending 與 Receiv

64、ing 拆分處理，空口長RT不影響 I/O 并發容量；汰換廢棄API：升級老舊NSURLConnection 到直接調用 網絡庫API。以上幾點問題，在大批量請求、系統資源競爭激烈場景下下(冷啟動，幾十個請求一擁而上)，更為明顯。改造方案，通過MTOP直接調用網絡庫接口來獲得較大性能體驗提升 數據效果：可以看到，在系統資源更為緊張環境下，如低端機上優化幅度更為明顯。弱網策略優化-Android網絡多通道實踐在WIFI信號差、弱網環境下，有時候多次重試對成功率提升效果并不明顯。系統提供了一種能力，允許設備在WIFI環境下將請求切換蜂窩網卡的能力。網絡應用層可以利用該技術，減少請求的超時等一類錯誤

65、，提升請求的成功率。29(圖23 Android多通道網絡能力優化+用戶合規授權)01年度精選技術棧內容終端技術篇/技術經典總結技術人的百寶黑皮書2022版大淘寶技術出品方案前提：當前Wi-Fi網絡環境是否支持蜂窩網絡。觸發時機：當請求發出超過一定時間未返回數據后，觸發切換蜂窩網絡重試的請求，原先流程的請求不中斷，使用優先返回的通道的請求響應，晚返回的會取消。時間控制：根據特定場景Orange配置，后續還需要靈活根據網絡強弱來動態調整。產品形態&合規上：使用時給用戶透出文案“正在同時使用WIFI和移動網絡改善瀏覽體驗，可在設置-通用里關閉”，彈出策略為 每次啟動首次功能觸發。在Android

66、21之后，系統提供了新的獲取網絡對象的方式，即使設備當前具有通過以太網的數據連接，應用程序也可以使用此方法來獲取連接的蜂窩網絡。所以，當用戶設備同時存在WIFI和蜂窩網絡的情況下，可以在特定策略下將不同請求同時調度到以太網和蜂窩網兩個網卡通道上，實現網絡加速。核心改動點：數據效果：在網絡資源競爭劇烈的情況下，WiFi+蜂窩雙通道網絡場景下，長尾和超時率優化較為明顯，AB數據，首頁API，P99/P999分位性能分別提升23%/63%，錯誤率減少1.19，首頁圖片，P99/P999分位性能分別提升12%/58%，錯誤率減少0.41。30(圖24 圖片設備分級規則)01年度精選技術棧內容終端技術篇

67、/技術經典總結技術人的百寶黑皮書2022版大淘寶技術出品第一階段，業務分級需要豐富的策略庫和判斷條件來實現分級，我們將在核心組件上沉淀這部分通用能力，幫助業務快速的實現業務分級能力。第二階段，隨著大量的業務都接入了分級能力，積累了大量的業務分級策略以及AB數據，那么可以去做單點業務分級策略的推薦&最優化，實現大量相似的業務可以快速復用，提升效率。技術策略分級-圖片分級實踐不同設備性能千差萬別，業務的復雜度也越來越高，很多業務無法在低端設備上讓用戶體驗到應有的效果，反而會帶來卡頓等不良的體驗。以往會通過“延遲、并發、預加載”等手段來優化性能，但只是規避了問題，核心鏈路仍然要要直面關鍵的調用耗時。

68、所以，我們需要對業務做體驗分級，基于對業務流程的分級處理，讓高端設備體驗最完美復雜的流程，低端設備也能順滑的使用核心功能，理想是期望實現 用戶體驗&業務核心指標 的雙高，退一步來說，讓部分功能有損(不影響核心業務指標)的情況下，讓性能體驗更佳，初步的設想是希望分2步走來實現：傳統CDN適配規則會根據網絡、view大小、系統等因素動態拼裝獲取最佳的圖片尺寸來減少網絡帶寬、位圖內存占用，提升設備圖片加載體驗，本次設備分級視角，并且會基于UED給出的規范，實現壓縮參數可配置，擴展原有CDN適配規則，實現不同機型的圖片分級策略，通過該能力，可以讓圖片的尺寸進一步縮小，加快圖片上屏。31(圖25 安全免

69、簽架構變化)01年度精選技術棧內容終端技術篇/技術經典總結技術人的百寶黑皮書2022版大淘寶技術出品網關協議升級：協議升級支持免簽，對外提供設置免簽接口，若業務API設置免簽，攜帶頭到網絡庫。AMDC調度服務：穩定性考慮，目前短期會先通過AMDC（無線網絡策略調度服務）調度到線上安全生產環境，因此AMDC調度模塊會根據描述標識判斷是否返回客戶端免簽vip，功能穩定性后，會靈活調度到線上主站環境。驗簽模塊遷移：安全延簽能力前置在AServer接入層，基于運維成本考慮，能力會從Aserver統一遷移到安全，后續Aserver不會有延簽模塊，安全會根據API/header特征 決定啟用驗簽等功能。M

70、TOP免簽錯誤重試：免簽情況下，MTOP層遇到非法簽名請求失敗會觸發降級老鏈路，保障用戶體驗。輕量化鏈路架構-安全免簽實踐外鏈拉端鏈路從啟動到海關請求再到落地頁加載（主請求仍是MTOP），涉及多次安全加簽，加簽屬于CPU密集型任務，低端機長尾明顯，拉端耗時過長會導致流量跳失，FY22 S1 在巨浪業務上，拉端鏈路做了很多性能優化，優化性能可以帶來跳失率的降低，目前性能大頭海關請求，海關請求安全加簽耗時占比高，因此希望跳過安全加簽，業務可以根據情況使用，提升進端的流量價值，鏈路涉及到MTOP、Aserver（統一接入層）、安全多方改造：3201年度精選技術棧內容終端技術篇/技術經典總結技術人的百

71、寶黑皮書2022版大淘寶技術出品總結&展望總結本文主要闡述了面對移動端現有挑戰，如何通過實現調用鏈路Tracing、標準Logging及場景化追蹤完成可觀測能力的建設，并基于全鏈路視角和新可觀測能力，打造全鏈路運維體系和性能持續優化體系，補齊移動端長久缺失的調用鏈追蹤能力、解決復雜調用場景下問題的快速定位、改變過去拉群人肉排查的低效過程，開始了流程賦能到技術賦能的轉變，并圍繞該能力構建全鏈路Metrics指標，打造全鏈路性能指標體系，深入業務場景展開治理，升級平臺技術能力，用數據驅動業務體驗改善和體驗的長效追蹤。不足雖然淘寶App陸續在接入各類場景，但離15分鐘內定位出問題還有不小的差距，相關

72、的卡點還較多，如日志上報成功率、服務端日志獲取的有效性、問題定位效率的提升、接入源頭的數據質量檢驗產品化&技術化、領域技術方對問題的認識和持續沉淀結構化信息，最后就是整個產品的用戶體驗，需要持續優化。展望延續阿里巴巴移動技術小組的移動原生技術理念，我們要做好技術做好體驗，需深入移動域腹地，直面東西向多研發框架、南北向端到端全鏈路等領域挑戰。18年體驗優化一期，我們在請求領域就引入類似理念并開展嘗試，直到如今尋求到合適的結構化理論基礎，并通過立足移動端特性開展深入實踐，持續做厚領域問題的定義和解決模型。希望打造出移動域可觀測技術體系、形成架構沉淀。參考資料1.可觀測性技術大會 https:/ h

73、ttps:/opentracing.io/docs/overview/3.萬字破解云原生可觀測性 https:/ APISIX https:/ 是什么 https:/ APM 分析報告 https:/ Relic APM https:/ https:/ 簡析 https:/ https:/ 分布式追蹤系統 https:/ Request：主要包括，鑒權、網絡傳輸、服務端處理、Network SDK的數據處理等。3.Data Parse：業務上的數據解析，如json解析等的操作，以及線程間的切換等耗時。4.UI Refresh：主要是視圖布局，渲染的操作。5.First Item Render：

74、第一張卡片的渲染時間。從上面數據上來看，客戶端的耗時主要是：1.請求前的參數綁定過程2.請求后數據解析3.數據上屏的圖層布局以及渲染4.異步請求過程中的線程不斷切換造成切換耗時客戶端上這些操作往往在整個鏈路上占比較小，且過程優化空間較??；然而大頭往往在這兩個方面：網絡傳輸和服務端處理。方案降低ServerRT（服務端處理耗時）通常降低服務端處理耗時，是由服務端小伙伴來優化，當然優化過程中需要端上一起協助完成，大致了解一下服務端耗時的幾種處理方案；主要有這幾種方式：降低網絡傳輸時間接口加緩存：合理設計臨時緩存、持久緩存可以提高接口性能內部接口并發請求：通常一個復雜的接口需要調用下游幾個業務的接口

75、，如果合理的進行并發請求，將會收到很好的效果異步化：如寫日志，更新緩存等不會影響接口準確性的非核心流程，可以采用異步方式進行處理，不阻塞主計算邏輯處理數據批量處理：接口存在較大量計算，可以通過批量分批次(分而治之)方式來解決大量數據計算耗時問題sql加索引：數據庫SQL是最常見的性能瓶頸，如SQL子查詢、不合理索引設計、全表掃描、大量數據返回、大SQL等，通過監控平臺查看慢查詢SQL可立即找出影響接口性能瓶頸關鍵點1.2.3.4.5.3501年度精選技術棧內容終端技術篇/技術經典總結技術人的百寶黑皮書2022版大淘寶技術出品雖然現有階段大多數用戶網絡已經很不錯了，但是還是有很多場景下，網絡耗時

76、占比還是非常高，尤其長尾數據中，網絡耗時往往是最大的占比，所以網絡耗時的優化依然是非常重要；當然端上的小伙伴在這個階段可參與的空間也更多。主要有哪些方式呢？接口多段返回通常一個接口承載了較多的內容的話，其內容就會無限的進行膨脹，如果將埋點，日志，反饋等非主線的數據進行多段返回的話將會有很大的收益，此方案主要結合接口組成進行分析；當然，此方案改動量也比較大，成本也比較高。更換協議大多數我們接口使用的是TCP協議，相比來說如果更換UDP協議，接口返回速度會快不少，詳細原因可以翻一下資料學習一下，這里不再多說。目前也已經有成熟的方案，比如阿里的XQUIC，有感興趣的可以了解一下，具體的收益我這里也還

77、在測試中?？s小網絡包為何縮小網絡包會降低網絡傳輸時間呢？客戶端和服務端網絡通信時數據傳輸過程如下圖所示：3601年度精選技術棧內容終端技術篇/技術經典總結技術人的百寶黑皮書2022版大淘寶技術出品數據包越大，則在光纖傳輸時所需的時間就會越久，因此接收方等待數據包的時間也會更長，最終會導致應用層等待數據時間變長。還有，由于TCP采用的滑動窗口機制來提升傳輸性能，窗口的大小受接收端處理速率和網絡擁塞情況影響，因此如果傳輸的包越小，則可以在盡量少的窗口周期完成數據的傳輸，減少響應的等待時間，反之，響應等待更長。從上面幾個方式來看，業務客戶端能夠做的一部分其實是縮小網絡包的大小，那么我們下面介紹一下縮

78、小網絡包研究。收益縮小接口網絡數據包方案與收益 縮小網絡包，是否真的會對網絡的傳輸有效果呢？我們對數據包的大小與網絡傳輸時長做了一個線下的實驗，以下是實驗的數據：3701年度精選技術棧內容終端技術篇/技術經典總結技術人的百寶黑皮書2022版大淘寶技術出品其他條件不變，我們將一頁返回數據改變后的數據；可以看出網絡傳輸時間與數據包的大小是有著正相關的關系的。減少網絡包大小有哪些措施呢？更優的壓縮算法不同的壓縮算法，壓縮算法是不一樣的：圖片來源于網上大佬的圖片但是，壓縮算法的調整需要考慮方面很多，如果僅僅是網絡時間的收益在很多場景下可能成本較高，暫未考慮。3801年度精選技術棧內容終端技術篇/技術經

79、典總結技術人的百寶黑皮書2022版大淘寶技術出品減少返回數據個數減少返回數據個數，服務端的同學已經在投入，但是遇到了一個問題，數據個數的減少就需要增加請求的次數，機器資源的成本就會升高，需要申請機器的資源；那就比較尷尬了，本身是優化，卻讓成本來買單。精簡返回字段在原有的請求數據上通過精簡字段，減少數據包的大小。這樣既能降低數據包，成本又不增高。如何做呢？下面來研究一下。精簡數據報文 做一個實驗一個接口的分頁接口數據包大小在1.5M左右，Server使用的是gzip（best模式）的壓縮方式，我進行壓縮后的大小為106KB左右。通常其他接口數據包大小壓縮后普遍在10KB以下，所以可以看出分頁接口

80、橫向對比來看，數據包大小是非常嚴重的。這也是為什么會選擇精簡數據報文作為優化手段一大原因。分析精簡數據報文需要根據業務的場景來看，我這里來舉一個我這邊實踐的例子：從數據包上分析，業務A的數據占比59.8%，而且該業務數據元素字段重復率非常高，來看一下去除該業務后的數據包大?。簭臄祿葘砜?，不同的卡片有大約18處的不同，其占比：占比=1-(5350/17439)0.693那么，此時就有一個問題了，重復的數據，經過壓縮后還會占包大小嗎？所以我就用服務端的壓縮方式對數據做了個壓縮：原始數據1472672降低率精簡后60758759.8%3901年度精選技術棧內容終端技術篇/技術經典總結技術人的百寶

81、黑皮書2022版大淘寶技術出品壓縮后降低率依然有46.9%。拿到這個結果后，如何做呢？數據查找表將重復的業務數據在第一頁的數據中建立字段的查找表，然后通過端上進行合并操作，具體方式：原始數據1472672降低率精簡后Gzip壓縮7851695%精簡后60758759.8%原始數據Gzip壓縮14789290%數據表明，針對重復字段的精簡，壓縮后依然是有效的。4001年度精選技術棧內容終端技術篇/技術經典總結技術人的百寶黑皮書2022版大淘寶技術出品但是，與服務端的同學對方案時，發現請求的第一頁數據放置查找表，服務端不容易實現，因為數據在下游。調整方案，將數據查找表改放置在每一頁數據中，這樣服務

82、端更改就非常少了，實現也比較簡單。但是數據放在每一頁，壓縮后還會有收益嗎？來看一下實驗的結果：采用壓縮方式：gzip的壓縮方式壓縮比：best模式（系統缺省值6）方案1：將負反饋數據查找表放在第一頁數據中：優化前后：降低45KB降低率：1-61/106 42.2%方案2：將負反饋數據查找表放置于每一頁數據的頭部：優化前后：降低43KB降低率：1-63/106 40.5%實驗發現，查找表的數據僅僅占用2KB，優化依然有效。4101年度精選技術棧內容終端技術篇/技術經典總結技術人的百寶黑皮書2022版大淘寶技術出品優化效果 精簡報文在原有的數據包下，線下實驗，精簡字段會將數據包從106KB降低至6

83、3KB；線下的實驗可以得到接近90ms的優化；縮小返回數據個數縮小接口返回數據的個數，從50個降低至20個，數據大小大約降低63KB，網絡傳輸耗時減低107ms；結論1.數據包的大小對于接口的性能、響應以及失敗率都有影響2.在一定場景下，數據中的重復字段對壓縮后數據包依然有較大的影響。注：1.網絡傳輸使用的是服務端的壓縮包，所以大小要看壓縮后的包大小2.精簡報文有很多同學可能都試過，實現后發現收益很小，所以需要先衡量包的大小會不會對網絡傳輸造成影響，如果僅僅是幾KB的優化，從上面實驗可以看出，基本收益不大，如果是上百KB，收益肯定是有的。團隊介紹我們是大淘寶技術-用戶產品技術，團隊主要負責電商

84、核心基礎鏈路業務和平臺的研發，包含：手機淘寶首頁、信息流、NewDetail、商品詳情、購物車、全域觸達、分享購物車、消息平臺等電商核心基礎能力及創新型業務。這里有世界一流的技術產品，有超大的電商基礎場景，有百億級別的數據、有超過百萬QPS的高并發流量，有豐富的業務場景，服務于10億級的消費者，這里有巨大的挑戰等著你的到來。4201年度精選技術棧內容終端技術篇/技術經典總結技術人的百寶黑皮書2022版大淘寶技術出品APM 頁面加載耗時校準作者：千諾出品：大淘寶技術在最新的 APM 自動化頁面加載耗時計算中，剔除了對用戶頁面加載體驗無效的元素，聚焦頁面加載體驗中的核心元素，既給了業務相對的自由度

85、，又達到了一定的加載體感準確性。背景APM 的全稱叫做 Application Performance Monitor，屬于應用性能監控部分。在手淘的 APM 中有一項特殊的數據，叫做頁面可視耗時，不同于業界常規的技術視角闡述數據，我們更傾向于從用戶體驗交互進行闡述。以 Activity 實現的頁面為例，在頁面加載過程中，用戶關心的是從點擊開始到最后頁面完全呈現，直至用戶可以進行交互的一個過程，而不是單純 Activity 的 Lifecycle 耗時，更不是技術視角的一個階段數據。更逼近用戶體驗的數據是我們在頁面加載上的追求。接下來我將從淘寶 APM 如何從用戶角度實現可視計算的歷史進行介紹

86、，并深入詳解淘寶對頁面加載耗時校準所做一些努力與改變。從0到1：可視計算頁面可視耗時可以拆解成起點與終點，起點爭議相對較少，使用的是 Activity onCreate 時間、Fragment onFragmentPreAttached 時間以及頁面跳轉時間，下面主要針對可視終點進行討論：為什么要引入可視計算？4301年度精選技術棧內容終端技術篇/技術經典總結技術人的百寶黑皮書2022版大淘寶技術出品在 APM 中，對于頁面打開耗時統計，常見有三類：Lifecycle、首幀、自定義埋點。監控 Lifecycle 是 Android 天然的一套監控耗時的方案，奈何生命周期的耗時只是頁面加載過程中

87、的一個階段，具有一定的技術需求觀測性，但是正如文章開頭所言，它其實不是我們追求的用戶體驗上的頁面加載時長。從 Android API 19 之后，Android 在系統 Log 中增加了 Display 的 Log 信息，它是 Activity 完成首幀的時間，可以看得出來，它也是 Google 比較重視的一個點，但它還是頁面加載過程中的一個分階段監控點，不是我們的目標結束點。除此之外，Google 還為我們提供了 reportFullyDrawn 接口，當業務認為渲染完成時進行調用。因為業務各自不一的實現往往導致首幀距離真正的頁面加載完成有相當一段距離。當然不只是 Google 意識到這一點

88、，FaceBook 也在這方面使用上做了些有趣的嘗試。reportFullyDrawn 接口與我們常說的業務埋點其實是一回事，這樣的方式統計出來的數據是相對不錯與精準的，但是仍會面臨幾個問題：業務埋點帶來了標準的不統一每一個頁面的實現都是不一樣的，每一個業務方對自己的可視終點有不一樣的定義。有的人認為頁面第一張圖片出來了就是可視，有些人認為頁面數據請求回來了就是可視，有些人認為第一幀上屏就是可視，一千個人心中有一千個哈姆雷特，這也導致埋出來的數據往往千差萬別，甚至會出現肉眼看見更慢的頁面數據更好的情況。4401年度精選技術棧內容終端技術篇/技術經典總結技術人的百寶黑皮書2022版大淘寶技術出品

89、框架復雜，在現有基礎上改動成本有些過高當前淘寶首頁會有 N 多個模版，并且模版間還存在組合關系。淘寶首頁是根據模版下發進行渲染數據，如果說對模版改造有些不太現實。同時，現階段的淘寶，業界中能見到的跨端框架，在淘寶都能看到影子，讓所有框架改造一個統一的可視標準，讓所有業務方手動打入可視時間有一些不切實際。業務與框架側都不具有全局視角，導致埋點不準確往往業務方將數據請求回來交給容器渲染時就認為可視了，可卻忽略了容器處理數據需要時間，數據上屏需要時間，容器將圖片 URL 交給圖片庫進行加載亦需要時間。對于業務方而言，上訴耗時，對他是透明并不感知的，對于框架而言，只是進行一次渲染，并不知是頁面加載還是

90、刷新頁面?；谏显V問題，我們將解決方案放在業務無入侵、統一可視終點標準上，并最終提出了 8060 算法?？梢曀惴ǔ醪綄崿F8060 可視算法規則很簡單，主要是將屏幕范圍內的 View，對 X、Y 軸進行投影，當覆蓋 X 軸長度的 80%、Y 軸的 60%就認為是可視。4501年度精選技術棧內容終端技術篇/技術經典總結技術人的百寶黑皮書2022版大淘寶技術出品為了將可視計算性能進一步提升，我們決定異步計算可視終點。異步計算可視是 APM 中比較巧妙的實現，因為可視算法涉及到 UI，Android 開發同學都知道，對 UI 的操作不是必須在主線程中實現，只需要保證操作的線程和 UI 的創建線程保持一

91、致即可，那么 Activity 界面的 UI 正常情況下都是在主線程創建的，這是否意味著可視算法只能在主線程中執行呢？答案顯然是不一定。其實 Android 系統需要保證的是 UI 的狀態，通過對線程的保護，可以很好的保證 UI 狀態的一致性。如果多線程對 UI 進行寫操作，那么會導致 UI 的狀態被破壞；但是如果是多線程讀操作呢，多線程讀 UI 的狀態并不會破壞 UI 的狀態，只會導致一個問題，即在讀的過程中讀到一個不穩定的狀態，導致程序異常，比如說 NPE，APM 在嘗試異步 UI 可視算法的起初，就遇到了 NPE 的一些問題。不過這到不是一個很嚴重的問題，因為當你讀到了一個不穩定的狀態時

92、，恰恰說明 UI 的狀態還不穩定，意味著 UI 在變化。拋棄本次計算，重新開始計算，直到有一次完整的頁面計算。這個算法其實來源于讀寫鎖的設計思路，如果讀不會導致數據變化，那么在 UI 線程在讀操作的時候異步線程也可以同時的讀 UI，并不會對 UI 的狀態導致破壞，程序依舊能正常運行。異步線程只需要保護好自己的運行狀態，能正確處理一些異常即可?？梢曀惴ǔ醪窖葑兯惴ň痛硕共搅藛?？其實并沒有，我們認識到元素是有差異的，不能同一標準而視之，同時我們在計算方式也在做新的嘗試。在手淘中，又孵化出另一種計算方式：將所有合格 View 的面積累加起來，計算出來的面積占整個屏幕的面積占比就是加載比率，當加載比

93、率超過 80%，就認為頁面可視了。4601年度精選技術棧內容終端技術篇/技術經典總結技術人的百寶黑皮書2022版大淘寶技術出品針對 View 不再是無差別計算，我們有了更細的規則：View 在全部或者部分在屏幕范圍內，且 Visibility 必須為 View.VISIBLE只針對 View 進行計算，ViewGroup 不在計算范圍之列，且不是 ViewStub如果是 ImageView，Drawable 必須為 BitmapDrawable、NinePatchDrawable、AnimationDrawable、PictureDrawable如果是 TextView，必須要有文字如果是 E

94、ditText，判斷是否已經聚焦，如果聚焦，整個頁面直接加載完成其他 View 默認加載完成1.2.3.4.5.6.4701年度精選技術棧內容終端技術篇/技術經典總結技術人的百寶黑皮書2022版大淘寶技術出品為了更為接近用戶體驗，我們決定對所有核心鏈路上的頁面加載耗時進行校準（這里的用戶體驗終點即頁面呈現完成）。其中心是對頁面視圖的理解：什么樣的視圖是用戶關心的？什么視圖是影響用戶體感加載耗時的？從這個角度上，校準的核心動作就呼之欲出了：提取視覺有用的有效元素出來計算，剔除用戶不能感知的無效元素。算法的迭代算法的迭代主要內容是解決在計算時，提取視覺有用的有效元素和剔除用戶不能感知的無效元素問題

95、。何為有效元素？我們認為在一個頁面上，最重要的是上面展示給用戶的圖文信息，除此之外，就是外加的一些操作元素，主要包括按鈕和輸入元素。當這些元素出現并占滿屏幕大部分的時候，我們就可以認為，我們內容已經完整呈現給用戶了。從1到2：Native頁面校準經過 APM 前期的發展，基礎的頁面加載耗時已經有了，但是準確性上還有待提高。4801年度精選技術棧內容終端技術篇/技術經典總結技術人的百寶黑皮書2022版大淘寶技術出品通過觀察發現，我們還發現頁面上很多元素并不是一直是無效或者有效的，比如說常規頁面需要上屏的一張圖片，圖片庫需要先加載默認圖，等到圖片庫網絡請求完成后才上屏，只有上屏了的圖片才是有效元素

96、，這一部分可以跟標準圖片庫打通，并在手淘中自定義圖片庫中推行 APM 標準即可（少數）。除此之外的元素，我們都將其默認視作無效元素，之前的算法，全部認為是有效的，所以才會導致可視終點過于靠前。例如在手淘首頁，下發的模版中會產生大量無效控件，例如透明控件、底色控件。將不能識別的元素默認視作無效這一舉動無疑會將計算的成功率拉低，但是會提高我們數據的準確性。同時基于雙端能力對齊的想法，并沒有在 View 面積之和的計算上進行修改，而是基于X、Y 軸投影的算法上進行修正：將所有的合格有效 View 對 XY 軸分別進行投影，同時將有無效標記的 View 對 XY 軸分別進行投影，當合格的投影減去無效

97、View 投影，分別覆蓋 Y 軸的 80%，X 軸的 60%，那么頁面加載完成?，F在投影算法已經是 APM 里面的推薦算法。利用此算法進行首頁校準前后的終點對比圖4901年度精選技術棧內容終端技術篇/技術經典總結技術人的百寶黑皮書2022版大淘寶技術出品支持 View 打標計算時候，會識別有效元素和無效元素的標記，這個標記是什么？在手淘中，哪些又做了這些標記呢？頁面元素鋪滿屏幕不等于加載完成。我們發現很多頁面為了追求更好的用戶體驗，會生成魚骨圖、頁面打底圖、圖片打底圖，同時頁面為了追求更為完美的展示效果，自定義 View 也是頁面上的常規操作。為了支持各種各樣的 case，APM 采用 Vie

98、w tag 的方式進行解決，APM 中提供三個 tag 進行選擇：在手淘中，需要打標的主要包括：魚骨圖、自定義圖片庫、自定義View（繼承于 ImageView、TextView 不需要打標）。而這一部分需要打標的 View 出現頻次較低，改動較少，故而在成本較低情況下，可以大大拉高準確度。這個變動毫無疑問是巨大的，也給 APM 在與業務低耦合的情況下，帶來了更大的靈活性，例如，詳情打開后會有一個全局遮罩的魚骨圖，對魚骨圖打標后，然后配合圖片庫打標，詳情的頁面加載準確性大幅提升/*當前狀態是無效的View，但是僅僅表示當前狀態，有可能變成有效，例如 ImageView*/String APM_

99、VIEW_VALID=valid_view;/*當前狀態是有效的View*/String APM_VIEW_INVALID=invalid_view;/*需要完全忽略的無用 View，這個 View 完全是計算的噪點，例如魚骨圖*/String APM_VIEW_IGNORE=ignore_view;1234567891011125001年度精選技術棧內容終端技術篇/技術經典總結技術人的百寶黑皮書2022版大淘寶技術出品通過線下測試可以發現，詳情的魚骨圖遮罩時間較長，在遮罩過程中會進行頁面加載，如果不對魚骨圖進行打標，那么 APM 計算出來的加載時長與用戶體感加載時長差距較大。下圖是詳情頁面校

100、準前后的線上數據，我們可以發現 7 月到 8 月線上數據有一個非常明顯的數據躍遷：通過給 View 打上是否合法的 tag，除了給 APM 帶來了靈活性，也給業務帶來了更大的自主性。對于高度復雜的業務來說，依舊存在自定義頁面的結束時間的訴求，但是這種自定義結束時間并不是直接給 APM 塞一個時間戳，而是在自身頁面加載邏輯完成之時，給 View 一個標記，標記此 View 完成了加載。例如，對于直播來說，他們需要的頁面加載耗時，并不是直播頁面的首幀，而是等待指定的直播小組件加載完成才算完成。如此高度定制的需求只需要做兩步就可以完成：1.在創建 View 樹的時候，在根 View 上打上非法標記2

101、.當直播小組件加載完成，將根 View 上的非法標記改成合法標記這是線上數據，APM 在校準上線后，發現更為符合業務方訴求與預期：設置頁面加載閾值是否任意一個頁面都適合同一加載閾值呢？答案當然不是的。5101年度精選技術棧內容終端技術篇/技術經典總結技術人的百寶黑皮書2022版大淘寶技術出品頁面的布局、機型的適配直接影響著頁面加載的比例，所以頁面加載的上限在不同的頁面中，也應該是不同的。在線下測試中發現，有些頁面加載在某些手機上勉強了達到 80%的閾值，有些手機上一直達不到，造成大量數據計算不成功?；谝陨峡紤]，APM 提供了設置單個頁面加載閾值的口子，通過配合校準的各種改造，頁面的加載時長準

102、確性大幅度提高，同時 Android 的計算成功率也飆升。errorCode=0 表示計算成功，由 12%上升到 78%自定義頁面根 ViewAPM 計算的根結點默認是頁面上的 DecorView，往下遍歷的根結點是否是合理的呢？存在修改的可能嗎？是存在的，自定義頁面根 View 可以更細粒度的控制頁面。對于頁面的理解一定是 Activity 或者 Fragment 嗎？不是的，我們既然討論的時候用戶體感加載時長，那么我們應該更多的從用戶視角去考慮這件事情。例如，逛逛頁面上有兩個 tab，基于用戶角度，我們更愿意理解成兩個頁面，推薦頁面和關注頁面。以逛逛關注頁面為例，點擊關注 tab 時候創建

103、了頁面，整個關注頁面也只是整個頁面的一部分，下圖為校準后的效果：5201年度精選技術棧內容終端技術篇/技術經典總結技術人的百寶黑皮書2022版大淘寶技術出品在 APM 中提出了 Page(頁面)的概念，每一個 Page 有一個對應的 pageRootView，使用 pageRootView 來進行頁面加載比率計算。當我們仔細去觀察頁面的 View 樹結構時，還發現自定義頁面根結點帶來了更大的靈活性，對于異常 case 也有了更多的處理手段，這里舉一個我們在校準過程中遇到的例子，逛逛首頁加載校準：逛逛的首頁是一個 Fragment，按道理說可以直接進行度量，但是在校準的時候發現：逛逛首頁（推薦）

104、有一個全局背景圖。當嘗試使用打標解決的時候才發現，逛逛業務定義了自身框架的 DSL，整個頁面使用的是 DSL 進行編寫（類 RN 原理），所有 ImageView 都是相同的 View，并沒有任何特殊性，在端側根本不感知這個背景圖。這就意味著打無效標的辦法不能用了。那么還有其他低成本的辦法嗎？當然有的，查看逛逛首頁的布局，發現全局背景圖在整棵 View 樹非?？可系奈恢?，與真正有效的 View 節點并沒有關聯，那么只需要將有效的子 View 樹的根結點作為計算的起點就可以了。53注：在原始 APM 計算邏輯中，是使用整棵 View 樹的根節點來進行向下遍歷計算的01年度精選技術棧內容終端技術篇

105、/技術經典總結技術人的百寶黑皮書2022版大淘寶技術出品最后的方案：更換逛逛首頁的頁面根結點（pageRootView）。下面是逛逛首頁的校準效果，如果沒有進行校準，那么當背景圖出現的時候就是頁面加載的結束點，而且二刷也沒完。通過打標解決了二刷問題，通過修正頁面根 View 解決背景圖問題，由于頁面 ImageView 存在動畫，所以加載完成后會有一個漸顯的動畫，當前 APM 認為這個漸顯動畫不影響可視點：5401年度精選技術棧內容終端技術篇/技術經典總結技術人的百寶黑皮書2022版大淘寶技術出品從1到2：H5 的標準在 H5 等場景下，WebView 的進度條并不一定代表真實的加載進度，導致

106、 APM 的頁面加載無痕算法在 H5 場景下準度很差。為此，我們引入 JSTracker（前端框架層）進行計算，與此同時，在 Android 中，UC 內核自主計算的可視時間也被引入其中。UC 內核計算的可視時間原理又是什么呢？在頁面加載的過程中，記錄所有的渲染幀，在頁面加載結束之后，回溯檢查每一幀，圖片渲染面積首次達到最大值的那一幀記為可視時間，而 JSTracker 計算原理類似，不同的是，JSTracker 是在前端框架層進行計算。5501年度精選技術棧內容終端技術篇/技術經典總結技術人的百寶黑皮書2022版大淘寶技術出品前端自定義終點除了 JsTracker/T2 的頁面加載終點之外，

107、還有沒有其他辦法來體現自身業務的自定義頁面加載終點呢？有的。APM 與前端框架定下了此規范。對于前端 H5 來說，如果需要自定義頁面終點，首先需要通過一種方式告訴容器，自身是需要自定義終點的，告訴的方式就是：增加 APM 規定的 HEADER 標簽。容器讀取到了這個 HEADER 標簽，表明當前 H5 頁面遵守規范，需要自定義終點，將會通過 APM 提供的 JSBridge 提供頁面加載的終點。此外，APM 也提供埋入參數和階段數據的 JSBridge。在大促會場場景下，使用此方案支持了性能優化結果產出，其產出的結果中，除了頁面可視之外，還包括秒開率，系統耗時，H5 容器框架耗時，前端耗時等指

108、標，結合 AB 產出對比數據結果，同時結合設備分級數據細化在不同手機等級下的數據。挑戰：多容器內嵌頁面在手淘中有各種各樣的跨端容器框架，如 weex 等。存在一個頁面上多種容器并存的情況，容器與容器之間，數據如何兼容，APM 提出了自身的仲裁方案。在店鋪一個頁面中，有可能存在多種框架混合使用的情況，舉個例子，可以用 WebView 實現一個廣告推薦，可以用 Weex 渲染出整個頁面。如果每一個容器直接將自己的頁面加載時間點通過一個接口直接打進來，APM 選取哪一個作為頁面真正的加載結束時間戳呢？如果選取最小的時間戳，如果對應的 View 不是頁面主要元素，那么這個值比體感加載時長小，如果選取最

109、大的時間戳，就有可能偏慢。其實在 Native 角度，每一個容器只是 View 樹上的一個節點，APM 只需要關心這個子 View 是否加載完成，然后使用頁面加載算法計算（8060算法），就可以知道整個頁面是否加載完成。5601年度精選技術棧內容終端技術篇/技術經典總結技術人的百寶黑皮書2022版大淘寶技術出品那么問題就簡化成如何知道這個子 View 是否加載完成。當前 APM 支持對 View 打標，當 View 沒有加載完成的時候，就會打上沒有加載完成的 tag，完成頁面加載就會打上完成的 tag。由于容器知道自己的加載狀態，就只需要在合適的時候，給自己的 View 打上合法的 tag 即

110、可。由于 APM 在遍歷 View 樹的時候，一旦發現 View 打上了 tag，就不再往下遍歷，直接確定了當前 View 的狀態，起到了數據仲裁的效果。寫在最后對于 APM 頁面加載耗時校準而言，目前 APM 還只是向前走了一小步。在最新的 APM 自動化頁面加載耗時計算中，剔除了對用戶頁面加載體驗無效的元素，聚焦頁面加載體驗中的核心元素，既給了業務相對的自由度，又達到了一定的加載體感準確性。團隊介紹淘寶Android體驗技術團隊，以打造極致的移動用戶體驗為愿景，立志于研發體驗相關技術、中間件，以及提供產品化解決方案，一站式為淘寶及其他移動應用核心場景體驗賦能。團隊在應用級優化有豐富的經驗，

111、并深耕于系統級能力，目前已有多個成熟技術方案服務于大促會場，應用啟動，外鏈拉端等，已建立全鏈路的線上性能監控體系，探索非確定性性能問題的監控及排查能力，我們長期招聘志同道合的伙伴，歡迎有志人士加入。5701年度精選技術棧內容終端技術篇/技術經典總結技術人的百寶黑皮書2022版大淘寶技術出品19條跨端cpp開發有效經驗總結作者：鹿慕出品：大淘寶技術跨多端開發避坑指南前言細想，專門從事跨多端開發已兩年有余，前段時間因為組里跨桌面端項目需要回歸windows下開發了整整2個月，怎么形容這兩個月呢，嘿嘿，各種“肆無忌憚”的寫法，終于不用在寫一行代碼考慮后面n個端的行為了，勞動力、效率得到大幅度解放，但

112、是隨著windows發版結束后，我負責mac的適配相關工作，在這個階段，發現很多不合規的奇技淫巧（原定2個工作日的適配quota，大概進行了一周），作為一個略有想法的cpp程序員，遂產生了想寫一個跨多端開發避坑指南的想法，想起過去看的Scott Meyers的Effective C+.努力寫xx條有效使用cpp開發跨端的經驗，期望看完此文可以幫助大家在如何保持同一份cpp代碼在多個平臺編譯和構建上行為一致上有一絲絲幫助?？缍喽碎_發下的復雜性，究其本質大多是因為兩個原因引發的1.多系統下平臺差異2.多編譯器下行為不確定性下面主要講解的也將從這兩個方面入手。同時，在拜讀了多份cpp程序員開發寶典里

113、，還是覺得 Google C+Style Guide是最有效的，最直接的避坑寶典，依舊推薦給大家：https:/google.github.io/styleguide/cppguide.html下面進入正文C+VERSION 的選擇C+version選擇可以說對于跨終端開發是至關重要的，跨端開發一個比較難的點在于多平臺下，如何很好的支撐平臺差異點，隨著C+版本的升級，越來越多的新feature在標準庫中得到支持，這也就是意味著開發者可以更少的關注平臺差異點，因此這里建議選擇最新的穩定版本，截止到目前推薦使用C+17.5801年度精選技術棧內容終端技術篇/技術經典總結技術人的百寶黑皮書2022版

114、大淘寶技術出品禁止在一個單獨的編譯中重復包含文件的現象出現可以通過兩種方式有效的避免此類情況1.#pragma once，需要特別注意 這是一個非標準但是被廣泛支持的前置處理符號，在主流的編譯中clang，ms等 均已支持。路徑和頭文件路徑分隔符的問題在windows中路徑的識別對于正反斜杠均支持，但是在linux中，只能是/，此外，在linux中對于路徑是嚴格區分大小寫的，對于windows則忽略大小寫。建議：1.對于路徑均需嚴格保證大小寫與實際路徑的匹配2.在代碼中禁止對路徑使用“”，請用“/”代替。此舉，將在你從win到mac適配過程中，節省大量的工作量。C標準庫的頭文件包含在Windo

115、ws下某些C標準庫的頭文件不用顯式包含，但是在linux下需要顯式包含。因此在跨端開發中，應在.c和.cpp文件中盡量包含這個文件中需要的頭文件，并且這也是C語言標準從C99以后的標準要求。2.使用#define的方式#pragma once#include.123#ifndef FOO_BAR_BAZ_H_#define FOO_BAR_BAZ_H_.#endif /FOO_BAR_BAZ_H_1234565901年度精選技術棧內容終端技術篇/技術經典總結技術人的百寶黑皮書2022版大淘寶技術出品代碼文件格式在跨終端開發中，特別是包含中文的部分，除非你的代碼都是英文注釋，否則很難避免在多平臺

116、下（特別是windows與類unix平臺下的開發）交叉開發帶來的中文亂碼問題。建議：全部使用UTF-8 BOM編碼格式。關于內聯函數定義：當函數被聲明為內聯函數之后,編譯器會將其內聯展開,而不是按通常的函數調用機制進行調用。參考定義，自然他的優點，在函數體比較小的情況下，內聯該函數可以令目標代碼更高效，通常情況下，應該鼓勵在函數比較短時使用內聯。關于內聯函數，或許很多非跨端程序員或認為不足為重，其實這里有幾個非常值得在跨端開發被重視的問題：綜上在跨端開發中因盡量避免使用內聯，這里給出幾個可以衡量的準則（經驗值？）：過度的內聯，會導致程序臃腫，特別是對于移動端，一方面c+代碼的體積問題一直不能很

117、好的得到解決，另一方面也會使得程序變慢。在導出頭文件中非恰當的使用內聯，會導致在跨模塊開發中帶來意向不到的結果。這里舉個例子，在提供跨終端SDK時，通常會提供導出頭文件，但是如果在導出頭文件里不恰當的內聯，將使得編譯從當前單元跨越到另外一個模塊，可能會引發一系列問題盡管編譯器對內聯函數都有或多或少優化，但是不同編譯器不盡相同，實踐下來良好的內聯使用習慣依舊能幫助大家，譬如，我們在移動端的某個cpp項目中，通過去內聯，減少了一定的包大小，實踐證明編譯器在擇優選擇的過程中不一定會完美契合。關于內聯的編譯器優化可以參考：https:/isocpp.org/wiki/faq/inline-functi

118、on1.2.3.行數超過10行禁止使用內聯（google 建議）在非get函數里禁止使用內聯（經驗值,這一條爭議會比較大，但在我看來只有在get某成員變量值時使用內聯是有必要的，其他都沒有必要且可能會帶來“驚喜”）內聯函數務必要有適當的修飾符（const）析構函數如果有自定義內容，禁止使用內聯（google 建議，通常析構函數遠比你想想的做的要多）1.2.3.4.6001年度精選技術棧內容終端技術篇/技術經典總結技術人的百寶黑皮書2022版大淘寶技術出品關于基礎類型定義請使用基礎類型定義，禁止使用自定義基礎類型?？催^團隊的幾個代碼庫，在基礎類型的使用上有些同學甚至三方庫也非常喜歡自定義，譬如C

119、HAR的定義char的定義需要顯示是unsigned還是signed。需要注意的是，char在標準中不指定為signed或unsigned，不同的編譯器可能會有不一樣的結果，在發生隱式轉換時可能會有超出期望的結果，譬如，char強轉int時，發現在x86平臺下是按照有符號處理的，但是在ARM32下被當成了無符號導致問題，ARM64正常有符號，當然你可以通過指定CFLAG+=fsigned-char 來解決，但是此類問題應當在規范時就被避免掉。關于寬字符的問題你需要知道的：在Windows中，wchar_t占兩個字節，Linux中占四個字節，這里有幾個問題1.導致體積占用大小不同。2.程序移植帶

120、來困難3.隱式轉換結果不符合預期在進行跨模塊開發以及代碼融合時，這些基礎類型的自定義經常會出現歧義，redefine等等，或許你會說這樣的定義應該要有自己的#define保護，但是大多數程序員不會這么做，這里強烈不建議自定義基礎類型，標準庫提供的已經足夠簡略和通用，請方便自己開發的時候同時照顧下團隊同學。typedef std:int8_t int8;typedef std:int16_t int16;typedef std:int32_t int32;typedef std:int64_t int64;typedef std:uint8_t uint8;typedef std:uint16_

121、t uint16;typedef std:uint32_t uint32;typedef std:uint64_t uint64;1234567896101年度精選技術棧內容終端技術篇/技術經典總結技術人的百寶黑皮書2022版大淘寶技術出品跨端開發應避免wchar的普遍使用，以避免寬窄字符轉換帶來的開銷以及額外的問題，應普遍使用utf-8作為主要的編碼，這也是主流的思路。即時是特殊場景也可以用使用utf16，避免使用wchar。簡而言之，除非必要，否則請不要使用。應該限定字符串數組在保存為字節流時，使用編碼為uft-8請在字符串前加u8,特別是包含中文的部分，習慣在vs下開發的同學也需要額外注

122、意，vs默認的文件編碼是gb2312,這會有概率導致字符串可能會不小心被保存為gbk編碼格式。同時u8僅限在字符串前使用，在字符前使用是沒有任何意義的，即時在ms上會編譯通過，在clang下會提示避免連續兩個尖括號的定義例如在Windows下這么寫沒問題，那么在某些平臺下可能編譯不過，提供兩種方式：1.可以在連續兩個尖括號符號之間留一個空格，即2.也可以typedefC+11標準里已經解決了此問題，如果確認編譯器版本已經支持了這個特性（參考:https:/isocpp.org/wiki/-faq/cpp11-language-miscIn C+98 this is a syntax error

123、 because there is no space between the two s.C+11 recognizes such two s as a correct termination of two template argument lists.），此條可以忽略，但是通常兩個的情況也意味著嵌套使用，typedef后通常閱讀性也會得到提高。int pos=targetID.rfind(u8_);/error:use of undeclared identifier u8.1std:vectorstd:vector vec1std:vectorstd:vector vec;16201年度

124、精選技術棧內容終端技術篇/技術經典總結技術人的百寶黑皮書2022版大淘寶技術出品對于平臺差異的代碼部分處理跨端開發難免出現平臺差異性代碼，對于這部分的處理，對于簡短的部分建議使用if def的方式區別，對于功能性的、代碼較多的建議使用分文件開發，xxxx_win.cpp,xxxx_mac.cpp,xxxx_linux.cpp,可以參考chromium的代碼在大量使用這種方式。同時對于差異性代碼部分，應保持除非必要否則不定義的原則，因盡可能保持跨端的代碼處理方式，過多的平臺差異性將勢必導致維護性變的很差。應避免使用非標準的編譯器支持的關鍵詞Assert的使用Assert在pc時代是作為一個廣泛（

125、甚至是爛泛）使用的警告處理方式，在移動端以及類unix系統中，debug下表現通常會比windows更加猛烈些，通常是阻塞式的處理，特別是移動端會導致程序繼續運行不下去，不像windows彈個框給你一個continue的選項。因此在跨端開發中應避免直接使用assert，可以考慮使用重定義后的assert，同時合情合理使用重定義后的assert。c+標準關鍵詞參考：https:/ NDEBUG#define ALOG_ASSERT(_Expression)(void)0)#else#define ALOG_ASSERT(_Expression)do .這里可以額外做error級別日志輸出，是否進

126、行assert阻塞式處理。if(HandleAssert()assert(_Expression);while(false)#endif12345678910116301年度精選技術棧內容終端技術篇/技術經典總結技術人的百寶黑皮書2022版大淘寶技術出品關于繼承Composition is often more appropriate than inheritance.When using inheritance,make it public.google的這個定義應該還是非常準確的，通常組合比繼承更合適，即時要使用也必須是publice的方式。應盡量保持“is a”的情況下使用繼承，如果你想

127、使用私有繼承,你應該替換成把基類的實例作為成員對象的方式。對于重載的虛函數或虛析構函數,使用 override,或(較不常用的)final 關鍵字顯式地進行標記.在部分clang編譯器下，編譯器要求務必顯示聲明，否則會報錯，ms則沒有此類要求。關于Static變量感興趣的小伙伴可以研究一下c+的特性“Dynamic Initialization and Destruction with Concurrency”，其中里面有定義靜態、動態變量析構的順序，線程生命周期的對象全部在靜態變量之前析構，靜態變量按照后構造的先析構的棧式順序釋放。實際在實踐中發現apple的clang編譯器和運行時庫對c+

128、11的這個特性支持，未實現靜態變量析構的多線程安全。因此在目前階段，如果有用到全局靜態變量時需要考慮到析構多線程安全的問題，否則線上在個別平臺會發生crash。一個比較簡單的思路：從全局靜態變量替換為局部靜態變量且不釋放，直到進程被kill。這里還有一個變相的好處：把加載時機從load變成了此代碼段真正運行時。eg：old：static std:recursive_mutex&m_mutex;new：static std:recursive_mutex&mutex()static std:recursive_mutex&mutex=*(new std:recursive_mutex();ret

129、urn mutex;1234567896401年度精選技術棧內容終端技術篇/技術經典總結技術人的百寶黑皮書2022版大淘寶技術出品關于模板模板的出現極大的方便了程序員，在未進入跨終端領域之前，雖了解它的一些詬?。ùa膨脹&不合理的使用帶來的性能損耗），也一直認為是一個非常棒的feature，隨著移動端對包大小的要求越來越嚴格，模板的使用在跨終端上被限制，需要更為合理的使用，否則將膨脹的非常厲害。在漫長的去模板化過程中有些經驗值可以輸出，供大家參考。最后再插一嘴，模板對于使用者確實是極大的方便，但是在跨終端領域似乎對于模板的構建者有著更為嚴格的要求，需要著重考慮如何避免被膨脹，此外對于性能的要求

130、也更為嚴格，c+11里有不少提供模板性能的方式，&配合std:forward實現完美轉發，等等，有興趣的可以看下Effective Modern C+。以上也適用于 宏。關于編譯器跨端開發勢必要了解多種平臺下的編譯器，這里面主要代表是clang、ms（也成vs）、gcc等等，編譯器的主要區別，這里不做主要的介紹了，可以去google下clang的前世今生，以及幾種編譯器的區別，和對應的使用平臺。clang作為一款飛速發展的編譯器，除了編譯速度有飛速的提升外，錯誤提示也非常明確，這里強烈建議跨端開發者，如果有可能優先進行clang作為主要的默認編譯器進行開發，良好的錯誤提示將提高極大的效率，同時

131、clang的代碼檢查將更為嚴格和規范，這也利于代碼進行跨平臺編譯。在涉及到移動端的跨終端開發里，應盡量避免使用模板，除非它帶來足夠多的收益，比如json序列化，通篇用cjson的方式替換，從開發體驗和代碼膨脹比上來看，替換就顯得不值得，比如自定義std標準容器，看似省了不少膨脹，但是代碼的維護性和可讀性降低了很多，同樣不值得替換。盡可能選擇小的模板編譯單元，比如原來一個模板類，改為類里的模板函數通常情況下模板可以以各種方式被除去，這里不是說在裸寫一遍模板換實參的方法。應盡可能的減少模板膨脹的速度，換句話說如果有可能應該盡量限制模板被特化的可能，譬如，我們的日志序列化，對于任意struct或者c

132、lass在實現了ToString()方法后均可以實現日志自動化輸出，任意類型在進入到LOG_IMPL中都會生成一份具體類型的實體，經過略微改造后，限制需要被序列化的類型需要顯示繼承IOBJECT的接口類，改造后，在同樣進入到LOG_IMPL中所有的類型只會有一份類型（IOBJECT*）實例化，此舉在實踐過程中大約減少了我們五分之一的包大小。在多重繼承中，特別是公共模塊基類如果包含模板，去模板的收益一般會比較大，因盡量限制基類中出現模板，除非必要，否則應以任何方式替換。1.2.3.4.5.6501年度精選技術棧內容終端技術篇/技術經典總結技術人的百寶黑皮書2022版大淘寶技術出品這里再再插一句，

133、之前在知乎上看過一篇文章對比各種編譯器，在比較clang與gcc時，排在第一次位的不是我們通常說的編譯速度和錯誤提示以及更小的編譯產物（這些都是普遍知道的），是 license，gcc的GPL的限制讓BSD許可下的以LLVM為代表的飛速發展，如果不是這個限制相信今天以LLVM為代表的的一系列編譯器都是屬于gcc。所以“做技術的同學不要以為技術牛就可以打天下，精準的市場地位有時候可以解決很多問題”，這句話說的還挺好的，與君共勉。關于轉換層如果做跨模塊開發，請堅守一個原則，轉換層不要做任何業務代碼邏輯以及特殊定向代碼邏輯。轉換層也成語言膠水層，是c+到oc,c+到java，以及其他，彼此相互語言轉

134、換的代碼層。通常wrapper堅守原則后，維護性會得到大幅度提升，專注于c+代碼的即可，對于語言轉換層，業界也有不少自動化轉譯的工具，諸如Djinni。結束在通往跨端開發的路上，我漸漸的從一個小白到逐漸羽翼豐滿，除了要感謝團隊給的機會外，非常感謝這一路上很多同學、特別是跨部們的同學幫助，感謝，比心另外團隊目前也在搞基于跨桌面端的研發框架支撐相關工作，也會很快出爐，敬請期待。最后回歸主題，跨端cpp開發閉坑指南遠不止這些，歡迎一起補充添加。鳴謝。團隊介紹我們是淘系技術部終端體驗平臺跨終端團隊，業務上負責為千萬級商家打造最高效的一站式工作臺千牛，為淘寶上億商家和消費者提供穩定高效的端到端消息IM服

135、務；技術上深耕C+跨終端及PC桌面端技術（Win-dows&Mac），為商家，消費者提供穩定，可靠，高效的客戶端產品。歡迎志同道合的小伙伴，毛遂自薦，團隊歡迎你，簡歷投遞郵箱：wdw159603alibaba-6601年度精選技術棧內容終端技術篇/技術經典總結技術人的百寶黑皮書2022版大淘寶技術出品下一代響應式Web設計：組件驅動式Web設計作者：大貘出品：大淘寶技術自從著名設計師 Ethan Marcotte（beep）在 A List Apart上發表了一篇名為 Responsive Web Design的文章之后，響應式網頁設計（RWD，即 Responsive Web Design）

136、的身影就出現在了公眾面前。自此就有了響應式 Web 設計這個概念。從提出這個概念到今天已經有十多年的時間了。在這十多年來，CSS 也發生了巨大的變化，新增了很多新的特性，近兩年尤其如此，近兩年尤其如此（詳細請參閱2022 年的 CSS一文）。這些變化，對于響應式Web設計的開發也有較大的改變。Una Kravets（Una）大神，在2021的Google I/O 大會上的分享，提出 新的響應式：組件驅動式 Web 設計。Web 生態即將進入響應式 Web 設計的新時代，并轉變我們對其含義的看法，也為會Web設計帶來新的變化。組件式驅動 Web 設計（或開發）也被稱為是下一代響應式 Web 設計

137、（或開發）。如果你對這方面話題感興趣的話，請繼續往下閱讀。文章鏈接：響應式Web設計的發展歷程既然要聊響應式Web設計，那么我們就花一點篇幅和時間簡單地了解一下其發展歷程。眾所周知，自從 Tim Berners-Lee 創建第一個 Web頁面（大約在1991年8月份左右）到90年代末，Web頁面都是非常簡陋的：Responsive Web Design（地址：https:/ 年的 CSS（地址：https:/ CSS 的到來才慢慢地有了美感，Web頁面看起來開始像我們今天使用的網站：正如上圖所示，越往后，Web 的 UI 越來越豐富，越來越漂亮。這也讓 Web 開發人員不得不在布局、設計和排版

138、等方面花費更多的時間。雖然 Web 開發人員為 Web 布局花費不少時間，但在這個過程中，也積累了很多不同的布局方法。在早期，Web 開發人員主要采用 固定寬度 和 流式布局 兩種布局方案來實現 Web 頁面的布局。特別是流式布局，自 Glenn Davis提出和推廣之后，可謂是轟動一時，并且長期以來，都認為流式布局就是響應式Web布局。流式布局（Liquid Layout）可以調整Web頁面尺寸以適應不同的顯示器分辨率或瀏覽器窗口的大小。來看一個流式布局的簡單示例：Liquid Page Layout Example?nickpettit?CodePen（地址：https:/codepen.

139、io/nickpettit/pen/dyZwVg）（地址：https:/codepen.io/nickpettit）（地址：https:/codepen.io/）6801年度精選技術棧內容終端技術篇/技術經典總結技術人的百寶黑皮書2022版大淘寶技術出品但流式布局并不是完美的。使用流式布局的Web頁面上，內容可能會溢出，在較小的屏幕上文字可能會換行，在較大的屏幕上可能會有很多不必的空白。大多數流體布局在 800px x 600px到 1280px寬或更大的屏幕分辨率下看起來還不錯。然而，如果我們能把它分割得更細一些，比如為 800px 1024px、1024px 1280px以及1280px以

140、上的分辨率提供不同的定制布局，那效果會更佳。同樣，對于 640px 800px、320px 640px、240px 320px 以及 240px 以下的分辨率也可以定制不同的布局。大約在 2004 年的時候，Cameron Adams（themaninblue）（地址：https:/codepen.io/）在他的博文Resolution dependent layout（地址：https:/ 標簽上title屬性的值分別為 narrow、default 和 wide，并且在 dynamiclayout.js中有一個 DynamicLayout()函數，將會根據 標簽的title屬性的值來調用不

141、同的樣式表：Kevin Hale 的博文 Dynamic Resolution Dependent Layouts詳細介紹該技術。這種布局技術后來就以 Cameron Adams 博客文章標題命名，被稱為 分辨率相關的布局。這種布局技術雖然會額外增加開發者（開發者需要為不同定制的布局提供不同樣式表）工作量，但在CSS媒體查詢流行之前還是很受歡迎的。它也被稱為是早期的 CSS 媒體查詢（通過JavaScript查詢斷點）。雖然這種依賴動態分辯率布局的方案可以在不同的分辨率下提供更佳的體驗，但隨著 2005年08月10日 Opera 軟件公司推出Opera Mini（地址：https:/www.w

142、ebdesignmuseum.org/web-design-history/op-era-mini-2005）和 2007年01月09是第一臺 iPhone（地址：https:/www.webdesignmuse-um.org/web-design-history/steve-jobs-introduced-the-first-iphone-2007）手機的出現，市場上不同品牌，不同分辨率的移動端以及品牌商自己的Web瀏覽器就越來越多。function dynamicLayout()var browserWidth=getBrowserWidth();/Narrow CSS rules if(

143、browserWidth=640)&(browserWidth 960)changeLayout(wide);123456789101112131415167001年度精選技術棧內容終端技術篇/技術經典總結技術人的百寶黑皮書2022版大淘寶技術出品在這種環境之下，基于動態分辨率加載不同的樣式表已不太現實，Web開發者不得不想出其他的方案來適應不同的屏幕尺寸。在很長一段時間，甚至到今日，為了適應不同屏幕的尺寸適配，為移動端單獨創建一個網站，即 移動子域名網站。比如 Facebook的桌面版本和移動端版本，采用兩個不同的域名來訪問：如此一來，開發人員要開發兩個版本，相應的工作量就更大了，特別對于要

144、快速響應和試錯的Web應用來說，難度變得更大。Web開發人員為了能改善這種現象，在 2010 年的時候，Ethan Marcotte（beep）基于 John Allsopp（johnallsopp）的 網頁設計的道（A Dao of Web Design）（地址：https:/ Web Design）（地址：https:/ Web Design，簡稱 RWD）的身影就出現在了公眾面前。Ethan Marcotte（beep）在Responsive Web Design（地址：https:/ 流體網格（Fluid Grids）、靈活的圖片（Flexible Imag-es）和媒體查詢（Medi

145、a Queries）三種技術來構建一個響應式Web網站或Web應用。另外，Ethan Marcotte（beep）構建了第一個具有響應式的Web網頁，可以說是響應式Web設計經典案例之一（只可惜現在打不開了）：7101年度精選技術棧內容終端技術篇/技術經典總結技術人的百寶黑皮書2022版大淘寶技術出品那通過這個示例，大家對響應式Web設計是什么樣的有了一個初步的了解了。其實，Ethan Marcotte 在他的文章中就提到：未來我們應該這樣，隨著訪問網頁的設備增加我們不會為每個設備單獨設計，而只會做一份設計，把每個設備作為這份設計要照顧的一個方面。也就是說，每個設備上都會去追求最佳的用戶體驗，

146、設計會自動適應各個設備。在過去的時代，設計師精確的知道自己的媒介材質，比如一張 A4 紙張，一個名片，或者一張海報。但是在我們這個多屏時代，Web 設計必須有這樣的思維，我們要為“任意尺寸”而去設計。自 Ethan Marcotte 提出響應式Web設計思路以及基于不同斷點（CSS 媒體查詢替代JavaScript查詢設備屏幕分辨）實現不同終端設備屏幕分辨率布局已有十多年了。大家都說，每十年就會看到一個生態系統迅速的發展，其中 CSS 也不另外。尤其是這兩年，CSS 新增了很多新的特性，比如大家最為期待的容器查詢特性container、級聯分層layer 以及 CSS作用域 scope 等。正

147、如 Una Kravets(Una)在2021的Google I/O 大會上的分享（地址：https:/io.google/2021/ses-sion/a1760fa3-879a-4e98-a616-994ca8d3aab5/?lng=zh-CN）所說：隨著用戶偏好查詢、容器查詢以及其他設備類型查詢的出現（CSS新特性），Web社區即將進入響應式 Web 設計的新時代，并改變我們對其含義的看法。換句話說，下一代響應式Web設計即將到來，或者說已經來到了我們身邊。響應式Web設計的現狀在聊一下代響應式Web設計之前，我們就要對響應式Web設計的現狀有所了解。我們分別從兩種不同角色（Web設計師和

148、Web開發者）的角度來看響應式 Web 設計的現狀。先從 Web 設計師的角色來聊。時至今日，雖然已是移動終端的天下，但如果要給不同終端提供設計稿的話，Web 設計師還是會依舊為不同的設備終端提供不同的設計稿。比如，為不同的設備視窗尺寸（如手機，平板和桌面端）提供不同的設計稿：7201年度精選技術棧內容終端技術篇/技術經典總結技術人的百寶黑皮書2022版大淘寶技術出品在上圖中，設計師為卡片（Card）提供了三種不同的 UI 效果。雖然卡片在不同設備視窗下有著不同的UI效果，但他們構成的元素是相同，都有卡片容器、卡片縮略圖、卡片標題 和 卡片描述等：我們來看下簡化后的不同版本的設計線框圖，如下所

149、示：7301年度精選技術棧內容終端技術篇/技術經典總結技術人的百寶黑皮書2022版大淘寶技術出品作為Web設計師，你已經使用了多個版本的布局來展示同一個組件三種不同狀態下的UI變化?？梢哉f把足夠多的信息傳遞給了Web開發者！到這一步，Web 設計師已給 Web 開發者提供了具有響應式的Web設計稿。接下來，再從另一種角色（Web開發者）來看響應式Web設計的現狀。對于 Web 開發者而言，要實現上圖中三種狀態下的卡片UI效果非常簡單。借助 CSS 媒體查詢特性，在不同斷點下調整CSS樣式規則即可：這種方式只能適合于同一組件獨立存在于不同版本下。就示例的設計稿來看，在桌面端有兩種效果的卡片，為了

150、滿足該設計效果，我們需要額外添加一些類名，在不同狀態下為卡片處理不同的UI效果：/*Mobile First*/.card display:flex;flex-wrap:wrap;gap:10px;/*Tablet*/media(min-width:700px).card gap:20px /*Laptop and Desktop*/media(min-width:1024px).card position:relative .card_thumb position:absolute;inset:0;12345678910111213141516171819202122232425267401

151、年度精選技術棧內容終端技術篇/技術經典總結技術人的百寶黑皮書2022版大淘寶技術出品CSS樣式代碼可能會是像下面這樣：/*Mobile First*/.card display:flex;flex-wrap:wrap;gap:10px;/*Tablet*/media(min-width:700px).card-vertical gap:20px /*Laptop and Desktop*/media(min-width:1024px).card-featured position:relative .card-featured.card_thumb position:absolute;inse

152、t:0;12345678910111213141516171819202122232425267501年度精選技術棧內容終端技術篇/技術經典總結技術人的百寶黑皮書2022版大淘寶技術出品看上去是不錯，但問題是，只有當視窗寬度大于一個特定的值時（常指的分辨率斷點值），相應的組件變體才會生效，比如當視窗寬度大于700px時，.card-vertical卡片UI效果才生效；當視窗寬度大于1024px時，.card-featured卡片UI效果才生效。換句話說，如果要在平板端看到.card-featured卡片效果就無法看到，因為它的媒體查詢在 1024px 或更大的視窗寬度下才會生效。不僅如此，We

153、b的內容是動態的，有的時候輸出的內容可能和設計預定的卡片數量不相符合，那么在這種情況之下，要么會有一個空的空間，要么卡片會擴展以填補容器的剩余（或可用）空間。比如我們這個示例中，在視窗寬度為 700px 或更大的視窗寬度中，.card-vertical 和.card-featured 都有可能出現這樣的場景。針對這樣的場景，Web設計師可能更希望有額外的UI效果給卡片。這部分我們放到下一節來聊。簡單地說，目前的響應式 Web 設計主要方案還是利用 CSS 媒體查詢特性在不同的終端上提供布局的切換。雖然他能滿足 Web 頁面布局大部分場景，但也相對喪失了一些其他能力，比如說將響應式的樣式注入到組

154、件本身的能力。換句話說，基于視窗寬度查詢構建的響應式Web頁面，尤其是響應式組件，其能力是有限的。7601年度精選技術棧內容終端技術篇/技術經典總結技術人的百寶黑皮書2022版大淘寶技術出品CSS 媒體查詢的不足在上一節中我們一起探討了 Web 開發者可以借助于 CSS 媒體查詢特性來查詢視窗寬度（或設備其他特性）為 Web 頁面在不同終端提供差異化的布局。但也暴露出很多不足之處，甚至是明顯的能力不足。就拿前面示例來說，卡片組件有三種差異化的UI效果，這些差異化的UI效果是取決于瀏覽器視窗寬度，也就意味著卡片組件不能根據其父容器寬度去調整 UI 風格。這就限制了開發者 只能在視窗寬度大于某個特

155、定值時（斷點）使用一個組件的特定樣式。例如視窗寬度到達 700px 或大于700px時，卡片組件從默認的.card（水平）狀態切換到垂直（.card-verti-cal）狀態。也就是說，如果我們想在小于700px寬度的視窗下，使用垂直狀態（.card-vertical）卡片效果是不行的：7701年度精選技術棧內容終端技術篇/技術經典總結技術人的百寶黑皮書2022版大淘寶技術出品另外一點就是當服務端吐出的數據和設計師預設的數量不一致時，最終的Web效果有可能不是設計師期望的。比如只有一張卡片、兩張、三張或更多，而設計稿中包含三張，這種情況之下，Web開發的實現的效果可能會像下圖這樣：正如上圖所示

156、，如果只有一張卡片數據吐出的時候，整個卡片寬度會擴展與容器寬度相等（拉伸）。此時，卡片寬度太寬導致用于卡片上的縮略圖被拉抻，有可能會使縮略圖變得模糊。事實上呢？這只是Web開發者的一廂情愿，設計師真正的意圖可能是像下圖這樣：在這種場景之下，使用 CSS 媒體查詢特性實現起來會比較棘手，但使用 CSS 容器查詢特性，就會容易地多，我們可以通過查詢卡片父容器來決定如何顯示卡片去解決這些問題。如果用一然話來概述的話：雖然 Web 開發者可以使用全局的視窗信息來設置組件的樣式，但組件仍然不能擁有自已的樣式，而且當我們的設計系統基于組件而不是基于頁面時，那么媒體查詢就無能為力！7801年度精選技術棧內容

157、終端技術篇/技術經典總結技術人的百寶黑皮書2022版大淘寶技術出品慶幸的是，生態系統正在改變，而且這兩年尤其突出。比如說，我們一直期望的容器查詢特性就如約而至。如果我們將組件自身的響應式樣式思路從查詢視窗轉換到查詢其祖先容器，是不是前面的問題就可以輕易解決。除此之外，早期的CSS媒體查詢只能查詢視窗寬度和媒體特性，但不能查詢用戶對設備喜好的設置。不過，這兩年CSS媒體查詢特性也有巨大的變化，我們除了查詢媒介（設備）特性之外，也可以查詢用戶偏好設置。正如 Una Kravets 所言：Web生態再一次讓CSS騰飛，這些新的特性將會讓響應式Web設計注入新的能力。我們也將進入響應式設計的新時代，并

158、轉變我們對其含義的看法。下一代響應式Web設計當媒體查詢被運用于 CSS 中時，“響應式Web設計”（Responsive Web Design）一詞就被 Ethan Marcotte 在 2010年創造出來。從那時起，Web設計師和開發人員就開始使用響應式Web設計的方法來設計和開發一個沉浸式的Web頁面或Web應用，以實時適配當今看上去無底洞的終端設備。今天，當我們提到響應式Web設計時，首先想到的是Ethan Marcotte（beep）的 Responsive Web Design（地址：https:/ 流體網格（Fluid Grids）、靈活的圖片（Flexible Images）和

159、媒體查詢（Media Queries）三種技術來構建一個適應不同屏幕尺寸或不同移動終端設備的 Web 頁面。7901年度精選技術棧內容終端技術篇/技術經典總結技術人的百寶黑皮書2022版大淘寶技術出品Web 開發者使用 CSS 媒體查詢來改變整個頁面的布局，并從上到下調整移動手機、平板電腦和桌面端的設計尺寸。這種方法很有效，而且效果很好，但它有一個明顯的缺陷，即 整個屏幕同時響應，或者說整個頁面同時響應。雖然該響應方式確實對用戶的體驗有一些較大的影響，但不能響應個別用戶的需求，也缺乏將響應式注入組件本身。好消息是，生態系統正在改變，而且進步非常迅速。Web 設計師和Web平臺的工程師正在開始用

160、一種新的響應式技術方案來構建Web頁面，這種方案被稱為組件驅動式Web設計（Component-Driven Web Design）。組件驅動式Web設計我們今天使用的響應式 Web 設計方法很快就會被認為是過時的，就像我們從90年代最初的基于表格的HTML開發過渡到現在的感覺一樣。Web 設計師現在要克服的挑戰是，目前的響應式 Web 設計方法本質上是一種一刀切的方法，把整個頁面和用戶體驗當作一個整體，沒有任何個性化?；谝暣暗拿襟w查詢（CSS 媒體查詢）給我們提供了許多媒體查詢的能力，但缺少為我們的Web設計提供精細度的能力，并創造一個對用戶、他們的環境和他們在頁面上采取的行動來說是獨特的

161、體驗。我們也缺乏將響應式樣式注入組件本身的能力。這里所說的組件是Web上的元素，可以由其他設計元素的集合或分組組成。如果我們把組件看成是由積木組成的，并把這個概念應用到像幻燈片、卡片或內容塊這樣的常見UI元素的構造中，就會更容易理解，在不久的某一天，我們可能會把響應式設計樣式注入單個組件或積木中，以定制和調整用戶的體驗，而不是把一套固定的樣式和規則應用于整個頁面的布局。我們可以使用全局視窗信息來控制元素的字體大小和最大寬度等樣式，或者調整這些組件的背景圖像和布局，但它們仍然無法控制擁有自己的樣式。當我們的響應式設計系統是基于組件的，而不是基于頁面的時候，這種限制就更難了。好消息是，全世界的We

162、b設計師和開發人員正在努力改變響應式Web設計的生態系統。盡管為了改變我們對響應式設計的思考方式以及組件如何適應其周圍環境，需要進行基本的設計思維過程的改變，但響應式設計專業人員處理響應式Web設計的方式正在快速變化。8001年度精選技術棧內容終端技術篇/技術經典總結技術人的百寶黑皮書2022版大淘寶技術出品現在為創新之火推波助瀾的是CSS和靈活布局的快速發展，比如添加了一些新的查詢規則、Flexbox 和 Grid布局。這里所取得的進步正在迅速迎來一個新的響應式Web設計的時代，而這個時代就在地平線之外。CSS生態快速的發展，即將徹底改變響應式 Web 設計的概念！現在，在我們被引入響應式

163、Web 設計這個激進的新概念的十多年后，我們又一次見證了響應式設計生態系統的演變，即 CSS新增的特性將直接基于組件而不是基于頁面注入樣式響應能力。這種能力被稱為 組件驅動Web設計（Component-Driven Web Design），基于組件驅動的開發將會成為一種真正流行的開發模式。為了理解這種開發模式的轉變，并為即將到來的變化浪潮做好準備，讓我們看看在響應式Web設計運動中我們可以期待的變化，以及這可能會如何改變我們對待響應式設計的概念。響應用戶的需求你可能對基于視窗可視區域大小的媒體查詢（通過 min-width、max-width、min-height、max-height、or

164、ien-tation 和 aspect-ratio 等）比較熟悉，比如：media(max-width:45rem)/*視窗小于 45rem*/media(min-width:45rem)/*視窗大于 45rem*/12345678101年度精選技術棧內容終端技術篇/技術經典總結技術人的百寶黑皮書2022版大淘寶技術出品也意味著這些新增的媒體查詢特性允許你根據用戶的偏好來調整用戶的體驗?，F在很多設備提供了一些用戶偏好的設置。比如在 Mac 電腦上，用戶可以根據自己喜好做一些設置：CSS媒體查詢提供了一些用戶喜好的查詢特性，這些特性可以識別出用戶在系統上的偏好設置，幫助Web開發者構建更加健壯和

165、個性化的 Web 體驗，特別是對于那些具有可訪問性需求的用戶。這只是 CSS 的 media 最基礎的一部分規則，事實上，media 規則大約包含了 24 個可供查詢的特性，其中大約19個查詢規則得到較好的支持，詳細的可以閱讀圖解CSS:CSS媒體查詢（地址：https:/ww- Media Queries Level 5（地址：https:/www.w3.org/TR/mediaqueries-5/#mf-user-preferenc-es）規范中的第十一部分，能夠讓你根據用戶自身的特定偏好和需求來設計 Web 體驗。8201年度精選技術棧內容終端技術篇/技術經典總結技術人的百寶黑皮書202

166、2版大淘寶技術出品使用prefers-reduced-motion媒體查詢用于檢測用戶的系統是否被開啟了動畫減弱功能。比如下面的這個示例，將會展示一組令人心煩的動畫，不過當你開啟了系統的“減少運動”后就能看到動畫減弱的效果了。示例效果演示的是prefers-reduced-motion媒體特性如何讓animation停止，其實CSS的transition也可以實現動畫效果，加上并不是所有設備對動效都有一個很好的性能支持（畢竟動效是較耗性能的），因此，我們可以像下面這樣來寫CSS：prefers-reduced-motionWeb頁面或應用難免少不了用一些動效來點綴，但有些用戶不喜歡這些動畫效果

167、，甚至對于少數用戶來說，這些動效會讓他們身體不適。這就是為什么現在大多數設備都支持一種方法讓用戶根據自己的喜好來做設置。.pulse animation:pulse 2s infinite;media screen and(prefers-reduced-motion:reduce).pulse animation:none;123456789media screen and(prefers-reduced-motion:reduce),(update:slow)*animation-duration:0.001ms!important;animation-iteration-count:1!

168、important;transition-duration:0.001ms!important;12345678301年度精選技術棧內容終端技術篇/技術經典總結技術人的百寶黑皮書2022版大淘寶技術出品這段代碼強制所有使用animation-duration或transition-duration聲明的動畫以人眼難以察覺的速度結束。當一個人要求減少動效體驗，或者設備有一個刷新率較低的屏幕，比如電子墨水或廉價的智能手機，它就能發揮作用。但需要注意的是，使用動態減弱并不意味著“沒有動效”，因為動效在Web頁面中傳達信息能起到至關重要的作用。相反，你應該使用一個堅實的、去除非必須的動效基礎體驗去引導

169、這些用戶，同時逐步增強沒有此項偏好設置的其他用戶的體驗。如果你對減弱動效效果這方面技術感興趣的話，還可以閱讀：這段代碼強制所有使用動畫持續時間或過渡持續時間聲明的動畫以人眼無法察覺的速度結束。當用戶要求減少動畫體驗，或者設備屏幕刷新率較低時，比如廉價智能手機，它就能工作。另外，Eric Bailey 在他的文章Revisiting prefers-reduced-motion,the reduced motion media query（地址：https:/css- prefers-reduced-motion 和 update 結合在一起使用：media screen and(prefers

170、-reduced-motion:reduce),(update:slow)*animation-duration:0.001ms!important;animation-iteration-count:1!important;transition-duration:0.001ms!important;1234567Revisiting prefers-reduced-motion,the reduced motion media query（地址：https:/css- Pause,Stop,Hide”with prefers-reduced-motion（地址：https:/hidde.bl

171、og/meeting-2-22-pause-stop-hide-with-prefers-reduced-motion/）（地址：https:/hidde.blog/meeting-2-22-pause-stop-hide-with-prefers-reduced-motion/）1.2.8401年度精選技術棧內容終端技術篇/技術經典總結技術人的百寶黑皮書2022版大淘寶技術出品而 color-scheme 這個 CSS 屬性和的name為theme-color是相同的。它們都是讓開發者更容易根據用戶的喜好設置來控制Web應用或頁面的主題，即允許開發者根據用戶喜好設置添加特定的主題樣式。其實

172、color-scheme 屬性和 相應的標簽與prefers-color-scheme相互作用，它們在一起可以發揮更好的作用。最重要的一點是，color-scheme完全決定了默認的外觀，而prefers-color-scheme則決定了可樣式化的外觀。假設你有下面這樣的一個簡單頁面：頁面上中的CSS代碼，把元素的背景顏色設置為gainsboro，如果用戶更喜歡暗色模式，則根據prefers-color-scheme媒體查詢，將的背景顏色設置為darkslategray。通過 元數據的設置，頁面告訴瀏覽器，它支持深色（dark）和亮色（light）主題，并且優先選擇深色主題。根據操作系統是設置

173、為深色還是亮色模式，整個頁面在深色上顯示為淺色，反之亦然，基于用戶代理樣式表。開發者沒有額外提供 CSS 來改變段落文本或頁面的背景顏色。fieldset background-color:gainsboro;media(prefers-color-scheme:dark)fieldset background-color:darkslategray;Lorem ipsum dolor sit amet,legere ancillae ne vis.Lorem ipsum Lorem ipsum 1234567891011121314151617181920212223248501年度精選技術

174、棧內容終端技術篇/技術經典總結技術人的百寶黑皮書2022版大淘寶技術出品 prefers-color-scheme你可能知道了，macOS系統和iOS13之后，蘋果設備具備DarkMode效果（地址：https:/ww- Users Motion Preferences（地址：https:/ With Reduced Motion For Motion Sensitivities（地址：https:/ Web Animation:The WCAG on Animation Explained（地址：https:/css- Animations in React（地址：https:/ 來定制不同

175、外觀主題時，還可以和theme-color 以及 color-scheme 結合起來使用。這將能控制系統應用的（比如瀏覽器）主題顏色：使用 prefers-color-scheme 查詢特性可以讓你對用戶是否打開了設備上Dark Mode來做出響應。換句話說，給Web頁面或應用添加Dark Mode只需要幾行代碼即可。首先我們默認加載的主題是亮色系，我們可以在:root 中聲明亮色系所需要的顏色，比如：然后通過媒體查詢prefers-color-scheme:dark為暗色系重置所需要的顏色：:root -text-color:#444;-background-color:#f4f4f4;12

176、34media screen and(prefers-color-scheme:dark):root -text-color:rgba(255,255,255,.8);-background-color:#121212;1234568701年度精選技術棧內容終端技術篇/技術經典總結技術人的百寶黑皮書2022版大淘寶技術出品請注意，元素的背景顏色是如何根據是否啟用了深色模式而改變的，它遵循了開發者在頁面上提供的內聯樣式表的規則。它要么是gainsboro，要么是darkslategray。上圖是亮色模式（light）下，由開發者和用戶代理指定的樣式。根據用戶代理的樣式表，文本是黑色的，背景是白色

177、的。元素的背景顏色是gainsboro，由開發者在內聯的式表中指定的顏色。上圖是暗色模式（dark）下，由開發者和用戶代理指定的樣式。根據用戶代理的樣式表，文本是白色的，背景是黑色的。元素的背景色是darkslategray，由開發者在內聯樣式表中指定的顏色。按鈕元素的外觀是由用戶代理樣式表控制的。它的顏色被設置為ButtonText系統顏色，其背景顏色和邊框顏色被設置為ButtonFace系統顏色?，F在注意元素的邊框顏色是如何變化的。border-top-color和border-bottom-color的計算值從rgba(0,0,0,.847)（偏黑）切換到rgba(255,255,255

178、,.847)（偏白），因為用戶代理根據顏色方案動態地更新ButtonFace。同樣適用于元素的color屬性，它被設置為相應的系統顏色ButtonText。8801年度精選技術棧內容終端技術篇/技術經典總結技術人的百寶黑皮書2022版大淘寶技術出品看上去不錯，但這也引出另一個新的概念，系統顏色（地址：https:/drafts.csswg.org/css-color/#css-sys-tem-colors）。8901年度精選技術棧內容終端技術篇/技術經典總結技術人的百寶黑皮書2022版大淘寶技術出品有關于系統顏色這方面的不在這里詳細闡述，如果你感興趣的話可以閱讀：prefers-reduced

179、-data不是每個人都能幸運地擁有快速、可靠或無限的數據（流量）套餐。你可能有過出差旅行的經歷，也可能碰到了手機數據不夠用，那么訪問一個重圖片的網站是很糟糕的（雖然說現在流量對于大家來說不是很大的事情，花錢總是能擺平的）。不過，一旦prefers-reduced-data得到支持，那么這個頭痛的事情就可以避免了，也可以幫用戶省下一定的費用。因為，該特性可以讓用戶跳過大圖或高分辨率的圖像。當用戶在設備上開啟了“Low Data Mode”（低數據模式），會加載占流量更低的light.avif圖像，可以幫助iPhone上的應用程序減少網絡數據的使用：.image background-image:

180、url(images/heavy.jpg);media(prefers-reduced-data:reduce).image background-image:url(images/light.avif);123456789系統偏好設置的那些事兒（地址：https:/ High Contrast Mode,Forced Colors Mode And CSS Custom Properties（地 址：h t t p s:/w w w.s m a s h i n g m a g a z i n e.c o m/2 0 2 2/0 3/w i n d o w s-h i g h-c o n-tr

181、ast-colors-mode-css-custom-properties/）Styling for Windows high contrast with new standards for forced colors（地 址：h t t p s:/b l o g s.w i n d o w s.c o m/m s e d g e d e v/2 0 2 0/0 9/1 7/s t y l-ing-for-windows-high-contrast-with-new-standards-for-forced-colors/）Operating System and Browser Access

182、ibility Display Modes（地 址：h t t p s:/w w w.a 1 1 y p r o j e c t.c o m/p o s t s/o p e r a t i n g-s y s t e m-a n d-b r o w s-er-accessibility-display-modes/）1.2.3.4.9001年度精選技術棧內容終端技術篇/技術經典總結技術人的百寶黑皮書2022版大淘寶技術出品插個題外話，上面提到的這三個媒體查詢特性主要是運用于 CSS 中，但它們還可以和 HTML 的 元素的 標簽元素結合起來使用?？梢愿鶕脩魧υO備的偏好設置來選擇不同的圖片源：

183、1234567891011121314151617181991.contrast background-color:#0958d8;color:#fff;media(prefers-contrast:high).contrast background-color:#0a0db7;1234567891001年度精選技術棧內容終端技術篇/技術經典總結技術人的百寶黑皮書2022版大淘寶技術出品 prefers-contrastprefers-contrast媒體查詢主要用于檢測用戶是否要求系統增加或減少相鄰顏色之間的對比度。比如一些喜歡閱讀電子書的用戶，在閱讀與文本背景對比度相差不大的文本時會遇到困

184、難，他們更喜歡較大的對比度，利于閱讀。其他與用戶偏好有關的媒體特性從W3C規范中不難發現，規范中提供了六個有關于用戶偏好的媒體查詢特性：比如像下面這個示例：92/SCSS.c-dialog_content background-color:var(-dialog-color-background);box-shadow:0 1rem 2rem 0#00000099;outline:var(-dialog-border-width)solid var(-dialog-border-color);padding:var(-dialog-padding-outer);width:min(90vw,3

185、8rem);z-index:1;media(forced-colors:active)-dialog-border-width:var(-size-300);1234567891011121301年度精選技術棧內容終端技術篇/技術經典總結技術人的百寶黑皮書2022版大淘寶技術出品我們來看一個 forced-colors 的示例，該示例來自于 Eric 的 Windows High Contrast Mode,Forced Colors Mode And CSS Custom Properties一文：在forced-colors媒體查詢特性中重新定義了-dialog-border-width

186、的值。這樣做的原因是一個非常有意思的調整。它把細的焦點框（outline）變成了一個粗的。這樣調整有助于顯示模態框的外部邊界，并傳達它是漂浮在頁面其他內容之上的信息。強制色彩模式刪除了模態框的盒子陰影（box-shadow），所以我們不能在這種專門的瀏覽模式下依賴這種視覺效果：提取使用 forced-colors 的示例代碼：Modal dialog with Forced Color mode tweaks?smashingmag?CodePen（地址：https:/codepen.io/smashingmag/pen/zYPVjPa）（地址：https:/codepen.io/smashi

187、ngmag）（地址：https:/codepen.io/）9301年度精選技術棧內容終端技術篇/技術經典總結技術人的百寶黑皮書2022版大淘寶技術出品響應容器的需求CSS的媒體查詢引發了一場響應式設計的革命，為開發者提供了一種方法來查詢用戶代理或設備環境的各個方面，比如視窗的大小或用戶偏好來改變 Web 頁面的風格。直到現在，媒體查詢還做不到讓元素的樣式能根據一個最近的容器的大小來改變樣式風格。也正因此，大家一直期待的容器查詢來了。如果你對上面提到的媒體查詢特性感興趣的話，可以深入閱讀下面這幾篇文章：Media features（地址：https:/web.dev/learn/design/m

188、edia-features/）CSS媒體查詢新特性（地址：https:/ 容器查詢都是大家期待的一個特性，在這幾年的CSS發展報告中，他一直位居第一：自 2010 年 Ethan Marcotte首次提出 響應式Web設計（RWD）（地址：https:/ CSS 媒體查詢特性（通常是視窗寬度、媒體設備特性等）來為Web頁面定制不同的表現形式，比如可以根據用戶瀏覽內容的設備特性來呈現不同的布局、不同的字體大小和不同的圖片等。9501年度精選技術棧內容終端技術篇/技術經典總結技術人的百寶黑皮書2022版大淘寶技術出品但對于 Web 設計師或Web開發者來說，在現代Web設計或布局中仍然缺少一特性，

189、頁面的設計不能夠響應其容器的寬度（或其他特性）。也就是說，如果Web開發者能夠根據容器寬度來改變UI樣式，那就更好了。容器查詢將在很大程度上幫助 Web 開發者更好的完成他們的工作，在為Web開發基于組件代碼時，其遺漏（容器查詢特性的缺失）是一個巨大的限制。正因此，有關于容器查詢的特性在社區中的探討就沒有停止過。早在2019年底，ZachLeatherman在尋找容器查詢起源（地址：https:/ Andy Hume的基于 JavaScript 的選擇器查詢和響應式容器的解決方案（地址：https:/ 年，Mat Wilto Marquis在響應式圖片社區小組引入了 元素，將響應式圖片帶到了響

190、應式 Web 設計的世界，他在Container Queries:Once More Unto the Breach（地址：https:/ali- Web 設計的文章之后的幾年里，Web設計師和開發人員的工作越來越集中在組件上，而不是整個頁面，這使得媒體查詢不那么理想。從那時起，雖然有很多人主張使用媒體查詢，但容器查詢向前推進的速度還是不夠理想。L.David Baron在Thoughts on an implementable path forward for Container Queries（地址：https:/ CSS 的工作原理，組件中的樣式會影響其大小。任意打破這個循環，既會產生奇

191、怪的結果，又會干擾瀏覽器的工作，還會增加瀏覽器優化的成本。除了 David Baron 之外，2018年6月，Greg Whitworth在荷蘭阿姆斯特丹舉辦的 CSS Day+UX Special（地址：https:/noti.st/events/elQrNX/css-day-ux-special）活動上的主題分享Over the moon for container queries（地址：https:/noti.st/gregwhitworth/UDul7E/over-the-moon-for-container-queries）中也解釋了容器查詢在Web平臺上推進慢的相關原因。更重要的是

192、，Greg Whitworth還提供了使用9601年度精選技術棧內容終端技術篇/技術經典總結技術人的百寶黑皮書2022版大淘寶技術出品新的 JavaScript API 和 CSS 的新技術來實現容器查詢的特性。David Barrrron 也提出了一個可以避免這種困境的策略（地址：https:/ Suzanne在David Baron的策略基礎上提出了container方法(地址：https:/ 方法通過對被查詢的元素應用大小和布局的限制來實現。任何具有尺寸和布局限制的元素都可以通過一個新的 container規則進行查詢，其語法與現有的媒體查詢類似。這個提議已經被 W3C 的 CSS 工作

193、組采納（地址：https:/drafts.csswg.org/css-contain-3/），并已經添加到 CSS Containment Module Level 3（地址：https:/www.w3.org/TR/css-contain-3/）模塊中。有關于該功能的相關問題和各網格平臺推進進度，可以點擊這里查閱（地址：https:/ CSS Containment Module Level 3 還是 FPWD 版本，規范中所描述的語法不是最終版本，直到寫這篇文章，其語法規則還在變，因此文章中所展示的語法有可能會變以及相關的示例有一天就無效了：97 Must Try Best Brownie

194、s in Town High quality ingredients and best in-class chef.Light,tender,and easy to make Order now 1234567891001年度精選技術棧內容終端技術篇/技術經典總結技術人的百寶黑皮書2022版大淘寶技術出品 什么是容器查詢CSS 容器查詢最大的特點是：容器查詢允許開發者定義任何一個元素為包含上下文，查詢容器的后代元素可以根據查詢容器的大小或計算樣式的變化來改變風格！換句話說，一個查詢容器是通過使用容器類型屬性（container-type或container）指定要能的查詢類型來建立的。適用于其

195、后代的樣式規則可以通過使用container條件組規則對其進行查詢來設定條件。容器查詢為響應式設計提供了一種更加動態的方法。這意味著，如果你將此卡片組件放在側邊欄或放在頁面主體內部的網格中，則該組件本身根據容器而不是視口進行響應式的信息展示。首先，把卡片放到一個容器元素中，比如.card_container：98/*Default*/.card /./*CSS Container Queries*/.card_container 1234567代碼可能像下面這樣：01年度精選技術棧內容終端技術篇/技術經典總結技術人的百寶黑皮書2022版大淘寶技術出品也就是說，當卡片組件被放在一個容器中時，代表

196、著它被包含在該容器中，比如上面代碼中的.card_container。這也意味著，我們可以使用 CSS 的 container來查詢.card_container 的寬度，并在container 對.card 設置不同的樣式規則。從而達到設計師真正的意圖：比如，容器寬度（.card_container）分別在 400px、550px 和 700px 時為.card設置不同樣式：99/*containers width 400px*/container size(width 400px).card /./*containers width 550px*/container size(width

197、550px).card /./*containers width 700px*/container size(width 700px).card /.8910111213141516171819202122232425262728293001年度精選技術棧內容終端技術篇/技術經典總結技術人的百寶黑皮書2022版大淘寶技術出品Untitled airen CodePen（地址：https:/codepen.io/airen/pen/ZEvoBYL）（地址：https:/codepen.io/airen）（地址：https:/codepen.io/）10001年度精選技術棧內容終端技術篇/技術經典

198、總結技術人的百寶黑皮書2022版大淘寶技術出品拖動卡片右下角的滑塊，改變.card_container 容器大小，你可以看到卡片組件（.card）UI效果的變化：container規則，其工作方式與使用media的媒體查詢類似，但相反，container查詢父容器以獲取信息，而不是視口和瀏覽器的UserAgent。容器查詢的使用到目前為止，CSS 容器查詢的語法規則已經經歷了多個版本更新，上面示例中展示是最新的使用方式。下面這幾篇文章中可以索引到其每個版本的使用方式的差異：接下來，通一個容器查詢卡片的示例來向大家展示如何使用 CSS 容器查詢。定義一個包含性上下文要使用 CSS 容器查詢特性，

199、首先要定義一個包含性上下文（Containment Context）。這個有點類似于使用 Flexbox 和 Grid 布局（定義Flexbox 或 Grid 上下文使用的是 display 屬性），只不過，定義一個包含性的上下文使用的不是我們熟知的 display 屬性，而是一個新的CSS屬性，即 container。在一個元素上顯式使用 container 可以告訴瀏覽器以后要針對這個容器進行查詢，以及具體如何查詢該特定的容器。比如，上面演示的示例中，我們在.card_container 元素上（.card的父容器）顯式設置了 container-type 的值為 inline-size：

200、上面的代碼告訴瀏覽器，可以基于.card_container容器的內聯軸（Inline Axis）方向尺寸變化進行查詢。也就是說，當.card_container容器寬度大小變化到指定的某個值時，其后代元素的樣式就可以進行調整。container-type 是 container 屬性中的一個子屬性，另外，還可以顯式使用 container-name 來命名你的容器，即給一個包含性上下文指定一個具體的名稱：初探CSS容器查詢（地址：https:/ container和 container（地址：https:/ container-type:inline-size123101.card_cont

201、ainer container-type:inline-size;container-name:card;/*等同于*/.card_container container:inline-size/card;123456789container containerName size(width 45rem)/*應用了包含性上下文后代元素的 CSS*/container size(width 45rem)/*應用了包含性上下文后代元素的 CSS*/123456701年度精選技術棧內容終端技術篇/技術經典總結技術人的百寶黑皮書2022版大淘寶技術出品如果一個容器查詢被應用到一個沒有定義的包含祖先元素

202、上，查詢將無法應用。也就是說，無論是 body 還是 html 元素，都沒有默認的回退包含上下文。另外，定義包含上下文名稱時不能是 CSS 的關鍵詞，比如 default、inher-it、initial 等。注意：container-name 可以省略，如果省略將會使用其初始值none，但 container-type 不可省略，如果省略的話則表示未顯式聲明包含性上下文！定義一個容器查詢現在我們知道使用 container（或其子屬性 container-type和container-name）對一個元素顯式聲明包含上下文（對一個元素應用包含性）。有了這個包含性上下文之后，就可以使用 CSS

203、 的 規則container來對應用了包含性元素進行查詢，即對容器進行查詢。container 規則的使用和 media 以及 supports相似：這種方式對于同一個上下文中有多個包含性上下文時非常有意義，可以更明確地知道哪些查詢會影響元素。你可以使用簡寫屬性container，只不過需要在 container-type 和 container-name 之間添加斜杠分割符/：.card_container container-name:card12310201年度精選技術棧內容終端技術篇/技術經典總結技術人的百寶黑皮書2022版大淘寶技術出品這兩種方式都是正確的使用姿勢，第一個示例中的 c

204、ontainerName 指的是 container-name 顯式聲明的包含性上下文的名稱。如果在container 中沒有指定查詢的容器名稱，那么這個查詢將是針對離樣式變化最近的聲明了包含性上下文的元素進行查詢。比如：表示這個查詢將是針對.card 元素最近的顯式聲明了包含性上下文的元素進行查詢。代碼中的size()函數是容器查詢中的新語法規則。這也是容器查詢語法變化之一，即 對查詢類型進行了更明確的規定。因為規范已經提高到不僅可以根據尺寸（size）屬性查詢，還可以根據樣式（style）屬性進行查詢。container size(width 30em).card border-radiu

205、s:20px;12345103container style(-card:large)/*CSS Style*/container size(width 30em)and style(-card:large)/*CSS Style*/123456701年度精選技術棧內容終端技術篇/技術經典總結技術人的百寶黑皮書2022版大淘寶技術出品到寫這篇文章的時候，還沒有瀏覽器支持對樣式進行查詢。另外，示例中用于 container 的查詢條件(width 30em)相當于(min-width:30em)。使用數學表達式要比使用 min-width或max-width更易于理解，自 Media Queri

206、es Level 4（地址：https:/www.w3.org/TR/mediaqueries-4/#mq-range-context）開始，在 media 規則中，也可以使用我們熟悉的數學表達式，比如=、=等來替代以往不易于理解的min-和max-：上面示例代碼中同時出現 container 和 container，但他們并不是指的同一個屬性，前者是一個CSS屬性，后者是一個CSS代碼塊。而且兩者有本質的區別：正如 Terrible Mia（容器查詢規范設計者）在 Twitter 上分享的一樣，可以使用 style()函數對樣式進行查詢：container 是 container-type

207、和 container-name 的簡寫屬性，用來顯式聲明某個元素是一個查詢容器，并且定義查詢容器的類型（可以由container-type指定）和查詢容器的名稱（由container-name指定）。container（帶有規則），它類似于條件CSS中的media或supports規則，是一個條件組規則，其條件是一個容器查詢，它是大?。╯ize）和（或）樣式（style）查詢的布爾組合。只有當其條件為真（true），container規則塊中的樣式都會被用戶代理運用，否則將被視為無效，被用戶代理忽略。1.2.10401年度精選技術棧內容終端技術篇/技術經典總結技術人的百寶黑皮書2022版大淘

208、寶技術出品如果你對這方面討論感興趣，可以閱讀 Ahmad Shadeed 的 The State Of Mobile First and Desktop First一文。（地址：https:/ Web 設計的出現以及移動終端設備越來越多，在設計中也有移動端優先（Mobile First）還是桌面端優先（Desktop First）的爭執：10501年度精選技術棧內容終端技術篇/技術經典總結技術人的百寶黑皮書2022版大淘寶技術出品我們通過 CSS Grid 來完成卡片的布局。先從最窄的開始，添加下面CSS代碼：如上圖所示，我們從左往右來實現卡片不同狀態斷點下的UI效果。先從最窄的卡片開始（最左

209、側，Default狀態）。構建這個卡片組件，所需要的 HTML 結構如下：Container Queries Rule Lorem ipsum dolor,sit amet consectetur adipisicing elit.Quis magni eveniet natus nulla distinctio eaque?Order now 12345678.card display:grid;gap:1rem;margin:5vh auto;border-radius:0.5rem;box-shadow:0 0.25rem 0.5rem-0.15rem hsla(0 0%0%/55%);

210、background-color:#fff;.card_thumbnail max-width:100%;aspect-ratio:16/9;height:auto;object-fit:cover;border-radius:0.5rem 0.5rem 0 0;.card_title font-weight:700;font-size:clamp(1.2rem,1.2rem+3vw,1.5rem);padding:0 20px;white-space:nowrap;text-overflow:ellipsis;overflow:hidden;.card_describe 1234567891

211、0111213141516171819202122232425262710601年度精選技術棧內容終端技術篇/技術經典總結技術人的百寶黑皮書2022版大淘寶技術出品嘗試調整上面示例中視窗的大?。好襟w查詢 vs.容器查詢通過上面的示例的介紹，我想你對容器查詢特性已經有了一個較清晰的認識了。從使用角度來看，容器查詢和媒體查詢是非常的相似，那么有人可能會問，有了容器查詢是不是就不再需要媒體查詢特性了呢？在回答這個問題之前，我們簡單的來看兩者的差異。眾所周知，媒體查詢查詢的瀏覽器視窗寬度（當然還有其他查詢特性），而容器查詢查詢的是組件其父容器（具有包含性上下文的祖先元素）的寬度（或樣式）。下圖可能可以

212、清晰的闡述兩者的差異：107.card_container container:inline-size;12301年度精選技術棧內容終端技術篇/技術經典總結技術人的百寶黑皮書2022版大淘寶技術出品正如上面的效果所示，卡片組件可以隨著其容器（.card_container）寬度自動變化，在窄屏下效果看上去還不錯，但在寬屏下，效果看上去有點怪怪的。不過不用擔心，這僅是最初的效果。我們期望的是通過容器查詢的特性，在容器不同斷點下改變卡片組件的布局。按照前面所介紹的，我們需要先創建一個包含性上下文，即在.card_container 上使用 container 顯式聲明該元素是一個包容性上下文。co

213、lor:#666;line-height:1.4;padding:0 20px;display:-webkit-box;-webkit-box-orient:vertical;-webkit-line-clamp:3;overflow:hidden;.card_button display:inline-flex;justify-content:center;align-items:center;border:none;border-radius:10rem;background-color:#feca53;padding:10px 20px;color:#000;text-decoratio

214、n:none;box-shadow:0 3px 8px rgb(0 0 0/7%);transition:all 0.2s linear;font-weight:700;justify-self:end;margin:0 20px 20px 0;cursor:pointer;.card_button:hover background-color:#ff9800;28293031323334353637383940414243444546474849505152535455565710801年度精選技術棧內容終端技術篇/技術經典總結技術人的百寶黑皮書2022版大淘寶技術出品Untitled ai

215、ren CodePen（地址：https:/codepen.io/airen/pen/MWrXNGM）（地址：https:/codepen.io/airen）（地址：https:/codepen.io/）可以在上面示例中嘗試拖動卡片右下角滑塊改變卡片容器寬度，你將看到的效果如下：有了這樣一個卡片組件之后，如果將其放在不同的位置，即使是同一頁面，同一視窗斷點下，也會根據其容器斷點自動匹配最為適合的布局（或UI效果）。比如：Untitled airen CodePen（地址：https:/codepen.io/airen/pen/WNdKgMK）（地址：https:/codepen.io/aire

216、n）（地址：https:/codepen.io/）效果如下：10901年度精選技術棧內容終端技術篇/技術經典總結技術人的百寶黑皮書2022版大淘寶技術出品就我個人認為，兩者不是誰替代誰的關系，更應該是兩者共存的關系。容器查詢特性的出現，我們可以不再局限于視窗斷點來調整布局或UI樣式，還可以基于容器斷點來調整布局或UI。換句話說，媒體查詢是一種宏觀的布局（Macro Layout），可以用于整體頁面布局；而容器查詢可以調整組件的每個元素，創建了一種微觀的布局（Micro Layout）。容器查詢解決的是什么問題？眾所周知，響應式設計的概念的核心是 CSS 媒體查詢的出現，它允許開發者根據瀏覽器視

217、窗的尺寸來設置各種樣式規則。也正因此，響應式設計和CSS媒體查詢開啟了更多的 Web 布局解決方案，以及多年來圍繞響應視窗尺寸創建的最佳實踐。而且，近些年來，設計系統和組件庫也得到了更廣泛的普及。對于更多開發者而言，更大的期望是：一次建成，隨地部署！這也意味著一個單獨開發的 Web 組件可以在任何情況下工作，以使建立復雜的界面更加有效和一致。只不過，這些組件會組合在一起，形成一個Web頁面或Web應用界面。目前，在只有媒體查詢的情況下，往往需要額外的一層來協調跨視窗大小變化的組件的突變。在這些情況下，你可能不得不在更多的斷點下使用更多的類名來設置不同的樣式規則。甚至更慘的是，即使這樣做仍然很多

218、情況之下也無法達到最理想的UI表面。很多時候，響應式Web設計不是關于瀏覽器視窗尺寸而是關于容器的尺寸大小，比如：11001年度精選技術棧內容終端技術篇/技術經典總結技術人的百寶黑皮書2022版大淘寶技術出品慶幸的是，CSS容器查詢的出現，使我們超越了只考慮瀏覽器視窗尺寸的范圍，并允許任何組件或元素對定義的容器尺寸做出響應。因此，雖然你可能仍然使用響應式來給Web頁面布局，但Web頁面的任何一個組件都可能通過容器查詢來定義自己的樣式變化。然后，它可以根據它是在一個窄的還是寬的容器中顯示，來調整它的樣式。容器查詢使我們不再只考慮瀏覽器視窗尺寸大小，而是允許任何組件或元素對定義的容器尺寸做出響應！

219、也就是說，有了CSS容器查詢，你就能以一種非常精確和可預測的方式定義一個組件的全部樣式。11101年度精選技術棧內容終端技術篇/技術經典總結技術人的百寶黑皮書2022版大淘寶技術出品 設計時考慮容器查詢雖然響應式設計給Web設計師帶來了更多的可有性，但響應式設計還是有很多的局限性。對于Web設計師而言，更期待的是能夠根據組件容器尺寸來提供不同的設計風格。依舊拿卡片組件來舉例：也就是說，CSS容器查詢特性來了之后，作為一名Web設計師，在設計Web頁面（或組件）時，就需要基于容器尺寸考慮如何設計。這樣一來，可以向Web開發人員提供組件的細節和變化，Web開發人員也可以基于這些細節進行編碼（進行開

220、發）。不過，這并不意味著容器查詢特性之后響應式設計是就失去了意義。在未來，容器查詢和響應式設計是共存的，簡單地說，Web設計師在設計組件時可能會將組件分為以下幾個部分：1.基于視窗（CSS媒體查詢）2.基于容器（CSS容器查詢）3.通用型（不受影響的組件）比如：11201年度精選技術棧內容終端技術篇/技術經典總結技術人的百寶黑皮書2022版大淘寶技術出品在未來，Web設計師給Web開發者投喂的設計稿可能就會像下圖這樣了：或許因為容器查詢的到來，設計師在設計Web的時候，也可能會做出相應的調整。投喂給Web開發的設計稿也可能會和以往的模式有所差異。那么這個時候，Web開發者就需要具備正確理解設計

221、師的意圖了。比如，Web設計師可能在未來的設計中會提供向下圖的卡片組件設計：作為Web開發人員，看到上圖設計效果，需要改變以往對設計圖意圖的理解，不能繼續執著于基于視窗尺寸來調整組件UI。11301年度精選技術棧內容終端技術篇/技術經典總結技術人的百寶黑皮書2022版大淘寶技術出品上圖是基于視窗的一種開發模式，需要為卡片組件設置不同的類名，并且基于視窗尺寸，在相應的類名下調整卡片組件UI。有了容器特性時，我們可以基于現代的Web布局技術，比如Flexbox或Grid布局，讓卡片組件基于其容器來調整其UI：正如上圖所示，可以基于視窗大小采用CSS媒體查詢特性，Flexbox或Grid布局等技術改

222、變卡片容器.card_con-tainer的大小，從而讓卡片組件根據其容器尺寸大小做出相應響應。擁有一個能根據其父容器尺寸做出響應（UI調整）的組件是非常有用的，正如你看到的，我們可以只構建一個組件，就可以滿足不同視窗布局下的設計訴求！容器查詢不應該讓組件變得復雜化組件是有由很多個元素組合在一起構成的：11401年度精選技術棧內容終端技術篇/技術經典總結技術人的百寶黑皮書2022版大淘寶技術出品雖然容器查詢特性到來，可以讓組件根據其容器尺寸來做出響應，但要記住的是，做出響應變化應該要有一個度。如果過度設計的話，對于Web開發人員而言，與其使用容器查詢特性來實現UI響應，還不如重新構建一個獨立的

223、全新組件。拿用戶信息組件（UserProfile）為例，組件內部結構保持不變，或者至少不會增加新的結構，只需稍加調整，比如調整布局就可以實現不同的UI效果，或者讓內部元素顯示隱藏切換等。在這種情景之中，采用容器查詢特性才能顯現其魅力：作用域樣式為了完善容器查詢特性，CSS 工作組還在積極討論作用域樣式（Scoped Styles）（地址：https:/css.odd- CSS 中另一個與容器查詢同樣被受期待的特性，級聯分層，即 layer 也可以用來解決命名沖突，樣式沖突的問題。該特性已得到了 Safari 和 Chrome 瀏覽器支持。如果你對該話題感興趣的話，可以閱讀初探 CSS 的級聯層

224、（?layer?）（地址：https:/ /*targeting the scope root*/.light-theme:scope.tab /*contextual styles*/123456789101111601年度精選技術棧內容終端技術篇/技術經典總結技術人的百寶黑皮書2022版大淘寶技術出品大致主要分為兩種類型，雙屏可折疊設備（如 Microsoft Surface Duo）和單屏可折疊設備（如 Huawei Mate XS）：在多屏幕或可折疊設備上，Web應用或Web頁面在這些設備上的打開姿勢也將會有所不同，應用可以單屏顯示，也可以跨屏顯示：換句話說，我們的應用或頁面要具備這種

225、跨越屏幕的能力，也要具備響應這種跨越的能力，以及還可能需要具備邏輯分隔內容的能力等。11701年度精選技術棧內容終端技術篇/技術經典總結技術人的百寶黑皮書2022版大淘寶技術出品可以說，多屏幕或折疊屏設備開啟了更廣闊的屏幕空間以及用獨特的姿勢將用戶帶入到另一個世界。針對于這種設備，除了用戶之外，對于UI設計師，用戶體驗師和Web開發人員都需要重新面臨解鎖前所未有的Web體驗。這也將是近十年來，Web開發帶來最大的變化之一，以及開發人員所要面臨的最大挑戰之一。在這里我們針對多屏幕和折疊屏設備的響應，就稱之為響應外形的需求。這也是響應式 Web 設計的一部分。由于可折疊設備相對來說是新型設備，面對

226、這些新型設備時很多開發者并沒有做好相應的知識儲備，甚至是不知道從何入手。事實上呢？有些Web開發者已經開始在為我們制定這方面的API，除了文章開頭提到的三星（Sam-sung）的 Diego Gonzlez，英特爾（Intel Corporation）的 Kenneth Rohde Christiansen之外還有微軟（Microsoft）的 Bogdan Brinza、Daniel Libby和Zouhir Chahoud。只不過對于Web開發者來說，現在這些制定的規范（CSS相關的特性）和Web API（JavaScript API）還很新，不確定因素過多，甚至差異性也比較大。到目前為止主

227、要分為兩個部分。其中一個部分是可用于雙屏幕和折疊屏的WebAPI（地址：https:/ww- Bogdan Brinza、Daniel Libby和Zouhir Chahoud一起制定的，更適用于“有縫”的折疊處設備；另一部分是目前處于W3C規范ED階段的 屏幕折疊 API（地址：https:/w3c.github.io/device-pos-ture/），它更適用于“無縫”的折疊設備。argyleink在Github上發起了一個使用CSS媒體特性來檢測折疊屏的討論（地址：https:/ screen-spanning 這個特性可以用來幫助Web開發人員檢測“根視圖”是否跨越多個相鄰顯示區域，

228、并提供有關這些相鄰顯示區域配置的詳細信息。11801年度精選技術棧內容終端技術篇/技術經典總結技術人的百寶黑皮書2022版大淘寶技術出品也可以使用 screen-fold-posture 和 screen-fold-angle 兩個媒體查詢來對無縫設備進行查詢：還可以使用 horizontal-viewport-segments 和 vertical-viewport-segments 查詢視口的數量：horizontal-viewport-segments 和 vertical-viewport-segments是最新的兩個查詢特性，它們將替代最初的screen-spanning這個媒體查詢

229、特性！除此之外，還可以通過一些折疊姿勢來進行查詢：11901年度精選技術棧內容終端技術篇/技術經典總結技術人的百寶黑皮書2022版大淘寶技術出品/有縫折疊media(spanning:single-fold-vertical)/CSS Code./無縫折疊media(screen-fold-posture:laptop)/CSS Code.12345678910除了CSS媒體查詢之外，還引入了六個新的CSS環境變量，以幫助開發者計算顯示區域的幾何形狀，計算鉸鏈區域被物理特征遮擋的幾何形狀：上圖中展示的這六個CSS環境變量將替代以前的 env(fold-top)、env(fold-left)、e

230、nv(fold-width)和env(fold-height)。對于Web開發者來說，我們可以像下面這樣來使用：12001年度精選技術棧內容終端技術篇/技術經典總結技術人的百寶黑皮書2022版大淘寶技術出品/折疊角度查詢media(max-screen-fold-angle:120deg)/CSS Code./視口數量查詢media(horizontal-viewport-segments:2)/CSS Code.media(vertical-viewport-segments:2)/CSS Code.111213141516171819202122在現代布局中，將這些媒體查詢特性、CSS環境

231、變量和CSS Grid布局結合在一起，就可以很輕易的滿足外形響應的需求變化。比如：Stephanie 在她的最新博文Building Web Layouts For Dual-Screen And Foldable Devices（地址：https:/ -sidebar-width:5rem;media(spanning:single-fold-vertical):root -sidebar-width:env(viewport-segment-left 0 0);main display:grid;grid-template-columns:var(-sidebar-width)1fr;12

232、3456789101112131412101年度精選技術棧內容終端技術篇/技術經典總結技術人的百寶黑皮書2022版大淘寶技術出品.recipe display:grid;grid-template-columns:repeat(3,1fr);grid-template-rows:minmax(175px,max-content);grid-gap:1rem;.recipe-meta grid-column:1/4;img grid-column:1/4;.recipe-details_ingredients grid-row:3;.recipe-details_preparation grid

233、-column:2/4;grid-row:3;media(horizontal-viewport-segments:2).recipe grid-template-columns:env(viewport-segment-width 0 0)1fr 1fr;grid-template-rows:repeat(2,175px)minmax(175px,max-content);.recipe-meta grid-column:1/2;img grid-column:2/4;grid-row:1/3;.recipe-details_ingredients grid-row:2;1234567891

234、01112131415161718192021222324252627282930313233343536373839404142122聊聊安卓折疊屏給交互設計和開發帶來的變化（地址：https:/ API（地址：https:/ API（地址：https:/ CSS and JavaScript update for web developers（地址：https:/ Web Layouts For Dual-Screen And Foldable Devices（地 址：h t t p s:/w w w.s m a s h i n g m a g a z i n e.c o m/2 0 2

235、2/0 3/b u i l d i n g-w e b-l a y-outs-dual-screen-foldable-devices/）1.2.3.4.5.6.01年度精選技術棧內容終端技術篇/技術經典總結技術人的百寶黑皮書2022版大淘寶技術出品 .recipe-details_preparation grid-column:2/4;grid-row:3;43444546474849如果你對多屏或折疊屏這方面技術感興趣的話，還可以閱讀:技術的變革是永無止境的，我們將來要面對的用戶終端也絕不會僅現于目前能看到的終端設備和媒介，就好比現在運用于游戲行業的 VR（虛擬現實）和 AR（增強現實）設

236、備。雖然現在 VR 和 AR 用于其他行業的場景還很少見，但我們可以預見，在 VR 和 AR 設備越來越成熟和更多的設備發布之后，我們就能看到 VR 和 AR 就像我們已經看到幾十年前的觸摸屏設備一樣?；蛟S有一天，你設計（或開發）的Web頁面或應用就需要能在 VR 和 AR 設備上有一個較好的呈現。12301年度精選技術棧內容終端技術篇/技術經典總結技術人的百寶黑皮書2022版大淘寶技術出品上圖來自于UX Case Study:Metaverse Banking VR/AR Design Concept of the Future（地址：https:/ Web 設計要響應的外形需求可能會更豐富

237、，更復雜?？偨Y響應式 Web 設計已經將 Web 帶到了今天人們所能接觸到的每一個連接的屏幕上。Web設計師和創意開發者用創造性的思維、大膽的想法和某種無畏的精神探索、測試和迭代他們的想法，使在線體驗更有吸引力、更容易訪問和更智能，推動了設計方法的發展。就好比這里所提到的 組件驅動式Web設計。12401年度精選技術棧內容終端技術篇/技術經典總結技術人的百寶黑皮書2022版大淘寶技術出品組件驅動式 Web 設計的到來或者說 CSS 容器查詢、作用域樣式、級聯層控制等特性的出現，這些先進的特性使我們有機會從頁面布局、全局樣式和用戶樣式中孤立組件樣式，從而實現更具彈性的響應式設計。這意味著你現在可

238、以使用基于頁面的媒體查詢設計宏觀布局，包括多屏或折疊屏的細微差異；同時使用基于容器查詢給組件設計微觀上布局，并添加基于用戶偏好的媒體查詢，來實現基于用戶的獨特偏好和需求的定制化體驗。這就是下一代響應式 Web 設計，也就是 組件驅動式 Web 設計（或開發）。它結合了宏觀布局和微觀布局，最重要的是，也將用戶定制化和尺寸外形都考慮到了。這些變化中的任何一個都將構成我們對web設計方式的重大轉變。但它們結合在一起，意味著我們甚至在概念化響應性設計方面的一個巨大轉變。是時候思考不止步于視口大小的響應性設計了，并開始考慮所有這些新方向，來獲得更好的基于組件和定制化的體驗。也就是說。如果我們將這些組件驅

239、動的功能納入設計系統，并從整體上改變我們對待 Web 設計的方式，我們就可以利用這些功能以及更多的功能來改善每一個登陸你網站的訪問者的用戶體驗。我們可以為他們提供真正個性化的體驗，提高參與度和轉化率，并最終提高用戶對你的品牌的感知。我們不再是為用戶群體設計。我們對 受眾一詞的理解將發生變化，因為內容和體驗將為一個人而不是許多人的受眾而變得高度集中。組件驅動的響應式 Web 設計將使 Web 真正的可移植，并能適應甚至還沒有發明的設備。與其在今天的技術范圍內追趕和設計，我們將只為用戶設計。最后，希望文章中提到的概念和技術對你有所幫助。團隊介紹我們是F(X)Team團隊，F(x)Team，F(x)

240、指函數 F(x)，是機器學習中常出現的符號，深度學習的本質也是求 f(x)的最優解，意味擁有不同特征的成員經過 fx 團隊神奇作用，不斷“訓練”，一起找到前端智能化團隊的最優解。我們致力于前端智能化領域的探索和實踐，賦能淘寶、天貓、聚劃算等日常與大促（如雙 11）業務，是淘系前端智能化實踐的領路人，也是阿里經濟體前端委員會智能化方向的核心團隊。我們在 D2C（Design to Code）領域開放了 Imgcook 平臺，逐步釋放阿里生態的前端生產力；同時我們也與 Google 的 tensorflow 團隊保持長線合作，基于 tfjs-node 之上，開源了我們的前端算法工程框架 Pipco

241、ok，引領前端行業向智能化時代邁進。12501年度精選技術棧內容終端技術篇/技術經典總結技術人的百寶黑皮書2022版大淘寶技術出品Flutter 新一代圖形渲染器 Impeller作者：谷鳴出品：大淘寶技術Flutter在2022年的Roadmap中提出需要重新考慮著色器的使用方式，計劃重寫圖像渲染后端。最近該渲染后端 Impeller（葉輪）初見端倪，本文將介紹 Impeller 解決的問題、目標、架構和渲染細節。背景Flutter在過去一年多時間解決了很多Jank問題，但著色器編譯導致的Jank問題一直沒有徹底解決。這里我們先了解下什么著色器編譯Jank。Flutter底層使用了skia做

242、為2D圖形渲染庫，而skia內部定義了一套SkSL（Skia shading language），SkSL 屬于 GLSL 變體。在Flutter的光柵化階段，當第一次使用著色器時Skia會根據繪圖命令和設備參數生成 SkSL，然后再將 SkSL 轉換為特定后端（GLSL、GLSL ES 或 Metal SL）著色器，并在設備上編譯為著色器程序。而編譯著色器可能花費幾百毫秒，導致數十幀的丟失。定位著色器編譯Jank問題可以查看trace信息是否有 GrGLProgramBuilder:finalize 調用。Flutter為了解決該問題，在Flutter 1.20 版本中為GL后端實現了SkS

243、L預熱機制，支持離線收集應用程序中使用的 SkSL 著色器并保存為json文件，然后把該文件打包到應用程序中，最終用戶首次打開應用程序時預編譯 SkSL著色器，從而減少著色器編譯 jank。隨后，在 Flutter 2.5中支持了 iOS metal 著色器的預編譯。Flutter gallery應用預熱前后，在Moto G4上從90ms減少到40ms，在iPhone 4s上從300ms減少到80ms，性能提升很明顯。在Flutter官方提供了SkSL著色器預熱后，社區經常提到的一些高頻問題收集如下：12601年度精選技術棧內容終端技術篇/技術經典總結技術人的百寶黑皮書2022版大淘寶技術出品

244、Q1.為什么不預編譯用到的所有著色器？為了獲得最佳性能，Skia GPU backend在運行時會根據一些參數（如繪圖命令，設備型號等）動態生成著色器。這些參數的組合會生成大量的著色器，無法在應用程序中預編譯和內置。Q2.不同設備上捕獲的 SkSL shader 通用嗎？理論上，沒有機制保證在一臺設備上捕獲的 SkSL shader 在其他設備上也有效。實際上，（有限的）測試表明 SkSL shader 能表現的較好，即使在iOS上捕獲的 SkSL 應用到Android設備，或者模擬器上捕獲的SkSL應用到真機上。Q3.為什么不創建一個超級著色器并僅編譯一次？這樣的著色器會非常大，本質上是重新

245、實現 Skia GPU 功能。大shader需要更長的編譯時間，從而引入更多的 Jank。但SkSL著色器預熱也存在自身的缺點和局限性：1.應用包體積變大2.應用啟動時間變長，因為需要預編譯 SkSL shader3.開發體驗不友好4.SkSL shader 的通用性無保證且不可預測以下時間線列舉了Flutter在解決Jank問題上的努力和進展：12701年度精選技術棧內容終端技術篇/技術經典總結技術人的百寶黑皮書2022版大淘寶技術出品對于著色器編譯Jank問題，官方經過多次嘗試依然無法徹底解決，因此在2022年的roadmap中請明確提出要重新考慮使用著色器的方式，計劃重寫圖像渲染后端。在

246、2022年計劃在iOS上將 Flutter 遷移到新架構上，然后根據經驗將該解決方案移植到其他平臺上。最近，該圖形渲染后端 impeller（葉輪）初見端倪，接下來讓我們看看 impel-ler有什么獨特之處。Impeller架構Impeller是為flutter量身定做的渲染器，目前處于早起原型階段，僅實現了metal后端，支持iOS和Mac系統。工程方面，他依賴了 flutter fml 和 display list，并實現了display list dispatcher 接口，可以容易的替換skia。Impeller被flutter flow子系統所使用，因此得名。Impeller核心目

247、標：impeller軟件架構可預測的性能：在編譯時離線編譯所有著色器，并根據著色器預先構建 pipeline state objects?？蓹z測：所有的圖形資源（textures、buffers、pipeline state對象等）都被追蹤和標記。動畫可以被捕獲并持久化到磁盤而不影響渲染性能?？梢浦玻簺]有與特定的渲染API相綁定，著色器編寫一次并在需要時轉換。使用現代圖形API：大量使用（但不依賴）現代圖形API（如Metal和Vulkan）的特性。有效利用并發性：可以在多線程上分發單幀工作負載。1.2.3.4.5.128Compiler:host端工具，包含著色器 Compiler 和 Re

248、flector。Compiler用于把 GLSL 4.60 著色器源碼離線編譯為特定后端的著色器（如MSL）。Reflector 根據著色器離線生成 C+shader bindings，以在運行時快速構建pipeline state objects(PSO)Renderer:用于創建buffer、從shader bindings生成pipeline state objects、設置RenderPass、管理uniform-buffers、細分曲面、執行渲染任務等Entity:用于構建2D渲染器，包含了著色器，shader bindings和pipeline state objectsAiks:

249、封裝 Entity 以提供類 Skia API，臨時存在，便于對接到 flutter flow1.2.3.4.01年度精選技術棧內容終端技術篇/技術經典總結技術人的百寶黑皮書2022版大淘寶技術出品impeller大致可以分為Compiler、Renderer，Entity、Aiks以及基礎庫Geomety和Base等幾個模塊。Impeller著色器離線編譯impeller compiler模塊是解決著色器編譯Jank的關鍵所在。在編譯階段，首先把compiler相關源碼編譯為host工具impellerc binary。然后開始著色器的第一編譯階段，利用impellerc compiler

250、把/impeller/entity/shaders/目錄下所有著色器源碼（包括頂點著色器和片段著色）編譯為著色器中間語言 SPIR-V。再開始著色的第二個編譯階段，把 SPIR-V 轉換為特定后端的高級著色器語言（如Metal SL），隨后（iOS上利用Metal Binary Archives）把特定后端的著色器源碼（Metal著色器）編譯為 shader library。同時，另外一條路徑中利用impellerc reflector處理SPIR-V生成 C+shader binding，用于在運行時快速創建pipeline state objecs（PSO）。Shader bind-ing

251、生成的頭文件中包括了一些結構體（有適當的填充和對齊），使得可以將uniform data和vertex數據直接指定給著色器，而無需處理綁定和頂點描述符。最后把shader library和binding sources編譯進flutter engine中。12901年度精選技術棧內容終端技術篇/技術經典總結技術人的百寶黑皮書2022版大淘寶技術出品13001年度精選技術棧內容終端技術篇/技術經典總結技術人的百寶黑皮書2022版大淘寶技術出品這樣所有著色器在離線時被編譯為shader library，在運行時不需要執行任何編譯操作，從而提升首幀渲染性能，也徹底解決了著色器編譯帶來的jank問題。

252、Shader Bindingsimpeller中的著色器僅需要基于 GLSL 4.60 語法編寫一次，編譯時轉換為特定后端的著色器和binding。比如 solid_fill.vert 頂點著色器經過離線編譯后生成了solid_fill.vert.metal，solid_fill.vert.h和solid_fill.vert.mm文件。solid_fill.vert：solid_fill.vert.metal：uniform FrameInfo mat4 mvp;vec4 color;frame_info;in vec2 vertices;out vec4 color;void main()g

253、l_Position=frame_info.mvp*vec4(vertices,0.0,1.0);color=frame_info.color;12345678910111213using namespace metal;struct FrameInfo float4x4 mvp;float4 color;struct solid_fill_vertex_main_out float4 color user(locn0);float4 gl_Position position;struct solid_fill_vertex_main_in float2 vertices attribute(

254、0);1234567891011121314151613101年度精選技術棧內容終端技術篇/技術經典總結技術人的百寶黑皮書2022版大淘寶技術出品solid_fill.vert.h：;vertex solid_fill_vertex_main_out solid_fill_vertex_main(solid_fill_vertex_main_in in stage_in,constant FrameInfo&frame_info buffer(0)solid_fill_vertex_main_out out=;out.gl_Position=frame_info.mvp*float4(in.v

255、ertices,0.0,1.0);out.color=frame_info.color;return out;1718192021222324252627struct SolidFillVertexShader /=/Stage Info=/=static constexpr std:string_view kLabel=SolidFill;static constexpr std:string_view kEntrypointName=solid_fill_vertex_main;static constexpr ShaderStage kShaderStage=ShaderStage:kV

256、ertex;/=/Struct Definitions=/=struct PerVertexData Point vertices;/(offset 0,size 8);/struct PerVertexData(size 8)struct FrameInfo Matrix mvp;/(offset 0,size 64)Vector4 color;/(offset 64,size 16)Padding _PADDING_;/(offset 80,size 48);/struct FrameInfo(size 128)/=/Stage Uniform&Storage Buffers=/=stat

257、ic constexpr auto kResourceFrameInfo=ShaderUniformSlot /FrameInfo FrameInfo,/name 0u,/binding1234567891011121314151617181920212223242526272813201年度精選技術棧內容終端技術篇/技術經典總結技術人的百寶黑皮書2022版大淘寶技術出品 ;/=/Stage Inputs=/=static constexpr auto kInputVertices=ShaderStageIOSlot /vertices vertices,/name 0u,/attribute

258、 location 0u,/attribute set 0u,/attribute binding ShaderType:kFloat,/type 32u,/bit width of type 2u,/vec size 1u /number of columns ;static constexpr std:array kAllShaderStageInputs=&kInputVertices,/vertices ;/=/Stage Outputs=/=static constexpr auto kOutputColor=ShaderStageIOSlot /color color,/name

259、0u,/attribute location 0u,/attribute set 0u,/attribute binding ShaderType:kFloat,/type 32u,/bit width of type 4u,/vec size 1u /number of columns ;static constexpr std:array kAllShaderStageOutputs=&kOutputColor,/color ;/=/Resource Binding Utilities=/=29303132333435363738394041424344454647484950515253

260、545556575859606162636465666768697013301年度精選技術棧內容終端技術篇/技術經典總結技術人的百寶黑皮書2022版大淘寶技術出品solid_fill.vert.mm 文件僅對相應結構體進行填充和對齊校驗，無實際功能。對于solid_fill.frag 同樣的處理邏輯，生成了solid_fill.frag.metal，solid_fill.frag.h和solid_fill.frag.mm文件。/Bind uniform buffer for resource named FrameInfo.static bool BindFrameInfo(Command&c

261、ommand,BufferView view)return command.BindResource(ShaderStage:kVertex,kResourceFrameInfo,std:move(view);/struct SolidFillVertexShader7172737475767713401年度精選技術棧內容終端技術篇/技術經典總結技術人的百寶黑皮書2022版大淘寶技術出品Shader binding文件包含了著色器所有描述信息，如入口點，輸入/輸出結構，以及對應的buffer slot。運行時根據shader binding可以快速生成為pipeline state objec

262、ts。另外，bindings中輸入/輸出結構是有填充和對齊的，所以頂點和uniform數據可以直接內存映射。Impeller渲染流程impeller通過分別繼承了IOSContext、IOSSurface和flowSurface，實現了IOSContextMetalImpeller、IOSSurfaceMetalImpeller和GPUSurfaceMetalImpeller結構對接到了flutter flow子系統中。在光柵化階段，通過DisplayListCanvasRecorder（繼承自SkNoDrawCanvas并實現了所有SkCanvas的函數）合成Layer Tree，把所有la

263、yer中的繪圖命令轉換為一個個的DLOps，并存儲到DisplayList結構。DLOps中存儲了繪圖的所有數據信息，如常見的AnitiAliasOp，SetColorOp，DrawRectOp等，共有73種Ops。如下為drawRect的DrawRectOp的結構：struct DrawRectOp final:DLOp static const auto kType=DisplayListOpType:kDrawRect;explicit DrawRectOp(SkRect rect):rect(rect)const SkRect rect;void dispatch(Dispatcher

264、&dispatcher)const dispatcher.drawRect(rect);123456789101113501年度精選技術棧內容終端技術篇/技術經典總結技術人的百寶黑皮書2022版大淘寶技術出品接下來進入impeller的渲染流程，使用DisplayListDispatcher執行DisplayList中所有Ops，在Op的dispatch()函數中調用DisplayListDispatcher的相應函數，把繪圖信息轉換為EntityPass結構。如果有saveLayer操作，則創建子EntityPass，形成EntityPass樹形結構。同時把多個相關聯的Ops轉換為Entit

265、y存儲到EntityPass中。每個Entity會對應一種Contents，表示一種繪圖操作（如drawRect/clipPath等），共有11種Contents（參見第五小節附錄impeller類圖）?？梢?，DisplayList記錄了細粒度的Op信息，結構扁平，無層次關系；轉換為EntityPass后，對Ops進行了組裝，根據savaLayer操作生成了有層次結構EntityPass tree，更便于后續的渲染。隨后，使用RenderPass從Root EntityPass開始遍歷，把EntityPass中每個Entity轉換為Command結構，即從Shader Bindings生成GP

266、U Pipeline，把Polygon轉換為頂點數據，設置片段著色器的顏色或紋理數據，再把頂點數據和顏色或紋理數據轉換為GPU buffer設置到GPU Pipeline中。遍歷完成所有的Entity Passes后，所有Com-mand都存儲到了RenderPass中。然后，開始渲染指令編碼階段，根據MTLCommandBuffer生成MTLRenderCommandEncoder，遍歷所有的Commands，把每個Command中的PipelineState，Vertext Buffer，Fragment Buffer設置MTLRenderCom-mandEncoder中，最后。結束編碼并

267、提交command buffer。如下為Entity Passes的結構圖：Canvas#saveLayer()操作會創建子EntityPass，用于離屏渲染；常見的需要離屏渲染的操作有：alpha blending，gradient，gaussian blur和expensive clipsEntityPass包含一系列Entity，每個Entity是一個繪圖操作，對應于Canvas#drawXXX()每個Entity對應一個Contents，表示一種繪圖類型，共11種Contents每種Contents在渲染時生成對應的Command，包含了頂點數據、片段著色器數據和GPU renderi

268、ng pipeline信息1.2.3.4.13601年度精選技術棧內容終端技術篇/技術經典總結技術人的百寶黑皮書2022版大淘寶技術出品GPU繪圖過程頂點數據至關重要，需要根據繪制的形狀生成頂點數據，再生成vertext buffer object（VBO）關聯到渲染管線上，如下為impeller中對頂點的處理過程：以Rect類型為例，在生成EntityPass階段會把Rect轉換為Path結構，然后在創建Command階段利用Tessellator（曲面細分器）根據Path生成頂點數據，存儲到主存HostBuffer上，并把offset和length保存為BufferView關聯到頂點或片段

269、著色器的PSO上。在Encode Commands階段把整個HostBuffer上傳到GPU buffer，把該次繪制的Vertext/Fragment Buffer、offset和length信息設置到對應的GPU pipeline上。Impeller渲染流程13701年度精選技術棧內容終端技術篇/技術經典總結技術人的百寶黑皮書2022版大淘寶技術出品總結以上我們介紹了impeller要解決的問題、他的目標、架構和渲染細節。目前該項目的現狀如下：團隊介紹阿里跨平臺技術人才儲備豐富，獨行快，眾行遠，歡迎優秀的你加入【大淘寶技術-跨平臺技術團隊】，一起打造靠譜的跨平臺方案！這里有H5容器、Wee

270、x、Flutter、小程序、游戲互動等諸多解決方案，既有技術深度也有廣泛業務場景，歡迎優秀的小伙伴來一起搞事情，一起把技術做穩一起為業務提效，手淘跨平臺技術團隊歡迎你的加入！由此可見，flutter為了解決jank問題、提升渲染性能不惜重寫圖像渲染后端，決心可見一斑。期待impeller能使flutter的渲染性能更上一層樓。impeller離線編譯shader為shader library，可有效提升首幀性能，避免著色器編譯帶來的jank問題目前僅實現了 Metal backend，支持iOS和Mac支持了73種Ops，11種Contents代碼量 18774 行，目前仍依賴了一些Skia數

271、據結構，如SkNoDrawCanvas，SkPaint，SkRect,SkPicture等項目處于早期原型階段，一些功能還不支持，如stroke、color filter、image filter、path effect、mask filter、gradient，以及drawArc、drawPoints、drawImage、drawShadow等等。issue#95434 中記錄了進展和計劃。整體工作量較大，相當于重寫了 Skia GPU功能1.2.3.4.5.6.13801年度精選技術棧內容終端技術篇/技術經典總結技術人的百寶黑皮書2022版大淘寶技術出品HTTPS的原理淺析與本地開發實踐作

272、者：陳超（攬辰）出品：大淘寶技術日常的開發過程中本地環境保持登錄狀態是前置條件，在校園B端業務模塊的日常研發過程中，一般先通過預發環境登錄，將登錄態保存在的domain下，然后在本地通過Vite/Webpack Server+Nginx+host的方式構造自定義域名（一級域名與登錄態的domain一致），進而做下一步的開發工作。但是目前預發/生產的域名都是https協議，本地自定義的域名默認協議是http。因此，為了讀取登錄態信息，需要將本地的訪問地址也配置成https協議。實現的過程主要是在本地通過OpenSSL工具按照x509證書標準生成自簽證書，并將這個自簽證書添加到電腦的證書配置項中即

273、可（具體操作過程可以關注明天的推送）。這個配置過程引起了我對數字證書與HTTPS協議關系的好奇，因此做了下面的原理探究，下面就對這個探究的過程就一下記錄，淺析HTTPS的實現原理，并將兩種配置證書的方式的具體操作步驟做了記錄。關鍵詞加密算法、數字簽名、秘鑰交換、Wireshark、OpenSSL引言首先就需要拋出一個問題，為什么HTTP協議的網址越來越少？我們可以通過下面這個典型的HTTP數據傳輸流程看出它的問題 即數據在Client/Server之間不加識別的明文傳輸。（-http1.1-only.pcapng）13901年度精選技術棧內容終端技術篇/技術經典總結技術人的百寶黑皮書2022版

274、大淘寶技術出品明文傳輸和匿名發送對象也體現了互聯網信息不可靠的典型特性：1.篡改數據（偽造）破壞數據一致性；2.嗅探（偷窺）破壞數據的安全性；問題解法 如果想解決http的這兩個問題，我們需要如何改良它？方案一：通過對稱加密的方式傳輸數據場景一：客戶端與服務端交互，通過約定的對稱秘鑰加密傳輸數據，在前端資源加載時，仍然可以從數據中找出想要的秘鑰；場景二：客戶端/服務端交互如果臨時生成隨機秘鑰，在傳輸過程中仍然有被截獲的風險；問題：秘鑰在網絡中傳輸容易被攔截，假設秘鑰泄露，密文全會被破解且無法確定發送方是否安全；方案二：通過非對稱加密的方式傳輸數據場景：服務端產生秘鑰對，公鑰交給客戶端，私鑰自己

275、保存，不會在互聯網傳輸，安全性更高；問題：1.由于公鑰是公開的，中間人可以篡改上行或者下行內容。該方案能解決上行數據安全性（密文傳輸，無法破解）問題，但是無法解決下行數據的安全性問題（公開的公鑰可以解密服務端返回的密文）。此外，數據一致性問題 業務法保證，因為中間人可以假借公鑰加密自己的數據給服務端，可以修改上行數據，或者中間人告知客戶端的 公鑰為自己的秘鑰對，進行修改下行數據。2.非對稱加密的效率偏低，不適合用于數據傳輸；方案三：先客戶端/服務端間通過非對稱加密協商秘鑰，然后用協商的秘鑰做后續的數據傳輸場景：先客戶端/服務端雙方通過約定的某種秘鑰協商算法在客戶端計算出秘鑰K，并通過公鑰加密K

276、傳輸給服務端，服務端通過私鑰解密后，開始基于秘鑰K做數據的對稱加密傳輸。問題：1.固定的秘鑰對和網絡中傳輸的秘鑰存在被竊取的可能，安全性并不牢固；2.客戶端/服務端在數據傳輸前沒有做合法性校驗，無法避免中間人攻擊；14001年度精選技術棧內容終端技術篇/技術經典總結技術人的百寶黑皮書2022版大淘寶技術出品方案四：先在客戶端/服務端之間做認證，然后通過非對稱加密協商秘鑰，最后用協商的秘鑰做后續的數據傳輸場景：在傳輸數據前先通過鑒別通信雙方是否真實，而不是假冒的其他用戶，在身份驗證完畢后，基于某種高安全性的秘鑰協商算法，通過非對稱加密（秘鑰對隨機產生）的方式在客戶端/服務端之間協商秘鑰，雙方會基

277、于協商算法的公開數據得到相同的秘鑰，然后開啟后續的對稱加密通信。特點：1.數據傳輸前先做身份認證，基本可以解決中間人攻擊的問題，防止篡改數據；2.使用高安全性的秘鑰加密通信數據，可以有效防止數據被嗅探；結論方案四就是HTTPS解決明文傳輸兩大問題的基本思路。其中身份認證涉及數字簽名和數字證書概念，而非對稱加密設計非對稱加密體系。由于非對稱加密的計算性能不及對稱加密，所以，在經過幾輪握手，協商好秘鑰后，將數據傳輸的加密方式改為對稱加密?？偟膩碚f，HTTPS就是通過數字證書+非對稱秘鑰體系+對稱秘鑰體系的組合方案來解決HTTP協議傳輸明文的兩大問題。HTTPS141確定性：如果兩個散列值是不相同的

278、（根據同一散列函數），那么這兩個散列值的原始輸入也是不相同的；不可逆性：故意創建產生給定散列值的消息是不可行的；散列碰撞：散列函數的輸入和輸出不是唯一對應關系的，如果兩個散列值相同，兩個輸入值很可能是相同的，但也可能不同；1.2.3.01年度精選技術棧內容終端技術篇/技術經典總結技術人的百寶黑皮書2022版大淘寶技術出品HTTPS(Hypertext Transfer Protocol Secure)是基于 HTTP 的擴展，用于計算機網絡的安全通信，已經在互聯網得到廣泛應用。在 HTTPS 中，原有的 HTTP 協議會得到 TLS(Transport Layer Security-安全傳輸層

279、協議)或其前任 SSL(Secure Sockets Layer-安全套接層)的加密。因此 HTTPS 也常指 HTTP over TLS 或 HTTP over SSL。（HTTPS）理論分析方案四只對信息傳輸的場景做了簡要分析，其中有數字簽名、數字證書、加密體系這些基礎概念，為了方便在后續解析TLS/SSL握手過程，這里先對涉及的基礎技術概念做簡要的匯總介紹。散列函數 散列算法、哈希函數 定義散列函數（Hash Function）是一種從任何一種數據中創建小的數字“指紋”的方法。散列函數把消息或數據壓縮成摘要，使得數據量變小，將數據的格式固定下來（散列值）。特點MD（Message Dig

280、est）摘要算法：MD算法生成的摘要消息都是128位長（32位的十六進制數字）表示，安全性排序：MD2 MD4 哈希運算（SHA-256）=文件哈希值（摘要）=簽名運算（RSA，私鑰加密）=數字簽名；小紅擁有小明對外開發的公鑰（PS：小紅可能不知道，小明的公鑰已經被替換成中間人的公鑰），在收到小明的信息后，做簽名驗證；公鑰解密后的哈希值與待簽名的文件哈希值對比，相同，則簽名成立，否則簽名不成立。數字簽名的問題小明傳輸的數字簽名可以被另外一個具有秘鑰對的中間人替換傳輸的文件。相當于中間人模仿了小明的“簽名”。RSA加密過程通式 ，公鑰=（e,n）RSA解密過程通式 ，私鑰=（d,n）秘鑰對為(e

281、,d,n)；14501年度精選技術棧內容終端技術篇/技術經典總結技術人的百寶黑皮書2022版大淘寶技術出品這個問題出現的核心原因在于：小明的公鑰被中間人的公鑰替換了，小紅自己無法判斷當前的公鑰是否是小明的！所以，我們需要證明的是接收方拿到的公鑰是發送方提供的，而不是中間人提供的?；诋斍暗陌咐?，我們如何證明小紅接收到的公鑰就是小明發送的，而非被他人篡改的呢？這就需要有一種公開的權威的認證機制 數字證書機制。數字證書數字證書是利用非對稱秘鑰體系中，秘鑰對的公鑰和私鑰是一一對應的特性，通過權威的證書簽發機構（CA）簽發證書預制秘鑰，并將根證書預裝在操作系統中，從而防止公鑰被篡改。所以，數字證書可以

282、用來證明公鑰是屬于某個認證用戶的。證書簽發機構用自己的私鑰對需要認證的人（或組織機構）的公鑰施加數字簽名并生成證書，即證書的本質就是對公鑰施加數字簽名。證書的產生和流轉過程 14601年度精選技術棧內容終端技術篇/技術經典總結技術人的百寶黑皮書2022版大淘寶技術出品這種在數據傳輸過程中引入第三方來證明公鑰的合法性是相對安全的，因為被信任的CA根證書都會被預裝在操作系統中，這就相當于信任自己的操作系統，所以HTTPS協議在整個傳輸過程中，數據的一致性和安全性可以得到有效的保證。任何解決方案都不是銀彈，都存在弱點或者不足?；贑A證書的通信過程也不是完美無缺的，因為CA機構本身也可能存在管理上的

283、問題，進而導致偽造證書泛濫，被有心者惡意利用，或者用戶本身安全意識淡薄導致將不安全的證書安裝進操作系統，導致數據傳輸安全問題的發生。（案例：distrusting-new-cnnic-certificateshttps:/blog.mozilla.org/security/2015/04/02/distrusting-new-cnnic-certificates/）HTTP的數據交換流程下面會基于wireshark工具，對單次HTTPS協議的網站流量進行詳細的分析。HTTP和HTTPS數據交換流程對比 HTTP 數據傳輸過程簡單，雙方沒有認證過程，數據明文傳輸產生終端證書：將發送方提供的身份信

284、息和公鑰信息作為基礎數據，CA基于這些數據做哈希和數字簽名（CA的私鑰加密）操作產生數字證書；證書合法性校驗：發送方會將CA簽發的終端證書通過互聯網發送給接收方，接收方會基于CA預裝在系統內的根證書（含CA公鑰）來驗證發送方提供的整證書是否合法；1.2.14701年度精選技術棧內容終端技術篇/技術經典總結技術人的百寶黑皮書2022版大淘寶技術出品 HTTPS 數據傳輸前要做復雜的協商過程，雙方要做合法性校驗，數據密文傳輸基于DH秘鑰協商算法的信息交換流程HTTPS數據傳輸步驟分解TCP握手 建立鏈接；TLS握手或者秘鑰協商過程（基于TLS版本的不同或者緩存影響，握手次數有所差異，這里只看TLS

285、v1.2的標準流程），握手目的：驗證身份、交換信息、生成秘鑰，為后續的通信做準備，總覽圖如下：1.2.（mac-https- no ico TLS use curl.pcapng）14801年度精選技術棧內容終端技術篇/技術經典總結技術人的百寶黑皮書2022版大淘寶技術出品3.TCP揮手 斷開鏈接；TLS握手過程簡析TCP建立鏈接和斷開鏈接不是本次關注的重點，這里只對TLS握手協商秘鑰的過程做一個簡要的分析。C端代表客戶端，S端代表服務端【C端-S端】告知S端，當前C端支持的協議版本（Version）、加密通信支持套件（Cipher Suites）等信息，并產生了一個隨機數（5a882b）。第

286、二次握手 第一次握手14901年度精選技術棧內容終端技術篇/技術經典總結技術人的百寶黑皮書2022版大淘寶技術出品【S端-C端】告知C端，確定使用TLS協議版本號是1.2、生成的隨機數(524401)、產生會話ID、確定加密通信的套件為TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384。通信套件（Cipher Suite）解析：1.生成秘鑰：密鑰協商算法使用ECDHE；2.數據傳輸加密算法：握手后的通信使用 AES 對稱算法，密鑰長度 256位，分組模式是 GCM；3.身份驗證：簽名算法使用RSA；4.完整性校驗：摘要算法使用SHA384；TLS 的會話緩存機制 Ses

287、sionId（協議標準字段）和 Session Ticket（協議擴展字段），后續篇幅研究；第三次握手150【S端-C端】第一步：發送證書 Certificate：服務器向客戶端驗證身份；第二步：完成證書驗證后，開始基于ECDHE做秘鑰協商：公開橢圓曲線 Curve25519 蒙哥馬利曲線（）和曲線基點G（值為9）、S端隨機產生私鑰d1（存在本地）、通過私鑰d1和基點G生成公鑰Q1（Pubkey）。攜帶簽名算法防止篡改公鑰。常見的三種秘鑰協商過程簡析：基于RSA的秘鑰協商（依靠非對稱加密算法）SSLv2的協商機制客戶端連上服務端；服務端發送 CA 證書給客戶端；客戶端驗證該證書的合法性；客戶端

288、從 CA 證書中取出公鑰P；客戶端生成一個隨機密鑰 K，并用這個公鑰加密得到 K；客戶端把K 發送給服務端；服務端收到 K 后用自己的私鑰S解密得到 K；此時雙方都得到了密鑰 K，協商完成；雙方開始使用秘鑰K進行加密通信；01年度精選技術棧內容終端技術篇/技術經典總結技術人的百寶黑皮書2022版大淘寶技術出品151RSA的協商方式存在的問題是，加密數據在C和S端傳輸，如果S端的私鑰泄密，則會導致加密傳輸的數據都會被破解，是否有更好的方式，能讓對稱加密的秘鑰不在網絡間傳輸，而是由雙方通過統一的規則來在各自的環境內計算得到？這就是需要用到下面的DH算法來優化當前這個傳輸的過程?；贒H的秘鑰協商（

289、依靠秘鑰交換算法）客戶端先連上服務端；服務端生成一個隨機數 s 作為自己的私鑰，然后根據算法參數計算出公鑰 S（算法參數通常是固定的）；服務端使用某種簽名算法把“算法參數（模數P，基數G）和服務端公鑰S”作為一個整體進行簽名；服務端把“算法參數（模數P，基數G）、服務端公鑰S、簽名”發送給客戶端；客戶端收到后驗證簽名是否有效；客戶端生成一個隨機數 c 作為自己的私鑰，然后根據算法參數計算出公鑰 C；客戶端把 C 發送給服務端；客戶端和服務端（根據上述 DH 算法）各自計算出 K 作為會話密鑰；01年度精選技術棧內容終端技術篇/技術經典總結技術人的百寶黑皮書2022版大淘寶技術出品152DH協商

290、秘鑰協商算法計算性能不佳，因為協商過程中雙方都需要做大量的乘法運算，為了提升 DHE算法的性能，所以就出現了現在廣泛用于密鑰交換算法 ECDHE算法?；贓CDHE的秘鑰協商ECDHE 算法是在 DHE 算法的基礎上利用了 ECC 橢圓曲線特性，可以用更少的計算量計算出公鑰，以及最終的會話密鑰。小紅和小明使用 ECDHE 密鑰交換算法的過程：這個過程中，雙方的私鑰都是隨機、臨時生成的，都是不公開的，即使根據公開的信息（橢圓曲線、公鑰、基點 G）也是很難計算出橢圓曲線上的離散對數（私鑰）。第三步：Server Hello done，S端已經完成向C端的消息發送；01年度精選技術棧內容終端技術篇/

291、技術經典總結技術人的百寶黑皮書2022版大淘寶技術出品雙方事先確定好使用的橢圓曲線類型以及曲線上的基點 G，這兩個參數都是公開的，一般采用密碼學中比較著名的橢圓曲線函數，例如本次會話用到的Curve25519曲線；雙方各自隨機生成一個隨機數作為私鑰d，并與基點 G相乘得到公鑰Q（Q=dG），此時小紅的公私鑰為 Q1 和 d1，小明的公私鑰為 Q2 和 d2；雙方交換各自的公鑰Q1和Q2；通過橢圓曲線特性計算得到相同的x坐標作為協商秘鑰K，過程如下：小紅計算點小明計算點基于橢圓曲線的特性 d1Q2=d1d2G=d2d1G=d2Q1，因此雙方的 x 坐標 是相等的，所以它是共享密鑰，也就是會話密鑰

292、。（詳細的數學原理：https:/ 第四次握手 第五次握手【C端-S端】【S端-C端】1.確認改用對稱加密算法加密后續的通信數據；2.使用同樣的方式傳輸加密后的數據并交給客戶端驗證。TLS 經過五次握手協商并得到加密秘鑰后，雙方就開始基于對稱加密的方式對傳輸數據，這樣能很好的提高數據傳輸的效率?？蛻舳嗽诒镜仉S機生成一個私鑰d2，通過私鑰d2和基點G生成公鑰Q2（Pubkey）。此時，雙方都有對方的橢圓曲線公鑰、自己的橢圓曲線私鑰、橢圓曲線基點 G。于是，雙方都就計算出點（x，y），其中 x 坐標值雙方都是一樣的。x直接作為對稱加密的秘鑰使用安全性低，雙方為了會提高秘鑰的安全性，會在x上“加鹽”

293、處理，即使用先前會話產生的隨機數組合產生秘鑰 【5a882b+524401+x】。秘鑰協商完畢，告知S端后續通信數據改用對稱算法加密；對數據做摘要算法，使用秘鑰加密，交給服務端驗證；1.2.3.15401年度精選技術棧內容終端技術篇/技術經典總結技術人的百寶黑皮書2022版大淘寶技術出品數據傳輸（加密）通信雙方使用“加鹽”后的秘鑰加密數據，并在網絡間傳輸。如果傳輸中獲取到秘鑰協商時產生的秘鑰，則可以解密已經加密的 Application Data，例如，TLSv1.3 的加密數據被wireshark解密。（https-no ico-WITH FIN TCP.pcapng）小結文章的最開始就提出

294、了HTTP協議在目前網絡傳輸中存在的問題，然后基于兩個典型問題做了合理的方案設想，最終推演出的第四種方案是更趨近于兩個問題的實際解決方案的。在提出方案后，開始對其中涉及到的哈希函數、數據加密、數字簽名等書面概念做了簡單的總結，目的是為后續HTTPS的實際秘鑰協商過程和數據傳輸過程做了鋪墊。隨后，基于wireshark工具，攔截一次HTTPS請求流量，對TLS（1.2版本）的秘鑰協商過程（握手過程）做了相對細致的分析，期間也對先前TLS版本使用的秘鑰協商過程做了簡要的介紹，希望能夠幫助你在理解HTTPS協議概念上能有所幫助。下一篇文章屬于實戰部分，將重點介紹HTTPS證書的配置過程，我將會以阿里

295、云證書配置和OpenSSL自簽證書配置兩種方式來讓你的網站從HTTP轉換到HTTPS。15501年度精選技術棧內容終端技術篇/技術經典總結技術人的百寶黑皮書2022版大淘寶技術出品概念匯總以上我們介紹了impeller要解決的問題、他的目標、架構和渲染細節。目前該項目的現狀如下：名稱解釋概念傳輸層安全協議/安全套階層-TLS（Transport Layer Security）/SSL（Secure Sockets Layer）openssl是一個功能豐富且自包含的開源安全工具箱它提供的主要功能有：SSL協議實現(包括SSLv2、SSLv3和TLSv1)、大量軟算法(對稱/非對稱/摘要)、大數運

296、算、非對稱算法密鑰生成、ASN.1編解碼庫、證書請求(PKCS10)編解碼、數字證書編解碼、CRL編解碼、OCSP協議、數字證書驗證、PKCS7標準實現和PKCS12個人數字證書格式實現等功能。OpenSSL Cryptography and SSL/TLS Toolkit信息摘要也稱特征值，它是將一段很長的數據信息，通過hash函數（MD5 或 sha 1等）計算，得到一串長度“較短”且“定長”的短數值，來作為這段數據獨一無二的特征值。該過程不可逆。Message Digest數字簽名使用用戶的私鑰(private key)對信息摘要進行加密，生成的信息。私鑰+信息摘要=數字簽名。Digit

297、al Signature數字證書由某個被信任的機構（CA）簽發、認證用戶身份的數字文件。CA私鑰+認證用戶的基礎信息+認證用戶的公鑰=數字證書Digital Certificate證書經權威授權機構數字簽名，包含公開密鑰的擁有者信息以及公開密鑰的文件，是權威機構頒發給網站的可信憑證。最簡單的證書包含一個公開密鑰、證書名稱以及證書授權中心的數字簽名。CRT常見于Linux系統，內容常用PEM，也有DER編碼，CER常見于Windows系統，內容常用DER編碼，也有PEM編碼。CRT/CER（Certificate）證書標準定義證書中需要包含的內容 https:/www.ietf.org/rf-c

298、/rfc5280.txtX.509X.509證書的編碼格式文本格式,以-BEGIN.開頭,-END.結尾,內容是BASE64編碼。PEM轉為DER：openssl x509-in cert.crt-outform der-out cert.derPEM（Privacy Enhanced Mail）X.509證書的編碼格式二進制格式,不可讀。DER轉為PEM：openssl x509-in cert.crt-inform der-outform pem-out cert.pemCER（Distinguished Encoding Rules）數字證書頒發機構/證書授權中心CA認證中心作為電子商務

299、交易中受信任的第三方，承擔公鑰體系中公鑰合法性檢驗的責任。CA（Certificate Authority）證書簽名請求它包含了您的服務器信息和公司信息。申請證書時需要將您證書的CSR文件提交給CA認證中心審核，CA中心對CSR文件進行根證書私鑰簽名后會生成證書公鑰文件（即簽發給您的SSL證書）CSR（Certificate Signing Request）存放私鑰或者公鑰的文件-KEY-可以使用一個數字證書綁定多個通用名稱（即使互不相關的名稱）。參加上面的手動創建CSRSAN（Subject Alternative Names）15601年度精選技術棧內容終端技術篇/技術經典總結技術人的百寶

300、黑皮書2022版大淘寶技術出品參考資料 1.https:/ 數據結構根據場景定義。因此，要定義出場景，收斂并標準化沉淀。首先場景是基于中后臺常見的產品模式和功能板塊拆解，對交互形式、接口數據結構進行標準化收斂后，提取出的功能高度收斂的場景物料和場景控件。從技術上定義來看：按UI體系原子化設計的粒度劃分，場景物料屬于模版粒度，比如，基礎查詢場景包含篩選表單、操作區、展示表格、翻頁器，是頁面內的大區塊；場景控件屬于組件和模塊的粒度，比如員工選擇器、日期展示組件等。從能力上看場景物料和場景控件具有業務屬性，內置了業務相關邏輯和API數據請求，比如：Fusion Table 是純 UI 組件，AntD

301、 ProTable 封裝了翻頁、篩選等預設邏輯，查詢場景物料還額外封裝了接口請求處理，標準了場景所需要的接口及其數據格式即場景模型。1.2.16001年度精選技術棧內容終端技術篇/技術經典總結技術人的百寶黑皮書2022版大淘寶技術出品場景內置核心功能，并預留一些擴展能力，通過場景控件擴展場景中輸入/展示/操作等 UI 組件，通過能力插件擴展條件渲染、聯動執行等非 UI 型能力。場景與控件正交組合，再結合能力插件，就構成頁面區塊的完整功能，多個區塊布局組合就構成完整頁面。圍繞上述核心邏輯，我們構建了完整的場景標準化體系：制定場景規范：成立場景規范小組，結合業務場景訴求，制定各場景統一的交互樣式和

302、接口數據規范。建立場景沉淀機制：對于與現有場景完全不同的新場景，先按業務訴求梳理場景案例，對功能抽象分類，再經由場景規范小組評審，設計出符合規范的場景，最后開發并沉淀場景。對于與現有場景相似但有定制化訴求的，拆解出要擴充/定制的能力，同樣經過小組評審后，在現有場景上進行迭代。構建場景生態體系：圍繞整個大淘寶中后臺域，構建整體場景標準及多業務域協同機制，統一管控及沉淀標準場景。并提供自定義物料研發套件及接入能力，以支撐更大范圍業務場景。1.2.3.16101年度精選技術棧內容終端技術篇/技術經典總結技術人的百寶黑皮書2022版大淘寶技術出品數據標準化核心為模型定義，數據模型生產及數據實體生產三個

303、環節，將基于場景標準化產出的場景物料對應的API及其所需字段通過場景化搭建配置組合業務模型中的字段生成具體所需API及字段，后端根據API需求提供并綁定API實體完成頁面所需API的標準化生產。模型定義，基于現有頁面API結構的拆解，主要有這幾部分：模型或者說標準的定義并不一定是定義本身多先進，而是大家認可并且能夠遵循。因此在整個工作臺維度我們成立了覆蓋全域產品后端的規范小組，通過整體Review，RFC機制保障模型的標準及有效，通過每個團隊的接口人推進規范落實及收集反饋持續優化。數據模型生產：有了上述三個模型，就可以在使用平臺研發時，通過選擇業務模型字段并關聯到場景配置中，進而推導出頁面所需

304、的接口定義（入參和返回值的字段結構）。技術上類似模版引擎，場景模型是模版，將業務模型字段填充到模版中的占位符，最后再套上網關模型的固定結構，就是期望的 API 數據模型。網關模型：描述工作臺網關封裝的數據結構，包含接口成功失敗標識、錯誤信息、網關額外的調試信息等。網關模型固定，對工作臺所有接口都有相同的結構。場景模型：描述具體場景涉及的所有接口的結構，包括場景內固定的入參、返回值字段，以及如何通過場景配置引入的業務模型字段。業務模型：描述實際業務中的概念、涉及對象及其屬性，包括字段、類型、含義等。同一個業務模型可以用于多個產品頁面。1.2.3.數據標準化16201年度精選技術棧內容終端技術篇/

305、技術經典總結技術人的百寶黑皮書2022版大淘寶技術出品數據實體生產：后端按照推導出的 API 接口定義來標準化實現接口，同時我們也基于場景標準構建了通用的Java類，比如分頁列表類、級聯查詢類等，配合一些工具函數，將 DO/DTO 快速轉化成 VO，降低接口表現層的研發成本。大部分情況下比如新業務后端都相對能夠較好的按照所產出的結構提供數據，但是針對一些存量接口，二方服務依賴較多的接口等情況后端改造及適配成本相對較高，我們也提供了字段組合映射能力及服務編排能力，以更低成本將非標接口快速轉化成推導出的 API。無代碼頁面生產無代碼核心目的是通過場景標準沉淀的場景物料及數據規范完全無代碼生產完整功

306、能頁面并驅動頁面所需API數據結構的生成，以解決現有研發效能低，體驗&質量難保障及前后端聯調等協同問題。頁面由UI、交互、數據構成，場景標準化和數據標準化保證了研發資產（場景和模型）是收斂的，已經有了 UI/交互/數據的結構化的大框架，只需要少量的研發工作就完成頁面研發，而對于簡單的結構化的頁面研發，高效的方式就是可視化配置。從場景的角度出發，剩余的研發工作主要有場景配置、多個場景布局和聯動、一些全局數據的貢獻等，都可以收斂并抽象成可視化配置。全流程無代碼可視化配置能降低非前端上手門檻，進一步提高交付質量和研發效率。與低代碼的差異？相較通用低代碼研發平臺，我們基于標準場景搭建將非UI部分的交互

307、邏輯和數據對接等也進行了抽象和更深層次的能力封裝，去除手寫代碼的負擔，使得全流程無代碼研發成為可能。16301年度精選技術棧內容終端技術篇/技術經典總結技術人的百寶黑皮書2022版大淘寶技術出品One more thing-中后臺研發效能度量年年效能持續提升但是還是沒變化？效率是中后臺研發的核心目標之一，目前業界和集團內缺少兼具普遍性和實操性的效能度量方案。因此，有必要建立通用可行的中后臺要能衡量對比中后臺源碼/低代碼/無代碼三種研發模式，覆蓋研發及聯調完整生產環節的效能度量模型及方案。以數據化方式度量項目、個人、團隊的研發效能并指導未來效能提升的方向?，F在方案的問題&策略核心方案標準協議：以

308、集團低代碼協議和 OneAPI 2.0 協議為基礎，補充場景模型、業務模型、網關模型、聯動布局等協議，構成完整的無代碼協議，同時支撐研發配置和運行渲染。研發資產：場景中心輸入場景和場景控件，模型中心輸入網關/場景/業務模型，共同作為標準的研發資產。研發配置：頁面研發可以分為UI/交互/數據三個方面，從UI入手對單個場景進行配置，包括條件渲染、參數傳遞、全局篩選等功能配置，對多個場景組合布局，交互上配置場景間的聯動關系，數據上將API推導的接口定義綁定到后端實現，就完成完整頁面研發。結合實時預覽和接口mock可以一邊配置一邊快速查看效果。構建發布：配置信息整合加工后，產出頁面schema和API

309、數據模型，然后提取組件依賴，結合腳手架生成代碼并更新倉庫，最后構建發布到CDN。除了常規的頁面應用，也支持將頁面構建發布成微模塊。運行渲染：使用集團低代碼渲染引擎解析頁面schema，渲染布局、場景和場景控件，使用聯動流程調度引擎處理整個頁面的聯動邏輯，接口請求則由場景自行發起和處理。1.2.3.4.5.效能度量方案僅停留在代碼復雜度層面，采用霍爾斯特德復雜度來度量，無法衡量項目變更的復雜度變化，無法解決中后臺源碼/低代碼/無代碼三種研發模式的效能對比。創新性地設計歸一化最小作用域復雜度模型，解決變更和不同研發模式統一度量問題。大部分度量方案沒有針對研發全鏈路更細致的度量指標。中后臺效能度量方

310、案從微觀和宏觀的研發、聯調時長出發，結合研發流程，計算過程指標和結果效能指標，并提供效率提升的分析依據和量化基準。1.2.定義效能指標及計算公式：分析拆解效能的度量指標，建立效能指標計算公式。研發效能=歸一化復雜度/研發總耗時=(最小作用域差量復雜度/研發模式標準頁面復雜度)/(連續研發工時+連續聯調工時)。構建復雜度度量模型：改進霍爾斯特德復雜度算法，引入代碼Diff、依賴分析、AST分析，搜尋差量代碼的最小作用域，計算變更引入的復雜度，解決目前業內霍爾斯特德復雜度無法評估變更效能。1.2.16401年度精選技術棧內容終端技術篇/技術經典總結技術人的百寶黑皮書2022版大淘寶技術出品總結一點

311、感悟 關于低代碼/無代碼由于近年來各種LCDP/Low-Code概念太熱各種方案及平臺層出不窮，導致不少偏執的認識。部分人粗暴的把所有研發內容可視化，比如一些僅僅是把寫代碼的過程轉化為可視化過程的產品，針對某些人群在某種程度上是降低了門檻，但在真實生產中效果有限定位尷尬。另外一種聲音是完全否定，只要是聽到相關名詞就覺得是重復的，或者說覺得做不到、效果一定不好。很多過程的配置化、可視化確實不適合就如前面的描述。但是無法否認的是可視化方式更直觀、約束更強、門檻更低，核心考量在于具體的場景，研發環節及內容抽象度及合理性，能否標準化，配置是否足夠友好，目標用戶及所解的命題。構建連續時長度量模型：預處理

312、源碼/低代碼/無代碼研發和聯調操作的打點數據，按時間進行閾值分隔，動態構建活躍會話窗口，計算連續研發時長和連續聯調時長。標準頁面歸一化：對不同研發模式的頁面分層采樣，統計場景頻次和占比，構建標準頁面，用于歸一化項目復雜度，解決不同研發模式語法信噪比不同導致的復雜度比較問題。完整度量計算鏈路：歸攏中后臺三種研發模式，設計度量采集、數據加工、指標匯總的完整鏈路，為提供效率提升的量化基準和分析方向3.4.5.16501年度精選技術棧內容終端技術篇/技術經典總結技術人的百寶黑皮書2022版大淘寶技術出品 關于新工具學習使用成本及收益對于解決問題的新工具如何考量自身學習和使用的投入產出，主要三個方面：權

313、衡取舍，成本、邊際量。直白說如果需要獲得的是編程技能，那用這類研發工具那是不適合的。如果你有大量的頁面生產工作，并且期望高效的完成，那投入成本學習是有價值的。所以很多時候要客觀理解具體的使用情況及反饋（當然是在工具真的能解決問題的前提下）。關于研發生產我們大部分時間開發其實本質就是在做某種邏輯的轉換，而不是做什么設計，如何將人肉繁雜的處理過程、協同過程轉為更高維度的抽象，各角色圍統一模型有機協同生產，帶來整體提效是需要持續探索的。而不是單一的構建一個工具、能力粗暴轉移工作量，僅僅解決一個角色自身問題為出發點。一些結果完成無代碼平臺初步建設，實現多角色協同生產，縮減非必要的轉譯環節，提高頁面生產

314、效能。定義場景標準，沉淀25個標準場景，場景業務覆蓋率達到96%；沉淀39個場景數據及81個業務數據規范。構建統一的中后臺研發效能度量方案Orca-Efficiency能夠度量完整頁面研發及聯調過程，可度量及對比ProCode、LowCode、NoCode三種研發模式。平臺全年支撐200+需求/項目迭代，覆蓋大淘寶商家、商品、營銷、智能人群運營全業務產品整體新需求覆蓋率79%，并支撐直播域，X業務等10+產品構建。根據統一效能度量無代碼模式效能相較源碼提升5倍，低代碼提升1倍，完整協同及生產提效68.6%。并且通過標準場景及無代碼方式有效保障產品體驗&研發質量。16601年度精選技術棧內容終端

315、技術篇/技術經典總結技術人的百寶黑皮書2022版大淘寶技術出品HTTP3 RFC標準正式發布，QUIC會成為傳輸技術的新一代顛覆者嗎？作者：XQUIC項目組出品：大淘寶技術6月7日早晨(UTC時間Mon,06 June 2022 20:09)，HTTP/3 標準RFC9114 由IETF標準化工作組正式發布，由此QUIC第一代協議族6大基礎標準（不變量/傳輸框架/擁塞控制和恢復/TLS/HTTP3/QPACK壓縮）全部完成RFC化，開啟一段新的網絡時代。在淘寶，我們從18年開始嘗試QUIC，到2122年實現IETF QUIC及HTTP3標準的規?；瘧?，針對導購和交易核心鏈路場景拿到1520%

316、的網絡耗時優化收益，同時沉淀自研的標準協議庫實現XQUIC，并于年初開源。筆者想借由本文談一談對于網絡7層模型中傳輸層的發展方向看法，以及對于底層技術發展過程中可能碰到的困難及問題提出一點可行的建議。開源倉庫：https:/ 可靠傳輸 與 非可靠/半可靠場景的傳輸能力設計，包括0-RTT降低握手延遲這些基礎的協議特性帶來的優勢，就不再多說。談談自研、標準與開源對于任何一項好用的技術來說，能夠先應用起來并且服務好業務需求，永遠是第一步。對于任何具備深度和一定壁壘的技術（碰巧網絡也屬于），一般我們都會經歷4個發展階段：筆者個人的觀點是，每個階段都需要投入不同的精力，對應著領域的持續深挖和人才的長期

317、培養與團隊建設。選擇走到哪個階段，沒有絕對的好與壞，而是應該根據實際的訴求、可持續投入情況 和 發展的觀點來判斷。另一方面，作為一個技術人，我們也應當充分尊重技術本身的深度，尊重愿意為了走到第三/四階段，而投入精力、克服重重困難的技術產品和團隊，而非通過一些短期包裝和走捷徑的方式，避免最終在技術上逐漸空心化，影響技術大環境的發展。如何維護技術環境的一片凈土，使得健康的種子能夠具備萌芽的條件，這也是技術管理者需要考慮和反思的。如何應用QUIC/HTTP3來提升傳輸性能表現這次IETF發布的RFC9114和9204分別描述的是HTTP/3.0和配套的Header壓縮算法QPACK的協議機制。HTT

318、P/3.0相對于HTTP/2到底有什么本質提升？這需要從HTTP/3底層的QUIC傳輸機制講起。第一階段，用好這項技術，首先能用好并切實在業務場景下拿到收益。在當前這個鼓勵開源的時代，第一步通過這個領域下已有的開源方案，來驗證技術的可行性，并拿到一些初步收益來驗證判斷和觀點，是最快的方式。第二階段，原理理解透徹，能夠充分理解透徹這項技術的底層原理和機制，并針對業務需求做出調整。在這個階段往往大家會有兩條分叉路徑：在已有開源項目上繼續修改并發展自己的分支；或者 籌備自研。在這個階段是選擇前者還是后者，核心依據有2個：一方面是 是對這項技術長期發展所能帶來的紅利，是否可以cover前期的投入；另一

319、方面是，是否具備自研能力。第三階段，具備自研能力，如果從2到3的判斷能夠滿足自研的前提，就會走上自研道路。因此我們可以看到絕大部分一線互聯網大廠，都會對戰略性的技術投入方向進行自研，同樣自研也能夠帶來技術壁壘的積累。這一步也是第四階段的前置門檻。第四階段，引領前沿發展，這個階段往往又存在兩種類型（或兩者兼有）：通過開源逐步成為事實標準，或者是參與到行業標準的制定當中。16801年度精選技術棧內容終端技術篇/技術經典總結技術人的百寶黑皮書2022版大淘寶技術出品我們都知道，QUIC基于UDP之上的多流（Stream）傳輸，實現解決原來TCP大管道下的Head-of-Line問題3，同時0-RTT

320、等握手機制可以保證連接會話的快速建立和首包的加速。QUIC提供了兩種傳輸模式，基于Steam的可靠傳輸，和基于Datagram的非可靠傳輸?；赟tream的模式下，發送方和接收方基于Steam的Offset進行流數據的重排和有序還原，并確保投遞給應用層的是有序可靠數據?；贒atagram的模式則適用于實時流媒體類型的場景，針對延遲有強訴求的同時不要求數據完全可靠有序的這類場景，Datagram提供了一種數據封裝和ACK通知的方式，幫助半可靠訴求的場景實現數據的快速投遞，并向應用層反饋送達情況。3 TCP Head-of-line頭部阻塞問題：原因是TCP是一條大的傳輸管道，基于TCP傳輸的

321、數據，由于TCP的傳輸機制，需要等待前面的數據包完成送達，后續的數據包才能被完成送達和向應用層投遞。這在多路復用的場景下，會導致不同的流數據之間互相block，這在HTTP/2是一個沒有被完全解決的問題。QUIC在丟包檢測和重傳機制方面也有較大革新。在丟包檢測方面，QUIC提供了兩大類丟包檢測方式，基于packet number的閾值檢測，和基于定時器的超時丟包檢測。這兩類機制相對于傳統的TCP檢測方式可以帶來更快的丟包感知和恢復。在重傳恢復方面，QUIC針對每一個packet分配獨立的packet number，避免了過去TCP因重傳包和原始包復用相同的sequence，導致的RTT測量不準

322、確的問題。準確測量的RTT，作為擁塞控制算法的一維重要輸入，能夠使得算法對瓶頸段擁塞狀況的檢測更加準確。這次發布的HTTP3 RFC，則是在QUIC基礎之上，描述了HTTP請求如何通過跟QUIC steam的映射，實現完整的HTTP語義，以及針對基于UDP的多流機制設計的專用頭部壓縮。因此所有QUIC在UDP之上實現的傳輸機制革新，HTTP3都可以享受到紅利。那么如何把這項革新的技術用起來呢？XQUIC針對QUIC和HTTP/3協議棧提供了完整的能力實現，并且完全符合IETF標準，并通過了IETF工作組的互通性驗證4。在手機淘寶我們提供了整套的網絡解決方案，包含客戶端的SDK和服務端網關的能力

323、支持，各類業務場景核心關注開關和放量情況即可。對于外部開發者，可以移步到XQUIC在github的開源倉庫5，開源倉庫有相對完整的文檔說明和RFC譯文，同時后續開源版本我們也將逐步更16901年度精選技術棧內容終端技術篇/技術經典總結技術人的百寶黑皮書2022版大淘寶技術出品新IETF工作組版本的Multipath8多路傳輸能力，以及Tengine相關的適配版本和模塊，方便外部開發者能夠更方便地使用。如何解決服務端UDP性能問題相信已經在嘗試應用QUIC/HTTP3的服務端開發者，或多或少都會經歷UDP在內核方面的性能瓶頸問題，考慮到UDP是在近幾年才隨著QUIC和流媒體傳輸的場景的逐漸流行，

324、才被逐漸廣泛地應用起來，因此內核UDP在性能方面很難與優化了三十年的TCP相抗衡，同時內核的復雜性和通用性要求，也導致一些新的高性能修改難以被迅速接收。因此，在UDP性能優化方面，我們和龍蜥社區的Anolis內核團隊聯合做了一版bypass內核的用戶態高性能udp收發方案。17001年度精選技術棧內容終端技術篇/技術經典總結技術人的百寶黑皮書2022版大淘寶技術出品首先我們需要了解到，ebpf6有一類專門用于網卡驅動處理的filter叫XDP7，可以實現對于網卡接收和發送的packet進行劫持處理；Anolis內核團隊基于XDP實現了一套UDP packet卸載和封裝邏輯并封裝為XUDP8庫，

325、而我們則基于XUDP進行UDP packet的收取和發送，實現完全bypass內核的高性能UDP收發。這一套方案相較于Linux內核默認的UDP收發+四元組hash查找優化的方案，可以在真實場景下，再提升26.3%以上的服務器協議棧處理性能。Tengine+XUDP+XQUIC的打包處理方案，我們后續也會在Tengine社區提供開源版本以供外部開發者參考。寫在最后希望大家都能在自己的領域，享受技術前進的快樂。17101年度精選技術棧內容終端技術篇/技術經典總結技術人的百寶黑皮書2022版大淘寶技術出品參考文獻1 HTTP3:https:/datatracker.ietf.org/doc/rfc

326、9114/2 QPACK:https:/datatracker.ietf.org/doc/rfc9204/4 互通性驗證：https:/interop.seemann.io/5 XQUIC開源倉庫：https:/ XDP:https:/dl.acm.org/doi/pdf/10.1145/3281411.32814437 XUDP:https:/ Multipath Extension for QUIC:https:/datatracker.ietf.org/doc/draft-ietf-quic-multipath/團隊介紹XQUIC團隊隸屬于大淘寶平臺技術-終端體驗平臺團隊，希望能通過網絡

327、技術演進給用戶帶來更絲滑的體驗。如果對XQUIC、網絡技術、高性能網絡傳輸等領域比較感興趣，歡迎點擊“閱讀原文”關注我們的 GitHub 倉庫：https:/ 業務發展目標作為業務團隊，以業務先贏為目標，以技術突破為手段，賦能購物車業務高效發展應當是我們的核心目標，那么購物車這個場景的業務發展目標又是什么？其實業務如何發展，首先要思考的是，這個域場景以及作為該場景的平臺方面對的角色都有哪些？這些角色目前對應的痛點與訴求是什么？對于購物車業務發展，總的來說當下面對三種角色：消費者、商家與平臺、業務方。因此，面對購物車域的這些產品痛點與訴求，我們將購物車的業務發展目標總結為三個方向：方向一：體驗購

328、物車產品的使用體驗體現在哪些方面？作為一個下單鏈路的基礎產品，購物車管理的“物”為商品、首先面對的“角色”是消費者，那么我們思考人與商品的關系，在整個產品使用中，人（即消費者）對物（即購物車商品）存在以下行動動線：存儲、瀏覽、管理、決策、結算。那么在以上幾個環節中消費者操作是否高效則定義為購物車產品良好的使用體驗?！鞠M者角色】：即需要使用淘寶購物車來完成購買過程的用戶；對于消費者來說，購物車產品基礎功能使用體驗差、購買決策效率低是最大的痛點；【商家與平臺角色】：購物車作為用戶私域，給商家營銷、運營提供較小的空間，對于如何促轉化、提高用戶購買意愿，從而獲得增量是該類角色面臨的最大痛點；【業務方

329、】：業務玩法愈的發復雜，導致業務邏輯也變的復雜，嚴重阻礙研發效率及業務發展迭代；1.2.3.17701年度精選技術棧內容終端技術篇/相關業務實踐技術人的百寶黑皮書2022版大淘寶技術出品方向二：轉化購物車作為一個基礎產品，是否具備轉化的空間？是否能為商家自運營營銷提供可能，并最終給平臺帶來增量？這是我們在購物車業務發展中思考和數據挖掘的方向。數據分析與挖掘帶給我們的結論：淘寶購物車中存在大量用戶加購但沒有被轉化的存量商品，這些存量商品轉化率隨著加購時間越久，轉化率越低，加購前兩個小時成交占比60%左右。因此購物車實際上有巨大的空間去獲得新的增量；如何增強貨品的吸引力以及重新喚醒用戶需求是購物車

330、轉化提升的兩個方向，除此之外實際上從21年我們逐步開始尋找購物車外場景的增量，結合算法手段精準推薦讓用戶買的更多、更劃算；方向三：效率無論是體驗還是轉化，業務的發展離不開快速的試錯與迭代，最終離不開高效的研發效率。而研發效率又面對惡劣的業務現狀和開發環境：業務上多端多平臺，需求繁多復雜；開發上，需求響應慢、溝通協調多，重度依賴客戶端發版。以上幾點都嚴重阻礙業務迭代速度。需要依靠技術改造來改變研發模式，提高研發效率；業務發展策略基于購物車業務發展的三個方向，我們拆解為兩個主要的實施策略：消費者側產品升級&研發提效?！静呗砸弧肯M者側產品升級：購物車產品升級主要體現在兩個方面：（1）基于購物車的工

331、具屬性進行體驗優化；（2）基于購物車的場景特征促轉化得增量；【策略二】研發提效：購物車研發效率的提升體現在兩個方面：（1）技術的改造提升研發效率；（2）業務的閉環提升業務迭代的效率；最后，我以我的理解將近兩年購物車的發展（業務+開發提效）總結為一張大圖（其中部分內容后面章節會詳細介紹）：17801年度精選技術棧內容終端技術篇/相關業務實踐技術人的百寶黑皮書2022版大淘寶技術出品當我們在說購物車體驗時我們在說什么作為一個基礎工具產品，無論KPI導向是GMV還是體驗，我始終認為提升用戶在日常以及大促的使用體驗才是產品升級的核心，那么，當我們在說購物車體驗時我們在說什么？我們又做了什么呢？淘寶購物

332、車產品使用現狀既然要提升用戶的體驗，那第一步需要了解用戶的訴求與痛點，以21年初一份手淘購物車體驗調研報告為例，從購物車使用人群分布、使用場景、使用痛點三個方面來看：17901年度精選技術棧內容終端技術篇/相關業務實踐技術人的百寶黑皮書2022版大淘寶技術出品當我們在說購物車體驗時我們在說什么購物車是一個提供商品管理、湊單合并結算能力的基礎工具，圍繞兩個核心：人和商品，人與商品的關系總結為兩個，即人對商品的管理以及人對商品的購買結算。那么購物車產品使用體驗也圍繞這兩個點展開。整體如下圖所示：【人群分布】：高購買力人群是購物車的主要使用群體；【使用場景】:（21年初統計的數據）：除收藏商品、購物

333、車結算等基礎功能外，用戶使用購物車的主要場景依次為為湊單、對比商品價格，對比商品屬性?？梢钥闯鲇脩魧徫镘囀褂迷V求主要總結為：商品管理與發現、算價與下單、湊單；【使用痛點】：（21年初統計的數據）：總結下來，用戶對購物車的使用痛點來自于幾個方面：（1）大促期間跨店湊單效率低；（2）價格體驗：包括預熱期無法透出大促價、動態計算結果與下單不能完全一致等；（3）購物車商品的快速發現：查找、分類篩選等；1.2.3.18001年度精選技術棧內容終端技術篇/相關業務實踐技術人的百寶黑皮書2022版大淘寶技術出品商品管理即用戶按照當下購買意愿強烈程度對商品進行查找、增刪改查等。影響用戶進行商品管理體驗的因素包括：（1）購物車容量問題導致的加購卡點；（2）商品查找與發現的效率；（3）商品管理即各種增刪改查的操作路線是否簡單高效；商品購買即用戶在購物車不斷選擇商品、算價、湊單、再算價最終完成下單結算的購買