盧偉冰長文解析K60至尊版 對Redmi有著里程碑式的意義
在今天的Redmi后性能時代戰略發布會結束之后，Redmi總經理盧偉冰又帶來了一篇長文，詳解了為什么 Redmi 要開啟后性能時代？為什么選擇和 MediaTek、Pixelworks 深度合作？以及后性
作者簡介
佳璐，攜程研發總監，專注大前端核心價值的構建和創新。
參照Apple、Booking和AirBnB等一眾品牌在國際化的進程中始終保持品牌認知的一致性，Ctrip和Trip（以下簡稱為“C&T”）并駕齊驅的過程中，集團對于不同國度和不同客群的品牌效應有趨于統一的訴求。
研發的整體鏈路上同樣存在由于C&T相似需求導致的重復開發工作量，服務鏈路上并沒有完全做到抽象與統一，前端鏈路上存在復用率低以及缺失動態化能力的情況。
多終端存在功能不對齊的情況，造成用戶體驗不一致，結合C&T的場景進一步加劇了功能模塊復用率低以及研發資源利用率低的問題。
綜上三點，C&T一致與多端融合的問題等待技術給出答案。
分析階段我們從品牌一致和多端一致兩個方面去探索技術可行性。
2.1 品牌一致
品牌一致性的源頭在于設計規范一致和功能實現一致。
設計規范一致：
功能實現一致：
在不解決品牌一致性的情況下，UED、產品和研發都需要付出雙倍或雙倍以上的工作量才能為兩個平臺的用戶提供服務。
2.2 多端一致
C&T和多終端在鏈路上幾乎都保持相對獨立的態勢。
目前多端不一致的現狀，從研發角度去分析體現在三個方面：
1）多終端隸屬于不同的研發團隊，研發資源的分配往往隨著訂單量的差異有所傾向。這種背景下會衍生出兩類問題：
2）各終端間的“代差”需要Controller層的服務做更多的兼容，隨著兼容代碼的增多，Controller按不同的終端訴求分裂成了一對一的架構形態，且公用的代碼部分也日益減少，進一步加劇了多端不一致的情況。
3）Controller層是由服務端開發負責，在多個Controller服務實例的場景下，由于“代差”的緣故，代碼的冗余（Controller層）與抽像邏輯的費力程度使得服務端的研發資源也成為了資源瓶頸。同時前后端代碼的分界線也缺少約束，加劇了多端整個鏈路的差異化和不一致性。
3.1 品牌一致
3.1.1 設計規范一致
UED的設計風格分別屬于 TDS（Trip Design System）與 CDS（Ctrip Design System）兩個不同的設計體系，在諸多設計元素的運用上存在差異。
逐步實現品牌一致的大背景下，兩套存在差異的設計體系需要完成一些“相互認同”的妥協。
我們采用的方案：
1）通過設計團隊構建 Design System，由全體設計團隊在品牌主題和設計理念的指導下達成一致的共有設計原則集合體，如色彩的運用、字號的等級劃分等。達成一致的設計原則可以通過 Design Token 來定義相同元素在兩個不同設計風格中的狀態。
2）由于 Design System 中的 Design Token 是對元素級顆粒度的設計約束，同時功能頁面是通過無數個元素組合而成，故而 Design Token 可以通過配置化實現靈活性，也為UED與前端研發間建立了契約。
3）通過 Design System 構建出一套具有細顆粒度的設計規范約束，同時能夠適配當前Ctrip和Trip兩個品牌設計現狀，最后可以通過該套 Design System 低成本且靈活得支持品牌一致的最終目標。
3.1.2 功能實現一致
絕大部分的現狀中，不同的品牌面向的地區客群決定了視圖層面中設計語言的差異，而這些差異并不會導致業務功能實現上的區別，如“支付訂單”功能，在不同的地區客群中都有著明確且唯一的認知。
但從不同終端的角度上觀察，相同的功能實現在用戶的交互方面存在一些差異，如App與H5終端上對于明細信息的展現形式存在不同。
基于上述分析，我們給出了建議方案：
1）服務側整理與抽象剝離功能模型與視圖模型，將Controller層中的業務功能邏輯下沉至Integrated Service層和Micro Service層，在技術底層實現功能實現的統一和收口。
2）視圖模型轉由BFF層來完成抽象與差異化定制，實現多終端的渲染共用一套BFF服務。
3）多終端的渲染通過前端業務組件庫承載，前端業務組件庫的作用是抹平各終端在交互操作上的差異，視圖模型作為銜接BFF服務與前端渲染的契約。
3.2 多端一致
分析了多端不一致的現狀后，倘若Controller服務層可以支持多終端復用，即在"功能實現一致"章節中提到的BFF層解決方案，則可以有效解決服務端研發資源瓶頸的問題。
同時，由于BFF層支持的是多終端，倘若拓展前端開發資源的能力至BFF層，既可以進一步釋放服務端研發資源壓力，還可以減少前后端研發資源的溝通成本。
隨著這種工作模式的推進，“代差”的問題終將被解決，研發資源的能效也會得到較大的提升。
3.2.1 BFF架構設計
在BFF模式中，不同的前端應用（如Web、移動端等）共享一套業務邏輯和視圖模型，支持獨立部署。這樣做的好處是，盡管不同的前端可能有不同的需求和特性，但它們可以利用同一個服務來處理視圖模型，同時還能根據各自平臺的特點進行必要的定制化處理。這種架構模式既保證了多端應用的一致性，又保留了靈活性和可擴展性。
架構設計方面需要從引擎、集成服務、BFF服務三層入手，分別代表：
3.2.2 動態化能力
上圖的架構設計中可以發現在BFF層存在 Service Driven Layer，它的作用正是支持前端的動態化能力建設。我們從幾個方面來完整闡述實現的思路。
由于通過BFF層來統一處理視圖模型，但在不同的業務場景下，仍然會存在個性化的差異，這些差異通過Service Driven Layer與前端組件庫協同解決。
以實戰成果來舉例，酒店列表頁中的酒店卡片與酒店營銷頁中的酒店卡片在展現形式上存在將近70~80%的一致性，個性化部分將如何解決？
售賣主流程
營銷流程
在組件庫方面，我們將頁面拆解成模塊集的結構組合，將模塊拆解成組件集的結構組合，將組件結構拆解成元素集的結構組合，這樣的拆解鏈路可以提煉出多個維度的結構，這些結構（Structure）會幫助我們在編譯時與運行時，更加靈活且有規則的實現動態化能力。
樣式部分的處理運用了類似的思路產生（Style），再通過與UED團隊的Design System對接，實現從視覺設計到產品實現的全鏈路規范與動態化能力。
最后通過Service Driven Layer，BFF層除了下發模塊所需的視圖模型（ViewModel）數據之外，還會下發兩項可選的內容：
通過這樣的組合，在不同的業務場景下，無論是靜態編碼還是動態下發，都可以遵循相同的理念去構建并渲染前端頁面，同時這些能力也將大幅提升研發資源的能效。
我們逐步來解析落地過程：
1）圖中的左半部分為開發階段，前端部分的落地方式
2） 圖中的右半部分為線上階段，服務部分的落地方式
從0到1落地BFF支撐C&T雙平臺、多終端和動態化，逐個項目論證技術可行性，搭建所需的技術支撐能力，同時清理歷史技術債，加快研發效能。
C&T Web 酒店詳情頁
目前C&T Web側酒店詳情頁均已支持該架構設計。共用一套BFF功能接口，實現模塊化功能接口。過程中完成了前端和服務端的雙端邏輯下沉工作，提升研發效率的同時拓展了前端職能。
改造范圍涉及Ctrip H5、小程序、Trip Online、Trip H5共5個終端，實現17個功能模塊接口的改造，多端功能模塊收口落地BFF層，實現多端一致和復用，提高研發能效。同時減少多個終端的前端Size 27~39%。
改造過程中實現了從業務領域模型轉換成抽象視圖模型，同時兼具了不同終端可能存在的個性化模塊和功能，從而驗證了該架構設計同時具備前端動態化能力。
C&T 多終端 酒店賣點頁
使用BFF服務結合攜程自研一碼多端框架xTaro，完成C&T共7個終端酒店賣點頁的落地工作。
該項目進一步論證了解決方案的可行性，大幅優化了研發資源能效以及整體工作流，在多端一致的場景下，通過組件庫完成了一碼多端的能力落地。
如此全鏈路的解決方案在落地過程中需要摸著石頭過河，大膽設想結合小心論證，時刻保持與相關團隊的溝通，為了一個共同的目標前行。
我們希望將這套方案中各環節的技術成果產品化，提供給更多具有相同需求的研發團隊，以此共勉。
本文鏈接：http://www.tebozhan.com/showinfo-26-85869-0.html攜程多品牌融合與多端一致的前端方案實踐
聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。郵件：2376512515@qq.com
Copyright ? 2016-2023 天津谷騏科技有限公司 版權所有 sitemap.xml
違法及侵權請聯系：2376512515@qq.com 津ICP備18001702號
津公網安備 12010102000574號