作者簡介

Brain，攜程高級軟件技術(shù)專家，關(guān)注前端技術(shù)框架、跨端技術(shù)方案、前端構(gòu)建和工程化工具，致力于前沿技術(shù)和架構(gòu)優(yōu)化。

一、背景

FlightAI（市場洞察平臺）是攜程機票大數(shù)據(jù)團隊推出的一款賦能行業(yè)的toB數(shù)據(jù)產(chǎn)品。FlightAI的用戶群主要使用微信，但也有移動端和其他企業(yè)辦公IM系統(tǒng)（如企業(yè)微信、釘釘?shù)龋┑氖褂眯枨?。由于大?shù)據(jù)團隊的前端工程師人數(shù)很少，且現(xiàn)有技術(shù)棧主要是web技術(shù)，缺乏移動端開發(fā)經(jīng)驗，因此需要選擇一種以微信為主、研發(fā)成本低、跨平臺（微信小程序、iOS、Android）應(yīng)用的技術(shù)，以滿足業(yè)務(wù)需求并提升研發(fā)效率。

FlightAI涉及大型表格操作與展示、大數(shù)據(jù)的圖表繪制、大數(shù)據(jù)量數(shù)據(jù)指標呈現(xiàn)等場景，對查詢和展示渲染性能要求較高。此外，還需要在微信公眾號、web系統(tǒng)、小程序、移動端等多維度產(chǎn)品矩陣中實現(xiàn)業(yè)務(wù)功能、用戶登錄注冊、賬號管理與體系打通，形成立體式產(chǎn)品服務(wù)，以提升用戶體驗和運營效率。

1.1 難點與挑戰(zhàn)

1.1.1 主要難點

a. 跨平臺開發(fā)的復雜性：

• 雖然一些框架如React Native，F(xiàn)lutter，Weex等同構(gòu)了iOS、Android的架構(gòu)，但在獨立完成移動端全流程開發(fā)和基礎(chǔ)設(shè)施建設(shè)上，仍面臨技術(shù)棧多樣性的問題，特別是跨端架構(gòu)中還需優(yōu)先支持小程序。
• 需要掌握不同平臺（iOS、Android、微信小程序）的證書管理、腳本命令調(diào)用、法律法規(guī)提示和約束差異、真機和模擬器開發(fā)、調(diào)試、構(gòu)建、發(fā)布技術(shù)。
• 跨平臺兼容性問題，如日歷優(yōu)化中遇到樣式兼容性，性能問題等，需要深入理解各平臺的差異和限制。
• 不同平臺、不同流程下各種Token、認證和法律法規(guī)限制概念較多，較難分清。
• UI組件在各平臺的兼容性、生命周期管理和權(quán)限系統(tǒng)、SDK稍有差異，一旦發(fā)生bug識別出這種差異較有難度。

b. 多端登錄態(tài)打通：

• 需要解決不同平臺間的登錄態(tài)同步問題，確保用戶在不同設(shè)備和平臺上有一致的體驗。
• 不同端的登錄支持方式多樣，需要做好同構(gòu)和異構(gòu)，如APP端需支持本機號碼一鍵登錄、賬號登錄、小程序登錄、微信登錄、蘋果登錄等，以支持各個平臺的審核。
• Token種類非常多且復雜，各自用途不同，涉及前臺與服務(wù)端code交換和token驗證等邏輯。

c. 大數(shù)據(jù)列表渲染支持：

• 小程序雙線程機制導致涉及交互的大數(shù)據(jù)列表渲染性能優(yōu)化成為難題。
• 在小程序的技術(shù)架構(gòu)下，官方支持最大DOM數(shù)是16000個，text類節(jié)點也被計算在總節(jié)點數(shù)中，容易超過DOM數(shù)限制，導致＂Dom limit exceeded＂錯誤。

1.1.2 新技術(shù)平臺的挑戰(zhàn)

a. 功能覆蓋率：

• 雖然官方號稱跨多端，但功能覆蓋率、API覆蓋率是否足夠，接入是否復雜，能否滿足當前和未來的需求？

b. 基礎(chǔ)設(shè)施：

• 研發(fā)工具、測試工具、部署工具、運維工具是否成熟，遇到問題如何快速找到支持和解決方案？

