一行代碼搞定 Android 復(fù)雜列表埋點(diǎn)曝光

一個(gè)好的產(chǎn)品離不開數(shù)據(jù)分析，在手機(jī) APP 中，數(shù)據(jù)分析極致化需要細(xì)致到某個(gè)時(shí)刻列表曝光的了哪幾個(gè) Item。

我們提供的服務(wù)有：網(wǎng)站建設(shè)、成都網(wǎng)站制作、微信公眾號開發(fā)、網(wǎng)站優(yōu)化、網(wǎng)站認(rèn)證、建寧ssl等。為上1000+企事業(yè)單位解決了網(wǎng)站和推廣的問題。提供周到的售前咨詢和貼心的售后服務(wù)，是有科學(xué)管理、有技術(shù)的建寧網(wǎng)站制作公司

2022 年了，基本上目前 Android 上可以滑動的復(fù)雜列表都是 RecyclerView 或者其擴(kuò)展，這里分享一個(gè)封裝的思路。

如果非要細(xì)化細(xì)節(jié)：

各種方案核心都差不多，最關(guān)鍵的就是通過 LayoutManager 獲取屏幕內(nèi)第一個(gè)可見和最后一個(gè)可見 item position，上報(bào)其區(qū)間內(nèi)的 Item。這里簡稱這個(gè)邏輯為 檢查上報(bào)邏輯 。

但是觸發(fā)時(shí)機(jī)有所不同，通常如下方案一和二所述，當(dāng)然除了方案一和方案二外，還有一些別的方案，比如監(jiān)聽 RecyclerView 的布局樹變化觸發(fā) 檢查上報(bào)邏輯 等方案。

可以發(fā)現(xiàn)方案二相比方案一更有利于減少各種回調(diào)的注冊和周期的控制，下文會在方案二的基礎(chǔ)上，闡述用法和相關(guān)實(shí)現(xiàn)思路。

倉庫地址： RecyclerViewExposure

這里會主要說明一些主要邏輯，需要完整的邏輯可以 fork 倉庫 查看

思路來自于 lifecycle 的設(shè)計(jì)，這里主要是想讓 Activity/Fragment 提供可見和不可見的狀態(tài)變化給外部訂閱

對 List Item 的收集處理是 RecyclerViewExposure 最核心的收集數(shù)據(jù)邏輯，這里針對在 Activity 的使用作為例子。上文已經(jīng)講述如何做一個(gè) PageLifeCycleHolder 為其他組件提供頁面可見狀態(tài)，下文將直接使用。

關(guān)于數(shù)據(jù)埋點(diǎn)，你需要知道的技術(shù)方案和規(guī)范流程

埋點(diǎn)是數(shù)據(jù)采集的專用術(shù)語，在數(shù)據(jù)驅(qū)動型業(yè)務(wù)中，如營銷策略、產(chǎn)品迭代、業(yè)務(wù)分析、用戶畫像等，都依賴于數(shù)據(jù)提供決策支持，希望通過數(shù)據(jù)來捕捉特定的用戶行為，如按鈕點(diǎn)擊量、閱讀時(shí)長等統(tǒng)計(jì)信息。因此，數(shù)據(jù)埋點(diǎn)可以簡單理解為：針對特定業(yè)務(wù)場景進(jìn)行數(shù)據(jù)采集和上報(bào)的技術(shù)方案。

數(shù)據(jù)埋點(diǎn)非常看重兩件事，一個(gè)是數(shù)據(jù)記錄的準(zhǔn)確性，另一個(gè)則是數(shù)據(jù)記錄的完備性。

先講數(shù)據(jù)的準(zhǔn)確性。數(shù)據(jù)埋點(diǎn)非常強(qiáng)調(diào)規(guī)范和流程，因?yàn)閰?shù)的規(guī)范與合法，將直接影響到數(shù)據(jù)分析的準(zhǔn)確性，如果準(zhǔn)確性得不到保障，那么所有基于埋點(diǎn)得出的結(jié)論，都是不可信的。辛辛苦苦做了很久的方案，一旦因?yàn)橐粋€(gè)疏忽的小問題，導(dǎo)致下游集中投訴，其實(shí)非常劃不來。

道理每個(gè)人都懂，但現(xiàn)實(shí)情況中，數(shù)據(jù)埋點(diǎn)所面對的客觀環(huán)境，其實(shí)非常復(fù)雜，例如：

