android用戶行為

A. 如何查看android軟體的行為

引言

在一個家庭中，老、幼兩類群體的安全是家庭成員比較擔心的，老人外出購物走丟，初中生上課期間去網吧等事件頻繁發生。針對此類安全問題，本文基於Android設計出位置實時監控系統。由於在Android系統手機上開發，可提高便捷性和普及程度，降低成本。

1 系統總體設計

本系統在整體上可以分成兩大部分，即被監控端和監控端。被監控端和監控端都是在基於Android操作系統的智能手機上開發實現。該系統內數據傳輸可採用WiFi、GPRS或者3G網路等通信模式，定位採用的GPS衛星定位的方式。然後利用位置分析資料庫進行位置數據分析，在手機上載入電子地圖，直觀地顯示被監控端的位置(若出現在非正常區域則進行提醒監控端)。系統總體的結構圖如圖1所示。

3.3 程序實現

一是接收發送過來的經緯度信息。本設計為直觀顯示經緯度信息，在載入地圖的同時，顯示在「簡訊內容：」部分。其接收功能實現代碼如下：

/**
* 監聽收到的簡訊
*/
private final class SmsObserver extends ContentObserver {
public SmsObserver(Handler handler) {
super(handler);
}
public void onChange(boolean selfChange) {
ContentResolver resolver = getContentResolver();
//查到發出的簡訊
Uri uri = Uri.parse("content://sms/inbox");
Cursor cursor = resolver.query(uri, new String[] { "address", "body" }, null, null, "_id desc limit 1");
if (cursor.moveToNext()) {
String address = cursor.getString(0);
if (address.equals("此處為被監控對象的手機號碼")) {
String body = cursor.getString(1);
smsContent.setText(body);
SearchButtonProcess(body);
}
}
}

二是實現電子地圖上的位置顯示。僅僅有經緯度信息，監控者無法直觀地了解被監控對象的方位。所以在監控端軟體上，載入網路地圖實現被監控對象的實時監控，運行結果如圖8所示。其實現代碼如下：

/**
* 對收到的地點發起搜索並顯示在地圖上
*
* @param v
*/
private void SearchButtonProcess(String smsContent) {
try {
// 逗號分隔過濾得到經緯度字元串
String[] point = smsContent.split(",");
// 獲取到的字元串需要轉化成long，然後long值需要乘1e6後轉化為int
String latitudeStr = point[0];
String longitudeStr = point[1];
GeoPoint ptCenter = new GeoPoint((int)(Float.valueOf(latitudeStr)*1e6),
(int)(Float.valueOf(longitudeStr)*1e6));
// 反Geo搜索
mSearch.reverseGeocode(ptCenter);
} catch (Throwable e) {
Toast.makeText(MainActivity.this, "SearchButtonProcess Error", Toast.LENGTH_LONG).show();
}

4 系統測試結果

如果被監控端和監控端都採用Android手機平台，可以充分利用Android提供的豐富的介面，使系統具有更好的擴展性和實用性。該系統進一步改進還可以實現拍照、截圖、標注和查看軌跡等功能。

5 結束語

該系統結構簡單、功能明確，軟體界面方便美觀，設計完成後該系統在自己家庭中進行試用。經過實際生活中的運用證明，該系統可對家中的老人或者孩子進行位置的實時監控，並根據其位置信息家庭成員可以判斷是否正常，及時打電話確保安全。此外在本系統的設計基礎上，添加LED的顯示模塊也可以應用到城市公交當中去，為乘客向導系統(PIS，Passenger Information System)的建立提供了一些方法和思路。還可以通過司機的Android操作系統手機，實現遠程運輸車輛的全程監控，極大地降低成本。

B. Android 12 兼容之行為變更

Android 12 平台包含一些行為變更，這些變更可能會影響您的應用。以下行為變更將影響在 Android 12 上運行的 所有應用 ，無論採用哪種 targetSdkVersion 都不例外。您應該測試您的應用，然後根據需要進行修改，以適當地支持這些變更。

此外，請務必查看 僅影響以 Android 12 為目標平台的應用的行為變更 列表。

在搭載 Android 12 及更高版本的設備上， 滾動事件 的視覺行為發生了變化。

在 Android 11 及更低版本中，滾動事件會使視覺元素發光。在 Android 12 及更高版本中，發生拖動事件時，視覺元素會拉伸和反彈；發生快速滑動事件時，它們會快速滑動和反彈。

如需了解詳情，請參閱 動畫演示滾動手勢 指南。

如果您之前在 Android 11 或更低版本中實現了自定義啟動畫面，則需要將您的應用遷移到 SplashScreen API，以確保它從 Android 12 開始正確顯示。如果不遷移您的應用，則可能會導致應用啟動體驗變差或出乎預期。

如需了解相關說明，請參閱 將現有的啟動畫面實現遷移到 Android 12 。

此外，從 Android 12 開始，在所有應用的 冷啟動 和 溫啟動 期間，系統始終會應用新的 Android 系統默認啟動畫面 。 默認情況下，此系統默認啟動畫面由應用的啟動器圖標元素和主題的 windowBackground （如果是單色）構成。

如需了解詳情，請參閱 啟動畫面開發者指南 。

從 Android 12（API 級別 31）開始，僅當您的應用獲准處理某個通用網路 intent 中包含的特定網域時，該網路 intent 才會解析為應用中的 activity。如果您的應用未獲准處理相應的網域，則該網路 intent 會解析為用戶的默認瀏覽器應用。

應用可通過執行以下某項操作來獲准處理相應的網域：

如果您的應用調用網路 intent，不妨考慮添加一個提示或對話框，要求用戶確認操作。

Android 12 整合了現有行為，讓用戶可以 在沉浸模式下更輕松地執行手勢導航命令 。此外，Android 12 還為 粘性沉浸模式提供了向後兼容性行為 。

Android 設備有許多不同的外形規格，如大屏設備、平板電腦和可折疊設備。為了針對每種設備適當地呈現內容，您的應用需要確定屏幕或顯示屏尺寸。隨著時間的推移，Android 提供了不同的 API 來檢索這些信息。在 Android 11 中，我們引入了 WindowMetrics API 並廢棄了以下方法：

在 Android 12 中，我們繼續建議使用 WindowMetrics ，並且正在逐步廢棄以下方法：

為了緩解應用使用 Display API 檢索應用邊界的行為，Android 12 限制了 API 為不完全可調整大小的應用返回的值。這可能會對將此信息與 MediaProjection 一起使用的應用產生影響。

應用應使用 WindowMetrics API 查詢其窗口的邊界，並使用 Configuration.densityDpi 查詢當前的密度。

為了與較低的 Android 版本實現更廣泛的兼容性，您可以使用 Jetpack WindowManager 庫，它包含一個 WindowMetrics 類，該類支持 Android 4.0（API 級別 14）及更高版本。

首先，確保應用的 activity 完全可調整大小 。

activity 應依賴於來自 activity 上下文的 WindowMetrics 來執行任何與界面相關的工作，尤其是 WindowManager.getCurrentWindowMetrics() 或 Jetpack 的 WindowMetricsCalculator.computeCurrentWindowMetrics() 。

如果您的應用創建了 MediaProjection ，則必須正確地調整邊界的大小，因為投影會捕獲運行投影儀應用的顯示分區。

如果應用完全可調整大小，則 activity 上下文會返回正確的邊界，如下所示：

如果應用並非完全可調整大小，則它必須從 WindowContext 實例進行查詢，並使用 WindowManager.getMaximumWindowMetrics() 或 Jetpack 方法 WindowMetricsCalculator.computeMaximumWindowMetrics() 檢索 activity 邊界的 WindowMetrics 。

注意 ：任何使用 MediaProjection 的庫也應遵循這些建議，並查詢相應的 WindowMetrics 。

Android 12 將多窗口模式作為標准行為。

在大屏設備 (sw >= 600dp) 中，所有應用都將在多窗口模式下運行，無論應用配置為何。如果 resizeableActivity="false" ，應用會在必要時進入兼容模式，以適應顯示屏尺寸。

在小屏設備 (sw < 600dp) 中，系統會檢查 activity 的 minWidth 和 minHeight ，來確定 activity 能否在多窗口模式下運行。如果 resizeableActivity="false" ，則無論最小寬度和高度如何，應用都無法在多窗口模式下運行。

如需了解詳情，請參閱 多窗口模式支持 。

相機應用通常假定設備的屏幕方向和相機預覽的寬高比呈固定關系。但是，大屏設備類型（例如可折疊設備）和顯示模式（例如多窗口和多屏幕）挑戰著這一假設。

在 Android 12 上，請求特定屏幕方向且不可調整大小 ( resizeableActivity="false" ) 的相機應用會自動進入邊襯區人像模式，從而確保相機預覽的屏幕方向和寬高比正確。在可折疊設備和其他具有相機硬體抽象層 ( HAL ) 的設備上，會對相機輸出應用額外的旋轉以補償相機感測器方向，並會剪裁相機輸出以匹配應用相機預覽的寬高比。無論設備屏幕方向如何以及設備是處於折疊狀態還是展開狀態，剪裁和額外的旋轉可確保應用正確呈現相機預覽。

除了 一些例外情況 之外，為了為短時間運行的 前台服務 提供流暢體驗，搭載 Android 12 或更高版本的設備可以將前台服務通知的顯示延遲 10 秒。此更改使某些短期任務可在顯示通知之前完成。

Android 11（API 級別 30）引入了 受限存儲分區 作為應用待機模式存儲分區。從 Android 12 開始，此存儲分區默認處於活躍狀態。在所有存儲分區中，受限存儲分區的優先順序最低（限制最高）。存儲分區按優先順序從高到低的順序排列如下：

除了使用模式之外，系統還會考慮應用的行為，以決定是否要將您的應用放在受限存儲分區中。

如果您的應用更負責地使用系統資源，就不太可能被放在受限存儲分區中。此外，如果用戶直接與您的應用互動，系統會將其放在一個限制較少的存儲分區中。

如需檢查系統是否已將您的應用放在受限存儲分區中，請調用 getAppStandbyBucket() 。如果此方法的返回值為 STANDBY_BUCKET_RESTRICTED ，則您的應用在受限存儲分區中。

如需測試您的應用在系統將其放在受限存儲分區中時的行為，您可以手動將您的應用移至該存儲分區。為此，請在終端窗口中運行以下命令：

在搭載 Android 12 或更高版本的受支持設備上，用戶可以通過按一個切換開關選項，為設備上的所有應用啟用和停用攝像頭和麥克風使用許可權。用戶可以從 快捷設置 訪問可切換的選項（如圖 1 所示），也可以從系統設置中的「隱私設置」屏幕訪問。

詳細了解這些 切換開關 以及如何檢查您的應用是否遵循了關於 CAMERA 和 RECORD_AUDIO 許可權的最佳實踐。

在搭載 Android 12 或更高版本的設備上，當應用使用麥克風或相機時，圖標會出現在狀態欄中。

詳細了解這些 指標 以及如何檢查您的應用是否遵循了關於 CAMERA 和 RECORD_AUDIO 許可權的最佳實踐。

[圖片上傳中...(image-bd519-1643780883994-1)]

<figcaption style="box-sizing: inherit; font-size: 14px; margin-top: -4px;"> 圖 1. 「快捷設置」中的麥克風和攝像頭切換開關。</figcaption>

[圖片上傳中...(image-f49bfd-1643780883994-0)]

<figcaption style="box-sizing: inherit; font-size: 14px; margin-top: -4px;"> 圖 2. 麥克風和攝像頭指示標志，顯示了最近的數據訪問。</figcaption>

在搭載 Android 12 或更高版本的設備上，根據應用對其他應用的 軟體包可見性 ，以 Android 11（API 級別 30）或更高版本為目標平台且調用以下某種方法的應用會收到一組過濾後的結果：

Android 12 移除了之前棄用的加密演算法的許多 BouncyCastle 實現，包括所有 AES 演算法。系統改用這些演算法的 Conscrypt 實現。

如果符合以下任何條件，則此變更會影響您的應用：

在 Android 12 及更高版本中，當某個應用首次調用 getPrimaryClip() 以 從另一個應用訪問剪輯數據 時，會彈出一個消息框消息，通知用戶對剪貼板的訪問。

消息框消息內的文本包含以下格式： <var translate="no" style="box-sizing: inherit; color: var(--devsite-var-color); -webkit-font-smoothing: auto; font-weight: 500;">APP</var> pasted from your clipboard.

注意 ：您的應用可能會調用 getPrimaryClipDescription() 以接收有關 剪貼板上當前數據的信息 。當您的應用調用此方法時，系統不會顯示消息框消息。

在 Android 12 及更高版本中， getPrimaryClipDescription() 可以檢測到以下詳細信息：

為了加強用戶與應用和系統互動時的控制，從 Android 12 開始，棄用了 ACTION_CLOSE_SYSTEM_DIALOGS intent 操作。除了 一些特殊情況 之外，當應用嘗試 調用包含此操作的 intent 時，系統會基於應用的目標 SDK 版本執行以下操作之一：

在以下情況下，應用仍然可以在 Android 12 或更高版本上關閉系統對話框：

為了維持系統安全並保持良好的用戶體驗，Android 12 會阻止應用使用 觸摸事件 ，使用觸摸事件時疊加層會以不安全的方式遮掩應用。 換言之，系統會屏蔽穿透某些窗口的觸摸操作，但 有一些例外情況 。

此變更會影響選擇讓觸摸操作穿透其窗口的應用，例如使用 FLAG_NOT_TOUCHABLE 標志。包括但不限於以下示例：

在以下情況下，允許執行「穿透」觸摸操作：

如果系統屏蔽觸摸操作， Logcat 會記錄以下消息：

在搭載 Android 12 或更高版本的設備上，不受信任的觸摸功能默認被屏蔽。如需允許不受信任的觸摸操作，請在終端窗口中運行以下 ADB 命令 ：

如需將行為還原為默認設置（不受信任的觸摸操作被屏蔽），請運行以下命令：

Android 12 更改了在按下「返回」按鈕時系統對為其任務根的啟動器 activity 的默認處理方式。在以前的版本中，系統會在按下「返回」按鈕時完成這些 activity。在 Android 12 中，現在系統會將 activity 及其任務移到後台，而不是完成 activity。當使用主屏幕按鈕或手勢從應用中導航出應用時，新行為與當前行為一致。

注意 ：系統僅會將新行為應用於為其任務根的啟動器 activity，即使用 ACTION_MAIN 和 CATEGORY_LAUNCHER 聲明 intent 過濾器 的 activity。對於其他 activity，在按下「返回」按鈕時，系統會像以前一樣完成 activity。

對於大多數應用而言，此變更意味著使用「返回」按鈕退出應用的用戶可以更快地從 溫狀態 恢復應用，而不必從 冷狀態 完全重啟應用。

建議您針對此變更測試您的應用。如果您的應用目前替換 onBackPressed() 來處理返回導航並完成 Activity ，請更新您的實現來調用 super.onBackPressed() 而不是完成 Activity。調用 super.onBackPressed() 可在適當時將 activity 及其任務移至後台，並可為不同應用中的用戶提供更一致的導航體驗。

另請注意，通常，我們建議您使用 AndroidX Activity API 提供自定義返回導航 ，而不是替換 onBackPressed() 。如果沒有組件攔截系統按下「返回」按鈕，AndroidX Activity API 會自動遵循適當的系統行為。

在 Android 12 中，無論顯示屏是否支持無縫過渡到新的刷新率，都會發生使用 setFrameRate() 實現的刷新率變化；無縫過渡是指沒有任何視覺中斷，比如一兩秒鍾的黑屏。以前，如果顯示屏不支持無縫過渡，它在調用 setFrameRate() 後通常會繼續使用同一刷新率。您可以調用 getAlternativeRefreshRates() 來提前確定向新刷新率的過渡是否有可能是無縫過渡。通常，會在刷新率切換完成後調用回調 onDisplayChanged() ，但對於某些外接顯示屏，會在非無縫過渡期間調用該回調。

以下示例說明了您可以如何實現此行為：

Android 12 中添加了以下 API：

如需創建 Passpoint 建議，應用必須使用 PasspointConfiguration 、 Credential 和 HomeSp 類。這些類描述了 Wi-Fi Alliance Passpoint 規范 中定義的 Passpoint 配置文件。

如需了解詳情，請參閱 適用於互聯網連接的 Wi-Fi 建議 API 。

Android 12 包含更新後的受限制非 SDK 介面列表（基於與 Android 開發者之間的協作以及最新的內部測試）。在限制使用非 SDK 介面之前，我們會盡可能確保有可用的公開替代方案。

如果您的應用並非以 Android 12 為目標平台，其中一些變更可能不會立即對您產生影響。然而，雖然您目前仍可以使用一些非 SDK 介面（ 具體取決於應用的目標 API 級別 ），但只要您使用任何非 SDK 方法或欄位，終歸存在導致應用出問題的顯著風險。

如果您不確定自己的應用是否使用了非 SDK 介面，則可以 測試您的應用 來進行確認。如果您的應用依賴於非 SDK 介面，您應該開始計劃遷移到 SDK 替代方案。然而，我們知道某些應用具有使用非 SDK 介面的有效用例。如果您無法為應用中的某項功能找到使用非 SDK 介面的替代方案，應 請求新的公共 API 。

如需詳細了解此 Android 版本中的變更，請參閱 Android 12 中有關限制非 SDK 介面的更新 。如需全面了解有關非 SDK 介面的詳細信息，請參閱 對非 SDK 介面的限制 。

C. Android端的用戶行為統計和日誌打撈方案

        提到移動客戶端的優化，大家首先想到的可能就是頁面的流暢度，也就是CPU和GPU的渲染問題，以此來提升用戶的體驗，然而對於CPU和GPU渲染的優化又是APP優化的兩把尖刀，讓一個app提升用戶量和體驗度有較高的推動力。然而讓我們無法預估的就是用戶的實際操作，也就是已經發出去的版本，我們很難知道用戶喜歡什麼功能和他們想要什麼功能以及他們習慣於什麼樣的操作姿勢，包括用戶安裝、卸載不用的情況，並且對潛在的線上崩潰問題，作為一位開發者我們就很想知道錯誤出現的精確位置以及錯誤信息，這些對一個APP的成長來說將是一個關鍵的導向作用，其實這也算是APP的一個比較重要的優化方案。

           對於以上出現的問題，開發者更關心APP的Crash問題，而對於產品來說，他們更關心用戶的喜好、行為和需求，以便於產品設計出更好的需求解決方案，目前市場上也出現了專門的問題解決方案，比如友盟統計、bugly統計、小米統計等，對於一個小型方案我們可以採用第三方的統計方案，但對於一個日活百萬乃至千萬的APP來說用第三方的統計方案就會受限很多，於是擁有自己的一套統計方案就顯的刻不容緩了，掌握市場的方向，我們就掌握了主動權，那麼我們怎樣去設計一套准確優良的統計方案。

1.1 傳統的pc端統計

以老牌的pc上的web頁面統計一般有PV.UV,和IP之分，對於crash問題，本身web頁面就存在遠程的伺服器端，日誌將會保存在伺服器的目錄，所以一般web項目開發者無需考慮收集Log的case,那麼我們更care的就是上面說的行為統計，下面說說這三種統計區別。  

2. 2、IP、PV和UV分別是什麼意思?

IP，實際上也就是指獨立IP,是獨立IP數的意思。00:00—24:00時間內相同IP地址只記錄一次。即使你有多台電PC，但是如果IP地址是一樣的，那麼也只能算是一個IP的訪問,IP數據依然為1。當然多台pc的ip一般都不一樣，除非你插上同一個網路埠然後換零一台連接，都是一樣，同時連接多台，每台pc的IP就是不一樣的。

PV, 指訪問量，它的英文是PageView，具體是指網站的是頁面總瀏覽量或者點擊量，頁面被刷新一次就計算一次。如果網站被刷新了10次，那麼流量統計工具顯示的PV就是10 。

UV，它是獨立訪客的意思，英文為Unique Visitor。具體指訪問您網站的一個客戶端(移動設備或者是電PC)為一個訪客。00:00-24:00內相同的客戶端（mac地址區分）只被計算一次。

3 . 3 IP、PV和UV之間的關系是什麼?

1.3.1.IP和PV之間的關系

PV是和IP的數量是成正比的，因為頁面被刷新一次那麼PV就會被記錄一次，所以IP越多，說明網站的PV數據也就隨之增多。但是需要注意的是PV並不是網站的頁面的訪問者數量，而是網站被訪問的頁面數量。因為一個訪問者可以多次刷新頁面，增加PV數量。

1.3.2 .IP和UV之間的關系：

在記錄網站流量統計數據時，運維有時候發現這樣一種情況：有時候網站的IP數據大於UV數據，有時候UV的數據也會大於IP數據。為什麼會出現這種現象呢?我們可以用一個例子來說明。比如，用同一個IP去訪問我們的某個網站，但是一個是用的台式的電腦，一個是用的筆記本，那麼網站流量統計工具顯示的數據就會是2個UV，1個IP。這時UV的數據就會大於IP的數據。但是，再比如，只是用一個台式電腦訪問我們的網站，但是一會撥一個號換一個IP，那麼這時候網站流量統計工具顯示的數據的UV就為1，但是IP的數據就會高於UV的數據。因此，IP和UV之間的數據並不一定存在比例關系，兩者之間的數據也不是此消彼長的關系。

1.3.3.IP和PV之間的關系：

那麼IP和PV的關系如何呢?如果一個IP刷新了網站100次，網站的PV就為100，所以從這點看二者之間沒有多大關系。但是，我們可以通過IP和PV之間的數據差異，來更加深入的理解網站的流量數據。如果IP和PV的數據懸殊很大，比如，我們在查看網站流量數據時發現網站的PV是1000,IP為100，那麼說明這個站點平均一個IP訪問了網站內容10次，說明網站內容還是比較受歡迎的，所以訪客才願意在網站中停留那麼久的時間，並瀏覽了那麼多的網站頁面內容。但是如果IP和PV的數據很接近，比如，網站的IP為100，PV為110，說明一個IP也就訪問了網站內容大約1次，就說明網站內容的可讀性太差，客戶點擊進去之後就離開了，沒有有過多的停留。如果網站流量統計這樣的數據過多的話，站長就需要對網站內容進行深入思考了，以便更好的提高網站的流量。

1.4 我們能從這邊得到什麼

鑒於已經很成熟的統計方案，我們在移動設備上（這里只說android）怎樣實現一個完美的用戶數據和行為統計，崩潰日誌的套裝方案呢。

那麼我們的一個App，我們能做的那些方面呢

2.1 .1 用戶數據（日活）

首先我們的可以加入ip，PV和UV統計模式，這樣我們可以成功的get到app的日活，以及整體使用情況， 

比如App啟動了多少次，訪問了多少h5頁面，有多少個ip(設備)訪問過，但是我們無法得native頁面的信息（也就是Activity）服務端是是無法獲取的，除非我們本地的頁面有載入服務端數據的介面的功能，這種情況下服務是可以監控到本頁面的數據流量的，但是在斷網情況下，服務端是無法及時獲取日活數據的，那麼怎麼解決呢，這里先不說，先看下個要解決的問題。

2.1.2 用戶行為

獲取到了APP整體流量後，怎麼能知道某個功能受歡迎，或者某個本地頁面經常被用戶使用呢，則具體行為統計是app必須的， 目前一般由客戶端和伺服器端協商好一套自定義事件字典（也就是所謂的統計id對照表），當用戶使用某個功能時，我們將對應的功能id發送到後台。這樣服務端就有統計用戶行為的能力了，那麼這種只是一種初次嘗試的想法，那麼斷網，或者功能多的情況子下，我們有如何採集用戶行為呢

2.1.3 Log日誌

那麼對於線上的app版本，又是怎樣收集carsh日誌呢。一般我們在app崩潰的時候發送一條請求到服務端，是可以實現的，但沒必要做，一般是將日誌保存到本地，在某個時間或者case觸發上報行為，

三 綜合方式。

一般統計策略不會採用單一的方式進行上報，多採用組合的形式實現，伺服器和客戶端，有網和沒網，實時和不定時。主動和被動的策略。

1 服務端

客戶端請求介面是 統一包含特定的請求頭，服務端的每個介面中可以去採集這些請求頭 記錄訪問量 包括ip，PV,UV , 這樣可以去捕獲一定的用戶數據。

服戶端也可以採用推送的形式，讓客戶端去發送特定的採集好信息上報給伺服器。

2 客戶端

統計一般大多體現在客戶端，我們可以將一個整體的app分解成多個模塊，每個模塊有多個功能，功能又分為用戶主動和被動接受之分，給每個域分配一定的ID，那麼在用戶使用某個功能時 我們動態記錄這個ID（比如登陸和注冊一般屬於用戶中心（001）,登陸和注冊輸入兩種功能，分別給03,04標記，登陸屬於用戶主動 那麼可以給 01，注冊被動跳轉給02）, 最後寫入到本地保存，那麼用戶打開用戶中心登陸產生的的數據信息就0010201 ，這樣伺服器能知道，我們只要在某個時間點將文本數據上傳即可，即使沒網路情況下我們也不怕，等設備有網的情況下 我們偷偷上報即可，那麼我們也可以在用戶登陸的時候時侯同時就上傳這些數據，這個策略視具體功而定。 

一般一個APP統計有模塊域 ，功能域，事件域，由大到小分配而來，也有按頁面區分的，具體看實際的需求場景而定

對於我們的app crash 我們可以繼承android自帶的全局異常類（UncaughtExceptionHandler），來進行自我捕獲異常，和用戶行為一起上報。

也可以單獨加個意見反饋功能，採集用戶的吐槽和建議。

說了上面一大堆策略問題，對於開發而言很可能覺得很無聊，那麼至於統計其實沒什麼技術含量（用戶設備的唯一標識符除外），無非就是採集數據寫到文件中，請求發送數據，最重要的還是一種策略的定義。

主流的多採用 時間戳，內存大小（日誌積累到多大位元組），次數（總計積累到多十條）等，

對於好的統計，我們可以檢測網路，檢測home建來觸發我們的上報數據介面，也可以採用注冊靜態廣播，用alarm 鬧鍾定時上報數據，然後這些技術也就是被大家玩透的功能而已，沒必要再這里給大家補腦，但是注意的是

統計設備唯一標識符的確定， 這個以後再去分析.

統計上報介面採用分布式，不然所有數據都請求同一個介面，那麼日活大的情況下，伺服器掛了 不僅無法收到數據，反而影響客戶端其他正常的功能

D. android 應用如何檢測用戶截屏行為

• 下一個手機專家，檢測

E. 用戶行為特徵

用戶行為特徵

用戶行為特徵，對於運營來說用戶的行為是需要關注的一個點，很多時候用戶的行為決定了一個網站甚至是一個軟體能否繼續運運營下去，所以通常都是要對於用戶行為特徵進行一個分析，下面一起看看相關內容。

用戶行為特徵1

用戶行為是用戶在產品上產生的行為，實際表現為相關的用戶數據。產品經理運用不同分析方法對不同數據進行分析，進而為產品迭代和發展提供方向。

一、用戶行為是什麼？

1、用戶行為

用戶行為是用戶在產品上產生的行為。我們以小明的case具象化用戶行為表現：

因為小明關注作者的信息被記錄了下來，當該作者有發布信息時，則會通知所有關注他的人，而小明也是其中之一。

小明關注作者的信息記錄，則是行為數據。小明的行為數據會有 啟動app、瀏覽、查看圖集、播放視頻、點贊、關注作者……

2、用戶行為數據

用戶行為數據是從一次次的行為中而來的，行為數據是通過埋點進行監控（相見埋點介紹）、後續一篇文章將介紹如何（設計埋點）。通常是數據同學完成埋點設計，由開發完成監控程序 或 調用SDK。針對小明的行為（假設以下均已埋點）：

3、用戶行為分析

是指對用戶行為數據進行數據分析、研究。

4、用戶行為分析的作用

（1）通過用戶行為分析，可以還原用戶使用的真實過程。

一個xxx的人在什麼樣的環境中（由於什麼樣的行為）在時間點做了xxx事情做了什麼事情結果如何

（2）「了解用戶，還原用戶」是「以用戶中心」的第一步。只有詳細、清楚的了解用戶的行為習慣、真實的使用路徑、進而找出 產品使用、渠道推廣等過程中存在的問題，提高用戶/頁面/業務過程中的轉化率。

（3）用戶行為分析（case需要補充）可以用於

A、拉新：渠道分析、SEM分析、用戶質量分析、

B、轉化：新增用戶注冊轉化過程、產品使用過程轉化（搜索、推薦等）、push推送調起過程、站外拉起過程

C、促活：用戶停留時長、用戶行為分布、

D、留存：用戶留存分析

E、商業化：根據用戶歷史行為展示廣告

二、如何進行用戶行為分析？

1、行為事件分析

行為事件分析方法主要用於 深度研究某行為事件，以及對產品的影響以及影響程度。

針對某一具體行為，全面的描述、對比，針對其異常表象 深度下鑽分析各維度、確認導致該行為數據表現的原因。如快手的播放量徒增:同期對比分析，確認歷史上是否有發生過，對比 去年/上個季度/上月/上周/昨日的 數據的相對表現。多事件對比分析。對比瀏覽量、點贊、評論、分享事件的數據是否存在徒增。通過對比多個事件，確認徒增現象發生的范圍。維度下鑽：由於播放量取決於3個部門用戶在快手消費視頻，被監控程序上報。

所以在三個方面分析：

監控程序是否異常？在快手哪個頁面的播放量增加呢？是發現、關注、還是同城？-> 對應頁面做了哪些調整？是否增加了引流；哪一部分用戶群的播放量增加了？交叉分析 用戶自然屬性（平台、性別、年齡、地域、教育學歷、機型、消費能力）、行為屬性（新增、迴流、常活躍用戶；直播用戶、短視頻用戶…、）、視頻屬性（視頻類型、作者類型…、）

2、留存分析

留存是衡量用戶是否再次使用產品的指標，也是每一個app賴以生存的指標，能夠反映任何一款產品健康度，是產品、運營、推薦效果的整體表現。如果一個app從來沒有留存用戶，那DAU將永遠是新增用戶，那麼產品將無法運行下去，更別說新用戶成本付諸東流。

貼合業務屬性、精細化留存過程 將對留存數據更有價值和指導意義。通過留存分析，能夠剖析用戶留在產品的原因，從而優化產品核心功能提升留存。

留存的類型：

用戶留存：用戶使用app後，經過一段時間仍舊使用。功能留存：用戶使用xxx功能後，經過一段時間仍舊使用該功能，且其他功能均有所變化。此時，該功能對用戶留存有正向作用。先前有寫過 留存分析的文章，這里就不贅述了。

3、漏斗分析

漏斗分析實質是轉化分析，是通過衡量每一個轉化步驟的轉化率，通過轉化率的異常數據找出有問題的環節並解決，進而實現優化整個流程的完成率。

在產品初期(處於與市場適配的階段)：通過漏斗分析找到用戶觸達的瓶頸，幫助用戶觸達產品核心價值，真實反映MVP與市場匹配程度；在產品中期(處於用戶平穩增加的階段): (1)通過漏斗分析優化渠道，找到目標群體用戶; (2)通過漏斗分析優化用戶在各模塊的體驗(基礎的登錄模塊、產品核心價值模塊: 如抖音的播放模塊、淘寶的購買模塊等)；在產品後期(處於用戶價值產出的階段): (1)通過漏斗分析可以改善用戶生命周期(優化用戶體驗提高用戶生命周期，間接拉長用戶群體的價值產出的時間長度，減少高價值用戶群體的流失)；(2)可以通過漏斗分析優化商業化模塊，像商品的購買過程（購物車-提交訂單的轉化漏斗）、廣告的曝光點擊等，提高生命周期中單位時間產生的價值。

4、路徑分析

路徑分析可以將紛雜的app日誌按照用戶的使用過程，呈現出「明確的」用戶現存路徑。發現路徑問題，進而優化，使用戶盡可能短路徑體驗到產品核心價值。

通過路徑分析，可以了解到像小明這樣9點左右播放視頻的用戶：他們是通過push點擊而來，這部分用戶佔比是多少；他們匆匆結束播放，再也沒有下一步行為，這部分用戶佔比又有多少。針對他們利用碎片化時間播放視屏的場景，尤其是突然退出的'場景，是否在下一次打開app時，仍舊打開終端的視頻。是否有其他策略可以針對該場景來優化？

此外，路徑分析不僅僅可以用於行為路徑分析，也可以用於用戶群體轉化分析。例如：新用戶中分別轉化為 忠實用戶、常活躍用戶、潛在流失用戶、流失用戶的分析。

5、用戶分群分析

通過了解用戶畫像，可以幫助運營理解用戶。根據用戶畫像（基本屬性、用戶偏好、生活習慣、用戶行為等）的標簽信息將用戶分群。

通過用戶分群行為表現對比，可以進一步了解不同群體對產品的反饋，有針對性的優化產品。

發現中 西南地區的低端機型使用app時，奔潰率特別高，開發可以針對該點進行優化、降低奔潰率；可以針對不同的用戶群體的行為表現 做 定向投放、push等，從而實現精細化運營。業內的商業化行為分析產品，基本上將用戶畫像的生成、標簽的過程均合並在用戶分群的群體定義中，降低了操作流程。

三、用戶行為分析的完整鏈路

以小明為case的用戶行為每天數以萬/億計的產生，如何對「這類人群」進行「行為分析」？需要行為分析將明細級別的日誌聚合後再以較為可讀的形式展示出來。

為了保障埋點可靠、數據上報及時、行為數據分析有效。需要一套完整的用戶行為系統，包括從數據埋點設計、埋點開發、數據上報、數據模型開發、行為數據分析。 過程中也需要多方協作完成，如何保障多方協作中高效、便利的完成、產出具有業務價值的數據分析結論。後續將介紹服務於用戶行為分析的相關平台介紹。

用戶行為特徵2

一、什麼是用戶行為

中國有句古話「天地四方為宇，古往今來為宙」，這句話揭示了空間和時間的概念。我們要想透徹地研究任何事物，常以時間和空間兩個維度來考慮。分析用戶行為也不例外。

換句話說，用戶行為的研究內容可以按照時間和空間維度展開。

從時間的維度來看，按照管理學大師菲利普科特勒的理論，用戶的行為軌跡包括：產生需求、信息收集、方案比選、購買決策；購後行為5個階段。其中購後行為包括使用習慣、使用體驗、滿意度、忠誠度等。

從空間的維度來看，用戶行為的構成要素包括5W2H，例如我們要全面描述用戶在購買階段的行為，就要回答這樣的問題，誰（who）？打算在什麼時候(when)？什麼地方(where)？買什麼東西(what)？產生需求的動機是什麼（why）？打算買多少（how much）？如何買（how）？同理，在使用階段也可以從這7個要素來描述。

5階段和7要素的結合，形成了用戶行為分析的研究體系。這個體系細化了用戶行為的研究內容，基於這些內容，就有了用戶調查問卷的一些基本的問題。

二、為什麼分析用戶行為（Why）?

之所以分析用戶行為，是為了找到用戶行為的特徵，從而為企業的經營提供支持。

大家想想，用戶行為具有哪些特徵呢？

Q1: 用戶行為是同質化的，還是差異化的？

A1：差異化的，因此用戶行為具有差異性

Q2:用戶行為是靜態不動的，還是動態變化的？

A2:動態變化的，因此用戶行為具有流動性

Q3:用戶行為是相互隔絕的，還是相互影響的？

A3:相互影響的，因此用戶行為具有傳播性

差異性、流動性和傳播性是用戶行為的三個顯著特徵。那麼，這些特徵具體是如何表現的，分析這些特徵對企業的經營有什麼作用？

這里我們只談差異性，後面的博文中會談流動性和傳播性。

用戶行為從時間和空間的維度，分為5階段7要素。因此用戶的差異性，就表現在這5階段和7要素上。例如，在產生需求階段，用戶的需求動機why不同。同樣是買電腦，有的是為了工作、有的為了學習、有的是為了消遣；再比如，在信息收集階段，用戶的信息收集渠道where不同。同樣是買房子，有的看網路廣告；有的聽朋友介紹；有的到現場采點。

這里只舉了兩個階段，你能說出在其他階段用戶的差異性表現嗎？

意識到用戶的差異性，企業的營銷工作就不會搞一刀切，就不會拿大炮轟蚊子，而是會進行市場細分和目標市場選擇，然後針對目標用戶進行精準營銷。這種精準營銷體現在市場定位、競爭戰略選擇、品牌形象和營銷組合等很多方面。

三、如何分析用戶行為(How)？

這里我們只談差異性，後面的博文中會談流動性和傳播性。

我們前面談到因為用戶行為具有差異性，因此需要進行市場細分和目標市場選擇，那麼如何進行市場細分和目標市場選擇呢？

市場細分的思路是看看從哪個維度切分市場，使所分得的細分市場內部具有的共性，細分市場之間具有個性。從哪個維度切要結合企業所處的行業特點的。例如食品市場，地域差異比較明顯，南甜北咸東辣西酸，所以食品市場可按地域分；服裝市場，性別差異非常突出，男款少而精；而女款多而靚，所以服裝市場可按性別分。此外二八原則，也廣泛用於市場細分，即我們可以按重要程度將用戶分為大中小三類。重要性可以有很多評價指標，比如規模、綜合實力、業內影響力、對企業的貢獻率、在同類產品上的總投入等等。

將市場劃分成幾個細分市場後，企業就面臨著目標市場選擇的問題。如何選擇目標市場呢？這是一個團體決策的過程，在選擇目標市場時往往需要企業的管理人員和骨幹營銷人員坐在一起討論來確定。討論共有五步進行

第一步指標的選擇需結合企業自身的實際情況。例如，我是大企業，規模經濟是我的優勢，那市場規模就是我選擇的重要指標；我是中小企業，我要更關注競爭的激烈程度，因為競爭太激烈了，我可能無法存活。因此，競爭強度就是我選擇的重要指標。

第二和第三步確定優先順序和為指標打分的方法可參考小蚊子的《誰說菜鳥不會數據分析》中的權重確定方法

第四步的綜合得分是第二步和第三步的結果加權平均得到。

第五步選擇目標市場可以企業適應度和市場吸引力為橫縱坐標，得出各個細分市場在四個象限中的位置。

六款免費的用戶行為分析工具測評

中國移動互聯網市場經過幾年的高速發展，增速已經明顯放緩，人口紅利逐漸消失。移動互聯網進入了下半場，市場競爭已經從增量用戶競爭逐步轉化成為存量用戶競爭。同時伴隨流量紅利消失，數據紅利時代已經到來，流程驅動性公司正轉變為數據驅動的數字公司，競爭從同業蔓延至異業競爭，跟隨用戶，跨場景地滿足用戶的需求將會成為數據紅利時代最核心的訴求。

如果說數字化轉型不可逆，那麼對於用戶的精細化運營將會是數字化轉型的支撐點之一。要實現對用戶的精細化運營，必不可少要對用戶行為進行分析。比如對網站、APP等渠道的用戶行為數據進行採集，對獲取到的用戶行為數據進行多維度、多角度對比分析，用以指導提升獲客效率、優化產品服務和用戶體驗，以數據驅動業務持續增長。

但目前來看，距離要實現這一目標，還有一定的差距。由於日常工作中，大家的分工不同，僅關注某一個方面的數據顯然不夠，無法全面了解產品運營情況，更不能提出行之有效的分析建議。

現在的情況是在公司內，業務部門想要看數據，會先提出自己的數據需求，這時候需要找到技術人員或者數據分析師，根據需求寫SQL將數據從庫里提出來，交給數據分析師進行分析，形成對應報表之後，再發給業務部門查看，完成整個過程沒個三五天搞不定，數據分析的時效性大大降低。

企業採用用戶行為分析工具，可以讓產品、運營、市場、數據等業務部門更方便的分析數據，讓技術部門日常面對的零碎需求更少，能把等多精力放在建立數據倉庫等核心工作上。

當我們在做產品開發或者產品運營時，通常需要第三方工具去做用戶行為分析以提供數據支持。因此免費產品的試用成了大家在前期選擇工具的必要方式。為了方便大家對目前市場上的用戶分析工具有一個清晰的了解，我們在試用了大量的工具後，分別從數據接入、數據分析、安全與拓展幾個方面進行了綜合分析。

許多人都在問，市場上有沒有免費的用戶行為分析工具，答案是有的！不過各家各有特點，國外知名用戶行為數據分析工具像Google Analytics（以下簡稱GA）、Mixpanel，國內有網路統計、易觀方舟Argo、友盟、TalkingData免費版（以下簡稱TD免費版）。

01、數據接入

談到數據接入，首先需要說明的是幾個產品在數據模型上的差別。

GA、網路統計誕生於傳統PC互聯網時代，都是以傳統的頁面瀏覽（PV）和用戶會話（Session）為核心。其中GA經過多年演進，增加了一些關於事件分析和自定義屬性的內容，但本質上主要還是服務於頁面類的產品。網路統計還是依然只支持頁面和會話統計。

隨著移動互聯網時代到來，用戶的行為觸點變多，以往以頁面和會話為中心所能採集到的結構化數據顆粒度不夠細，頁面和會話模型已經不適用了。因此，基於「用戶+事件（User+Event）」模型出現了，在分析的時候可以完全自主的定義需要分析的事件，並從不同的屬性維度進行交叉分析。剛推出不久的易觀方舟Argo，以及Mixpanel、友盟、TalkingData免費版都採用了 「用戶+事件」模型。

在埋點方面，目前根據埋點的工具和方式，可以劃分為三種類型：代碼埋點，可視化埋點和全埋點，並沒有說哪一種方式能夠碾壓其他幾種，因為都各有弊端，具體的各種埋點方法的分類與優缺點我們也做一下對比：

下面我們看一下市面上幾家免費的數據分析產品之間在數據接入方面對比。需要注意的是由於GA、Mixpanel都是國外產品，在數據採集的規則適配了iOS、Android的設計規范，但國內開發者常常直接忽視這些設計規范開發產品，而GA、Mixpanel在數據採集上沒有針對國內產品的特點進行優化，因此在數據採集的准確性上可能會受到一些影響。

另外，需要提到的一點是Mixpanel和易觀方舟Argo的數據採集SDK開放了源代碼，一定程度上可以打消企業在數據採集安全方面的顧慮。

02、數據分析

數據分析是用戶行為分析工具的核心，除了網路統計以外，其他幾款產品都可以滿足用戶行為數據分析的基本需求，但在功能的豐富程度上不盡相同。具體對比可以看下錶。

從分析模型豐富程度上來看，Mixpanle和易觀方舟Argo是裡面功能最全的，堪稱全家桶，唯一遺憾的是目前易觀方舟Argo目前尚不支持熱圖分析。比如最常用的「事件分析」這個功能，不止可以從PV、UV等方面進行分析，還可以根據不同的屬性值設定具體的指標按照不同的維度進行對比，功能非常強大。

從數據准確性上來看，GA在演算法的嚴謹性上應該是最好的，但如果用戶或者事件量比較大的時候，會採取抽樣分析，可能會影響到數據的准確性，Mixpanel的免費版本也會存在類似的問題。易觀方舟Argo在這方面表現搶眼，在數據計算上支持秒級實時數據分析、自定義指標、多維多人群指標對比、人群交叉分析、智能分析、數據實時回傳、即席數據分析等。

從數據管理、項目管理、許可權管理這些常用的管理功能方面來看，幾款工具都提供了比較友好的支持。但僅有友盟+提供了手機app，可以隨時通過手機查看監測的數據情況，易觀方舟Argo支持通過手機瀏覽器訪問查看數據看板。

另外，值得一提的是易觀方舟Argo裡面的用戶運營和觸達功能。目前易觀方舟Argo可以在完成用戶分析與分群後，通過郵件、簡訊、Push消息等方式對目標用戶進行觸達，還支持配置UTM追蹤參數對廣告進行跟蹤。

03、安全與拓展性

企業級產品在數據安全性和可拓展性上，需要提前做一些考量，幾款產品也各有側重，具體對比情況如下表所示：

（點擊圖片可查看清晰大圖）

GA免費版 和 Mixpanel 提供的都是SaaS服務，但因為伺服器都在國外，在國內使用起來穩定性和刷新速度上可能會有一定的影響；網路統計、友盟統計、TD免費版基本上都是SaaS服務；易觀方舟Argo提供安裝包，可由企業自己私有部署，如果對數據安全有顧慮，易觀方舟Argo是個不錯的選擇。在服務方面，除了GA和易觀方舟Argo可提供社區服務支持以外，其他產品目前還沒有完善的用戶服務支持。

總結

對比來說，剛推出不久的易觀方舟Argo，在數據採集、數據分析能力上，已經可以滿足產品數據和用戶行為數據分析的需求，而且提供了獨家的一站式用戶運營和用戶觸達。與目前其他國內的免費工具產品對比來說，易觀方舟Argo在顆粒度細致程度、分析模型全面性、系統性能方面表現優秀。

目的，大多數成長型團隊、創業團隊的市場及運營預算都相對緊張，每一分投出去的錢恨不得立馬知道什麼時候能轉化回來，如果自己搭建一套完整的數據分析平台要花費的功夫肯定不少。相信更多性能全面的用戶分析和運營分析工具的免費開放，能避免企業在市場運營方面走彎路；也能解放團隊更專注的在業務上，通過用戶行為分析提升營銷效率、優化迭代產品、留住更多用戶，真正用數據指導和驅動業務。

最後，這次選型過程中，在易觀方舟Argo社區交流感受較好，現在市面上能見到的免費工具產品不少，但真正形成自己技術服務社區的不多。相信未來他們能把這個社區做的更好，就像當年小米運營MIUI做社區一樣，能給廣大的技術宅和數據愛好者提供一個炫技、PK、互助的圈子。

F. android 的action bar有什麼作用

下面是一個actionbar的使用截圖，來源於android學習手冊，360手機助手中可下載，裡面有108個例子，源碼還有文檔

Action bar是一個標識應用程序和用戶位置的窗口功能，並且給用戶提供操作和導航模式。在大多數的情況下，當你需要突出展現用戶行為或全局導航的activity中使用action bar，因為action bar能夠使應用程序給用戶提供一致的界面，並且系統能夠很好根據不同的屏幕配置來適應操作欄的外觀。你能夠用ActionBar的對象的API來控制操作欄的行為和可見性，這些API被添加在Android3.0（API 級別 11）中。

Action bar的主要目的是：

1.提供一個用於識別應用程序的標示和用戶的位置的專用空間。

這個空間的左邊是應用的圖標或logo，以及Activity的標題。但是，如果是像當前選擇的標簽這樣的標識當前View對象的導航標簽，你可以選擇刪除Activity的標題。

2.在不同的應用程序之間提供一致的導航和視覺體驗。

Action bar提供了用於Fragment間切換的內置導航標簽。它還提供了一個用於替換導航模式或優化當前視覺效果（如按照不同條件排序的列表）的下拉列表。

3.突出Activity的關鍵操作（如「搜索」、「創建」、「共享」等），並且在可預見的方法內給用戶提供快捷的訪問。

對於關鍵的用戶操作，你能夠通過把選項菜單項作為操作項直接放到操作欄中，從而提供快捷的訪問。操作項目還能提供一個操作窗口，這個窗口給更直接的操作行為提供一個嵌入的窗口部件。沒有改進成操作項的菜單項在溢出菜單中還是有效的，用戶既可以使用設備上的菜單按鈕（設備上有按鈕的時候），也可以使用操作欄中的溢出菜單按鈕（當設備上不包含菜單按鈕時）來顯示這些操作項目。

上面的總結一下：Action bar就是替換3.0以前的tittle bar和menu。

圖1. Honeycomb Gallery應用中的操作欄，從左邊開始，依次是logo、導航選項標簽和操作項（在右邊插入的一個懸浮菜單按鈕）。

Note:If you're looking for information about the contextual action bar for displaying contextual action items, see theMenuguide.

Action Bar Design For design guidelines, read Android Design'sAction Barguide.

添加Action Bar

從Android3.0（API級別 11）開始，Action bar被包含在所有的使用Theme.Hole主題的Activity（或者是這些Activity的子類）中，當targetSdkVersion或minSdkVersion屬性被設置為「11」或更大的數值是，這個主題是默認的主題一。如：

[html] view plain print?

<manifest...>

<uses-sdkandroid:minSdkVersion="4"

android:targetSdkVersion="11"/>

...

</manifest>

<manifest ... >
<uses-sdk android:minSdkVersion="4"
android:targetSdkVersion="11" />
...
</manifest>

在這個例子中，應用程序要求最小的API版本級別是4（Android 1.6），但是它還要求了目標API版本級別是11（Android 3.0）。這樣，當應用程序運行在Android3.0或更高的版本上時，系統就會給每個Activity應用holographic 主題，這樣，每個Activity就會包含Action bar。

如果你想使用ActionBar API來進行添加導航模式和修改操作欄樣式的操作，你應該把minSdkVersion屬性設置為「11」或更大的值。有一些方法可以使你的應用支持更舊的Android版本，同時在API等級為11或更高的API等級的機器的使你的應用支持一些Action bar apis。為了保持後向兼容，請參考邊框內的內容（邊框內容如下）。

Remaining backward-compatible

If you want to provide an action bar in your applicationandremain compatible with versions of Android older than 3.0, you need to create the action bar in your activity's layout (because theActionBarclass is not available on older versions).

To help you, theAction Bar Compatibilitysample app provides an API layer and action bar layout that allows your app to use some of theActionBarAPIs and also support older versions of Android by replacing the traditional title bar with a custom action bar layout.

刪除Action bar

如果你不想要Action bar，把Activity的主題設置為Theme.Holo.NoActionBar就可以了，如：

[html] view plain print?

<activityandroid:theme="@android:style/Theme.Holo.NoActionBar">

<activity android:theme="@android:style/Theme.Holo.NoActionBar">
或者使用Action bar的 hide()方法，如下：

[java] view plain print?

ActionBaractionBar=getActionBar();

actionBar.hide();

ActionBar actionBar = getActionBar();
actionBar.hide();

當Action bar隱藏時，系統會調整你的Activity來填充當前有效的屏幕空間。你能夠使用show()方法來再次顯示操作欄。

在隱藏和刪除Action bar時，要當心為了適應被Action bar佔用的空間而導致的Activity的重新布局。如果你的Activity有規律的隱藏和顯示Action bar，你可能想要使用覆蓋模式。覆蓋模式在Activity的頂部描畫操作欄，而不是在它們所擁有的屏幕的區域。這樣，在Action bar隱藏和重新顯示時，你的布局保持不變。要使用覆蓋模式，就要給Activity創建一個主題，並且把android:windowActionBarOverlay屬性設置為true。

提示：如果你有一個刪除了Action bar的定製化的Activity主題，它把android:windowActionBar樣式屬性設置為false。但是，如果你使用了刪除Action bar的一個主題，那麼，創建窗口將不允許Action bar再顯示，因此，你不能在以後給這個Activity添加Action bar---因為getActionBar()方法將返回null。

添加操作項

有些時候，你可能想要讓用戶直接訪問選項菜單中的一個項目，因此你要把應該在Action bar中顯示的菜單項作為一個操作項來聲明。操作項能夠能夠包含一個圖標或文本標題。如果一個菜單項不作為一個操作項顯示，那麼系統就會把它放到懸浮菜單中。懸浮菜單既可以通過設備的Menu按鈕來顯示，也可以在Action bar中一個額外的按鈕來顯示。

當Activity首次啟動時，系統會調用onCreateOptionsMenu()方法給你的Activity組裝Action bar和懸浮菜單。在這個回調方法中應該載入在XML文件中定義的菜單項資源，如：

[java] view plain print?

@Override

(Menumenu){

MenuInflaterinflater=getMenuInflater();

inflater.inflate(R.menu.main_activity,menu);

returntrue;

}

@Override
public boolean onCreateOptionsMenu(Menu menu) {
MenuInflater inflater = getMenuInflater();
inflater.inflate(R.menu.main_activity, menu);
return true;
}

圖2. 帶有圖標和文本標題的兩個操作項，和懸浮菜單按鈕。

在XML文件中，你能夠通過給<item>元素聲明android:showAsAction=」ifRoom」屬性，請求把一個菜單項作為一個操作項來顯示。用這種方式，只在有有效的空間時，菜單項才能顯示在Action bar中。如果沒有足夠的空間，這個菜單項會顯示在懸浮菜單中。

如果你的菜單項支持標題和圖標---帶有android:title和android:icon屬性---那麼默認情況下，操作項僅顯示圖標。如果你要顯示文本標題，就要給android:showAsAction屬性添加withText設置，如：

G. Android各版本間差異

一個好的APP最好支持90%設備，由於不同版本系統提供的API可能不同，所以了解不同版本間系統差異很重要，這樣才能更好的適配更多的智能設備。

Android4.X

Android5.X 這是一個里程碑的版本

Android6.X

Android7.X

Android8.X

Android9.0
對更大屏幕顯示的追求和視覺等體驗的優化，智能的開始體現（用戶行為的學習及正確化引導，網路環境的智能適應，電池電量的優化），更加人性化。

參考文檔：
Android從1.0到 6.0各版本的差別
大致總結一下 安卓各大版本的差異（安卓4以上版本）
Android 9.0新特性
關於Android Pie（Android 9.0），你想知道的都在這了

H. Android網路請求知識（三）授權，TCP/IP，HTTPS建立過程

由身份或持有的令牌確認享有的許可權，登錄過程實質上的目的也是為了確認許可權。

Cookie是客戶端給伺服器用的，setCookie是伺服器給客戶端用的。cookie由伺服器處理，客戶端負責存儲

客戶端發送cookie：賬戶和密碼
服務端收到後確認登錄setCookie：sessionID=1，記下sessionID
客戶端收到sessionID後記錄，以後請求服務端帶上對比記錄下sessionID，說明已經登錄

會話管理：登錄狀態，購物車
個性化：用戶偏好，主題
Tracking：分析用戶行為

XXS：跨腳本攻擊，及使用JavaScript拿到瀏覽器的cookie之後，發送到自己的網站，以這種方式來盜用用戶Cookie。Server在發送Cookie時，敏感的Cookie加上HttpOnly，這樣Cookie只能用於http請求，不能被JavaScript調用
XSRF:跨站請求偽造。Referer 從哪個網站跳轉過來

兩種方式：Basic和Bearer

首先第三方網站向授權網站申請第三方授權合作，拿到授權方頒發的client_id和client_secret（一般都是appid+appkey的方式）。

在這就過程中申請的client_secret是伺服器持有的，安全起見不能給客戶端，用服務端去和授權方獲取用戶信息，再傳給客戶端，包括④，⑤的請求過程也是需要加密的。這才是標準的授權過程。
有了access_token之後，就可以向授權方發送請求來獲取用戶信息

步驟分析就是上面的內容，這里把第4,6,8請求的參數分析一下
第④步參數：
response_type：指授權類型，必選，這里填固定值『code』
client_id：指客戶端id，必選，這里填在平台報備時獲取的appid
redirect_uri：指重定向URI，可選
scope：指申請的許可權范圍，可選
state：指客戶端當前狀態，可選，若填了，則認證伺服器會原樣返回該值

第⑥步參數：
grant_type：指使用哪種授權模式，必選，這里填固定值『authorization_code』
code：指從第⑤步獲取的code，必選
redirect_uri：指重定向URI，必選，這個值需要和第④步中的redirect_uri保持一致
client_id：指客戶端id，必選，這里填在平台報備時獲取的appid
client_secret：指客戶端密鑰，必選，這里填在平台報備時獲取的appkey

第⑧步參數：
access_token：指訪問令牌，必選，這里填第⑦步獲取的access_token
token_type：指令牌類型，必選，大小寫不敏感，bearer類型 / mac類型
expires_in：指過期時間，單位秒，當其他地方已設置過期時間，此處可省略該參數
refresh_token：指更新令牌，可選，用即將過期token換取新token
scope：指許可權范圍，可選，第④步中若已申請過某許可權，此處可省略該參數

我們在上面的第八步中會有refresh_token的參數，這個在實際操作中也比較常見

有時候我們在自己的項目中，將登陸和授權設計成類似OAuth2的過程，不過去掉Authorization code。登陸成功返回access_token，然後客戶端再請求時，帶上access_token。

我們常常會說到TCP/IP，那到底是什麼呢。這就需要講到網路分層模型。TCP在傳輸層，IP在網路層。那為什麼需要分層？因為網路不穩定，導致需要重傳的問題。為了提高傳輸效率我們就需要分塊，在傳輸層中就會進行分塊。TCP還有兩個重要的內容就是三次握手，四次分手。

HTTPS 協議是由 HTTP 加上TLS/SSL協議構建的可進行加密傳輸、身份認證的網路協議，主要通過數字證書、加密演算法、非對稱密鑰等技術完成互聯網數據傳輸加密，實現互聯網傳輸安全保護

1.客戶端通過發送Client Hello報文開始SSL通信。報文中包含客戶端支持的SSL的指定版本、加密組件列表（所使用的加密演算法及密鑰長度），客戶端隨機數，hash演算法。

2.伺服器可進行SSL通信時，會以Server Hello報文作為應答。和客戶端一樣，在報文中包含SSL版本以及加密組件，服務端隨機數。伺服器的加密組件內容是從接收到客戶端加密組件內篩選出來的。

3.之後伺服器發送Certificate報文。報文中包含公開密鑰證書。一般實際有三層證書嵌套，其實像下面圖二直接用根證書機構簽名也是可以的，但是一般根證書機構比較忙，需要類似中介的證書機構來幫助。

4.最後伺服器發送Server Hello Done報文通知客戶端，最初階段的SSL握手協商部分結束。

5.SSL第一次握手結束後，客戶端以Client Key Exchange報文作為回應。報文中包含通信加密中使用的一種被稱為Pre-master secret的隨機密碼串。該報文已用步驟3中的公開密鑰進行加密。

6.接著客戶端繼續發送Change Cipher Spec報文。該報文會提示伺服器，在此報文之後的通信會採用Pre-master secret密鑰加密。

7.客戶端發送Finished報文。該報文包含連接至今全部報文的整體校驗值。這次握手協商是否能夠成功，要以伺服器是否能夠正確解密報文作為判定標准。

8.伺服器同樣發送Change Cipher Spec報文。

9.伺服器同樣發送Finished報文。

10.伺服器和客戶端的Finished報文交換完畢之後，SSL連接就算建立完成。當然，通信會受到SSL的保護。從此處開始進行應用層協議的通信，即發送HTTP響應。

11.應用層協議通信，即發送HTTP響應。

12.最後由客戶端斷開連接。斷開連接時，發送close_notify報文。這步之後再發送TCP FIN報文來關閉與TCP的通信。

利用客戶端隨機數，服務端隨機數，per-master secret隨機數生成master secret，再生成客戶端加密密鑰，服務端加密密鑰，客戶端MAC secert，服務端MAC secert。MAC secert用於做報文摘要，這樣能夠查知報文是否遭到篡改，從而保護報文的完整性。

Android網路請求知識（一）HTTP基礎概念
Android網路請求知識（二）對稱和非對稱加密、數字簽名，Hash，Base64編碼
Android網路請求知識（三）授權，TCP/IP，HTTPS建立過程