在當(dāng)今快速迭代的互聯(lián)網(wǎng)產(chǎn)品領(lǐng)域，社交App作為用戶日常生活中不可或缺的一部分，其設(shè)計(jì)細(xì)節(jié)和用戶體驗(yàn)至關(guān)重要。本文作者憑借多年的產(chǎn)品設(shè)計(jì)經(jīng)驗(yàn)，從產(chǎn)品經(jīng)理的視角出發(fā)，總結(jié)了27條關(guān)于社交App項(xiàng)目的產(chǎn)品設(shè)計(jì)經(jīng)驗(yàn)。

產(chǎn)品經(jīng)理常常很快就把原型畫出完了，但是在設(shè)計(jì)UI的時(shí)候或開發(fā)的時(shí)候就常常被拉去澄清細(xì)節(jié)。

原因就是對(duì)設(shè)計(jì)的細(xì)節(jié)交代不清楚，或者了解的不甚深入，缺少對(duì)邊界或排他項(xiàng)的界定。

筆者將社交App項(xiàng)目做下來后，整理如下見解。

本文就移動(dòng)端App產(chǎn)品的日?？偨Y(jié)，從產(chǎn)品經(jīng)理設(shè)計(jì)需求的角度，分享一些注意事項(xiàng)和細(xì)節(jié)如下。歡迎批評(píng)探討。

1、明確App的按鈕類型

從定義需求的角度來說，產(chǎn)品經(jīng)理只要交代了哪里是按鈕就可以了，可以通篇一律使用同一個(gè)按鈕線框表達(dá)。

但是這只能是個(gè)初稿，在落實(shí)之前，產(chǎn)品經(jīng)理或交互設(shè)計(jì)師需要確定按鈕的具體形態(tài)。

一般而言，一個(gè)APP的按鈕設(shè)定四種就夠了，設(shè)置的維度可以是按鈕的定位權(quán)重。（注意，菜單的入口或圖表不包括在本次討論中，比如微信的+、定位圖標(biāo)這種）。

1. 權(quán)重最高的按鈕：這種按鈕一般比較大，顏色明顯，主題鮮明。常見的比如用戶“登錄”按鈕；
2. 中等權(quán)重的按鈕：這種按鈕在產(chǎn)品中最為常見，比如一般的詢問框上的【確定/取消】按鈕；
3. 權(quán)重最小的按鈕：比如“關(guān)閉”、“查看更多”按鈕。這些按鈕的作用就是可以點(diǎn)擊，用戶看得到即可。這種按鈕形式多樣，可以沒有框，只有文字。也可以只是個(gè)圖形，比如關(guān)閉按鈕用x表示；
4. 特殊按鈕，這種按鈕區(qū)別于其他的按鈕，少且特別。要么是帶很多文字，要么是App的核心入口，比如soul首頁的“靈魂匹配”按鈕。

在輸出的需求文檔中，可以一開始在“全局規(guī)范”中就定義這四種按鈕代號(hào)，然后在原型中備注按鈕類型的代號(hào)。

這樣設(shè)計(jì)就知道你是要怎么樣的效果了。

2、了解第三方登錄的本質(zhì)

社交類App登錄方式，基本都是手機(jī)驗(yàn)證碼為主，配合第三方登陸，很少注冊(cè)賬號(hào)密碼（與App的定位和用戶群有關(guān)）。

第三方登錄就是借助第三方應(yīng)用的接口實(shí)現(xiàn)用戶登記，比如常見的三家：微信、QQ、微博。

其目的之一是關(guān)聯(lián)賬號(hào)，形成社交群落之間的呼應(yīng)，有利于用戶生態(tài)鏈的搭建；其二是獲取用戶的一部分已有信息，比如用戶信息或流量資源。需要注意的有兩點(diǎn)：

（1）第三方賬號(hào)給的資料完善度和安全性不好把控。比如你期望獲取QQ中的頭像、昵稱、年齡、地區(qū)，但是QQ可能只給你頭像和昵稱。

又比如有一天第三方封了接口，那么第三方登錄功能就停擺了。

（2）第三方登錄方式，對(duì)用戶來說不一定就是省時(shí)省力的渠道。因?yàn)橄嚓P(guān)法規(guī)的要求很多APP是需要用戶手機(jī)號(hào)的，而第三方登錄并不能獲取用戶已經(jīng)提供給第三方的手機(jī)號(hào)（用戶隱私）。

因此對(duì)用戶來說常常是使用第三方登錄后，仍然要跳轉(zhuǎn)到驗(yàn)證手機(jī)號(hào)的界面，還不如直接使用手機(jī)驗(yàn)證登錄。

3、我們常見的支付功能的貓膩

支付很常見，社交應(yīng)用的虛擬禮物購買、知識(shí)平臺(tái)的付費(fèi)學(xué)習(xí)等。在設(shè)計(jì)支付功能的時(shí)候，主要注意的是要從安卓和IOS兩個(gè)系統(tǒng)的角度區(qū)分設(shè)計(jì)。

（1）首先明確一個(gè)常識(shí)，就是支付必須是有資質(zhì)的支付平臺(tái)才能進(jìn)行操作處理。

這就是為什么很多大的電商公司的交易要經(jīng)過支付公司的結(jié)算才能拿到錢，比如paypal、騰付通、支付寶、微信支付、網(wǎng)銀在線等。其中安卓手機(jī)最常用的是支付寶或者微信。

（2）安卓系統(tǒng)接通第三方支付體系還是比較友好的，手續(xù)費(fèi)也不高。調(diào)用支付寶或微信支付，會(huì)返回其綁定的銀行卡或者余額，可以作為業(yè)務(wù)數(shù)據(jù)保存在后臺(tái)。

有時(shí)候前端感受不到這個(gè)數(shù)據(jù)，產(chǎn)品經(jīng)理應(yīng)該知道，作為功能擴(kuò)展的考慮因素。

（3）蘋果手機(jī)（IOS系統(tǒng)）正常來說只能調(diào)用蘋果支付，蘋果順帶扣的手續(xù)費(fèi)比較高。

虛擬支付的時(shí)候，安卓是可以使用任意金額充值的，但是蘋果手機(jī)對(duì)特定的原幣，只能選擇固定的金額。

