2018年5月11日至13日，騰訊WeTest與Unity聯合打造的移動遊戲性能分析工具（Unity Performance Analysis，以下稱為UPA）正式亮相2018 Unite大會，為Unity手遊開發者提供更加深度的遊戲性能優化、測試服務，帶來了更多產品測試與優化的“新姿勢”。

會上，Unity大中華區企業支持經理&UPA開發工程師高川先生、騰訊遊戲性能優化工程師 & UPA開發工程師徐森先生代表UPA團隊，為開發者們帶來了題為“使用UPA工具優化項目”的分享演講。

Unite大會技術專場演講現場

以下為演講實錄

徐森

大家下午好，今天和大家分享一下使用UPA工具優化項目的經驗。

大家在看到這個題目的時候可能第一時間想到的就是說UPA是什麽東西？所以由我先為大家分享一下工具的起源或者說我們為什麽做這樣一款工具？我這邊是負責遊戲性能的優化工作，所以在騰訊碰到很多遊戲優化的案例。時間是遊戲的生命線，大家知道手遊的生命周期比較短，一款成功的手遊大概2到3年已經很可以了，所以說在這麽短的時間內我們需要把一個遊戲的功能性能做到最好，其實這是非常耗時間的操作，所以大家可能平時加班比較多一點，這也是沒有辦法的事情。

騰訊遊戲性能優化工程師 & UPA開發工程師 徐森先生

這麽一個大前提下我們說性能優化這個工作既重要也不是很重要，首先它很重要，這是大家玩遊戲的過程中都有體會，如果遊戲性能優化不好會出現很多問題，比如玩起來卡，閃退或者掉線，這個會導致用戶流失掉。這是做性能優化很重要的方面。為什麽說它不重要？因為一個遊戲的項目組裏面最多的同學可能做功能開發或者做美術，或者做發行做運營。其實一個項目組裏面專門針對性能優化的人員非常少，一個遊戲可能一到兩個人左右。這麽有限的時間把所有的性能優化好，顯然不可能。我們這邊進行遊戲優化的過程中，最重要的需求就是高效，我們一定在最短的時間內利用最少的人力，幫助我們發現並且解決掉我們遊戲可能產生的一些性能問題。

那麽說到這裏有這樣一個想法，我們可以做這個工具幫助我們高效的解決性能問題，所以這是我們UPA這個工具產生的前提條件。所以這個標題是效率，我們工具其實主要是幫助我們提升性能優化的效率工具。那麽有了目標以後我們考慮怎麽根據目標進行產品的開發，首先第一點為什麽強調是Unity和騰訊合作開發的產品，因為我們覺得做這個工具它的前置條件很多，首先對底層的工具了解，後面對遊戲測試或者遊戲開發中的流程或者規範非常的清楚，可以幫助我們使用人員更快的上手工具，同時這個工具更有針對性。

所以說Unity扮演一個專家角色，對於我們底層的代碼負責了解。那麽騰訊這邊扮演一個偏向於使用者的角色，我怎麽設計這個工具，才能最大程度的提高使用人員的效率。所以這是兩個前提條件，導致我們兩邊進行合作產品。這個產品最主要的就是，這邊寫的可能比較繞口，基於四無產品概念的非侵入式測試。什麽意思？解釋一下四無，首先第一個我們被測的遊戲不需要接入SDK，第二測試機不需要其他的權限，第三測試時候不需要上傳被測的應用，第四測試的時候不需要Unity的開發環境。

其實有了四無的概念以後，這個工具在任何場合，只要大家有一款手機，有我需要測試的應用就可以拿到這個工具進行測試了。其實非侵入式我覺得可能是對我們之前的四無的補充，因為我們知道現在很多市面上流行的一些測試產品，在PC端還好一點，那麽在手機端可能需要一些很苛刻的Root權限，很苛刻的限制，所以我們強調非侵入式，相當於它的優點。

講完了主要的以後下面還有一個，其實是全自助式的測試模式，這是針對使用的用戶來講，這樣一款工具我們是完全開放給用戶自主使用。我可以在任何時間任何地點，當然在家也可以測，任何時間任何的測試的手機上，可以測試我任何想要的場景，其實這麽一款遊戲測試工具跟玩遊戲的場景其實差不多。

