App性能優化概覽與平臺化實踐理論

本文首發於公衆號「Android開發之旅」， 歡迎關注

如今你們都在談性能優化或者在面試的時候被問到性能優化相關問題，那麼咱們爲何要作性能優化呢？以及性能優化的難點是什麼？在整個項目週期中不一樣的階段該作什麼？優化效果如何長期保持？帶着這些問題咱們來一塊兒看看如何作性能優化。

當一款App在被用戶使用的時候，若是出現各類異常、奔潰、卡頓等問題，那麼在有耐心的用戶也會堅決果斷的卸載App的（心裏OS：什麼S13玩意），那麼這對公司、對運營同事來講都是莫大的打擊，你們花錢辛辛苦苦拉來的用戶最後卻由於App的各類不穩定而流失，腦補一下運營同事看你的表情（技(yi)術(lian)真(xian)棒(qi)）。做爲程序員的咱們只能說：這個鍋咱們不背，由於咱們有解決問題的利器：性能優化。

既然要作性能優化，那麼就要綜合考慮性能在哪些方面表現差？以及咱們如何排查線上問題？還有就是作了性能優化後做爲開發的咱們如何長期保持？

性能表現差的因素有不少，好比用戶直觀感覺的App啓動慢，用戶點擊App圖標到徹底能操做使用等了過久時間，那麼這種就要咱們作啓動優化，等了過久後終於能使用了可又出現各類卡頓、丟幀現象，若是你是用戶，你會咋想。因此這種咱們要作卡頓等優化。還有一些用戶感覺不那麼直觀的就是內存佔用高、抖動頻繁，這些用戶無感知可是積累到必定程度也會引發奔潰的，影響用戶使用。其餘方面還有耗電、網絡請求慢，奔潰率異常率高等等，這些都是須要咱們着手進行優化的。

那麼在用戶使用出現問題的時候，咱們如何第一時間感知到異常，如何第一時間收集到用戶的使用日誌和使用路徑，快速復原「案發」現場，快速的止血呢，這就要接入APM平臺了或者咱們自建的APM平臺。

如何避免性能優化打來的長期開銷大的問題呢？ 這就要將問題在上線以前解決掉，將問題扼殺在萌芽階段，還有就是制定一些開發規範，互相review，避免將有問題的代碼發上線。

因此對整個性能優化的要求就是：性能表現好，線上問題易排查，長期投入較小。

App性能優化解決方案演進分爲不一樣的階段，如項目初期、項目壯大期、項目成熟期，在每一個階段咱們所作的事情是不盡相同的。

項目初期： 在項目初期咱們須要快速的佔領市場，應用在不斷的作加法，咱們可能只關心奔潰率，沒有太多的時間去採集其餘各個方面的性能數據，也沒有性能檢測優化的方案，在早期咱們可能只接入了騰訊的bugly平臺，它能夠很好的幫助咱們上報異常而且對java和native層的奔潰採集較準確且全面。

項目壯大期 ： 項目發展到這個階段，性能優化獲得必定程度重視，開始逐步完善性能優化解決方案。開始採集各種指標，但可能還不夠全面和深刻，接入成熟的APM平臺好比聽雲，可是排查手段仍是比較單一的，如今檢測、優化方案還不成型，尚未造成一套完整的系統。

項目成熟期 項目到這個階段，App的各類功能已經比較穩定了，文員也比較充足，那麼就該考慮精細化運營和重點關注性能相關的問題了。在這個階段咱們採集的數據比較豐富，手段也多樣化，同時也具有了線上線下一整套的性能檢測完善的解決方案。甚至會自建APM平臺，爲何要自建呢？主要是由於第三方APM平臺成熟通用，不知足個性化需求，且和內部系統難打通，帶來時間成本。App的日活、人均使用時長、運營數據容易留存在三方平臺也是很不安全，咱們要數據必須掌握在本身手上。這樣能保證APM貼合自身業務特色，知足定製化要求同時也保證了數據的安全。

以上就是對性能優化的各個難點以及不一樣階段所作的事項的一些闡述，主要是一些理論相關的東西，俗話說：「 磨刀不誤砍柴工」，只有理論基礎紮實了，才能更好的應用到項目中。後面會繼續給你們帶來啓動優化，內存優化、佈局優化、卡頓檢測優化、線程網絡等各個方面的性能優化系列文章。

推薦閱讀：

Android性能優化之啓動優化實戰

Android性能優化之佈局優化實戰

如何監測Android應用卡頓？這篇就夠了

掃描下方二維碼關注公衆號，及時獲取文章推送。