1. 文档阅读
TBD
2. 整理输出 2.1 App与后台通信协议 网上暂答: 通用的语言有很多种，例如英语和中文. 在网络的通讯中，通用的协议有很多，其中http是被最广泛使用的。 如果是私有的协议，那就只能自己另外设计. 用http是最方便的，如果是私有协议，包含协议的封装和拆解，工作量大，前端程序员和后端程序员都要增加很多额外的工作量。而且私有协议对程序员的要求高，不适合从web网站转过来的开发者。除非是手游，不然用http就好了。 问题 App和服务器通讯使用长连接还是短连接？ 假设现在通过手机拨打另外一个人的手机，手机通话费用非常便宜[甚至可以忽略]，但是有两个注意的地方：
1.一台手机同一时间只能接听一个电话。
2.一台手机接听电话前非常麻烦，要拨号啦，要等接听，这需要一段时间。 App和服务器通讯使用长连接还是短连接这个问题，可以等同于上面电话模型，是一直保持着通话，还是有需要时才拨号通话这个问题？ 当App和服务器通讯使用长连接，就相当于一直保持着通话，服务器能保持的通讯数量有限，如果通讯满了，那其他App就不能和服务端通讯了。这种通讯方式，多数是使用socket或websocket连接长时间连接，对程序员的要求比较高，开发比较困难，除了手游和聊天推送服务外，不建议使用。 当App和服务器通讯使用短连接，就相当于需要时才拨号通话。 这种通讯方式，配合http协议，是现在主流的通讯方式，开发效率高，有大量的第三方资源，使用非常广泛，推荐使用这种方式。 当App和服务器通讯使用短连接，就相当于需要时才拨号通话。这种通讯方式，配合http协议，是现在主流的通讯方式，开发效率高，有大量的第三方资源，使用非常广泛，推荐使用这种方式。 当App调用api的时候，只需要明确下面３点
1.这个api是干啥的（柜员机例子中，是取款功能，还是查询余额,还是转账） 2.知道要输入什么（柜员机例子中，取款要输入金钱） 3.知道结果是什么（柜员机例子中，取款是成功还是失败） 至于api内部是怎么处理的，app根本无需理会。 api，一般是以http的形式调用的，通过http传入参数，返回结果。 其中，结果一般是以json格式返回的，因为json格式被众多计算机语言支持，而且省流量。 app站内信实现原理 App站内信通常的实现原理如下：
在服务器端建立一个站内信表，包含通知 ID、接收者 ID、发送者 ID、发送时间、通知内容等信息。
接收者打开 App，App 向服务器发送请求，获取所有未读的站内信。
App 取得站内信后，将其显示在用户界面中，标记为未读消息。
用户点击站内信界面，切换至站内信详情页面。
App 向服务器发送请求，获取某一条站内信的详细内容。
服务器返回站内信详细内容，App 显示通知内容，标记该站内信为已读消息。
通过这些步骤，站内信可以实现用户之间的信息发送和接收，有效地传递信息。
站内信客户端主动定时发请求拉取未读消息？
是的，站内信客户端通常需要定时向服务器发起请求获取未读消息。这个过程通常称为“轮询”，客户端定时发送请求，服务器返回最新的未读消息。
为了减少轮询的次数和消耗，常常使用“长轮询”技术。客户端发起请求后，服务器会保持连接不关闭，直到有新的站内信到达或者一定时间后返回响应，然后客户端再次发送请求。
长轮询可以实现服务端向客户端实时推送消息的效果，减少了轮询操作产生的网络开销和服务器资源消耗，并保证了信息的及时性。
轮询与长轮询的区别？ 轮询和长轮询都是客户端定时向服务器请求数据的方法，主要区别如下：
响应时间： 轮询方式中，客户端定期向服务器发送请求，服务器返回结果，并主动断开连接。在客户端下一次定时请求之前，可能有新的数据更新，但此时客户端无法及时获取。而在长轮询中，客户端发送请求后，服务器会保持连接，直到有新数据更新或者一定时间后才返回结果，保证了数据更新的及时性。 网络资源消耗： 在轮询中，客户端定期向服务器发送请求，即使没有新数据更新，仍需要消耗一定的网络资源（每次都建立连接）；而在长轮询中，客户端只需要发送一次请求，等待服务器返回更新数据，不会产生多余的网络开销。 服务器资源消耗： 在轮询中，服务器要处理大量的不必要请求，降低了服务器的处理效率和服务器的资源运行效果。而在长轮询中，服务器只有在有数据更新时才需要处理请求，节约了处理资源。 总体而言，长轮询相较于轮询更加实时、效率更高，具有更好的数据更新效果，并且相对节约网络和服务器资源，更加适合异步通信和即时通信等实时性要求较强的场景。 在长轮询中，服务器可以主动想客户端发送请求 发送消息？
在长轮询中，服务器通常不能主动向客户端发送请求或发送消息，这是因为长轮询的核心原理是在客户端发起请求后，服务器等待并保持连接，直到有新的数据或定时返回响应，然后客户端再次发送请求。 但是，在一些实现方式中，服务器可以通过推送服务主动向客户端发送请求或者消息，实现实时数据推送的功能。这种实现方式通常称为“Comet”。 Comet 可以通过两种方式来实现实时数据推送：一种是“长连接”（Long Connection）, 即在客户端发起请求后，服务器保持响应连接不关闭，然后服务器可以随时向客户端发送数据，以达到实时推送的效果，这种方式需要服务器开启很多的连接，对资源的消耗也比较大，不太建议使用；另一种是“HTTP 流”（HTTP Streaming）, 即通过类似视频流的方式，将数据分成多个包发送到客户端，长时间不关闭连接，以达到模拟实时推送的效果，这种实现方式可以在现有的 HTTP 网络基础上实现，不需要额外的连接，也不会影响网络速度。可以是一个较好的解决方案。
长轮询和长连接的区别
长轮询（Long Polling）和长连接（Long Connnection）虽然名字相似，但是它们之间存在较大的区别。主要区别如下：
概念不同： 长轮询是一种简单的 Web 技术，即在客户端向服务器发送请求，服务器接到请求之后，如果发现没有数据需要返回，则将这个请求挂起，直到服务器端有数据更新或时间到期再返回数据。长连接是指在客户端和服务端之间保持一个持久的连接，客户端和服务端可以双向通信，即使没有请求数据，也不会断开连接。 应用场景不同： 长轮询用于定时获取最新的数据更新，相对适用于 HTTP 协议获取实时数据。而长连接通常用于即时通信、实时推送以及在线游戏等场景，能够实现真正的实时通信。 是否需保持定时发送请求： 在长轮询中，客户端需要在一定时间内定时向服务端发送请求，这会占用一定的网络带宽，产生一些资源消耗；而在长连接中，客户端和服务端的连接始终保持打开，不需要定时发送请求。 是否需要推送服务支持： 长连接通常是通过推送服务实现的，需要服务端支持 WebSocket、STOMP 等协议。长轮询同时也可以是 Comet 实现中的一种，不一定需要额外的支持。 综上所述，长轮询和长连接是两种不同的通信方式，适用于不同的应用场景。长轮询适用于定时获取实时数据的场景，长连接适用于实时通信、即时推送和游戏等对实时性要求比较高的场景。 请求挂起怎么理解？ 请求挂起（Request Held or Suspended）是一种在服务器端处理 Web 请求的方式。在 Web 应用程序中，通常的情况是客户端发送一次 HTTP 请求，服务器处理请求并立即返回相应结果，然后断开连接。但是，在请求挂起的情况下，服务器不会立即返回响应，而是“挂起”请求，即等待一段时间（一般是几秒钟）后再返回响应。 具体来说，客户端向服务器发起请求后，服务器立即返回一个等待状态的响应，然后保持与客户端的连接，直到新的数据可以返回为止。在此期间，连接处于挂起状态，客户端可以选择等待或者取消请求。 请求挂起的作用在于可以减少不必要的网络开销和服务器资源消耗，以及实时性更新数据和推送通知。开发者可以对不同的数据流参考实际情况使用请求挂起的方法，从而确保系统的稳定性和数据传输的及时性。 如果客户端可以选择等待，客户端是否表现为阻塞，影响用户体验？ 在请求挂起的情况下，如果客户端选择等待，客户端通常会进入一种类似阻塞（Blocking）的状态，即等待响应期间不能与服务器进行通信。从客户端角度来看，这可能导致一些用户体验问题。 具体表现来说，如果客户端等待时间过长，用户可能会感到应用程序不可用，甚至可能超时或挂起；如果客户端需要一直等待，用户体验是不好的。另外，如果客户端选择等待，这可能会消耗一些服务器的资源，包括线程和内存，这可能会导致一个瓶颈。 为了提高客户端的体验，开发人员可以使用 JavaScript 框架，例如 jQuery、React 或 AngularJS 等，在客户端中实现请求挂起，并利用异步编程的方式等待响应，使用户可以同时执行其他操作，提高客户端的反应速度和用户体验。另外，对于一些数据量较大的操作，可以采用分页、滚动等方式，分批获取数据并显示，以减少等待时间和提高用户体验。 所以，站内信的实现方式一定是由客户端主动发起请求才行？如果app进程关闭，则站内信一定获取不到消息？ 通常情况下，站内信的实现方式确实需要由客户端主动发起请求，向服务器获取最新的站内信数据。如果 App 进程关闭，那么客户端也就无法运行，也就无法继续向服务器发送请求获取站内信，这是获取不到最新的消息的。 不过，为了提高 App 的用户体验，并确保用户不会错过重要的站内信信息，有些 App 会采用消息推送的方式，即服务端在手机等设备上推送消息。这样，在 App 进程关闭或者处于后台运行的情况下，也可以及时地向用户推送消息，提醒用户查看站内信。 需要注意的是，消息推送需要用户的同意和权限，并需要在服务端和客户端分别进行配置和实现，具有一定的技术难度和安全隐患，需要开发人员进行相关的开发和测试，确保消息推送的准确性和实时性。 ！！！消息推送的实现原理？ 消息推送是通过在客户端和服务器间实时、双向地建立一个持久的连接（长连接）来实现的。具体实现原理如下： 客户端向服务器注册推送服务，服务器保存客户端和推送服务之间的映射关系。 客户端和推送服务建立长连接，连接保持打开状态，等待服务端信息推送。 服务器检测到有新的消息需要推送时，通过推送服务向客户端发送数据，客户端接收器数据并进行处理。 数据传输完毕后，连接仍保持打开状态，并等待下一次数据发送。 当客户端不再需要接收推送消息时，或者连接超时时，客户端向服务器发送断开连接请求，服务器删除客户端和推送服务之间的映射关系。 消息推送的关键在于长连接的维持和消息的实时推送。为了减轻服务器压力，通常使用轮询或长轮询来检测是否有新消息，如果有新消息，则立即推送给客户端，否则等待下一次轮询。消息推送通常需要服务器配置和应用程序的支持，并需要保证数据安全和传输的可靠性。较常用的实现方式是 WebSocket、STOMP 和 MQTT 等协议。 所以当app开启消息通知时，即使app处于关闭状态，后台依然存在进程与推送服务器保持连接？ 是的，当 App 开启消息通知功能后，即使 App 处于关闭状态，后台仍然会有一个进程与推送服务器保持连接，以保证即使在 App 未被打开的情况下，也能够接收到新消息的推送。 这个后台进程通常称为“推送服务进程”，负责建立和维护客户端和推送服务之间的长连接，并处理服务器推送的消息通知。这个进程是独立于 App 进程的，在 App 被关闭或者进入后台运行状态时，推送服务进程也会继续保持运行状态。 需要注意的是，为了确保数据的安全，这个进程并不是无限期运行，通常会由系统自动维护和管理。在一些操作系统中，如 iOS，当推送服务长时间不活动或者被系统强制关停时，推送通道可能会被重置或关闭，此时客户端需要重新注册推送服务，重新建立推送服务通道。 这个推送服务器是由谁提供？业务服务器还是第三方服务器？ 推送服务器可以由业务服务器提供，也可以由第三方服务提供商提供。具体实现方式和选择取决于应用场景和业务需求。 当应用业务比较简单的时候，推送服务器通常由业务服务器提供，通过配置消息推送模块，使用类库 API 或开发框架对推送服务进行封装，进行差异化的推送。 而对于一些复杂的业务场景，通常使用第三方提供的推送服务，如苹果的 APNs、谷歌的 FCM、华为的 HMS、极光推送和腾讯信鸽等。这些第三方服务提供商通常具有稳定、高效、安全和灵活的推送服务、可以为用户提供强大的消息推送能力。 不过，使用第三方服务提供商也会产生一些成本和安全方面的考虑，例如推送量是否限制、推送的费用、数据私密性等问题。因此，在选择推送服务器时，需要综合考虑自身业务需求和成本等因素，选择最适合自身情况的推送服务提供方。 2.2 浏览器与服务器通信
TBD
后续补充 ... | 
发表评论 取消回复