這個(gè)是因?yàn)樘O果公司將充值金額本身固定了，當(dāng)成一個(gè)一個(gè)的商品對(duì)外出售。

如下圖就是蘋果提供的清單，比如可以購買的價(jià)格列就是需要支付的金額，收入列就是扣掉手續(xù)費(fèi)之后有效的金額?？梢钥吹交?元錢，在蘋果這里只剩下了4.12元。

這就是為什么陌陌同樣是充值6塊錢，安卓系統(tǒng)給60個(gè)虛擬幣，蘋果只給42個(gè)幣。

4、了解后臺(tái)數(shù)據(jù)的存儲(chǔ)

做APP的不僅要盯住頁面和用戶，也要理解數(shù)據(jù)的運(yùn)作，這樣對(duì)內(nèi)容推送機(jī)制、數(shù)據(jù)搜索的頁面展示的方案選型幫助很大。這里介紹三點(diǎn)：

（1）初創(chuàng)公司的數(shù)據(jù)基本都使用的云端存儲(chǔ)，同時(shí)配合自己的數(shù)據(jù)庫。從效率和安全性上都會(huì)更有保障。產(chǎn)品經(jīng)理需大概了解數(shù)據(jù)存儲(chǔ)的定位。

以視頻直播類為例，直播或視頻數(shù)據(jù)文件占存比較大，一般都是存儲(chǔ)在云端的，而用戶業(yè)務(wù)數(shù)據(jù)放在自己的服務(wù)器的數(shù)據(jù)庫中，原因很簡(jiǎn)單這些牽扯更多的隱私和安全責(zé)任，且一般數(shù)據(jù)不會(huì)太多。

（2）產(chǎn)品經(jīng)理需直觀地理解關(guān)系型數(shù)據(jù)庫和非關(guān)系型數(shù)據(jù)庫。比如非關(guān)系型的mongdb數(shù)據(jù)庫，一般存儲(chǔ)信息量大的不定型數(shù)據(jù)，比如用戶日志。而MySQL則承擔(dān)了大部分可以用二維表表達(dá)的規(guī)則的數(shù)據(jù)，比如用戶資料、數(shù)據(jù)字典的參數(shù)配置等。

（3）數(shù)據(jù)存儲(chǔ)與頁面的搜索方式等方面都有很大關(guān)系。比如，在“我的好友”中搜索用戶昵稱，是只搜索自己關(guān)系為好友的用戶，還是搜出有一部分是好友，另一部分非好友的用戶并用標(biāo)簽分類呢？

這兩個(gè)方案前者比較保守，但是如果期望用戶擴(kuò)大社交圈的話后者更有價(jià)值。因?yàn)椴粌H可以看到好友并且還能提供增加陌生人為好友的功能。

但是這時(shí)候還要結(jié)合后臺(tái)數(shù)據(jù)的存儲(chǔ)，是否好友和陌生人存儲(chǔ)在一個(gè)表里了呢，如果分開了那最好就不要一起搜索，隨著用戶量增大，聊表查詢很耗性能。

5、了解前后端接口

項(xiàng)目過程中，前端與后端開發(fā)之間溝通需求基本都是圍繞接口請(qǐng)求數(shù)據(jù)進(jìn)行的。接口是前后端分開開發(fā)的行業(yè)標(biāo)配嗎，是高內(nèi)聚的體現(xiàn)。

因此產(chǎn)品經(jīng)理要理解接口的原理和自己的目的，協(xié)助前后端完善接口的定義（另一篇文章有專門介紹）。

后端開發(fā)在寫接口的時(shí)候，一般需要知道未來的走向，包括數(shù)據(jù)量級(jí)、功能擴(kuò)展性等。

產(chǎn)品經(jīng)理要針對(duì)該功能給開發(fā)們說清楚未來的擴(kuò)展可能性。比如：App的用戶動(dòng)態(tài)的評(píng)論，計(jì)劃是展示一部分優(yōu)質(zhì)評(píng)論內(nèi)容（類似微信的朋友圈）在外層，類似下圖：

但是對(duì)于展開部分的算法尚還在研究階段，因此這個(gè)版本將評(píng)論折疊，只顯示數(shù)字。點(diǎn)開則打開評(píng)論列表。

后端在給前端傳的接口中，可能會(huì)多設(shè)計(jì)出“是否展示在外層”標(biāo)識(shí)，提前預(yù)留參數(shù)，以后版本用。本版本前端只需填留下自己需要的信息即可。

6、圖片比例、圓角和縮放的注意事項(xiàng)

App用到圖片的地方很多，每一處又可能有不同狀態(tài)下的不同表現(xiàn)形式。產(chǎn)品經(jīng)理不能只放一張圖了事。應(yīng)當(dāng)對(duì)圖片不同場(chǎng)景下的樣式列舉清楚。比如下面幾點(diǎn)：

（1）縮略圖的縮放比例

微信朋友圈的列表中，圖片都是縮略的。那么設(shè)計(jì)的時(shí)候首先就是縮略方式的問題。

之所以要給出縮小的比例或最終尺寸大小，是因?yàn)榕臄z的手機(jī)屏幕尺寸和比例不一致，上傳的圖片又可能有各種形狀。

因此發(fā)布之后要給予對(duì)應(yīng)的規(guī)則和秩序。避免效果模糊、展示不全、圖片過小等不良效果。

在確定方案的時(shí)候，合理即可?？梢酝ㄟ^研究競(jìng)品，找近期流行的產(chǎn)品的規(guī)律。比如：

按圖片或視頻的H:W:

