App產品原型背后要交代的細節或要理解的原則(六)
本文接上一篇「App產品原型背后要交代的細節或要理解的原則(五)」。
22 「緩存」是整體性、系統性的工作
使用緩存,主要是提高性能和離線訪問數據(用戶需求或體驗)。比如,緩存可以支持離線訪問、支持用戶離線操作、減少用戶流量損耗、提升速度、節約訪問服務器成本等。
其原理就是將加載過的內容存儲下來(緩存),下次讀取時,首先從緩存中查找,找到了則直接執行,找不到則再從內存中找。
1. 產品經理在處理緩存問題的三類場景
第一類,功能或性能上必須緩存。這種情況下無需產品經理強調,開發都會進行緩存處理的。
比如微信通訊錄中用戶的頭像,在第一次加載的時候就全部拿到。之后刷新列表,都將基于前一次緩存的數據重新進行更新。
第二類,產品經理有目的地針對具體功能要求給予緩存。根據KANO模型,多是為了做出用戶期望的或興奮的效果。
比如,資訊閱讀類App,用戶第一次加載出的內容緩存下來。下次因網絡太差無法加載數據時,可以看到老信息。
第三類,在產品功能基本完善的時候,將緩存作為一個系統整體機制來梳理和規范。這個時候產品經理做的是排查,然后以緩存作為方案進行補充完善。
產品經理要清楚一般App的緩存習慣,比如如下場景:
- 聊天記錄(使用IM及時聊天SDK的情況下,往往本身就是保存了的);
- 個人資料(用戶自己在本地維護的,所以無需拉取服務器);
- 自己創作的作品(原理同個人資料);
- 草稿或編輯一半的內容(比如制作視頻的規程中意外中斷了操作,下次進入可以繼續);
- 支付明細,或其他操作記錄。
- 其他。
以上,有的可能在開發的過程已經實現了。但最終產品經理要做一個核查和規范。
2. 緩存的數據到哪里了
緩存數據就是存在手機的文件夾路徑中了。當然也可以存儲在相冊這樣的地方。必要的時候產品經理要與開發定義。
總的來說,App緩存的位置分內部存儲和外部存儲兩類(以前的手機的SD卡就是外部存儲)。
內部存儲里的文件默認是只能被指定的App訪問的。卸載App的時候,里面的相關文件都清除干凈。
外部存儲并不總是可用的,往往需要請求授權,比如訪問相冊。當用戶卸載App時,系統僅僅會刪除其中相關的文件。
3. 緩存數據的清除
緩存本質就是拿內容換時間,因此緩存的內容會擠壓存儲空間,甚至拖累性能。通常自動清除,結合手動清除。
自動清理緩存的兩個要素:設置緩存的上限、設置清理緩存的頻率。
比如UCG的視頻,App每次刷新可以加載10個,且不重復加載,那么就可以將每次加載的視頻ID存儲在手機中,下次加載做差異化扣減。但是顯然這個量日積月累也夠大的。所以可以設置為(比如)每周自動清除一次。
手動清除,比如微信的清除緩存。
手動和被動清除,都需要代碼規定哪些可以清掉,哪些不能,這個在具體應用中要與開發約定。
23 「版本更新」的三種場景
版本更新,通常是通過應用市場、使用時提醒用戶、離線時推送消息,這三種手段分別對應三種用戶與App的場景。
1. 彈框更新提醒
版本發布到應用市場,市場就會判斷后提醒用戶更新(當然前提是用戶得來到應用市場)。如果用戶不來,就需要App內彈窗提醒更新。
打開應用時,通過彈窗的方式來告訴用戶有新的版本了。好處在于用戶使用產品時就能夠看見,有針對性。不好的是打擾到用戶了。
一種常見的機制是,設置兩個版本號,一個開發版本號,另一個是顯示給用戶的用戶版本號。每個App版本都有唯一的開發版本號,就像序列號一樣唯一且嚴格。
而顯示版本號是給用戶看的,所以可以擬定,在用戶打開應用時校驗版本差別。
后臺設置的參數有:開發版本號、顯示版本號、更新內容、是否啟用等。
還有一個看不見的規則:當新版本的【開發版本號】大于用戶版本的【開發版本號】,則強制更新;否則,更新,但不強制。
舉個例子:用戶的App的當前顯示版本號是V1.1.1,開發版本號是1.2.2。發布了更新,并在后臺設置新版的顯示版本號是V1.1.2,開發版本號是1.2.2,那么啟動后,會彈框提醒,但是不強制用戶更新。
2. 總結彈框更新提醒
- 每次打開App,都校驗是否有新版本;若有,則校驗是否屬于強制更新。強制更新 則只能更新,或者退出應用;非強制更新可以不更,繼續使用;
- 安卓往往從公司服務器下載(避免商城的不確定性),當然也可以像IOS一樣跳往應用商店;
- 安卓受管制少,所以一般直接顯示下載進度條,下載不能打斷或暫停;下載完畢 toast提示,同時直接安裝;安裝完畢 toast提示,同時直接打開APP;
- 提醒更新和商店更新的文案不同。提醒更新的更簡潔,文案在后臺配置。比如,要求最多顯示6行(一行顯示不完的自動換行,超行與換行符的換行無差別對待),超出6行的顯示…
3. 推送消息通知更新
提醒更新前提是用戶打開App,為避免用戶長久不打開App,也可以通過發推送的方式提醒用戶更新版本。
推送不能點擊后直接跳入AppStore。其主要作用是提醒用戶:最近我有很多好玩的新功能哦,快來瞅瞅吧。
24 熱更新就那點事
熱更新就是,通過一些技術手段,直接對線上App添加新功能或者修改bug,以避開上架審核造成的麻煩或不通過。該過程所用的技術手段就統稱為熱更新。
熱更新時候,可以通知用戶手動觸發,比如王者榮耀。也可以不告訴用戶,直接更新。無論代碼是原生還是H5,理論上都可以進行熱更新。
熱更新可以理解為代碼版本更新的一個細分手段,只下載缺失的那部分內容,文件對比后 重新合并,減少了下載量。
25 關于安裝測試包
1. 正式包與測試包
測試App時候,可以使用正式包(生產包),也可以使用測試包,二者因連接兩個不同環境的服務器而區別。
需要注意的是,這與是否連外網沒必然關系,測試環境也可以連外網,供在公司之外測試。
有時候我們需要生產和測試環境切換來來排查問題,安卓的開發員通常會寫一個開發者模式,這樣安裝一個APK包,就可以在測試版和正式版之間切換。
正式包與測試包通常是同一份代碼,分別發布在不同的環境中。但需要注意, 兩個版本可能不對稱。比如1.1版本的代碼只在正式服務器發布了,那么切換到測試服務器的時候代碼是不一樣的,功能就不一樣了。
2. 安裝版本
安裝新版本的時候,安卓可以文件傳輸形式進行安裝。但是蘋果不能。蘋果需要連手機線在特定環境下安裝。當然也可以申請一個臨時的小版本企業賬戶(百十來個人的上限),因為蘋果管控比較嚴格。
新舊安裝包安裝時候,壓縮包簽名相同的會自動覆蓋,這樣更新之后賬號依然在,類似熱更新。但最好是先卸載舊的,避免可能的沖突。
26 APK壓縮是最后一關
精簡安裝包大小對用戶升級等待時間和流量消耗影響很大。在正式發布之前,會抽出一段時間,著重壓縮安裝包。
基本是從兩個思路去減少APK體積的:減少代碼的大小、減少資源的大小。
1. 減少代碼的大小
比如,刪除無用的代碼邏輯,刪除無用的產品邏輯,混淆代碼,把一些代碼做內聯,把代碼中的類名、方法名和變量名替換成更加短小的無意義名字,測試代碼分離等。
2. 減少資源的大小
其原理就是找出里面較大的文件或數據庫,進行壓縮。比如封面圖或字體大小,若壓縮之后清晰度可以,那么就這么干了。
通常開發通過插件,對所有的圖片進行遍歷,自動壓縮成webp,并刪除原來的圖片;很多png是不能進行webp化,那么可以進行tinypng壓縮。
壓縮應用是個持續工作。如果沒有去持續關注,很可能一點點就擠壓過大了。
#相關閱讀#
#專欄作家#
唧唧歪歪PM,公眾號:唧唧歪歪PM(ID:jjyypm),人人都是產品經理專欄作家。書籍《后端產品經理寶典》作者,藥學碩士轉行互聯網產品多年;熟悉跨境電商業務,醫藥領域;擅長大型后臺體系,社交App。
本文原創發布于人人都是產品經理,未經作者許可,禁止轉載。
題圖來自Unsplash,基于CC0協議
連續看大佬多篇文章呢 少有 的干活 鼓勵繼續輸出
不錯