本文接上一篇「」。

22 「緩存」是整體性、系統(tǒng)性的工作

使用緩存，主要是提高性能和離線訪問數(shù)據(jù)（用戶需求或體驗）。比如，緩存可以支持離線訪問、支持用戶離線操作、減少用戶流量損耗、提升速度、節(jié)約訪問服務(wù)器成本等。

其原理就是將加載過的內(nèi)容存儲下來（緩存），下次讀取時，首先從緩存中查找，找到了則直接執(zhí)行，找不到則再從內(nèi)存中找。

1. 產(chǎn)品經(jīng)理在處理緩存問題的三類場景

第一類，功能或性能上必須緩存。這種情況下無需產(chǎn)品經(jīng)理強(qiáng)調(diào)，開發(fā)都會進(jìn)行緩存處理的。

比如微信通訊錄中用戶的頭像，在第一次加載的時候就全部拿到。之后刷新列表，都將基于前一次緩存的數(shù)據(jù)重新進(jìn)行更新。

第二類，產(chǎn)品經(jīng)理有目的地針對具體功能要求給予緩存。根據(jù)KANO模型，多是為了做出用戶期望的或興奮的效果。

比如，資訊閱讀類App，用戶第一次加載出的內(nèi)容緩存下來。下次因網(wǎng)絡(luò)太差無法加載數(shù)據(jù)時，可以看到老信息。

第三類，在產(chǎn)品功能基本完善的時候，將緩存作為一個系統(tǒng)整體機(jī)制來梳理和規(guī)范。這個時候產(chǎn)品經(jīng)理做的是排查，然后以緩存作為方案進(jìn)行補(bǔ)充完善。

產(chǎn)品經(jīng)理要清楚一般App的緩存習(xí)慣，比如如下場景：

1. 聊天記錄（使用IM及時聊天SDK的情況下，往往本身就是保存了的）；
2. 個人資料（用戶自己在本地維護(hù)的，所以無需拉取服務(wù)器）；
3. 自己創(chuàng)作的作品（原理同個人資料）；
4. 草稿或編輯一半的內(nèi)容（比如制作視頻的規(guī)程中意外中斷了操作，下次進(jìn)入可以繼續(xù)）；
5. 支付明細(xì)，或其他操作記錄。
6. 其他。

以上，有的可能在開發(fā)的過程已經(jīng)實現(xiàn)了。但最終產(chǎn)品經(jīng)理要做一個核查和規(guī)范。

2. 緩存的數(shù)據(jù)到哪里了

緩存數(shù)據(jù)就是存在手機(jī)的文件夾路徑中了。當(dāng)然也可以存儲在相冊這樣的地方。必要的時候產(chǎn)品經(jīng)理要與開發(fā)定義。

總的來說，App緩存的位置分內(nèi)部存儲和外部存儲兩類（以前的手機(jī)的SD卡就是外部存儲)。

內(nèi)部存儲里的文件默認(rèn)是只能被指定的App訪問的。卸載App的時候，里面的相關(guān)文件都清除干凈。

外部存儲并不總是可用的，往往需要請求授權(quán)，比如訪問相冊。當(dāng)用戶卸載App時，系統(tǒng)僅僅會刪除其中相關(guān)的文件。

3. 緩存數(shù)據(jù)的清除

緩存本質(zhì)就是拿內(nèi)容換時間，因此緩存的內(nèi)容會擠壓存儲空間，甚至拖累性能。通常自動清除，結(jié)合手動清除。

自動清理緩存的兩個要素：設(shè)置緩存的上限、設(shè)置清理緩存的頻率。

比如UCG的視頻，App每次刷新可以加載10個，且不重復(fù)加載，那么就可以將每次加載的視頻ID存儲在手機(jī)中，下次加載做差異化扣減。但是顯然這個量日積月累也夠大的。所以可以設(shè)置為（比如）每周自動清除一次。

手動清除，比如微信的清除緩存。

手動和被動清除，都需要代碼規(guī)定哪些可以清掉，哪些不能，這個在具體應(yīng)用中要與開發(fā)約定。

23 「版本更新」的三種場景

版本更新，通常是通過應(yīng)用市場、使用時提醒用戶、離線時推送消息，這三種手段分別對應(yīng)三種用戶與App的場景。

1. 彈框更新提醒

版本發(fā)布到應(yīng)用市場，市場就會判斷后提醒用戶更新（當(dāng)然前提是用戶得來到應(yīng)用市場）。如果用戶不來，就需要App內(nèi)彈窗提醒更新。

打開應(yīng)用時，通過彈窗的方式來告訴用戶有新的版本了。好處在于用戶使用產(chǎn)品時就能夠看見，有針對性。不好的是打擾到用戶了。

一種常見的機(jī)制是，設(shè)置兩個版本號，一個開發(fā)版本號，另一個是顯示給用戶的用戶版本號。每個App版本都有唯一的開發(fā)版本號，就像序列號一樣唯一且嚴(yán)格。

而顯示版本號是給用戶看的，所以可以擬定，在用戶打開應(yīng)用時校驗版本差別。

后臺設(shè)置的參數(shù)有：開發(fā)版本號、顯示版本號、更新內(nèi)容、是否啟用等。

還有一個看不見的規(guī)則：當(dāng)新版本的【開發(fā)版本號】大于用戶版本的【開發(fā)版本號】，則強(qiáng)制更新；否則，更新，但不強(qiáng)制。