那麽說了這些大家可能關註到這個工具會有什麽樣的特點？其實很多工具功能我們都是為了彌補我們當前測試工具的不足來針對性的開發。大家可能平時會使用很多性能優化工具，相信大家使用過程中也會感覺有這樣或者那樣的不太好用的地方。

我們可以列舉一下目前市面上比較流行的一些性能優化工具。最常接觸的可能就是Unity Profiler，它是嵌在界面中大家用起來最方便，開發的時候就順手拿過來，這個是Unity官方推出的，所以有很多好用的地方，比如采集的數據分類非常明確，到底是CPU或者GPU數據或者內存數據或者物理數據，我可以看到問題出哪兒。還有其他的優勢，比如說裏面的數據是用曲線展示的，可能可讀性會好一點，並且數據是從引擎官方內部采集的，所以數據可靠性比較高，不會出現誤報的情況，這個就是Profiler本身的優點。

有優點就有缺點，其實平常我們在和用戶溝通過程中，經常聽到用戶的吐槽。比如說Profiler界面顯示的數據有限，同一時間有500幀，現在不太清楚，可能會有一些提高。這可能是不太好用的一點，還有另外一點Profiler的數據雖然分類比較明確，但是讀起來有些難讀，比如說會有一些函數的名字還有模塊的名字，單看名字可能不理解這個東西是什麽東西，可能還要上論壇上面求助或者Unity的專家去求助，才能大概知道這是什麽意思。

還有一個問題其實Unity統計數據是從軟件層面來統計的，那麽深入不到硬件層，最明顯的例子就是不支持的GPU的型號讀不到裏面的硬件數據，CPU也是讀不到，這些數據對優化問題還是很重要的。剛才說到Unity提供的Profiler工具，其實很多硬件上面我們的硬件廠商也有提供一些Profiler工具，比如IOS和安卓上面都有工具。這些硬件廠商提供的工具會有什麽優點？他們這些數據的統計和他們的硬件強相關，可以深入到硬件層。那麽這樣子的話，統計的數據非常的全面，從軟件到硬件層都有，並且他們的可靠性非常高。

但是硬件層的數據有一個明顯的缺點，就是它的可讀性不是很強，我經常可能看到一些內存地址的數據對不上我自己寫的代碼，這樣導致工具使用門檻很高，非常有經驗的人才可能從工具中發現一些問題。

說完了硬件，隨著Unity在國內使用的幅度越來越大，其實很多第三方的Profiler工具也會提供出來。比如商店裏面可能有一些性能優化的插件，第三方工具的好處在什麽地方？首先第三方工具相當於是針對我們的遊戲開發者進行開發的，所以使用方面還有數據可讀性方面，比一般的工具強一些的。但是也不是沒有問題，因為很多第三方的工具開發商，之前可能也是Unity引擎的使用者，他可能對引擎底層的技術不是很了解。那麽功能的一些更新可能很滯後，並不一定兼容最新Unity的版本，還有數據解讀有一些誤解，可能誤導我們對這個數據的理解。

這個是我們在平常現有一些Profiler工具會產生的一些缺點，當然嚴格來說我們UPA是一個第三方的工具，但是我們和Unity合作所以可以避免一些第三方工具出現的一些典型的問題。這個合作還有一個比較重要的一點，其實我們是除了工具的可用性以外，其實我們想做一些數據分析以及整理，也就是說我們把Unity和騰訊在性能優化過程中積累的經驗還有數據標準共享給大家，幫助大家比較快速的發現我們這個遊戲到底哪個方面存在性能問題，並且可以方便的優化它，這是這個產品，相當於一些特點或者它想針對的目標。

有了這個產品之後大家可能就會想到這個產品應該怎麽用？在平時的開發或者測試過程中應該怎麽用這個產品才能更大化的發揮它的效果。其實這個產品我們在平時的推廣過程中也積累了一些使用場景，可以跟大家分享一下。首先第一個是數據采集者和數據分析者，其實對於這個產品來說我們數據采集的人員和數據分析的人員可以不是同一個人，我們知道之前的Profiler工具可能都是，我那些做性能優化的同學自己用，自己采集數據看這個數據然後優化這個問題。

