Android開發技術周報183學習記錄

來源:互聯網
上載者:User

標籤:需要   欄位   AC   pen   標記   ffffff   情況下   自動裝箱   自訂   

Android開發技術周報183學習記錄教程Android效能最佳化來龍去脈總結記錄一、效能問題常見

記憶體流失、頻繁GC、耗電問題、OOM問題。

二、導致效能問題的原因

1.人為在ui線程中做了輕微的耗時操作,導致ui線程卡頓。
2.layout過於複雜,無法在16ms完成渲染。
使用RelativeLayout替換LinearLayout,說是可以減少布局層次,然而,現在不再建議使用RelativeLayout,因為ConstraintLayout才是一個更高效能的消滅布局層級的神器。ConstraintLayout基於Cassowary演算法,而Cassowary演算法的優勢是在於解決線性方程時有極高的效率,事實證明,顯性方程組是非常適合用於定義使用者介面元素的參數。
3.同一時間執行的動畫過多,導致CPU或者GPU負載過重。
主要是因為動畫一般會頻繁變更view的屬性,導致display失效,而需要重新建立一個新的displayList,如果動畫過多,這個開銷可想而知。
4.view過度繪製的問題。
可以通過手機設定裡面的開發人員選項,開啟Show GPU Overdraw的選項,發現問題,盡量往藍色靠近。
5.gc過多。
6.資源載入導致執行緩慢。
兩種解決辦法:a.預先載入,即還沒有來到路徑之前,就提前載入好。
b.要等到用到的時候載入,加一個進度條。
7.背景工作執行緒優先順序設定不對,導致和ui線程搶佔cpu時間。
使用Rxjava時需要注意,設定任務的執行線程可能會對效能產生較大的影響。
8.靜態變數

三、解決

1.GPU過度繪製,定位過度繪製地區
直接在開發人員選項,開啟Show GPU Overdraw,就可以看到哪塊需要最佳化。
減少布局層級,使用ConstraintLayout替換傳統的布局方式。
檢查是否有多餘的背景色設定。
2.主線程耗時操作排查
開始strictmode,止癢以來,主線程的好事操作都將以警告的形式呈現到logcat當中。
直接懷疑的對象加@DebugLog,查看方法執行耗時。DebugLog註解需要引入外掛程式hugo,這個是Android之神JakeWharton的早期作品,對於監控函數執行時間非常方便,直接在函數上加入註解就可以實現,但是有一個缺點,就是JakeWharton發布的最後一個版本沒有支援release版本用空方法替代監控代碼。
3.對於measure,layout耗時過多的問題
一般這類問題是由於布局過於複雜的原因導致,建議使用ConstraintLayout減少布局層級,問題一般得以解決,如果發現還存在效能問題,可以使用traceView觀察方法耗時,來定位下具體原因。
4.leakcany
用於記憶體流失檢測,引入

dependencies {    debugImplementation ‘com.squareup.leakcanary:leakcanary-android:1.5.4‘    releaseImplementation ‘com.squareup.leakcanary:leakcanary-android-no-op:1.5.4‘}

注意引入方式中releaseImplementation保證在發布包中移除監控代碼,否則,他自身不停的catch記憶體快照,本身也影響效能。
5.onDraw裡面寫代碼需要注意
onDra由於大概每16s都會被執行一次,因此本身就相當於一個forloop,如果你在裡面new對象的話,不知不覺中就滿足了短時間內大量對象建立並釋放,於是頻繁GC就發生了,於是卡了。正確的做法是將對象放在外面new出來。
6.json還原序列化問題
json還原序列化是指將json字串轉變為對象,如果資料量比較多,特別是有相當多的string的時候,解析起來不僅耗時,而且還很吃記憶體。解決方案:
a.精簡欄位,與後台協商,相關介面剔除不必要的欄位。保證最小可用原則。
b.使用流解析,使用Gson.fromJson即可,可以提高25%的解析效率。
7.viewStub&merge的使用
對於只有在某些條件下才展示出來的組件,建議使用viewStub包裹起來,include某布局如果其更不懼和引入他的夫布局一致,建議使用merge包裹起來。
8.載入最佳化
將耗時的操作封裝到非同步中去。
9.重新整理最佳化
a.對於列表中的item的操作,有寫只需要布局重新整理,不應該讓整個列表重新整理。
b.對於較為複雜的頁面,建議不要寫在一個activity中,建議使用幾個fragment進行組裝,這樣一來,module的變更可以只重新整理某一個具體的fragment,而不用這個整個頁面都走重新整理邏輯。
10.動畫最佳化
使用硬體加速來做最佳化,注意在動畫做完之後,關閉硬體加速,因為開啟硬體加速本身就是一種消耗。
11.耗電最佳化
a.建議在定位精度要求不高的情況下,使用wifi或英東網路定位,沒有必要開啟GPS定位。
b.建議先驗證網路的可用性,在發送網路請求,比如,當使用者處於2G狀態下,而此時的操作是查看你一張大圖,下載下來可能都200多k甚至更大,就沒有必要去發送這個請求,讓使用者一直等待載入吧。

