plainify

从Quest3/Vision Pro浅淡“空间计算”

前情提要 2023 年 6 月 6 日凌晨,苹果在 WWDC23 上发布了旗下首款 MR 产品 Apple Vision Pro,售价为 3499 美元。仅三个月后的 2023 年 9 月 28 日,Meta 在其召开的 Meta Connect 大会上发布了 Meta Quest 3 头显,售价 499 美元。二者都不约而同的强调 了自己在 MR(混合现实)方面的能力和表现,都希望自己可以将整个世界带入“空间计算”的时代。但和 Quest3 不同的是,Apple Vision Pro 直到 2024 年 2 月 2 日才正式在北美开售,如今各路评测视频都已经放出,笔者也购入了被大多数人誉为“Vision Pro 最佳平替”的 Meta Quest3,想借着自己实际的使用体验聊一聊“空间计算”这个全新的概念。喜欢的朋友不妨点个赞关注一下哦 😯 我为什么购买 Quest3 我为什么会购买 Quest3,说不是心血来潮肯定是有假,但是说一时兴起也不完全对。之前看过很多 Quest3 的测评,都说相较之前代有很大提升,直到这次 Vision Pro 正式开售,我又才重新关注起来。笔者本身就是一个数码爱好者,生活中也经常会和朋友们聊些这个,这也算是我第一次尝试写个简单的测评文章。 Quest3 实际使用简评 首先结论先行,Quest3 是一个很好的头显,画质很棒,影音效果也很棒,游戏体验不错,有一定的沉浸感,舒适度一般,带久了脖子难受,我最期待的 MR 能力形同虚设(这还是发布会上 Meta 重点宣传的内容)。说实话如果不是因为代购的,不能退货,以及价格确实还是可以接受的,不然肯定是会退货的。 首先硬件参数方面,已经发布大半年了,网上到处都能找到,我就不复述了。鉴于我之前没有体验过其他头显设备,和前代/其他厂商的对比这里也没办法给出,因此直接进入简评环节。...

2024-02-25 271 words 2 min
plainify

想追女神?先学 Synchronized 吧

在之前的《从找对象到多线程》一文中我曾介绍了一些和多线程有关的知识,而谈到多线程,就一定离不开「锁」这个名词。在 Java 中,锁的使用主要有两种:Synchronized 关键字和 Lock 接口,本文将会换个角度来聊一聊 synchronized 中的锁。 Synchronized 用的锁是存在对象头里的,用来表明当前对象所持有的锁。在 Java SE1.6 之前,Synchronized 是作为重量锁出现的,一旦使用了 synchronized,就一定会阻塞到其他线程。而在 Java SE1.6 后,为了减少获得锁和释放锁带来的性能问题,引入了"偏向锁"和"轻量锁"的概念。由此可以得知,在新的 Java 中,锁一共有 4 种状态:无锁状态、偏向锁状态、轻量锁状态和重量锁状态。这几个状态会随着竞争不断升级且只能升级不能降级,即轻量锁只会升级到重量锁而不会降级到偏向锁。 以上的解释未免太过官方了,我们从一个小例子入手。 我们用女神来表示同步代码块,就好比女神有很多追求者,同步代码块也会被很多线程执行。有一天女神的微博状态变成了「单身」,此时她就处于无锁状态,于是这些追求者纷纷创建了一个名为**「找对象」的线程**,此时对于女神(对象)来说,还没有任何线程来访问她,所以当第一个男生小 A 试图邀请她看电影的时候**(获取锁)**,她会偏向小 A 的邀请,此时她就是处于「偏向锁」状态的。有了这次经历之后,小 A 就知道该怎么邀请女神而不用反复试探了,这就是「可重入锁」,即同一个线程可以多次访问同一代码块。 再后来女神发了一条微博,说今天和这个男生看电影很开心。这条微博被其他男生看见了,大家也都知道了女神这个对象的偏向状态了。可还是有男生小 B 想追女神,此时这两个男生各自「找对象」的线程就在女神这个对象上产生了竞争。 小 B 一直关注女神的微博动态,他心想着,只要小 A 被女神拒绝了,女神就会变成「无锁」状态,自己也就有机会被女神偏向了。女神也知道小 B 在追自己,为了找到最合适的另一半,女神也在暗中观察小 B,有两个竞争者同时竞争,这时候她就处于**「轻量锁」的状态。虽然女神明显更喜欢小 A,但在小 B 心里觉得小 A 除了比自己早点出现外根本不具有和自己竞争的能力,于是不断给女神献殷勤,保持关系,这就叫自旋,**不断的将自己的时间花费在获取锁上,逐渐成为一条舔 🐶。 虽然一开始女神也会偶尔答应小 B 的邀请,但当竞争者越来越多后,小 B 变得疯狂起来,追求逐渐变成了骚扰,女神也逐渐不耐烦起来。最终在小 A 的努力下,女神和小 A 确定了关系,并发了微博告知众人,此时她的状态就升级成为**「重量锁」状态**。这时,除了小 A,其他所有竞争者的「找对象」线程都没有办法再追求女神了。这样做的好处就是赶紧断了那些追求者的念头,让他们可以早日觅得其他良人,不要在一棵树上吊死。 从线程的角度来看,重量锁使除了拥有锁的线程外的其他所有线程都阻塞,这样可以有效防止 CPU 空转,避免造成资源的浪费。 在偏向锁和轻量锁阶段,女神还没有和任何人确定关系,只要给点甜头小 B 等其他追求者都会很开心,这是一种「乐观锁」。而一旦女神和小 A 确定了关系,自身状态升级为重量锁后,小 B 就很不开心了,对他来说这就是一种「悲观锁」。...

