近日，有部分iPhone14Pro和ProMax用戶反映在使用相機App時遇到了問題，具體表現在相機打開時可能需要幾秒鐘才能加載完成。還有部分蘋果iPhone14Pro系列用戶稱，第三方App使用相機時出現了畫面模糊和抖動問題，同時伴隨著物理的嗡嗡聲。Snapchat、TikTok和Instagram等流行的第三方App都出現了該問題。
問題描述：受影響的用戶稱，在點擊相機應用圖標后，相機需要四到五秒才能激活。此外，該問題是在相機已經打開后出現的，也就是開啟相機后，將其放到后臺，再點擊相機圖標打開，就會出現加載延遲。
據測試，這個問題只會在iOS16官方相機App的拍照模式下偶現，視頻模式下沒有問題，且不影響第三方App，不過重啟、重置等操作都無法解決。
解決辦法：iPhone14Pro相機打開慢可能是相機App的內存管理出錯。我們可在輔助功能中清除iPhone14Pro系列的內存，清除以后相機App即可正常啟動，但此方法并不能徹底解決這個問題，再次使用時問題還會再現。
針對iPhone14Pro相機打開慢，第三方App使用相機出現抖動等問題，蘋果稱將在進行軟件更新修復，希望新版本能一次把這些問題全修復好。
背景介紹：本人原先是android逆向工程師，后來因為工作變動，離開了協議分析這類的崗位，目前在做直播機與第三方應用兼容性分析相關分析，所以就有了這篇兼容性分析文章。
問題：tiktok在我們推流設備直播時，經過幾個特定步驟后切換前后置攝像頭會出現卡住的問題。
現象：直播畫面卡住不動了。
解決思路：找到點擊切換按鈕后的點擊事件回調，找到切換攝像頭的核心邏輯，來找到卡住原因。
1、如果了解ART虛擬機的同學會知道，jni函數和java函數都會調用到art虛擬機ArtMethod的Invoke函數。

輸出日志：
find target method: android.view.View.performClick
ArtMethod Invoke【22955】: ; lr:0x4af78c; libart.so: android.view.View.performClick
ArtMethod Invoke【22955】: ; lr:0x2e2800; libart.so: java.lang.Enum.toString
ArtMethod Invoke【22955】: ; lr:0x2e2800; libart.so: X.Ggh.LIZ
ArtMethod Invoke【22955】: ; lr:0x2e2800; libart.so: java.util.LinkedHashMap.<init>
ArtMethod Invoke【22955】: ; lr:0x2e2800; libart.so: java.util.HashMap.putAll
ArtMethod Invoke【22955】: ; lr:0x2e2800; libart.so: java.util.HashMap.put
ArtMethod Invoke【22955】: ; lr:0x2e2800; libart.so: X.DED.LIZ
ArtMethod Invoke【22955】: ; lr:0x2e2800; libart.so: X.D5k.onClick
通過frida hook libart.so的ArtMethod的Invoke函數，我們找到了點擊事件的回調類X.D5k.

找到這個類對應的onClick函數后，我對整個流程做個簡單的研讀，感覺發現了核心代碼在注釋直播流處理。

跟著核心代碼一路往下找到LiveCore這應該就是直播的核心代碼，其實現類為LiveCoreImpl，ILiveStream的實現類為LiveStream。


發現此處只是做了日志信息的合成和應用鏡像之類的代碼，但是又找到一個核心的類LiveStreamVideoCapture。

追蹤到這里發現鏈路斷了，又湊巧通過frida打開tiktok卡死在啟動頁上，那么接下來使用Xposed繼續理流程。
上面的代碼雖然沒有追中到切換攝像頭的核心邏輯，但是我們找到了兩個核心邏輯的類LiveStreamVideoCapture和LiveCoreImpl，分別和直播視頻流控制直播核心流程控制相關，所以Xposed繼續走的時候以這兩個類為重點，那么此處就開始放大招了，hook這兩個類的所有函數，貼上代碼。注意這里使用的classloader是application的classloader。


日志太多了，這里通過shell命令setprop做了個日志控制。



然后找到CameraVideoCapturer類的tryDeliverFrame，這里是處理相機的視頻幀，感覺越來越接近真相了，繼續hook這個方法，然后發現相機切換卡住以后，這個方法也停止調用了，那么沒辦法，繼續往上找堆棧中run方法的調用調用處。

繼續hook。


找到這個類。

