欧美成人精品手机在线观看_69视频国产_动漫精品第一页_日韩中文字幕网 - 日本欧美一区二区

LOGO OA教程 ERP教程 模切知識(shí)交流 PMS教程 CRM教程 開(kāi)發(fā)文檔 其他文檔  
 
網(wǎng)站管理員

[點(diǎn)晴永久免費(fèi)OA]手機(jī)APP新信息推送技術(shù)介紹

admin
2023年3月20日 9:7 本文熱度 735
:手機(jī)APP新信息推送技術(shù)介紹

推送

推送簡(jiǎn)直就是一種輕量級(jí)的騷擾方式

自從有了推送,各個(gè)公司基本上都在使用推送,這確實(shí)是一個(gè)比較好的提醒方式,Android較iOS強(qiáng)的一個(gè)部分,也就是在于Android的Notification。Google教育我們利用好Android的通知模塊,做更多友好的交互,可這句話,翻譯成中文,不知不覺(jué),就變成了在Notification中推送各種廣告,而且僅僅就是一些廣告,Notification各種牛逼的功能,完全不需要,這也違背了Google設(shè)計(jì)Notification的初衷。

更關(guān)鍵的是,現(xiàn)在隨便找一款A(yù)pp,沒(méi)有推送的真是鳳毛麟角,更可惡的是,做外賣(mài)的App給我推送奧運(yùn)新聞,一條新聞十幾個(gè)App推送,以至于現(xiàn)在很多用戶都非常反感各種推送廣告,就我本人而言,基本上會(huì)禁用所有廣告類(lèi)的App的推送。

本人非常反感推送,借用王思聰?shù)囊痪湓挘琗XX App天天給我推送各種廣告,還TM是自己做的推送,真是絕了。

推送方案

輪詢

輪詢是最簡(jiǎn)單的與服務(wù)器保持通信的方式,即循環(huán)向服務(wù)器通信。這個(gè)方案的特點(diǎn)就是通信由客戶端主動(dòng)發(fā)起,你需要自己實(shí)現(xiàn)輪詢消息隊(duì)列、頻率等等參數(shù),在功耗和效果間做權(quán)衡,類(lèi)似于TCP的短連接。

SMS

這個(gè)其實(shí)就是借助短信來(lái)實(shí)現(xiàn)信息的展示,只不過(guò)把短信內(nèi)容展示到了Notification中,這個(gè)方案,到達(dá)率確實(shí)高,畢竟短信是比較可靠、穩(wěn)定的,但劣勢(shì)也很明顯,就是成本很高,而且在Android平臺(tái)上,短信的權(quán)限比較開(kāi)放,容易被劫持。

長(zhǎng)連接

長(zhǎng)連接和前面提到的短連接,都是基于Socket連接的方式,他們的區(qū)別在與,短連接是每次數(shù)據(jù)傳輸完畢后就斷開(kāi)連接,而長(zhǎng)連接不會(huì)。所以,基于輪詢的方式,每次都要進(jìn)行鏈路的連接,性能消耗更大,基于長(zhǎng)連接的方式,就是對(duì)這點(diǎn)的改進(jìn)。應(yīng)用一旦與服務(wù)器連接成功,并不會(huì)主動(dòng)斷開(kāi)連接,后面的通信都基于這個(gè)通道。目前大部分的推送服務(wù)都是基于長(zhǎng)連接的推送,在后臺(tái)維護(hù)一個(gè)Service,維持應(yīng)用與服務(wù)端之間的TCP長(zhǎng)連接。

推送方案

iOS

iOS這邊使用系統(tǒng)統(tǒng)一的APNs,所有推送消息都由蘋(píng)果的服務(wù)器進(jìn)行下發(fā),同時(shí),也由系統(tǒng)進(jìn)行統(tǒng)一展示和處理。

GCM

與iOS一樣,Android同樣有一套內(nèi)置的推送方案,但很可惜的是,Google的服務(wù)在中國(guó)大陸無(wú)法使用,草了個(gè)蛋。

第三方推送服務(wù)

專(zhuān)業(yè)的第三方推送

  • 極光

  • 個(gè)推

  • 友盟推送