因此本文有非常長的篇幅來寫流程問題，其實(shí)是非常有必要的。

再講數(shù)據(jù)的完備性。因?yàn)槁顸c(diǎn)主要是面向分析使用，對用戶而言是個(gè)額外的功能，因此埋點(diǎn)的業(yè)務(wù)侵入性很強(qiáng)，很容易對用戶體驗(yàn)造成影響。別的不說，僅僅是流量的消耗，就很容被用戶噴。因此，要提前想清楚，我們要采集哪些東西，因?yàn)樾薷姆桨傅某杀?，是傷不起的?/p>

通常情況下，我們需要記錄用戶在使用產(chǎn)品過程中的操作行為，通過4W1H模型可以比較好的保障信息是完備的。4W1H包括：

規(guī)定好記錄信息的基本方法之后，按照固定的頻率，如每小時(shí)、每天，或者是固定的數(shù)量，比如多少條日志，或者是網(wǎng)絡(luò)環(huán)境，比如在Wifi下上傳，我們就可以開心的把埋點(diǎn)數(shù)據(jù)用起來了。

當(dāng)然，數(shù)據(jù)記錄的時(shí)效性也比較重要，但因?yàn)槁顸c(diǎn)數(shù)據(jù)通常量級會比較大，且各個(gè)端數(shù)據(jù)回傳的時(shí)間不同，因此想做到實(shí)時(shí)統(tǒng)計(jì)，還是需要分場景來展開。在Flink技術(shù)日漸成熟的今天，全鏈路的實(shí)時(shí)采集與統(tǒng)計(jì)，已經(jīng)不是什么難題。

在埋點(diǎn)的技術(shù)方案中，首先要重視的，是用戶唯一標(biāo)識的建設(shè)。如果做不到對用戶的唯一識別，那么基礎(chǔ)的UV統(tǒng)計(jì)，都將是錯(cuò)誤的。

因此，在數(shù)據(jù)埋點(diǎn)方案中，有兩個(gè)信息是一定要記錄的，即設(shè)備ID+用戶ID。設(shè)備ID代表用戶使用哪個(gè)設(shè)備，如安卓的ANDROID_ID/IMEI，IOS中的IDFA/UDID，瀏覽器的Cookie，小程序的OpenID等。用戶ID，代表用戶在產(chǎn)品中所注冊的賬號，通常是手機(jī)號，也可以是郵箱等其他格式。

當(dāng)這兩個(gè)信息能夠獲得時(shí)，不論是用戶更換設(shè)備，或者是同一臺設(shè)備不同賬號登錄，我們都能夠根據(jù)這兩個(gè)ID，來識別出誰在對設(shè)備做操作。

其次，我們來看一下Web的數(shù)據(jù)采集技術(shù)。Web端數(shù)據(jù)采集主要通過三種方式實(shí)現(xiàn)：服務(wù)器日志、URL解析及JS回傳。

瀏覽器的日志采集種類又可以分為兩大類：頁面瀏覽日志和頁面交互日志。

除此之外，還有一些針對特定場合統(tǒng)計(jì)的日志，例如頁面曝光時(shí)長日志、用戶在線操作監(jiān)控等，但原理都基于上述兩類日志，只是在統(tǒng)計(jì)上有所區(qū)分。

再次，我們來看下客戶端的數(shù)據(jù)采集。與網(wǎng)頁日志對應(yīng)的，是手機(jī)應(yīng)用為基礎(chǔ)的客戶端日志，由于早期手機(jī)網(wǎng)絡(luò)通訊能力較差，因而SDK往往采用延遲發(fā)送日志的方式，也就是先將日志統(tǒng)計(jì)在本地，然后選擇在Wifi環(huán)境下上傳，因而往往會出現(xiàn)統(tǒng)計(jì)數(shù)據(jù)延遲的情況。現(xiàn)如今網(wǎng)絡(luò)環(huán)境好了很多，4G、5G流量充足，尤其是視頻類APP基本上都是一直聯(lián)網(wǎng)，因而很多統(tǒng)計(jì)能夠做到實(shí)時(shí)統(tǒng)計(jì)。