c. 研發(fā)生態(tài)兼容性：

• 除了大的跨端技術(shù)框架面臨挑戰(zhàn)，落地實施會面臨更多小型技術(shù)選型的挑戰(zhàn)，如組件系統(tǒng)、圖表庫、其他平臺支持、兼容性問題。

1.2 技術(shù)選型

1.2.1 業(yè)務(wù)需求與現(xiàn)狀

a. 團隊規(guī)模小，跨多端需求和高研發(fā)效率需求：

• 小型研發(fā)團隊，現(xiàn)有技術(shù)技能主要是JS技術(shù)棧，缺乏移動端開發(fā)經(jīng)驗，必須控制培訓成本和研發(fā)成本；
• 考慮集成難度和行業(yè)趨勢，分析功能需求和性能需求等，F(xiàn)lightAI用戶有強烈的移動端使用需求，僅開發(fā)小程序無法滿足；
• 需要選擇一款技術(shù)復雜度低、研發(fā)成本低、技術(shù)棧簡單的跨平臺框架，而Donut技術(shù)滿足跨多端、高性能、低成本需求，且有騰訊官方支持；

b. 業(yè)務(wù)需求：

• 建立獨立賬號體系、獨立域名和品牌，要求與微信公眾號、web系統(tǒng)體系化運營，形成產(chǎn)品矩陣；
• 微信小程序在功能和性能上都要求高優(yōu)先級支持；

c. 高性能需求：

• Donut在小程序支持度和App性能上表現(xiàn)優(yōu)異。在App上底層基于Flutter，使用和微信小程序相同的一套容器，接近原生渲染性能；
• FlightAI具有大批量數(shù)據(jù)實時渲染的需求，對渲染性能要求很高；與公司框架計劃支持使用Flutter提升渲染性能的技術(shù)路線一致；

1.2.2 為何選型Donut技術(shù)

由于用戶群體主要以微信小程序為主要使用場景，所以無法支持小程序的多端框架如React Native，F(xiàn)lutter等無法選用，而既支持小程序又支持移動端的技術(shù)框架，目前市面比較流行的是taro和uni-app，但存在如下顧慮：

• 使用該類框架后，功能更新完全依賴于框架，微信小程序里有的功能可能無法支持；
• 使用該類框架后，代碼經(jīng)過二次轉(zhuǎn)換，性能可能不如原生WXML，而且會帶入轉(zhuǎn)換邏輯額外引入的代碼和性能憂慮；
• 該類框架一般都會自定義DSL，有一定的學習成本，文檔是否健全，社區(qū)支持是否完善將直接影響配置和自定義功能的效率；
• 該類框架優(yōu)勢多在跨多端小程序，實際上線APP的案例并不多，大坑小坑無法避免，例如uniapp的nvue原生開發(fā)有局限性，特別是樣式方面限制比較嚴重；
• 跨多端應(yīng)用開發(fā)的全生命周期集成和管理能力是否強大，包括開發(fā)，測試，構(gòu)建，發(fā)布，運維，法律法規(guī)提示與解讀，token管理等；

而Donut是騰訊官方推出的和小程序同源容器，在功能和性能上比這類衍生框架更優(yōu)秀，在App上底層基于Flutter，接近原生渲染性能；Donut以小程序DSL作為開發(fā)語言，可以無縫切換，也沒有二次轉(zhuǎn)換的成本，會開發(fā)小程序就會寫Donut APP。在研發(fā)工具、測試工具、部署工具、運維工具上騰訊做了全方位集成，小型團隊可能遇到的問題幾乎全部涵蓋。官方文檔一步一截圖，閱讀體驗良好，總結(jié)如下：

a. 功能覆蓋率較高

常用需要適配API（8個），根據(jù)使用情況進行選擇支持，Donut官方提供了非常多的功能API，從功能支持度、易用性和架構(gòu)上App小程序同構(gòu)上也可以看出官方的大力投入。

JSAPI 和組件支持匯總，涉及6大方面

組件部分：視圖組建，表單，導航，媒體，地圖，畫布，開發(fā)能力，原生組建都能較好支持；