那麽有了這個UPA的工具以後，其實這個角色可以分兩個部分。首先第一部分是我們的數據采集人員，這個可以交給我們的外包或者測試同學來做，剩下的開發人員做功能就好，等到他們跑完了我們指定的場景或者指定的機型數據以後，可以把我們采集的數據或者生成的報告拿到專門負責性能優化的同學那邊，其實省了我們平常可能是一些問題或者是采集數據的時間。這是第一點。

第二點因為我們報告采集以後是存在雲端的，所以這個報告可以進行任意應該的分享。比如我們可以分享給我認識的一個比較厲害的大牛，我可以請他給我看一下這個報告有沒有問題？如果這個問題我解決不了的話。可以分享我們Unity的專家，請他們看一下這個報告減少我分析報告的成本。當然分享給專家以後如果我們有采購Unity的駐場支持，他們在駐場的時候可以看一下報告減少他們的駐場時間。

還有應用比較多的場景，我之前已經發現類似的問題並且已經進行優化，這個時候看一下優化效果怎樣，這個問題有沒有被真正的解決，這個時候可以跟我之前沒有進行優化的報告進行對比。那麽兩邊的數據對比以後我可以很明顯的發現，這個數據是不是恢復正常？這個代表我之前做的優化效果是不是有效。

最後一個也是我們最近在推廣過程中碰到的一些項目的使用，項目組使用這個工具做自動化測試的工作，為什麽做這個？因為自動化測試應用面比較小，因為如果是做功能的自動化，那麽這些自動化過程中出現的問題可能我並不一定能夠自動化的發現。如果自動化跑一個遊戲中間突然花屏，有一些角色的渲染不太正常，或者有些文本顯示不對，這個時候很難通過自動化的方式來發現，我跑自動化的時候可能還需要人來盯著這個東西。看一下這個跑的過程中有沒有問題。

那麽這樣的話自動化測試的效率其實很低，當然我們剛才說是功能自動化，如果做性能自動化的測試的話，之前大家可能采集一些幀率或者內存這種指標。那麽雖然有了這些指標，自動化測試可以幫助我發現一些問題，但是自動化工作能夠做的工作到此為止，接下去我們又回到之前的數據優化的這麽一個老套路。有了這種性能采集的工具以後，如果結合自動化的測試我們可以在每次自動化的時候，采集一些性能數據。然後通過測試結果的對比我們可以發現一些潛在的性能問題。

比如說一個函數它的時間可能每個版本都會增加10%或者5%，雖然可能一兩個版本看不出來問題，但是等真正上線的時候這個問題已經成為一個問題，到時候我們再花時間進行優化，那麽效率就會比較低，所以我們自動化測試的時候，提前幫助我們發現一些問題。

這是我們使用UPA的場景，說到這裏大家已經對這個工具有一點好奇了，這個工具到底什麽樣的？能達到什麽效果？或者能夠幫助我們解決什麽問題？下面我們請Unity的支持工程師高川同學幫助我們詳細的演示一下這個工具的使用方法還有典型的使用案例。

高川

大家好！我是來自Unity的高川，下面演示一下日常如何使用UPA以及我們用UPA發現具體項目的具體問題。

在正式開始講之前打一個廣告，我們現在Unity在招現場支持工程師，如果你想更多的接觸一些客戶解決一些非常尖端的難題，歡迎加入我們，這是我們的地址以及二維碼。

接下來我們講一下怎麽使用UPA。UPA分成兩個部分，我先問一下在座的各位有誰之前使用過UPA？UPA由兩個部分組成的測試系統，一部分是我們手機上的客戶端，裝在手機上的，還有一部分是我們的網站，首先各位在手機的客戶端去下一個我們WeTest的助手這樣一個軟件，通過這個軟件我們可以啟動測試，下載之後登錄之後會看到這樣的界面。

Unity大中華區企業支持經理&UPA開發工程師 高川先生

我們可以看到有幾項，一般來講就是第一項，我們選擇UPA，進入之後進這樣一個界面，這個界面裏面我們可以看到有這樣幾個選項，第一我們要求用戶選擇一下你們測試哪個Application，然後下面有三個選擇，第一個是性能分析，後面是資源分析和MONO內存分析，報告所屬你可以對報告進行分組，Unity版本，我們會有5.6以上和5.6以下版本，截圖這個讓用戶理解你測試過程中究竟發生了什麽。為什麽做成開關？因為我們知道有些公司對於項目的截圖比較敏感，所以這個截圖是關閉的，如果有需要一定打開，這個對於你自己或者你的朋友或者其他的專家來閱讀和解析整個報告是非常重要的。