客戶端的日志統(tǒng)計(jì)主要通過SDK來完成，根據(jù)不同的用戶行為分成不同的事件，“事件”是客戶端日志行為的最小單位，根據(jù)類型的不同，可以分為頁面事件（類比頁面瀏覽）和控件點(diǎn)擊事件（類比頁面交互）。對于頁面事件，不同的SDK有不同的方式，主要區(qū)別為是在頁面創(chuàng)建時(shí)發(fā)送日志，還是在頁面瀏覽結(jié)束后發(fā)送日志，區(qū)別在于業(yè)務(wù)統(tǒng)計(jì)是否需要采集用戶的頁面停留時(shí)長。

頁面事件的統(tǒng)計(jì)主要統(tǒng)計(jì)如下三類信息：

埋點(diǎn)其實(shí)還需要考慮數(shù)據(jù)上傳的方案，批量的數(shù)據(jù)可以通過Flume直接上報(bào)，流式的可以寫到Kafka，或者直接使用Flink來處理。這些框架相關(guān)的內(nèi)容不是本文考慮的重點(diǎn)，有興趣的可以自行查閱資料。

有了指導(dǎo)思路和技術(shù)方案后，我們就可以著手制定相應(yīng)的數(shù)據(jù)埋點(diǎn)流程規(guī)范了。

籠統(tǒng)上，流程規(guī)范會分成五個(gè)步驟，即需求評審、埋點(diǎn)申請、技術(shù)開發(fā)、埋點(diǎn)驗(yàn)證、發(fā)布上線。

第一步，需求評審。

前文提到過，數(shù)據(jù)埋點(diǎn)的方案一旦確定，返工和排查問題的成本都很高，但數(shù)據(jù)埋點(diǎn)之后的分析工作，又涉及到了PD、BI、算法、數(shù)據(jù)等多個(gè)角色。因此非常有必要，將需求內(nèi)容和數(shù)據(jù)口徑統(tǒng)一收口，所有人在一套口徑下，將需求定義出來，隨后業(yè)務(wù)側(cè)再介入，進(jìn)行埋點(diǎn)方案的設(shè)計(jì)和開發(fā)。

以前文提到的4W1H模型為例，常見的記錄內(nèi)容如下：

最后我們統(tǒng)計(jì)時(shí)，按照上述約定，統(tǒng)計(jì)用戶在某個(gè)時(shí)間和地點(diǎn)中，看到了哪些信息，并完成了怎樣的動作。上下游的相關(guān)人員，在使用這份數(shù)據(jù)時(shí)，產(chǎn)生的歧義或者是分歧，會小很多。

第二步，埋點(diǎn)申請

當(dāng)下的熱門應(yīng)用，大多是以超級APP的形式出現(xiàn)，比如微信、淘寶、支付寶、抖音，超級APP會承載非常多的業(yè)務(wù)，因此技術(shù)方案上會十分統(tǒng)一。

因此，當(dāng)我們的技術(shù)方案確定后，通常要在相應(yīng)的埋點(diǎn)平臺上，進(jìn)行埋點(diǎn)申請。申請的內(nèi)容包括分配的SPM、SCM碼是什么，涉及到的平臺是哪些，等等。SPM、SCM是什么，有什么用，同樣可以自行查閱。

第三步，技術(shù)開發(fā)

當(dāng)需求確定、申請通過后，我們就可以開始開發(fā)動作了，這里基本上是對研發(fā)同學(xué)進(jìn)行約束。埋點(diǎn)的開發(fā)，簡單講，是分成行為埋點(diǎn)和事件埋點(diǎn)兩個(gè)大類，每一類根據(jù)端的不同進(jìn)行相應(yīng)的開發(fā)。具體的技術(shù)方案詳見前文01章節(jié)。

詳細(xì)的設(shè)計(jì)規(guī)范，是需要留文檔的，因?yàn)榇a不能反應(yīng)業(yè)務(wù)的真實(shí)意圖，而不論是事后復(fù)盤與業(yè)務(wù)交接，都需要完整的文檔來闡述設(shè)計(jì)思路。

第四步，埋點(diǎn)驗(yàn)證

埋點(diǎn)的驗(yàn)證很關(guān)鍵，如果上線后才發(fā)現(xiàn)問題，那么 歷史 數(shù)據(jù)是無法追溯的。

驗(yàn)證有兩種方式，一種是實(shí)時(shí)的功能驗(yàn)證，一種是離線的日志驗(yàn)證。

實(shí)時(shí)功能驗(yàn)證，指功能開發(fā)好后，在灰度環(huán)境上測試相應(yīng)的埋點(diǎn)功能是否正常，比如點(diǎn)擊相應(yīng)的業(yè)務(wù)模塊，日志是否會正確的打印出來。通常而言，我們需要驗(yàn)證如下三個(gè)類型的問題：

