02 facebook接入登錄(小米手機APN接入點不見了,里面一片空白，咋回事)

交互細節上又可以延伸用戶進行注冊或登錄需要幾個步驟？這些步驟是在一個頁面上承載還是一步一個頁面以多頁面去承載？單一頁面承載的優勢是用戶能夠有很清楚的預期，他完成注冊需要進行哪些操作，但是劣勢是一個頁面承載過多信息顯得雜亂，操作的次序也會不明確；多頁面承載的劣勢是用戶對完成注冊的具體行為沒有完整預期，更容易跳出，優勢是頁面整潔并且路徑單一，能引導用戶完全按照通暢的預設路徑進行。我個人更推薦后者，因為用戶預期可以用頁碼／步驟管理用戶預期。

下面是我根據我們產品的定位和需求設計的用戶登錄／注冊系統原型：如上所說，我設計的用戶系統是需要承載多產品的，所以我設計融合賬號密碼登錄和手機號快捷登錄兩種方式，以用戶出發需要登錄的場景去切換展現在用戶面前的是哪一種。

補充一些貼心的小點：

1.申請讀取本機號碼權限，并幫用戶填寫

2.申請讀寫短信權限，獲取到驗證碼后自動填寫并點擊下一步

3.應該前置到提醒：上次登錄方式，合法的手機號，正確的圖形驗證碼等等

三、服務端設計

很多產品，特別是沒有技術背景的產品不會去接觸和設計服務端需求，實際上我自己日常工作中接觸服務端需求也并不多，并不是說產品要負責設計一個完善的用戶系統服務端，而是要學會以服務端同事能懂的方式表達清楚自己的訴求，兩邊對功能的實現不會有太多的偏差，這是產品設計服務端目的所在。

簡單的用戶系統服務端的基本功能需求為：判斷賬號身份（注冊/未注冊），賬號身份生成（新用戶分配id），賬號密碼驗證；這里要設計的并不滿足于注冊登錄，需要考慮多平臺賬號打通的用戶系統并且要和在打通情況下單一平臺或多個平臺之間，用戶的多個賬號之間綁定于解綁。現在先說一下多平臺賬號打通需要考慮哪些問題：

1.用戶系統身份的創建，因為我們是多平臺的系統，所以用戶身份只能納入手機號注冊的用戶，若第三方授權注冊的也算用戶系統用戶，在賬號綁定的那一關則會出現混亂；

2.實現多平臺賬號打通，要實現多平臺賬號打通，即所有接入多平臺都能夠查詢到此用戶身份；

3.平臺間用戶身份獨立，要實現平臺間用戶身份獨立，則需要在用戶系統用戶身份的基礎上創建一個平臺的用戶身份；

(一) 用戶系統多平臺打通

名詞解釋

1)Appid：接入用戶系統時首先分配，用于區別接入的各個app；

2)Unionid：用戶手機注冊時，由用戶系統根據手機號創建，在用戶系統作為用戶唯一身份標識；

3)Appuserid：用戶注冊時，由app服務端根據union或者第三方授權的openid創建，在app內作為用戶唯一的身份標識；

基本原則

1)手機號作為用戶系統賬號的注冊的唯一途徑，根據手機號在用戶系統服務端創建并保存unionid；app服務端根據unionid創建并保存appuserid，且將unionid對應保存；

2)用戶系統同一unionid可對應不同的appuserid

3)使用第三方openid授權的注冊用戶不計入用戶系統僅存在app服務端作為單app用戶，即unioid為空只生成appuserid；第三方授權包括微博買粉絲，QQ，Facebook，Twitter

1. 主線流程圖

手機號注冊主流程為：

用戶注冊時，用戶系統服務端需要驗證手機號＋驗證碼是否為真，此手機號是否已有對應unionid；若有提示已注冊，請登錄；若無創建對應unionid，app服務端根據unionid創建appuserid。至此成功生成了用戶系統身份及當前app用戶身份。

手機號登陸主流程為：

用戶登錄時，用戶系統服務的驗證手機號＋密碼是否為真，此手機號是否有對應unionid，若有，則說明此用戶有用戶系統身份。

還需要app服務端需要查詢是否有對應的appuserid，若有說明此用戶有此app身份，直接用其appuserid登錄；若無則說明是用戶系統內其他聯合app注冊用戶根據unionid創建此app的用戶身份，至此登錄成功。

用戶系統是大多數app都會有多構成，單一的用戶系統也并不那么復雜，但是若要構建產品矩陣進行多平臺間的用戶打通，加上帳號綁定與解綁，并不是一時半會能夠想清楚的需求，若大家感興趣為會繼續補充帳號綁定和賬號安全產品應該關心和設計的事情。謝謝：）

很赞哦!（3）