至此，熟悉相機開發的同學應該知道，這就是SurfaceTexture.setOnFrameAvailableListener后，相機的可用幀會回調到這個函數，切換相機后卡頓，可用幀也同時不回調。
接下來hook原生相機。



調用的是android.hardware.Camera，也就是camera1相關的api，切換卡頓的時候并沒有調用Camera.open函數。


首次開直播的時候調用了這兩個函數，點擊切換相機的時候并沒有調用，在X.HCF這個類里找到switchCamera函數，那么猜測首次開相機，和切換前后相機走的并不是同一個流程，因為這個bug只有在切換相機時才會出現，所以我們就不關注首次開相機的流程。


果然，切換相機的時候走了這個流程，這是又發現了LiveStreamVideoCapture這個核心類，那么簡單進去看看SwitchCaptureRunnable這個有沒有被創建。


經過測試，發現這個類只會被創建一次，而run方法每次切換都會被調用，而且卡住的情況下也會被調用，那么結合上面Camera.open卡住時沒有調用，可以大膽的猜測中間過程某個條件不滿足被return了。根據堆棧信息繼續往下找幾個關鍵點。


發現CameraVideoCapture里也有切換相機的流程，切一步步往下走，能調用到上面我們hook過的X.HCF的switchCamera，那么我們就看看這里的switchCamera有沒有調用吧。
•情況一：先滑動直播界面，再按home鍵，然后回到tiktok，再切換相機，此時status()函數返回1，走了后續Camera.open流程。


•情況二：先滑動界面，再切換相機，然后按home鍵，接著回到tiktok，最后切換相機，此時status()函數返回2，沒走后續Camera.open流程。

從日志看switchCamera兩種情況都走了，再結合switchCamera的源碼看，源碼里的status()函數的返回值決定了是否繼續往下調用切換相機的流程，很遺憾的是，兩種情況都出現了，而且都會卡住（為什么兩個status值會不一樣呢，這里先留個坑，最后來填）。這可把我難住了！
就在這時腦子突然開竅，既然畫面卡住，那么必然有錯誤信息回調，果然一搜索CameraVideoCapture這個核心類有onError函數，毫不猶豫hook它，發現每次出錯時，這個函數的錯誤碼都會報-421錯誤（截圖省略-421錯誤碼的測試過程）。


錯誤信息非常明確的告訴我們是因為相機不支持縮放，導致的打開相機失敗，那么至此相機卡住的直接原因找到了，但是還沒找到為什么特殊的操作流程后會卡住，而正常的操作不會。于是乎繼續跟著堆棧信息往上找。

發現走進了這里的流程，導致的相機進縮放流程，為了驗證猜想，我決定在這個函數調用前，把message里的what字段改成2，讓它不走這個流程，來看看是不是就不會導致界面卡住，于是就有了下面這段代碼。

經過這一番篡改，果真隨便怎么折騰，直播界面都不會卡住了。那么我只要找到那里給handler發送的這個message就應該離真想很近了。


然后找這個handler的sendMessage相關切message的what字段賦值為1的函數。

然后我找到了它，這個函數還和縮放相關，那就八九不離十了。


按之前的堆棧繼續hook，發現卡住的時候這些方法確實都走了，而正常的時候是不走的，那么在X.Dvc的LIZ繼續用拋堆棧大法。
得到如下兩種堆棧：
•X.DCM接收到了touch事件，然后交由X.DCc這個類進行手勢判斷，發現是需要執行縮放的手勢，于是執行了相機的縮放功能（由于我們業務原因需要隱藏底部NavigationBar，在Window底部上劃會顯示NavigationBar，上劃的手勢同時觸發了控件的以為需要執行相機縮放），但是我們的虛擬攝像頭又不支持縮放，導致打開相機失敗，畫面就卡在了之前相機拿到的最后一幀。

X.DCc類

X.DCO的invoke方法

•點擊tiktok的切換相機Button，觸發進入相機的縮放，這里就和我們之前的點擊事件聯系上了，紅框部分就是補上了之前沒關注但是最重要的相機縮放功能判斷部分。


至此，我們已經把相機卡住的直接原因和根本原因都找到了，先手勢再點擊切換相機觸發了進入相機縮放功能判斷流程，由于我們的虛擬相機不支持縮放，導致打開相機失敗，卡在相機的最后一幀（也可能是黑屏）。所以只要交付給framework組開發人員，讓他們支持相機縮放相關功能就可以了。
接下來來填前面留下的坑，為什么退到后臺會導致status函數的返回值不一樣？
我們回到CameraVideoCapturer類，看看這個status()函數到底是個什么鬼！

