張紹文android開發高手課讀書筆記1

本系列博文 基因而前微信高級工程師張紹文專欄 《Android開發高手課》的讀書筆記。

文章所寫內容是本人讀完的感悟,須要原文的朋友請自行購買。

Android的開發前景如何

移動互聯網發展不知不覺已經十多年過去了，「風口上的豬」也從Mobile First變成了AI First.

做爲從業者的咱們能很清楚的感覺到移動端的招聘量變少了,但不得不提的是中高端崗位需求卻更多了.

這說明移動互聯網已通過了高速發展的階段,逐漸成熟規範了。對從業者的要求也變高了,面對這種狀況,

咱們能作的就是不斷提升本身的技術深度,同時也得擴寬技術廣度.

至於一些跨平臺技術,如RN,PWA,Weex,以及Flutter雖然能代替一部分App開發的需求,但在最終的實現效果

上仍是比不上原生開發。因此移動端的從業人員不要急着去改換門庭,應該花更多的時間去修煉內功.

另外移動端開發也不只限於App開發,還有loT(物聯網)，音視頻,VR/AR 等這些領域也是離不開移動互聯網的.

崩潰優化

咱們一般所說的崩潰就是指程序出現異常.Android下的崩潰分爲java崩潰和Native崩潰。

其中java崩潰還算是比較好找的,網上也有挺多日誌上報的方法.

而Native崩潰呢.通常都是由於在 Native 代碼中訪問非法地址，也多是地址對齊出現了問題，或者發生了程序主動 abort，這些都會產生相應的 signal 信號，致使程序異常退出。

Android開發高手課中講的可能是Native崩潰的處理,然而我我的對這部份內容瞭解的也不多,因此下文可能是摘取張老師專利中的重點內容。

Native入門可先看這篇博文 Android 平臺 Native 代碼的崩潰捕獲機制及實現

Native 崩潰從捕獲到解析通常要經歷如下流程

• 編譯端。編譯 C/C++ 代碼時，須要將帶符號信息的文件保留下來。
• 客戶端。捕獲到崩潰時候，儘量地將有用的信息寫入日誌,而後選擇適當的時間傳到服務器
• 服務端 . 讀取日誌,尋找合適的符號文件,生成可讀的C/C++調用棧.

第三方工具中比較成熟的當屬Chromium的Breakpad

在異常捕獲過程當中最重要的是保證在各類極端狀況下生成崩潰日誌,同時要保證程序不發生二次崩潰。

生成日誌時會出現的問題

1. 文件句柄泄漏，致使建立日誌文件失敗，怎麼辦？

   咱們須要提早申請文件句柄 fd 預留，防止出現這種狀況。

2. 由於棧溢出了，致使日誌生成失敗，怎麼辦？

   爲了防止棧溢出致使進程沒有空間建立調用棧執行處理函數，咱們一般會使用常見的 signalstack。

   在一些特殊狀況，咱們可能還須要直接替換當前棧，因此這裏也須要在堆中預留部分空間。

3. 整個堆的內存都耗盡了，致使日誌生成失敗，怎麼辦？

   這個時候咱們沒法安全地分配內存，也不敢使用 stl 或者 libc 的函數,由於它們內部實現會分配堆內存

   這個時候若是繼續分配內存，會致使出現堆破壞或者二次崩潰的狀況.Breakpad 作的比較完全，從新封裝了Linux Syscall Support，來避免直接調用 libc。

4. 堆破壞或二次崩潰致使日誌生成失敗，怎麼辦？

   Breakpad 會從原進程 fork 出子進程去收集崩潰現場,此外涉及與 Java 相關的，通常也會用子進程去操做。

   這樣即便出現二次崩潰，只是這部分的信息丟失，咱們的父進程後面還能夠繼續獲取其餘的信息。

   在一些特殊的狀況，咱們還可能須要從子進程 fork 出孫進程。

固然對於通常的公司來講,要作這些仍是有些強人所難,幸運的是市面上有合適的服務.好比騰訊的Bugly,阿里的啄木鳥平臺,網易雲捕等.

在熱修復流行的當下,就算線上發送了一些崩潰,也可能經過打補丁來達到在線修復。可是若是崩潰發生在啓動的時,在熱修復代碼執行以前,那就糟糕了。因此一些大公司的產品還會有"安全模式"來保障啓動流程.

安全模式

在App熱修復中有一個特殊狀況，就是應用在啓動階段crash，根本啓動不了，熱修復就難以奏效。這個時候能夠採起一種安全模式的啓動方式.

簡單來講,就是增長一個flag啓動標記位,用來標記用戶是否連續兩次啓動失敗,這個時候就會進入安全模式進入修改階段.修復的方式

• 自修復,清空業務數據,嘗試啓動
• 熱修復,根據配置文件來判斷是否修改
• 重製爲初始安裝狀態,將Document、Library、Cache三個根目錄清空

詳細可看 安全模式：天貓App啓動保護實踐

如何快速定位崩潰

發生崩潰就必定會有崩潰信息,那麼咱們應該看的是那部分信息？

1.崩潰基本信息

進程名、線程名。崩潰的進程是前臺進程仍是後臺進程，崩潰是否是發生在 UI 線程。

崩潰的堆棧和類型.是java崩潰,Native崩潰,仍是ANR.是本身的代碼問題,仍是系統的代碼問題.

2.系統和應用的運行日誌.

系統的event logcat會記錄App運行的一些基本狀況,記錄在/system/etc/event-log-tags 中。

system logcat:
10-25 17:13:47.788 21430 21430 D dalvikvm: Trying to load lib ... 
event logcat:
10-25 17:13:47.788 21430 21430 I am_on_resume_called: 生命週期
10-25 17:13:47.788 21430 21430 I am_low_memory: 系統內存不足
10-25 17:13:47.788 21430 21430 I am_destroy_activity: 銷燬 Activty
10-25 17:13:47.888 21430 21430 I am_anr: ANR 以及緣由
10-25 17:13:47.888 21430 21430 I am_kill: APP 被殺以及緣由

複製代碼

3.機型、系統、廠商、CPU、ABI、Linux 版本等

上述這些數據可用做橫向比較,你常常會發現某個問題只會在特定的狀況下出現。

4.設備狀態 是否root,是不是模擬器.有些問題是由Xposed 或多開軟件形成

5.內存信息,考慮一些內存不足的崩潰是否多發生在低內存的手機上.

6.自定義的應用信息

這部分信息主要用來輔助定位崩潰位置.能夠記錄崩潰發生的位置,某個activity;還能夠記錄發生崩潰以前的幾個操做步驟,便於復現崩潰場景.

解決崩潰

1.優先級: 優先解決Top 崩潰或者對業務有重大影響;其次簡單易排查的java崩潰,疑難雜症放到最後

2.嘗試復現: 針對疑難雜症,能夠經過早先在日誌中自定義的應用信息來複現崩潰過程

3.着眼硬件: 排查是不是手機系統,內存,機型引發的。

4.系統錯誤: 有些問題是Android系統不一樣版本之間存在的問題。

最後,給本身公衆號打個廣告,【碼農的嘮叨】聊技術,聊熱文,聊互聯網趣事,也發嘮叨