API部分支持情況：總共大概507個API；支持371個，大概占73%，部分支持或者不支持的部分官方提供一些其他的替代方案；（2024-03統(tǒng)計）

SDK部分：基礎(chǔ)SDK和擴展SDK支持較好；這部分是Native功能，根據(jù)需要進行勾選，不選就不會打入包中，按需打包降低包size；

NativePlugin：支持Native自定義擴展，該部分都是一次性工作，除非有強烈的自定義需求，一般都用不上；

云支持：云開發(fā)云托管，Donut網(wǎng)關(guān)防護；

埋點監(jiān)控：熱力圖，回放功能支持完善，支持全埋點；

b.基礎(chǔ)設(shè)施較完善

Donut 平臺覆蓋開發(fā)、部署、產(chǎn)品體驗分析全產(chǎn)品開發(fā)周期的各種需求，研發(fā)工具、測試工具、部署工具、運維工具上騰訊做了全方位集成，基礎(chǔ)設(shè)施比較完善，貫穿產(chǎn)研全流程支持，可大幅提升研發(fā)效率，特別對于沒有移動端研發(fā)經(jīng)驗的團隊具有引導和指導的作用。

• 多端框架-支持使用小程序原生語法進行一次代碼編寫，多端編譯，實現(xiàn)多端開發(fā)。 
• 多端身份管理-幾行代碼，快速實現(xiàn) App、小程序的身份認證和用戶管理。
• 安全網(wǎng)關(guān)-提供弱網(wǎng)加速、防爬防刷、流量治理等能力，全方位保障業(yè)務(wù)安全高效穩(wěn)定運行。
• 產(chǎn)品體驗分析-從真實的用戶視角洞察產(chǎn)品問題，尋找產(chǎn)品體驗的不足之處，提升用戶留存與轉(zhuǎn)化，具有如下功能：
• 零代碼、全埋點
  無需開發(fā)，一鍵接入，元素自動全埋點，快速開始小程序數(shù)據(jù)分析。
• 還原用戶操作現(xiàn)場
  創(chuàng)新可視化日志 & 熱力圖，還原用戶實際操作現(xiàn)場，問題分析一目了然。
• 可視化交互分析
  全程無需 SQL 編寫，僅需在模擬器上點選交互即可完成分析過程。
• 一鍵智能分析
  無需數(shù)據(jù)分析背景，根據(jù)業(yè)務(wù)目標智能分析，查找用戶漏點，提升轉(zhuǎn)化率。

c. 研發(fā)生態(tài)兼容性較強

• UI組件系統(tǒng)

UI組件系統(tǒng)選型TDesign還是使用WeUI，還是使用Ant Design for Mobile，NutUI，Vant，Material-UI？

主要考慮組件的成熟度，兼容性，組件功能，TDesign是騰訊官方出品的組件庫，而WeUI則側(cè)重提供樣式庫，考慮社區(qū)實踐經(jīng)驗，最終選擇TDesign，組件相對豐富，常用組件齊全，貼合微信設(shè)計規(guī)范，在Donut APP的兼容性較好，復用組件可以節(jié)省不少開發(fā)工作量。

• 圖表庫選擇

圖表庫使用echart還是g2移動版圖表庫，還是選擇wx-chart，ucharts，D3，antV，Threejs等圖表庫？從如下幾個方面進行了考慮：代碼規(guī)范：EChart、D3官網(wǎng)的部分案例還是使用了ES5的語法，Antd遵循了ES6新語法規(guī)范。靈活度：ECharts＜G2＜D3；使用難度：Echart≈G2PLot＜G2＜D3；場景：三維圖推薦用Threejs，二維圖用ECharts或者G2、G2Plot均可；考慮到FlightAI圖表類型為常規(guī)圖形，而且PC版本選型也是Echart，在小程序集成和兼容性上，Echart都表現(xiàn)較好，但Echart在分辨率處理上和Donut系統(tǒng)并不兼容，但在編寫適配層解決該難題后，用起來非常絲滑，所以最終選定Echart。

• 小程序兼容性

小程序轉(zhuǎn)其他小程序或者web的方案調(diào)研如morjs等轉(zhuǎn)出來的小程序，其他跨多端如Taro轉(zhuǎn)Donut技術(shù)是否可行？