①H:W>4/3(高圖）：切上下兩端，保存為4/3，靠左展示。

②3/4≤(H:W)<4/3之間(方圖）：切成正方形，靠中間展示。

③H:W≤3/4(扁圖）：切成3/4，靠中間展示。

以上并不一定是最好的，但是秩序是要給到開發(fā)的。

（2）圖片的圓角和直角

留意的話，就會(huì)發(fā)現(xiàn)有的App的圖片是圓角的有的是直角的。

目的只有一個(gè)，就是確定這兩種展示方式哪種更符合產(chǎn)品的定位和氣質(zhì)。

一般而言，做社交類的產(chǎn)品，圖片用圓角看著舒服和氣。做技術(shù)類的或者法律類的比較嚴(yán)肅的產(chǎn)品，可以考慮直角。

最后還是一句話，看競(jìng)品，以及一段時(shí)間流行哪種。

（3）大圖和縮略圖

消息發(fā)送成功之后 ，圖片也是縮略的。并且要設(shè)計(jì)發(fā)送失敗的提示圖例。點(diǎn)擊打開之后大圖是否鋪滿整個(gè)窗口？

最后就是不要忘記做縮略圖和大圖，這是完整的一套。

另外在很多公司，這個(gè)算是設(shè)計(jì)師方面的工作，但是產(chǎn)品經(jīng)理要全局把關(guān)，就要知其然知其所以然，不是主管覺得看著順眼就這樣吧。

7、產(chǎn)品經(jīng)理對(duì)視頻拍攝窗口的界定

產(chǎn)品經(jīng)理在設(shè)計(jì)拍攝視頻或圖片功能的時(shí)候，需要考慮是否滿屏拍攝，是否限制必須按一定比例拍攝等。

之所以考慮這個(gè)問題，是因?yàn)橛械氖謾C(jī)全屏比例拍攝的效果并不美觀。另外一些帶劉海的手機(jī)屏幕，劉海部位必然是看不到拍攝畫面的。

因此為了避免這個(gè)影響，很多產(chǎn)品就會(huì)選擇將上方平齊與劉海的高度遮住，設(shè)置成只支持劉海以下拍攝。

當(dāng)然，也有將底部菜單位置遮住的，還有的規(guī)則是只允許拍攝出指定比例的畫面，比如安寬度固定，取16:9的畫面作為視頻窗口，多余的部分在拍攝期間都用黑色背景遮住。

這種規(guī)則的制定有好有壞，屬于A/B選擇的問題。這個(gè)選擇，需要產(chǎn)品經(jīng)理來定。

產(chǎn)品經(jīng)理可以通過借鑒競(jìng)品和分析本產(chǎn)品的定位，有理有據(jù)地說出自己的理由，支持自己的觀點(diǎn)即可。

8、將低頻功能放深一點(diǎn)，以便將高頻功能凸顯出來

以拍攝視頻后的貼紙為例，貼紙可以貼在視頻的指定位置，也可以應(yīng)用在視頻的某一時(shí)間段上。

但是根據(jù)調(diào)研，多數(shù)用戶使用的功能只是選擇貼紙、刪除貼紙和拖動(dòng)位置。少數(shù)用戶才會(huì)花精力在手機(jī)上調(diào)整貼紙應(yīng)用的時(shí)間段，因?yàn)檫@個(gè)操作稍微有點(diǎn)麻煩。

但是畢竟還是有這么一小部分用戶是希望將自己拍攝的作品精益求精的，對(duì)此我們看如下方案：

方案一，在選擇貼紙的同時(shí)就展示出時(shí)間軸，讓用戶選擇貼紙和應(yīng)用的時(shí)間軸一次性完成。讓功能集中在一處開始和結(jié)束，干凈利索。

方案二，將選擇貼紙、刪除貼紙和拖動(dòng)位置放在第一層。完成之后，再點(diǎn)擊該貼紙，彈出‘編輯’，這才進(jìn)入時(shí)間軸的編輯。

很明顯第二個(gè)方案要好一些，一來提高了大部分用戶的操作效率，不被無關(guān)的功能干擾；另外也不會(huì)影響發(fā)燒用戶進(jìn)一步挖掘極致。

這其實(shí)是整個(gè)產(chǎn)品設(shè)計(jì)的指導(dǎo)思想：考慮了復(fù)雜性和使用頻率，針對(duì)大眾用戶和極致用戶進(jìn)行功能分離，最終實(shí)現(xiàn)完美的效果。

9、圖片上傳、壓縮等需要注意的細(xì)節(jié)

圖片上傳是APP離不開的功能，比如聊天消息、上傳照片做認(rèn)證或頭像等。

提到圖片上傳，就離不開上傳的規(guī)制、發(fā)送或上傳成功的效果、點(diǎn)擊后的效果、發(fā)布失敗的效果、下載到本地的效果等。具體可以這樣分析：

（1）上傳的圖片文件大小和尺寸大小的要求：

在服務(wù)器承受的壓力之內(nèi)盡量不做限制，必要的時(shí)候才給予閾值。作為產(chǎn)品經(jīng)理，需要與開發(fā)溝通當(dāng)前的方案選項(xiàng)是否有限制的必要。

一般而言，可以由客戶端自行壓縮或調(diào)整后展示。

對(duì)于PRD，給不給上述限制都要交代清楚。

（2）限制一次上傳的圖片張數(shù)：

比如微信是9張，抖音12張。對(duì)于PRD，該限制雖小，但要交代清楚。

（3）上傳的圖片限制格式：

一般盡量不限制。作為產(chǎn)品經(jīng)理，需要與開發(fā)溝通當(dāng)前的方案選項(xiàng)是否有限制的必要。對(duì)于PRD，要交代清楚。

（4）上傳圖片后展示的效果：

一般都是縮略圖，固定顯示的長(zhǎng)寬高。上傳失敗的圖片，支持再次上傳。

點(diǎn)擊上傳成功的圖片，打開大圖。

（5）若需要該圖片進(jìn)行小圖標(biāo)或者展示形式的多樣化應(yīng)用，則后臺(tái)只需要保存原圖，其余的格式化應(yīng)用在客戶端進(jìn)行定義。

比如頭像圖片在后臺(tái)存一張大圖，應(yīng)用層面展示的是原型圖。又比如送禮物的圖標(biāo)，選擇的界面展示的是大圖，發(fā)出去之后的消息通知可能就只是個(gè)小圖標(biāo)。

（6）圖片上傳的方式：

①第一種是九宮格式的

典型的就是微信發(fā)朋友圈的圖片上傳功能，這種圖片上傳功能適合上傳多張圖片，圖片的呈現(xiàn)方式一般都是九宮格的方式，在社交類，電商類的商品上傳和寫游記的app上多見。

多用于信息內(nèi)容的展示，一般都是圖文相結(jié)合。一般是先開啟相冊(cè)選取圖片，圖片的點(diǎn)擊順序也一般是最后的呈現(xiàn)順序。

②第二種文件上傳式

一般在聊天界面會(huì)用到這個(gè)功能居多，點(diǎn)擊qq和微信下方工具欄的加號(hào)都會(huì)有一個(gè)圖片上傳的功能，這種功能一般是基于聊天的場(chǎng)景，這部分圖片上傳功能展開的方式都是半浮窗的樣式，系統(tǒng)會(huì)先展示當(dāng)前相冊(cè)最近的幾張圖片，會(huì)有選擇是否發(fā)原圖的設(shè)計(jì)。

③第三種嵌入式圖片上傳

嵌入式圖片上傳一般應(yīng)用在文檔撰寫類的應(yīng)用，在編寫文章的時(shí)候需要嵌入一些圖片說明，這種設(shè)計(jì)時(shí)圖片嵌入屬于一種輔助文檔編輯的功能，一般需要去調(diào)取系統(tǒng)相冊(cè)，然后手動(dòng)從相冊(cè)里選取出你所需要的圖片，可一次性上傳多張圖片。

④第四種添加附件

這種圖片上傳形式一般圖片會(huì)作為附件的形式上傳，也是調(diào)取系統(tǒng)相冊(cè)，一般上傳成功后圖片都是縮略圖的形式展示。

例如我們常用的寫周報(bào)和百度云盤里就常用到這個(gè)功能。這種設(shè)計(jì)的圖片上傳功能適合大批量的圖片上傳。

10、時(shí)間格式的定義

時(shí)間的顯示基本分兩類，一類是展示在外層的，不需要很精準(zhǔn)的時(shí)間，比如聊天環(huán)境下的時(shí)間、用戶動(dòng)態(tài)外層顯示的時(shí)間；另一種作為嚴(yán)格的時(shí)間落款，比如賬單明細(xì)。

后者基本可以一刀切，就用年月日時(shí)分秒，一般都不是問題。

前者就要切合場(chǎng)景，對(duì)時(shí)間的要求和用戶情感的匹配性，融入一定的感情色彩或者暗示。這里就有多種流派，比如推特和微信就區(qū)別很大。

對(duì)于前者，筆者在這里整理一套自己用于聊天信息、評(píng)論、系統(tǒng)消息、動(dòng)態(tài)的時(shí)間的展示規(guī)則，可以作為借鑒：

剛剛（T<1分鐘）；

XX分鐘前（1≤T<1h），比如53分鐘前；

XX小時(shí)前（1h≤T<24h），比如23小時(shí)前；

昨天 +點(diǎn)鐘（24h≤T<48h），比如 昨天 12：20。

日期+點(diǎn)鐘（48h≤T<1年） 比如：6-5 14:52，跨年則加上年 2018-12-9 16:21

年-月（1年≤T） 比如：2018-5

11. 請(qǐng)求設(shè)備授權(quán)可以更簡(jiǎn)捷嗎？

用戶如果未開啟APP的設(shè)備授權(quán)，那么用到相應(yīng)的功能，就需要臨時(shí)提醒用戶授權(quán)。

比如點(diǎn)擊【抖音】的拍攝按鈕進(jìn)行視頻拍攝，就需要請(qǐng)求攝像機(jī)授權(quán)。

如上圖，點(diǎn)擊“去設(shè)置”，則前往手機(jī)的【系統(tǒng)設(shè)置】界面手動(dòng)操作。

相當(dāng)于App只負(fù)責(zé)告訴用戶：我需要你去設(shè)置中授權(quán)。

①若不同意，則放棄視頻功能的使用。

②若同意，則前往【系統(tǒng)設(shè)置】中，執(zhí)行獨(dú)立于App之外的操作。

操作完成，會(huì)發(fā)現(xiàn)連個(gè)返回APP功能都沒有，還需要自己找到App再進(jìn)入一次。是不是很low？

為什么不能在App中一鍵完成授權(quán)呢？

這其實(shí)與手機(jī)操作系統(tǒng)有關(guān)系。

以IOS為例，手機(jī)操作系統(tǒng)對(duì)設(shè)備授權(quán)有一個(gè)規(guī)定：

安裝后，首次打開App，App會(huì)自動(dòng)請(qǐng)求用戶進(jìn)行設(shè)備授權(quán)。

僅此一下，之后打開App，操作系統(tǒng)就不會(huì)幫忙請(qǐng)求了。

因此，若首次未授權(quán)，或之后關(guān)閉了授權(quán)，那么手機(jī)系統(tǒng)不允許App直接一鍵授權(quán)了。

明白這個(gè)道理，設(shè)就可以設(shè)計(jì)出貼合實(shí)際的方案。需摸到操作系統(tǒng)的“屋檐”，適當(dāng)“低頭”。

12.頁面刷新加載的“蘿卜和泥”

刷新，是產(chǎn)品經(jīng)理需要定義的常見的功能。

要么是手動(dòng)觸發(fā)刷新，要么是定時(shí)任務(wù)觸發(fā)。

定時(shí)任務(wù)觸發(fā)，比如1分鐘內(nèi)的消息顯示“剛剛”，那么系統(tǒng)就可以每一分鐘自動(dòng)刷新一次，使顯示合理的時(shí)間格式。

本文主要以手動(dòng)觸發(fā)說明，產(chǎn)品經(jīng)理至少可以考慮四個(gè)方面的問題：

①怎樣的觸發(fā)方式

列表頁面加載，主流觸發(fā)方式是滑動(dòng)，包括上下左右滑動(dòng)。

對(duì)于瀑布流的內(nèi)容為主的產(chǎn)品，刷新較為頻繁，除了使用滑動(dòng)加載之外，還可配合按鈕加載。

比如【抖音】，可以雙擊底部菜單實(shí)現(xiàn)頁面刷新。

“滑動(dòng)+點(diǎn)擊”這樣的設(shè)計(jì)，避免用戶置身于視頻瀑布流中只靠單一滑動(dòng)帶來的枯燥和不適。

②打開新頁面加載的

刷新有打開新頁面的，也有在當(dāng)前頁面加載新內(nèi)容。

打開新頁面的，需要考慮如下：

a. 翻頁方向：目前流行的交互方式，是左右平移或覆蓋平移，比較符合用戶對(duì)線性操作流程的的直觀感受。

b. 加載發(fā)生在翻頁的前還是后呢？

翻頁前加載：適用于需要判斷及驗(yàn)證處理的頁面中。例如表單信息判斷和登錄驗(yàn)證等。

而絕大部分app采用翻過去之后加載，這樣可以極大的增強(qiáng)頁面的流暢感。

③設(shè)計(jì)loading標(biāo)示

a.loading標(biāo)示的樣式

菊花和進(jìn)度條是最基礎(chǔ)的loading標(biāo)示。

若做成動(dòng)畫，或者加入App品牌特色，就更顯誠意了。

 

 

b.loading標(biāo)示的位置

是在頂部、中部、還是底部呢？

若看不出優(yōu)劣，就選一種，并向團(tuán)隊(duì)交代清楚。必要的時(shí)候做A/B測(cè)試。

④加載策略

在實(shí)現(xiàn)機(jī)制上，產(chǎn)品經(jīng)理要說清楚效果。

比如最遲不超過2s、要求某些內(nèi)容先加載出來等等。

這樣就引導(dǎo)出了常見的幾種機(jī)制：

異步加載、分模塊加載、懶加載和預(yù)加載等。

需要注意的是：加載機(jī)制不僅僅是受限于網(wǎng)速，更是信息泛濫時(shí)代的一種策略：

讓用戶優(yōu)先看到什么，節(jié)約用戶精力，提高回報(bào)率。

13. 【消息】模塊的設(shè)計(jì)

①消息歸類

在設(shè)計(jì)消息菜單的時(shí)候，需要考慮默認(rèn)置頂、消息歸類等功能。讓目標(biāo)信息曝光增加，同時(shí)讓消息有條理。

比如，【互動(dòng)通知】置頂在列表的最上方，類于“文件夾”。點(diǎn)擊，則打開系統(tǒng)消息列表。

②未讀提示：數(shù)字還是紅點(diǎn)呢？

一般而言，人與人的聊天顯示未讀條數(shù)，因?yàn)闀r(shí)效性要求高。