除去實(shí)時(shí)驗(yàn)證，我們也需要把日志寫到測試環(huán)境中，查看數(shù)據(jù)上報(bào)的過程是否正確，以及對上報(bào)后的數(shù)據(jù)進(jìn)行統(tǒng)計(jì)，側(cè)面驗(yàn)證記錄的準(zhǔn)確性，如統(tǒng)計(jì)基本的PV、UV，行為、事件的發(fā)生數(shù)量。

很多時(shí)候，數(shù)據(jù)是需要多方驗(yàn)證的，存在一定的上下游信息不同步問題，比如對某個(gè)默認(rèn)值的定義有歧義，日志統(tǒng)計(jì)會有效的發(fā)現(xiàn)這類問題。

第五步，發(fā)布上線。

應(yīng)用的發(fā)布上線通常會有不同的周期，例如移動端會有統(tǒng)一的發(fā)版時(shí)間，而網(wǎng)頁版只需要根據(jù)自己的節(jié)奏走，因此數(shù)據(jù)開始統(tǒng)計(jì)的時(shí)間是不同的。最后，應(yīng)用應(yīng)當(dāng)對所有已發(fā)布的埋點(diǎn)數(shù)據(jù)，有統(tǒng)一的管理方法。

大多數(shù)時(shí)候，數(shù)據(jù)埋點(diǎn)的技術(shù)方案，只需要設(shè)計(jì)一次，但數(shù)據(jù)準(zhǔn)確性的驗(yàn)證，卻需要隨著產(chǎn)品的生命周期持續(xù)下去，因此僅僅依靠人肉來準(zhǔn)確性驗(yàn)證是不夠的，我們需要平臺來支持自動化的工作。埋點(diǎn)的準(zhǔn)確性，大體有兩種方法保障：一種是灰度環(huán)境下驗(yàn)證真實(shí)用戶數(shù)據(jù)的準(zhǔn)確性；另一種則是在線上環(huán)境中，驗(yàn)證全量數(shù)據(jù)的準(zhǔn)確性。因此，發(fā)布上線之后，后續(xù)的管理動作，應(yīng)該是對現(xiàn)有流程的自動化管理，因?yàn)閳F(tuán)隊(duì)大了，需要埋點(diǎn)的東西多種多樣，讓平臺自己測試、自動化測試，就是很多測試團(tuán)隊(duì)必須走的路

數(shù)據(jù)埋點(diǎn)技巧

移動互聯(lián)網(wǎng)時(shí)代，無論是Android、iOS還是小程序，都有很多成熟的解決方案，無需花費(fèi)很多的時(shí)間去處理埋點(diǎn)的事情，而且基于第三方提供的SDK進(jìn)行埋點(diǎn)，在數(shù)據(jù)處理和分析上也有很大的優(yōu)勢。

但是在之前的PC互聯(lián)網(wǎng)時(shí)代，除了網(wǎng)頁端有百度統(tǒng)計(jì)、谷歌分析等，客戶端的埋點(diǎn)似乎沒有一套能拿出來可供大家討論的解決方案，我就基于我的工作經(jīng)驗(yàn)和理解，給大家分享一下PC客戶端的埋點(diǎn)。

PC客戶端的埋點(diǎn)

首先，在PC上，我們得知道我們需要統(tǒng)計(jì)些什么內(nèi)容。

一個(gè)PC客戶端，無論是工具類的還是內(nèi)容類的，我們都希望知道我們提供的服務(wù)的效果。那么，我們從一個(gè)客戶端安裝、運(yùn)行到最終被卸載來看看。

就拿產(chǎn)品使用較多的工具“Axure RP”來舉例吧。如果“Axure RP”是我們自己的軟件，首先我們需要知道被安裝了，之后，我們關(guān)注激活情況，也就是使用，到最后，被卸載了，這一整個(gè)環(huán)節(jié)，構(gòu)成了一個(gè)生命周期。 重點(diǎn)來了，對于這個(gè)生命周期，所有你想知道的關(guān)于“Axure RP”的情況你都可以統(tǒng)計(jì)到。

1.軟件的安裝