plainify

接口调度者—— API 网关

背景 我们知道在微服务架构风格中,一个大应用被拆分成为了多个小的服务系统提供出来,这些小的服务他们自成体系,也就是说这些小系统可以拥有自己的数据库,框架甚至语言等,这些小系统通常以提供 Rest Api 风格的接口来被 H5, Android, IOS 以及第三方应用程序调用。 在《浅入浅出消息队列》这一篇文章中,我提到了消息队列是方便服务与服务之间的通信解耦,如下图所示: 那么这时候问题来了,如果一个外部的应用(浏览器、App)要去访问这个大应用怎么办? 很简单啊,直接通过 HTTP 请求不就完了? 问题 真的这么简单吗?我们以淘宝的商品详情页为例: 如上图所示,这个页面包含了视频、库存、商品价格、商品评价等内容,这些数据都来自不同的微服务中,所以没办法像传统单体应用一样依靠数据库的 join 查询来得到最终结果,因此就需要多次调用以检索数据,如下图所示: 这就会引发几个严重的问题: 不同的客户端设备可能需要不同的数据。Web,H5,APP,需要单独写一套 API 多次客户端请求导致用户体验不佳。移动网络相较于服务于服务间的局域网,有更低的带宽和更高的延时,如果可以同时执行请求倒也还好,但如果客户端要按照顺序执行请求,就会让用户体验变得异常糟糕。 缺乏封装导致前后端不协调。过分的拆分 API,会导致客户端和服务端过度耦合,再加上移动端 APP 的新版本迭代到每个手机用户时需要很久,这样会使后端很难更改服务的 API。 这样显然是不好的设计,因此,本期的“天降猛男”就出现了——API 网关。 API 网关 在介绍 API 网关前,我们先来介绍一个设计模式——外观模式。 外观模式(Facade Pattern)它向现有的系统添加一个接口,来隐藏系统的复杂性。类图如下所示: 之所以要在说 API 网关前说一下外观模式,是因为二者的设计理念是类似的。 和外观模式类似,API 网关封装了应用程序的内部架构,并为其客户端提供 API,他还可能具有其他职责,如身份验证、监控、负载均衡、缓存、请求分片与管理、静态响应处理。下图展示了客户端、API 网关和服务之间的关系。 所有的客户端和消费端都通过统一的网关接入微服务,在网关层处理所有的非业务功能。其出现也是侧面贯彻了软件工程中**“高内聚,低耦合”**的思想。 核心作用 API 网关负责请求路由、API 组合和协议转换。来自外部客户端的所有 API 请求首先会先转到 API 网关,后者再将请求路由到相应的服务。API 网关使用 API 组合模式处理其他请求,调用多个服务并聚合结果。同时他还可以在客户端友好的协议(例如 HTTP)与客户端不友好的协议之间进行转换。 请求路由 当 API 网关收到请求时,随机会查询路由映射,该映射将指定请求路由到哪个服务。例如,路由映射可以将 HTTP 方法和路径映射到服务的 HTTP URL,这一点和 Nginx 提供的反向代理的功能是一样的,后面我们也会对其进行一个比较。...