發現他是父類ExternalVideoCapturer的函數，而且就是返回個字段，那再看看他那里進行了賦值。

通過AndroidStudio自帶的字段讀寫索引功能，很容易找到父類里的start、stop和release函數，以及自身的onErrorOnHandler函數里（也就是我們之前拋-421錯誤堆棧的函數）。如果熟悉相機開發的同學應該知道，一般我們界面退到后臺會釋放相機，然后回到前臺重新打開。那么接下來我們把這幾個函數都hook一下，來驗證猜想。

這里我多hook了一個onCaptureStarted函數，這個函數會調用父類的onStart函數，想看看是否會有調了onCaptureStarted但是沒調父類的onStart的情況。然后還hook了CameraVideoCapturer自身重寫的onStart和父類ExternalVideoCapturer的onStart函數。
下面是剛打開直播時的日志，此時status=1。

•情況一：先滑動直播界面，再按home鍵，然后回到tiktok，再切換相機，此時status()函數返回1，走了后續Camera.open流程。
這是直播退到后臺時的調用，說明確實釋放掉了，但是又調用了父類的onStart函數，那么此時的應該為2的status又變回了1。

接下來回到前臺，此時一切正常status還是為1，而且重走了自身的onStart函數，相當于相機整個流程完全重開。

再接著切換相機第一次，這時的status還是為1，相機正常，緊接著我們發現了-421錯誤，發現又重走了父類的onStart函數，那么此時status還是1。

接下來切換相機畫面卡住了，但還是走了父類的onStart。


以上就是第一種情況，由于每次切換相機都會拋完-421錯誤后，再調用父類ExternalVideoCapturer的start函數來重置status，也就造成了能調用Camera.open但是畫面卡住的情況。
•情況二：先滑動界面，再切換相機，然后按home鍵，接著回到tiktok，最后切換相機，此時status()函數返回2，沒走后續Camera.open流程。
前面流程就不貼了，直接開后面的流程記錄。
退到后臺 status=1

回到前臺status=1

切換相機第一次，畫面正常status=1

切換相機第二次，在調用switchCamera之前先拋了一次-421的錯誤，導致status=2，然后switchCamera函數里判斷status為2就被return，沒有調用Camera.open函數，接下來也沒有更多函數來重置status的狀態，所以無論怎么切換相機，都無法執行到Camera.open(),除非tiktok退到后臺，再回到前臺。