你選擇所有的東西之後點開始測試，你的Application拉起來，你可以玩遊戲一樣開始你的測試，測試時長沒有限制，我們一會兒可以看一下我們的案例測試。這是我們的Demo報告，這是用Unity的AngryBots做的測試，上面有一個報告是合格還是不合格還是警告，同時收集一些Application信息，你的CPU性能情況，使用什麽手機測試，基於騰訊後臺大數據我們對手機進行分類，屬於高配中配低配。然後下面是一堆列表，大家比較關註幀率、MONO的內存、紋理、網格，包括Tris在這裏有一目了然的展示，我們也會用顏色來區分。這些報告，由於大部分人對自己的遊戲很了解，看這兒可能結束了，因為所有的問題列這兒，你可能不需要放其他的數據或者再分析，可能有時候這個地方發現一些非常直接的問題，然後開始著手解決。

再下面是我們建議的這樣一個關註點，包括一些模塊的耗時這樣一個排列，這是概況頁，然後下面我們對CPU內存圖形渲染三個方面進行分析。大家比較關心CPU使用情況，如果看截圖非常清晰的知道這一幀在幹什麽。所以會有比較清晰的對比。最上面是我們的性能的摘要報告，包括你的耗時的平均，以及物理的耗時平均。再下面我們看到這是一個主的TimeLine，這個上面是采集每一幀的數據的采樣點，我們可以針對某一幀進行放大，這一幀裏面可以看到整個耗時，Rendering耗時非常凸顯，我們可以一幀一幀的展開，看一下每個函數的耗時是什麽。

再下面是我們的建議，雖然這裏比較凸顯，但是整體沒有太大，我們Unity的Demo優化很棒，這真的沒有太大問題，我們一會兒可以看到相對優化不那麽好的項目。再下面是對於對象激活統計，大家知道Unity裏面這兩個操作是非常耗時的操作，每次都有樹的傳遞，你的腳本有操作，這個傳遞非常慢，尤其是UI。比如人物頭頂的billboard，我們在有的項目裏面就會看到這個耗時是非常凸顯的狀況。我們和項目的優化過程中我們經常看到，有一些非常集中的實例化會導致卡頓，一會兒我們的案例也有相關的內容。下面我們會看到有一個內存方面的報告。

這是內存的報告，首先我們可以看到Mono，在這裏有非常頻繁的產生，一會兒案例中會看到非常明顯的內存使用的問題。然後是動畫、音頻、材質、網絡的細分展示，在圖形裏面我們關註關註Draw Calls，再下面是Verts和Triangles，它加載某一些模型的時候加載策略不合適，所以把無用的模型統統加載進來。再下面是VRAM的值，這個值是一個估算值，所以給大家做一個參考，再下面是VBO的統計，以及這一幀裏面更加詳細的數據使用。

還有一個模塊是我們的合批模塊，我經常被問一個問題，要不要開通靜態合批和動態合批，我們知道它對CPU產生一定的壓力，或者對內存產生一定的壓力，所以我們給的答案是能或者不能，大部分的答案是試試吧，所以我們通過合批想幫助大家解決這個問題。其實這裏最重要的是黃色曲線，你通過開啟動態合批為你省掉多少，如果這個曲線非常高，說明你的動態合批做的非常好，你可以付出相對比較小的代價獲得比較大的收益，但是反之你不應該開它或者進行材質和渲染順序之間的調整。這個稍後我們也會在案例裏面看到一個非常明顯的例子。還有我們認為渲染方面非常耗時的，這是大家平時做項目的時候遇到耗時非常尖峰的地方，所以我們提出來讓開發者重點關註一下。

下面看一個案例，這個案例是騰訊的真龍霸業，這是早期的版本，我們看上完了是紅通通不通過，真龍霸業的同學比較擔心，它是在米4測的，它的平均幀率只有10幀，紋理資源是80多兆，峰值已經達到500。我們看一下問題建議，首先FPS均值很低，邏輯腳本高於渲染，這是我們看項目的時候，90%的項目都有這個問題，GC頻率9.42次，然後是Canvas，還有就是紋理消耗比較高。我們看一下模塊耗時，這個函數比較有意思，一會兒可以重點看一下這個東西應該幹什麽，它不僅會產生比較高的耗時，同時會產生比較高的GC alloc。