plainify

你的系统可用性 5 个 9 了吗?

又是一年放榜日,众多考生满怀期待的点开招生网,结果输了信息才发现根本没办法查询——查询人数太多了,直接把系统打挂了! 这个时候,还没翻身的码农闰土被问到一个直击心灵的问题:这个系统可用性达到了多少个 9? 想要回答这个问题,我们得先有些前置知识。 可用性&可靠性 这两个词很相似,我也一直找不到一个很好的定义区分这两个词,直到后来在看分布式系统的时候,看到了一个解释: 可用性被定义为系统的一个属性,它说明系统已准备好,马上就可以使用。换句话说,高度可用的系统在任何给定的时刻都能及时地工作。 可靠性是指系统可以无故障地持续运行,是一个持续的状态。与可用性相反,可靠性是根据时间段而不是任何时刻来进行定义的。 举个例子,想要评估一个舔 🐶,可用性就是你找他的时候能不能找到,而可靠性就是你需要花钱的时候他出手大不大方。一个舔 🐶 如果随叫随到,但是花钱太抠,就是高可用、低可靠;而如果他经常找不到人,但出手很大方,就是低可用、高可靠。 类比到系统时,如果系统在每小时崩溃 1ms,那么它的可用性就超过 99.9999%,但是它还是高度不可靠。与之类似,如果一个系统从来不崩溃,但是每年要停机两星期,那么它是高度可靠的,但是可用性只有 96%。 百度百科对于系统可靠性的解释是:系统可靠性一般是指在规定的时间内和规定的工况下,系统完成规定功能的能力/概率。也就是系统的无故障运行概率。而在我们在评估一个系统的可用性和可靠性时,一般都会说三个 9,四个 9 之类的。这些一般都是说系统的**SLA(Service Level Agreement)**具体是几个「9」,以此,来表示该系统一年中具体宕机的时间。对于这几个 9 的解释,我会放到第三节来详细解释。 不过,在实际交流过程中,大多数人对这两个词的理解还是差不多的。况且咬文嚼字也并非本文的主题,接下来我们来看看可用性的计算方式。 可用性计算 通常我们用 A 表示一个系统的可用性,用以下几个指标来辅助计算: 相关指标 MTBF MTBF,即平均故障间隔时间,英文全称是“Mean Time Between Failure”。是衡量一个产品(尤其是电器产品)的可靠性指标。单位为“小时”。具体来说,是指相邻两次故障之间的平均工作时间,也称为平均故障间隔。 MTTR MTTR,全称是 Mean Time To Repair,即平均修复时间。是指可修复产品的平均修复时间,就是从出现故障到修复中间的这段时间。MTTR 越短表示易恢复性越好。 通过上述公式计算出单个组件的可用性后,我们便可以以此计算出整个系统的可用性,而系统可用性是通过将系统建模为串联和并联的组件来计算的。以下规则用于确定系统是串联的还是并联的: 如果组件的失效导致组合变得不可操作,则认为这两个部件是串联操作的 如果组件的故障导致另一部件接管故障部件的操作,则认为这两部件并行操作 串行可用性 如上图所示,两个组件 X 和 Y,如果有一个出问题导致整个组合都不可用,就认为 X 和 Y 这两个组件是串联的。只有组件 X 和组件 Y 同时可用时,整个组合才可用。由此可见,组合的可用性是这两部分的乘积,公式如下: A = Ax Ay...

2020-08-22 251 words 2 min
plainify

DO,VO,DTO 你知道吗?