理論上Donut提供的是小程序運行容器，其他跨端或者轉(zhuǎn)換技術(shù)只要最終產(chǎn)物符合微信小程序規(guī)范，應(yīng)該可以運行，但是轉(zhuǎn)換必然導致功能和性能上有損耗，而且對于Donut條件編譯等語法需要進行特殊處理，一般轉(zhuǎn)換代碼會帶來額外的處理邏輯，會增大包Size，雖然有副作用，但Donut本身的擴展能力還是很強的，畢竟提供了和微信一致的小程序容器。

1.3 Donut簡介

Donut平臺是騰訊出品的基于小程序?qū)崿F(xiàn)跨多端（小程序，IOS，Andord）的技術(shù)體系，覆蓋了開發(fā)、部署、產(chǎn)品體驗分析全產(chǎn)品開發(fā)周期的各種需求。開發(fā)者可以專注于代碼邏輯，將復雜的開發(fā)構(gòu)建流程，開發(fā)及運行環(huán)境等統(tǒng)一管理，有效降低多端應(yīng)用開發(fā)的技術(shù)門檻和研發(fā)成本，以及提升開發(fā)效率和開發(fā)體驗。包含4大特色能力：多端框架，多端身份管理，安全網(wǎng)關(guān)，產(chǎn)品體驗分析。

1.3.1 Donut系統(tǒng)模塊圖：

主要分為客戶端和云端功能，客戶端主要負責端側(cè)的標注化容器，處理小程序基礎(chǔ)庫，小程序SDK等基礎(chǔ)設(shè)施，云側(cè)主要處理各種管理和審核功能，流程都集成在了微信開放平臺，微信開發(fā)者平臺，微信公眾平臺，Donut管理平臺幾大平臺上。

1.3.2 Donut工作流程

簡單理解，就是微信抽象了一個簡化版本的微信APP作為容器，底層都是基于Flutter進行渲染，承接小程序的能力，并利用微信開發(fā)者工具提供研發(fā)支持；理論上只要是微信小程序都能運行在該平臺上。

1.3.3 Donut技術(shù)適合誰

a. 基于小程序生態(tài)開展業(yè)務(wù)的個人或企業(yè)；

b. 需要跨多端支持、高性能和高研發(fā)效率的項目；

c. 已經(jīng)擁有小程序，想擴展到移動端的項目；

d. 希望簡化或標準化開發(fā)運營流程，利用微信提供的全軟件研發(fā)周期集成能力的項目。

二、FlightAI如何基于小程序構(gòu)建一款跨多端移動應(yīng)用Donut-APP

首先在微信公眾平臺（mp.weixin.qq.com）注冊小程序，完成注冊后可同步進行信息完善和開發(fā)。下載微信開發(fā)者工具、參考開發(fā)文檔進行開發(fā)和調(diào)試。要成為Donut跨多端研發(fā)人員需要了解如下信息：

2.1 多端應(yīng)用開發(fā)：開發(fā)賬號準備

2.2 了解賬號關(guān)系

2.3 多端應(yīng)用開發(fā)：開發(fā)資源準備

2.4 開啟多端應(yīng)用模式

a. 新建或者升級小程序為多端項目即可

b. Donut多端項目結(jié)構(gòu)

和小程序項目結(jié)構(gòu)一致，只是多了一些跨多端框架的配置文件，app.miniapp.json主要作用是維護多端應(yīng)用和小程序綁定關(guān)系，配置App小程序登錄頁面地址，授權(quán)頁等。

project.miniapp.json則主要用于配制原生插件，多和native交互有關(guān)；project.config.json則是小程序相關(guān)的配置文件。

2.5 了解條件編譯

Donut支持以條件編譯的方式編寫特定平臺代碼；如有些組件只有微信支持，有些業(yè)務(wù)需求只在微信展示，那么就需要條件編譯實現(xiàn)差別需求，在app上和小程序使用不同的代碼方式實現(xiàn)，一般該類代碼占比較少，F(xiàn)lightAI項目中，我實現(xiàn)了自動統(tǒng)計條件編譯代碼的功能，可統(tǒng)計上報或者單機運行了解項目狀態(tài)。

2.6 多種登錄方式支持-多端身份管理