我們看一下GPU，我們看很多項目大多數的曲線是鋸齒，在下面不停的抖，這個曲線是遊戲平均幀率比較低，而且出現偶爾的卡頓，就是不流暢。但是這種曲線玩家的體驗會停頓，所有的紅色的曲線玩家感覺非常明顯的停頓而不是卡頓。因為用UPA測試的時候版本比較早，所以沒有做截圖功能，所以打了一個Tag，我們看一下典型意義，比如紅通通的，有4幀，第94幀是耗時非常高的一幀，這一幀是在幹什麽？耗時最高是這個函數，這是你的UI在加載一個滾動列表，你加載一個過大的滾動列表，所以這一幀之內大家可以看到它已經是非常誇張的值。而且這一幀裏面僅僅一個函數就400，所以這就是明顯的停頓而不是卡頓。

我們再看這個，從名字可以猜出來是第一個場景已經加載，這裏有很多加載過程和初始化過程，所以導致這一幀的加載大概400多，這個意味著什麽？如果這是一個等待的場景還好，如果這是遊戲中的動態加載，玩家會卡將近一秒鐘的時間，因為這兩個函數卡一秒鐘，這是難以忍受的。

所以我們給項目組提的優化，第一個向滾動列表我們需要進行少量加載，可以把時間分開，同時第一次進場景的時候檢查是不是某一幀做了過多的事情，導致CPU卡了非常非常多的時間。129幀也是類似的問題，我們可以看到有一個Loading，我們裏面又看到了很多的等待這邊，它的耗時非常高，這時間開發組開發的時候沒有考慮同一幀裏面CPU的負擔，而簡單粗暴同一幀裏面把所有的加載任務放一幀裏面。這是我們給項目組做優化的時候看到一個通病，因為大家會基於項目時間或者管理成本或者代碼，在加載的時間管理和CPU的時間管理做的不是那麽細致，所以經常有粗放的大列表加載，一開始這樣做沒有問題，但是隨著項目增長，這個地方的瓶頸會慢慢的凸顯出來。所以我們建議他們初期或者中期做規劃的地方，對於提前加載的地方布局一些措施，比如進行監控進行表的自動化篩查，以及提早做分幀加載，這些都是經驗上的東西。

我們看一下內存，內存非常有意思，可以看一下總內存大概占將近500兆，這個內存已經非常高，我們看一下Mono Reserved，我們可以看一下，前面幾幀的內存比較有意思，前面都是紅線，這意味著什麽？從系統層面來看，系統看到綠色的，綠色過高系統就會回收，這是時簡單粗暴的說法。那麽紅線是你使用的，對於Mono的內存池來講，你使用內存不夠，它分配新的內存拓展內存池，供遊戲進一步的使用。我們可以看到前面這個是一個合理的，因為綠色上漲的同時紅色也在上漲，這個地方比較有意思，大家可以看到這個地方紅色是下降，但是綠色反而上漲，包括後面也是非常大的上漲，這一幀的時候紅色有不太大的上漲，但是綠色有非常大的上漲。

我們經常看到非常典型的，第一個就是這樣，我們知道Mono頂上去非常難以下來，所以盡量控制尖峰不要頂高，另外是沒有突破綠色反而上漲的曲線。Mono是無壓縮的內存池，它一直不停的分配，分配大的時候首先找裏面有沒有可以供你用的。我們可以看到項目裏面GC非常多，意味著大量分配小碎片內存，最後導致內存碎片化嚴重，你分配相對大一些的內存，你的內存池已經沒有地方可以分配出這樣的內存，所以就申請新的內存。所以這個項目在後期浪費非常嚴重，大家可以關註一下大概有10兆左右，有10兆內存已經被分配，但是項目根本不會用到。所以大家優化的內存的時候，並不是只考慮我盡量減少分配，同時考慮分配內存的連續性。

所以有一些項目裏面建議用戶先分配大內存，再分配小內存，先分配大內存使用之後釋放掉，然後用大內存的小內存進行碎片。還有一種方式我們Unity這邊也在嘗試升級Mono的虛擬機，下一代的虛擬機可能比較好的解決內存碎片化的問題。但是還是那句話，再優秀的機制也抵不住亂寫的代碼，所以開發上要有一定的節制，如果不節制什麽機器也抗不住。這個項目比較有意思的就是它的紋理，80多兆的紋理內存，為什麽？因為這個東西本身不大，但是它是一個2D遊戲，開發組當時為了加載速度問題，把所有的紋理加進來不釋放。