作为后端最常用的编程语言之一,Java 已经有很多年的历史了,在阿里内部,Java 也是使用最广泛的一门语言。在阿里实习的这段时间,规范一词是我感受最深的。没有规矩不成方圆,今天来说一下 Java 中的各种 O(bject)。 为什么会出现这些 O? 我们知道,这些 O 不管叫什么名字,其本质都还是对象(Object),既然本质都一样,为什么非要给他们套上各种马甲? 个人认为原因有三: 第一,随着编程工业化的发展,需要有一套合理的体系出现。中国人喜欢造神,外国人喜欢造概念,于是 MVC、MVP、MVVM 等编程模型就出现了,为了搭配这些编程模型的使用,需要对 Object 的功能进行划分,于是我们便看到了这些层出不穷的 Object。当然这里并没有批评这些概念的意思。 其二,我认为在团队协作编码中,一个好的命名方式是可以节约很多时间成本的。就比如getItemById一眼看去就知道是通过 id 获取一个 item 对象,ItemVO一眼看去就知道是前端透出的 json 对应的对象。 其三,如此划分,可以让项目结构更加清楚,不至于出现东一块西一块,对象乱扔的局面。尽可能避免了在多人协作时对象混乱的情况。 总的来说,这一切都是为了让软件编程更加合理、更加规范、更加高效。 有哪些 O? 这些 O 有很多衍生出的命名,比如 VO、DO、BO,这里我们把常见的 O 列举出来,然后一一解释。 以下内容参考阿里巴巴 Java 开发手册,如果有需要可以在微信公众号「01 二进制」后台回复「Java 开发手册」获得。 DO( Data Object):与数据库表结构一一对应,通过 DAO 层向上传输数据源对象。 PO(Persistant Object):持久对象,一个 PO 的数据结构对应着库中表的结构,表中的一条记录就是一个 PO 对象 DTO( Data Transfer Object):数据传输对象,Service 或 Manager 向外传输的对象。 BO( Business Object):业务对象。 由 Service 层输出的封装业务逻辑的对象。 AO( Application Object):应用对象。 在 Web 层与 Service 层之间抽象的复用对象模型,极为贴近展示层,复用度不高。 VO( View Object):显示层对象,通常是 Web 向模板渲染引擎层传输的对象。 POJO( Plain Ordinary Java Object):POJO 专指只有 setter/getter/toString 的简单类,包括 DO/DTO/BO/VO 等。 DAO(Data Access Objects):数据访问对象,和上面那些 O 不同的是,其功能是用于进行数据操作的。通常不会用于描述数据实体。 一下子给出 8 个常见的 O,光看解释大家可能会有些迷糊,接下来我们从下面这张图入手,带大家直观的感受下,这些 O 的用处。...

plainify

聊一聊 2038 年问题

庚子年是中国传统的 60 甲子纪年法。擅长观测的古人很早就发现,每当年份执行到庚子这一年,自然灾害变多,突发事件频频,一些震动世界、影响安定的大事件也容易发生在这一年。而我们现在所处的 2020 年就是新一轮的庚子年,现在都 4 月了,很多网友都调侃说新的一年什么事情都没做,光在见证历史了。 当然了,作为一个技术博主,我并不是来给大家科普庚子年的,今天我们要说的是计算机中的一个比较危险的年份——2038 年。 2038 年问题 在说 2038 年问题前,我们需要先明白计算机是如何存储系统时间的。 在 Unix 或类 Unix 系统中,都是以 1970 年 1 月 1 日 0 点 0 分 0 秒作为时间的基准点,用秒数来表示系统时间,也即当前系统时间是从基准时间(1970 年 1 月 1 日 0 点 0 分 0 秒)走过多少秒之后的时间。 用公式简单表示就是这样:系统时间 = 基准时间 + 秒数 因为基准时间是确定的,所以我们唯一需要考虑的就是秒数应该如何保存。在当时那个年代,计算机硬件资源非常紧缺,用 16 位表示数据就已经是一个非常奢侈的选择了。因此当时的设计者都认为用 32 位存储秒数已经**“足够大”**了。所以从那个时候开始使用 32 位来表示秒数。 我们知道在二进制中,32 位数能表示的最大的数是$2^{32}-1$,不过为了能够让时间可以往前往后数,会用第一位作为正负的判断位,第一位如果为 0,则说明为正;若第一位是 1,则说明为负。因此,在 Unix 或类 Unix 系统中,这$2^{32}-1$个数被分成了 2 部分,分别是$+2^{31}-1$和$-2^{31}$。这样我们就可以以 1970 年 1 月 1 日 0 点 0 分 0 秒作为时间的基准点,往前往后每过一秒就加一个数字,依此来计算时间。...