a.FlightAI登錄架構(gòu)設(shè)計

Donut支持多種登錄方式，一般項目完全夠用了，并在后臺做了較好的集成管理，官方叫做多端身份管理，F(xiàn)lightAI的場景比較復雜，除了Donut提供的5登錄方式之外，還支持了密碼登錄等總共10種登錄方式，給客戶最大的便利和可選擇性；支持方式多樣，但是底層驗權(quán)，鑒權(quán)，授權(quán)等接口都實現(xiàn)了統(tǒng)一。

b.小程序和 App 的統(tǒng)一身份識別

小程序的token和code2Session接口進行交換，App的token和code2Verifyinfo接口進行交換，各個接口都有配套API，比較復雜，不能搞混了，最好單獨一整套接完，再接入另外一套。

2.7 大列表渲染

在webview的雙線程架構(gòu)下，小程序的官方支持最大Dom數(shù)是16000個，text類節(jié)點也被計算在總節(jié)點數(shù)中，非常容易就超過Dom數(shù)限制，導致Dom limit exceeded， please check if there's any mistake you've made.

無論是模擬器還是真機，小程序還是Donut APP，在FlightAI場景中view-all頁面，經(jīng)過測試442條渲染Item是臨界點，超過442條就會白屏，在該數(shù)據(jù)結(jié)構(gòu)下Dom數(shù)會達到臨界點，并且442條數(shù)據(jù)在IOS模擬器上渲染耗時5646ms，這也側(cè)面證實了各端各工具在Dom數(shù)限制上是一致的。

官方推薦標準

官方推薦說明（也是評分標準），單頁面節(jié)點盡量不超過1000個節(jié)點，嵌套不超過30層，子節(jié)點不超過60個，頁面深度不超過10個；但功能較為復雜的頁面，非常容易就超出限制，那么如何突破這個問題呢？

長列表渲染特點

1）列表數(shù)據(jù)很大，首次 setData 的時候耗時高，雙線程模型使得交互性能成為瓶頸；

2）一次渲染出來的列表 DOM 結(jié)點多，每次 setData 都需要創(chuàng)建新的虛擬樹、和舊樹 diff 操作耗時都比較高；

3）渲染出來的列表 DOM 結(jié)點總數(shù)多，占用的內(nèi)存高，造成頁面被系統(tǒng)回收的概率變大。

優(yōu)化思路

要么徹底改變雙線程的底層架構(gòu)，要么通過一些手段優(yōu)化參與渲染的數(shù)據(jù)和狀態(tài)，只渲染顯示在屏幕的數(shù)據(jù)，基本實現(xiàn)就是監(jiān)聽 scroll 事件，并且重新計算需要渲染的數(shù)據(jù)，不需要渲染的數(shù)據(jù)留一個空的 div 占位元素。如下是2個解決方案：

a.微信官方提供recycle-view的解決方案，虛擬列表方案；

在滾動過程中，重新渲染數(shù)據(jù)的同時，需要設(shè)置當前數(shù)據(jù)的前后的 div 占位元素高度，同時是指在同一個渲染周期內(nèi)。頁面渲染是通過 setData 觸發(fā)的，列表數(shù)據(jù)和 div 占位高度在2個組件內(nèi)進行 setData 的，為了把這2個 setData 放在同一個渲染周期，用了一個 hack 方法，所以定義 recycle-view 的 batch 屬性固定為 batch=＂{{batchSetRecycleData}}＂。

b.微信官方為提升渲染速度，開發(fā)了skyline渲染引擎。

skyline渲染引擎，使用更精簡高效的渲染管線，并帶來諸多增強特性，讓 Skyline 擁有更接近原生渲染的性能體驗。

使用skyline之后，不會有dom數(shù)限制了；而且很明顯的一個對比是使用skyline后，快速滑動長列表不卡頓，首頁沒有開啟skyline快速滑動會卡頓。

注意列表布局容器，僅支持作為 scroll-view 自定義模式下的直接子節(jié)點或組件直接子節(jié)點，scroll-view要設(shè)置自定義模式 type=＂custom＂，list-view要作為 scroll-view 直接子節(jié)點。

