cnuser002

markdown 顺应的是 web 时代一行行写东西的这种感觉，重内容，轻格式。

网页开发是有一个从简单到复杂的过程的。

最开始的网页就像书页一样，一个开版的大小上显示一些文章段落和图片，然后使用 CSS 做一些排版和样式。

我们把网页按照目录组织好，放在一个 Web 服务器里，别人按照目录下载网页显示在他的浏览器里，根据超链接跳转到新的页面，就像翻页读书一样。

这个阶段写网页，就跟写报纸，编杂志一样，主要是内容和排版。此时还没有后端。

但这种设计有个问题，如果你要频繁更新网页的内容，就需要经常重写网页。这很麻烦。于是出现一个新的设计，将内容存到数据库里，然后编写一个程序，能够从数据库存取数据，自动生成网页。

这样在 Web 服务器那边，只用存一组类似目录的网址，真正的网页，在用户请求网址时，根据当时的内容，由程序自动生成。这种程序就是后端。著名的 PHP 就是专门写 Web 后端的语言。 而别的语言，像 JAVA ，C#,使用专门的库，也可以写这样的后端程序。

这种采用后端自动生成页面技术的网站，就是所谓的动态网站了。他能做的事情，就不仅仅是写一本书了，可以做论坛，可以做音视频网站，可以做网盘等等。

再后来。是因为 Chrome 等现代浏览器的出现，使得浏览器的功力大增， 又有了一种新想法。就是前后端分离。 后端自动生成页面技术里，后端里面很大一部分工作，是前端展示内容的处理逻辑，就是你拿到数据后，怎么渲染页面。

而这个工作，现在可以专门写一组 Javascript 脚本实现。这组脚本在浏览器运行，自动从后端拿数据，渲染成网页，提供交互。这样一来后端就可以把这档子事甩出去了。

虽然乍一看，这样只是把工作量换了个地方。

但是随着移动互联网发展，手机 APP 也要数据。而手机 APP 是自己的语言写 UI ，不需要后端自动生成页面。
所以后端就逐渐变得专注于提供数据，而 Web 这边，需要前端使用 Javascript ，在浏览器里实现接近于手机 APP ，桌面程序的界面布局和交互体验。

这样的需求，催生出了 Angular ，React ，Vue 等 前端工程框架。它们设计了一套前端写应用 GUI 的范式，用这个范式，可以写出 Web GUI 。再配合 Javascript 越来越强的能力，能写出不仅包括 UI ，还能包括数据处理逻辑的 Web Application 。

目前前端就是处在这个阶段。

后端本身什么语言都可以写，甚至本来只存在于浏览器里的 Js ，因为有 node.js 这个开发环境，也可以写后端。 所以有一些网站开发的分支，又回到了后端生成网页技术。不过这时的后端本身也是用的 Javascript 。能带来一些好处。

楼主的担忧我能理解。比如一个发送端，一个接收端。

我当然希望每次接收端收到，都是一个完整的消息，不就能直接处理了么？

但如果这个消息，真的很大呢？ 或许他一次发送不完，那我收到的就不全。我要等，这可就麻烦了呀。同样的，下一次把之前的尾巴，跟下个报文的头一起发送了，我还得拆，更麻烦了。

嗯。Tcp 它就有这种操作，这不是它的问题，而是它的设计，就是基于 Stream ，像流水一样一直给你灌数据。 底层打散但是保证消息还是前后有序进来的。对于这种流，需要按流的处理方法，收取后进入缓冲区，然后在缓冲区里，根据协议里面的约定，比如固定包头，特殊符号来解析出内容。

而这个就是 HTTP 干的事情。 所以你的需求，用 HTTP 就可以实现。你可以认为 HTTP 接口每次拿到的，就是完整的数据。

WebSocket 也可以。

对我来说，首先是 NAS 的本身涵义，网络附属存储。

家里最初只有一台主力电脑，游戏，照片，电影等数据都在这里。这时对网络存储，没有需求。

但是渐渐的，家人们随身的手机，床头的平板，客厅的电视。这些设备，他们的存储容量偏低，自身的数据比如照片等等，需要经常导出；另一方面，类似看电影电视剧，又需要从外部拉取文件。

这个时候还靠那台已经不怎么开的主力电脑，干这个事情就不太合适了。

