產品設計時的App性能需求考量
智能手機的普及比電腦要短,但目前已經成為了我們生活中必不可少的工具了。手機的性能和配置也在不斷提高,作為產品經理,需要基于用戶最常關注的性能問題,明確產品設計的需求。本文將探討產品設計時的App性能需求考量,一起來看看吧。
智能手機的普及時間遠比電腦要短,但其已成為人們生活中更為重要的設備了。隨著時代的發展,智能手機的配置也在發生巨大的變化,無論是CPU性能還是內存容量都在以肉眼可見的方式不斷提升。
除此之外,App在使用時的耗電量、流量、發熱情況等也是用戶極為關心的,這些其實都屬于性能方面。作為產品經理,需要基于用戶最常關注的性能問題,明確產品設計的需求。
一、Android手機為何普遍比較卡頓
很多用戶對Android手機存在著極大的“偏見”,覺得Android手機很卡,蘋果手機不卡。
1. 系統生態
造成這種差異的原因很多,最核心的是Android系統生態問題。由于谷歌主張的開源策略,諸多手機廠商都會基于原生Android系統定制新系統,加之不同手機廠商研發水平不同,從而造成部分手機易卡頓的情況。相比之下,iOS系統則是從系統到App完全封閉打造,App開發者必須完全遵從蘋果生態要求,從而使得系統全局對App有更好的管理。
2. 硬件配置
除了系統生態,App自身的原因也會導致卡頓情況發生。
手機的硬件配置是一個非常重要的原因。蘋果手機憑借著完全自研的CPU芯片,與自研的系統完美結合,從而可以更加充分地發揮出硬件性能。Android手機則使用了第三方CPU廠商的芯片,系統與硬件的配合并不能做到像蘋果手機那樣完美,只能靠提升配置來彌補。不過目前很多Android手機的配置已遠超蘋果手機,所以配置上基本已經達標。
3. App“抱團”
很多國產App廠商,為了盡可能占用用戶的使用時間,想盡各種辦法讓App一直處于運行狀態,無論是在手機后臺運行還是使用其他方式。為了達到這樣的目的,甚至會“抱團作戰”,比如某公司旗下有10款App,在用戶啟動了其中一個App后,該App就會想辦法在后臺啟動其他9個App,一旦啟動,這些App就處于“抱團”的狀態,互相之間彼此牽制,其中一個App被“殺死”,另一個App就會想辦法再把被“殺死”的App喚醒,這樣會使系統的內存資源逐漸消耗掉,從而造成卡頓的情況。
這種行為從公司層面看無可厚非,但從用戶的角度看,極大地傷害了用戶體驗,這是以完成KPI為目的的“作惡”行為。有時App中所表現出的功能及做法,也是一個產品經理人品和一家公司調性的體現。
4. 內存泄漏
內存泄漏也有可能造成App卡頓。要理解內存泄漏的原因,首先需要大概了解系統中App的運行機制。簡單來說,App啟動后,系統會為App分配一塊內存空間,App需要的越多分配得就越多,當App不需要該內存空間時,就將其釋放出來供其他App使用。如果某個App無需運行,但占據的內存無法釋放,就會造成系統中內存的浪費,從而引發App的運行速度變慢,甚至整個系統都無法響應。
內存泄漏的情況并不只發生在Android系統中,iOS系統中同樣會發生,大部分情況都是App開發者在內存回收方面沒有做好處理導致的。
二、App的耗電量
在功能機時代,手機充一次電,可以輕松用上一個星期,進入智能機時代后,一天一充或多充都很常見。當然,正常使用手機導致的掉電,用戶能接受,但有時只要手機上裝了某些App,哪怕沒有使用手機,耗電也很快,就會讓用戶難以接受。
對于手機廠商,從系統層面控制App的耗電量是必須考慮的。另外,App自身也得想辦法降低自己給手機帶來的耗電影響。
常見的會導致耗電量增加的因素主要有這幾個方面:CPU及內存的高頻使用帶來的電量消耗,數據傳輸造成的電量消耗,使用定位(尤其是GPS定位)帶來的電量消耗,屏幕亮度過高造成的電量消耗,以及各種傳感器的使用帶來的電量消耗等。
為避免CPU及內存的高頻使用帶來的電量消耗,在App退到后臺后,應盡量減少App的主動運行;為避免數據傳輸造成的電量消耗,設計產品時可考慮將常用數據緩存到本地,避免每次都請求加載網絡數據;App中要使用GPS或其他傳感器時,應盡可能地控制這些傳感器的使用時間及使用頻率,只在必要時才提示用戶開啟使用它們,其他時間則無須一直開啟。
三、App的安裝包大小
App的功能越做越復雜,導致安裝包的大小也越來越大。盡管現在人們的手機流量已經很充裕,但用戶在只想體驗某產品時,卻發現產品App的安裝包有好幾百MB大,這時或多或少會猶豫,一是下載會消耗流量,二是下載時間較長,除非“剛需”則八成會放棄下載。并且,關于App安裝包大小對App下載量的影響,曾有過相關統計,當App的安裝包大小每增加6MB時,App下載量會下降1%。所以,產品經理,以及開發者,要想辦法讓App在保持功能不變的情況下,盡可能縮減安裝包大小。
為了更好地完成這件事,下面先來了解一下安裝包由哪些部分組成,這可以幫助我們明確優化方向。
1. Android的App安裝包
先說說Android的App安裝包。Android的App安裝包是APK格式的文件,在應用市場中下載App安裝包,并將其解壓縮后,會發現APK文件中包含了一些共同的內容,如圖6-60所示。
圖6-60 Android App安裝包解壓縮后的目錄結構
AndroidManifest.xml文件:該文件是Android App安裝包中的配置文件,包含了App的配置信息,包括App的包名、App中所使用的組件、各頁面的Activity名稱及使用的第三方lib名稱。
assets文件夾:該文件夾中保存的是文件的原始格式,即App中需要用到的固定文件,如字體文件或需要引用的音視頻文件。
classes.dex系列文件:在Android系統中,這些文件是可以直接在Dalvik虛擬機上運行的文件,由Java源代碼經過開發工具編譯后轉換而成。轉換的目的是方便硬件更好地運行這些代碼,而且轉換后的文件體積也會減小。
lib文件夾:很多App的開發者會使用第三方庫,后綴名多為.so,是一種二進制文件,類似于Windows系統中的dll文件。
META-INF文件夾:該文件夾中主要保存描述jar文件中信息和簽名相關信息的文件。
r文件夾:App中用到的資源文件,比如頁面布局xml文件,App中的固定圖標及圖片文件等。
resources.arsc文件:該文件可以理解為資源的索引表或目錄,其中記錄了各種資源ID信息、資源名稱、資源路徑及對應值,App運行過程中AssetManager會通過該索引表找到需要的具體資源。
從組成目錄及文件歸類,可將這些文件劃分為資源文件及代碼文件,classes.dex系列文件和lib文件夾中的文件都可以算作代碼文件,剩下的基本上都可以算作資源文件。要調整這兩類文件的文件大小,具體可以怎么著手呢?
首先,對于代碼類型的文件,應盡可能優化代碼,使文件大小減小。可通過剔除無用的lib庫,刪除代碼中的無用功能,優化代碼中的冗余代碼,將重復代碼通過封裝簡化來減小文件大小。另外,因classes.dex系列文件是由Java代碼轉換后生成的文件,所以這類文件的大小與代碼中的方法數有很大關系,方法數過多會造成轉換后的文件變大,這時開發者可通過減少代碼中的非必要方法來達到目的。除了上面提到的幾種方法,還存在一種方法可以間接起到作用,這就是將代碼混淆。因為代碼混淆后,代碼中的類名、字段名及方法名均被簡化并替換成無實際意義的名稱,這樣可減小最終生成的classes.dex文件的大小,從而減小安裝包的大小。
然后,就是從資源文件角度優化了。資源文件中隨著版本迭代,可能會出現曾使用,現在已經不再使用,但卻沒有及時刪除的功能的情況,所以每次發布新版本時可以讓開發者及時清理App中不再使用的資源文件,比如無效xml代碼及圖片資源等。如果實在無法刪除,還可以對資源文件中的圖片、音頻、視頻等進行壓縮處理。
2. iOS的App安裝包
再來說說iOS的App安裝包。iOS的App安裝包格式為IPA,將IPA文件解壓縮后會得到如圖6-61所示的目錄,其中包含了4部分內容,iTunesArtwork是一個沒有后綴名的圖片,用途是在iTunes中顯示App的圖標;另一個是iTunesMetadata.plist文件,用來記錄開發者及App的基本信息;META-INF文件夾則保存了一些簽名信息;最關鍵的是Payload這個文件夾,其中有一個.app文件,這是安裝程序的主程序。
圖6-61 iOS App安裝包解壓縮后的目錄結構
在Payload文件夾中找到.app文件后,繼續執行解壓縮或者直接顯示包內容,能看到更多文件,這些文件又可以分成以下這幾類。
簽名文件:主要放置在_CodeSignature文件夾中,記錄了所有資源的簽名信息。
資源文件:找到Payload文件夾中的.app文件,點擊右鍵并選擇“顯示包內容”,可以查看到App在運行過程中用到的資源文件,比如圖片、音視頻及其他配置文件。
可執行代碼文件:這類文件是App中的主體內容,是確保App功能得以實現的重要部分。
其他支持文件:這部分文件又包含了多種不同類型的文件,如開發過程中會用到的第三方庫文件及一些插件等。
了解了安裝包文件中包含的文件后,對于如何減小安裝包大小,就應該有思路了。大體上還是與Android App安裝包一致,即減小代碼文件、資源文件及其他支持文件的大小,通過優化代碼、壓縮資源文件、刪除非必要支持文件等方式達到目的。
本文節選自作者新書《產品經理技術手冊》,本書定位于讓不懂技術的產品經理從產品經理的工作和思考方式切入了解應該掌握的技術原理。
專欄作家
小風老師,公眾號:村上風,人人都是產品經理專欄作家?!懂a品經理技術手冊》作者,互聯網從業者,獨立原創音樂人。
本文原創發布于人人都是產品經理。未經許可,禁止轉載。
題圖來自Unsplash,基于CC0協議。
該文觀點僅代表作者本人,人人都是產品經理平臺僅提供信息存儲空間服務。
棒~