WebView 的 JS 邏輯、DOM 樹創(chuàng)建、CSS 解析、樣式計算、Layout、Paint （Composite） 都發(fā)生在同一線程，在 WebView 上執(zhí)行過多的 JS 邏輯可能阻塞渲染，導致界面卡頓。

Skyline 創(chuàng)建了一條渲染線程來負責 Layout， Paint 和  Composite等渲染任務(wù)，并在 AppService 中劃出一個獨立的上下文，來運行之前 WebView 承擔的 JS 邏輯、DOM 樹創(chuàng)建等邏輯，架構(gòu)深度優(yōu)化后性能提升顯著。

Skyline長列表官方文檔

性能對比

官方示例：小程序助手的線上數(shù)據(jù)，可以看出 Skyline 的首屏時間比 WebView 快 66%，并且手機性能越低端，差異就越明顯。

另外嘗試自行計算小程序的Dom數(shù)，Dom層級，做統(tǒng)計或者優(yōu)化，發(fā)現(xiàn)querySeletorAll API無法使用通配符，另外涉及到Shadow-Dom，計算變得非常麻煩；向微信官方求證過Dom最大size的數(shù)量是16000個，這是編譯器層面的限制，無法放開。經(jīng)過和微信官方溝通結(jié)果是他們可以提供小程序的Dom數(shù)計算API，目前還沒有提供，將來可以提供。

2.8 實現(xiàn)Push消息推送

FlightAI接入TPNS或者公司的Push系統(tǒng)的一些思考和調(diào)研；騰訊云有提供TPNS，但是這套推送接入成本較高，而且已停止售賣；收費標準大概是800*DAU/10000，8分錢/條，按用戶收費。

Donut提供了基于IM的新版本推送服務(wù)，2024-8月份開始支持；通過配置插件和證書實現(xiàn)推送功能，支持在線推送和離線推送；IOS和Android的各個廠商需要分別進行配置，這是廠商的規(guī)范不同導致。

新版本收費規(guī)則根據(jù)數(shù)據(jù)中心位置和不同的套餐有所不同。后臺需要根據(jù)各廠商申請對應(yīng)的證書AppKey和AppID，并根據(jù)需求制定推送策略。

對于接入成本的考慮，在客戶端只需簡單配置PluginId即可，配置示例：

2.9 正式構(gòu)建APK和IPA

構(gòu)建移動端APP的臨時簽名和正式簽名是區(qū)分的，臨時簽名Donut官方直接提供，正式簽名證書，需要研發(fā)人員按照目標平臺進行注冊，上傳，注意簽名文件對目錄有要求，必須放在項目內(nèi)，IOS的鑰匙串必須和配置中的名稱完全一致。

2.10 內(nèi)測分發(fā)與提交審核

在開發(fā)者工具上 選擇 正式版點擊「構(gòu)建」- 「上傳資源包」，即可將開發(fā)版本的資源包上傳至Donut資源包管理平臺，之后跟進研發(fā)流程自行決定測試版本和線上版本。

2.11 完成各平臺隱私協(xié)議，法律條款，授權(quán)彈窗等上架要求，發(fā)布APP

需要注意的是各大電子市場的要求各不相同，為了能夠上架，需要滿足各平臺的各種規(guī)范，否則審核無法通過，特別是涉及法律條款需要法務(wù)部門介入，通常時間非常長，要做好相關(guān)準備。

2.12 踩了哪些坑

• 一些證書導致的問題
  在進行基礎(chǔ)設(shè)施建設(shè)中，完成小程序，Donut跨多端基建，包括環(huán)境搭建、系統(tǒng)配置、開發(fā)、測試和發(fā)布流程的打通， 技術(shù)框架搭建，架構(gòu)設(shè)計模型，開發(fā)流水線等。比如證書位置不對，證書信息不匹配，申請證書的Domain，link等信息不一致，在構(gòu)建的時候可能會報一些奇怪的錯誤，始終無法通過構(gòu)建，這塊的研發(fā)信息提示很不明確，但會Block研發(fā)進程，已建議官方優(yōu)化；
  