超過99條一般顯示99+。

實(shí)際顯示99也可以，對(duì)用戶而言已無差異。

非緊急的通知可以不顯示具體數(shù)字。

消息已讀的判斷標(biāo)準(zhǔn)：只要打開就算已讀。

哪怕眼前條只展出了1條，哪怕沒來得及看就手機(jī)掉線了，也都當(dāng)做已讀處理。

③刪除消息

分兩類，一類是單條聊天記錄的刪除；一類是整個(gè)聊天條目的刪除。

④消息保存時(shí)長(zhǎng)

可以保存在服務(wù)器，用戶可以通過加載，分批查看歷史消息。

此外，考慮聊天消息的復(fù)制、轉(zhuǎn)發(fā)、失敗重發(fā)等。

14. Web在手機(jī)端的適配

產(chǎn)品官網(wǎng)，初期都很簡(jiǎn)單，基本都是：產(chǎn)品介紹+下載鏈接。

功能不復(fù)雜，因此可以考慮設(shè)置手機(jī)訪問官網(wǎng)的功能。

如上圖所示，手機(jī)端直接訪問PC官網(wǎng)體驗(yàn)極差。

因此需要一定程度的適配，大概會(huì)有以下幾種形式：

①極簡(jiǎn)適配

極簡(jiǎn)適配就是對(duì)內(nèi)容進(jìn)行刪減，直到剩下最后一個(gè)頁面，用一個(gè)頁面去呈現(xiàn)最基本的產(chǎn)品介紹以及下載按鈕。

