精华内容
下载资源
问答
  • 本文详细讲述58同城高性能移动Push推送平台架构演进的三个阶段,并介绍了什么是移动Push推送,为什么需要,原理和方案对比;移动Push推送第一阶段(单平台)架构如何设计;移动Push推送典型性能问题分析解决,以及高...
  • SDCC2015-58赶集集团-孙玄-58同城高性能移动push推送平台架构优化之路
  • 58同城高性能移动PUSH推送平台经过不断演化,目前能够满足58同城所有业务线的移动PUSH推送需求,每秒中能够达到10万QPS的吞吐量,每天的吞吐量为百亿量级。众多的移动业务线已经接入进来:58同城、转转、58帮帮、58...
     
    

    58同城作为中国最大的生活服务平台,涵盖房产、招聘、二手、二手车、黄页核心业务。随着移动化时代的到来,每个业务线都有移动PUSH推送的需求,满足多个业务线海量的消息PUSH推送需求,成为我们急需优先解决的关键问题之一。58同城高性能移动PUSH推送平台经过不断演化,目前能够满足58同城所有业务线的移动PUSH推送需求,每秒中能够达到10QPS的吞吐量,每天的吞吐量为百亿量级。众多的移动业务线已经接入进来:58同城、转转、58帮帮、58速聘、58违章、58二手车等等。

     

    本文详细讲述58同城高性能移动PUSH推送平台架构演进的三个阶段:什么是移动PUSH推送?为什么需要移动PUSH推送?移动PUSH推送原理和方案对比?移动PUSH推送第一阶段(单平台)架构如何设计?移动PUSH推送第二阶段(多平台)架构如何设计优化?移动PUSH推送第三阶段(公司级统一高性能)架构和协议如何设计和优化?移动PUSH推送典型性能问题分析解决以及高可用、高性能、高稳定性我们如何保证?

     

    什么是移动PUSH推送?

    移动PUSH推送是移动互联网最基础的需求之一,用于满足移动互联环境下消息到达Apps客户端。以转转(58赶集旗下真实个人的闲置交易平台)为例,当买家下单后,我们通过移动PUSH推送消息告诉卖家,当卖家已经发货时,我们通过移动PUSH消息告诉买家,让买卖双方及时掌握二手商品交易的实时订单动态[1]

         

           转转订单移动PUSH推送消息 


    为什么需要移动PUSH推送?

    移动互联网络环境下,经常会出现弱网环境,特别是2G3G等网络环境下,弱网环境下网络不够稳定,Apps客户端和相应服务器端的长连接已经断开,消息无法触达到Apps客户端。而我们业务需要把Message(转转Apps交易消息等)、Operation(转转Apps运营活动等)、Alert(转转红包未消费提醒等)等消息推送给Apps客户端,从而触发用户看到这些消息,通过点击这些PUSH消息达到相应目标。

     

    移动PUSH推送原理和方案对比

    移动PUSH推送主要有三种实现方式:

    移动Apps轮询方式PULL

    Apps客户端定期发起PUSH消息查询请求,来达到消息推送的目的。PULL方案的优点和缺点都比较明显,整体架构简单但实时性差,我们可以通过加快查询频率,提高实时性,但这会造成电量、流量消耗过高。

     

    移动Apps基于短信推送方式(SMS PUSH)

    通过短信发送推送消息,并在客户端置入短信拦截模块,将接收到的短信拦截,并解析后转发给Apps应用处理。这个方案实时性好、到达率高,但成本很高。

     

    移动Apps长连接方式(PUSH)

    移动PUSH推送基于TCP长连接实现,消息实时性好,这是目前主流实现方式,需要维护Apps客户端和服务端的长连接心跳,会带来额外的电量、流量消耗,在架构设计时,需要做些折中,以避免流量和电量的大量消耗。此外PUSH推送技术架构复杂度较高,维护移动Apps客户端的海量长连接请求,并建立与Apps客户端通信的加密通道,整合成内部少量有限的长连接,对通信数据进行压缩与解压,以节省流量。

     

    目前移动PUSH推送技术基本都是结合这 3 个方案进行,但对于不同的移动终端平台,又有各自不同的实现,这里详细介绍下iOS平台Android平台上的具体实现方案。

     

    iOS平台

    对于iOS平台,由于iOS平台的特殊性,移动PUSH推送相对较简单,iOS中的应用是不允许service后台常驻,所以你没有别的选择,也没有办法通过开发自己的 push service 来完成推送下发,只能通过苹果 APNS方式来完成推送,iOS移动PUSH推送流程[2]如下:


    2 iOS移动PUSH推送流程 

    Android平台

    Android平台上,由于没有iOS平台上不允许service常驻的限制,可以选择的方案就相对多一些:可以通过Google官方C2DM完成移动PUSH推送、移动PUSH推送开源方案(例如XMPP)、借助第三方移动PUSH推送方案、完全自主研发的移动PUSH推送方案。

     

    GoogleC2DM[3]的主要流程如下:

    3 C2DM移动PUSH推送流程

     

    GoogleC2DMAppleAPNS流程大致类似,但其最大的问题是移动PUSH推送服务器在国外,很容易被屏蔽,而且PUSH推送延迟较大,而且由于Android社区分裂比较严重,很多厂商可能直接就把 C2DM 模块给去掉了,所以在国内这个方案极不可靠,变成了一个理论上的方案。

     

    移动PUSH推送开源方案

    对于开源移动PUSH推送协议,常见的有XMPP,事实上谷歌的 C2DM底层也是基于 XMPP协议实现的,我们通过线下测试发现,开源移动PUSH推送方案主要有两个问题:第一没有ACK机制,移动PUSH消息到达性不保证,因此消息到达不可靠;第二、当移动PUSH消息请求量并发增大时,系统开始变的不稳定,甚至出现了模块宕机的情况。因此直接使用移动PUSH推送开源方案,也不是非常可靠,我个人建议:在大规模使用开源的移动PUSH推送方案之前,需要能够做到对开源技术方案整体的HOLD住,不然一旦出现问题,无法及时定位和修复的话,带来的后果将可能是灾难性的。

     

    借助第三方移动PUSH推送方案

    除此之外,目前移动PUSH推送市场,还有不少第三方移动PUSH推送产品供选择,使用第三方移动PUSH产品需要面临以下几个问题:

    第一、到达率

    虽然第三方移动PUSH推送产品都宣传到达率能够达到 90%及以上,但实际使用起来,发现远远不到。当然到达率低的问题,除了第三方移动PUSH推送平台本身技术原因外,还和业务推送方推送用户选取有很大关系,如果选取的推送用户较活跃,那么移动PUSH推送达到率就会高些,如果选取的用户不活跃,可能这些用户已经卸载了相应的Apps客户端,必然造成移动PUSH推送到达率进一步降低。

    第二、实时性&控制度

    第三方移动PUSH推送产品的推送通道是共用的,会面向多个推送客户,如果某一个客户PUSH推送量特别大,那么其他的移动PUSH推送消息实时性可能就会受到影响,这些都是业务推送方不可控的,会比较被动。

     

    完全自主研发的移动PUSH推送方案

    我们曾经考虑实现一套完全自主的移动PUSH推送平台,如果从零开始来做,需要解决几个难点:第一、移动PUSH推送服务端对移动Apps客户端海量长连接的维护管理;第二、Apps客户端常驻service稳定性,如何使push service常驻?我们可以借助父子进程互相监控的方式来做到,一旦发现对方进程不在了,会重新建立对方进程,继续循环监控;第三、手机在内存不足的时候,系统会杀掉push service,甚至有些操作系统比较强势,它会向iOS系统一样并不允许第三方push service 常驻;第四、移动PUSH推送到达率的提高,除了技术手段外,还有一些PR的手段,比如移动Apps客户端pushservice通过在相应操作系统上添加白名单的方式使其永久常驻。总之,移动互联复杂场景下如何让移动PUSH推送到达率变的更高不是一件简单的事儿

     

    58同城移动PUSH推送方案

    我们综合考虑前面讲述的开源方案、基于第三方方案、完全自主研发方案,58同城的移动PUSH推送方案没有选择从零开始完全自主研发的方案,我们最终采用了基于第三方移动PUSH推送平台和自主研发高性能Provider的方案[4],满足每天百亿量级的吞吐量,并通过动态组合和扩展的方式,结合离线的移动PUSH推送数据分析,不同手机使用不同的推送策略,针对性优化,在Android平台方法,我们融合多种第三方移动PUSH平台,从而有效提升到达率。

    4 58同城移动PUSH推送平台技术架构

     

    移动PUSH推送第一阶段(单平台)架构如何设计?

    背景&需求

    2011年我们研发了58帮帮,58帮帮是一款满足58用户和58商户之间沟通的即时通讯软件,用户间可以互相添加好友、收发消息等。58帮帮帮的消息推送是基于Apps客户端和服务器的长连接,一旦这条长连接断开,那么IM服务端的消息将无法推送给Apps客户端,用户也无法看到这些消息。在iOS平台上,由于iOS平台的特殊性,58帮帮Apps切换到后台后,AppsIM的长连接断开,消息无法触达,这时候我们需要借助iOS APNS机制,IM消息需要发送给APNSAPNS再转发对应的消息到58帮帮AppsAndroid切换至后台,AppsIM的长连接保持,IM消息可以正常推送,因此在这个阶段我们需要解决的问题是在iOS平台上,当58帮帮Apps切后台后,IM在长连接断开后的消息触达需求。

     

    设计目标

    基于上述的背景和需求,我们在设计移动PUSH推送第一阶段(单平台)架构时,首先要满足在iOS平台上,当IM长连接断开后,IM消息的能够触达到Apps客户端。其次我们的移动PUSH推送协议设计也具备很好的扩展性,在可以预见的未来,我们的移动PUSH推送平台逐步接入更多的Apps,因此我们设计目标是iOSProvider是一个通用的iOS推送服务。不同Apps通过使用不同的移动PUSH推送证书借助同一的iOSProvider完成移动PUSH消息推送,对于不同Apps的接入,我们采用了配置文件方式动态扩展接入,iOSProvider根据所配置Apps证书与APNS建立并维护多条TSL连接。配置文件的格式如下:

    第一个域#第二个域#第三个域#第四个域

    其中,第一个域为推送服务类型Type,以备扩展,1APNS;第二个域为内部定义的APPID号,对应服务的Apps;第三个域为AppsApple证书文件名;第四个域为与APNS建立的连接数;

    每个Apps接入的配置为一行,举例如下:

    1#88#zhuanzhuan.p12#64

    1#66#58tongcheng.p12#32

     

    除此之外,iOSProvider[5]需要对每个接入AppsAPNS连接池进行管理,动态增删TSL连接,具备动态重连机制,并具有单独的反馈接收线程,用于异步的接收APNS返回无效的Token,反馈给移动PUSH推送业务方,用于下次移动PUSH消息推送的优化。iOSProdiver根据TypeAPPID选择对应的APNS连接,通过推送线程组装APNS包发送到APNS服务器。

    5 iOSProvider架构图


    移动PUSH推送第二阶段(多平台)架构如何设计优化?

    随着移动互联时代的到来,58同城研发了多个Apps58帮帮、58同城等等,每一个Apps都有移动PUSH消息推送的需求(消息、运营活动、过期提醒等),并且每一款Apps同时具有多个终端:Android版本、iOS版本等。在这样的需求背景下,我们的移动PUSH推送平台需要继续演进,如何演进呢?

     

    iOS移动PUSH推送通道可以很好的满足业务推送的需求,目前还不具备Android移动PUSH推送的能力,因此我们急需要研发Android移动PUSH推送通道。如何做?综合目前可选择的Android移动PUSH推送方案,我们选择了基于第三方推送平台以及自主研发高性能AndroidProvider的方案。

    首先重点讲述针对Android移动PUSH推送的流程[6]:第一、Apps客户端向第三方移动PUSH推送平台注册,获取对应的Apps唯一标示(Token);第二、Apps把从第三方移动PUSH推送平台注册获取的Token信息发送给AndroidProvider并集中存储,以便后续基于Token的移动PUSH推送;第三、AndroidProvider通过HTTPS或者TSL的方式和第三方移动PUSH推送平台建立连接,并把需要推送的消息发送到第三方移动PUSH推送平台;第四、第三方移动PUSH推送平台收到AndroidProver推送的消息后,会把此消息及时的推送到Apps,从而完成整个移动PUSH消息的推送过程。

    6 Android移动PUSH推送流程



    7 AndroidProiver系统架构图


    AndroidProvider子系统整体结构分为四个层次[7],第一层为业务方移动PUSH推送接入,用于众多移动PUSH推送业务方的接入层;第二层为网络交互层,用于接收移动PUSH推送业务方的消息数据以及发送请求处理层的处理数据给业务推动调用层;第三层为请求处理层,用于处理网络交互层放入请求队列的数据,组装成第三方移动PUSH推送接口需要的数据,通过HTTP或者HTTPS的方式调用下游的接口,并等待请求结果的返回,把请求返回的结果放入回应队列;第四层为第三方移动PUSH推送平台,由第三方提供,开放给使用方接口,供调用其功能。

     

    随着越来越多的移动Apps接入,移动PUSH推送需求变的越来越多样化,同时移动PUSH推送业务逻辑复杂化(多终端、批量发送、业务规则多样),公共策略每个业务方重复开发(深夜防打扰功能、发送频率和发送速率的限制等),造成开发效率低下。为了解决这些问题,我们抽象了公共的逻辑[8],并进行了统一的封装,对业务调用方透明,这些公共的逻辑包括:通用的策略和通用的控制。

    8 Android移动PUSH推送演进业务架构

     

    在移动移动PUSH推送第二阶段(多平台)阶段,我们具备了AndroidiOS的通道服务能力,满足满足移动PUSH推送消息的需求。但是我们没有提供统一的发送接口,业务方需要各自组包(AndroidiOS)发送不同的移动PUSH推送通道,除此之外,移动PUSH推送通道性能方面还有待提升,移动PUSH推送通道稳定性方面还有待提升,移动PUSH推送通道包含了相对共同的业务逻辑,移动PUSH推送通道还不够“纯粹”。

     

    移动PUSH推送第三阶段架构和协议如何设计和优化?

    移动PUSH推送第二阶段还存在一系列的问题,因此在移动PUSH推送第三阶段我们需要解决这些问题,并且随着更多Apps接入进来,我们需要提供公司级统一的高性能移动PUSH推送平台。基于第三方移动PUSH推送平台,我们自主研发了满足每天推送百亿量级的高性能Provider,移动PUSH推送平台具备了高稳定性、接入方便,并提供了较高的推送到达率。

     

    移动PUSH推送平台第三阶段我们如何架构和设计?首先我们满足对下游接入方多种连接的管理(HTTPHTTPSTCPSSLTSL)。具备了多种连接动态伸缩性,从而满足Provider层对移动PUSH推送连接的要求;其次我们平台要具备高并发的特性,通过完全异步的设计和多线程的支持,做到了高并发和支持10QPS的吞吐量;再次我们需要对接入下游的错误进行处理,一旦发现连接被断开等错误后,要能够自动使用新的连接,并且对已经发出还没到达Apps客户端的推送消息进行重发,以保证推送消息的不丢失;第四我们需要对通道进行封装,对外提供统一的友好接入接口,屏蔽底层iOSAndroid接入的差异性;最后在Android移动推送方面,我们接入了更多的第三方推送平台,以达到更高的到达率。

     

    基于这些方面的考虑,58同城移动PUSH推送平台采用了低耦合的分层架构设计[4],分为三层push entrypush transferprovider(iOSProviderAndroidProvider)。其中push entry是业务方调用的入口,我们采用异步消息队列的方式,提供了较高的业务方发送的速度,并且具备了消息缓冲的功能,使得高峰期的海量移动PUSH消息推送对整个平台冲击较少,也起到了保护移动PUSH推送系统的作用;push transfer会从push entry层接收消息进行解析,对移动PUSH推送消息进行合法性检查,如果消息格式不合法,直接丢弃,同时会进行接收到的推送消息格式转换成内部的消息格式,分平台转发到iOSProvider或者AndroidProvider上;provider接收到push transfer的消息后,会按照下游需要的消息格式(APNS协议、Android协议)进行转换,进行消息的下发,在下发的过程中,会进行消息的重发,以确保消息下发到第三方推送平台。

     

    provider模块内部我们如何设计?以iOSProvider为例,讲述下我们的设计,iOSProvier分为三个层次[9]:接入逻辑、业务逻辑、APNS出口。其中接入逻辑主要处理网络交互和请求分发;业务逻辑主要处理线程分裂扩展、并发处理和错误处理;APNS出口处理向APNS的发送逻辑。

    9 iOSProvider模块结构图


    对于移动PUSH推送平台来说,追求达到率是我们最核心的指标,没有之一。因此在Android移动PUSH推送方面,我们融合了多个第三方移动推送平台,通过机型控制,对不同的机型使用不同PUSH通道,进一步提升推送到达率。AndroidProvider层进行消息推送策略的控制,先推送一通道,根据此推送通道ACK情况,是否继续推送其他通道。推送多个PUSH通道,会出现推送消息重复到达Apps客户端的情形,此时需要Apps客户端根据推送消息的ID进行去重,收到的重复推送消息忽略处理。

     

    移动PUSH推送典型性能问题分析解决以及高可用、高性能、高稳定性我们如何保证?

    在移动PUSH推送不断演进的过程中,我们遇到AndroidProvider并发低,仔细分析是因为我们采用HTTPS库,由于库中HTTPS的连接实现不是线程安全的,对每个HTTPS的请求都加锁串行化处理,从而保证了线程的安全性。发现问题后,我们通过在线上增加多进程部署的方式暂时解决,使得我们有足够的时间分析此问题产生的根本原因。经过我们深入的分析,发现是我们对HTTPS的库掌握不够,导致我们加锁的粒度过大,通过HTTPS库提供的更小粒度的锁[10],我们不仅解决了线程不安全的问题,也提升了AndroidProvider的并发度。

    10 HTTPS库细粒度锁实现方式


    总之,58同城统一的高性能移动PUSH推送平台,我们通过无状态化设计和冗余部署等方式提供了推送平台的高可用,通过纯异步、动态多线程的支持提供推送平台的高性能,通过质量保证、多种监控机制(进程监控、语义监控、错误日志监控、数据波动监控等),有问题及时发现处理保证了推送平台的高稳定性。

     

    最后,我要感谢项目组的同学,特别感谢姚劲同学,有了你们持续不断的努力和付出,才有了今天这篇文章;也感谢老婆大人,有你在背后默默的支持,才有了今天这篇文章。

    展开全文
  • 对于el-col,可以使用push和pull布局: 今天一个项目写页面时候报错 就是授权记录这里的问题,因为对el-col设置了栅格向右移动16格,但是传入的是字符串,需要传入的是数值类型 改成这样就可以了: ...

    对于el-row,可以使用type,justify,align等方式实现布局
    在这里插入图片描述
    对于el-col,可以使用push和pull布局:
    在这里插入图片描述
    今天一个项目写页面时候报错
    在这里插入图片描述
    就是授权记录这里的问题,因为对el-col设置了栅格向右移动16格,但是传入的是字符串,需要传入的是数值类型
    在这里插入图片描述
    在这里插入图片描述
    改成这样就可以了:
    在这里插入图片描述

    展开全文
  • 移动Push(推送)通用类 & 原理图!

    千次阅读 2013-11-13 17:12:03
    这是一个推送工具类,作为移动推动的后台服务,由吕津(lvjin948@163.com)开发。它: 1. 支持Android推送,使用百度云推送。(参考代码:https://github.com/xiariqingquan/BaiduPushAspxServer) 2. 支持IOS(Apple/...

    这是一个推送工具类,作为移动推动的后台服务,

    由博主吕津(Email: lvjin948@163.com,QQ: 258652032,微信个人号:lvjin119,微信公众号:深圳市瑞驹商贸) 开发。它:

    1. 支持Android推送,使用百度云推送。(参考代码: https://github.com/xiariqingquan/BaiduPushAspxServer
    2. 支持IOS(Apple/iPhone)推送,使用APNS-Sharp(参考代码: https://github.com/Redth/APNS-Sharp

    百度的那块改写自APNS.


    下载地址:http://download.csdn.net/detail/lvjin110/6546297




    上图【移动审批消息推送(示例IOS)】是金蝶K/3移动审批案例。有兴趣的可以下载试玩一下。(能买当然好喽!)

    http://k3mobile.kingdee.com:8800/WISE/default.htm


    展开全文
  • PushMail移动应用

    2009-04-28 14:37:55
    关于移动PushMail应用,对于手机开发的很有用哦。
  • 中国移动WAP Push SP接口协议. 本文档定义了MISC与SP之间WAP Push消息的接口协议,版本号为1.0。
  • wappush移动

    2008-10-18 22:42:21
    wap push 很有用的,是移动的。拿过来就是可以用了。
  • 移动平台的push服务ppt

    2013-03-04 17:50:03
    介绍ios,android, win7系统下的push服务特点
  • OMA push协议

    2013-08-21 20:49:37
    push协议,用于开发wap push使用。该push为移动push,cdma push还包含一层teleserviceId,该协议是做wap push必要手册。
  • Push信息自动启动JAVA移动应用程序,J2me例子
  • PUSHMAIL 标准摘要

    2008-06-04 13:24:47
    移动PUSHMAIL标准摘要
  • 如果您已经有一个现成的混合移动项目,比如IBMWorklight项目,请跳过这一节。1.如果您还没有该项目的话,请下载ApacheCordova的节点打包模块,并为ApacheCordova设置环境。2.在安装Cordova后,打开一个命令提示符。3...
  • 移动无线PUSH MAIL技术简介说明

    千次阅读 2007-10-09 11:01:00
    采用"PUSH"技术移动终端用户无需主动接收EMAIL、不需要拨号也不需要主动发起链接。您的EMAIL会被"PUSH"到您的移动终端上。PUSH MAIL系统会不断地监测您的EMAIL帐号,如果有新的EMAIL,系统会主动地将您的EMAIL的正文...

        采用"PUSH"技术移动终端用户无需主动接收EMAIL、不需要拨号也不需要主动发起链接。您的EMAIL会被"PUSH"到您的移动终端上。PUSH MAIL系统会不断地监测您的EMAIL帐号,如果有新的EMAIL,系统会主动地将您的EMAIL的正文部分"推"送到您的手机上,在收到EMAIL时手机会发出提醒。收到邮件后,用户可以阅读邮件的正文并可以以"流"(Streaming)的形式分页对各种通用格式的附件文件进行浏览。它可以与用户已有的企业或个人邮箱结合,将用户的企业和个人邮箱延伸到其移动终端上,同时也可以实现接收、发送、转发和回复等邮件功能。还可为移动终端提供过滤、阻断等功能,确保用户在移动中只接收到关键和有用的邮件。PUSH MAIL 为移动用户提供端到端的通用的、被广泛接受的加密措施,确保PUSH MAIL的安全性。

        目前已有一些电信运营商选择已经了采用PUSH MAIL服务器或网关(例如:Smartner www.smartner.com 、 Visto www.visto.com、Blackberry www.blackberry.com)为其智能手持终端用户提供无线电子邮件的服务。其中以Blackberry 最为成功,目前已经拥有近3百万用户,Blackberry 只是针对企业用户,但用户必须使用其专用终端设备,并且其对多种通用格式的附件文件的浏览能力十分有限,加之其封闭性的结构和每月数十美元的服务费用,使其难于大面积普及。

    Picsel 文件浏览器
        以为移动终端提供文件浏览软件著称的Picsel,其产品已经被摩托罗拉、三星、DoCoMo等在Linux, Symbian, Pocket PC, Smartphone, Palm, Nucleus等平台上大量采用。

        Picsel产品背后的核心技术是ePAGE™ 。它是一个占用内存很小的、快速的、优化的以及高可移植的图形描绘和文件显示引擎。与其他的图形应用不同ePAGE™ 不依赖于设备OS的图形API。它在其自己的存储空间内对一个文件进行描绘并请求OS将其显示在屏幕上。这使得由ePAGE™ 所驱动的应用具有很高的可移植性,可以移植到几乎所有其它的平台上。

        Picsel受专利保护的ePAGE™ 技术提供了一个统一的文件阅读和Web浏览的平台,可以在各种手持终端上忠实地显示Adobe PDF, HTML, Word, PowerPoint, Excel, JPEG, GIF, BMP, Text, Zip和其它多种格式的文件。与OS独立,意味着 ePAGE™ 可以在移动终端上资源有限的特殊条件下,对数据进行一致地、可预见地描绘,与终端屏幕的尺寸、色彩能力、操作系统等无关。

        Picsel的附件处理服务器和移动终端的文件浏览的客户端可以很容易地分别与PUSH MAIL服务器或网关以及移动终端上的PUSH MAIL的客户端集成在一起,提供一个完整的能够处理附件的PUSH MAIL的整体解决方案,将电子邮件中的各种不同格式的文件附件在不改变其原来格式和页面的情况下打开和显示。

        在收件箱中附件由一个文件图标指示。附件的文件名和文件类型在信息正文的末端列出。可以在移动终端上对附件进行选择阅读第几页,用户无需等待文件全部下载完毕。对于大的文档用户可以选择浏览某一页,节省网络费用和时间。文件显示可以随意放大、缩小、、平移以及改变显示方向。

    互联网邮箱移动PUSH MAIL解决方案(例如):

        拥有智能手机的移动用户只要在其手机上安装相应的PUSH MAIL客户端软件就可以通过又PUSH MAIL运营商提供的服务,将其在互联网上的EMAIL邮箱有选择地推送到手机上,并且可以对邮件正文和各种通用格式附件进行分页浏览。

    企业邮箱移动PUSH MAIL解决方案

        企业在其内部放火墙内安装PUSH MAIL平台,并在移动终端上安装相应的PUSH MAIL客户端软件,可以将企业邮箱用户现有的EMAIL帐号延伸到手机上,不改变用户的使用习惯,可以浏览邮件的附件。采用端到端的加密措施,确保邮件的安全性。

    目前支持的移动终端平台
        Linux, Symbian, Microsoft Mobile, PalmOS, Nucleus。

    支持的文件浏览格式
        Adobe PDF, HTML, Word, PowerPoint, Excel, JPEG, GIF, BMP, Text, Zip等

    在移动终端上浏览各种格式文件的效果


    PowerPoint PPT


    Adobe PDF


    Word

    结论
        移动用户对于能够在第一时间及时阅读到电子邮件,特别是来自公司内部或其他来源的各种格式的文件是至关重要的,可以大大提高了工作效率、把握市场先机。

        永远在线-PUSH MAIL 可以将用户的邮件主动地推送到用户的移动终端上并提醒和等待用户的阅读。用户可以定义过滤器通过智能化的屏蔽和选择,控制不想接收邮件。

    展开全文
  • 中国移动139邮箱_Pushmail_v3.6.7.cab
  • app-push:该项目向移动应用程序发送通知
  • 选择HTML上的内容并将其推送到移动设备 1.将html消息推送到手机上。2.从计算机到手机,您可以轻松地将文本或Web内容推送到手机上。 在计算机上键入→收到通知的电话→复制,发送短信,打开URL或地图。 3.Translation...
  • 论文一篇,基于SMS的PUSH技术及其在移动网络异步通信中的研究与应用
  • 基于Push和LBS技术的移动互联网 校园传媒平台毕业设计论文
  • 电信设备-下发PUSH消息的方法、后台服务器和移动终端.zip
  • aws sns 移动设备push服务(gcm 方式)

    千次阅读 2015-01-30 15:54:50
    aws云服务提供了非常完善的服务,移动设备的消息推送服务也非常不错,且费用极低、性能良好。 虽然aws官网上有很详细的步骤说明,但是偶还是走了一大圈弯路,主要由于对于Google的接触实在太少,以至于在使用Google ...
  • 此脚本使用 Pushover API 在 MATLAB 完成脚本运行或脚本因错误终止时向一台或多台移动设备发送通知。 API 调用使用简单的 HTTP POST 请求,因此可以轻松修改以与其他 API 配合使用,以通过 SMS 或其他方式发送消息...
  • 那么对于有n个元素的vector调用push_back,若不涉及扩容,则调用一次拷贝构造函数;若涉及扩容,则调用n次移动构造函数和一次拷贝构造函数。 参考: https://blog.csdn.net/nie_quanxin/article/details/81187468 ....
  • 首先仔细阅读 C++ primer 第五版 P474 Note下面的一段话意思是说当我们在类中定义了移动构造函数的时候,假设这个移动构造函数是noexcept的,类似对应StrVec类的操作,vector可能会重新分配内存,也就是说会将元素从...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 179,597
精华内容 71,838
关键字:

移动push