手機(jī)ROM廠商推送

  • 華為推送

  • 小米推送

BAT級(jí)別的全家桶

  • 阿里推送

  • 信鴿推送

  • 百度推送

關(guān)于第三方推送服務(wù)在各個(gè)App中的使用率,大家可以參考賈吉鑫的那篇文章,微信沒(méi)辦法貼鏈接。。。麻煩大家自己搜一下。

第三方推送注意

這些推送服務(wù)大同小異,基本上一家使用了一個(gè)新功能,另外幾家,也會(huì)很快推出這個(gè)功能,就例如之前比較火的,『共享推送通道進(jìn)行App喚醒』這個(gè)技術(shù),友盟、個(gè)推推出后,很快其它推送服務(wù)商就支持了,所以開(kāi)發(fā)者并不需要擔(dān)心哪一家推送功能比較強(qiáng)。

這里還需要說(shuō)下現(xiàn)在的『推送喚醒』這樣一個(gè)功能,簡(jiǎn)單的說(shuō),就是所有安裝了A推送的App,只要有一個(gè)還活著,就可以把其它安裝了A推送的App拉起來(lái),從而提高推送的到達(dá)率。有些阿里系、百度系的App,被大家稱作『全家桶』,實(shí)際上就是因?yàn)檫@個(gè)原因,這個(gè)方式,確實(shí)能在一定程度上提高推送到達(dá)率,但另一方面,也破壞了Android生態(tài),增加了功耗,打亂了系統(tǒng)的清理策略。

另外,小米推送、華為推送,大家接入的原因可能很簡(jiǎn)單,就是他們的手機(jī)市場(chǎng)占有率比較高,接入他們自家的推送,可以在一定程度上提高到達(dá)率,但需要注意的是,推送分為透?jìng)骱头峭競(jìng)鲀煞N方式,透?jìng)骷次覀冏约篈pp處理推送消息,而非透?jìng)鳎瑒t是交給相應(yīng)的PushSDK處理,對(duì)于小米推送、華為推送來(lái)說(shuō),只有采用非透?jìng)飨ⅲ竭_(dá)率采用保證,而透?jìng)飨ⅲc其它推送并沒(méi)有什么區(qū)別,換句話說(shuō),小米手機(jī)、華為手機(jī),只對(duì)非透?jìng)鞯耐扑拖⒆隽丝煽啃员WC,但非透?jìng)飨⒌恼故靖袷椒浅9潭ā⒑?jiǎn)單,且不能自定義,這是一個(gè)很大的問(wèn)題,這點(diǎn)應(yīng)該是很多開(kāi)發(fā)者的誤區(qū)。

最后,很多推送服務(wù)都需要在Application中進(jìn)行初始化,同時(shí),各種被喚醒策略,又會(huì)拉起Application,導(dǎo)致推送進(jìn)程的重復(fù),所以,這里經(jīng)常需要對(duì)進(jìn)程名進(jìn)行過(guò)濾,非主進(jìn)程,不進(jìn)行初始化。

自建推送服務(wù)

基本都是基于AndroidPN、MQTT、XMPP、長(zhǎng)連接這些方式去實(shí)現(xiàn)的,自己搭建Push平臺(tái)服務(wù),一個(gè)最大的問(wèn)題就是服務(wù)端的架構(gòu)設(shè)計(jì),不僅成本高,而且效果不一定好,建議中小企業(yè)不要輕易嘗試。

推送名詞解釋

RegistrationID\ClientID

一般來(lái)說(shuō),類(lèi)似這類(lèi)ID都是用于唯一標(biāo)識(shí)應(yīng)用\用戶的,每個(gè)App在每臺(tái)手機(jī)上都會(huì)生成一個(gè)唯一ID。

RegistrationID\ClientID生成規(guī)則

Android平臺(tái)上因?yàn)閲?guó)內(nèi)存在大量山寨設(shè)備,所以很多設(shè)備的IMEI、Mac地址、AndroidID 都有可能為空或者錯(cuò)誤,所以不能單獨(dú)作為唯一標(biāo)識(shí),需要將這些進(jìn)行組合起來(lái)使用。