2020-04-16 199 words 1 min
plainify

2022的取舍与得失

每年双十二结束都意味着新年降至,回想这一年发生了太多太多的事情,总觉得需要写些什么,但又不知从何下笔。提笔前翻了一下待办,里面收集了很多自己想写的文章,比如之前一直想写一篇文章来聊一聊内卷的,又或者聊一聊自己工作这一年的总结感悟,但总是由于这样或那样的原因耽搁了,如今正好趁着🐑了在家隔离的这段时间把这些想写的东西收一下。这篇不算年终总结的文章,也没什么脉络,就是想到什么就说什么了。 如今疫情终于放开,报复性消费没有看见,反而是越来越多的小🐑人涌现出来。很不幸的,笔者近期也中招了,本想着分享一些自己的新冠自愈过程,但也不知是杭州的毒株较为温和还是我的抵抗力较强,除了第一天晚上有轻微的发热外,其他时候的感觉甚至不如普通感冒让我难受。而网上所传的喉咙刀片的感觉、食欲不振等情况也都没有经历过,这点看来还是较为幸运的,而且事后为了奖励我的免疫系统,我的食欲也随之提升,这么看来明年的减肥又变得艰巨起来了。 先说说内卷,提到阿里,除了996、福报这些词之外,更多的就是“卷”这个词了,卷王、奋斗逼这一系列名词应运而生。而且由于国内这种“形同虚设”的劳动法以及中国人骨子里“艰苦奋斗”的精神又让这一切变得那么正常与合理。仿佛你从小一路成绩优异、名校毕业后就该在这岗位上累死累活。说了这么多,接下来举几个例子来说说什么是内卷。 抢火车票,一个人先用抢票软件,逼得其他人也用抢票软件,因为票没有变多,最后大家都回到了起跑线,但是开发抢票软件的赚了。 孩子上学,一个孩子上辅导班,逼得大家都去上辅导班,最后排名还是没变,但开辅导班的赚了。 本来大家都是工作8小时,有人开始加班,最后逼得所有人都加班,所有人挣得还是那点钱,但是老板的3系换5系了。 内卷是啥,内卷就是大家都损失了,只有一小撮人赚了。 内卷是无法带来质变的量变。 至于怎么摆脱内卷,无非两条路,要么多一点,要么均一点。 “华盛顿不是一个生活的地方。这里房租高,这里吃的差,这里的灰尘令人作呕,这里的道德令人厌恶。去西部吧,年轻人。去西部,并和国家一起成长。”——纽约论坛报,1865年。 “好在苦惯了,而且什么人都是一样苦,从军长到伙夫,除粮食外一律吃五分钱的伙食。发零用钱,两角即一律两角,四角即一律四角。因此士兵也不怨恨什么人。”——毛选《井冈山的斗争》 掐指一算,从去年7月毕业入职到现在工作也有一年半了,期间经历过业务方向调整、团队成员变更、好友离职等等,当时实习时一起留下来的小伙伴们如今也是走的走,散的散,没留下多少人了。近来也时常会思考,要不要看看外面的机会,留在这里的意义又是什么?思来想去仍然没有一个明确的答案,一来因为业务确实还行,内容化本来就是每个大厂在做的事情,相对来说还是有些前景的。二来团队氛围确实很棒,自从前段时间换了leader之后,团队氛围有了质的提升,轻松的氛围确实有助于工作效率的提升。 试想一下,如果长时间处在一个被挤压、高强度push的环境下,员工的心理是否健康都需要划一个问号,更别说静心工作了。个人看来,不仅仅是阿里,现在的大厂里有很多leader是极其不称职的,这个不称职不仅仅体现在专业能力上,更多的是个人素养,说的难听点就是**“早生几年吃到时代红利而趾高气昂的油腻中年人”**。这些人个人能力并不突出,却要通过不断的否定下属以此获取所谓优越感。这里也不好多说什么,总之还是很庆幸脱离苦海了。 这一年,因为疫情的原因,各家效益都很差,裁员的裁员,倒闭的倒闭的。之前看过一个观点,当一个行业走下坡路时,大家如果都还在希望自己拿到裁员补贴的话,这个行业还有救。当大家都开始希望自己不被裁的时候,这个行业才是真的危机了。所以这么看来的话,现在应该还远没到最差的时候。只是随着获客成本的不断增加,以及其他同行的步步紧逼,留给淘宝的时间又有多少呢?只是这个问题就不该是我操心的了。 说说失与得吧。 因为一开始选择的是业务部门,导致自己与技术偏离的越来越远,这一年多全在做业务需求,哪怕是技术沉淀也没什么好说的,无非是各种架构的设计、各种方案的选型,各种漏洞的治理。真正沉下心做技术的时间太短太短了。做业务or做技术一直是一个两难的话题,有一个段子是说所有的后台需求最终都会归结到excel上,侧面也反映了业务需求的难度其实大抵如此。除了对所用的中间件越来越熟之外,底层原理却也不像读书时一样能钻研进去了,这是下一年需要好好改进的地方。 这一年有没有其他什么明显的成长呢?我想还是有的。看待问题的角度确实相较以前更加多元化了,也越来越明白了个人的力量在一个庞大的组织面前是那么的无力。有的时候哪怕你发现了团队中的一些问题,初出茅庐的你指出了这个问题,可后来发现其实大家早就知道这个问题,但就是无能为力。我不清楚是只有阿里是这样自上而下的,还是说其他公司也大多如此,如果真是这样,那恐怕希望自己媳妇熬成婆的那天仍然能一直年轻吧。 总的来说这一年因为疫情过的相对平淡很多,出行不方便以至于除了团建没别的外出游玩的机会了。另一方面也由于工作的原因,公众号的更新也基本维持在一个月一篇,而且也从技术科普类的转向架构设计,算是对平时工作的一个梳理与总结。而且马上新的一年就要来了,对于flag啥的没什么想法,就是希望能顺利晋升,快乐一些。 最后,2022年要恭喜梅老板手捧大力神杯。

