如果说UI编程是在有限的有一个具体的有长和宽像素点阵的屏幕上绘图,那么视口就是倒过来从一个没有具体长宽的虚拟屏幕上截取一块放在一个具体的屏幕上显示。
这就好比你在野生动物园里从远处去看一只大象,和你近距离抚摸大象,你视觉中的大象其实不同的概念一样。古人自知事物全貌和局部给人的感受差别,所造成的是认知不同,比如管中窥豹、一叶障目、盲人摸象、一览众山小,知识和讲解类视频就像是给人一节「竹管」、一片「树叶」、一双「慧眼」以及登高远望一览无余的「山峰」,用得好可以循序渐进、用得不好则误人子弟。
可以说「视口」概念天生具有知识传播属性,因为我们总是在学习尚未认知完整但是已被证明是正确的体系,就好像我们已经不再在学校学习四书五经陈旧的但是曾经成体系的知识。
我们是通过见微知著地一点点学习来不断完善对整体的认知的,这需要投入大量的时间来完成某种“教学大纲”,因为你现在学习的高数、大物其实都是为后续的专业课打基础的,只是你现在并不知道它的用处。因此视口还具有让庞大的知识体系变得简单灵活的作用。
此外视口能够屏蔽掉非干扰信息,让你专注于当下内容,比如我只关注环境保护的内容,就不要给我先讲半个小时人文科技的背景,视口就像搜索引擎,只给你看你关注的内容。
其实视口就如Windows操作系统的字面意思,提供视窗。让所有本来晦涩难懂的专业性代码图形化、视窗化,也就是数据可视化,经过可视化后的数据容易被人理解、操作和用于决策。
如果你用过各种拖拽式的组件你就会发现,像ListView这种子视图是没有具体长度的,可以无限延伸,除此以外少有不需要指定具体大小的,即便你开发的时候没有指定,也有通过布局体系来自动判断和确定视图的大小。绝大多数容器型组件都必须有长和宽的限制,也几乎可以编程重新指定大小以及绘制方位,比如.x=0, .y=118, width=80, height=168 这样图形系统才能绘图完成我们之前说过的在有限物理屏幕上绘制。
两相对比,如果把知识视觉化,不论是一张图片、一段视频、一个思维导图、一张表格、一篇论文、一段合同、一段法规。他们是没有坐标和长宽概念的,但是也都具有以下特点:
对比现实世界和游戏世界的地图绘制,你就会知道,在资源有限的情况下绝不可能真的先把整体和全貌绘制下来再截取其中一段投放在有限物理像素的屏幕上,他们使用一种独特的拼接技术,从数据和结构层面做了优化,使得一次只渲染处于视口中的像素。那么当用户在通过移动屏幕意图阅览其他方位时,就可以根据这些数据和结构实时生成新的地图。这时候地图的显示也并不像是从屏幕边缝里流出来的,完美贴合屏幕的空白区域,而是大块地不规则地绘制,没有绘制的依旧成为空白,继续判断是否完成了视口的绘制,没有则继续拿出探测的区块数据进行视觉化绘制。
那么这样的按需绘制其实就可以借鉴到知识视觉化中来,经过简单分析发现这种拼接技术需要具备一些基本条件:
再跟之前知识视觉化进行对比,我们不难得出结论,传统的知识视觉化很难做到实时拼接技术,因为它需要一种新的基于片段检索
以及 片段完整性复原
的支持体系。
这两句话的意思被知识视觉化翻译之后就是
2. 法规
3. 论文
笔者认为有两种途径可以解决这种矛盾
而 从原有完整性结构中拆分出片段式结构
又有两种主流的实现方式:
其实主流媒体制作软件从最初的自家格式到一些通用格式都是这种思路,世界上广泛接纳的格式比如xml等等。天生具有结构化分解、重组、描述性等特征。
为此APP需要两种新的磁贴:
借用编程语言中常用的功能函数,就是类似进行splice、slice、split、reduce 之后再 join 起来。
这样知识就可以像地图一样,上下左右,放大缩小,成为工具而非精神鸡汤。再加上一些娱乐化的手段至少在解说领域可以做到有趣、有料了。
下图是Flutter在1.20版本中最新提供的基于视口的组件
可以设想以后知识类视频制作者从一大长段的视频中插播一小段视频,不用再素材收集、导入剪辑再导出,格式转化了;
可以设想教师授课不用再去从众多乌烟瘴气的广告信息、陈旧信息、商业化信息中大海捞针一般地寻找有用的作为教学素材了,他可以直接引述一个经过APP背书的流行的课程、视频,从它的引用信息中直接获得若干进行转述或再引用;
可以设想知识类UP主们不用再画很多精力放在图片放大,裁切,截图处理,添加动效表情,制作鬼畜效果来达到传播知识的同时娱乐大众了,你们节省下的时间可以制作和搬运更多有趣的内容,以及个人品牌推广,做视频真的很费时间。
也欢迎关注我的专栏
以及最新热文