對(duì)于應(yīng)用卸載后RegistrationID的問(wèn)題,很多PushSDK的策略是,生成一個(gè)DeviceID保存到本地存儲(chǔ),應(yīng)用被卸載后如果被重新安裝,如果檢測(cè)到存儲(chǔ)里的DeviceID還在的話,就判定是同一個(gè)設(shè)備,不重新生成RegistrationID。

AppKey\AppID

這些Key基本都是用于驗(yàn)證App的,每個(gè)包名對(duì)應(yīng)一個(gè)加密的Key。

透?jìng)鱘非透?jìng)?/strong>

非透?jìng)飨⑹侵竿扑拖⒈籔ushSDK獲取并處理,透?jìng)飨⑹侵竿扑拖⒈籔ushSDK交給宿主應(yīng)用處理,非透?jìng)飨⑼ǔV荒茉O(shè)置一些固定的樣式,比較簡(jiǎn)單,而透?jìng)飨ⅲ梢杂葾pp自定義處理,比較靈活。

推送數(shù)據(jù)基礎(chǔ)

累計(jì)注冊(cè)

通過(guò)應(yīng)用使用的appid統(tǒng)計(jì)用戶注冊(cè)總量。

日在線用戶

通過(guò)應(yīng)用使用的appid統(tǒng)計(jì)當(dāng)天的在線用戶數(shù)。

活躍用戶

通過(guò)應(yīng)用使用的appid統(tǒng)計(jì)當(dāng)天在推送平臺(tái)激活過(guò)的用戶總數(shù)。

在線下發(fā)率

在線消息下發(fā)數(shù)/總下發(fā)數(shù)。

回執(zhí)率

消息回執(zhí)數(shù)(去重)/消息在線下發(fā)數(shù)。

到達(dá)率

到達(dá)數(shù)/實(shí)際下發(fā)數(shù)。

百日內(nèi)聯(lián)網(wǎng)用戶數(shù)(可推送用戶數(shù))

是指最近三個(gè)月內(nèi)有登錄過(guò)(設(shè)備與推送服務(wù)端建立長(zhǎng)鏈接)的設(shè)備總數(shù),即有效可下發(fā)的用戶數(shù)。一般的推送服務(wù)端認(rèn)為,設(shè)備在100天內(nèi)沒(méi)有登錄請(qǐng)求,認(rèn)為該設(shè)備已經(jīng)失效,所以無(wú)需再次發(fā)送。

實(shí)際下發(fā)數(shù)

實(shí)際可推送設(shè)備數(shù)(在消息有效期內(nèi),有聯(lián)網(wǎng)并推送進(jìn)程正常的設(shè)備,即消息有效期內(nèi)的在線下發(fā)數(shù)。消息有效期就是設(shè)置的離線時(shí)間)。

到達(dá)數(shù)

客戶端SDK接收到消息的設(shè)備數(shù)(通過(guò)統(tǒng)計(jì)客戶端SDK接收到消息后的回執(zhí)獲得)。

展示數(shù)

用自定義非透?jìng)飨⒃谟脩羰謾C(jī)展示過(guò)的設(shè)備數(shù)。

點(diǎn)擊數(shù)

點(diǎn)擊通知欄消息的設(shè)備數(shù)。

推送數(shù)據(jù)分析

那么關(guān)于推送,大家實(shí)際上最關(guān)系的,就是『到達(dá)率』。那么這個(gè)到達(dá)率究竟怎么計(jì)算呢?

首先我們舉個(gè)例子來(lái)說(shuō)明上面的這些數(shù)據(jù)背后的實(shí)際意義,例如,我們有一款A(yù)pp,有100w的下載量,每個(gè)App啟動(dòng)后,都將上報(bào)給服務(wù)器一個(gè)唯一ID,所以,累計(jì)注冊(cè)量就是100w,也稱發(fā)送總量。

那么在服務(wù)端準(zhǔn)備發(fā)送推送的時(shí)候,當(dāng)前手機(jī)端推送進(jìn)程還活著的,也就是說(shuō)推送的長(zhǎng)連接還健在的,就是在線設(shè)備,如果按天算,那么就叫日在線設(shè)備數(shù),我們假設(shè)這個(gè)數(shù)字是60w。

