手機端被迫下線實現方案
方案一(現用,
具體看嘀嗒應用原始碼):
後台:定義乙個字段
(useid),
登陸時把這個字段返回給使用者,
前台:在
bacractivity
裡定義乙個執行緒
,每個十秒請求一次
,請求到返回的數值跟本地比較
,不一樣是直接跳到登陸介面
,從而實現異地登入被迫下線功能.
注意事項:
第一次不匹配
,被迫下線後前台已存的頁面要清空
,應用到
activity
管理優點:
實現簡單
,後台修改簡單
,前台只需乙個執行緒就
ok缺點:
每十秒請求一次資料
,當使用者群小時還行
,當使用者群多時
,伺服器壓力大
.同時每十秒重新整理也給使用者帶來了不必要的流量浪費
.應用場景:
應用要求不太嚴格
,使用者量少的客戶端.
方案二:
利用廣播接收器,當
a使用者登陸乙個
id1後
,b使用者再登陸
id1後
,利用推送訊息機制
,伺服器給
a發乙個訊息
,a接收到廣播後
,執行下線操作.
具體實現過程:(
利用到推送服務)
後台:
當乙個id
已經登入
,再次登入時
,通過伺服器向第乙個登入的使用者傳送訊息,
前台:整合第三方推送(.
信鴿,極光),
通過自定義廣播接收器
,首先把本個應用推送預設為不可設定且為預設接收
,當接受廣播訊息進行驗證欄位或標籤來執行是否下線
,如果是直接提示使用者」該賬號應經在其他地方登陸,
請重新登陸
!」注意事項:清楚推送服務的型別,避免造成不必要的麻煩.前台應用自定義廣播接收器,且設定為不可遮蔽.被迫下線及時清空activity.
缺點:因為不同的第三方推送有不同的伺服器型別,一種是使用者關閉推送訊息,是關閉伺服器,不在推送訊息,一種是關閉後只是不在提示,但依據能接收,所以用第三方推送時要了解清楚.一旦遮蔽訊息無法接收後,就不能實現被迫下線功能.
優點:對伺服器壓力小,對使用者來說,減少請求次數,減少不必要的流量和電量浪費.
應用場景:使用人數多,需要推送機**務的客戶端
手機端頁面自適應解決方案 rem布局
只需在頁面引入這段原生js 就可以了 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 function doc,win else if doc.addeventlistener return win.addeventlistener resizeevt,recal...
手機端頁面自適應解決方案 rem布局
相信很多剛開始寫移動端頁面的同學都要面對頁面自適應的問題，當然解決方案很多，比如 百分比布局，彈性布局flex 什麼是flex 也都能獲得不錯的效果，這裡主要介紹的是本人在實踐中用的最順手最簡單的布局方案 rem 什麼是rem 布局 rem布局非常簡單，首頁你只需在頁面引入這段原生js 就可以了 f...
PC端手機端自適應方案總結
pc端手機端自適應方案 一 做成兩個站，兩個網域名稱 方法 後端判斷裝置切換，跳轉鏈結 前端js判斷裝置切換，跳轉鏈結 缺點 1.兩個網域名稱，不利於seo優化 2.兩個站，量大，布局專案繁雜 優點 1.邏輯清晰，簡潔 適用場景 pc端和手機端設計圖差別較大時 二 做成乙個站，乙個網域名稱 方法 用...