②完全適配

做了全適配的官網(wǎng)會(huì)在手機(jī)端有良好的表現(xiàn)。當(dāng)然，Pc端的官網(wǎng)有時(shí)候體量太大，在適配到手機(jī)端的時(shí)候也要有刪減。

15. 左右滑動(dòng)切換Tab頁簽

很多App的Tab頁簽，支持左右滑動(dòng)切換。那么是不是在設(shè)計(jì)Tab頁簽的時(shí)候都要這樣規(guī)劃呢？

筆者認(rèn)為在確定這個(gè)方案時(shí)，產(chǎn)品經(jīng)理需要考慮如下：

（1）明確滑動(dòng)切換頁簽的優(yōu)缺點(diǎn)

操作步驟上，點(diǎn)擊切換和滑動(dòng)切換都是1個(gè)動(dòng)作事件。只是通常來看，滑動(dòng)操作比點(diǎn)擊操作難度稍低，畢竟點(diǎn)擊需要找到觸發(fā)區(qū)。

另一個(gè)方面，支持滑動(dòng)切換可以覆蓋更多用戶的操作預(yù)期——假設(shè)用戶普遍習(xí)慣滑動(dòng)切換的操作方式。

但是滑動(dòng)切換頁簽的操作本身也有弊端。比如有時(shí)候本來是想上下滑動(dòng)的，但是手指一不小心就滑歪了，于是無意識(shí)觸發(fā)了滑動(dòng)事件，跳到了另一個(gè)頁面去，可能就打斷用戶沉浸式體驗(yàn)。

（2）基于以上，筆者建議如下

①沉浸式的瀑布流，比如抖音的視頻流，不推薦滑切Tab頁。

如果非要做，則將滑動(dòng)切換觸發(fā)靈敏度降低。

②內(nèi)容長(zhǎng)度有限，或者閱讀速度快的Tab頁簽，可以使用滑切。比如電商商品的【參數(shù)】、【評(píng)論】之間的切換。

③除了左右滑動(dòng)切換Tab，還可以結(jié)合下翻切換：如果頁面內(nèi)容較短，那么在下翻至Tab頁內(nèi)容結(jié)束的時(shí)候，緊接著就切換下一頁的內(nèi)容。比如：

最后要注意，不管做不做滑切，產(chǎn)品經(jīng)理都要給予開發(fā)人員明確的說明。

16. 分享功能的“借尸還魂”

（1）分享的原理

第三方平臺(tái)提供了分享接口，目標(biāo)App對(duì)接后，獲取了對(duì)應(yīng)權(quán)限和功能支持。

因此在分享事件中，目標(biāo)App分享出去的內(nèi)容是“客隨主便”：第三方支持什么，分享出去才能做什么。

通常，內(nèi)容分享出去之后，會(huì)在第三方平臺(tái)中以一定的格式展示。這種格式不由產(chǎn)品經(jīng)理設(shè)計(jì)，而是第三方平臺(tái)規(guī)定的。（產(chǎn)品經(jīng)理需要確認(rèn)要展示的內(nèi)容）。