OK,推送發(fā)出去后,客戶端收到推送消息,并產(chǎn)生回執(zhí),代表完成了一次推送,假設(shè)這些完成推送的設(shè)備是55w,這個(gè)就是送達(dá)設(shè)備數(shù)。一般來(lái)說(shuō),只要設(shè)備在線,基本都能送達(dá),所以這個(gè)數(shù)字和在線設(shè)備數(shù)非常接近,不接近的話,這個(gè)推送基本就有問(wèn)題了,其中可能送不達(dá)的原因就在于網(wǎng)絡(luò)切換等導(dǎo)致長(zhǎng)連接斷掉這類(lèi)因素。

那么到這里,一般的推送服務(wù)商會(huì)使用送達(dá)設(shè)備數(shù)/在線設(shè)備數(shù)的方式來(lái)計(jì)算到達(dá)率,當(dāng)然,前面我們也說(shuō)了,這個(gè)比例一定是很高的,如果保持長(zhǎng)連接的設(shè)備都不能收到推送,那一定是有問(wèn)題了。

而一般的到達(dá)率,應(yīng)該是送達(dá)設(shè)備數(shù)/可送達(dá)設(shè)備數(shù),也就是百日內(nèi)活躍的設(shè)備數(shù),這樣一除,這個(gè)比例一下子就小了很多,因?yàn)檎l(shuí)也不知道,這一百天內(nèi)曾經(jīng)活躍的用戶,第二天是不是就已經(jīng)把你卸載了。所以說(shuō),Android下統(tǒng)計(jì)推送的到達(dá)率一般都很低,而推送服務(wù)商宣傳的到達(dá)率都很高,這其實(shí)就是一個(gè)偷換概念的問(wèn)題,我們說(shuō)的是一般的到達(dá)率,而服務(wù)商宣傳的是在線到達(dá)率。

而且,這個(gè)到達(dá)率與iOS完全沒(méi)有可比性,因?yàn)閕OS統(tǒng)一通過(guò)APNs來(lái)進(jìn)行推送,且無(wú)法獲取到達(dá)回執(zhí),所以,iOS基本不存在到達(dá)率這一說(shuō)法,如果有,幾乎也是100%,完全沒(méi)有意義,所以,如果哪一天有產(chǎn)品或者運(yùn)營(yíng)跟你說(shuō),為什么Android的到達(dá)率比iOS的到達(dá)率差這么多,請(qǐng)毫不客氣的砸它一斤蘋(píng)果。

Tag\Alias

Tag

Tag,或者叫標(biāo)簽,是用戶的一種屬性,在給某些用戶設(shè)置某類(lèi)標(biāo)簽后就可以針對(duì)推送。比如給喜歡『編程』的人打上『編程』的標(biāo)簽,就可以只給他們精準(zhǔn)推送。

通常情況下,一個(gè)設(shè)備(在一個(gè)App里)可以設(shè)置多個(gè)標(biāo)簽。標(biāo)簽與別名類(lèi)似,其對(duì)應(yīng)關(guān)系也是保存在推送服務(wù)器側(cè)的。

Alias

Alias,或者叫別名,是對(duì)已經(jīng)安裝某應(yīng)用的用戶取個(gè)別名進(jìn)行標(biāo)識(shí),在對(duì)該用戶消息推送時(shí),就可以用此別名來(lái)進(jìn)行推送。設(shè)置了別名后,推送時(shí)服務(wù)器端指定別名即可。推送服務(wù)器端來(lái)把別名轉(zhuǎn)化到設(shè)備ID來(lái)找到設(shè)備。

Tag和Alias他們的共同點(diǎn)在于,提供對(duì)用戶的精確推送。

推送原理

目前大部分的第三方推送服務(wù),都是基于長(zhǎng)連接的推送方案,下面將對(duì)這個(gè)方式進(jìn)行詳細(xì)講解。

NAT

