什么是App？App都做了啥？App与Event关系？为何需要事件？

什么叫Server？

我们要来思考Application微观实现，它和Server的区别在哪里？

1. Server 是一个while轮询的一段运行程序，启动之后，会定时的循环，每次循环，都会处理一些逻辑，同时还会到内存的某一片地方扫描一下有没有自己需要的数据；
   • 端口Port监听和自己写的While死循环服务区别？
   • 如果自己用一个while死循环，则同Http频繁请求一样，对系统的性能消耗很大，除非你每次while都sleep(1s)
   • 监听的点在于事件的优越性，即将自己的这个服务处于挂起状态，循环事件交给操作系统，服务启动后，将代码挂在操作系统的上，等操作系统接收到消息后，解读消息中带的端口号，然后找到订阅该端口号的服务，然后把消息转发过去，这样就省去了while服务对cpu的骚扰。
   • 因此，如果个人想要实现一个服务，则尽量采用监听端口的方式启动，避免采用while的方式轮询redis或者mysql获取数据进行中转；
   • php的问题就在于是脚本语言，并没有很好地在监听端口写服务上下功夫，而其他语言都很容易实现这些概念，比如python，node.js，java，但基于swoole的php已经解决了这个问题
2. Server 一般是没有界面的，界面的存在是人机交互的基础，服务一般是写死的逻辑，接收输入，给出相应的结果，该过程就结束了；
3. 一个后端程序员一上来就从开发服务入手，就不太容易理解Application的概念，因为Server只单纯的处理固定的输入和输出，没有人机交互的设计，也即没有UI层面的设计，当接触到Application开发后，就会有点懵
4. 单纯的Server可能连多线程都不需要，纯粹的同步逻辑处理完毕之后，返回结果就完了，但是Application因为交互比较复杂，要处理的工作也受制于通信I/O延时性导致需要一系列异步编程，这也是跟Server的区分；

什么叫Application？Application解决什么问题？

1. Application就是Server的概念升级，最大不同就是人机交互UI的开发，实际上App开发不是一个完全的前端开发，更是偏重于后端的编码能力，甚至有时候比后端还要复杂，但由于很多东西已经被封包起来，不用前端关心，难度变得可控；

App有那些需要解决的点？

• 异步请求，如果所有ajax请求都必须是异步的，这个概念只要是前端都能理解，前端的数据都由后端来处理那，前端的交互就不可能了，直接就卡死了，所以App的天然基因就是异步处理，而这个异步间切换，如果都开线程也不现实，直接就把客户的机器给搞崩溃了，所以协程就是最好的解决方案，也就是yield让出cpu的能力；
  • 多个ajax的请求是协程方式，可以不阻塞式的与远程服务端交互，但是所有的ajax同时返回时，都直接去修改UI，那么UI就会出现抖动以及不可预测，安卓和IOS就将所有的UI操作都当做队列传给UI控制层，保证渲染的可预测性
  • 浏览器就没很好地遵守这个特点，所以浏览器的渲染就是并发的渲染，其实对于安卓来说，你强行修改也没啥问题，就看你能否把握得住，用好了就是加速，用不好就是bug

---

• 所有的资源文件的请求，这个也必须是异步的，否则下载一个图片，也卡在那里也就崩溃了，但是资源相互之间并不依赖，应该是多开线程并发下载图片，但同样会考虑线程的并发数，会有一个线程池来统一管理图片下载的线程数
• 底层常驻服务，因为App是Server的衍生品，因此底层Server能力是肯定的，这些Server往往以线程的方式随着主进程启动而启动，并且能与主进程进行通信，同时Server与Server间应该可以通信

监听事件是个什么概念？

1. 事件就是一个字符串，click、input等因为有了UI让前端总是不好理解这个概念，停留在表现层的认识，我们还是要回到通信上来理解事件，它就是一段约定字符串，事件就是通信间的一个动作标识
2. 把UI 和 控制层分离开，将其理解为互相通信，UI将收集的信息发过来，这个信息最后还是会被压缩为字符串格式
   • 其实所有的对象，类，因为调试给我们造成的错觉，认为他是一个结构体，实际上也还只是大的字符串，结构体只不过是计算机读入这些字符串之后，用指针的方式，将各个数据关联起来，这样就给你一种感觉仿佛是一个大的结构体，经过调试工具的可视化，让你更进一步觉得这种结构体有了具体的形象，这其实是一种误解
3. UI在安卓中是一个渲染对象，控制层也是个对象，渲染对象会实现约定的一些事件，控制层要实现知道有这样的事件发过来，就会订阅这些事件，并把自己的逻辑（回调函数）放进去，这样当控制层收到UI发过来的消息后，就会提取消息中的事件字符串，然后把订阅该事件的逻辑都拿出来跑一遍

事件放在客户端和服务端之间又是怎样的？

1. 需不需要事先约定事件？

当然需要，服务端不告诉客户端自己有那些事件会发过来，客户端怎么订阅？所以socket.io开发时，前端和后端人如果是两个人，这个概念就简单理解；

全栈为何会搞混socket.io中的event概念？

因为事件和消息类型是同一个概念
因为受到前端click，input这类事件的影响，认为事件是一种表现方式，却不清楚其产生的原因，在后端处理逻辑中，往往会用对象中的一个type字段，或者通过url来表示某件事，如删除事件：/leads/del

自己实现websocket可以不要event概念吗？

那你就需要messageType这个概念，总之你跑不出去，同时你还要自己来实现整个onmessage，提取messageType，trigger这个messageType绑定的一堆逻辑，通socket.io做的事情一模一样，所以socket只不过把这个过程给你封装了起来，你只需要在服务端按格式发送回去事件类型，客户端接收后，写逻辑即可，如果没看过socket.io的源码，这就是迷惑的点，因为封装的太深了

websocket通信时为何需要事件这个概念？

对于长连接来说，因为消息是来回的，url只会被调用一次，此时想要区分各个消息的类型，就只有两个方法，要么采用前端的事件概念，要么采用后端的对象中的type字段，在节省传输资源来看，多一个没用type key，并不是最好的，所以直接约定字符串某段位置就是事件类型

一次http请求过程为何也要加个事件概念？

因为链路过程中比较长，前后逻辑有交互，有需要分文件进行保存，举例来说，第135行时，有一个动作，要等到执行到500行的结果来判断要不要做，如果没有事件的概念，那么这里就需要if判断一下，写一段逻辑，那如果上面有30个动作都需要第500行来判断要不要做，那么这地500行代码是不是要写30个if判断，这可能不是很好地编码习惯
所以，通过在135行里监听一个事件，这个事件完全就是你自己取的一个字符串，期间第150行也要监听一个，以此类推，前30个动作，监听30个事件，等到第500行时，经过计算，得出一种事件，那就触发这个事件，这个事件的回调逻辑就会被执行，这大大解耦了代码的前后逻辑