本來之前覺得Android專案優化系列的文章基本整理完畢了,但是近期看了一下《阿里Android開發手冊》有了很多識訓,想再整理一篇,下面就開始吧,
先在這里列一下之前整理的文章及鏈接:
Android 專案優化(一):專案代碼規范優化
Android 專案優化(二):啟動頁面優化
Android 專案優化(三):MultiDex 優化
Android 專案優化(四):記憶體優化
Android 專案優化(五):應用啟動優化
Android 專案優化(六):專案開發時優化技巧總結 下面是《阿里巴巴Android開發手冊》為我們提供的開發建議,一、Android 基本組件開發規范
1. Activity 開發
必須要遵守的開發規范如下:
a). Activity 間資料通信,對于資料量比較大的,避免使用Intent + Parcelable的方式,可以考慮使用EventBus等替代方案,以免造成TransactionTooLargeException例外,
b). Activity 間通過隱式的Intent跳轉,在Intent發出去之前必須使用resolveActivity檢查,避免找不到合適的呼叫組件,造成ActivityNotFoundException例外,
c). Activity 動態注冊BroadCastReceiver時,registerReceiver和unregisterReceiver方法要成對出現,且生命周期對應,(否則會導致記憶體泄漏,部分華為機型對receiver進行資源管控,單個應用注冊過多receiver會觸發管控模塊拋出例外,可能會導致應用崩潰,)
建議的遵守的開發規范如下:
a). 不要在Activity的onDestroy()內執行釋放資源的作業,例如一些作業執行緒的銷毀和停止,因為onDestroy執行的時機可能較晚了,可以根據時機需要在Activity的onPause或onStop方法中結合isFinishing來判斷執行相應的邏輯,
b). 當前Activity的onPause方法執行結束后才會創建(onCreate)或恢復(onRestart)別的Activity,所以在onPause方法中不適合做耗時較長的操作,耗時較長的操作會影響頁面之間的跳轉效率,
c). Activity的onSaveInstanceState方法不是Activity生命周期方法,也不保證一定會被呼叫,它是用來在Activity被意外銷毀時保存UI狀態的,只能用于保存臨時資料,例如UI控制元件的屬性,不能用于資料持久化的存盤控制,持久化存盤應該在Activity的onPause/onStop中實行,
2. Service 開發
必須要遵守的開發規范如下:
a). 避免在Service的onStartCommand/onBind方法中執行耗時操作,如果確實有需求,應改為IntentService或者采用其他異步機制完成,
建議的遵守的開發規范如下:
a). Service需要以多執行緒并發處理多個啟動請求,建議使用IntentService,可避免各種復雜的配置,
b). 建議總是使用顯式的Intent啟動或者系結Service,且不要為Service宣告Intent Filter,保證應用的安全性,如需要隱式呼叫,建議設定Intent的指定包名,這樣可以充分消除目標Service的不確定性,
3. BroadCastReceiver開發
必須要遵守的開發規范如下:
a). 避免在BroadCastReceiver的onReceive方法中執行耗時操作,如果有耗時作業,應該創建IntentService完成,而不應該在BroadCastReceiver內創建子執行緒去做,
b). 避免使用隱式的Intent廣播敏感資訊,資訊可能被其他注冊了對應的BroadCastReceiver的App接收,如果廣播僅限于應用內,可使用LocalBroadcastManager的sendBroadcast實作,避免敏感資訊外泄和Intent攔截的風險,
建議的遵守的開發規范如下:
a). 對于只用于應用內的廣播,優先使用LocalBroadcastManager來注冊和發送,LocalBroadcastManager安全性更好,能避免敏感資訊外泄和Intent攔截的風險,同時擁有更高的運行效率,
二、UI 與 布局開發規范
必須要遵守的開發規范如下:
a). 布局中不得不使用ViewGroup多重嵌套時,不要使用LinearLayout嵌套,改用RelativeLayout,可以降低嵌套層數,
說明:Android 應用頁面的任何一個View都需要經過measure、layout、draw三個步驟才能被正確的渲染,嵌套層級越多,帶來的measure次數越多,計算就會越費時,
b). 不要在非UI執行緒進行View相關的操作,
c). 不能用ScrollView包裹ListView/GridView/ExpandableListView,因為這樣會把ListView的所有Item都加載到記憶體中,需要消耗巨大的記憶體和CPU去繪制畫面,這里推薦使用NestedScrollView,
d). 在使用Adapter的時候,如果你使用了ViewHolder做快取,在getView()的方法中,無論這項convertView的每個子控制元件是否需要設定屬性,都要顯式的設定屬性(包括文本內容、背景色及其他屬性),否則在滑動中,因為adapter item復用的原因,會出現內容的顯示錯亂,
建議的遵守的開發規范如下:
a). 在Activity中顯示對話框或彈出浮層時,盡量使用DialogFragment,而非Dialog/AlertDialog,這樣便于隨Activity生命周期管理對話框/彈出浮層的生命周期,
b). 推薦文本大小使用:dp單位,推薦View大小使用:dp單位,因為:sp是Android早期推薦使用的,但sp即受螢屏密度影響又受到系統字體設定影響,dp相對能保證UI的一致性,
c). 盡量避免在Activity沒有完全顯示時顯示PopupWindow和Dialog,
d). 盡量不要用AnimationDrawable實作幀影片(尤其圖片多的時候),它在初始化時會將所有圖片加載到記憶體,非常消耗資源(低端機可能直接OOM),且不能釋放,釋放后下次加載會報錯,
三、行程、執行緒與訊息通信開發規范
必須要遵守的開發規范如下:
a). 不要通過Intent在Android基礎組件之間傳遞大資料,否則可能會導致OOM,
b). 在Application的業務初始化代碼加入行程判斷,確保只在自己需要的行程初始化,特別是后臺行程減少不必要的業務初始化,
c). 新建執行緒時,必須通過執行緒池提供(AsyncTask或者ThreadPoolExecutor或者其他形式的執行緒池),不允許在應用中自行創建執行緒,
說明:使用執行緒池的好處是減少在創建和銷毀執行緒上所花的時間以及系統資源的開銷,解決資源不足的問題,如果不使用執行緒池,有可能造成系統創建大量同類執行緒而導致記憶體消耗完或者過度切換的問題,另外,創建匿名執行緒不便于后續的資源使用的分析,對性能分析會造成困擾,
d). 執行緒池不允許使用Executors去創建,而是通過ThreadPoolExecutor的方式,這樣的方式能夠讓寫的同學更加明確執行緒池的運行規則,規避資源耗盡的風險,
e). 子執行緒中不能更新界面,更新界面必須在主執行緒中進行,網路操作不能在主執行緒中呼叫,
建議的遵守的開發規范如下:
a). 盡量減少不同App之間的行程通信及拉起行為,拉起會導致占用系統資源,影響用戶體驗,
b). 新建執行緒時,定義能識別自己業務的執行緒名稱,便于性能優化和問題排查,
c). 使用執行緒池是,在業務滿足的情況下盡量設定執行緒的存活時間(setKeepAliveTime),確保執行緒空閑時能夠被釋放,
d). 盡量避免在多行程之間用SharePreferences共享資料,雖然可以通過設定MODE_MULTI_PROCESS來實作,但是這種方式官方已經不推薦使用了,
e). 謹慎使用Android的多行程,雖然多行程能降低主行程的壓力,但是需要注意以下問題:
- 首次進入新啟動行程的頁面會有延遲現象(可能黑屏or白屏幾秒),
- 應用內多行程時,Application實體化多次,需要考慮各個模塊是否需要在所有行程中初始化,
另外,使用多行程還會造成如下幾方面的問題:
(1)靜態成員和單例模式完全失效
(2)執行緒同步機制完全失效
(3)SharedPreference 的可靠性下降
(4)Application 會多次創建
(1)和(2)的原因是Android會為每一個行程分配一個獨立的虛擬機,(3)是因為SharedPreferences底層是通過讀/寫XML檔案來實作的,并發讀寫顯然很可能出現問題,(4)是大家基本都知道的問題,這里就不多贅述了,
四、檔案與資料庫開發規范
必須要遵守的開發規范如下:
a). 任何時候都不要硬編碼檔案路徑,請使用Android檔案系統API訪問(硬編碼存在機型兼容問題),
b). 當使用外部存盤時,必須檢查外部存盤的可用性,
c). 應用間共享檔案時,不要通過放寬檔案系統的權限去實作,而是應該使用FileProvier,
d). 資料庫Cursor必須確保使用完后關閉,以避免記憶體泄漏,
e). 多執行緒寫入資料庫時,需要使用事務,以免出現同步問題,
f). 執行SQL時,應該使用SQLiteDataBase的insert、update、delete方法,不要使用execSQL方法,以免SQL注入風險,
g). 如果ContentProvider管理的資料存盤在SQL資料庫中,應該避免將不受信任的外部資料直接拼接在原始SQL陳述句中,
建議的遵守的開發規范如下:
a). SharePreference中只能存盤簡單資料型別(int、boolean、String等),復雜資料型別建議使用檔案、資料庫等其他存盤方式,
b). SharePreference提交資料時,盡量使用apply方法,除非需要確定提交結果,并據此執行后續操作時,才使用commit方法,
c). 將大資料寫入資料庫時,請使用事務或者其他能提高I/O效率的機制,保證執行速度,
五、Bitmap、Drawable與影片
必須要遵守的開發規范如下:
a). 加載大圖或者一次性加載多張圖的時候,應該在異步執行緒中進行,圖片的加載,涉及IO操作,以及CPU密集操作,很可能引起卡頓,
b). 在ListView、ViewPager、RecyclerView、GridView等組件中使用圖片時,應做好圖片的快取,避免使用持有圖片導致記憶體溢位,也要避免重復創建圖片,引起性能問題,推薦使用Fresco、Glide等圖片加載庫,
c). 在Activity的onPause方法或onStop方法中,關閉當前Activity正在執行的影片,
建議的遵守的開發規范如下:
a). 推薦根據展示實際需要,壓縮圖片,而不是直接展示原圖,這樣能提高App的性能,
b). 使用完畢的圖片,應及時回收,釋放寶貴的記憶體,(2.3.3及以下版本需要呼叫recycle方法,2.3.3以上GC會自動管理不需要呼叫recycle方法)
c). 在影片或者其他異步任務結束時,應考慮回呼時刻的環境是否還支持業務處理,并增加相關的空指標等判斷邏輯,
d). 謹慎使用Gif,注意限制每個頁面同時允許播放的gif圖片數量,以及單個gif圖片的大小,
e). 根據設備性能,選擇性的開啟復雜影片,以實作一個整體較優的性能和體驗,
六、安全
必須要遵守的開發規范如下:
a). 將android:allowbackup屬性必須設定為false,防止應用資料被匯出,
說明:android:allowbackup 是Android提供的adb除錯功能,如果設定為true,可以匯出應用資料并在任意設備上恢復,這會對應用安全性和用戶資料隱私構成極大的威脅,所以必須設定為false,防止資料泄漏,
b). 在SDK支持的情況下,Android必須使用v2簽名,這將對APK檔案的修改做更多的保護,
c). 確保應用發布的版本的android:debuggable屬性設定為false,
建議的遵守的開發規范如下:
a). 在Android 4.2以上,對安全性較高的應用可在Activity中,對Activity所關聯的Window應用WindowManager.LayoutParams.FLAG_SECURE,防止被截屏、錄屏,對于其他的Window的視窗,如Dialog、DialogFragment等,根據需要也進行相應的保護,
轉載請註明出處,本文鏈接:https://www.uj5u.com/yidong/47855.html
標籤:Android