首先,我們需要了解下一個(gè)網(wǎng)絡(luò)基本知識(shí)——NAT,即網(wǎng)絡(luò)地址轉(zhuǎn)換(Network Address Translation,NAT),這是因?yàn)镮P地址是有限的,手機(jī)無(wú)論是通過(guò)路由器還是數(shù)據(jù)網(wǎng)絡(luò),都有一個(gè)內(nèi)網(wǎng)IP地址,同時(shí),路由器上會(huì)維護(hù)一個(gè)外網(wǎng)IP地址,從而形成一個(gè)NAT路由表,即內(nèi)網(wǎng)IP地址:端口,以及對(duì)應(yīng)的外網(wǎng)IP地址:端口。這樣通過(guò)一層層封裝與解封裝,就達(dá)到了內(nèi)網(wǎng)與外網(wǎng)交換通信的方式。

NAT超時(shí)

由于NAT路由表的大小有效,所以一般路由都有NAT有效期,WIFI下,這個(gè)NAT有效期可能會(huì)比較長(zhǎng),而在數(shù)據(jù)流量下,運(yùn)營(yíng)商一般都會(huì)盡快更新NAT路由表,淘汰無(wú)效的設(shè)備,所以,在使用數(shù)據(jù)流量時(shí),長(zhǎng)連接經(jīng)常容易斷。

那么除了NAT路由表主動(dòng)淘汰過(guò)期的設(shè)備之外,切換網(wǎng)絡(luò)環(huán)境和DHCP服務(wù)器租期到期,這些情況都有可能導(dǎo)致NAT路由表改變,從而造成長(zhǎng)連接中斷。

心跳包

前面我們說(shuō)了,現(xiàn)在的推送服務(wù)一般采用的是長(zhǎng)連接的通信方式,而長(zhǎng)連接會(huì)因?yàn)镹AT路由表的更新而中斷,所以,客戶端會(huì)定時(shí)向服務(wù)端發(fā)送一個(gè)心跳包,來(lái)定期告知NAT路由表,我還活著,別殺我!這就是心跳包的作用——防止NAT路由表超時(shí),同時(shí)檢測(cè)連接是否被斷開(kāi)。

心跳包的心跳時(shí)間

既然心跳包的作用是防止NAT超時(shí),那么就需要將心跳包的發(fā)送頻率設(shè)置為小余NAT超時(shí)的檢測(cè)頻率,而WIFI和數(shù)據(jù)流量下,對(duì)于NAT路由表的超時(shí)時(shí)間又是不一樣的,而且不同的網(wǎng)絡(luò)運(yùn)營(yíng)商的超時(shí)時(shí)間,甚至都不一樣,所以,一個(gè)比較好的方法就是根據(jù)設(shè)備當(dāng)前網(wǎng)絡(luò)環(huán)境,來(lái)動(dòng)態(tài)的設(shè)置心跳時(shí)間。

注意,心跳包與輪詢是不一樣的,心跳包建立在長(zhǎng)連接上,只要發(fā)送數(shù)據(jù)即可,而輪詢每次都是一個(gè)完整的TCP連接。

心跳包誰(shuí)來(lái)發(fā)

既然需要定時(shí)任務(wù),那么就需要使用AlarmManager來(lái)作定時(shí)喚醒了,原因之前的文章有講過(guò),是關(guān)于處理器喚醒的原因,這里就不贅述了,大家可以參考我之前的文章:

Android中的睡與不睡

進(jìn)程保活

所謂進(jìn)程保活,是指App希望盡可能的保證自己的App的推送進(jìn)程能夠存活在后臺(tái),以保證可以收到服務(wù)端的推送消息,因此,才出現(xiàn)了一大批關(guān)于進(jìn)程保活的方式,例如NDK層的文件鎖,fork子進(jìn)程、前臺(tái)服務(wù)、進(jìn)程優(yōu)先級(jí)等等方式,然而,這些東西,實(shí)際上,都不能完全保證手機(jī)的進(jìn)程管理策略放過(guò)你,特別是Android 5.0以后的系統(tǒng),Android對(duì)進(jìn)程的管理更加嚴(yán)格,還有國(guó)內(nèi)的這些ROM層的修改,ROM想要?dú)⒛氵@個(gè)進(jìn)程,你怎么做也沒(méi)有辦法,哦,除了白名單。所以,不要再花心思去找什么進(jìn)程保活的黑科技了,好好做好應(yīng)用,提供用戶的使用黏性,才是最佳的保活,而對(duì)于一些產(chǎn)品、運(yùn)營(yíng)所謂的『為什么微信、QQ都可以保活』這樣的問(wèn)題,我建議你回答它:『如果你能把產(chǎn)品做到微信、QQ那樣的數(shù)量級(jí),我也能讓你活!』