需要专门有个网络存储，供局域网里的设备共用。
我也试过一些方法，比如说，在家庭 Wifi 下挂载一个移动硬盘。权宜之计，能用，但可以更好。
所以当有了折腾的余裕后，就买了硬盘盒，加上小主机，自己 diy 了一个 NAS 。
实现了本地网盘啊，本地媒体库啊，电影分享，照片备份等等功能。

拥有了 NAS 后，从另一个角度，就等于有一台家庭服务器。那自然可以整点服务器的东西玩玩。挂一些服务，搞一点应用，这时 NAS 就是个容器。

我所知道的响应式设计，是一种布局思路，用这个思路，对不同宽度的屏幕，都能给出一个相对合理的排版。

这里的不同宽度，不仅仅是 PC ，也有 Ipad ，折叠屏，甚至手机横过来。

这个思路的要点，是优先考虑屏幕窄的情况，满足最窄屏幕的布局后，对于更宽的屏幕，可以扩大间距，拉伸组件，增加分栏，总之把它填满。

这里面竖屏手机是最窄的，所以响应式设计，也以“移动端优先”。

这跟业务上 PC 端摆烂，专注 APP 那种“移动端优先”，不是一个意思。

但实际效果，普遍没有想象中的好。首先因为手机的屏幕，相对于 PC ，实在是太窄了。手机 APP 很多是用层级菜单，底部导航栏等适配手机的组件，这些东西放到平板那个宽度，就不好沿用了，想好看的话，还是得重新设计布局。

其次，响应式设计，你得用它的栅格系统，这样的话，你的组件的宽度，组件大小，都是被限制的，不容易跟设计稿对齐。

所以我看现在像 douyin 这种愿意做 web 端的，也都是分两块。移动端弄个 m.域名，直接给你干到 app 下载页，web 端重新设计，从平板的宽度开始，向上用响应式。

Python 本身就是强类型语言，只是它提供许多默认的转换，让你可以直接转数据类型。这点写脚本很方便，不然 JS 也不会有那么多 [魔法]

现在 Python 也有代码类型标注，写的时候带上这种也是可以的。

第一个问题:

现场设备是 A ， 物联网平台是 B ， 手机应用是 C

A 要主动把数据，按 B 定好的格式，传给 B 。 然后 C 按 B 定好的接口，从 B 查数据。

C 要控制 A ，就按 B 定好的接口， B 发命令，B 收到命令后，转发 A 。A 收到后执行。

B 对 C 开放的是 HTTP 接口，或者 Websocket 接口，不涉及到 Native ，所以 C 该怎么开发怎么开发。

Flutter 还，RN 略有过时，写过 React 可以路径依赖，没写过推荐 Flutter 。



第二个问题

A 跟 B 怎么连，两种情况，

如果 A 本身是一个能主动往外推数据的设备，那么它默认有一个对应的 A*平台的格式，你可以自己搞个 B ，兼容 A*的格式，然后修改设备的发送地址。或者你就用 A*的平台，自己写个中间件去拿。

如果 A 本身不是所谓的物联网设备，那么它一般不会是一个能主动往外推数据的设备，需要放一个网关 D, 转成能往外推数据的设备，D 一般有个对接的平台 D*，你可以用它的平台，也可以兼容 D*的格式，弄个自己的。

像阿里，aws 那种，希望你是一个设备生产商，让你的设备，直接接入它们平台，让它们来代管。对你来说，中间的数据存储，流转，就不用你自己操心了。

说说我的体会，
1. 写刷法题，完成小作业，这种场景 C++和 Java ，没有太多区别。
2. 有 IDE 的加持下，用 C++写 windows 桌面程序，和用 Java 写 Android 移动端程序，体验也差不多。同样的模式，都是在预设的框架里按套路写。
3. C++写网络编程，就比较麻烦了，Java 写则很简单，或者说，不简单的地方，已经有高手为你写好了。
4. C++写完了并不算完。头文件管理，交叉编译，调试等等都费劲。尤其一个叫 cmake 的东西，当年把我狠狠干住了，发现没有 Visual Studio ，咋干啥都不顺。Java 这块就轻松多了。

后面用 JS ，Python ，又体会到一种语言在“领域内的垄断”。 比如 JS 在前端，Python 在科研，JAVA 在网络，那 C++呢，则在所谓的高性能领域，什么游戏引擎，网游服务器，音视频处理，高性能硬件开发等等，这个领域本来就费脑子，开发效率天然就低。