四、代碼建議

(正確使用alarm,正確申請和釋放wakelock)、(節制地使用service)、(當介面不可見時釋放記憶體)、(Allocate Memery,Pd->model,使用最佳化過的資料集合)、(謹慎使用抽象編程)、(Try/Catch語句,應把其放在最外層)、(System.arraycopy()代替For迴圈複製)、(Hashmap->sparsearray)、(列表滾動停止之後載入網狀圖片)、(注意使用wrap_content)、(使用Canvas.cliprect()來協助系統識別那些可見的地區,自訂view最佳化)、(對於定時任務盡量使用alarmmanager,而不是sleep或者timer進行管理)。
建議只用SpaseArray代替HashMap,因為SparseArray比HashMap更省記憶體,在某些條件下效能更好,主要是因為它避免了對key的自動裝箱,它內部則是通過兩個數組來進行資料存放區的,一個儲存key,另一個儲存value,為了最佳化效能,它內部對資料還採取了壓縮的方式來表示稀疏資料的資料,從而節省記憶體空間。
不到不得已,不要使用wrap_content,推薦使用match_parent,或者固定尺寸,配合gravity=’center’,因為在測量過程中,match_parent和固定寬度對應EXACTLY,而wrap_content對應AT_MOST,這兩者對比AT_MOST耗時較多。

深入理解flutter的編譯原理與最佳化記錄

查了一下flutter,不建議學習,不看了。

技術之外GitHub 的用法與禮儀記錄

遊客
Watch(關注):表示你對這個倉庫中發生的事件感興趣。
Star(星標):表示特別標記這個倉庫。
Fork(分支):兩種用途,一種是你要參與它,為它提交代碼;另一種是覺得這個倉庫可能會被原作者刪除,因此Fork出來一份,這樣即使作者刪除了,也有一個Fork那個時間點的版本的快照。
貢獻者
貢獻的形式有兩種:提issue和提pill request,這兩者有一些共同的要求,包括:

  • 認真看病遵循對方給出的issue模板/PR模板。
  • 及時跟進,當對方有回複時應該儘早給出足夠明確的回答。如果覺得對方的回覆已經解決了你的問題,或者這個確實不是問題,就及時關閉,不要等作者動手。
  • 大多數倉庫都要用英文提,但專門面向中文使用者的倉庫是例外。

提issue也就是提問題,可以再細分為兩種:提BUG和提需求(Feature Request/Proposal)。
提BUG的基本要求是確認它是問題並把問題說清楚。
提需求的基本要求是要能坦然接受別人的拒絕。
提Pull Request(簡稱PR)也就是申請往主庫中合并代碼。提PR的前提是先Fork對方的倉庫,而不要clone下來然後上傳到自己的倉庫,那樣的話GitHub無法知道這倆庫是同源的。
Fork之後,你的個人倉庫中就有了一個分支倉庫,可以往這個分支倉庫中提交代碼,覺得達到了PR的預定目標之後,就推送它,並回到GitHub頁面中發起PR。
作者
作為倉庫的作者,首先要在倉庫中包含一個明確的LICENSE檔案。
通常代碼類的倉庫會選擇MIT等比較開放的協議,如果是開源狂熱者,也可以選擇GPL等比較激進的協議,但是要注意原則上GitHub不允許開放倉庫中的代碼使用私人/純商業授權協議。
文檔類的倉庫通常會選擇CC或者CC-BY-NC協議,兩者的區別是前者允許商用,後者不允許商用或商用時需單獨授權。

Android開發技術周報183學習記錄

相關文章

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.