在第三方平臺(tái)中打開分享的內(nèi)容后，就會(huì)基于第三方平臺(tái)內(nèi)置環(huán)境進(jìn)行功能展示。通常都會(huì)引導(dǎo)用戶觸發(fā)打開App，或到應(yīng)用市場(chǎng)下載App。

（2）技術(shù)實(shí)現(xiàn)方面

第一步，接口對(duì)接，實(shí)現(xiàn)第三方系統(tǒng)的授權(quán)。

未授權(quán)的情況下做分享，會(huì)有類似下圖的提示：

第二步：實(shí)現(xiàn)功能需求。

以分享小視頻到微信為例，若要在微信H5中實(shí)現(xiàn)視頻播放、點(diǎn)贊等功能，則要基于H5寫相關(guān)的代碼。

當(dāng)然也可以使用SDK（SDK通常本身支持多個(gè)系統(tǒng)：電腦、安卓、ios、H5等）。

而前面提到的跳轉(zhuǎn)到APP或應(yīng)用市場(chǎng)的邏輯，就是校驗(yàn)到本手機(jī)沒有App則跳轉(zhuǎn)到應(yīng)用市場(chǎng)下載，校驗(yàn)到已經(jīng)安裝則打開App。

但是在實(shí)現(xiàn)的時(shí)候，要了解第三方分享接口是否支持喚醒App。若不能支持，那么就要借助其他方式間接實(shí)現(xiàn)需求。

（3）產(chǎn)品經(jīng)理要確認(rèn)的

①確定分享的場(chǎng)景或業(yè)務(wù)位點(diǎn)：

比如，操縱完成或得到結(jié)果時(shí)提示分享（如截圖后、完成拍照和攝像時(shí)）、打開App時(shí)出彈層提示分享、勝利完成任務(wù)時(shí)提示分享（比如王者榮耀連勝的提示“炫耀一下”）。

②確定分享的形式

主要有：文字或鏈接地址的分享（比如天貓和淘寶的“淘口令”）、圖片分享（靜態(tài)圖片、GIF動(dòng)圖）、音視頻類行形（標(biāo)記它是音頻或是視頻，并且可以直接在當(dāng)前頁播放）；網(wǎng)頁分享（帶有網(wǎng)頁縮略圖的）。

其中網(wǎng)頁分享是最常見的。

以分享到微信為例，分享過去的網(wǎng)頁有自己的格式。比如：同一個(gè)內(nèi)容，從APP或外部瀏覽器分享到微信，會(huì)顯示APP的名稱和縮略內(nèi)容，從微信內(nèi)置瀏覽器分享的就不會(huì)展示這些信息。

另外注意：分享網(wǎng)頁和分享鏈接是不同的分享形式。前者帶有網(wǎng)頁自身的縮略內(nèi)容，后者屬于文本范疇的分享，簡(jiǎn)單原始。

③用戶打開的效果是什么

如果將分享理解為“借尸還魂”引流的話，那么打開分享鏈接之后，可以以最基礎(chǔ)的靜態(tài)畫面呈現(xiàn)，再次點(diǎn)擊頁面，則引導(dǎo)跳轉(zhuǎn)到App，或引導(dǎo)到應(yīng)用市場(chǎng)下載App。

但是，產(chǎn)品經(jīng)理需要知道，某些第三方的應(yīng)用不給提供便利，不支持跳轉(zhuǎn)到App。比如微信。

因此設(shè)計(jì)時(shí)候考慮增加提示“使用本地瀏覽器打開”（假設(shè)瀏覽器是支持的）。這樣就借助一個(gè)新的橋梁“假途滅虢”實(shí)現(xiàn)需求了。如下圖這樣：

④最后，讓分享自然甚至驚喜

比如：讓用戶獲得優(yōu)惠，得到好處（如「哈羅單車」通過分享獲得紅包）；

輔助業(yè)務(wù)實(shí)時(shí)共享（如「滴滴」可以分享行程給他人共享實(shí)時(shí)位置）；邀請(qǐng)好友，分享快樂（如「王者榮耀」邀請(qǐng)朋友一起組團(tuán)開黑）；

分享成就（如游戲獲得了九連勝等）。

17. 【消息】模塊設(shè)計(jì)的關(guān)注點(diǎn)

（1）必要時(shí)提供消息歸類

讓目標(biāo)信息曝光增加，同時(shí)讓消息有條理。

就好像微信的【訂閱號(hào)消息】一樣，進(jìn)行歸類，給予總?cè)肟凇?/p>

（2）未讀消息提示數(shù)字或紅點(diǎn)

為了不給用戶負(fù)擔(dān)，不是很要緊的消息盡量使用紅點(diǎn)。

消息數(shù)的消除以打開為準(zhǔn)，即打開就視為已讀。

（3）歷史消息保存留時(shí)長(zhǎng)

永久保存在服務(wù)器，用戶可以通過加載，分批查看歷史消息。

（4）聊天消息記錄的操作

①已發(fā)出的文字和表情（包括發(fā)送失?。?/p>

長(zhǎng)按可以轉(zhuǎn)發(fā)、刪除、復(fù)制。

②已發(fā)出的音頻、圖片和視頻（包括發(fā)送失敗）：

長(zhǎng)按，可以轉(zhuǎn)發(fā)、刪除，但不能復(fù)制（系統(tǒng)不支持）；

點(diǎn)擊，打開預(yù)覽大圖，長(zhǎng)按大圖，彈出保存按鈕。

③發(fā)送失敗的內(nèi)容：

增加重復(fù)發(fā)送按鈕，或者點(diǎn)擊發(fā)送失敗的按鈕實(shí)現(xiàn)重發(fā)。

④長(zhǎng)按消息記錄，彈出的操作框開口方向：

就近原則，若消息在屏幕上方，則操作內(nèi)容在下方；

反之，長(zhǎng)按后的操作框展示在內(nèi)容上方。

（5）消息通知方式

根據(jù)緊要程度，選擇橫幅通知、鎖屏通知、菜單通知。

建議只對(duì)主要的信息用音效，盡量不要騷擾到用戶。

