遠端日誌是什麼？具體做了哪些事情？內部是怎麼實現的？本文將從 功能、架構、體驗優化三個方面來介紹一下遠端日誌發展過程及展望。阿里雲 雲原生應用研發平台emas 張月（此間）
遠端日誌具體在裡面做了哪些事情？內部又是怎麼實現的？接下來我就會從 功能、架構、體驗優化 三個方面來介紹一下遠端日誌發展過程，最後再聊聊我們的展望。
遠端日誌的定位是非同步拉取，把問題日誌從移動裝置端拉回來分析。結合不同使用場景，使用者對裝置精準度、拉取及時性、拉取成功率等不同側重的特點，我們在拉取模式和產品聯動上做了不同的實踐。
精準拉取：指定裝置列表
這個模式下，使用者使用面臨了兩個體驗問題：
拉取成功率低。下發拉取任務會有部分裝置inactive，導致沒辦法接受拉取指令，導致日誌無法上傳。
針對這個問題，我們在拉取上做了相關的優化，實現了智慧型篩選的功能。
智慧型篩選：指定篩選條件
使用者不需要指定目標裝置列表，而是關心某個或幾個維度下的裝置詳細日誌。那使用者可以設定拉取的裝置組合條件，系統自動幫使用者選取裝置。
為了加快裝置拉取速度以及拉取成功率，遠端日誌在選取裝置增加了如下策略：
在端上問題發生的場景中，大多數是因為崩潰或者異常行為。為了給與對這種場景支撐，我們提供了崩潰分析資料聯動的支援，打破了「崩潰分析」 和「遠端日誌」兩個產品之間的資料孤島，提供了問題排查的更多的可能性。
資料聯動：崩潰裝置列表
通過崩潰分析提供崩潰裝置列表，可以幫遠端日誌直接劃定待拉取裝置範圍，使用者更加省力，通過 emas 「崩潰分析」中的列表頁一鍵跳轉拉取。
這個方式極大簡化了使用者在排查崩潰相關問題時選定裝置列表的工作，但對於每個崩潰問題還是需要建立拉取日誌任務。這個拉取過程還是存在乙個時間上的遲滯感，這不僅會打斷工程師的排查思路，也會消磨排查問題的積極性。我們能否免除拉取動作，直接把崩潰問題對應的裝置日誌準備好呢？「智慧型拉取」就是為了解決這個場景的問題。
智慧型拉取：提前拉取
我們加深了前面的資料聯動，對於首現和 top 崩潰問題，每天7點定時建立任務，開發同學上班的時候基本上都已經拉取成功了，極大的提公升了開發同學的問題排查效率。
除了在內功上打磨，產品的使用體驗上我們也做了相當多的優化，也和大家分享一下。
到此，遠端日誌的現有的功能、架構和體驗介紹就此結束了，接下來說說我們對未來的規劃。
現在我們的日誌列印僅限於使用者日誌，還需要支援更多的無痕埋點，記錄使用者操作路徑和網路io等操作，讓日誌資料更豐富，能夠通過日誌復現使用者操作流水，機器狀態的變化。
移動端BUG排查思路
2020年 是我做測試的第7年，也是做移動端測試第7年。現分享分享下移動端bug排查思路 一 輔助工具 fidlder charles 移動端測試的吃飯工具，用於抓去http請求後，然後進行各類分析及操作 二 熟悉並了解常見http碼 比如 抓包看到請求 404 那就是資源不存在。那就3種可能 1 ...
日誌排查問題總結
寫在前面 因為公司負責的專案流程鏈路很長，經常需要排查問題定位問題。目前專案是把每個service的方法前後都加上了入參和返回值的列印。接管專案後，總結了一下通過日誌定位問題的經驗，希望以後排查問題能有一些幫助。第二版 運單後台排查問題的方法總結 邏輯熟悉時 4.再根據測試 現場人員描述的描述以及自...
移動端問題
最近的移動端開發中發現標籤在安卓手機和chrome瀏覽器上只可以輸入數字，輸入非數字字元不會顯示，但在iphone上可以輸入非數字字元，在輸入框中可以顯示出來，但提交表單的時候是空的，也不會有任何提示，這就造成如果這項是非必填項的話，使用者會覺得漏掉了自己提交的資訊 他可能沒意識到自己填寫錯誤了 這...