在PC客戶端安裝的過程中，流程一般是這樣的：①運(yùn)行安裝包②彈出安裝界面提供給用戶操作③執(zhí)行安裝過程-寫注冊表、啟動項(xiàng)、計(jì)劃任務(wù)等④執(zhí)行安裝過程-創(chuàng)建安裝的文件夾（③和④可以交換）。

在這個(gè)環(huán)節(jié)，我們一般需要知道：

安裝包被運(yùn)行了

在安裝界面用戶做了哪些操作

我們的安裝過程是否正常執(zhí)行

我們最終是否安裝成功

在PC上，只要我們的安裝包運(yùn)行起來了，無論是彈出安裝界面、寫注冊表還是創(chuàng)建文件，這些都是安裝包可以控制的，所以我們能通過安裝包進(jìn)程，將整個(gè)安裝環(huán)節(jié)的所有數(shù)據(jù)記錄下來發(fā)送到我們的后臺并記錄下來 （這里要重點(diǎn)記住，由于安裝是一次性的動作，所以統(tǒng)計(jì)一定要發(fā)實(shí)時(shí)的） 。

2.軟件的使用

軟件的使用，包括啟動軟件、使用功能和退出軟件。

在PC上，軟件的啟動有很多種方式，例如開機(jī)自啟動、計(jì)劃任務(wù)、手動點(diǎn)擊快捷方式，我們繼續(xù)以“Axure RP”舉例，當(dāng)我們裝上了“Axure RP”后，會在桌面、開始菜單中，創(chuàng)建快捷方式（有些程序會在任務(wù)欄上也創(chuàng)建），同時(shí)，會將后綴名為“rp”的文件默認(rèn)打開方式調(diào)整為“Axure RP”。

對于啟動， 我們就有了三種方式：桌面快捷方式、開始菜單快捷方式和默認(rèn)軟件打開，所以我們需要統(tǒng)計(jì)軟件是否被啟動了，是如何啟動的。

對于使用功能， 當(dāng)軟件運(yùn)行起來后，其進(jìn)程就會啟動，這個(gè)時(shí)候就跟移動端的應(yīng)用類似，我們需要統(tǒng)計(jì)一系列事件，每個(gè)功能的使用情況、功能狀態(tài)、付費(fèi)、登錄等一系列信息（區(qū)別于移動端的是，在PC上一般這些統(tǒng)計(jì)都是做單點(diǎn)統(tǒng)計(jì)，例如統(tǒng)計(jì)彈窗的彈出、功能的點(diǎn)擊、某個(gè)狀態(tài)，對于相互關(guān)聯(lián)的一組事件統(tǒng)計(jì)是比較復(fù)雜的，需要定義結(jié)構(gòu)體，在一條統(tǒng)計(jì)中包含很多組字段信息，因?yàn)闆]有成熟的SDK集成，所以基本都要自己定義埋點(diǎn)，復(fù)用性較差）。

這部分統(tǒng)計(jì)分為公共統(tǒng)計(jì)和專用統(tǒng)計(jì)。公共統(tǒng)計(jì)就是基本信息，常用的是用戶標(biāo)識、用戶基本信息、計(jì)算機(jī)硬件信息和其他的可復(fù)用的；專用統(tǒng)計(jì)就是針對你的功能，你想了解哪些情況，針對性進(jìn)行埋點(diǎn)統(tǒng)計(jì)。

對于軟件退出， 這就比較簡單了，是正常退出還是異常退出？軟件使用了多久退出？

3.軟件的卸載

軟件卸載的流程包括啟動卸載程序、用戶操作、刪除注冊表及文件等操作、完成卸載。

在這個(gè)過程中，我們主要關(guān)注兩方面的信息，一方面是用戶怎么卸載的？是主動使用卸載程序，還是通過一些管理軟件進(jìn)行卸載；另一方面是用戶為什么要卸載，這個(gè)時(shí)候我們可以在卸載的界面中給用戶提供選擇，以獲取用戶的反饋。

該怎么埋點(diǎn)

1.埋點(diǎn)的分類

（1）時(shí)效性

PC客戶端一般情況下都比較復(fù)雜，子功能很多，可統(tǒng)計(jì)的內(nèi)容很多，為了節(jié)省帶寬，我們不可能每次都實(shí)時(shí)將數(shù)據(jù)傳輸回來，而且很多時(shí)效性不是很強(qiáng)的功能沒有必要實(shí)時(shí)上報(bào)。

實(shí)時(shí)統(tǒng)計(jì)