（PS 但是根據(jù)經(jīng)驗(yàn)，一般老板都會(huì)要求“騷擾”用戶。）

18. 「聊天」發(fā)表情，是怎樣的機(jī)制

在微信發(fā)一個(gè)表情出來，你發(fā)現(xiàn)顯示的是名稱[調(diào)皮]，而不是一個(gè)圖標(biāo)

。

收到表情的一方，退出到聊天信息總列表，顯示的也是[調(diào)皮]。

那么為什么不是直接放一個(gè)表情在上面呢？實(shí)際這與實(shí)現(xiàn)原理有關(guān)系。

當(dāng)發(fā)表情給對(duì)方的時(shí)候，實(shí)際上發(fā)的是這個(gè)表情對(duì)應(yīng)的ID——>服務(wù)器拿到這個(gè)ID之后，再傳給接收方的客戶端——>接收方收到，再解碼出一個(gè)表情，展示在客戶端。

用圖示如下：

因此，表情的發(fā)送，是發(fā)送給服務(wù)一個(gè)對(duì)應(yīng)ID，而不是發(fā)送表情文件給對(duì)方的。

所以表情文件（圖文件）需要存在客戶端，而不需存在服務(wù)器。此外客戶端還要存表情名稱和ID。

事實(shí)上客戶端需要以josn格式存儲(chǔ)表情圖-名稱-表情ID，如下圖這樣：

注意，App正式運(yùn)營階段，需要自己制作表情，避免盜用侵權(quán)。

19. 「輸入框」的約束這件小事

從約束的程度看，輸入框可以分兩類，一類相對(duì)開放，比如作品評(píng)論框、好友留言框；另一類相對(duì)約束，比如昵稱、個(gè)性簽名、標(biāo)簽。

這兩類之所以約束程度不同，主要是跟用戶心理訴求以及頁面的展示形式?jīng)Q定的。

比如個(gè)性簽名一般會(huì)展示在個(gè)人資料頁，不管是自己看，還是他人看，都要求美觀，比如居中對(duì)齊。

同時(shí)頁面空間有限，所以字?jǐn)?shù)需加以限制。

那么對(duì)于這類輸入框，要做的是：限制字?jǐn)?shù)、對(duì)齊方式、內(nèi)容校驗(yàn)、文案提示等。

舉一個(gè)個(gè)性簽名輸入框約束方案的例子：

（1）限制字?jǐn)?shù)：字?jǐn)?shù)上限盡量高，不讓用戶心理上感到被束縛（好比商城大廳都很高，盡管“摸著天杜千”這樣的用戶很少），比如40-50字。

字?jǐn)?shù)上限可以在右下方顯示，隨著輸入而扣減字?jǐn)?shù)。

（2）字?jǐn)?shù)校驗(yàn)：推薦在輸入的時(shí)候，截取到限定字?jǐn)?shù)，多余的不予錄入。無需語言提示，用戶都看得懂。

（3）文案提示：根據(jù)（1），由于已經(jīng)有顯示位數(shù)了，所以可以換個(gè)提示，比如“據(jù)說簽名會(huì)提升關(guān)注幾率哦”。

如果簽名為空，為了提高體驗(yàn)，則建議對(duì)他人展示一個(gè)固定值，比如“歡迎關(guān)注我”。

（4）對(duì)齊方式：展示的時(shí)候，建議居中，最多顯示兩行，多出的省略。

在編輯環(huán)境自己看的時(shí)候，如果是下圖這種樣式，可以規(guī)定：滿行則靠左側(cè)對(duì)齊，不滿行靠右對(duì)齊。

20.你的App用到過「音效」嗎

以App「SOUL」的匹配按鈕為例，匹配中有音效，匹配成功，也會(huì)有個(gè)音效。

那么音效的實(shí)現(xiàn)是怎么的機(jī)制呢？是不是在后臺(tái)配置音頻文件，通過點(diǎn)擊按鈕調(diào)用呢？

實(shí)際上一般不需要在后臺(tái)存儲(chǔ)音頻文件。

一來是因?yàn)橐粜ё儎?dòng)不大，比如QQ的加好友的咳嗽聲用了那么多年。所以在客戶端寫死并不影響實(shí)際需要。

二來牽扯到觸發(fā)后，對(duì)交互的時(shí)效性要求較高。對(duì)比前面提到的表情，音頻文件會(huì)大很多。

以「SOUL」為例，本來已經(jīng)匹配到用戶了，如果因?yàn)榫W(wǎng)速等導(dǎo)致了延遲，遲遲沒有發(fā)出匹配成功的聲音，那就尷尬了。

21.分頁加載，還是一次加載全部

考慮是否需要分頁的時(shí)候，基本有三個(gè)特征：

• 第一，數(shù)據(jù)需要從服務(wù)器拉??；
• 第二，拉取的數(shù)據(jù)容量不太??；
• 第三，拉取內(nèi)容的條數(shù)不太小。

客戶端是一次加載完，還是分頁加，分別需要服務(wù)器提供分頁或全部數(shù)據(jù)的吞吐機(jī)制。

那么采取兩種措施的優(yōu)劣如何呢？

從用戶角度，并不能一棍子打死說全部加載就省事。

因?yàn)槿考虞d浪費(fèi)用戶流量和加載時(shí)間。很可能后面的內(nèi)容是用戶不需要的。這時(shí)候加載那么多反而適得其反。

但是分頁加載的缺點(diǎn)就是增加用戶操作的次數(shù)。用戶看完一頁需要再次加載才能看更多內(nèi)容，影響用戶沉浸性體驗(yàn)。

目前整體來說，采用分頁加載的較多。根據(jù)用戶的適應(yīng)性，每一頁給予的內(nèi)容數(shù)量加以調(diào)整。比如抖音的分頁瀑布流。

作為產(chǎn)品經(jīng)理，在確認(rèn)列表頁（比如好友通訊錄）、信息流（比如好友動(dòng)態(tài)）的時(shí)候，首先要在PRD中明確是否分頁加載。

若分頁，則確定每頁加載的大致條數(shù)。最重要的是需考慮清楚，支持分頁或不分頁的原因。

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

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

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

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

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

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

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

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

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

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

①聊天記錄（使用IM及時(shí)聊天SDK的情況下，往往本身就是保存了的）；