舉個例子：用戶的App的當(dāng)前顯示版本號是V1.1.1，開發(fā)版本號是1.2.2。發(fā)布了更新，并在后臺設(shè)置新版的顯示版本號是V1.1.2，開發(fā)版本號是1.2.2，那么啟動后，會彈框提醒，但是不強(qiáng)制用戶更新。

2. 總結(jié)彈框更新提醒

1. 每次打開App，都校驗是否有新版本；若有，則校驗是否屬于強(qiáng)制更新。強(qiáng)制更新 則只能更新，或者退出應(yīng)用；非強(qiáng)制更新可以不更，繼續(xù)使用；
2. 安卓往往從公司服務(wù)器下載（避免商城的不確定性），當(dāng)然也可以像IOS一樣跳往應(yīng)用商店；
3. 安卓受管制少，所以一般直接顯示下載進(jìn)度條，下載不能打斷或暫停；下載完畢 toast提示，同時直接安裝；安裝完畢 toast提示，同時直接打開APP；
4. 提醒更新和商店更新的文案不同。提醒更新的更簡潔，文案在后臺配置。比如，要求最多顯示6行（一行顯示不完的自動換行，超行與換行符的換行無差別對待），超出6行的顯示…

3. 推送消息通知更新

提醒更新前提是用戶打開App，為避免用戶長久不打開App，也可以通過發(fā)推送的方式提醒用戶更新版本。

推送不能點(diǎn)擊后直接跳入AppStore。其主要作用是提醒用戶：最近我有很多好玩的新功能哦，快來瞅瞅吧。

24 熱更新就那點(diǎn)事

熱更新就是，通過一些技術(shù)手段，直接對線上App添加新功能或者修改bug，以避開上架審核造成的麻煩或不通過。該過程所用的技術(shù)手段就統(tǒng)稱為熱更新。

熱更新時候，可以通知用戶手動觸發(fā)，比如王者榮耀。也可以不告訴用戶，直接更新。無論代碼是原生還是H5，理論上都可以進(jìn)行熱更新。

熱更新可以理解為代碼版本更新的一個細(xì)分手段，只下載缺失的那部分內(nèi)容，文件對比后 重新合并，減少了下載量。

25 關(guān)于安裝測試包

1. 正式包與測試包

測試App時候，可以使用正式包（生產(chǎn)包），也可以使用測試包，二者因連接兩個不同環(huán)境的服務(wù)器而區(qū)別。

需要注意的是，這與是否連外網(wǎng)沒必然關(guān)系，測試環(huán)境也可以連外網(wǎng)，供在公司之外測試。

有時候我們需要生產(chǎn)和測試環(huán)境切換來來排查問題，安卓的開發(fā)員通常會寫一個開發(fā)者模式，這樣安裝一個APK包，就可以在測試版和正式版之間切換。

正式包與測試包通常是同一份代碼，分別發(fā)布在不同的環(huán)境中。但需要注意， 兩個版本可能不對稱。比如1.1版本的代碼只在正式服務(wù)器發(fā)布了，那么切換到測試服務(wù)器的時候代碼是不一樣的，功能就不一樣了。

2. 安裝版本

安裝新版本的時候，安卓可以文件傳輸形式進(jìn)行安裝。但是蘋果不能。蘋果需要連手機(jī)線在特定環(huán)境下安裝。當(dāng)然也可以申請一個臨時的小版本企業(yè)賬戶（百十來個人的上限），因為蘋果管控比較嚴(yán)格。

新舊安裝包安裝時候，壓縮包簽名相同的會自動覆蓋，這樣更新之后賬號依然在，類似熱更新。但最好是先卸載舊的，避免可能的沖突。

26 APK壓縮是最后一關(guān)

精簡安裝包大小對用戶升級等待時間和流量消耗影響很大。在正式發(fā)布之前，會抽出一段時間，著重壓縮安裝包。

基本是從兩個思路去減少APK體積的：減少代碼的大小、減少資源的大小。

1. 減少代碼的大小

比如，刪除無用的代碼邏輯，刪除無用的產(chǎn)品邏輯，混淆代碼，把一些代碼做內(nèi)聯(lián)，把代碼中的類名、方法名和變量名替換成更加短小的無意義名字，測試代碼分離等。

2. 減少資源的大小

其原理就是找出里面較大的文件或數(shù)據(jù)庫，進(jìn)行壓縮。比如封面圖或字體大小，若壓縮之后清晰度可以，那么就這么干了。

通常開發(fā)通過插件，對所有的圖片進(jìn)行遍歷，自動壓縮成webp，并刪除原來的圖片；很多png是不能進(jìn)行webp化，那么可以進(jìn)行tinypng壓縮。

壓縮應(yīng)用是個持續(xù)工作。如果沒有去持續(xù)關(guān)注，很可能一點(diǎn)點(diǎn)就擠壓過大了。

#相關(guān)閱讀#

#專欄作家#

唧唧歪歪PM，公眾號：唧唧歪歪PM（ID：jjyypm），人人都是產(chǎn)品經(jīng)理專欄作家。書籍《后端產(chǎn)品經(jīng)理寶典》作者，藥學(xué)碩士轉(zhuǎn)行互聯(lián)網(wǎng)產(chǎn)品多年；熟悉跨境電商業(yè)務(wù)，醫(yī)藥領(lǐng)域；擅長大型后臺體系，社交App。

本文原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)作者許可，禁止轉(zhuǎn)載。

題圖來自Unsplash，基于CC0協(xié)議