當(dāng)功能觸發(fā)時(shí)或達(dá)到一定條件，立即將統(tǒng)計(jì)回傳，一般情況下用于時(shí)效性比較強(qiáng)的功能，例如活躍統(tǒng)計(jì)、營收類統(tǒng)計(jì)，我們需要實(shí)時(shí)分析并調(diào)整策略。

延時(shí)統(tǒng)計(jì)

統(tǒng)計(jì)不立即回傳，將統(tǒng)計(jì)積累，達(dá)到一定的條件或者一定的時(shí)間，統(tǒng)一將這部分統(tǒng)計(jì)回傳，一般情況用于時(shí)效性不強(qiáng)的功能，例如采集設(shè)備信息、獲取某些功能的狀態(tài)、常規(guī)功能的統(tǒng)計(jì)，這部分統(tǒng)計(jì)使用范圍比較廣，一般都是隔日發(fā)送，有一天的延遲，統(tǒng)計(jì)的信息晚一天不會對分析產(chǎn)生較大的影響。

（2）埋點(diǎn)的作用

常規(guī)的基礎(chǔ)統(tǒng)計(jì)

每次統(tǒng)計(jì)都需要發(fā)送，可以理解為公用統(tǒng)計(jì)，這部分統(tǒng)計(jì)是將幾乎所有的統(tǒng)計(jì)都需要的部分包括進(jìn)來，封裝成一個(gè)統(tǒng)一的部分，每次發(fā)送統(tǒng)計(jì)都會帶上這些內(nèi)容，方便管理，節(jié)省后續(xù)埋點(diǎn)時(shí)間。

功能統(tǒng)計(jì)

針對特定功能，當(dāng)功能被使用或者生效的時(shí)候，我們需要統(tǒng)計(jì)效果或者狀態(tài)，可以理解為專用統(tǒng)計(jì)，不同于移動端，PC一般沒有第三方提供的SDK，需要每個(gè)專用統(tǒng)計(jì)自己埋點(diǎn)，維護(hù)大量的統(tǒng)計(jì)內(nèi)容，不過在一個(gè)公司內(nèi)部，可以統(tǒng)一設(shè)計(jì)規(guī)范，方便維護(hù)。

（3）數(shù)據(jù)類型

結(jié)構(gòu)體

統(tǒng)計(jì)連貫的事件，各項(xiàng)信息之間的關(guān)聯(lián)很重要。

計(jì)數(shù)

統(tǒng)計(jì)某個(gè)行為發(fā)生的次數(shù)。

字符串

統(tǒng)計(jì)內(nèi)容。

整形

統(tǒng)計(jì)數(shù)值，也可用來統(tǒng)計(jì)狀態(tài)。

布爾型

統(tǒng)計(jì)需要判斷的類型，一般使用場景較少，為了方便計(jì)算，大部分被整形和字符串替代。

2.數(shù)據(jù)埋點(diǎn)實(shí)例

（1）軟件安裝

場景：統(tǒng)計(jì)安裝過程中的信息

（2）軟件的使用

場景：軟件啟動后，用戶使用了分享功能，將自己做的原型分享到了云端，最后用戶關(guān)閉了軟件。

要注意的是，軟件啟動和關(guān)閉，看需要是可以調(diào)整的，如果你只是想知道是不是啟動了，來判斷活躍，那么僅僅需要啟動的時(shí)候發(fā)送個(gè)整型的值標(biāo)識即可；如果想知道更詳細(xì)的信息，比如啟動方式、啟動時(shí)間等等，可以定義結(jié)構(gòu)體，將這一刻更多的信息發(fā)送回來，可靈活定義。

（3）軟件卸載

卸載跟軟件安裝類似，這里就不贅述了。

在這里，如果希望收集用戶的卸載原因，可以定義一個(gè)字符串，將用戶填寫的內(nèi)容上報(bào)，這種形式的數(shù)據(jù)如果太多，不太利于分析，所以看產(chǎn)品情況可靈活設(shè)置。

Android性能優(yōu)化第（八）篇---App啟動速度優(yōu)化之耗時(shí)檢測處理

應(yīng)用的啟動速度緩慢這是很多開發(fā)者都遇到的一個(gè)問題，比如啟動緩慢導(dǎo)致的黑屏，白屏問題，大部分的答案都是做一個(gè)透明的主題，或者是做一個(gè)Splash界面，但是這并沒有從根本上解決這個(gè)問題。那么如何從根本上解決這個(gè)問題或者做到一定程度的緩解？