②個(gè)人資料（用戶自己在本地維護(hù)的，所以無需拉取服務(wù)器）；

③自己創(chuàng)作的作品（原理同個(gè)人資料）；

④草稿或編輯一半的內(nèi)容（比如制作視頻的規(guī)程中意外中斷了操作，下次進(jìn)入可以繼續(xù)）；

⑤支付明細(xì)，或其他操作記錄。

⑥其他。

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

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

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

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

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

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

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

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

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

比如UCG的視頻，App每次刷新可以加載10個(gè)，且不重復(fù)加載，那么就可以將每次加載的視頻ID存儲(chǔ)在手機(jī)中，下次加載做差異化扣減。

但是顯然這個(gè)量日積月累也夠大的。所以可以設(shè)置為（比如）每周自動(dòng)清除一次。

手動(dòng)清除，比如微信的清除緩存。

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

23. 「版本更新」的三種場(chǎng)景

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

（1）彈框更新提醒

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

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

一種常見的機(jī)制是，設(shè)置兩個(gè)版本號(hào)，一個(gè)開發(fā)版本號(hào)，另一個(gè)是顯示給用戶的用戶版本號(hào)。

每個(gè)App版本都有唯一的開發(fā)版本號(hào)，就像序列號(hào)一樣唯一且嚴(yán)格。而顯示版本號(hào)是給用戶看的，所以可以擬定。在用戶打開應(yīng)用時(shí)校驗(yàn)版本差別。

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

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

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

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

①每次打開App，都校驗(yàn)是否有新版本；若有，則校驗(yàn)是否屬于強(qiáng)制更新。強(qiáng)制更新 則只能更新，或者退出應(yīng)用；非強(qiáng)制更新可以不更，繼續(xù)使用；

②安卓往往從公司服務(wù)器下載（避免商城的不確定性），當(dāng)然也可以像IOS一樣跳往應(yīng)用商店。

安卓受管制少，所以一般直接顯示下載進(jìn)度條，下載不能打斷或暫停；下載完畢 toast提示，同時(shí)直接安裝；安裝完畢 toast提示，同時(shí)直接打開APP。

④提醒更新和商店更新的文案不同。提醒更新的更簡(jiǎn)潔，文案在后臺(tái)配置。

比如，要求最多顯示6行（一行顯示不完的自動(dòng)換行，超行與換行符的換行無差別對(duì)待），超出6行的顯示…

（3）推送消息通知更新

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

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

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

熱更新就是，通過一些技術(shù)手段，直接對(duì)線上App添加新功能或者修改bug，以避開上架審核造成的麻煩或不通過。

該過程所用的技術(shù)手段就統(tǒng)稱為熱更新。

熱更新時(shí)候，可以通知用戶手動(dòng)觸發(fā)，比如王者榮耀。也可以不告訴用戶，直接更新。

無論代碼是原生還是H5，理論上都可以進(jìn)行熱更新。

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

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

（1）正式包與測(cè)試包

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

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

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

正式包與測(cè)試包通常是同一份代碼，分別發(fā)布在不同的環(huán)境中。但需要注意， 兩個(gè)版本可能不對(duì)稱。

比如1.1版本的代碼只在正式服務(wù)器發(fā)布了，那么切換到測(cè)試服務(wù)器的時(shí)候代碼是不一樣的，功能就不一樣了。

（2）安裝版本

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

新舊安裝包安裝時(shí)候，壓縮包簽名相同的會(huì)自動(dòng)覆蓋，這樣更新之后賬號(hào)依然在，類似熱更新。但最好是先卸載舊的，避免可能的沖突。

26. APK壓縮

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

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

（1）減少代碼的大小

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

（2）減少資源的大小

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

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

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

27. SDK調(diào)研和選型

接入SDK是明智的選擇。

功能插件的底層代碼，沒有誰再愿意從石器時(shí)代重新造一遍輪子。比如人臉識(shí)別、美顏等。

但前提是SDK的加入，在時(shí)間、質(zhì)量上靠得住。

（1）參與SDK的初步調(diào)研和篩選

先閱讀準(zhǔn)供應(yīng)商的SDK方案文檔，判斷是否滿足產(chǎn)品當(dāng)前的大致需求，以及未來的擴(kuò)展。

下圖就是某SDK提供商的方案文檔局部截圖：

以拍攝視頻的功能為例，其功能清單如下圖：

通過分析功能，列舉出缺失功能，和自研該功能的成本。

從而得出對(duì)該家SDK的基本評(píng)分。

（2）多家的橫向?qū)Ρ龋瑩駜?yōu)而取

假設(shè)我們鎖定了四家SDK，他們的基本版功能都是滿足的。但是實(shí)現(xiàn)方案和細(xì)節(jié)就有差異。

比如，某SDK沒有編輯時(shí)間軸的功能。也就是只能一個(gè)貼紙應(yīng)用整個(gè)視頻，無法實(shí)現(xiàn)在視頻不同時(shí)間段使用不同貼紙的需求。

而我們是需要這個(gè)時(shí)間軸編輯功能的。因此就將這個(gè)SDK的該項(xiàng)缺陷登記出來，并評(píng)估出自己開發(fā)所需的成本。

使用該方法，輸出一份初步調(diào)研文檔，以便后續(xù)跟蹤調(diào)查，如下圖所示：

（3）輸出基于SDK的需求、UI方案

SDK往往還需要二次開發(fā)，或者自主研發(fā)一些功能加以彌補(bǔ)。

就算代碼不需要寫，UI還是要自己做的。

因此需為開發(fā)人員輸出一份基于SDK的需求文檔。

SDK結(jié)合本地代碼之后，可能出現(xiàn)未曾預(yù)見的新問題。

比如，拍攝視頻到發(fā)布視頻的過程中，會(huì)出現(xiàn)多次合成或加載，影響用戶體驗(yàn)。

這個(gè)時(shí)候產(chǎn)品經(jīng)理就需要基于當(dāng)前的環(huán)境，羅列出不同的操作場(chǎng)景下的加載位點(diǎn)，并用文案區(qū)分出不同位點(diǎn)的提示文案。

選擇適當(dāng)?shù)腟DK固然能省事，但是一款產(chǎn)品的品質(zhì)，還在于協(xié)調(diào)和氣質(zhì)定位等。