plainify

AI换脸——汝怎饰品如面

事先说明,该篇文章中的代码是我无意中发现的,这里仅做一个分享,文末会给出参考文章,不喜勿喷。 完整源码和预训练模型可在公众号:「01 二进制」后台回复:「AI 换脸」获取 前言 作为一个经常逛 b 站的肥宅,前段时间无意中看到了一个名为"换脸哥"做的换脸视频,让杨幂“穿越”到了 1994 年版的《射雕英雄传》里,“代替”了朱茵,“出演”了黄蓉这个角色。视频如下(b 站视频已经被删了,只能转载知乎的视频了,原地址是杨幂“换脸”,AI 换脸究竟有多可怕 - 科技富能量的文章 - 知乎): 看完我便虎躯一震,这也太厉害了吧,这种技术一旦流行起来,ab 不用去片场就能拍戏了啊,真的是躺着赚钱啊。这要是运用到 H 片上,岂不是 😅😅😅 言归正传,作为一个 coder,在看到这个视频之后我就很想知道这究竟是怎么做出来的,在查阅了一些资料后,我才发现最悲伤的事情莫过于,好不容易把源码找到了,数据集下载好了,结果显卡带不起来… Tips:这里给出我之前找到的两个有关视频换脸的仓库,有兴趣的自己去了解下: deepfakes_faceswap FaceIt 既然条件不允许,那我们只能降低成本,既然视频里的脸不好换,那就退而求其次,换一下图片里面的脸,果然在我的苦苦寻觅后,我找到了一个低配版的 Python 换脸大法: 《Switching Eds: Face swapping with Python, dlib, and OpenCV》 以下内容均参考上述所标注的文章,在这感谢原作者。 接下来我将会介绍如何通过一段简短的 Python 脚本(200 行左右)将一张图片中面部特征自动替换为另外一张图片中的面部特征。 具体过程分为四个步骤: 检测面部标志; 旋转、缩放和平移图 2 以适应图 1; 调整图 2 的白平衡以匹配图 1; 将图 2 的特征融合到图 1 中; 实验环境 MacOS 10....

plainify

API与SDK:有什么区别?