• 構(gòu)建產(chǎn)物，雖然功能增多，業(yè)務(wù)邏輯變的越來越復雜，包size會正常增長，但是如果有自定義管理資源包的需求，那么就會遇到包size上傳限制的問題，那么就需要分包，比如我們nephle最大支持30M的包，需要解決分塊上傳問題；另外如果要實現(xiàn)ios自動下載安裝的能力，模版地址和包地址需要放在同一目錄，否則坑較深，會浪費不少精力和時間；另外真機調(diào)試和構(gòu)建，直連的數(shù)據(jù)線非常重要，帶轉(zhuǎn)換的多功能數(shù)據(jù)線很有可能帶來不少意外的構(gòu)建問題；
  
• 功能開發(fā)與性能優(yōu)化：圖表功能開發(fā)，日歷功能開發(fā)與性能優(yōu)化，TDesign官方日歷組件存在性能問題，官方提供的format鉤子，在遇到多年份日期遍歷的時候，性能問題突出，t-calendar并且不支持虛擬列表，所以性能不理想，采用Hash算法后優(yōu)化了近400倍，提升日歷功能的性能，另外TDesign和Donut是不同的團隊，提issue的時候要找準團隊，否則可能不被受理。
  
• 小程序備案，域名備案，微信認證，用戶告知，服務(wù)條款，隱私協(xié)議，軟著商標，何時啟動？有哪些坑？
  法務(wù)審核和各種認證需要準備很多企業(yè)實體資料，盡早準備提交，完全按照文檔操作，否則會被打回重寫，再者審核周期不可控，應(yīng)當盡早啟動，隱私彈窗和授權(quán)彈窗必須使用模版或者native開發(fā)，不能使用其他方式，因為APP在授權(quán)之前是不能加載和運行代碼的。請仔細閱讀相關(guān)章節(jié)注意事項；
  
• token管理
  
  token是測試一套，生產(chǎn)一套，配置不同，Android和IOS平臺各自管理一套，另外mobileprovision必須包含Doman，而且Donut和開發(fā)工具，APP中的信息必須一致；
  

三、成果與經(jīng)驗

3.1 技術(shù)創(chuàng)新與效率提升，代碼復用率99%

• 代碼復用率：實現(xiàn)了99%的代碼復用率，特定平臺代碼代碼為非復用代碼，自行實現(xiàn)了自動統(tǒng)計的功能；
• 成功研發(fā)一款跨平臺高性能APP：成功開發(fā)了業(yè)務(wù)代碼基于小程序，底層框架與微信同源基于Flutter的高性能跨多端移動應(yīng)用，確保iOS、Android和微信小程序上的一致性和高性能，為公司探索新跨多端技術(shù)方案；搭建了iOS和Android應(yīng)用的自動化構(gòu)建和持續(xù)集成（CI/CD）管道，提升了開發(fā)和發(fā)布效率；
• 采用Skyline新渲染引擎， 首屏時間比 WebView 快 66%，更重要的是Skyline沒有Dom數(shù)限制，對于開發(fā)大型項目來說非常重要；
• 一碼多端，跨多端真機效果；
  

3.2 打造產(chǎn)品矩陣，用戶體驗

為了提升攜程市場洞察平臺的應(yīng)用范圍和市場競爭力，我們打造了一個全面的產(chǎn)品使用矩陣，實現(xiàn)了移動端、小程序、現(xiàn)有的Web端、微信公眾號和API服務(wù)的完整覆蓋。通過這種多端覆蓋，我們能夠更好地滿足用戶在不同場景下的使用需求，提升產(chǎn)品的市場競爭力。

為了提升用戶體驗，我們打通了多種設(shè)備和多種類型的登錄態(tài)，支持用戶通過不同設(shè)備和渠道無縫登錄。除了Donut提供的5登錄方式之外，還支持了密碼登錄等總共10種登錄方式，給客戶最大的便利和可選擇性。

在市場洞察平臺中基于Donut實現(xiàn)了跨多端高性能移動端的技術(shù)實踐，確保了產(chǎn)品在各種移動場景下的優(yōu)異表現(xiàn)。

通過這些技術(shù)創(chuàng)新和優(yōu)化，我們不僅提升了產(chǎn)品的應(yīng)用范圍和市場競爭力，還顯著改善了用戶體驗，為用戶提供了更加便捷和高效的使用體驗。