1、冷啟動：當(dāng)啟動應(yīng)用時(shí)，后臺沒有該應(yīng)用的進(jìn)程，這時(shí)系統(tǒng)會首先會創(chuàng)建一個(gè)新的進(jìn)程分配給該應(yīng)用，這種啟動方式就是冷啟動。

2、熱啟動：當(dāng)啟動應(yīng)用時(shí)，后臺已有該應(yīng)用的進(jìn)程，比如按下home鍵，這種在已有進(jìn)程的情況下，這種啟動會從已有的進(jìn)程中來啟動應(yīng)用，這種啟動方式叫熱啟動。

3、溫啟動 ：當(dāng)啟動應(yīng)用時(shí)，后臺已有該應(yīng)用的進(jìn)程，但是啟動的入口Activity被干掉了，比如按了back鍵，應(yīng)用雖然退出了，但是該應(yīng)用的進(jìn)程是依然會保留在后臺，這種啟動方式叫溫啟動。

adb shell am start -W [PackageName]/[PackageName.MainActivity]

執(zhí)行成功后將返回三個(gè)測量到的時(shí)間：

這里面涉及到三個(gè)時(shí)間，ThisTime、TotalTime 和 WaitTime。WaitTime 是 startActivityAndWait 這個(gè)方法的調(diào)用耗時(shí)，ThisTime 是指調(diào)用過程中最后一個(gè) Activity 啟動時(shí)間到這個(gè) Activity 的 startActivityAndWait 調(diào)用結(jié)束。TotalTime 是指調(diào)用過程中第一個(gè) Activity 的啟動時(shí)間到最后一個(gè) Activity 的 startActivityAndWait 結(jié)束。如果過程中只有一個(gè) Activity ，則 TotalTime 等于 ThisTime。

總結(jié):如果只關(guān)心某個(gè)應(yīng)用自身啟動耗時(shí)，參考TotalTime；如果關(guān)心系統(tǒng)啟動應(yīng)用耗時(shí)，參考WaitTime；如果關(guān)心應(yīng)用有界面Activity啟動耗時(shí)，參考ThisTime。

從我們Application開始到首頁顯示出來，這個(gè)過程，我們應(yīng)該注意一些什么，將這個(gè)過程細(xì)分一下，會有下面的時(shí)間點(diǎn)需要注意。

Application的構(gòu)造器方法——attachBaseContext()——onCreate()——Activity的構(gòu)造方法——onCreate()——配置主題中背景等屬性——onStart()——onResume()——測量、布局、繪制顯示在界面上。

因?yàn)樯厦孢@些階段全部都是在主線程中執(zhí)行的，任何不經(jīng)意的操作都可能拖慢應(yīng)用的啟動速度。所以我們不應(yīng)在Application以及Activity的生命周期回調(diào)中做任何費(fèi)時(shí)操作，具體指標(biāo)大概是你在onCreate，onResume，onStart等回調(diào)中所花費(fèi)的總時(shí)間最好不要超過400ms，否則用戶在桌面點(diǎn)擊你的應(yīng)用圖標(biāo)后，將感覺到明顯的卡頓。但是有些 不得以的任務(wù) 又必須在UI顯示之前執(zhí)行。所以我們要將 任務(wù) 劃分優(yōu)先級。

對于首頁渲染完成后，開始加載，或者延遲加載，延遲加載的目的就是界面先顯示出來，然后加載，但是你覺得要延遲多久呢？在 Android 的高端機(jī)型上,應(yīng)用的啟動是非常快的 , 這時(shí)候只需要 Delay 很短的時(shí)間就可以了, 但是在低端機(jī)型上,應(yīng)用的啟動就沒有那么快了,而且現(xiàn)在應(yīng)用為了兼容舊的機(jī)型,往往需要 Delay 較長的時(shí)間,這樣帶來體驗(yàn)上的差異是很明顯的。延遲加載有一種方式。

極力推薦用第二種，在窗口完成以后進(jìn)行加載，這里面的run方法是在onResume之后運(yùn)行的。關(guān)于這種懶加載機(jī)制，參考 Android應(yīng)用啟動優(yōu)化:一種DelayLoad的實(shí)現(xiàn)和原理(上篇) ，給出了詳細(xì)的解釋。