推送整合方案

介于各種第三方推送與ROM推送的特點(diǎn),我們目前采用的推送方案,名為『UniversalPushSDK』,即整合了多個(gè)不同的推送渠道,通過(guò)模板設(shè)計(jì)模式來(lái)進(jìn)行整合,并向外暴露統(tǒng)一的接口,這種方式的好處在于UniversalPushSDK利用的各個(gè)不同推送特點(diǎn),提高推送到達(dá)率,但是壞處在于,包的體積會(huì)大一些。例如,我們現(xiàn)在整合了『小米推送、極光推送、華為推送』,在系統(tǒng)啟動(dòng)的時(shí)候,判斷當(dāng)前系統(tǒng),如果是小米系統(tǒng),則啟用『小米推送』,如果是華為手機(jī),則啟用『華為推送』,其它的Android設(shè)備,則啟用『極光推送』,通過(guò)這種方式來(lái)設(shè)計(jì)我們自己的推送SDK,可以在一定程度上,利用好各個(gè)推送平臺(tái)的特性。

那么如果利用這種方式來(lái)設(shè)計(jì)SDK給到不同的App接入,就需要能夠?qū)?yīng)用的推送Key做到動(dòng)態(tài)配置,這也是我們遇到的最大的一個(gè)問(wèn)題,解決方法大家可以參考之前寫(xiě)的一篇文章:

http://blog.csdn.net/eclipsexys/article/details/51283232

雖然我極力反對(duì)這種方案,我堅(jiān)持認(rèn)為,做好App,提升用戶使用黏性,才是提升推送到達(dá)率的關(guān)鍵


該文章在 2023/3/20 9:07:19 編輯過(guò)
關(guān)鍵字查詢
相關(guān)文章
正在查詢...
點(diǎn)晴ERP是一款針對(duì)中小制造業(yè)的專(zhuān)業(yè)生產(chǎn)管理軟件系統(tǒng),系統(tǒng)成熟度和易用性得到了國(guó)內(nèi)大量中小企業(yè)的青睞。
點(diǎn)晴PMS碼頭管理系統(tǒng)主要針對(duì)港口碼頭集裝箱與散貨日常運(yùn)作、調(diào)度、堆場(chǎng)、車(chē)隊(duì)、財(cái)務(wù)費(fèi)用、相關(guān)報(bào)表等業(yè)務(wù)管理,結(jié)合碼頭的業(yè)務(wù)特點(diǎn),圍繞調(diào)度、堆場(chǎng)作業(yè)而開(kāi)發(fā)的。集技術(shù)的先進(jìn)性、管理的有效性于一體,是物流碼頭及其他港口類(lèi)企業(yè)的高效ERP管理信息系統(tǒng)。
點(diǎn)晴WMS倉(cāng)儲(chǔ)管理系統(tǒng)提供了貨物產(chǎn)品管理,銷(xiāo)售管理,采購(gòu)管理,倉(cāng)儲(chǔ)管理,倉(cāng)庫(kù)管理,保質(zhì)期管理,貨位管理,庫(kù)位管理,生產(chǎn)管理,WMS管理系統(tǒng),標(biāo)簽打印,條形碼,二維碼管理,批號(hào)管理軟件。
點(diǎn)晴免費(fèi)OA是一款軟件和通用服務(wù)都免費(fèi),不限功能、不限時(shí)間、不限用戶的免費(fèi)OA協(xié)同辦公管理系統(tǒng)。
Copyright 2010-2025 ClickSun All Rights Reserved