智能手機的普及比電腦要短，但目前已經成為了我們生活中必不可少的工具了。手機的性能和配置也在不斷提高，作為産品經理，需要基于使用者最常關注的性能問題，明确産品設計的需求。本文将探讨産品設計時的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安裝包一緻，即減小代碼檔案、資源檔案及其他支援檔案的大小，通過優化代碼、壓縮資源檔案、删除非必要支援檔案等方式達到目的。
本文節選自作者新書《産品經理技術手冊》，本書定位于讓不懂技術的産品經理從産品經理的工作和思考方式切入了解應該掌握的技術原理。
作者：小風，産品經理；公衆号：村上風
本文由 @小風老師 原創釋出于人人都是産品經理。未經許可，禁止轉載。
題圖來自Unsplash，基于CC0協定。
該文觀點僅代表作者本人，人人都是産品經理平台僅提供資訊存儲空間服務。