從目前它的數據來看這種策略對於他們項目來說有一點危險，因為整體內存非常高，但是並不是把紋理加載進來不釋放這個事兒不能做，只是這個項目裏面我們覺得不太合適，所以我們建議他們適當的地方去釋放一些內存，對於紋理進行一些更細致的加載。同樣這個問題也是非常常見的問題，還是由於開發周期以及人員叠代，導致資源和內存管理上非常粗放，到了後期我們發現內存是幾何級的增長，我們之前遇到很多用戶後期找到我們我有很多很多奇怪的現象，到底是為什麽？我們到了現場之後發現七八十是由於內存爆掉了，但是他們不會意識到這個問題，因為他們是在線上，線上抓回來的不會告訴你是內存，所以內存會導致非常撓頭的問題。

所以大家進行管理內存的時候，雖然做資源管理內存管理是非常細致的活，它必須貫穿整個項目，但是這樣的收益一定是非常大的，千萬不要在項目前一個月發現內存抗不住了，然後找美術找GD，據我們接觸的項目這樣的問題不在少數，這是給開發者一個建議，這是我們做UPA的初衷，幫助大家盡早發現風險，把風險消滅在萌芽狀態。

還有一個是圖形，大家看上面有兩個0，他們不是沒開，真開了，但是開了之後這邊合不掉什麽東西，因為他們的材質非常非常復雜，所以我們的建議要麽關掉，要不優化一下你的材質的使用。所以通過這個工具我們可以很好的回答我們之前沒法回答的問題，我們要不要開？我們直接告訴開發者你的情況是這樣，你自己決定優化或者不開，省掉這部分的CPU消耗。

由於時間關系我們案例先分享這些，如果大家有興趣的話一會兒交流之後可以到外面的展臺來跟我們工程師進一步交流。關於WeTest我們後面做什麽東西，我請徐森繼續介紹一下。

徐森

其實大家了解這個工具以後，其實可以看到這個工具目前還是處於一個比較初級的階段，因為可能很多人心裏都有一個問題，對於數據來說我們並不是說打算采集一些更深入或者更詳細的數據，其實能采集的大概都已經采集光了。其實我們想做的我總結下來是一個收集和分享的功能，我們通過收集很詳細的性能數據，然後集合我們平時在遊戲測試過程中，遊戲優化過程中的經驗還有Unity他們駐場的經驗，然後總結出來一些常見的性能問題，並且常見的優化方案，最後把這些問題和優化方案通過我們自動化報告分析的方式分享給大家，大家看到這個報告以後可能就會很快的知道我到底是哪部分出了問題，這個問題怎麽改，這是我們做這個工具最想做的方面。

但是目前來看可能只是針對一些比較初級的問題，比較初級的方案，如果真的是詳細的問題，可能具體項目具體分析。所以我們也不會搶了Unity專家的服務的市場。另外一個比較重要的問題，大家用測試工具過程中發現雖然數據拿到了，但我可能做二次分析，比如算一個平均幀時間，這是一個非常常用的功能，但是在Profiler裏面辦不到，因為它只是數據展示，沒有做數據分析和數據對比，這是我們想做的，未來我們把報告數據的方式提供給大家，方便大家下載下來進行分析，這也是平時做性能優化方面工作很需要的。

還有一點就是我們可能也會考慮做一些現在這些市面上Profiler工具沒有的功能，現在我們會提供一些快照對比的功能，大家可以嘗試一下，最終希望通過UPA這個工具把大家平時在工作過程中積累的經驗碰到的問題進行整合分析，幫助大家提高性能優化效率，這會是我們的發展方向。

今天就分享這些，謝謝大家！

若有任何疑問，歡迎在公眾號留言給我們或聯系WeTest企業QQ：800024531進行問詢。

點擊http://wetest.qq.com/cube/，WeTest UPA邀您體驗。進入UPA體驗頁面，認證用戶即享UPA - 60分鐘使用時間。

2018 Unite大會——《使用UPA工具優化項目》演講實錄