以上就是第二鐘情況。
首先，對比傳統的制造業中國的移動互聯網產品出海的表現，顯然更加亮眼；其次，對比去年榜單，工具類APP的位置已被內容類APP取代，字節跳動憑借TikTok首次入圍就殺入前五的位置，表明中國移動互聯網出海進入內容型產品主導階段。
內容型產品的底層邏輯是內容生產——內容分發——內容消費(變現)。其中，內容生產是決定成敗的首要條件如何降低內容生產成本成為很多公司必須要面對的問題，在PGC內容生產成本居高不下的情況，只有在UGC內容生產上下功夫才能健康持續發展。特別是在如今移動互聯網出海進入內容型產品的主導階段，研究這個課題更具現實意義。
內容型產品的冷啟動，包括短視頻、網文等產品，除了團隊自制和授權合作等PGC手段，以及簽約KOL帶動UGC創作外，另外一種方式是，通過特定的主題活動策劃進行UGC內容征集。以短視頻APP為例，通過策劃主題視頻征集活動，比如美妝達人視頻征集大賽，旅游達人視頻征集大賽等，在社交媒體上推廣征集大賽的H5頁面進行短視頻UGC內容征集。
一來可以征集各類優質視頻，發掘優秀的短視頻達人，為產品上線進行內容儲備，實現內容冷啟動；其次通過在社交媒體推廣大賽可以為社交媒體主頁積累粉絲，為后續APP的推廣與品牌營銷做鋪墊。本文將通過復盤一個活動，來討論內容型產品出海如何通過活動實現UGC內容征集。文章基于實操案例，對部分內容和數據做了脫敏處理，但基本邏輯一致。該案例的剖析分為上下2篇，本文首先與大家分享“活動運營基本流程和核心要素”。
1、結合產品內容方向與用戶需求，明確活動的目標、資源和時間。
首先，活動策劃一定要在了解目標市場用戶需求，內容方向上有確定的規劃之后進行，因此負責活動運營的同學要與負責內容的同學進行充分溝通，以確定此次活動的主題。因為活動的根本目的是，通過特定內容主題活動推廣引導相關用戶進行內容生產，平臺可以對該主題優秀內容和創作者的快速征集和篩選，這兩點是核心要素，所以我們可結合現有資源(主要是獎品獎金和推廣費用)，設定特定數量的優質內容和創作者作為活動目標。
Tiktok在澀谷最繁忙的十字路口的廣告屏幕
評估活動資源和預算確定獎品獎金和推廣計劃。獎品獎金不僅是活動吸引用戶參與的重要動力，而且也是活動推廣宣傳的重要元素，因此在獎品獎金設置上要花點心思。我認為有2點需要考慮，
一是獎品最好跟內容主題掛鉤，比如是短視頻征集大賽，獎品可以選擇跟短視頻相關的獎品，比如相機等；
二是一等獎要有足夠的吸引力，一等獎作為活動獎品的門面，在推廣上有直接助推作用，能夠調動用戶的主動參與積極性。
另外，除了物質激勵，也可以通過曝光激勵或榜單激勵等方式來滿足用戶的訴求，更好的激發用戶參與活動的熱情，比如最終獲獎者獎有機會在特定的線下大屏幕廣告位展示曝光等，像Tiktok在日本舉行的挑戰賽的獎勵就是獲獎者有機會登上澀谷最繁忙的十字路口的4塊大型廣告屏幕，最終吸引短視頻投稿超過6萬，觀看數也超過3億。
活動時間則是本次活動的周期多長，與活動目標以及本次活動規模多大和活動頁面開發上線所需時間等因素息息相關，要具體問題具體分析。如果活動獎品獎金豐厚，設定的征集內容數量較高，則活動可能需要以季度為單位；若活動目標較易實現，獎品獎金一般，則以月或周為單位。其次就是根據公司所有的開發資源評估開發活動頁面所需的時間來決定最終的活動開始時間。
2、設計活動玩法和形式。
線上玩法設計的核心要素是有趣新穎，從活動主題文案描述和活動海報設計，到獲獎機制的設置都要能夠吸引用戶參與；其次，內容征集類活動內容上傳，要設計好上傳的入口和路徑，確保便利用戶上傳內容。
首先，要根據具體場景和用戶使用設備來確定活動上傳入口。不同的內容形態，內容長度和生產場景決定用戶創作使用的是PC站還是移動設備。
例如，對于長篇的網絡小說創作來說，作者更習慣和方便的是在電腦進行寫作，活動的落地頁最好基于PC站；對于短視頻的拍攝，視頻達人基本是使用手機等移動設備進行拍攝，活動基于應用程序，如果在APP未上線的情況下可以通過H5頁面上傳視頻。
其次，做好上傳機制的路徑設計，盡量縮短操作路徑。從影響營銷轉化的因素來說，一個要有大規模的精準流量曝光，另外一個就是縮短轉化環節了。因為每多一個轉化環節，那就有提高內容上傳的流失率，因此，無論是在PC站還是移動端，都要確保用戶上傳機制路徑的精簡和穩定性。
最后，除了基于PC站或移動設備產品的主路徑上傳機制，要有補充的上傳或投稿方式選擇。考慮到目標用戶所在地區的網絡情況（海外不同國家和地區網絡情況差異巨大），用戶上傳或投稿習慣（用戶尚未習慣線上上傳內容），甚至是上傳機制由于bug或其他因素影響用戶在線上上傳內容，所以一定要有一個可供用戶選擇的上傳或投稿內容的第二選項，比如說，可以留一個官方郵箱供用戶上傳內容使用。
3、活動落地執行過程團隊內部，要及時溝通調整方案，確認資源并跟進順利上線。
活動方案策劃好，運營團隊內部通過后，接下來就是方案的執行落地環節，這一環節核心要素是細扣活動流程和體驗，活動的文案和視覺效果，與其他團隊一起協作確保活動順利上線。
做好項目管理，確保各個關鍵節點如期完成以保證上線。活動落地涉及到不同部門的協助，包括設計，開發，數據，廣告和新媒體等，首先需要進行設計評審和開發評審，以評估開發活動頁面所需時間，然后要與數據組提前做好埋點的溝通，確保活動的相關數據能夠拿到以評估最終效果，最后就是要與廣告和新媒體做好活動預熱和推廣的準備。
在這個過程中，運營同學需要注意幾點：
一是在活動評審會為各個模塊制定目標和確定的“死線”(deadline)，包括設計稿出來的時間點，什么時候能夠開發完成，埋點所需哪些數據，廣告和新媒體預熱與推廣的計劃與時間線怎樣等等，與每個模塊負責人討論確定好具體時間點并在會議結束后繪制成SOP甘特圖同步給所有與會人員，確保每個人對自己事項的時間節點產出理解到位并能夠實現。
二是對不同部門注意采用合適溝通方式，快速推進各個部門落地實施。活動運營既是活動策劃的大腦，又是推動整個活動落地的推手，因此運營同學在活動執行中與其他部門的溝通就很重要。不同部門同學思維方式和思考的出發點可能會有所不同。
三是在溝通中反復調整運營方案，注意對運營方案的細節進行優化。活動落地執行是在各個角色碰撞中實現運營方案的過程，活動運營同學在策劃好活動方案后需要畫好交互原型，便于其他人理解和實現。
4、活動的預熱和推廣。
怎么進行預熱和推廣呢？要選擇合適的渠道進行預熱和推廣，充分利用內外渠道進行曝光。
內部流量包括自家APP和網站，以及自家社交媒體賬號體系。可以在自家的APP和網站醒目的位置上放置設計好的Banner圖或頁面的其他地方放上活動的鏈接，保證預熱宣傳的最佳位置。社交媒體賬號體系，包括FB，Ins等全面覆蓋了自家的粉絲，傳播時效性強，是預熱曝光不可忽視的渠道。
預熱海報是最常見的預熱素材，對于UGC內容征集類預熱活動，可以在突出內容征集主題情況下，把獎金獎品或其他具有亮點的獎勵呈現在預熱海報上，吸引對活動感興趣和有需要的參與者。另外，如果距離活動上線有足夠時間，可以利用粉絲的社交媒體的關系鏈進行傳播，策劃預熱活動，利用小額獎品作為獎勵鼓勵用戶轉發預熱海報。
一來成本相對較低，二來愿意轉發的用戶往往本身是對活動感興趣的用戶，物以類聚，這部分人的關系鏈往往也是潛在的參與者，從而實現低成本擴散的目的。
外部流量主要就是KOL合作，合作互推和廣告投放等。一般來說，外部流量的推廣是公司的廣告投放部門負責，因此運營同學在活動評審會議就需要廣告投放的同學參與，因為他們也需要清楚活動的背景和目標是什么，而不是等到活動上線后再匆匆提需求，這樣雙方都不方便，會議要達成投放達成廣告投放計劃產出的時間，和正式投放的時間的共識并同步到SOP甘特圖上，以便于落地實施。
運營需要把本次活動廣告投放的目標，預算，具體時間段，目標受眾定位信息等告知廣告投放同學，廣告投放同學產出的投放計劃則需要包括整體預算的分配，投放的節奏，著陸頁面關鍵環節埋點追蹤，廣告效果預估和建議等。
同時，運營在與廣告投放溝通中要注意傾聽對方意見，因為運營同學作為活動的策劃者，有可能會當局者迷，從而遺漏某些重要環節，而廣告投放的同學會從用戶看到廣告到點擊上傳內容的角度提出一些用戶上傳環節潛在的問題。以視頻上傳為例，用戶的行為路徑包括點擊廣告—進入頁面—上傳視頻—提交視頻—提交成功，運營同學重點關注的是視頻征集，思考的是正常情況下是用戶相冊里已經有視頻，點擊提交上傳視頻。
但是廣告同學會從用戶看到廣告到提交視頻的整個場景去思考，因為廣告是即時展示，如果用戶相冊里沒有視頻，需要退出頁面，去拍攝，在這段過程中，用戶再回去提交，該頁面可能消失，廣告也不一定再展示給他，這是運營同學可能會忽略的一個場景。
因此，由廣告投放同學角度出發，可能會發現一些潛在的問題，需要給沒有本地視頻的用戶另外一個選擇，比如給到官方主頁信息，而官方主頁也會有活動的鏈接，從而使得這部分用戶有上傳通道。這個例子給我們的啟示是，運營需要多與其他項目相關方多溝通，而不是僅僅要求對方執行方案，只要這樣才能不斷完善，減少或杜絕上線后問題的出現。
5、活動執行過程中的數據分析監測，發現問題與及時優化。
活動上線后我們需要時刻關注數據的變化，通過數據分析觀察現狀、定位問題，并及時解決問題。
分析頁面的用戶行為。觀察用戶內容上傳主路徑的行為數據，通過漏斗模型分析每個環節的具體數據和轉化率，從而明確問題所在和改進的方向。若某個環節的轉化率低于預期，那要去分析原因，是頁面存在bug還是某個按鈕視覺效果不夠吸睛，從而去定位是技術還是設計上的問題，與相關同學溝通解決辦法并確定具體的改進方案和上線時間。
分析活動的關鍵指標。通過分析活動的關鍵指標我們可以快速地了解活動的效果，以短視頻征集活動為例，在這個業務場景中，活動的關鍵指標包括用戶日均提交成功視頻數，日均提交成功次數和提交成功用戶數，知道這幾個數據我們可以直觀地評估活動征集的總體效果好壞。其次，知道上述幾個數據之后我們還可以得知人均提交成功視頻次數和人均提交成功視頻數。從微觀角度分析用戶上傳視頻的積極程度，如果這兩個數據大于1，說明用戶平均上傳視頻數和次數不只一次，數字越大，說明用戶對活動上傳視頻越是積極，活動效果越好。
6、優質內容的篩選與二次傳播優質內容篩選機制與社交傳播。
活動如果能達到病毒傳播是最理想的情況，其中必須要重視二次傳播，而不能太過佛系。建議要有意識地在活動策劃時就在活動獲獎規則增加社交媒體傳播作為評獎一個權重，根本目的是在用戶參與活動的同時帶動他的人際關系去評論，點贊和分享活動，這樣活動就開始二次傳播的過程，既增強用戶的參與感，又使得活動影響范圍擴大。
以短視頻征集為例，可以在獲獎規則中增加社交媒體對參賽作品的點贊或分享作為一個評獎維度，將參賽者入圍的優質視頻上傳到社交媒體，鼓勵參賽者積極去分享和拉好友點贊。一方面能夠滿足參賽者曝光的需求，使得參與者更加積極參與活動，另一方面也能夠達到良好的二次傳播效果。當然在考慮將社交媒體傳播因素作為評獎規則一部分的時候要考慮好防止刷獎，因為如果規則有漏洞可能有些人會趁虛而入。
另外，制造話題，通過軟文在社交媒體或論壇上宣傳也是不可忽視手段。
7、活動復盤與效果評估。確定活動結果，完成獎金獎品發放。
在活動策劃時，對于獎勵機制的設定，具體來說，除了上述說到的與活動主題相關原則以及一等獎足夠吸引原則，還需要考慮本地化原則與便于發放原則。本地化原則指要對目標市場用戶進行調研，運營同學需要注意與當地運營溝通，不可想當然地按照國內經驗套用，要確保獎勵機制是受目標用戶歡迎，能夠激發起他們參與活動的熱情的獎品或其他獎勵。便于發放是指選擇獎品要考慮發放環節是否便于主辦方發放給所有的獲獎者，而且如果涉及到獎品的快遞，要考慮獎品快遞的安全性以及獎品物流的成本等。
效果評估和活動復盤。復盤是向自己學習的方式，我認為獲得比較快速進步的方法就是善于向自己學習。相信很多同學也都想過這個問題，對于自己的職業選擇，是選擇在一個團隊獨當一面去探索還是去一個有大牛的團隊學習？其實，能夠跟對大牛或好的領導機會可遇不可求，所以只有具備自我學習能力才是根本，復盤就是鍛煉自我學習能力必備技能。
如何進行活動復盤呢？簡單來說，可以按照以下順序展開：
1）回顧目標：活動的目的是什么？
2）評估結果：原定目標的完成情況怎樣？有哪些成績和不足之處？
3）分析原因：目標完成的成功或失敗的原因是什么，包括主客觀兩方面。
4）活動總結：通過上述思考分析通過活動進行UGC內容征集是否是一個可行的方式，其中有哪些環節可以優化，有什么做法是下一次活動可以復制等。
其實，上述每個環節的梳理，可以說是從基本流程角度對活動進行了一次復盤，而且這個流程適用于其他線上活動。活動策劃后落地執行需要做好每個環節的轉化，因為如何在既定預算的前提下提高整體征集的UGC內容數量，特別是優質內容的數量，是這次活動運營最核心的指標。關于這個問題，將在下篇文章中和大家分享我的看法。