推薦系統:精排多目標融合與超參數學習方法

来源:https://www.cnblogs.com/orion-orion/p/18199461
-Advertisement-
Play Games

粗排/精排的個性化多任務學習模型,能預估20多個不同的預估值,如點擊率、有效播放率、播放時長、點贊率、關註率等,那如何用它來排序呢?從多任務學習到多目標排序,中間有一個過渡,即如何把這些預估值融合成一個單一的排序分,最後實現多目標精排。這也就引入了本文要介紹的正題:多目標融合(multi-task ... ...


帕累托最優指的是這樣一種社會狀態:當且僅當不減少其他人的效用就無法增加任何一個人的效用時,這種社會狀態就稱之為帕累托最優。

1 導引

1.1 推薦系統基本架構

在介紹多目標融合模塊之前,我們先來回顧一下推薦系統的基礎架構,以及多目標融合模塊在推薦系統中所處的基本位置。一種在各大廠(如快手[1]、美團[2]、阿裡飛豬[3]等)中常見的“多層漏斗型”推薦系統架構如下:

上述過程中,召回、粗排、精排+多目標融合、序列/多樣性重排、異構混排是在服務端進行(其中異構混排亦有放在移動端的[4]),端上重排[4]是在移動端進行。下麵大致介紹一下這些步驟的作用:

  • 召回 召回是推薦系統的第一步,負責快速從大量的物品中篩選出一部分候選物品,將樣本數量由千萬/百萬級降到1萬左右。召回並不需要十分準確,但需要不漏掉用戶可能喜歡的物品。召回模塊通常採用多路召回,且受限於龐大的樣本量,一般會使用一些簡化的特征或模型。經典召回模型包括協同過濾、FM、DSSM雙塔模型等,針對序列數據和圖數據,亦有序列模型SASRec和圖模型GraphSAGE等。召回是源頭,在某種意義上決定著整個推薦系統表現的天花板。
  • 粗排 粗排可以理解為精排前的一輪過濾機制,減輕精排的壓力,將樣本數量從從1萬左右降到1千/幾百。設置粗排模塊的原因是有時候召回結果還是太多,精排層的速度跟不上。粗排要同時兼顧精準性和低延遲,其模型一般也不會太複雜。最後,由於粗排處於召回和精排之間,因此粗排需要獲取和利用更多後續鏈路的信息來提升效果,粗排和精排的聯動也成為實際工程中所需要面臨的挑戰。
  • 精排( + 多目標融合) 精排負責獲取粗排的結果,並對候選集進行打分和排序。精排需要在最大時延允許的情況下,保證打分的精確性,是整個系統中至關重要的一個模塊,也是最複雜、研究最多的一個模塊。不同於粗排常常使用簡單的雙塔模型,精排在特征和模型上都會做的比較複雜。目前,精排模型已被深度學習模型“一統天下”,包括Wide&Deep、DeepFM、DIN等,亦會使用Attention(如DIN)、對比學習、遷移學習等機制來提高模型精度。由於在工業界的實踐中常常有多個線上指標,故又常使用深度多任務學習(MTL)模型。最後,由於精排關註的是物品的排序,所以其loss亦不同於常見的loss,常依據排序學習(Learning to Rank)策略來進行設計。而LTR方法按照樣本生產方法和損失函數loss的不同,又分為pointwise形式和pairwise形式這兩類。
  • 重排 重排模塊的任務是對之前排序模塊的結果進行二次排序或調整,以進一步提高推薦的準確度和個性化程度。重排所要處理的問題包括序列價值最大化(也即所謂listwise、不同於單item效果的累計)、增加推薦列表的多樣性等等。重排一般是做打散或滿足業務運營的特定強插需求,同樣不會使用複雜的模型。此外,重排還可能在移動端上,即所謂端上重排。
  • 混排 混排的任務在於將多源異構內容(比如視頻和廣告)的返回結果進行恰當組合,得到一個綜合價值最大的返回序列。

1.2 多目標融合(MTF)簡介

不同於學術界只考慮點擊ratings預估的做法(即將推薦系統建模為簡單的二分類問題,然後離線評估算單個AUC或者HR/MRR啥的),推薦系統的優化目標在工業界的實踐中常常是有多個的(且大多為線上指標),尤其是短視頻推薦場景。以短視頻推薦場景為例,在推薦系統的排序建模過程中,我們需要提升用戶的使用時長/正向反饋,減少負向反饋,從而提高用戶的留存。短視頻推薦場景中的用戶反饋可分為四類:

  • 隱式正反饋 用戶在無意間的行為,如播放時長、播放完成率、完播、復播等等。
  • 顯式正反饋 用戶有意識地做出的反饋,如收藏、下載、關註、點贊、發表正向評論等等。
  • 隱式負反饋 用戶隱式表達的負反饋,如短播放、用戶終止一次session等。
  • 顯式負反饋 用戶顯式表達的負反饋,如不感興趣、負向評論、舉報等。

我們的目標是提高正向反饋、減少負向反饋,提高用戶體驗。然而,我們之前說過,粗排/精排的個性化多任務學習模型,能預估20多個不同的預估值,如點擊率、有效播放率、播放時長、點贊率、關註率等,那如何用它來排序呢?從多任務學習到多目標排序,中間有一個過渡,即如何把這些預估值融合成一個單一的排序分,最後實現多目標精排。這也就引入了本文要介紹的正題:多目標融合(multi-task fusion, MTF)

如上圖所示,多目標融合模型在精排MTL模型輸出多個預估分數(對應上述各種用戶的反饋)之後,對多個預估分數進行融合,隨後根據融合的打分進行精排,並輸入到後續的重排模塊。

2 多目標融合方法介紹

2.1 手工融合

最簡單的多目標融合方式就是手工融合,一般包括線性加法指數乘法兩種:

  • 線性加法
    線性加法的融合公式如下:

    \[\text{score} = \sum_{i=1}^n w_i\space \text{score}_i \]

    這裡\(\text{score}_i\)為精排的多任務模型對第\(i\)項目標的預估分數,包括觀看動作、喜歡、觀看時間等目標的預估分數。

    線性加法還有許多變種,比如採用加權Logloss:

    \[\text{score} = \sum_{i=1}^n w_i\space \log \text{score}_i \]

    線性加法的優點在於其目標權重就指示了目標在融合公式中的重要度,直觀上哪個目標更重要我們就將哪個目標的權重調大。當然其缺點也非常明顯,這個權重繫數對於所有類型的目標都是一視同仁的。事實上對於點贊這種稀疏目標,理論上應該讓預估分數高的權重更高(活躍的用戶權重更高),預估分數低的權重更低(不活躍用戶的權重更低),但上述形式的目標顯然做不到。

  • 指數乘法

    \[\text{score} = \prod_{i=1}^n \space \text{score}_i^{w_i} \]

    和線性加法基本一樣,唯一的區別是把累加換成了累乘。其優點和缺點正好和線性加法相反:其優點是可以做到增強高的預估分數、抑制低的預估分數;其缺點是不能調大單一目標的指數權重,因為如果簡單地給單一目標增大指數那就相當於對所有目標都生效了(等價於融合公式整體乘一個繫數)。

愛奇藝在多目標融合的初期實踐中採用的就是加法融合的方式,但這樣產出的排序得分對各子目標的得分值域很敏感(也即容易被某些顯著偏大的目標所主導,比如點贊這種目標就可能存在一些明顯偏大的異常值),因此他們增加了\(\alpha\)\(\beta\)兩個超參數,來聯合調節各子目標得分的靈敏度與提升比例,也就得到瞭如下所示的帶權指數加法[5][6]的公式形式:

  • 帶權指數加法

    \[\text{score}=\sum_{i=1}^n \text{factor}\cdot\left(\alpha_i+\text{score}_i\right)^{\beta_i} \]

    這裡\(\text{factor}\)為超參數,表示組合權重;\(\beta\)為超參數,用於提升比例與非線性處理;\(\alpha_i\)亦為超參數,表示靈敏度。

愛奇藝在工程實踐中發現,在業務目標較少時,通過加法融合公式新增目標可以短期內快速獲得收益。但隨著目標逐漸增多時,加法融合公式的融合能力會逐漸受限。這是因為對加法融合公式而言,新增目標後,各子目標的重要性影響會減弱。此外,哪怕是已經增加了超參數\(\alpha\)\(\beta\)的情況下,加法融合公式仍然容易被最大的目標主導。不過,乘法融合公式就不存在這些問題。因此,在此基礎上,愛奇藝又把多目標融合公式調整為了乘法:

  • 帶權指數乘法

    \[\text{score}=\prod_{i=1}^n \text {factor}\left(\alpha_i+\text{score}_i\right)^{\beta_i} \]

    這裡公式參數含義與上述公式一致,只是把累加換成了累乘。

手工融合的優點在於其目標權重就指示了目標在融合公式中的重要度,比較直觀且可解釋性強。當然其缺點也非常明顯,這個權重繫數對於所有用戶都是一樣的,缺少個性化。此外,這裡無論對預估分數使用加法還是乘法的方式來融合,模型serving時的超參數均是通過網格搜索(grid search)[7]來得到離線最優的幾組解。而我們知道,推薦系統的實際表現還需要線上A/B實驗才能確定的,這導致該方法效率較低。而且隨著模型的迭代與樣本分佈的變化,最優參數也在變化。最後,手工融合的缺點還體現於維護成本高(因為常常要進行多次的手工調整)。

那麼,我們是否可以用模型來學習超參數呢?這就涉及到了融合超參數的學習方法[8]了,也即用一個模型來學習各預估分數的組合權重。

對於融合超參數的學習方法而而言,最容易想到的應該是離線方法,也就是用一個離線模型來學習各預估分數的組合權重。這種方法的優點和缺點都很明顯,分別如下所示:

  • 優點 離線方法是off-policy的方法,數據利用率高(100%樣本都可以被使用),且模型的自由度和複雜度較高,可以容納item embedding並使用稀疏特征,可以訓練千億規模的參數。

  • 缺點 優化的離線AUC無法直接反映業務指標。因為這個過程做了很多簡化,推薦系統不是精排之後就直接對接用戶了,中間還有重排(比如多樣性)等的影響,甚至還有一些商業化/運營流量的混排融合,所以該方法難以考慮到線上複雜多模塊間的完整影響。此外,線下訓練數據和線上數據也存在分佈不一致的問題。

考慮到離線超參數學習方法具有的上述的缺點,在實際工業界的應用中,我們常常使用線上的超參數學習方法。線上方法的工作流程如下圖所示:

可以看到,線上超參數學習演算法基於探索與利用機制,會在baseline附近探索生成\(N\)組參數,傳給推薦系統後獲得這\(N\)組參數對應的展現給用戶的差異化排序結果,從而獲得不同用戶的反饋。之後再收集這些反饋日誌並做收益(reward)統計,最終送給BayesOpt/ES/CEM等調參演算法產生下一組更好的參數。經過不停迭代,參數就會向一個多目標協調最優的方向前進。

線上的超參數學習方法具有以下優缺點:

  • 優點 直接優化線上指標,靈活性高且反饋迅速,並且可以把推薦系統當做一個黑盒,無需關心內部細節。且可以做多場景聯合優化,不限於ranking,在召回等場景也可以用。

  • 缺點 需要線上上劃分出一部分探索流量(大約5%),從而影響少部分用戶體驗,且由於數據稀疏,受雜訊影響較大,尤其是一些稀疏的動作標簽,比如分享、下載、收藏等;能容納的參數量較小,一般幾十到數百,相對離線學習的參數規模小很多。

常見的線上超參數學習方法包括貝葉斯優化方法(Bayesian optimization)[9]進化策略演算法(evolutionary strategy)[10]CMA-ES自適應進化演算法[11]等,下麵我們主要介紹貝葉斯優化方法和進化學習演算法。

2.2 融合超參數學習方法

2.2.1 貝葉斯優化演算法

貝葉斯優化演算法充分考慮了真實的線上收益,通過收集多組小流量經驗,基於小流量實驗的評估結果來進行參數優化。

貝葉斯優化的基本思想在於由於真實優化函數計算量太大或是個黑盒(比如推薦場景中用戶的真實反饋收益),我們需要用一個代理函數(surrogate function) 來近似它。而在代理函數周圍可能是最小值點的附近,或者是在還沒有採樣過的區域採樣新的點之後,我們就可以更新代理函數,使之不斷逼近目標函數。我們常採用高斯過程(Gaussian process, GP) 來建模概率代理函數的分佈,然後再設計一個採集函數(acquisition function),基於高斯過程回歸的結果來計算下一組可能更優的採樣點(使採集函數最大化)。註意:這裡之所以使採集函數最大化,而不是直接使代理函數最大化,因為直接優化代理函數過於目光短淺了,因為我們還要考慮不確定性。事實上,這也是一種探索(exploration)機制的體現。貝葉斯優化與網格搜索的不同之處在於,它在嘗試新的超參數組合時會考慮之前的評估結果(即利用了證據,即evidence的信息來估計代理函數的後驗分佈),並基於代理函數來求解採集函數的極值,從而確定下一個採樣點。

貝葉斯優化包含兩個關鍵組成部分:

  • 概率代理模型 用於對代理函數的分佈進行建模,在迭代開始前初始化為一個指定的先驗分佈。常用的概率代理模型有:高斯過程(GP)、樹形Parzen估計器(tree-structured parzen estimator, TPE)、神經網路、決策樹等。
  • 採集函數\(u\) 採集函數用於衡量每一個點值得探索的程度。每輪迭代演算法會基於現有的高斯過程,從候選集中選擇下一步的迭代點以使得採集函數最大化。貝葉斯優化效果受採集函數的影響較大,選擇不合適的話容易陷入局部最優解。採集函數的選取可以看做一個探索-利用問題,常用採集函數包括置信區間上界(Upper Confidence Bound, UCB)方法、POI方法、EI方法等(其中最為簡單易用的是UCB方法)。

首先,演算法會初始化一個代理函數的先驗分佈,然後開始迭代。演算法的第\(t\)步迭代的偽代碼描述如下:

  • 通過優化採集函數\(u\)以獲得\(x^{t+1}\)\(x^{t+1}=\text{arg max}_{x} \space u(x\mid \mathcal{D}^{t})\)
  • 通過用戶的線上反饋收益\(r\)(對應貝葉斯優化中的目標函數)得到\(y^{t+1}\)
  • 對數據進行增廣:\(\mathcal{D}^{t+1} = \{\mathcal{D}^t,\quad (x^{t+1},\quad y^{t+1})\}\)
  • 更新概率代理模型(如高斯過程回歸),得到一個代理函數的後驗分佈(做為下一步迭代的先驗分佈)。

演算法流程示意圖如下:

註意,在實際的推薦系統場景中,我們用於定義高斯過程的代理函數就是我們之前所定義的融合冪乘函數,即\(\text{score} = \prod_{i=1}^n \space \text{score}_i^{w_i}\)。具體在短視頻推薦場景中,\(\text{score}_i\)可能為用戶time、like、follow等行為的預估分數。用戶的線上反饋收益\(r\)可以設定為單次屏幕刷新中的點贊率、平均視頻播放時長等,樣本集合\(\mathcal{D}=\{(x, y)\}\),這裡\(x =(w_1, w_2, \cdots, w_n), y=r\)

2.2.2 進化策略(ES)演算法

前面講述的基於貝葉斯優化的多目標融合演算法雖然解決了手工融合的許多問題,但模型的參數(即多目標融合參數)仍然是單一的,不夠個性化,亦不具備動態環境與上下游自適應性。

由於現在多目標融合參數量非常大(有的甚至達到了百級別),我們需要一種更高效、更自動化的方式來優化超參數,從而能夠動態調整不同人群的單目標優化參數。因此,人們提出使用進化策略演算法,以線上實時的真實收益為指引,對模型的參數進行優化。

註意,進化學習與強化學習的優化目標都是預期的reward,但強化學習是將雜訊加入動作空間並使用反向傳播來計算參數更新,而進化策略則是直接向參數空間註入雜訊。

如上圖所示,使用進化學習演算法,線上對模型參數進行擾動,根據擾動後的結果來計算reward(常設置為人均或單刷的停留時長/播放時長/深度消費等關鍵業務指標),並離線進行小時級模型訓練。觀察到較優模型參數組合後,則更新線上的baseline模型參數。

進化演算法第\(t\)輪模型迭代偽代碼如下:

  • 採樣雜訊 \(\varepsilon_1, \cdots, \varepsilon_n \sim \mathcal{N}(\boldsymbol{0}, \boldsymbol{I})\)
  • 計算reward \(r_i = r (\theta_t + \sigma \varepsilon_i),\space \text{for}\space i = 1, \cdots, n\)
  • \(\theta^{t+1} = \theta^t + \alpha \frac{1}{n\sigma}\sum_{i=1}^nr_i\varepsilon_i\)

在工程實踐中,該方法常常面臨如何權衡reward的問題。以短視頻推薦場景為例,我們常常關註單次屏幕刷新中的平均播放時長、產生交互行為(喜歡、關註等)的比率,那麼我們就有以下兩種結合方式:

\[\begin{aligned} \text{reward} &= \alpha \cdot \text{avg}\_\text{time} + \beta \cdot \text{interaction}\_\text{rate} \quad (1) \\ \text{reward} &= \text{avg}\_\text{time}\cdot (1 + \alpha \cdot \text{interaction}\_\text{rate}) \quad (2) \\ \end{aligned} \]

在實踐中,通常reward \((2)\)的穩定性更高。

我們進一步分析,這是一個多峰優化問題,很容易造成不同業務指標之間的此消彼長(也就是所謂的“蹺蹺板效應”),從而陷入局部最優,導致效果不盡如人意。

當發生蹺蹺板現象時,我們可以將部分reward進行進一步拆分,比如將interation_rate拆分為like_rate和follow_rate兩個不同的指標:

\[\text{reward} = \text{avg}\_\text{time}\cdot (1 + \alpha \cdot \text{like}\_\text{rate} + \beta \cdot \text{follow}\_\text{rate})\\ \]

可見,在reward的優化中,我們一直在規避不同重要指標之間的置換現象,及時調整reward的形式,不斷追求理想情況(也就是Pareto最優狀態)。

上述的這種進化策略演算法我們一般稱為自然進化策略(natual evolutionary strategy, NES)演算法。除了上述這種NES演算法之外,愛奇藝還提出可以採用啟髮式的粒子群優化(particle swarm optimization, PSO)[5][6]演算法來離線搜索融合參數。該演算法本質上也屬於一種進化策略演算法(不過不同於NES演算法的線上特性,PSO演算法是離線的),旨在從個體構成的群體中採樣並讓其中成功的個體來引導未來後代的分佈。

PSO演算法通過初始化一群隨機的粒子,啟髮式地進行多次迭代來求出最優解。每一次迭代中,粒子通過個體極值(該粒子所經過的歷史最優解)和群體極值(種群找到的最優解)來更新各自的位置。這樣,最終所有的粒子會兼顧個體的歷史最優解和群體所共用的全局最優解直至收斂。

最後,上面我們介紹的都是朴素的進化演算法,缺乏進化的穩定性和自動調節學習率的特性。所以,人們又提出了利用協方差矩陣自適應策略(covariance matrix adaptation evolutionary strategies, CMA-ES)進一步提升多目標融合模型的能力。感興趣的讀者可以參見文章《新聞資訊混排場景下的多目標融合實戰(四)》[11]

參考

數學是符號的藝術,音樂是上界的語言。
您的分享是我們最大的動力!

-Advertisement-
Play Games
更多相關文章
  • 正常上下文在複製一個一模一樣的上下文 appsettings.json添加兩個資料庫連接字元串 Program.cs裡邊一樣添加兩個 控制台遷移命令 必須加上-Context 後邊跟的是我們上下文的名稱 Add-Migration MyMigration -Context MYDBContext22 ...
  • 引言 近期我們註意到很多學生朋友通過郵件嚮導師申請報名,請註意!!!​這是無效的,請必須通過“開源之夏”官方後臺申請報名,請仔細參考這篇【報名攻略】 所以,我們特此舉辦這次宣講會,目的是向所有感興趣的學生詳細介紹Apache DolphinScheduler社區在開源之夏中提供的項目,並且解答學生朋 ...
  • Percona Toolkit 神器全攻略 Percona Toolkit 神器全攻略系列共八篇分為 文章名 文章名 Percona Toolkit 神器全攻略 Percona Toolkit 神器全攻略(實用類) Percona Toolkit 神器全攻略(配置類) Percona Toolkit ...
  • 本文分享自華為雲社區《MySQL全文索引源碼剖析之Insert語句執行過程》 ,作者:GaussDB 資料庫。 1. 背景介紹 全文索引是信息檢索領域的一種常用的技術手段,用於全文搜索問題,即根據單詞,搜索包含該單詞的文檔,比如在瀏覽器中輸入一個關鍵詞,搜索引擎需要找到所有相關的文檔,並且按相關性排 ...
  • 前言 來整理一下緩存雪崩、擊穿和穿透的問題,這個問題在面試中常出現,不是瞎說,我已經遇到幾次了 一、緩存雪崩 1.雪崩 什麼是雪崩,某度給出的解釋 雪崩 當山坡積雪內部的內聚力抗拒不了它所受到的重力拉引時,便向下滑動,引起大量雪體崩塌,人們把這種自然現象稱作雪崩。 說白了就是一部分雪因不可抗力出現問 ...
  • 創建表時應當設置not null,添加一個預設值0或''去替代null。 sum('field')的坑 若一列的所有值都是null,那麼sum函數的結果不是0,而是null,所以可能會因為值的類型相容問題,出現意料之外的情況。 null值會有NPE問題。 count('field')的坑 有null ...
  • 哪些場景下MySQL會使用索引查詢數據,哪些場景下MySQL不會使用索引查詢數據,以及如何使用索引提示來告知查詢優化器使用索引、忽略索引和強制索引索引。 ...
  • 本文首發於公眾號:Hunter後端 原文鏈接:MySQL面試必備三之事務 這一篇筆記介紹一下 MySQL 的事務,面試中常被問到關於事務的幾個問題如下: 事務是什麼 為什麼需要事務,事務有什麼作用 事務的特點 事務可能帶來哪些問題 事務有哪些隔離級別,這些隔離級別都可以解決哪些問題 可重覆讀隔離級別 ...
一周排行
    -Advertisement-
    Play Games
  • 移動開發(一):使用.NET MAUI開發第一個安卓APP 對於工作多年的C#程式員來說,近來想嘗試開發一款安卓APP,考慮了很久最終選擇使用.NET MAUI這個微軟官方的框架來嘗試體驗開發安卓APP,畢竟是使用Visual Studio開發工具,使用起來也比較的順手,結合微軟官方的教程進行了安卓 ...
  • 前言 QuestPDF 是一個開源 .NET 庫,用於生成 PDF 文檔。使用了C# Fluent API方式可簡化開發、減少錯誤並提高工作效率。利用它可以輕鬆生成 PDF 報告、發票、導出文件等。 項目介紹 QuestPDF 是一個革命性的開源 .NET 庫,它徹底改變了我們生成 PDF 文檔的方 ...
  • 項目地址 項目後端地址: https://github.com/ZyPLJ/ZYTteeHole 項目前端頁面地址: ZyPLJ/TreeHoleVue (github.com) https://github.com/ZyPLJ/TreeHoleVue 目前項目測試訪問地址: http://tree ...
  • 話不多說,直接開乾 一.下載 1.官方鏈接下載: https://www.microsoft.com/zh-cn/sql-server/sql-server-downloads 2.在下載目錄中找到下麵這個小的安裝包 SQL2022-SSEI-Dev.exe,運行開始下載SQL server; 二. ...
  • 前言 隨著物聯網(IoT)技術的迅猛發展,MQTT(消息隊列遙測傳輸)協議憑藉其輕量級和高效性,已成為眾多物聯網應用的首選通信標準。 MQTTnet 作為一個高性能的 .NET 開源庫,為 .NET 平臺上的 MQTT 客戶端與伺服器開發提供了強大的支持。 本文將全面介紹 MQTTnet 的核心功能 ...
  • Serilog支持多種接收器用於日誌存儲,增強器用於添加屬性,LogContext管理動態屬性,支持多種輸出格式包括純文本、JSON及ExpressionTemplate。還提供了自定義格式化選項,適用於不同需求。 ...
  • 目錄簡介獲取 HTML 文檔解析 HTML 文檔測試參考文章 簡介 動態內容網站使用 JavaScript 腳本動態檢索和渲染數據,爬取信息時需要模擬瀏覽器行為,否則獲取到的源碼基本是空的。 本文使用的爬取步驟如下: 使用 Selenium 獲取渲染後的 HTML 文檔 使用 HtmlAgility ...
  • 1.前言 什麼是熱更新 游戲或者軟體更新時,無需重新下載客戶端進行安裝,而是在應用程式啟動的情況下,在內部進行資源或者代碼更新 Unity目前常用熱更新解決方案 HybridCLR,Xlua,ILRuntime等 Unity目前常用資源管理解決方案 AssetBundles,Addressable, ...
  • 本文章主要是在C# ASP.NET Core Web API框架實現向手機發送驗證碼簡訊功能。這裡我選擇是一個互億無線簡訊驗證碼平臺,其實像阿裡雲,騰訊雲上面也可以。 首先我們先去 互億無線 https://www.ihuyi.com/api/sms.html 去註冊一個賬號 註冊完成賬號後,它會送 ...
  • 通過以下方式可以高效,並保證數據同步的可靠性 1.API設計 使用RESTful設計,確保API端點明確,並使用適當的HTTP方法(如POST用於創建,PUT用於更新)。 設計清晰的請求和響應模型,以確保客戶端能夠理解預期格式。 2.數據驗證 在伺服器端進行嚴格的數據驗證,確保接收到的數據符合預期格 ...