前言 什么是 API? 什么是 SDK? 两者之间有何关系? 欢迎来到本次的每周一问系列。 既然点进来了,相信你或多或少都听说过这两个名词了,因此,在为你解答之前,让我们先从一个例子出发。 假如你想开发一个 OCR 应用(通俗的说就是文字识别应用),他的功能是识别用户上传的一张图片,然后将图片中的文字识别出来返回给用户。如下图所示: 通常,OCR 应用的后端服务都会部署在云上,那么我们应该如何在移动应用程序与基于云的服务之间进行通信呢? 这就是 API 和 SDK 的用武之地了。 API API 的特点 通信 首先我们要明白的是 API 是和通信有关的,是用于应用(服务)与其他应用(服务)对话所定义的协议。在上述例子中,你可以简单理解为 API 是 OCR 应用和云端服务之间沟通的桥梁。 那么 API 到底是什么? API 全称 Application Programming Interface,即 「应用程序接口」 。 一般是指一些预先定义的函数,目的是供应用程序与开发人员基于某软件或硬件得以访问一组程序的能力,而又无需访问源码,或理解内部工作机制的细节。 以 Java 为例,当你想要实现一个数组排序的功能时,你是会先手写一个排序算法,还是直接使用Arrays.sort()函数?我想你心里是有答案的。 抽象 其次,我们要理解,API 的另一个重要特点——抽象。 抽象指的又是什么? 还是以这个 OCR 应用为例,当我们在使用云端提供的文字识别能力时(比如百度文字识别),他的背后可能会有成千上万的代码,比如提供识别能力的机器学习的代码、提供 Web 能力的后端代码等等。 但是你作为一个 APP 的开发者,你需要去看这些代码是怎么写的吗?难道不知道背后的源码就不能调用百度提供的文字识别能力了吗?当然不是。 通常服务商已经给你提供了文档,告诉你如何去调用相应服务,只要你按照他的要求来即可。 因此,在你的 APP 和 OCR 服务之间,API 抽象出所有复杂的逻辑,简化了调用过程,这使得你只需要考虑获取所需的数据即可。 标准化 API 是标准化的,这意味着存在有关如何定义 API 的行业标准,比如 SOAP、REST、GraphQL 等。...

plainify

IP 地址怎么定位?

我们经常可以在影视作品中见到某某组织通过对某个人的 IP 地址进行监控,定位其位置,甚至精确到某栋大楼的某一层,如此可怕的场景在现实生活中真的有可能会发生吗? 先来说结果,仅通过 IP 地址最精确能够达到街道级别。而且在不通过运营商的用户数据库查询情况下,定位到家庭住址和单元楼的情况难度很高。 ISP 在《互联网是如何工作的》一文中,我们介绍道,IP 地址是类似于现实世界中的地址这样的东西,通过 IP 地址,我们就可以在网络上定位到一台计算机,在现实世界中,IP 地址是由一个叫互联网服务提供商,即 ISP 提供的。 回想一下我们上网的过程: 去运营商(移动、电信、联通)办理宽带业务 -> 业务员上门拉线 -> 电脑连接宽带 -> 访问互联网 在这一过程中,三大运营商就是我们能接触到的 ISP 的,ISP 可以从互联网管理机构申请到很多 IP 地址,然后一些机构和个人从某个 ISP 获取 IP 地址的使用权,并可通过该 ISP 连接到互联网。 那么 ISP 又是如何标记 IP 地址的地理位置的呢? 我们先来说说 ISP 的三层结构。 三层 ISP 结构分为主干 ISP,地区 ISP,本地 ISP。本地 ISP 给用户提供最直接的服务,本地 ISP 可以连接到地区 ISP,也可以连接到主干 ISP。从原理上讲。只要每一个本地 ISP 都安装了路由器连接到某个地区 ISP,而每一个地区 ISP 也有路由器连接到主干 ISP,那么在这些相互连接的 ISP 的共同作用下,就可以完成互联网中的所有的分组转发任务。 这里我们通过计算机网络教材中的一张图来理解三层结构,如图 1 所示 👇 也就是说,当你向好友发了一条微信,这条微信首先会从你所在公司/学校的内网上发到当地的服务器,再从当地服务器发送到地区服务器,之后从地区服务器通过移动/联通/电信的服务器向你好友所在地的地区服务器转发,再通过本地服务器最终转发到好友所在公司/学校的内网。 如此一来,既然你的 IP 地址是由当地的 ISP 分配给你的,自然也就知道了你所在的 IP 地址的大致位置了。...