通過上面我們知道一種懶加載機(jī)制，所以我們可以將Application中和首頁的onCreate中的有些耗時(shí)任務(wù)，放到首頁渲染完畢后加載。如何找出這些耗時(shí)任務(wù)，TraceView就派上用場了，TraceView的用法，移步我的前面的博客 Android性能優(yōu)化第（六）篇---TraceView 分析圖怎么看？

比如在首頁的onCreate中我們進(jìn)行了用戶啟動上報(bào)，這個(gè)進(jìn)行懶加載是不是分分鐘減少139毫秒呢？

在比如在Application里面用到了GSON，將String轉(zhuǎn)化成json,我將這個(gè)移動到懶加載里面，是不是又減少了100毫秒呢？

在比如，有些Application中做了支付SDK的初始化，用戶又不會一打開App就要支付，放在Application中加載干嘛？

此處我們這里舉得例子是優(yōu)化了139毫秒和100毫秒的，其實(shí)真正耗時(shí)的任務(wù)有的有1秒多，都被我優(yōu)化完了，所以trace圖中看不到了，就舉個(gè)了這兩個(gè)例子，還有SharedPreferences也是耗時(shí)大戶，經(jīng)過檢測保存一個(gè)boolean變量耗時(shí)120+毫秒以上。

利用TraceView可以清楚我們每一個(gè)方法的耗時(shí)時(shí)間，極大的幫助了我們做優(yōu)化工作。

五、優(yōu)化思路總結(jié)

1、UI渲染優(yōu)化，去除重復(fù)繪制，減少UI重復(fù)繪制時(shí)間，打開設(shè)置中的GPU過度繪制開關(guān)，各界面過度繪制不應(yīng)超過2.5x；也就是打開此調(diào)試開關(guān)后，界面整體呈現(xiàn)淺色，特別復(fù)雜的界面，紅色區(qū)域也不應(yīng)該超過全屏幕的四分之一；

2、根據(jù)優(yōu)先級的劃分，KoMobileApplication的一些初始化工作能否將任務(wù)優(yōu)先級劃分成3,在首頁渲染完成后進(jìn)行加載，比如：PaySDKManager。

3、主線程中的所有SharedPreference能否在非UI線程中進(jìn)行，SharedPreferences的apply函數(shù)需要注意，因?yàn)镃ommit函數(shù)會阻塞IO，這個(gè)函數(shù)雖然執(zhí)行很快，但是系統(tǒng)會有另外一個(gè)線程來負(fù)責(zé)寫操作，當(dāng)apply頻率高的時(shí)候，該線程就會比較占用CPU資源。類似的還有統(tǒng)計(jì)埋點(diǎn)等，在主線程埋點(diǎn)但異步線程提交，頻率高的情況也會出現(xiàn)這樣的問題。

4、檢查BaseActivity,不恰當(dāng)?shù)牟僮鲿绊懰凶覣ctivity的啟動。

5、對于首次啟動的黑屏問題，對于“黑屏”是否可以設(shè)計(jì)一個(gè).9圖片替換掉，間接減少用戶等待時(shí)間。

6、對于網(wǎng)絡(luò)錯(cuò)誤界面，友好提示界面，使用ViewStub的方式，減少UI一次性繪制的壓力。

7、任務(wù)優(yōu)先級為2，3的，通過下面這種方式進(jìn)行懶加載的方式

8、Multidex的使用，也是拖慢啟動速度的元兇，必須要做優(yōu)化。后面有空專門寫一篇Multidex。

相關(guān)鏈接：

Android應(yīng)用啟動優(yōu)化:一種DelayLoad的實(shí)現(xiàn)和原理(上篇)

Android性能優(yōu)化之加快應(yīng)用啟動速度

手機(jī)淘寶性能優(yōu)化全記錄

Android客戶端性能優(yōu)化（魅族資深工程師毫無保留奉獻(xiàn)）

Please accept mybest wishes for your happiness and success !

分享題目：android埋點(diǎn),安卓埋點(diǎn)怎么設(shè)計(jì)
網(wǎng)頁URL：http://jinyejixie.com/article28/dsdisjp.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供建站公司、企業(yè)網(wǎng)站制作、外貿(mào)網(wǎng)站建設(shè)、手機(jī)網(wǎng)站建設(shè)、網(wǎng)站營銷、網(wǎng)頁設(shè)計(jì)公司

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來源： 創(chuàng)新互聯(lián)