dtysky|一个行者的轨迹

我的简历

dtysky — Friday, 14 Mar 2025 00:00:00 -00:00

瞬光寂暗

邮箱 : dtysky@outlook.com

Github : dtysky

学历和工作

2025.03 - now , 腾讯，互娱，游戏引擎技术组长
2020.08 - 2025.02，腾讯，微信，图形/大模型
2019.07 - 2020.07，支付宝，前端技术专家
2018.03 - 2019.07，支付宝，高级前端开发工程师
2016.08 - 2018.03，哔哩哔哩，前端工程师
2015.10 - 2016.07，上海禾赛光电，软件工程师
2015.07 - 2015.09，华为，逻辑（FPGA）工程师
2014.10 - 2015.06，Xilinx，研发实习生
2011.08 - 2015.06，东南大学，测控技术与仪器，工学士

发展方向

游戏/WEB/AI。

技能

工具

工作语言：TypeScript, C#, C++, CSS...需要什么就写什么呗，哪有那么多讲究。
领域技术：WebGL，WebGPU，FPGA，图形学，游戏开发...需要什么去学呗，哪有这么多讲究。
业余语言：Rust, Python, Scheme, VHDL, Verilog...更没讲究了，写着玩。
兴趣爱好：微单，无人机，PS，LR，LRT，Davinci，剪映。

专业领域

工作：WEB开发, 游戏引擎开发, 图形学
业余：数字图像处理, FPGA
爱好：文学创作，专业风光/人文摄影

个人介绍

生命是积累痛苦的巡礼，但这断然不是虚无与毁灭的故事，在前方一定还存在着救赎和希望。

非典型码农，INFP，ADHD，宿命论者，混乱善良。自洽，坦然，从容。
厌恶无聊，追求有趣，言出必遂，尽力而为。但为了避免过早毁灭，也知道节制。
最欣赏的特质是清醒和勇气，最讨厌的特质是怯懦和贪婪。
看过不少书，经历过不少事，但仍旧保持着初心。
从小漂泊过半个中国，没有故乡。
毕业后换过四个城市五家公司，在B站用爱发电过，在阿里经历过斗争，现在在鹅厂搬砖，工作内容和兴趣一致。
事业比大多同龄人快，见识过很多光鲜外表下的不堪，看透了许多事，觉得任何交往中最重要的是真诚。
人格已达「完全之形」，拥有不随环境变化的强硬核心，承受逆境的能力很强。
对世俗物质本质上没有需求，但仍然在不影响创作的前提下努力工作赚钱，为了获得更多的体验作为输入。
严格来说我有很多种世俗上更好的选择，不过都放弃了。
因为从个人审美来看，现在选择的这种生存方式可能会支付更多代价，但却是最美丽动人的。

欣赏过一些严肃文学，文艺片，舞台剧，摇滚，独立游戏。
持续探索适合自己的创作方式，想创作出令自己满意的作品，并产生社会价值，让他人得到慰藉或清醒。
写过剧本小说，系统学过画画。每周末都会出去拍VLOG，假期会出去旅游。
目前是专业风光摄影师，设备A7R5/A7R3/AIR3。

年少时蔑视命运，坚信“我命由我不由天”、“人定胜天”，做事没有节制和分寸，以对自己和周围的损害换取高人一等，现在想来只是不知道恐惧、也不知伤害为何物。
再后来总是被命运戏弄，了解到了人的局限性，知道了人不一定胜天，就多了些怯懦和贪婪，想苟活于世，尽可能向这个世界索取更多，达到一种“盈余”性质的无憾。
而现在终于理解了命运的本质：“命”为宿命，在人生的起点便已经达成了某种意义上的结束，是无法改变的一个范围；而“运”则为运势，是可以尽力去改变和拨弄的，而这种“拨弄”，就是在既定结局前的选择。
向世界索取一些，然后再向世界归还等价的一些。选择与代价的一体两面，成长所意味的背负，以负担换取生命的厚度。知晓恐惧后却仍要向前走，观测之后更重要的是付诸行动。
以前不理解为什么异域镇魂曲的主角在历经一切、得知真相的最后，选择放弃永生随意捡起一把武器冲向战场，现在我终于彻底理解了——

“意义并不在于‘包罗万象’的观测，而存在于任一行动的回响之中。”

这大概就是所谓“命运”在审美层次的真正内涵吧。

主要项目（工作I）

Supercell游戏迁移

说明: 将Supercell的自研引擎,以及所有游戏迁移到小游戏平台.
规模: 超大
性质: 公司项目
职位: 技术组长
进度: 第一个游戏预备上线

XR-FRAME 2.0

说明：在微信小程序中，实现一套官方的混合渲染、高性能、易用、强扩展性、渐进式、遵循小程序开发标准的XR渲染方案。
规模：大
性质：公司项目
职位：主要负责人，整体架构设计、客户端和前端实现。
进度：第二版开发完毕，待上线。使用技能：
图形学, 客户端开发，前端架构, 游戏引擎架构,WebGPU，Metal，XR, Typescript, C++，OC，JNI......
完成内容：

基于1.0的前端架构，重构了后端实现。

负责了WebGPU的工具用渲染后端实现。

负责了基于Google/Dawn项目的wgpu客户端渲染后端实现。

实现了XR系统，让项目可以在VR眼睛上运行。

实现过一个纯Metal的渲染后端，后来由于维护成本放弃。

XR-FRAME

说明：在微信小程序中，实现一套官方的混合渲染、高性能、易用、强扩展性、渐进式、遵循小程序开发标准的XR渲染方案。
规模：大
性质：公司项目
职位：主要负责人，整体架构设计、渲染系统、资源系统、XR系统。
进度：第一版已发布，第二版开发中
使用技能：
图形学, 前端架构, 游戏引擎架构, XR, Typescript, C++......
详见官网：微信小程序 XR-FRAME
惯例彩蛋：小程序示例官方AR彩蛋，开启传送门探寻世界真相
完成内容：

负责了整体架构，在顶层实现了一个小程序的渲染后端，提供了给用户高度的组件定制、资源定制能力。

基于跨平台的渲染层（微信内是客户端实现），负责了主体渲染前端和WebGL后端的实现。

其他重要系统，例如资源系统、AR系统、后处理系统等等的实现。

富有个人特色的文档，全面的数据上报监控。

和多个团队以及外部服务商对接合作，进行业务落地的推进。

第二版将实现3D和2D标签的混合，在GL中统一渲染，便于开发者实现更加酷炫的UI。

微信小游戏高性能解决方案

说明：在微信小游戏环境内提供逼近原生的性能。
规模：超大
性质：公司项目
职位：主要负责渲染部分。
进度：全新版本已发布
使用技能：
图形学, 游戏引擎架构, Typescript, C++......
详见官网：微信小游戏框架
完成内容：

参与渲染引擎设计，与同事一同决定了渲染部分的方案。

负责了整个渲染引擎前端部分的实现。

负责了整个引擎的Web跨端方案实现。

项目已经支持不少项目，比如新轩辕传奇、天龙八部荣耀版，可在微信小程序内直接搜索游玩。

支付宝2020新春五福活动

说明：负责首页3D展示和福满全球：亿级前端项目中的3D技术-支付宝2020年新春活动的背后。
规模：大
性质：公司项目
职位：项目前端负责人。
进度：已上线
使用技能：SEIN.JS
完成内容：

主会场3D模型，5个场景，极致优化，只占20M内存。

福满全球，几乎所有元素都在3D场景内，所有材质均为定制，极致优化了内存。

可靠的降级方案。

覆盖面极广（10亿用户级），极低的闪退率。

SEIN.JS

说明： Web3D游戏引擎。
规模：超大
性质：公司项目
职位：项目负责人，负责内核开发，体系设计，跨BU合作项目管理，部分工具开发
进度：已开源，持续迭代中
使用技能：
图形学, 游戏引擎架构, Typescript, Unity, Unreal4, C#, Webpack, WebAudio......
项目源：一系列项目，比如Sein.js、SeinJSUnityToolkit和seinjs-gltf-loader等等...
惯例彩蛋：荒诞，艺术，存在
完成内容：

游戏引擎本体

空间音频系统、相机控制器、GUI等扩展系统(合作)和组件。

Unity扩展

CLI

一系列Webpack扩展Loader以及Plugin

VSCode扩展

Inspector

项目已经支持内部不少业务。

Paradise平台

说明：支付宝内部互动图形探索平台。
规模：大
性质：公司项目
职位：项目前后端负责人
进度：完成
使用技能：
Typescript，NodeJS，React, Mysql......
项目源：闭源
完成内容：

前端以及服务端，拥有各种复杂的逻辑，包括但不限于创建作品、自动创建仓库、绑定HOOK自动构建、审核、测试、CLI、Lottie和3D模型预览发布等等。

Bilibili圣诞音游《Jingle Beats》

说明： Bilibili圣诞音游《Jingle Beats》。
规模：大
性质：公司项目
职位：项目前端负责人、开发者、原案
进度：完成
使用技能：
PIXI.js, Typescript, WebGL, Tween，MUG、Touch Events......
项目源：Bilibili圣诞游戏剖析-用pixi.js实现鬼畜音游
完成内容：

一个HTML5的偏硬核音游，基于2D渲染引擎PIXI.js。

Bilibili七夕游戏《Double;7》

说明： Bilibili七夕游戏《Double;7》。
规模：大
性质：公司项目
职位：项目前端负责人、开发者、原案、制作进行
进度：完成
使用技能：
Egret, Typescript, WebGL, Tween......
项目源：egret-galgame
Bilibili《七夕之约 - Double;7》技术剖析
完成内容：

一个HTML5的Galgame，基于游戏引擎Egret，使用了陀螺仪、Websocket等技术，用技术为阿宅带来人文关怀。

BML2017主视觉

说明： BML2017主视觉。
规模：大
性质：公司项目
职位：项目前端负责人和开发者
进度：完成
使用技能：
Node.js, React.js, Typescript, Less, Webpack......
项目源：BML2017主视觉技术剖析
完成内容：

一个酷炫的主视觉，用到大量DOM动画和H5视频，PC和移动端双端适配，包含一个复杂的贴吧性质的讨论区。

Bilibili活动管理后台

说明：一个超大型复杂管理后台。
规模：超大
性质：公司项目
职位：核心开发者和架构者之一
进度：完成
使用技能：
Node.js, React.js, Redux, Express.js, ES6, Scss, Webpack......
项目源：闭源。
完成内容：

大型活动管理后台，包括一个复杂CMS，数据源聚合管理，权限系统和发布系统。
全栈开发，前端技术栈为React + Redux + React-router + Immutable，后端技术栈为Node + Express。

业余项目

Project 31

说明：三十一岁庆生短片。
规模：中
性质：严肃创作
职位：负责人，剧本，演出，后期
进度：完成
使用技能：写作，摄影，后期
完成内容：

我是「」，祝我三十一岁生日快乐，我的故事仍在继续

Project Destiny

说明：三十岁庆生微电影。
规模：中
性质：严肃创作
职位：负责人，剧本，演出，后期
进度：完成
使用技能：写作，摄影，后期
完成内容：

三十岁生日，我给自己拍了部微电影

Project Tomorrow

说明：独立游戏。
规模：大
性质：梦想
职位：负责人，剧本，程序，演出，出钱
进度：剧本创作
使用技能：写作，游戏开发，花钱
完成内容：

第二版剧本已完成，MVP版本创作中。

Awaken

说明：基于Hybrid方案和WebDAV的全平台开源阅读软件。
规模：中
性质：产品输出
职位：独立完成
项目源：
Awaken
使用技能：Hybrid,WebDAV,Android,iOS,Tauri,React
完成内容：

功能介绍：Awaken-开源跨平台多端同步阅读软件。
技术教程：Awaken-基于Hybrid方案和WebDAV的全平台开源阅读软件。

Project Love

说明： 29岁前交友企划，以及某种意义上的人生回顾。
规模：中
性质：记录
职位：创作
进度：完成
使用技能：写作，剪辑
完成内容：

公众号发文：Project Love
VLOG：某「非刻板印象INFP码农」的日常一天

Project Self

说明： 28岁自我记录企划。
规模：中
性质：记录
职位：需求定制，创作，演讲
进度：完成
使用技能：写作，花钱
完成内容：

写真集+文章：Project Self
个人访谈：访谈，公众号发文

WebGPU Renderer & Path Tracer

说明：一个基于WebGPU的渲染引擎，以及基于其实现的路径追踪渲染器，并产出了系列教程。
规模：中
性质：技术学习
职位：独立完成
进度：完成
项目源：
webgpu-renderer
Live Demo
使用技能： WebGPU, Typescript, 图形学
完成内容：

使用WebGPU实现了一个渲染器，包含绝大部分3D渲染功能。
利用渲染器，使用光栅化+计算着色器混合方式，实现了一个路径追踪渲染器，其中包括场景合并、BVH构建、射线求交、蒙特卡洛方法、BRDF、BSDF、降噪等。
产出了多篇系列教程：WebGPU实时光追美少女系列。

Double;14

说明：庆生用原创游戏。
规模：中
性质：生日纪念
职位：剧本，程序
进度：已完成
使用技能：
写作，编剧，Unity
项目源：闭源
完成内容：

游戏录屏：《Double;14》个人独立游戏小说版本： Double;14

gl-matrix-wasm

说明：将gl-matrix移植到WebAssembly。
规模：中
性质：技术输出
职位：独立完成
进度：完成
项目源：
gl-matrix-wasm
Live Demo
使用技能： Rust，WebAssembly
完成内容：

使用Rust + wasm-bindgen + wasm-pack技术栈。
提供分离、单JS两种形式。
包含完全的单元测试，以及完整的Benchmark。

D2-2017前端论坛嘉宾

说明：代表B站，在D2-2017前端论坛进行了分享，中心主题和PPT在这里：D2-现代前端-对视觉和交互的探索。
规模：中小
性质：分享
职位：独立完成
进度：完成
使用技能： PPT，演讲......

kanata

说明：一个纯前端实现、无依赖的图像处理库，纯TypeScript编写，并在计划WebAssembly的版本。
规模：中
性质：技术输出
职位：独立完成
进度：开发中
项目源：
kanata
Live Demo
使用技能： TypeScript，React.js，数字图像处理......
完成内容：

主要包含一个ImageCore和若干点操作、几何变换、直方图操作和局部滤波器。
本身支持单操作引用，设计上支持流式处理，为敏感的性能做了一些优化，优于市面上很多库。
目前已然实现了许多操作并搭好了测试框架、写了一部分测试，剩下的操作正在实现中。

hana-ui

说明：和两位队友一起实现的一个React UIKit，作为本项目的负责人，我设计项目框架，完成了项目开发、文档和DEMO的整体结构。除了设计，我也承担了相当的组件开发，在这个过程中我对React、工程化和样式的理解都大有进步。
规模：中
性质：技术输出
职位：独立完成
进度：已完成并在内部系统可用、部分外部系统可用，开源准备中。
项目源：
hana-ui
Homepage
惯例彩蛋：hana song
使用技能： React.js, ES6, Scss......

BlogReworkPro

说明：重构BlogRework，这是此Blog迎来的第四次重构了，和上一次的间隔比预期要早一些，不过这种事早点没啥坏处。这次重构主要是重写了前端、修了一些后端的BUG，跟进ES6，用Eslint和Flow约束代码规范，上了React最佳实践全家桶并且实现了完美的服务端渲染，加了Memory Cache，样式换成了less，DOM语义化也做了，构建工具也换成了gulp，也就是说，上一次遗留的Feature基本都搞定了。
规模：中小
性质：新技术学习实践
职位：独立完成
进度：完成
使用技能：
Python, Node.js, Flask, React.js, Redux, MongoDB, Express.js......
项目源：
BlogRewrokPro
【React/Flask】BlogReworkPro-Rework the BlogRework
【React/Redux/Router/Immutable】React最佳实践的正确食用姿势
 【React/Redux】深入理解React服务端渲染
 【Flask/React】此博客服务端的缓存实现
 【Less】实现可选参数以及各种autoprefixer
完成内容：

服务端渲染。

内存缓存。

资源优化。

SEO。

MoeNotes

说明： 正在使用Redux + RXJS重构。MoeNotes是一个简单的日记写作软件（当然，我也用其写一些不是特别复杂的小说和文章），不同于印象笔记、Onenote、Leanote等，它所要解决的问题仅仅是“本地展示”，也就是在本地管理你的日志文件，并提供一个类似于Onenote的分类体验。本软件使用Markdown作为笔记编写语言，每一篇日记都会以.md文件的形式保存到本地而不是数据库中，用户可以自行选择如何同步这些文章以及将它们同步到多少地方，完全不依赖于平台，这也是我编写本软件而不使用现成日记软件的一个主要的原因。当然，对文章和分类进行拖动排序也是被支持的。除此之外，本软件还支持“即写即看”，“专注写作”和“专注阅读”三种模式，也可以进行主题的切换和自定义，由于是基于web进行得开发，所以扩展起来也十分方便和简单。
规模：中
性质：造一个满足自己需求的轮子
职位：独立完成
进度：完成
使用技能：
Javacript, Node.js, React.js, Electron, HTML, CSS, Grunt, Webpack, Jasmine......
项目源：
MoteNotes
Github
完成内容：

本地文件树管理。

OneNote的分类体验，增强版Markdown支持。

即使预览、专注写作和专注阅读模式。

可定制主题。

BlogRework

说明：重构Blog为SPA。
规模：小
性质：新技术学习实践
职位：独立完成
进度：完成
使用技能：
Python, Node.js, Flask, React.js, MongoDB, Express.js, Jade, CSS......
项目源：
[Flask/React/MongoDB]BlogReworkIII-如何搭建一个动态Blog
BlogRewrok
完成内容：

扩展Markdown文章解析以及数据库管理。

后端Web服务器。

前端界面。

前端WEB服务器。

SEO。

主要项目（工作II）

激光雷达上位机

说明：用于展示激光雷达的3D数据，包括实时显示、数据录制、数据回放。
职位：负责人
进度：基本功能完成
使用技能：
JavaScript, C++, Python, Electron, Node.js, React, Three.js, HTML, CSS, Webpack, Grunt 项目源：闭源
完成内容：

整体功能分析，实现了UI的设计和所有功能的开发。

用Electron作为框架，使用web的方式开发了桌面应用。

编写了C++的Node.js扩展，提高了点云坐标系转换效率。

用Three.js完成了点云的绘制。

实现了数据、显示、控制的隔离，自己实现了事件驱动的设计，保证可维护性。

无人机甲烷监控数据可视化平台

说明：将后台数据库进行表格形式的显示，兼容WEB、iOS和安卓三个平台。
职位：负责人
进度：基本完成
使用技能：
JavaScript, Python, Flask, MySQL, HTML, CSS, PyJade, Node.js, React native, Object-C
项目源：闭源
完成内容：

开发基于Flask的后端以及使用PyJade模板进行网页显示

开发了一版Object-C编写的APP，用于熟练iOS底层。

用React native开发了iOS和安卓的APP。

设计了美观的UI。

PM25传感器数据监测平台

说明：接手项目，开发一个数据监测平台，收集不同地方的传感器传回的数据，进行记录和分析
职位：负责人之一
进度：正在进行
使用技能：
JavaScript，Node， React， MongoDB， Grunt， Python， HTML， CSS
平台：
OSX（开发），Ubuntu（部署）
项目源：闭源
完成内容：

开发基于Node.js的后端

开发基于React.js的前端，用Grunt管理。

包含数据库管理，数据下载，数据呈现等功能。

做了设计，美化了UI。

无人机定位

说明：寻找并实现无人机的一些定位方式
职位：负责人
进度：基本完成
使用技能：
Python
平台：
Windows（PC），Ubuntu（Ordroid）
项目源：闭源
完成内容：

差分GPS的研究和应用。

激光定位的研究和应用。

UWB定位的研究和应用。

主要项目（大学）

梦见星空之诗 - Aria der Freiheit und des Seins：

说明：原创游戏。
规模：超大
性质：梦想
职位：企划，监督，设定，剧本，程序
进度：长期规划，剧本重构中
使用技能（已经）：
哲学（半吊子），设定，写作，编剧，Python，Ren'py
使用技能（预定）：
Unity3d，编译器设计，FPGA设计，商学
项目源：闭源
完成内容：

游戏剧本解析器。

70万字剧本原稿。

游戏系统和界面（暂定）。

体三维显示器：

说明：一个分辨率较高的、由二维LED点阵旋转的三维显示器。
规模：大
性质：省级SRTP
职位：独立完成
进度：基本完成
使用技能：
PCB，FPGA，C，C#，Autocad
项目源：
控制，PCB，机械
完成内容：

学习Cadence套件，设计了一个由0603LED，PMOS，NMOS构成的120*114，密度为15.2d、cm^2的LED阵列；同时，完成了由触发器、锁存器、电源部分构成的此LED阵列的控制板，控制板为四层，走线密度较高。

学习使用FPGA，利用Altera的CycloneIV系列的器件，使用VHDL语言完成了：
1).DDR2控制器，完全由自己实现，并自己编写Testbench，利用Modelsim进行了批量数据验证，但缺少PHY的支持。
2).LED控制器，完全由自己实现，使用ROM进行了板上验证。
3).学习使用高速USB芯片cy68013，熟悉其slave-fifo模式，完成了它的FPGA控制部分，进行了板上验证。

学习使用C#语言，使用cy68013芯片的提供的. net下的API，完成了其上位机。

学习C语言，完成了cy68013的固件部分设计。

机械部分的设计，设计了底座、联轴器，以及LED阵列的装载板；使用Autocad设计。

基于Matlab的三维切片。

游戏剧本解析器：

说明：一个分离剧本和代码的解析器，用于将自己设计的DSL解析成Ren'py的脚本，提供扩展和输入插件。
规模：中
性质：个人项目
职位：独立完成
进度：基本完成
使用技能： Python，Ren'py
项目源： Gal2Renpy
完成内容：

学习使用游戏引擎ren’py和Python，了解了各自特性。

DSL的形式继承自xml语言，自己完成了标记语言的解析，以及与ren’py脚本的映射,同时提供给用户自行扩展的接口，具有良好的可扩展性。

Sublime的插件，方便输入。

FPGA Image Library：

说明：一个开源的FPGA图像处理库，将一些图像处理操作在FPGA上实现，每一个操作都会封装成一个模块，并拥有各自的软件测试与功能仿真，测试图片可以自由选取,并且设计为统一接口，流水化处理。
规模：大
性质：独立项目
职位：独立完成
进度： 1.0版本发布，由于工作原因暂时中断= =
使用技能： FPGA设计（Verilog, SystemVerilog），Python，图像处理
项目源： FPGA-Imaging-Library
完成内容：

灰度化，二值化，亮度和对比度变换。

彩色字符输出（任意字体）（暂停）。

帧控制器，行缓存生成器，窗口生成器。

窗口均值滤波，二值腐蚀膨胀，二值模板匹配，灰度腐蚀膨胀，排序滤波器。

Harris角点检测。

平移，缩放，镜像，裁剪，旋转，仿射变换。

预计加入直方图操作。

我的主页：

说明：一个用于记录自己学习经验的博客。
规模：小
性质：个人项目
职位：独立完成
进度：完成
使用技能 HTML，CSS，JS
项目源：不开源完成内容：

学习使用pelican(基于jinjia2)，学习css、html、js，在VPS上搭建。

一个面向教学的单周期MIPS CPU：

说明：一个MIPS CPU，单周期32bits，vivado搭建，模块化设计，设立了tcl文件简化预览。
规模：小
性质：实习项目
职位：独立完成
进度：完成
使用技能：FPGA设计, Verilog, Systemverilog, Python
项目源： SIMPLE_MIPS_CPU
完成内容：

完成了ALU, REGFILE, CONTRLO_UNIT, DATAPATH, INST_MEM, DATA_MEM模块的设计与随机测试，并将它们拼接，完成了用于功能仿真的CPU。

完成了KEY2INST, SHOW_ON_LED模块的设计与测试，将它们拼接于以上模块中，设计了一台按键编码，用于CPU的板上测试。

tcl文件的建立，用户可以在vivado界面写source tcl文件来快速建立工程。

其他

欲戴皇冠，必承其重。

一个人不可能被所有人理解，这几年遭受的攻击、嘲讽、中伤即从中来。

人要为其言论负责，表达的代价也即为此。

如此坚持的结果应有两种可能——倘若无悔，那将是无上的荣耀；倘若后悔，也将是深刻的戏谑。

但无论如何，这种种经历都会成为我一生的注脚。

当拥有了永恒的视角后，你可以选择入戏当演员去起舞，也可以选择出离来当个观众，但只有一点：

作为演员的时候，我们不可忘却愤怒。
作为观众的时候，我们不可忘却叹息。

我将倾尽所能去体验、去观测、去记录、去表达。
不能迷惘、不许后悔、不准遗憾、不计代价、不可回头。
直至肉身灭亡的一刻到来。

Awaken-基于Hybrid方案和WebDAV的全平台开源阅读软件

dtysky — Tuesday, 27 Dec 2022 23:33:00 -00:00

在本篇文章中，我将从技术选型开始，分享我在开发这个阅读软件过程中的一些经验和心得，也算是对个人技术道路的又一个路标。

前言

今年六月，亚马逊宣布Kindle将在次年退出中国市场，听到这个新闻的我开始寻找它的替代品，同时由于在思考后彻底失去了对内容平台的信任，我对这个替代品定了以下要求：

存储不依赖于平台。
能够跨平台和设备共享，要求支持桌面/安卓/iOS全端。
允许笔记和进度同步。
笔记协议开放，能够从Kindle导入。

带着这些要求寻觅了许久后，我并未找到完全满足的软件。作为一个合格的程序员，我便自然有了自己去实现它的想法，这同时也可以作为我的最终项目《Project Journey》预热。但由于事情太多同时离Kindle完全停止运营为时尚早，我并未立即开始这个项目，而再次启动它的契机，则是九月份的另一个项目。

在延续创作完去年的独立游戏《Project Tomorrow》的第二版剧本后，我陷入了美术的困境，为了避免一开始就把事情搞砸，我启动了一个另一个比较小的博客改版项目《Project Totem》来磨合和美术的相性，但很遗憾最终失败了（题外话也因此我打消了相当的找个美术对象、或者说合作伙伴对象的想法）。但无论现状如何，项目总要继续推进，于是我最终决定提高自己的艺术修养，让自己继程序、剧本后也成为美术总监把控全局，便于之后找外包。而这个设想前提则离不开读书，所以正好借这个机会完成这个读书软件。

我知道以上思维路径看起来很离谱，但我确实是这么想的。

从九月底开始，我便启动了这个命名为《Awaken》的项目，花了近两个月的业余时间，我终于将其完成。

项目开源在此：

https://github.com/dtysky/Awaken

功能介绍在此：

Awaken-开源跨平台多端同步阅读软件

技术选型

经过这么多年的开发，我逐渐明白了技术选型的重要性。看起来轻松的方案最后可能会踩更多的坑，而看起来麻烦的方案可能却是弯路最少的，反而会达到稳定和效率的平衡。技术选型的前提是需求，而由前言中提到的需求可得最影响决策的两个需求是——“同步”和“全平台”。

“同步”决定了C/S架构，继而需要考虑服务端存储和多端同步方案；而“全平台”则决定了客户端需要一种跨端方案。

服务端

一般来讲，服务端有两种选择：

像常见平台那样，服务端除了存储还接管同步逻辑，书库一开始就存在于服务端，用户只是去获取并将其拉取到客户端，而笔记、进度等也都由服务端处理同步后下发。
服务端只做存储，所有的同步逻辑交由客户端，书籍由客户端添加上传，笔记、进度也都在客户端运算。

第一种方案的优势是逻辑中心化，清晰简单，要处理的状况少，但代价就是需要一个独立的服务端，而且书库的维护可能要另外写逻辑。比较适合大平台，但不适合个人维护，尤其在国内这种动辄要备案的环境更是巨麻烦。

第二种方案的优势就是只需要一个远端存储方案，而代价就是逻辑是分布式的，状况比较多且复杂。这种方案也比较适合个人用户。

综合权衡后我选择了第二种方案，那么接下来的问题只有一个了——如何选择存储方案。这个没什么说的，我选了WebDAV：

WebDAV （Web-based Distributed Authoring and Versioning）一种基于 HTTP 1.1协议的通信协议。它扩展了HTTP 1.1，在GET、POST、HEAD等几个HTTP标准方法以外添加了一些新的方法，使应用程序可对Web Server直接读写，并支持写文件锁定(Locking)及解锁(Unlock)，还可以支持文件的版本控制。

目前国外支持WebDAV的网盘有不少，国内的话就坚果云吧，我也一直用的这个。

客户端

客户端的选型要比服务端复杂一些，不同于服务端只负责存储，客户端要负责整个软件所有的逻辑。倘若只是单个平台还没啥，但一旦涉及到跨端就麻烦了，主要考虑最终效果和开发成本两点：

不同平台分别实现，优点是最终性能肯定好上限高，代价是承受不起的开发成本。
Flutter，移动端效果应该不错，桌面端残废，开发效率中等吧。
ReactNative，emmm...不想再踩一次坑，桌面端也差不多残废。
Hybrid分层方案，在Webview跑的JS前端 + 客户端通过JSB/XHR拦截实现的后端，优点是能充分利用JS生态，代价是效果受到Webview约束，仍然要实现不同客户端的JSB拦截。

其实不用再多分析大家也能看出来了，综合效果和开发成本，只有第四种方案是可行的：Hybrid本身就是一种业界早已成熟的方案，没有太多坑，不会出现原理上难以解决的工程问题，而且能充分利用JS生态也省去了很多功夫，我是没兴趣为了这么个次要项目重新造一些轮子。

开发流程

在具体的实现前，需要先确定整个开发测试和构建的流程。

如图，这里我按照一个过时前端老人的习惯，选择了typescript作为主要开发语言，webpack作为构建工具，使用dev-server做为开发服务器，发布时稍微改动做下打包就行。同时为了在开发阶段测试webdav协议，我写了webdav.server.js在本地开了个服务。

代码本体在src下，interfaces中包括后端接口协议和书籍同步接口协议的定义，backend中是不同平台下后端的具体实现，frontend最后则是具体的前端逻辑。

platforms是不同平台下的项目工程。在开发阶段，我用dev-server开个支持hot-load的本地服务器，以不同平台的Webview打开本地Url来方便调试；在发布阶段，我将产物构建到三个平台工程的指定目录下，再以后续会提到的手段加载。

test中是提供测试的一些书籍和Kindle导出的笔记。

后端实现

客户端的后端部分主要负责通过一致的接口协议，将Native基础能力暴露给Webview前端使用。

在代码接口上，我在src/interfaces/IWorker中定义了接口协议，并在src/backend中在各端具体实现，同时在``

接口协议

分层设计最重要的是接口协议，我这里依照项目需求，设计了以下接口：

export type TBaseDir = 'Books' | 'Settings' | 'None';
export type TToastType = 'info' | 'warning' | 'error';

export interface IFileSystem {
  readFile(filePath: string, encoding: 'utf8' | 'binary', baseDir: TBaseDir): Promise<string | ArrayBuffer>;
  writeFile(filePath: string, content: string | ArrayBuffer, baseDir: TBaseDir): Promise<void>;
  removeFile(filePath: string, baseDir: TBaseDir): Promise<void>;
  readDir(dirPath: string, baseDir: TBaseDir): Promise<{path: string, isDir: boolean}[]>;
  createDir(dirPath: string, baseDir: TBaseDir): Promise<void>;
  removeDir(dirPath: string, baseDir: TBaseDir): Promise<void>;
  exists(filePath: string, baseDir: TBaseDir): Promise<boolean>;
}

export interface IWorker {
  fs: IFileSystem;
  loadSettings(): Promise<ISystemSettings>;
  saveSettings(settings: ISystemSettings): Promise<void>;
  selectFolder(): Promise<string>;
  selectBook(): Promise<string[]>;
  selectNote(): Promise<string[]>;
  showMessage(msg: string, type: TToastType, title?: string): Promise<void>;
  setBackground(r: number, g: number, b: number): Promise<void>;
  onAppHide(callback: () => void): void;
  getCoverUrl(book: IBook): Promise<string>;
}

接口的方法名都很明显了，不做过多解释。接下来要做的就是在各端实现这个IWorker接口。

桌面端

在桌面端，基于浏览器的方案有不少，比如最广为人知的Electron，还有类似的CEF等，其基本都是打包了一个Chromium进去，在开发简单、一致性强、兼容性强等优点下，也有安装包大小和内存开销等为人诟病的代价。

一开始我是准备直接用Electron的，但由于其只支持桌面，想偷懒的我便不由自主得想：“都2022年了，这么热衷造轮子的前端业界，不会还没有能直接跨所有端的方案吧？”虽然答案仍然确实是没有，但却意外发现了一个框架——Tauri。

Tauri是基于Rust和Webview的混合应用开发框架，其目前支持全桌面平台，并计划支持客户端（当然遥遥无期）。其优势是利用系统原生的Webview（不错桌面系统也有Webview），包体积很小并且内存开销会小一些，但相对代价就是很难利用Node生态，并且可能存在平台一致性问题，在某些低版本操作系统不支持。

经过权衡，最终我选择了Tauri，因为这个应用并不需要什么扩展逻辑，只需要基本的文件系统、提示、桌面选择器等等基本能力，而这些它都有官方支持。接下来，就让我们看看怎么在桌面端实现这个接口。

FileSystem

首先是接口中的文件系统，看到方法名便可以知道它们本质上就是对本地文件的存取。这个在Tauri中很简单，其官方提供的库@tauri-apps/api中就有相关能力，只需要将其引入并在tauri.conf.json中的tauri.allowlist中配置好fs的参数即可使用，比如：

import {fs} from '@tauri-apps/api';

async readFile(filePath: string, encoding: 'utf8' | 'binary', baseDir: TBaseDir) {
  const {fp, base} = processPath(filePath, baseDir);

  return encoding === 'utf8' ?
    fs.readTextFile(fp, base && {dir: base}) as Promise<string> :
    (await fs.readBinaryFile(fp, base && {dir: base})).buffer;
}

注意到baseDir这个参数，他指定了当前操作路径相对的目录，这里我用TBaseDir指定，Books表示用户指定的书籍目录，Settings 则是用户个人配置目录，None代表传入绝对路径。当然这些目录在不同平台下的表现不一致，在桌面端由于能够允许用户自己指定文件夹，所以Books是用于配置的，Settings则是appDir。

其他接口

文件系统之外就是其他接口了，其中：

loadSettings和saveSettings只是存取Settings/settings.json文件。
selectFolder、selectBook、selectNote和showMessage都可以用@tauri-apps/api中的dialog模块解决，前三个是dialog.open，最后一个是dialog.message。
setBackground和onAppHide在桌面端是不必要的。
getCoverUrl本质上是一种优化，这个会在前端部分说明。

安卓端

不同于桌面端Tauri帮我们搞定了大部分事情，移动端就要麻烦不少，安卓和iOS要去分别手动实现JS到客户端的绑定，不过好在如开头所说这个选型是比较稳健的，踩了点坑还算顺利。

安卓的我用的是Kotlin，写起来没Java那么啰嗦，它的Webview用起来是比较简单的，JSBridge通过addJavascriptInterface方法配合@JavascriptInterface注解即可添加：

// 定义JSB
class AwakenJSB {
  @JavascriptInterface
  fun setBackground(r: Double, g: Double, b: Double) {
    ......
  }
}

// 注册JSB
webView?.addJavascriptInterface(jsb!!,"Awaken")

很简单是吧？那么看起来我们只要通过这个JSB实现下文件之类的接口，也没多麻烦的样子？一开始我也是这么想的，但做起来后却发现没这么简单。

文件系统

JSB有个很大的问题是它只能传输基本类型，也就是数字、字符串之类的，而不能传输二进制数据。但对于这个软件来说，电子书和封面都是二进制数据，如果全部都走JSB的话，只有一招——在一端把二进制数据转base64，到了另一端再转回来。

虽然理论上这没啥问题，对于绝大部分书籍而言（1M以内）转换的开销对于客户端或者V8 JIT加持下的JS绰绰有余，但每次都这么转一下对于我而言是难以接受的——即使到现在，我还是有那么一些完美主义倾向。

那么是否存在一种方式，能够在双端不经转换地传输二进制数据呢？仔细想想，“由前端和其他端互相传输二进制数据”，这不就是XHR或者说fetch吗？至此，我的思路便从“如何用JSB传输二进制数据”变成了“如何拦截XHR”。

在稍许调研后，我便找到了安卓Webview提供的官方拦截方法：

webView.webViewClient = object: WebViewClient() {
  override fun shouldInterceptRequest(view: WebView?, request: WebResourceRequest?): WebResourceResponse? {
    ......
  }
}

我们可以从request最后拿到请求的url，然后拆分出host、path和query，进入下一步操作：

if (url.host.equals("awaken.api")) {
    var method: String = url.path.toString().substring(1)
    var params: MutableMap<String, String> = mutableMapOf(
        "method" to request.method
    )
    url.queryParameterNames.forEach {
        params[it] = url.getQueryParameter(it).toString()
    }

    return jsb!!.callMethod(method, params, requestHeaders)
}

这里我以awaken.api作为此类特殊接口的host标识，以path作为请求的方法名，以query传递参数，一次接口调用转换为请求如下：

fetch(`http://awaken.api/${method}?${query}`, {
  method: data ? 'POST' : 'GET',
  body: data
});

识别到此类请求后，客户端会调用jsb示例（直接复用了上面提到的JSB类）对应的方法，进行处理：

fun callMethod(
    method: String,
    params: Map<String, String>,
    origHeaders: Map<String, String>
): WebResourceResponse {
  val headers = HashMap<String, String>()
  headers["Access-Control-Allow-Origin"] = "*"
  headers["Access-Control-Allow-Methods"] = "*"
  headers["Access-Control-Expose-Headers"] = "X-Error-Message, Content-Type, WWW-Authenticate"

  try {
    处理实际逻辑......
    return WebResourceResponse("", Charsets.UTF_8.toString(), 200, "OK", headers, stream)
  } catch (error: Exception) {
      headers["X-Error-Message"] = error.message.toString()
      return WebResourceResponse("application/json", "utf-8", 200, "Error", headers, ByteArrayInputStream(ByteArray(0)))
  }
}

这里要注意我在返回的headers中都写入了允许跨域，这实际上也是为了解决后面章节的问题，而其中的X-Error-Message这个字段是为了返回错误，至于为什么么...因为iOS中的拦截无法返回自定义状态信息，安卓也只能跟着搞了。

至于实际上的文件存取逻辑没什么好说的，查一下API就完了，唯一值得一提的点是我将用户文件都存在了context.getExternalFilesDir(null)!!.toPath()取得的扩展外部存储中。

按理说到这了，文件系统应该OK了吧？既满足了需求，又能够避免base64转换，简直完美！那我只能说太天真了。在实现过程中我很快就遇到了麻烦——我无法获取到POST请求的body。并且在深度搜索的最后，也只找到了一个社区给谷歌在19年提的Issue，他们说在考虑支持然后就...没有然后了。

所以虽然很不甘心，我最终也只能做了个特殊处理——如果是安卓平台并且是writeFile接口，还是走JSBridge，也就是说在写入的情况下，二进制数据还是要经历 encodeBase64 -> 传到客户端 -> decodeBase64 的过程，具体的逻辑就不多说了也很简单。

不过最终综合来看，从前端向客户端写入二进制数据的状况只有在添加书籍时，这在移动端是个非常低频的操作，远低于读取，而读取的优化是不受这个影响的，整体仍然很赚。

其他接口

其他接口的实现就是完全通过JSBridge了，其实也没什么好说的，简单提一下吧。

首先是showMessage这个接口，实际上就是利用了客户端的AlertDialog：

// 定义
mAlertDialog = AlertDialog.Builder(mContext)
mAlertDialog.setPositiveButton("OK",
    DialogInterface.OnClickListener { dialog, which -> dialog.cancel()}
)
mAlertDialog.setNegativeButton("Close",
    DialogInterface.OnClickListener { dialog, which -> dialog.cancel()}
)

// 调用
mAlertDialog.setTitle(title)
mAlertDialog.setMessage(message)
mAlertDialog.show()

而select系列就稍微有点麻烦了，实际上是实现了一个通用的selectFiles接口：

@JavascriptInterface
fun selectFiles(title: String, mimeTypes: String) {
    var res: Array<String> = arrayOf()
    mContext.selectFiles(mimeTypes) {
        res = it
        mContext.mainWebView?.evaluateJavascript(
            "Awaken_SelectFilesHandler(${JSONArray(res)})",
            ValueCallback {  }
        )
    }
}

首先注意这里的evaluateJavascript，这是因为JSBridge都是同步调用，但这里面实际上执行了一个异步操作，所以为了通知前端，我执行了一个全局的JS方法Awaken_SelectFilesHandler，而对应于前端则会在调用JSB方法前设置这个全局方法的值。

而这里之所以会调用主activity的接口然后回调，主要是因为安卓机制上的限制——唤起文件选择菜单实际上是启动另一个activity，而我们需要重写主activity的onActivityResult方法，来获取结果：

fun selectFiles(
    mimeTypes: String,
    callback: (files: Array<String>) -> Unit
) {
    selectFilesCallback = callback
    val intent = Intent(Intent.ACTION_OPEN_DOCUMENT).apply {
        addCategory(Intent.CATEGORY_OPENABLE)
        type = mimeTypes
        putExtra(Intent.EXTRA_ALLOW_MULTIPLE, true)
    }

    // 唤起菜单，指定状态码为4
    startActivityForResult(intent, 4)
}

// 
override fun onActivityResult(requestCode: Int, resultCode: Int, resultData: Intent?) {
    if (requestCode == 4) {
        // 处理状态码为4的结果
        ......
    }

    super.onActivityResult(requestCode, resultCode, resultData)
}

剩下的就是onAppHide方法可以监听主activity的onPause周期，然后用evaluateJavascript执行一个全局JS方法即可；setBackground方法在安卓端并不需要，取而代之的是隐藏安卓的虚拟按键，这个本质上就是隐藏ActionBar并进入全屏模式，代码自己看吧没啥特别要注意的。

iOS端

iOS的接口思路和安卓是完全一致的，不过由于平台差异，实现起来还是有些不同。由于实在不想写OC了，这里我选择的是Swift顺便带上swiftui，同时为了JIT的性能用的是WKWebView。和安卓类似，我同样需要注册JSBridge和进行XHR拦截，这里先说JSBridge，XHR拦截就完全交给文件系统一节吧。

WKWebView的JSBridge注册也很简单，首先我们要定义一个实现了WKScriptMessageHandler协议的类AwakenJSB，然后将其实例注册即可：

// 实现JSB
public class AwakenJSB: NSObject, WKScriptMessageHandler, WKUIDelegate {
  init(onChangeBg: @escaping (_ color: CGColor) -> ()) {
    ......
  }
}


// 以下代码在`swiftui`对应实现`UIViewRepresentable`协议的`WebView`类中
// 实例化JSB
let jsb = AwakenJSB(onChangeBg: onChangeBg)

// 初始化JS脚本
initJS = """
window.Awaken = {
    getPlatform() {
        return 'IOS';
    },
    showMessage(message, type, title) {
        window.webkit.messageHandlers.showMessage.postMessage({title: title, message: message, type: type || ''});
    },
    selectFiles(title, types) {
        window.Awaken.showMessage("iOS设备不支持导入本地书籍，请使用其他平台操作", "error", "");
        window.Awaken_SelectFilesHandler([]);
    },
    setBackground(r, g, b) {
        window.webkit.messageHandlers.setBackground.postMessage({r: r, g: g, b: b});
    }
}
"""

// 初始化WebView
let config = WKWebViewConfiguration()
...一些初始化逻辑
let wkWebView = WKWebView(frame: .zero, configuration: config)

// 注入初始化脚本
config.controller.addUserScript(WKUserScript(source: initJS, injectionTime: .atDocumentStart, forMainFrameOnly: true))
// 注册JSB
config.controller.add(self, name: "showMessage")
config.controller.add(self, name: "setBackground")

onChangeBg回调这里暂时无需在意，其他除了流程和安卓大差不差，唯一有显著区别的就是initJS了，这是一段会在WKWebView加载完html、执行用户js前注入的一段js代码。可以看到其实际上给全局挂载了一些方法，而这些方法在安卓中是直接用@JavascriptInterface注解实现在JSB类中的。再看每个方法的实现，除了iOS无法实现文件选择外导致无效的selectFiles外，都有个调用window.webkit.messageHandlers.xxxx.postMessage，这是因为WKWebView只支持前端和客户端的异步通信，只能这么搞，好在这几个接口基本都不需要返回值，随便搞搞就行了。在js中postMessage后，我们还需要在客户端稍微处理下：

public func userContentController(_ userContentController: WKUserContentController, didReceive message: WKScriptMessage) {
    if (message.name == "showMessage") {
        let params = message.body as! [String: String]
        showMessage(message: params["message"]!, type: params["type"]!, title: params["title"]!)
    } else if (message.name == "setBackground") {
        let params = message.body as! [String: Double]
        setBackground(r: params["r"]!, g: params["g"]!, b: params["b"]!)
    }
}

Swift是我写过的第二啰嗦的语言，苹果的API设计不敢恭维，XCode就是依托答辩。

文件系统

iOS端的XHR拦截的方式和安卓大同小异，不过这API搞起来虽然蛋疼，但人家却支持了获取request的body...要我说你两就不能合计合计整个完全体吗？

不吐槽了...来看看怎么搞吧，iOS提供了WKURLSchemeHandler协议来为WKWebView提供XHR拦截：

// 实现协议的类
public class AwakenXHRHandler: NSObject, WKURLSchemeHandler {
    // 请求开始
    public func webView(_ webView: WKWebView, start urlSchemeTask: WKURLSchemeTask) {
        ......
    }

    // 请求结束
    public func webView(_ webView: WKWebView, stop urlSchemeTask: WKURLSchemeTask) {
        ......
    }
}

// WKWebView的那个`config`，注册拦截器，传入`jsb`只是为了和安卓一样复用JSB类实现逻辑
config.setURLSchemeHandler(AwakenXHRHandler(jsb: jsb), forURLScheme: "awaken")

这里特别要注意的、和安卓不同的是forURLScheme这个参数，它指定了一个请求的schema，因为理论上iOS不允许开发者拦截WKWebView的标准协议，类似http/https等等，所以这里我必须指定一个自定义的awaken，实际请求时为：

fetch(`awaken://awaken.api/${method}?${query}`, {
  method: data ? 'POST' : 'GET',
  body: data
});

不过在安卓上用自定义schema请求会报错，也是够麻烦的。

由于WKWebView允许获取拦截到的请求的body，所以也不用像安卓那样麻烦地去搞什么base64转换了：

let request = urlSchemeTask.request
guard let requestUrl = request.url else { return }
var method = requestUrl.path
method = method == "" ? method : String(method[method.index(method.startIndex, offsetBy: 1)...])
var params: [String: String] = [:]
let components = URLComponents(url: requestUrl, resolvingAgainstBaseURL: true)
let queryItems = components?.queryItems;
if (queryItems != nil) {
    params = queryItems!.reduce(into: [String: String]()) { (result, item) in
        result[item.name] = item.value
    }
}
let body = request.httpBody

取得了method和params后，就可以正常处理请求并返回了，这个并没有什么麻烦的，感兴趣可以直接去项目看代码，唯一值得说道的下面几点：

其一，如何获取用户目录：

let paths = NSSearchPathForDirectoriesInDomains(
    .documentDirectory,
    .userDomainMask,
    true
);
mBaseDir = URL(fileURLWithPath: paths.last!, isDirectory: true)

其二，如何返回response。一般的教程中都会说返回URLResponse，但这个无法自定义状态码和headers，无法满足需求，在调研后我最终找到了HTTPURLResponse：

let response = HTTPURLResponse(url: requestUrl, statusCode: 200, httpVersion: nil, headerFields: headers)

其他接口

和安卓相同，其它接口都是通过JSBridge实现的。

首先是showMessage这个接口，得益于iOS的天才API设计和每升一个版本就相当于另一门语言的swift，恕我懒得搞清楚它背后做了什么，直接用吧：

func showMessage(message: String, type: String, title: String = "") {
    let alert = UIAlertController(title: title, message: message, preferredStyle: UIAlertController.Style.alert)
    alert.addAction(UIAlertAction(title: "确定", style: UIAlertAction.Style.default, handler: nil))

    UIApplication
        .shared
        .connectedScenes
        .flatMap { ($0 as? UIWindowScene)?.windows ?? [] }
        .first { $0.isKeyWindow }?
        .rootViewController?
        .present(alert, animated: true, completion: nil)
}

然后是onAppHide，这个也很简单，我们首先要让AwakenJSB持有WKWebView实例，然后配合NotificationCenter实现：

public func setWebview(webview: WKWebView) {
    self.webview = webview
    NotificationCenter.default.addObserver(self, selector: #selector(didEnterBackground), name: UIScene.didEnterBackgroundNotification, object: nil)
}

@objc func didEnterBackground() {
    webview?.evaluateJavaScript("window.Awaken_AppHideCB && window.Awaken_AppHideCB()")
}

最后就是setBackground了，这个在安卓中无用，但对于大部分都是刘海异形屏的iPhone，还是很有必要的——我们需要将WKWebView放在Safe Area，顶部和底部保证和WebView的背景色一致，而这一点我最终的做法是利用swiftui的特性：

struct ContentView: View {
    @State var bgColor: CGColor = CGColor(srgbRed: 1, green: 1, blue: 1, alpha: 1)

    var body: some View {
        ZStack() {
            Color(bgColor)
                .frame(minWidth: 0, maxWidth: .infinity, minHeight: 0, maxHeight: .infinity)
                .background(Color.red)
                .edgesIgnoringSafeArea(.all)
            WebView(
                onChangeBg: changeBgColor
            )
        }
    }

    func changeBgColor(color: CGColor) {
        bgColor = color
    }
}

在UI的根节点，我在底层放了一个全屏的Color控件来铺满背景，然后在上面放上自定义的WebView控件，并利用onChangeBg这个回调来修改控件的bgColor属性，最终影响到Color的颜色。而进一步，我们再将其传入一开始定义给AwakenJSB传入的那个onChangeBg回调，最终在JSB类中实现功能

func setBackground(r: Double, g: Double, b: Double) {
    mOnChangeBg(CGColor(srgbRed: r, green: g, blue: b, alpha: 1))
}

webdav跨域

至此，三端的后端接口都实现完毕，理论上为前端实现扫平了障碍，但在实际的开发中却还是遇到了因Web方案带来的麻烦，其中最大的一个就是跨域问题。

众所周知浏览器对于跨域资源是有CORS来限制的，这本质上是为了内容安全，无可厚非。但对于webdav这种协议，尤其是用户购买的私有服务，跨域本就不应该是障碍，而实际上很多厂商包括坚果云确实也没做这个限制。一开始我在用本地webdav-server和webdav-client这两个开源库调试的时候，也遇到了跨域问题，但在大量搜索后认为是server的实现不标准，对其进行了魔改后凑合开发，但最终实际环境测试时仍然绕不过这个问题。为此我还专门联系了坚果云的开发人员，而他们的答复也很简单：“我们实现的是标准的WebDAV服务端协议”。

好了扯了这么久，困扰我的这个问题究竟是什么呢？其实很简单：对于非简单的跨域请求，浏览器在发送真正的请求前会先发送一个名为preflight的OPTIONS请求，来保护不知晓CORS的老服务器，只有这个请求成功后才允许发出真正的请求。

听起来很合理对吧？对于大多请求时没毛病，但问题在于webdav服务是有账号密码验证的，而preflight请求是不会携带验证信息的，而大多“按照标准实现”的WebDAV服务器在校验前并不会区分你是不是preflight请求...这TM就死锁了。

那怎么办呢？没啥办法，既然浏览器的限制绕不过去，就只能借由客户端了，毕竟客户端并没有CORS。如此一来，就不得不给我们上面提供的XHR拦截多加个方法了。不过这块处理起来，比上面那些接口要更复杂一些。

前端拦截

首先因为是用的开源库（我这么懒显然不想去拉一份下来自己改），所以只能看有没有hook的方案，而这时候选择Hybrid方案的优点就体现出来了——轮子多。我使用了ajax-hook库来在前端拦截XHR，将所有webdav请求都加上了一个prefix来协助拦截：

export const DAV_PREFIX = 'http://AwakenWebDav:';

proxy({
  onRequest: (config, handler) => {
    if (!config.url.startsWith(DAV_PREFIX)) {
      return handler.next(config);
    }

    const url = config.url.replace(DAV_PREFIX, '');
    ...接下来的代理操作
});

hook住XHR后，接下来就是在不同平台实现请求代理了。

桌面后端

首先是桌面端，在上面接口的实现中，桌面对文件系统并不依赖与XHR拦截，所以这里要额外想怎么实现。好在Tauri官方已经给我们准备好了由rust实现并绑定好的http模块。

首先在tauri.conf.json的tauri.allowlist中配置：

"http": {
  "all": true,
  "request": true,
  "scope": [
    "https://**",
    "http://**"
  ]
}

随后在代码中简单实现即可：

// 引入
import {http} from '@tauri-apps/api';

// 实现代理
http.fetch(url, {
  method: config.method as any,
  body: config.body ? (typeof config.body === 'string' ? http.Body.text(config.body) : http.Body.bytes(config.body)) : undefined,
  headers: config.headers,
  responseType: /(png|epub)$/.test(url) ? http.ResponseType.Binary : http.ResponseType.Text
}).then(res => {
  handler.resolve({
    config: config,
    status: res.status,
    headers: {},
    response: res.data
  });
}).catch(error => {
  handler.reject(error);
});

安卓后端

移动两端做法基本一致，为前面的XHR拦截协议新增方法webdav，然后将真正请求的url作为请求的参数传入客户端即可：

if (config.body && platform === 'ANDROID') {
  const isBase64 = typeof config.body !== 'string';
  const data: string = isBase64 ? atob(config.body as ArrayBuffer) : config.body;
  jsb.setWebdavRequestBody(url, config.method, data, isBase64);
}

fetch(`${API_PREFIX}/webdav?url=${encodeURIComponent(url)}`, {
  method: config.method,
  body: config.body,
  headers: config.headers
}).then(res => {
  const errorMessage = res.headers.get('X-Error-Message');
  if (errorMessage) {
    throw new Error(`${errorMessage}: webdav(${url})`);
  }

  return (/(png|epub)$/.test(url) ? res.arrayBuffer() : res.text()).then(data => {
    handler.resolve({
      config: config,
      status: res.status,
      statusText: res.statusText,
      headers: res.headers,
      response: data
    });
  });
}).catch(error => {
  console.error(error);
  handler.reject(error);
});

但在最后的处理中双端还是有一些差异：

首先安卓端由于前面说过的原因，需要将二进制body转换为base64，所以在客户端需要实现一个JSB接口setWebdavRequestBody，在请求前将转好的base64发给客户端，这个在上面的代码也有所体现。接下来在客户端只需要将请求的url作为key，把base64存到一张Map中，后续接收到请求取出处理即可，无序赘述。

其次就是请求代理的本质是将从Web拦截下的请求由客户端发出，再将结果返回Web。而客户端发出请求时，应当带上原先请求的headers和body，很遗憾我并未在安卓的官方API找到能满足需求的接口，所以最终我使用了okhttp3这个库：

fun webdav(url: String, method: String, headers: Map<String, String>): okhttp3.Response {
    val request = okhttp3.Request.Builder().url(url)
    val cache = mWebdavRequestCache[method+url]

    if (cache == null) {
        request.method(method, null)
    } else {
        if (cache.second) {
            request.method(method, Base64.decode(cache.first, Base64.DEFAULT).toRequestBody())
        } else {
            request.method(method, cache.first.toRequestBody())
        }

        mWebdavRequestCache.remove(method+url)
    }

    headers.forEach {
        request.addHeader(it.key, it.value)
    }

    return client.newCall(request.build()).execute()
}

吐槽一下kotlin、gradle这些工具和依赖他们的库之间的各种依赖冲突真是蛋疼。

iOS后端

iOS这边比起安卓要更简单一些，其原生的URLRequest就可以满足需求了，在上面的XHR拦截入口前加上一个分支即可：

if (method == "webdav") {
    let url = URL(string: params["url"]!)!
    let session = URLSession.shared
    var req = URLRequest(url: url)
    req.httpMethod = request.httpMethod
    req.httpBody = body
    req.allHTTPHeaderFields = request.allHTTPHeaderFields
    let task = session.dataTask(with: req, completionHandler: {[weak self] data, response, error in
        guard let strongSelf = self else { return }
        if (error != nil) {
            strongSelf.postFailed(to: urlSchemeTask, error: error!)
        } else if (data != nil) {
            var res = (response as! HTTPURLResponse)
            var headers: [String: String] = [
                "Access-Control-Allow-Origin": "*",
                "Access-Control-Allow-Methods": "*",
                "Access-Control-Expose-Headers": "X-Error-Message, Content-Type, WWW-Authenticate"
            ]
            strongSelf.postResponse(to: urlSchemeTask, response: HTTPURLResponse(
                url: requestUrl, statusCode: res.statusCode,
                httpVersion: nil, headerFields: headers
            )!)
            strongSelf.postResponse(to: urlSchemeTask, data: data!)
            strongSelf.postFinished(to: urlSchemeTask)
        }
    })

    task.resume()
    return
}

前端实现

前端逻辑主要是书籍和笔记的管理与同步，堆业务逻辑嘛懂得都懂，无非都是说难也不难，说简单却也坑多有些麻烦。所以这里我不会说太多细节，只会捡重点说一些心得。

为了加快开发效率（其实是懒），这里我选择了以前用惯了的React作为前端框架，样式用SCSS配合css-modules，并配合17年在B站用爱发电期间和同事一起开源的hana-ui，效果还行吧。

已经两年多没写正儿八经的前端代码了，有些手生，第一次用hooks玩不太转，而且也懒得用什么状态管理库了硬莽，不得不服老啊...嘛...又不是不能用。

书籍管理

首先是书籍管理，也就是维护书籍列表，这也是软件刚进去的首页。

协议

要维护书籍，首先就需要定义好书籍的数据结构：

export type TBookType = 'EPUB';

export interface IBook {
  hash: string;
  type: TBookType;
  name: string;
  author: string;
  ts: number;
  removed?: boolean;
  cover?: string;
}

这里面最重要的是hash，它是电子书本身的md5，保证了书籍的唯一性，之所以特意算一遍hash是因为书籍本身可能重名而且也不一定都有ids元数据。在实际的存储中，我会给每本书籍创建一个以hash命名的目录，将具体内容存于其中。

type是书籍类型，之所以有这个的理由你应该猜到了...不错，一开始我想支持EPUB/PDF/MOBI等多种书籍格式，但最后发现太麻烦不值得花这么多精力就只剩EPUB了（没事毕竟我们还有针对PDF的OCR和转换神器calibre嘛...又不是不能用。

name和author是从电子书提取的书名和作者，没啥好说的。ts记录的是书籍被修改的（添加/删除）的时间戳，配合removed在同步时使用，毕竟咱没有中心服务器处理逻辑，为了避免同步错乱没啥办法。

最后一个cover是从书籍中提取的封面，方便首页展示。我在添加书籍时，会将封面的二进制数据提取出来存到书籍目录下，之后在每次软件启动拿到书籍信息后，会根据当前平台自动生成一个cover地址。

在桌面端，我们需要在tauri.conf.json中的tauri.protocol字段中进行配置，允许软件访问用户本地文件：

"protocol": {
  "asset": true,
  "assetScope": [
    "**"
  ]
}

之后利用接口转换地址即可：

import {tauri} from '@tauri-apps/api';

getCoverUrl(book: IBook): string {
  return tauri.convertFileSrc(`${BOOKS_FOLDER}/${book.hash}/cover.png`);
}

而在移动端就简单了，复用之前实现过的文件接口协议即可：

getCoverUrl(book: IBook): string {
  return `${API_PREFIX}/readBinaryFile?filePath=${book.hash}/cover.png&base=Books`;
}

同步

书籍列表的同步从原理上其实挺简单的，但要处理的边界情况稍微会有点麻烦，其本质上可以规约为：

拉取远端列表 -> 和本地列表对比 -> 拉取远端新增书籍 -> 上传本地新增书籍 -> 同步列表目录

具体的逻辑就不写了，有兴趣的可以自己去看代码。这里值得特别说明的有几点：

首先是书籍冲突，其原因很简单，因为本方案没有一个中心的逻辑服务器，逻辑是分布在各个设备单独处理的，同时添加本地书籍并不需要联网，这就可能导致各端分别添加了同样的书籍，然后一并同步到远端的状况，这又会带来两个可能的问题：

本地尚未上传的书籍已然存在于远端。这个问题从设计层面被解决了：因为书籍的唯一性由hash决定，一般来讲不会碰撞，所以这里不涉及到状态。
两个设备同时将本地书籍同步到远端。这个问题是切实存在的，理论上来讲可以通过webdav协议的lock方法解决，但考虑到实际会这么操作的可能性很低（喜欢在日常中COS测试工程师的用户不在其中，我也没义务考虑），所以就这么办吧，不处理。

其次是书籍的删除，同样是由于没有中心服务器的缘由，书籍的删除变得非常麻烦。我不能直接把条目移除覆盖到远端，这样会导致有两个设备都存在统一条目的情况下永远删不掉。所以我退而求其次，即便是删除了也保留条目，然后用书籍协议中的removed和ts字段，选择时间戳比较近的，然后判定是否被删除：

const syncToLocalBooks: IBook[] = [];
remoteBooks.forEach(book => {
  const localBook = localTable[book.hash];
  if (
    (localBook && (book.ts > localBook.ts)) ||
    (!localBook && !book.removed)
  ) {
    syncToLocalBooks.push(book);
  }
});

const syncToRemoteBooks: IBook[] = [];
books.forEach(book => {
  const remoteBook = remoteTable[book.hash];
  if (
    (remoteBook && (book.ts > remoteBook.ts)) ||
    (!remoteBook && !book.removed)
  ) {
    syncToRemoteBooks.push(book);
  }
});

最后是错误处理，由于我的设计中支持批量添加书籍，那么在中途任一环节被异常中断都是可能的。这个为了避免状况复杂化，我的选择是：直接退出，下次同步时直接重新处理，对远端直接覆盖上传。严格来说这样确实不是最优解，但本身就是低频操作，代价也还行吧。

EPUB解析阅读

在书籍列表点击任一封面后，进入的就是阅读界面了。这里我使用了epub.js这个开源库，虽然文档一般坑不少，但却是能解决绝大多数的问题，至少不用从头去再造轮子了。

这一部分吧...虽然算起来是前端最复杂的一部分，也搞了挺久，但其实也没有太多好说的，大部分看epub.js的文档就OK，值得重点提的几个地方：

首先初始化，对书籍的初始化大致逻辑如下：

const book = ePub(props.content);
rendition = book.renderTo('epub-viewer', {
  width: '100%',
  height: '100%',
  stylesheet: props.bookStyle,
  allowScriptedContent: true,
  allowPopups: true
});

这其中要注意的是allowScriptedContent和allowPopups的设置，由于epub.js使用iframe的sandbox模式渲染，所以要启用所有功能必须开启。而stylesheet会在下面的主题切换一节说到。

其次是分页，众所周知页码是用来分割传统书籍的内容的，而EPUB这种电子媒介中并没有这个东西。对于Kindle而言，页码其实是一种额外信息，由亚马逊特别处理还原传统书籍照顾读者习惯或者方便引用。而我显然是拿不到这种信息的，所以只能按照业界一般的估计，以600字每页来分割书籍，这自然是一种不严谨的做法，但也凑合吧：

const pages = await book.locations.generate(600);

这样看起来似乎OK了，但如果只是这样，你会发现每次进入阅读都会很慢，因为生成页码是个非常耗时的操作。好在epub.js提供了一个口子，我们只需要生成一次pages，然后将其存下来，之后每次进入时读取即可：

// 存储分页数据
async savePages(book: IBook, pages: string[]) {
  return await bk.worker.fs.writeFile(`${book.hash}/pages.json`, JSON.stringify(pages), 'Books');
}

// 加载已存在的分页数据
book.locations.load(pages);

有了分页，自然就要考虑页面跳转，但这个其实没有这么简单。如果用户已经体验过阅读模式，可以知道页面的跳转有以下几种：

上一页/下一页：通过键盘左右，或者点击左右空白处。
进度条：拖动或者点击进度条，快速跳转。
目录跳转：在目录界面，点击章节标题跳转。
笔记/书签跳转：和目录类似，不过是点击笔记或书签列表。

而这些跳转，都是通过一个函数实现的：

const jump = (action: EJumpAction, cfiOrPageOrIndex?: string | number | IBookIndex) => {
  if (action !== EJumpAction.Page) {
    rendition.on('relocated', updateProgress);
  }

  if (action === EJumpAction.Pre) {
    rendition.prev();
    return;
  }

  if (action === EJumpAction.Next) {
    rendition.next();
    return;
  }

  if (action === EJumpAction.CFI) {
    // first, jump to chapter
    rendition.display(cfiOrPageOrIndex as string).then(() => {
      // then, jump to note
      rendition.display(cfiOrPageOrIndex as string);
    });
    return;
  }

  if (action === EJumpAction.Index) {
    rendition.display(idToHref[(cfiOrPageOrIndex as IBookIndex).id]);  
    return;
  }

  if (action === EJumpAction.Page) {
    rendition.display(rendition.book.locations.cfiFromLocation(cfiOrPageOrIndex as number));
    return;
  }
};

函数开头的relocated方法监听，是为了在进度跳转后，向上一级同步页数。下面就是根据不同状况做的区分处理了：

Pre和Next：针对普通切页操作，直接使用prev()和next()方法切换页面，这里不能用生成的页码是因为针对不同设备和画布，一屏显示的内容并不对应一页。
Index：针对目录索引，idToHref可以通过book.loaded.navigation处理得到。
Page：针对通过进度条修改的页码，可见是转换到CFI处理。
CFI：这个比较特别，将在下一节详细论述。

笔记、书签和进度

这一部分的逻辑算是阅读部分最为复杂的，由于需要同步，所以和上面的书籍列表同步有相似的问题，但由于需要注意顺序，状况更多更麻烦一些。

协议

首先还是要定协议，看下面两个接口：

export interface IBookNote {
  cfi: string;
  start: string;
  end: string;
  page: number;
  text?: string;
  annotation?: string;
  // timestamp
  modified: number;
  removed?: number;
}

export interface IBookConfig {
  ts: number;
  lastProgress: number;
  progress: number;
  bookmarks: IBookNote[];
  notes: IBookNote[];
  removedTs?: {[cfi: string]: number};
}

其中IBookConfig是每本书的配置文件，存于目录的config.json中：ts是更新时间戳，progress是本地进度，lastProgress是远端最新进度，这三个配合起来可以做进度同步。bookmarks和notes分别是书签和笔记列表，removedTs则是为了解决笔记的删除问题，无奈下特意的一个优化用对象。

IBookNote则是笔记或书签的数据结构：cfi/start/end这三个都是CFI下面会解释，page是根据cfi算出的页码，text和annotation是笔记专有的标注的文本和用户输入的注解，而modified/removed是时间戳，用于记录当前设备删除/修改一条笔记的时间，用于同步。

CFI

上面多次提到了CFI，那么这到底是是个什么东西呢？让我们看看官方解释：

This specification, EPUB Canonical Fragment Identifier (epubcfi), defines a standardized method for referencing arbitrary content within an EPUB® Publication through the use of fragment identifiers.

简单来说，CFI或者说epubcfi，就是用于表达对EPUB电子书中某一段内容的引用。我们可以可以利用它完成对电子书中任一片段的定位索引，其形如epubcfi(/6/12!/4[3Q280-46130e5d9d644673954c13edca4fc20f]/4,/1:325,/1:340)。具体的定义我不再赘述，有兴趣可以直接看Specification，这里只讲我如何利用其完成的笔记功能。

首先是书签，在上面我们提到过relocated事件会更新进度，这个事件会返回一个location，通过其我们可以得到需要的信息：

props.onBookmarkInfo({
  start: location.start.cfi,
  end: location.end.cfi,
  cfi: mergeCFI(location.start.cfi, location.end.cfi),
  page: loc, modified: Date.now()
});

location.start和location.end分别是当前显示内容的起始和结束CFI，我自己写了个方法mergeCFI将它们合并起来备用。而在onBookmarkInfo的处理中，我并没有直接将其作为待处理的信息直接交由书签标记逻辑，而是先用另一个方法进行了处理：

const parser = new EpubCFI();
export function checkNoteMark(notes: IBookNote[], start: string, end: string): INoteMarkStatus {
  if (!notes.length) {
    return {exist: false, index: 0};
  }

  for (let index = 0; index < notes.length; index += 1) {
    const {start: s, end: e, removed} = notes[index];
    const cse = parser.compare(start, e);
    const ces = parser.compare(end, s);

    if (ces <= 0) {
      return {exist: false, index};
    }

    if (cse <= 0) {
      return {exist: removed ? false : true, index};
    }
  }

  return {exist: false, index: notes.length};
}

这个方法传入一个书签或者笔记，返回其是否存在，以及在当前列表中的位置。为什么要做这个处理呢？因为前面说过——书签和笔记都是有序的，所以我们不能随便插入了事，要先知道插到哪个位置。而有了位置信息，接下来的逻辑也就水到渠成了。

比起书签，笔记的处理要更麻烦一些，因为其不是一个定点而是片段，同时还需要让用户自己去选中这个片段。UI层面的交互我就不多说了，无非就是堆点逻辑，其中比较重点的是如何获取选中的文字片段。如果你去查文档，它会告诉你在rendition中有个selected事件可以解决，但事实上不行，我在阅读了源码后最终只能得到一个Hack的方案——在locationChanged事件后，获取到当前的content，在其上注册事件：

rendition.on('locationChanged', () => {
  content?.off('selected', selectNote);
  const c = rendition.getContents()[0];
  c?.on('selected', selectNote);
  c !== content && setContent(c);
});

而这个事件处理器selectNote的逻辑也很简单，就是将其传入笔记标注工具组件。在这个组件中，我对每个传入的CFI判断是否为新，如果是的话使用checkNoteMark计算出其在当前笔记列表中的状态和位置，然后再计算出工具栏在页面上的位置：

const range: Range = content.range(cfi);
const {x, y, width, height} = range.getBoundingClientRect();
const cw = document.getElementById('epub-viewer').clientWidth;

setX(x % cw + width / 2);
setY(y + height / 2);

然后就可以按照工具栏上的功能写逻辑了，比如删除笔记、修改注解等等。添加/删除笔记同时也伴随着高亮的标注，这个倒是比较简单：

// 添加
rendition.annotations.add('highlight', cfi, undefined, undefined, 'awaken-highlight');

// 删除
props.rendition.annotations.remove(note.cfi, 'highlight');

其中awaken-highlight是主题的一部分，后面会说。

功能到这差不多完备了，但还有点体验上的细节：

其一，一般来讲，对于一段已经标注好的笔记，我们往往希望点击它就可以弹出笔记工具栏，而不是需要选中。此时rendition的markClicked事件就可以帮助我们。

其二，如果你看了epub.js关于文本选择的源码，可以发现其处理非常粗暴：以选择开始为起点，在150ms后判定结束返回事件，而这做法显然不合理，所以我做了点优化（当然仍然不想改工程，凑合改了）：

const EVENT_NAME = bk.supportChangeFolder ? 'mouseup' : 'touchend';
(Contents as any).prototype.onSelectionChange = function(e: Event) {
  const t = this as any;

  if (t.doingSelection) {
    return;
  }

  const handler = function() {
    t.window.removeEventListener(EVENT_NAME, handler);
    const selection = t.window.getSelection();
    t.triggerSelectedEvent(selection);
    t.doingSelection = false;
  };

  t.window.addEventListener(EVENT_NAME, handler);
  t.doingSelection = true;
}

修改很简单，将选择结束的条件改为mouseup或者touchend就行了。

同步

书签和笔记的同步在内容上比书籍简单，因为只需要合并两个数组，但由于其有序并且存在同一条目的更新（修改注解），而且量可能较大还要考虑效率，所以更加麻烦。不过好在这也不是特别复杂的算法，凑合写了个大家看看就懂：

private _mergeNotes(localNotes: IBookNote[], remoteNotes: IBookNote[], removedTs: {[cfi: string]: number}): IBookNote[] {
  const res: IBookNote[] = [];
  let localIndex: number = 0;
  let remoteIndex: number = 0;
  let pre: IBookNote;
  let less: IBookNote;
  let preRemoved: IBookNote;

  while (localIndex < localNotes.length || remoteIndex < remoteNotes.length) {
    const local = localNotes[localIndex];
    const remote = remoteNotes[remoteIndex];

    const comp: number = !local ? 1 : !remote ? -1 : parser.compare(local.start, remote.start);
    if (comp === 0) {
      if (local.modified < remote.modified) {
        less = remote;
        remoteIndex += 1;  
      } else {
        less = local;
        localIndex += 1;  
      }
    } else if (comp === 1) {
      less = remote;
      remoteIndex += 1;
    } else {
      less = local;
      localIndex += 1;
    }

    // local
    if (less.removed) {
      removedTs[less.cfi] = Math.max(less.removed, removedTs[less.cfi] || 0);
      preRemoved = less;
      continue;
    }

    // remote
    if (preRemoved?.cfi === less.cfi) {
      if ((removedTs[less.cfi] || 0) > less.modified) {
        continue;
      }
    }

    // remote
    if (pre?.cfi === less.cfi) {
      pre.modified = Math.max(pre.modified, less.modified);
      continue;
    }

    if ((removedTs[less.cfi] || 0) > less.modified) {
      continue;
    }

    res.push(less);
    pre = less;
  }

  return res;
}

其中每个note的removed属性仅存在于本地条目，而到了远端则变成removedTs中一部分。这么做首先是由于和书籍同步同样的原因，我必须要在远端存下来某个条目是否被删除了；其次不像书籍一样直接同步removed字段是由于一个笔记占用开销，同时按照上面这种优化实现逻辑上会出问题。

如何合并完远端和本地的笔记与书签后，本地存一份然后立即同步到远端，搞定。

Webview默认行为

Kindle笔记迁移

有了笔记功能，别忘了我最初是为了什么搞这个软件的——从Kindle迁移。所以终于到这一步了，就是如何将Kindle的书迁移过来，笔记也迁移过来。

Kindle的书籍迁移已经有很成熟的教程了，可以参考：一键批量下载 Kindle 全部电子书工具 + 移除 DRM 解密插件 + 格式转换教程 (开源免费)，最后用calibre转换的时候选择EPUB即可。

接下来就是笔记迁移了，亚马逊提供了几种笔记导出方案，本来想都支持的，后来由于时间不够懒得搞了就只支持从桌面端软件（PC/Mac）导出的笔记，详细教程搜一下就有，最后导出的应当是名为XXXXX-笔记.html这样的文件。

这里吐槽一下亚马逊的同行们，你们连个html文件的输出都拼不对我真是服了...是因为html本身容错率太高导致看了下能渲染就没检查了是吧？

导出的笔记文件格式分析我就略过了，经过我的解析处理后，大致可以得到如下信息：

笔记的标注内容文本，去掉了空格填充。
如果有注解，注解文本。
笔记的“位置”。

看到这，读者可能觉得最直接的方法就是将笔记的“位置”转换为EPUB的CFI就行，特别简单对吧？哪有这么好的事...在经过查询后，我大概了解了Kindle是怎么计算“位置”的：每128个字节算一个“位置”，这也就解释了为什么你复制中文文本甚至导出的笔记里都会插入这么多空格（我猜的），所以这路子行不通，那可咋整呢？

想来想去，最后还是只能用原始暴力的方法——文本搜索匹配。我直接把笔记拿出来全文搜索出那个片段总行了吧？正好epub.js也提供了对章节的find接口。但在满怀期待试了以后，发现...问题更复杂了：

脚注：很多书中都会有“xxx[1]yyy”这样的脚注，而由于EPUB本身是xml结构的，脚注会被单独渲染为一个结点，但搜索是基于结点的，直接去搜索根本搜不到。
段落：和脚注差不多的原因，搜索基于xml结点，跨段落直接跨结点了，搜不了。
重复：同一段文字会多次出现，对于笔记的“金句”而言不多见，但还是可能在译者评论中出现。

为了解决这些问题呢，我搞了个挺恶心的算法，具体太长就不贴了有兴趣自己去看吧，大概说下思路：

用query的前N个字获取rangeStart，后N个字获取rangeEnd，最后合并。
N看实际情况来取，而textEnd需要在textStart（无脚注link）/linkEnd（有脚注link）的若干结点之内。
先判断是否有[\d+]的link，没有的话：
1. 小于六个字的，直接全文搜索。
2. 大于六个字的，拆成前六后六两部分，分别搜索后合并。
有的话
1. 先查找到第一个link，然后反向搜索link前的文本的前（小于等于六个字），没有文本则直接以link为起点。
2. 然后找到最后一个link，正向搜索link后的文本的最后（小于等于六个字），没有文本则以link为终点。

但即便如此，仍然无法覆盖所有情况，不过大部分情况已经可以覆盖了（只要你处理的是中文书籍），对于边界情况，我会收集起来在最后弹窗提示用户，并复制到用户的剪贴板。

主题切换

至此，主要的功能逻辑都搞定了，但由于个人的习惯，搞了这么久不加点私货是不可能的，所以主题切换功能就此诞生，其属于阅读设定的一部分：

export interface ITheme {
  name: string;
  color: string;
  background: string;
  highlight: string;
}

export interface IReadSettings extends ITheme {
  theme: number;
  fontSize: number;
  letterSpace: number;
  lineSpace: number;
}

由数据结构便可以看到阅读设定允许的内容：fontSize是文本大小，letterSpace是字间距，lineSpace是行间距，这几个单位都是rem。而theme就是最重要的主题了，name是主题名，color是文本颜色，background是背景色，highlight是标注高亮、注解、外部链接颜色。

如何修改这些字段的UI逻辑没必要赘述，这里比较重要的是如何让这些参数产生效果。还记得前面说过的后端的setBackground接口，以及初始化电子书时的stylesheet字段吗？setBackground配合阅读界面的背景颜色，来让异形屏客户端的非安全区统一颜色，这个没啥好说的。stylesheet则可以给渲染EPUB的iframe添加一个css文件，而这个文件是我动态生成的：

export function buildStyleUrl(settings: IReadSettings): string {
  const style = `
body {
  color: ${settings.color};
  font-size: ${settings.fontSize}rem;
  line-height: ${settings.fontSize + settings.lineSpace}rem;
  letter-spacing: ${settings.letterSpace || 0}rem;
  touch-action: none;
  -webkit-touch-callout: none;
  word-break: break-all;
}

img {
  width: 100%;
}

a {
  color: ${settings.color};
  text-decoration: none;
  border-bottom: 2px solid ${settings.highlight};
}
  `

  return URL.createObjectURL(new Blob([style], {type: 'text/css'}));
}

当用户每次修改完样式确认后，我还需要去修改重新设置样式：

const applyReadSettings = async (rSettings: IReadSettings) => {
  const {background, highlight} = rSettings;
  await bk.worker.setBackground(
    parseInt(background.substring(1, 3), 16) / 255,
    parseInt(background.substring(3, 5), 16) / 255, 
    parseInt(background.substring(5, 7), 16) / 255
  );
  const sheet = document.getElementById('global-style') as HTMLStyleElement;
  sheet.textContent = `g.awaken-highlight {fill: ${highlight} !important;fill-opacity: 0.5;}`;
  setBookStyle(buildStyleUrl(rSettings));
  setReadSettings(rSettings);
}

其中global-style的修改是为了笔记高亮的样式（epub.js是用SVG实现的），而setBookStyle后执行的则是：

rendition.themes.register('awaken-style', props.bookStyle);
rendition.themes.select('awaken-style');

卸载之前的样式重新加载即可。

构建发布

开发完成后就是最终的构建发布了，这个在三端也有不同的做法。当然无论如何，第一步都是构建出生产环境的代码，我将最终代码构建到了dist目录，以备后续处理。

桌面端

桌面端的构建很简单，Tauri都帮我们想好了，我在tauri.conf.json中指定了资源目录build.distDir为./assets，并用脚本将上一步构建后的产物复制到其内：

d=platforms/desktop/assets && rm -rf $d && mkdir $d && cp dist/* $d

最后执行切换到桌面工程目录下执行构建代码即可：

cd ./platforms/desktop && tauri build

最终的产物在./platforms/desktop/target/release/bundle内。

安卓端

移动端相较于桌面端，需要自己区分开发和生产环境，而且对资源的处理也要更复杂一些。

在安卓端，首先区分开发和发布环境是通过菜单的Build -> Select Build Variants窗口设置的，默认有debug和release两种模式，在不同模式切换后会有个全局单例中的变量BuildConfig.DEBUG能判断处于什么环境：

if (BuildConfig.DEBUG) {
    ......
}

接下来在发布时，我们现将构建好的前端代码复制到指定目录：

d=platforms/android/app/src/main/assets && rm -rf $d && mkdir $d && cp dist/* $d

至于如何返回这些包内静态资源呢？也很简单，在前面我已经在客户端实现了Webview中XHR的拦截，现在只要在里面添加一些逻辑即可。

首先，在发布环境下，我需要将Webview加载的url从调试的dev-server的地址，换到我们拦截的schema：

mainWebView?.loadUrl(if (BuildConfig.DEBUG) { host } else { "http://awaken.api" })

然后对于所有在之前接口协议之外的method，全部认为是对包内静态资源的请求，然后进行拦截处理：

fun loadAsset(url: String): InputStream {
    return mContext.assets.open(if (url == "") { "index.html" } else { url })
}

可见在安卓上对包内资源的请求是很简单的。在完成这些后，我们还需要给应用提供一个签名，用Build -> Generate Signed Build or APK即可。

最终构建产物在platforms/android/app/release中。

iOS端

iOS的工程配置是完全由XCode管理的，单纯从构建区分来讲并不复杂。

首先是区分开发和发布环境，这个只需要在工程配置文件的Build Settings -> swift compiler - Custom Flags -> Other Swift Flags中，给Debug配置加上-DDEBUG，给Release配置加上-DRELEASE，然后创建两个构建的Schema，在其中分别使用哪个环境，最后就可以在代码中使用这些编译选项了：

#if RELEASE
......
#else
......
#endif

接下来在发布时，我们现将构建好的前端代码复制到指定目录：

d=platforms/ios/Awaken/assets && rm -rf $d && mkdir $d && cp dist/* $d

随后在XCode项目配置的Build Phase -> Copy Bundle Resource中，将assets目录添加进去，让其能打入构建包。随后便可以在代码中的发布分支中编写具体逻辑了：

let rp = Bundle.main.path(forResource: "index", ofType: "html", inDirectory: "assets")!
do {
    let str = try String(contentsOfFile: rp, encoding: .utf8)
    wkWebView.loadHTMLString(str, baseURL: URL(string: "awaken://awaken.api")!)
} catch {
    wkWebView.load(URLRequest(url: URL(string: host)!))
}

可见这里比安卓要复杂不少，我先读取了本地Bundle内的index.html，然后指定了我们实现了XHR拦截的地址awaken://awaken.api作为baseURL。接下来WKWebView就会以这个地址为基础去请求JS、CSS等静态资源了。

之所以要提前读取html的内容，是因为通过XHR拦截返回index.html会出现问题。

静态资源的处理和安卓基本一致，对于不满足既定接口方法的请求直接尝试加载本地资源即可：

private func loadAsset(url: String) throws -> FileHandle {
    let fp = url == "" ? "index.html" : url
    let nameExt = fp.components(separatedBy: ".")
    let rp = Bundle.main.path(forResource: nameExt[0], ofType: nameExt[1], inDirectory: "assets")
    let file = FileHandle(forReadingAtPath: rp!)

    if (file == nil) {
        throw "File load error: \(url)"
    }

    return file!
}

结语

搞之前没想到还挺麻烦的，要是之前有人搞了我也不会花着精力，毕竟这甚至不属于我既定项目的一部分。不过总体来讲，做完还挺有成就感的，未来有别的项目也可以作为模板打个样。

无论如何，我过去从开源社区已经索取了这么多，那么尽可能做出力所能及的回报也是必要的。无论做点啥总都比躺着伸手祈求强，毕竟——

意义并不在于‘包罗万象’的观测，而存在于任一行动的回响之中。

接下来就是去读书然后完成既定的主线项目了。

Project Self

dtysky — Saturday, 30 Apr 2022 00:00:00 -00:00

褐色的枝干攀附于浅黄的墙壁，粉白的花簇拥着吊在其上，油绿的树叶反而成了点缀。风不大，偶有几片花叶被吹落到地上，笔直的水泥路灰里透着青，一直向远处的湛蓝天空延伸。我站在墙下抬头望去，阳光逆着我的视线透过树叶，照在了我带着蓝色美瞳的眼睛上。

“对对对，就是这个姿势，保持一下！老天赏脸，这光真不错。”身后的摄影师@夏昊（以下简称X）背着他的富士GFX100S，语气轻松：“你今天状态感觉还好吧？”

X和我同龄，几年前毕业于北影，据说刚毕业时吃过一阵子肉，但前些年电影行业开始不景气就离开了这行当。好在他家境不错，这两年便自由在家学习感兴趣的东西，不时出来给有缘人拍些写真赚点钱。

“还好，虽然感冒还是有点。”我顶着些许的身体不适，努力保持着这个姿势。保持，意味着静止，而完全的静止，对我而言是不可能的。虽然肉体可以尽量不动，但无法停止的思绪却开始了游离。

这段时间我似乎一直在感冒，说是感冒，其实就是持续性的头晕加嗓子不舒服。症状一般始于起床，午饭后逐渐缓解，晚上到家又开始。前几天我似乎开始适应了这种不适，但今天特别需要一个良好状态，所以出门前饭后我磕了个对乙酰氨基酚片。和年少时不同，现在的我不再会硬抗肉体的不适来获取某种悲壮的情绪。数次实践下选出的最适合自己的药，让我现在的症状相比早上拍和猫的合照时缓解了许多。

想到了猫，便想到了早晨，对早晨的回想接替了感冒的主题。而按照惯例，这思绪又进一步跳跃，回到了我和X首次沟通的那天。

沟通-起点

沟通，对于我而言可以很简单，也可以很困难，这取决于具体的内容。当然，每个人都有自己擅长或不擅长沟通的领域，但像我这么极端区分的，应该是不多。以前我会将这些领域内容区分为很多种类，比如技术、工作、二刺螈、文学、哲学、情感问题等等，但现在想来，我大概仅会将其分为两类：取悦他人，或是取悦自己。

我擅长取悦自己，即便是往常那对自我的折磨，很多也可以说是一种变相的取悦。但取悦他人，的确是我极不擅长的，所以我一般会尽力避开那些取悦他人的场合，来让自己得到最大的安宁。倘若所有的事情都能被如此干脆得划分，倒也不失为一种有益的秩序。但现实的本质既是混乱，又怎可能事事顺遂？现在摆在眼前的，便是一个特例。

写真作为一个特例，包含了取悦他人和取悦自己的双重性质。这个取悦的他人倒不是说摄影师，而是源于我拍摄的初心：一个妹子对我社交账号照片的建议。她说“从女方视角，很多男的都很卷，各种花里胡哨，你也应该搞点让大家喜欢的照片。”我觉得蛮有道理，便认真考虑起了这个建议。“考虑”这件事本来并不是什么大事，我每天本就在考虑许多无关紧要的屁事，但前面加上“认真”二字就不同了。

认真，在我的词典里优先级是极高的。任何事一旦加上了这个前缀，便会直接跃升为一个大工程，我会尽自己的所有可能将其做到最好。写真这事说起来，一开始不过是为了搞几张取悦他人的照片，按理说花个几百块拍套简单的、温柔的、沉稳的艺术照即可。但既然认真了，就需要考虑将其维度延展开。这一认真，一延展，一加工，我便又给自己挖了一个坑。和我之前定下的诸多类似《Project Heart》、《Project Tomorrow》、《Project Fake》等等企划一般，我脑海里突然浮现了一个企划。

这个企划的名字便是《Project Self》，而其核心便是三个人，或者说是三个人格，亦或说是三个投影比较合适：少年，少女，青年。

不错，这三个投影，正是在我过去写给自己的私小说中，那数次出现的少年H、少女H和青年H。如此一来，这写真就成了一种记录和表达，那么它和写作也就相去无几。而我的写作，无论目的如何，取悦自己的比例一直远高于取悦他人。考虑到这，写真的初心就变了个味，从取悦他人变成了取悦自己。

拍写真取悦自己，意味着需要高度的定制，定制又意味着预算和增加和详尽的沟通。对于现在的我，相比于预算这种小事，沟通显得额外艰难。作为一个INFP，我是比较擅长自我剖析和暴露，也逐渐不在乎他人的不理解，但此次却不能如此。如果将其也视为一种创作，那么和往常我一人构思和执笔不同，这一次我是将笔交予了对方。它不但要求摄影师完全理解了我的诉求，还要求对方能够认同，这样才能由衷给出那种表达。

我写了一篇需求来描述我的意图，将其发给了几个朋友介绍的本地摄影大佬，但都被拒接了。其中有一位给出了“这个只能让一个比较熟悉你的摄影师”来的建议。循着这建议，我找到了这个深圳的北影出身的知乎KOL摄影师朋友。将需求发给他想让他介绍个广州的圈内朋友给我后，他便饶有兴致得以“我就喜欢创意型摄影”自己接下了这个单。

摄影的报价是我给出的，出于对朋友的信任和避免某些无效的沟通，我咨询了圈内朋友后，给出了圈内的一般最高价格——三四千，对方表示可以：如果结果不满意三千，满意四千，而且排期自由。我觉得如果能达到要求，也算合理，便定了下来，具体时间则是在清明。

我本来认为做好了这些前置准备，便只需要为了取悦自己而沟通，如此一来效果的达成也就是时间问题。但事后想来，取悦他人还是自己不过是结果论罢了，对于这样的一种非常主观的活动，本质上是双方需求的对抗与中和。对抗和中和，也就是沟通的另一种说法，但在这个侧面而言，沟通的实质其实是“要求”。

极其不擅于提出“要求”的我，让拍摄饶了一些弯路。

第一日

拍摄的第一日，正是清明的第一天。由于感冒症状以及昨晚摄影设备和电脑的调试，我大约九点醒来，却挣扎到了十点多才起床。不过打开窗户后，和煦的阳光让我心情好了不少，天公赏脸，今日并未像预报一般是阴天。换了衣服走出卧室后，惯例的低血糖让我有些头晕，便当即决定吃了饭再出门。饭后磕了药，身体状况并未瞬间好了起来，但时间已然不早，我也不想拖延更久，便和X说先带着猫在小区内拍几张日常，之后再正式开始今天的外景。

在这所有的拍摄之前，X先问了我一句：“看你的需求，到底是想要美化的，还是比较真实的？”

我不假思索得回到：“我不想做一个伪物，所以当然是真实。”

于是真实便成了这系列拍摄的主基调，在这个基调下，我们带着滚滚和糖糖下楼了。

猫

小区坐落在海珠和番禺两个区的交界处，位置可以说是偏僻到鸟不拉屎，但其另一面也确实有足够大的面积、很低的容积率与不错的绿化。我们站在单元门口一眼望去，是一条被错落有致的树木包裹着的林荫小道。此时万里无云，明媚的阳光正透过树叶，向被砖红色和青涩投下粒粒光斑，非常适合取景。我们向前走了几步，X观察了周围，很快就确定了个地点。我走了过去，将猫抱了出来，开始了拍摄。

“就这是吧？”城市来讲，如果可以列一个我不擅长的事情列表，“拍照”应该是能排在很前列的。所以在拍摄时，我第一想的便是专业的事交给专业的人，尽量遵从对方的指导。

“再前面一点，对，就这几个光斑下面。”他指着地上的几个光斑，我带着猫走了过去。

“糖糖！别瞎跑。”生性好动谨慎的糖糖刚下地就想着躲起来，她体型很小又白，匍匐在地，东张西望，见缝就钻。好在虽然我身体仍然不适，但在三年多的相处下早就学会了对付她。我将比较傻不拉几的滚滚放在一边，迅速拎起了糖糖的脖子，将她放回原地。如此重复三四次后，她可能暂时得习得性无助了，便不再反抗。

拍照在搞定了猫后顺利了起来，这组写真的主角是猫而不是我，所以我个人在镜头前的特质并没有表现出来。同时在和猫的互动中，我的表情相对自然并且还有些许笑意，这掩盖了一些本应出现的麻烦，让我们认为接下来的拍摄都会如此简单。

第一组照片，就这样完成了。

少年

“你过来看下效果吧。”

“...好的。”

X的声音将我从回想中拉回，我走了过去，看了看他相机中的照片。情绪有点复杂，但还是回了句：“感觉不错，挺有日系清新的那个味。”

情绪复杂，不是在于对方拍摄技巧不好，也并非由于本应出现的那个麻烦：它还尚未出现。问题是在于，这和我本身设想的感觉确实不太一样。在我的设想中，摄影的第一个阶段是“少年”，而我的少年时光，与大众意义、也可能是X所理解的少年感，还是有不小差距的。

我对少年的标签，是桀骜不驯，唯我，以及脆弱，其模板如下：

而X拍摄出的，是包容、阳光和温暖。

此刻我本应提出一些要求，但虽然时常在文章或是其他场合不掩饰自我的特质，但在这种一对一的、我所不擅于应对的场合中，我将主导权完全交由了对方。“要求”此刻对我而言成为了非常困难的事情，便出于尽可能减少“沟通”的想法，选择了沉默。

我们就这样相对沉默，顺着笔直的道路向前走着，寻觅着下一个拍摄的场所。走了不一会，我们便停在了一片露营地旁。他指了指不远的一处草丛，说：“这不错，你去坐到这个地方。”

我便走了过去，很配合得坐了下来，之后又按照X的提示摆好了姿势。这里和方才不太一样，人多了不少，大多还都是妹子。虽然表面上力保那种体面和从容，我的心中还是有些不是滋味。即便是在社会上找到了许多自信的我，还是很不适应那种非常社会化的审视目光，这并非出于怯懦，而是出于一种由羞耻心和厌恶感交织而成的复杂情绪。

抱有这样情绪的我，望着对面的他，感觉他手中的相机就像是一挺枪，将周围的那种审视浓缩成了对我特攻威力巨大的子弹，要将其射入我的胸口，铭刻我此时的惨状。

“你能笑一笑吗？”他一边端着相机对着我，一边向我示意应当摆出的表情。

“我尽力...”我当然可以理解他说的含义，那也是世俗“少年感”的一部分，所以我尽可能尝试去这么做了。而从此刻开始，那个源于我特质的麻烦也就出现了。

不一会，我们在这一块换了几个地点，拍了几张照片。整个过程中我们的气氛也逐渐缓和，不再那么沉默，随便聊了聊周边环境，广州的生活气息，甚至还有照片中那个可乐售卖机引发出的一系列关于时代感标语的探讨。然而拍完这一组后，我们的话题还是最终落在了那个麻烦的地方。

“你是不太放的开的那种性格是吧？”X语气轻快，开玩笑般向我问道。

“嗯，我是比较严肃。”

“确实，你这个嘴角一直都是这样”他说着比了个︵的手势：“的，总有种生人勿近的感觉。”

“哎，那也没啥办法，尤其是在相机前。”我无奈的口吻发自真心：“虽然以前恋爱开心的时候确实也︶过不短时间。”

“那即便是单身，你也可以把这种状态延续下去吧，从你的一个目的来讲，这样会有更多人喜欢你，阻力也小一些。”

“可能吧，不过既然你也创作过，应该可以理解︵的时候比较容易出好东西，而︶的时候一般是创作不能的。所以...”

“OK，我理解了，那就按照这种感觉去拍也好。”虽然他这么说，但我明白他应该是理解了他心目中的那种少年感应该是无法达成了。

下一组照片决定了在江边拍摄。我们过了马路，靠着石质的栏杆，眼下便是缓缓流淌的珠江。在江的对岸是数座林立的高楼，那便是广州的CBD珠江新城，也是这个城市房价最贵的地方。而此时不知是巧合还是命运，我的旁边，正是一个被放在栏杆墩子上的路灯。路灯虽然很小，但看到了它的我还是会心一笑。我不知道X是否也有这样的想法，但他最后敲定的地点就是这里。

“好就这个姿势，眼睛看向十点钟方向。”

我坐到了栏杆上，将双腿交叉，双手自然搭在两侧，按X所说望着十点钟的方向，静静等待着他的拍摄。十点钟的方向，是天空，天很蓝，云很少。群青的天空，CROSSING，群青学院广播社，孤独，这样一来确实有些我认为的少年氛围吧。所以至少在这一刻，我确信我应当展露出了少年的情绪，而当最终拍摄结束时，我看到样片时也终于确定了：我的少年时代，大概确实如此。

拍完这组后，X提议这个形态室外差不多了，可以换个内景试试。离这最近的比较适合内景的，自然是广东博物馆。我们便回到了方才的那片露营地，绕着它走向博物馆，而在这个途中，一串泡泡在我们眼前飘过，X便有了想法：“你觉不觉得这个很有意思？”我虽然没有完全会意到，但觉得也算有趣，便和他一起走去，完全没有意识到前方的艰难：密度更高的人群，和他人的配合，更多注视着我的人，还多了小孩和他们的家长。不过最后的结果还挺好，虽然我仍然没能笑出来。

过度

到博物馆时已经快四点了，我们被管理人员告知今日预约已满，便只好考虑接下来的行程。我原定的规划是去TIT，回工位换衣服后直接进入青年状态，在园区内取一些景物后入夜再到海心桥上拍夜景。但X的想法却有些不同，他建议中间加一个“过渡态”，来体现少年到青年的这种转变。

我想了一下，感觉这个提议确实有道理。一来我确实带了三身衣服备用，二来如果说白日对应少年，黑夜对应青年，那么傍晚黄昏作为过度，也确实是一个绝妙的象征。于是我换上了第二身衣服，银白的休闲西裤，米黄色的衬衫，蓝灰色的休闲西装外套，加上黑框眼镜，恰好对应了白到黑的一个渐变，也体现了少年/青年特质的部分过度——

尚未完全颓废的桀骜不驯，尚未演变成疏离的脆弱，尚未完全伪装起来的自我。

拍摄始于一个比较文艺的咖啡馆，我们的座位侧面是一个挺帅的、打扮讲究的小哥，后面则是看起来在暧昧的男女。X提议为我在这里拍两张照片，他拿起相机拍我的时候，我感觉其他几个人又审视起了我，这让我不太舒服，效果也就不太好。所以在些许休息后，我们终于走出了这里去了外景，我便松了一口气，恢复了状态。

第一批正式的照片是在不远处拍的，TIT整个园区的绿化都做得很好，找一个枝叶繁盛的背景并不困难。我按照指导站在了一簇簇树木和花草之前，背对着它们后方的双层Loft：微信的访客中心。此刻已经接近傍晚，透过枝叶的阳光没有了之前的凌厉毒辣，变得温暖且柔和。我在X示意下，大概构想了一下应当摆出的姿态，结果仍然是理所当然的克制和拘谨。而后接着这个情绪，我们找个了比较僻静的角落，顺着台阶一路往上，又拍了几张表现出日常和带着颓废的照片。

但这几张更多是体现了那种和解和隐忍，而忽视了反抗，不过即便意识到了问题，我也并未直接提出诉求，而是在接下来的过程中找机会从我这边调整。幸运的是接下来的两个场景非常恰恰到好处，虽然比起达到“被人喜欢”，它们更多的应当是引起大多人的厌恶，但这种审视和倨傲比起白日的那些照片，我认为更能体现我所言的“少年感”，也是我认为少年真正应该拥有的气质。

拍完后面这张后，X对我说：“是不是有你给的那个广州市人民医院的例子的feel了？”我粗略看了下效果，确实如他所言，相比起来病态的气质少了一些，但多了些肃穆的氛围，总体在我看来拍得很好，却也没有过多的感想。但当事后我再次打开它，我便明确了这是我今天最喜欢的一张照片：

些许杂草和青苔丛生在脚下的木板上，像一张破败的地毯。红砖砌成的墙壁充满着岁月的痕迹，横竖两道水泥交叉着嵌在其中，像是半截巨大的十字架。我就站在这十字架的正下方，昂着头，宁静得闭着眼，任由斜射在墙上的阳光从半张脸上掠过。

如此一来，这个阶段就算是结束了。我提议先去客村那边吃个饭再回来换衣服进入下个阶段，二人便向那边走去。而在快要到目的地时，X却停下来，并把我叫住，我回首一看，他正望着边上这条城中村小道，若有所思。我走了过去，没想到今天最考验我羞耻心的瞬间就如此开始了：在这个最为繁华的时刻，城中村的小道行人和车辆络绎不绝，他让我站在入口的正中间，逆着人流，尽可能摆出姿势停留...我照做了，于是今天他最喜欢的一张照片就这么诞生了。

“我有这么胖，脸有这么方吗？”裸高173，体重62，照镜子认为自己是鹅蛋脸的我，看着这张被像是特稿封面的照片，不禁陷入了沉思。

青年

晚餐后已是黄昏尾声，我们回到了TIT换了最后一身衣服，进入今天最后的一个形态——青年，也就是现在的我。从最初的白天，到过渡的黄昏，我们终于来到了符合这个阶段的象征——夜晚。不过在去到规划中的拍摄地点之前，我们先拍了张搞事的照片——《某大厂被毕业无助青年》（逃

以及水中的倒影：

接下来便去到了二沙岛海心桥旁的艺术公园，开始了预定的行程。到岛上时，暮色已经缓缓降临，远方的天空自上方的紫色逐渐向下渐变为橘红，挡在前面那树木错落的枝丫在夜色的浸染下通体黝黑，静静得沉默着。我们拉着箱子过了马路，在路边观望着来来往往的人群，顺便寻觅着第一个拍摄地点。而就在此时，我忽然感受一股袭来的倦意，便毫不讲究得坐在了一根石柱上，将手撑在了行李箱上。

“就这么来两张吧。”我下意识对着X提议到，于是第一张青年阶段的照片就这么诞生了。事后再看回来，它应当是准确得体现出了我想表达的青年阶段特质颓废，伪装，疏离中的“颓废”：

坐了一会后，我恢复了一些精神，二人便顺着人流继续向前走，不知不觉就来到了海心桥边。海心桥横驾于珠江之上，被其上众多暖白的灯光的映照着，在这夜色中熠熠生辉。在它之下的珠江被微风带起了阵阵涟漪，水面上的倒影随着波纹摇摇晃晃，让身为半个图形程序我不禁在心中感叹：“这渲染果然还是TM得让三次元来啊，这反射，这高光...”

而就当我这么想的时候，X示意我去往桥边不远处的护栏前方。我走到了那里，背靠护栏，看着他走到了我的左前方，便随着他的视线向右后望去。在立即明白了他的想法后，我微微侧头望向了十点钟的方向，尽可能表现出了第二个特质“伪装”。

随后又在珠江边的另一处拍了张青年的隐藏特质装傻（笑

按原计划来说，下一个地点本应是海心桥，但这个点还排的十分长的队伍证明了我的失策，也打消了我们上去的念头。折返后是漫无目的的闲逛，疲惫的我们穿过了公园，越过了马路，正准备就此回家的时候，却意外发现了一块树上满挂着红灯笼的地方。他停了下来，示意我站在这片草地中间，按下了快门：

“你这张很像我的美术老师，二十年后再用吧。”他示意我看着照片。

“嗯...确实有点显老。”但无论如何，至少这张确实大概表现出了第三个特质“疏离”。

至此，第一天的拍摄结束，感冒药的药效似乎也完全过了。我脑袋有些昏沉，便拒绝了X邀请我去晚上的一个舞会以“认识圈内朋友”的邀请，打车回到了家后，又让司机将他送到了舞会现场。而在车上是，他提到了付款方式，我表示用大额资金习惯用支付宝，随后我问了句“你现在就要还是？”他表示“先给吧，少点利息。”于是出于信任和与人为善，我便将于先说好的三千先转给了他，最后的一千等全部完成了再给。

第二日

按照计划，本来应当是第二天就立马去棚里拍第三个形态“少女”，但由于X约定的另一个客户的突发时间安排，时间确实相对比较自由的我便调整了时间，改为了次日的下午。

前奏

大约下午四点半，我到了摄影棚，发现在场的除了X，还有一对情侣——这正是X的另一个客户，据说是他交了许久的朋友。既然他们还在这里，也就意味着还没拍完。起初我坐在沙发上看了他们一小会，觉得确实还蛮般配，尤其是知道他们异地了不少时间最终成了眷属的情况下。

但过了不久，我便坐到了化妆台前，由X联系的化妆师给我化妆。

化妆

由于接下来有个场景还是需要少年/青年两个形态出境，所以我先画了个简单的淡妆，遮了个瑕，然后补了个少年/青年的形态，随后便进入了正式的化妆环节。

化妆师应该是个三十多的姐姐，看起来已经有多年行业经验了。她一边用娴熟的手法给我上着妆，隔离、打底、遮瑕、修眉、假睫毛、眼线等等，一边还和我搭着话。

“你这是搞COS嘛？”

“啊？也不算吧，就是明年就三十了，给自己留个纪念。”

“三十？看起来一点都不像。”她笑了笑：“感觉就和二十出头一样。”

“谢谢，很多人都说我显年轻。”我已经不在意对方是不是奉承，说到底这也根本不重要。

“不过你这想法挺好的，我都三十好几了，那时候也没想着给自己留个纪念。”

“嗯...我是觉得还是得留下点啥吧。”完全是反射性的回答，我也不知道自己在说什么。

时间就这样过着，过着，直到最后遮瑕的那一步。

“小伙子你这皮肤有些差啊，遮瑕估计是没办法完全遮住的。”

“嗯，最近在做激光试试，你尽力吧。”虽然表现得若无其事，但内心还是有些刺痛吧，但确实也没什么办法，我的基因和出身又不是我能决定的。

“没事没事，反正现在有灯光和后期，你这个只是在妆下会显得明显些。男汉子粗糙点也正常的。”

“嗯...”再次反射性的回答，我当然知道对方这是出于礼貌，但我也不想因为这礼貌产生任何感激。

不过无论如何，虽然没有感激，却也没有憎恨和厌恶，纯粹是没有感觉。没有感觉，意味着麻木，但对于某些事情的麻木，对于我而言，可能并不是一件坏事。

少女

化妆大概在半小时左右结束，后面化妆师还很靠谱得帮我带上了美瞳和假发。在确定没什么问题后，我按照她和X约定的价格，将三百转了过去，随后换上了第一身衣服——白色LO，并走到了摄影棚的中心，形态“少女”的拍摄正式开始。

这个棚是一个白棚，和我预想的不太一样。我本来以为回到一个实景棚，里面布置成一个温馨的小房间之类的，有些道具来互动，但这里除了白一无所有。不过既来之则安之，我不擅长提要求，也很讨厌麻烦，便只能对着X和后面到来的他的助理小妹妹，摆起了姿势。

然后在几张样片后我可悲得发现，即便是穿上了女装，我也没有办法回到几年前穿LO时的那种纯洁可爱的感觉了。

“这个，我有这么胖吗？”我指着样片，又看了看镜中的自己，感受到了明显的反差。

“......”X似乎忙了一天，很疲惫，没有做过多回复。

“算了，靠后期吧。”

当然，事后我查了一些资料才知道“动眼效应”，图像的扁平化也确实会让人显得更胖，不过还是可以靠一些角度和修饰来解决的。但此刻的我只能无奈回到了原地，继续拍那个“祈祷”的姿势，进而完成了“三位一体”的拍摄：

后续我又尽可能找感觉来远离我一贯的那种苦大仇深，进而体现出少女设定中温暖，纯真，善良的特质，但尝试了若干张之后，我才终于算是有了一张勉强有感觉的：

而此刻的我也将这种显胖的原因甩给了“白色”，众所周知，白色的衣服本就容易显胖。于是我连忙换上了那身暗红色的日常LO，走到了镜头前。但在拍了几张后，感觉表情和神态还是不怎么对。于是X提议将镜子放在我的身边，以此来让我注意自己的动作和神情，而在这种优化的操作下，我像是忽然找到了那种日常的自我，出了几张感觉不错的图，虽然仍然没有笑容：

日常这身拍完后，便是最后一身GOTH系的LO，设定里是由“白”反转而成的“黑”。在换上了这身衣服后，对着镜子的我感觉才找到了真正的自我，那种不协调的违和感瞬间消失，我不需要去强行伪装出任何表情，只需保持日常的不屑和高冷即可。也正因此，这一身的出片品质应该是今天最高的：

晚餐

拍摄大约在九点左右结束，此刻的我已经非常疲惫，匆匆卸妆收拾完后便准备回家。但在这之前，我下意识问了一句：“你们吃了吗？”

“还没有，那你请我们吃饭吧。”X如此回应。

“OK，我找找吧。”我觉得大家确实也辛苦了一天，即便这一天里只有一半是在为我辛苦，但只要结果好，也无妨。

于是很快我便打了个车，前往目的地：最近的一家海银海记。

“那我就按我的习惯点了。”落座后，我按照习惯，将那老几样——三花趾，五花趾，吊龙，胸口朥，千张，粿条等加入购物车下了单。然后大家便闲扯了起来。

“你是他带的学生，所以是准备考北影嘛？”我起了个话头，问了问对面看起来比我高的小妹妹。

“嗯，考明年的。”

“明年...你今年本科毕业嘛？也就是00的？”

“嗯...我01的。”

“......”虽然我一直号称自己永远年轻，抵制成长，但当一个真的01年应届生坐在我面前时，还是下意识感受到了自己的老去。

“挺好，不过现在这环境，还去考电影是真爱啊，你本科是传媒吗？”

“不是...是工科的。”

“读研要三年，这不景气也不能一直这样吧，就赌一下三年后的环境。”X接着话茬，阐释着对方的选择并非没有道理。

“说的也是，反正这年景哪行都不行，互联网也裁员，读研避避风头也好。”

接着顺着这个，我们便聊起了疫情防控，进而聊到了康米，又转进到了情感问题，接下来又是青春与理想，然后是人的异化...

这诸多可说与不可说，宏大与鸡毛蒜皮，严肃和消失与腹中的牛肉。事后想来，也算是这个时代特有、却又在漫长的历史中有着诸多共性的，极其有趣、讽刺又悲哀的场面吧。

毕竟那些种种神圣和憧憬，最终都不过是饭桌上的谈资罢了。

回顾-要求

摄影结束后便是漫长对修图的等待，在这等待中我看着这些原片，回想着这两天的拍摄，说是十分满意肯定是不可能的。而想来这各中的不满的源头，应当正是铭刻在我身上那和“要求”这个词的不适性。

众所周知“要求”是双向的，一个人提出，一个人接受或者否决。而倘若在一段重要的关系中一个人的要求总是被否决，那么提出要求的这个人便会渐渐沉默，这关系便会走向终结——按常理而言应该如此。但这世界上却并非所有关系都能被单方终结，在这个奴隶已经不存在的世界...不，90后的很多亲子关系，和主人奴隶之间的关系可谓神似。在许多家庭中，孩子在成长中逐渐都患上了习得性无助，便失去了“要求”的能力，或是即便没有失去，却也觉得“要求”本身是错误和可耻的。而我，自然也是其中的一员。

我非常不擅长提出要求，取而代之的则是表面的讨好人格，与实际上“沉默->消耗忍耐度->结束关系”的链路。即便在毕业后终于离开了家中的六年中，我也只是学会了在职场合理得提出要求，在生活中即便是非常努力去改变，却也只是收获寥寥。这极大限制了我的能力边界，也让我白白遭受了许多无谓的伤害。

这些伤害可大可小，我可以举出很多很小却可笑的例子。最近一次印象深刻的小事，是在公司咖啡店发生的。往常在我点了热柠檬茶后，店员一般会在上面套上一个隔热的套子，来防止烫手。而不知为何，从某一天后，店员就不会再主动套这个套子了。没有了套子的柠檬茶，握在手上，十分得烫，但在相当的一段时间呢，我的做法都是拿起就走。不错，即便这温度让我感到十分不适，我仍然忍耐着握着它走到了两百米外的办公区。

就这样过了数次后，某天的我又像往常一样点了个热柠檬茶。而下一瞬间，我并未直接拿起它就走，而是像忽然开窍一般，拿起了旁边的一个套子，自己套上了。看着此时手中的柠檬茶，我并没有往常那样灼热的触感，这让我恍惚了一下，然后忽然意识到了什么，接下来便是盘旋在我脑海中的一句话：

“他不给，你就不能要？他妈的我凭什么不能要？”

伴随着这句话，过去二十八年的种种场景便如潮水一般灌入了我的脑海。其中记忆最深刻的，应该是我大概在大二的某个夜晚。那晚我忽然感受到了强烈的牙痛，那是一种钻心的疼痛，让我坐立不安。但我第一时间想得居然不是去医院，而是忍着，是喝凉水，是用纸团顶着它，是用种种手段来抑制疼痛，以此期望它自己过去，不要带来更多的麻烦。即便是后来实在忍不住去了医院，我一开始也没有告知父母，而是想着通过自己的生活费省吃俭用省下这就医的钱。直到被医生说很严重，不得不花几千块钱来做烤瓷牙套时，我才不得不打电话给父母。

如此正当的一个要求，当时的我却至始至终觉得自己像个贼一般，不配得到这样的治疗，浪费了他们的钱。但时候细想，他们缺这点钱吗？并不缺。我的牙变成这样是我自己造成的吗？并不是。那为什么我会感到这么耻辱？那么我只能认为这是从小的各种经历和教育，让我养成了一种我之前并未意识到的性格：

厌恶和他人争执，厌恶麻烦别人，厌恶请求他人。不错，我并不是不懂得“要求”，只是不喜欢“请求”罢了。因为请求意味着亏欠，而我不想亏欠任何人。所以我只能用一些其他的策略来让他人认为“应当主动给我”，而不是“我向你要的”。但显然，这种手段只对于亲密关系能产生作用，而且基本都有着严重的副作用。对于商业化的交换，这最终只能导致自己吃亏的同时，还憋着一肚子气。

所以回归到这次拍摄来看，我这“不愿请求”的习惯，确实让我们的拍摄饶了一些弯路。但好在后续和朋友的沟通下，他们给出了一些分析和建议，说“你既然支付了成本和精力，那应当需要让自己满意”。这让我再次意识到了我去“要求”的正当性和必要性，于是便联系了X，来为了补上第三日的拍摄：室内，以及一个实景棚的剧情编排。

准备

定下了第三日拍摄日程，便要开始准备了。准备分为两个部分，其一是对家中的收拾，让其变得更加整洁以适应拍摄。

家中的收拾倒是没什么，也确实该来个大扫除了。我对这种事的启动成本虽然一向比较高，但一旦启动了就会尽可能做好。从卧室飘窗开始，书桌，床上，客厅沙发，电脑桌，餐桌...垃圾收拾得差不多后，我开始拿着吸尘器处理灰尘。从地面，到书架，再到电视柜，以及架在电视柜两旁的音箱...

“...这是？”我停了下来，望着其中一个音箱上的日历。这是去年公司发的新春礼品的一部分，而其上的日期则一直停留在了2021年的7月份。

“......”脑中忽然闪过了一些回忆，它们一件件稍纵即逝，却又连绵不绝：“你追求留下痕迹，我追求飞过和体验”，“你追求的是无以轮比的闪耀”，“可是代价呢？”......

“行了行了，瞎几把想啥，干活。”把日历叠起来扔到垃圾袋后，房间很快便被我顺利打扫干净了。

收拾房间后的第二件事，则是推演和购置棚拍所需要的道具。吸取上次的经验，以及按照编排的剧本要求，我列了一个需要购置的物品清单。按理说这些东西应该是平平无奇，网上随便就能买到的，但实际过程却非常艰难，也让我学到了一些奇怪的知识。

首先是在黑色男装形态手中的那把枪，我本以为搞一把没有实际发射功能的、一比一的模型枪应该不难，但一开始搜遍全网，却都只能买到1:2.05的模型。在纳闷之中我查了下原因，才知道现在对枪模的管制已经如此之严格，哪怕是外形一样没有功能都不行，为数不多可以等比例的枪模还必须报备，交由专业的剧组团队保管。我虽然可以理解这政策，但着实也带来了很多麻烦。当然好在经过大量的搜索和碰巧，最后我还是找到了一把金属外壳、等比例的、可以发射软弹的左轮手枪，也算是有个好结果。

然后是GOTH女装形态手中的《圣经》，我本来只是想着搞个道具，想着这问题应该不大吧即便没有那买本书拿着也不是不行，结果无论是淘宝还是京东一搜索都发现根本没有结果。于是我在纳闷中又去查了下原因...嗯，原来如此，那也没招。最后我只能用家中那本海德格尔的《林中路》来凑合替代一下。

再者在国内电商网站上和“圣经”有着相似待遇的，还有手持的金属十字架。我已经不想再去查原因是啥了，就直接放弃了这个构思，换了种构图。

总之虽然遭遇了意想之外的麻烦，但也勉强算是准备好了所需要的道具，它们被我收拾了起来，静待着拍摄日的到来。

专访直播

在这第三次的拍摄日程前，还插入了一段《腾讯程序员》视频号对我的专访。这个专访缘起于今年二月内部的一个邀请，但由于疫情一次次推迟，直到现在才终于定下了日期。虽然还有少许风险，我还是决定义无反顾去了直播室。这首先是源于我对不可控性的厌恶——那是早已准备好的事情的一再延误，所派生出的那种悬而未决的感觉。再者，则又是一个宿命般的巧合，因为我忽然意识到——这次专访，不正好也可以算作是这《Project Self》的一部分吗？

“写真”静态地从外侧记录了我疏远和断绝于这个世界那封闭的“自我”，“访谈”则动态地自内部挖掘了我连接于这个社会那开放的“外延”。

直播的整体来看算是成功，即便是一开始由于我的小概率事故体质导致除了一些故障（笑），让直播整体延期了半个小时，导致流失了一些观众，但最后数据还是不错：

直播访谈录屏

访谈后续公众号发文

访谈结束的第二天，便是最后一日的拍摄了。

第三日

第三日比原计划晚了一些，但也正碰巧——那是近一周天气最好、没有雨的一天。这次拍摄起前两次有两点区别。其一是我叮嘱了X别拍那种文艺的感觉，早上就搞一些日常的记录，下午就好好拍剧情编排；其二，则是这次多了一个特别的摄影助手。

这个摄影助手并非和上次一样是X的学生，而是我的一个朋友。这位中大文学在读博士朋友（下称S）曾经鸽过我两次（笑），由于认知上相对接近，比较聊得来，所以认识了快半年还会不时聊聊天。当之前得知我要拍写真时，她觉得这种创作很有趣，就说要来给我当助理，但由于疫情封校遗憾错过。所以得知我还要补第三次，而她正好也能出校，便二话不说做好了计划。

日常

我们大概在九点半起了床，此时早晨阳光正好，我将滚滚从阳台抱了出来，开始了第一个场景的拍摄。在这个场景中，我的本意是体现出我在做独立游戏的感觉，显示器上的内容也正是如此：一个32寸的屏幕分成了四块，一块是Unity，一块是写逻辑的VS，一块是写剧本VSCode，一块是框架文档。

然而X似乎并没有回到我的意，而是直接从左前方，也就是显示器的背面进行了拍摄。当然我是可以理解从我侧后方拍的话，位置比较憋屈，所以也没有多说什么。我照计划装模作样敲起了文字，按理说这场景很快就应该过去，但这臭猫不知道犯了什么病，开始折腾。

“滚滚，你在干啥这么不配合？”我一边按住它的身子，一边将其拖回原位：“你个臭猫，我好吃好喝伺候着，看病花了我四五万，就配合我拍个父慈子孝都不乐意？”

但滚滚似乎并不能听进这些道理，反而更加变本加厉得想逃跑。

“哎...”看来它不吃硬的，只能来软的了。我将其抱回了原位，抚摸着他的头和下巴，让他逐渐冷静了下来，虽然还是满脸不高兴，但至少勉强静止，于是照片就这么诞生了：

第一张拍完后，剩下的几张倒是没什么特别好说的，打游戏那张的糖糖虽然也想跑，但好在比较小和轻，自然是逃不出我的魔掌（笑：

正片

拍完早上的日常照后已是接近中午，不一会S便到了小区楼下，我在接她的同时也去楼下趟花店，买了束郁金香来作为今天最后的道具。一切准备就绪，我们就打上了车，前往今天本来定好的目的地——81号摄影棚。

81号摄影棚是一个广东COS摄影圈内的朋友推荐的，我看了看它家的微博宣传图，觉得里面教堂这个景挺不错，后续虽然也和另一家对比了下，但由于感觉这家的态度比较好，也没想太多就定了下来，其收费是：两小时起订，一小时120，定金150。

本以为到了地方三个多小时即可结束今天的计划，但实际到了这个坐落于城中村后的棚却让我大跌眼镜：三楼小小的场地，随意凌乱摆放的破旧道具，不伦不类的两侧幕布，以及甩手不过问任何布置的老板。我们在不断调整布景，来来回回忙活了一个多小时后，大家都达成了确实没办法达到我想要的效果的共识，于是当断则断支付了两个小时的费用后及时撤离了。

撤离后的我们站在路上，已是接近下午三点。我们徘徊在原地，不知如何是好。按照我的规划，找一个真是的教堂，例如“圣心大大教堂”自然是最合适的，但这种地方显然不会让我们进去。

“要不我先申请入教，然后去拍，拍完了再退教？反正我比他们大对信徒对上帝的理解更深刻。”

“你可别扯了，人家是要让你信的，谁让你理解了。”

“哎...”

犹豫，踟蹰，打趣解决不了实际问题。但我忽然灵光一闪，找到了之前那家觉得态度不好而放弃的棚，在S一个电话得到对方回应后，我们便打了个车，火速去了那里，然后发现这确实是一个质量不错的实景棚。

“虽然还是不大，但这40平的实景棚看起来已经是广州能找到的最适合的地方了，就今儿拍完吧。”我们做出了决定，拍摄就这样开始了。

准备

这最后一次的拍摄，重点在于“情节”，情节需要演员出境铺就，而这些演员则是我的多个人格。既然是多个人格一起出镜，那必然就会伴随着技术上的合成，而合成，则需要固定的机位和固定的站位。

为了达成这个目的，我事先准备好了标签纸和记号笔，同时做好了每个情节、每个角色的序号编排，例如第一个场景的白衣少年是“WB S1”，第三个场景的黑衣少女是“BG S3”等等...写好这些标签后，我就需要把它们贴到地面上，来标记到时候我拍摄应当站在的位置。

图为S配合我演绎情节中的站位，同时我贴标签的场景：

准备结束后，拍摄便正式开始。我总共换了四身衣服，来表现四个人格，而每个人格也基本都有符合自己设定的单人照，以及最后那用于合成的十个场景。至于具体剧情，我就不文字描述了，只能说...我尽力了。

单人格

多人格

结语

经过了将近五个小时的漫长拍摄，除了最后的合成，整个企划终于宣告结束。老板人还是不错的，最后收了三个小时的钱，一小时180，加上妆娘的150，加起来共700。为了庆贺，我请二人吃了顿火锅，在整个庆功宴和最后的返程中，我们又闲聊了许多琐事：我个人在理想和现实中游走平衡的焦虑，X事业和生活间的挣扎和平衡，S学业和规划上的压力等等。想来这次聚餐与上次最大的区别，大概就是在于01年的学生妹子换成了94年的在读博士妹子吧，年龄相仿的三人在一起，讨论的话题自然也就现实了许多。也是因此，我再次意识到：无论外在和人设怎样表现出一种青春少年，但人生阶段确实是不同了。

在回到家中后的第二天，我整理出了S帮我站位的一些花絮发给了她，聊起整个拍摄过程，她直言：“我觉得你的优点挺多的，尤其是细致和认真。”

面对这个这个评价，我只能无奈一笑：“原来我展现给别人的是这样一种值得褒奖的品质吗？”作为一个标准的INFP，我太清楚自己的拖延和惰性了，但早已根植于我内核的“决定了就一定要做好”的诅咒，却让我不得不花很大精力去反抗我的本能。这一次次细致的规划和设计，无不伴随着极大的焦虑和数次的失眠，客观来讲这对我的身心造成了不小的负担。不但如此，我之所以会这么早就做好尽可能全面的规划，同时事必躬亲不喜欢他人插手，应当还是出于一种深刻的“不信任”——

似乎从某个时刻起，我就无法由衷得对任何人产生信任了，无论是朋友，还是父母，亦或是其他时刻的我自己。

自相矛盾，却又强行保持一致。有憧憬光明向其奔跑的一面，也有封闭于漫长黑夜隔绝一切的一面。是一个能很好运用逻辑和理性工作的青年，也是一个拥抱非理性在荒诞和虚无中挣扎的少年。口口声声说着完成最优先，却又无法真的脱离完美主义的陷阱。不断努力尝试扎根于现实的生活，却还是只能悬于空中无法真正得落到地上。

这样的我未来会成为一个怎样的人呢？会像五年前、十年前的我对现在的我的态度一样吗？我不知道。但我能确定的是，几年、十几年、甚至几十年后的我看到这个项目，一定会产生一个疑问吧：“这个时刻的我，也就是你，究竟是想记录什么，又想表达些什么？”

我现在能给出的回答是：“这些照片和访谈都是次要的。最重要的，是这整个记录的过程，是表达自我时的那些态度和情绪，是这不断重复的憧憬、尝试、失望、挣扎、渴求、补偿，以及在精疲力尽后却并仍不完美、满含残缺的‘结局’。”

“正如，你自己的一生。”

WebGPU实时光追美少女

dtysky — Tuesday, 05 Oct 2021 22:00:00 -00:00

作为一个老二刺螈，我进入这个行业的最初动机可以追溯到十年前打通了《Ever17》的那个下午，这个动机就是——美少女。做一个美少女游戏，是我人生的悲愿，而为了完成这个愿望，我必须要从头开始，学习编程、图形学、编写渲染引擎、乃至实现游戏引擎。而在硬件高速发展的现在，实时光线追踪成为了可能，同时Web平台上的新一代图形APIWebGPU提供了丰富的能力也可以让我们进行这样的尝试。

所以为了渲染一个美少女，我一边学习一边实现，最终完成了这个项目和系列文章教程。本系列文章将会论述如何用WebGPU来实现一个实时路径追踪渲染器，从一个简单渲染器为开端层层深入，了解经典路径追踪渲染器的各个部分，以及BRDF模型在路径追踪中的实现。

当然，最后因为性能太渣，真实感的美少女并没有被渲染出来，只能渲染一个LowPoly的Miku555

项目

项目的Github仓库为：dtysky/webgpu-renderer。

Demo为：Demo，注意目前需要最新的Chrome Canary版本，并且打开特定flag才行，详见项目的readme。

文章

概览介绍：将会对整个项目涉及的知识做一个综述。
WebGPU基础与简单渲染器：通过自己实现的一个简单渲染器来论述WebGPU的能力。
路径追踪-场景数据组织：针对路径追踪，如何组织场景数据，涉及到PBR材质、glTF、场景合并等。
路径追踪-管线组织与GBuffer：针对路径追踪，如何组织渲染管线，同时论述GBuffer的生成。
路径追踪-BVH与射线场景求交插值：如何构建BVH，以及如何在CS中求交。
路径追踪-BRDF与蒙特卡洛积分：论述如何在路径追踪中运用蒙特卡洛采样实现直接光照和间接光照，以及运用BRDF光照模型。
路径追踪-降噪与色调映射：如何对充满噪点的图像进行空间和时间的滤波，最后输出如何进行色调映射。
踩坑与调试心得：对于WebGPU这样一个实验性的API（至少当时），我是如何进行调试的血泪史（主要是CS部分）。

后记

由于本人水平有限，文章难免会有纰漏，欢迎各位在评论区积极指正。

以及即便是能搞这些了，我还是做不出来我的美少女游戏，哎......

报班学素描和水彩半年成果

dtysky — Saturday, 07 Aug 2021 00:00:00 -00:00

接近于连续学了半年吧。
太菜了，感觉啥都没学会，尤其是越到后面生活中哦出现了很多意外比较燥。
不过无论如何，算是努力过了，有了些基础，以后在想继续也可以有个底子了。

（这天赋搞啥艺术啊，还是老老实实想着能不能画美少女吧......

以下按照画的日期正序：

SEIN.JS - 渐进式Web3D解决方案

dtysky — Saturday, 18 Jul 2020 00:00:00 -00:00

SEIN.JS是我在支付宝工作两年的技能集大成作，我负责了整体的架构、整个Runtime（除渲染引擎外）的编写、全量注释的编写、整个官网的编写和所有文档的编写、Unity扩展的设计和编写、Webpack所有工具的编写以及大部分扩展的编写，还支持了许多业务（包括作为2020新春五福的3D部分负责人）。SEIN.JS现在已经完全开源，主要的介绍发在了知乎，这里做个存档：

SEIN.JS - 渐进式Web3D解决方案

亿级前端项目中的3D技术-支付宝2020年新春活动的背后

GIGA GJ2018作品-摩的大飚客

dtysky — Sunday, 08 Jul 2018 23:00:00 -00:00

Muddy Driver (摩的大飚客)

一个胡逼游戏。项目工程：Muddy Driver

需求

一个PC。
四个玩家。
四个手机。
良好的局域网。

如何游玩

Clone code, 运行:

npm install

打开 client/src/config.ts, 修改 url 为 ${your_ip}:4444，运行:

npm run build
npm run server

打开 ${your_ip}:4444/view, 出现LOGO：

在此画面点击：

使用手机扫描二维码，都就位后点击start按钮，进入游戏后，每个车要两个人操控，一个使用方向传感器控制方向，一个使用滑动触摸控制速度：

先到终点线的就算赢:

Staff

程序:

dtysky(H光)
greenSnot(虫合)

美术:

shishi(诗诗)
spot

主策划:

greenSnot(虫合)
陶然
 dtysky(H光)

My world

dtysky — Monday, 18 Jun 2018 22:00:00 -00:00

hana-ui - 一个清新二次元风格的React-UIKit

dtysky — Saturday, 24 Feb 2018 16:00:00 -00:00

hana-ui(官网，Github)是一个二次元清新风格的React-UIKit，使用ES6+SASS+Typescript开发，拥有丰富的组件用以构建复杂前端界面系统，目前已在Bilibili管理后台和一些前端页面进行了应用。

有兴趣的来点个Star吧www

初心

这个项目是在B站完成的，完成者是我和另外两个同事，其名字源于我和其中一位同事的一次饭后讨论，死宅嘛，总想要搞出一些东西为二次元啊业界啊做出些贡献，于是便有了这个UIKit，懂行的人一看hana-ui这个名字大概也就明白这个库是什么风格了。

其实不严格来说，这个项目在去年五月份差不多就完全完成并投入使用了，但由于公司等原因一直没有开发出来，而在这空闲的几个月我们将其升级到了React16，并添加了一些新的特性，并进一步完善了官网和文档。

定位

定位方面，由于我们团队都比较务实，比较讨厌现在吹来吹去的所谓“Design Language”，所以定位也就是一个单纯的React用UIKit，一个UI组件库。

设计

基本UIKit应该有组件的都有了。组件分为种子（seeds）、芽（burgeon）和花（flower）三部分，复合性层层递增。

风格方面，主题可配置，默认走清新风格。

代码方面。主代码走一套ES6加上一套Eslint（项目开始的时候还没上Typescript），不过补上了一套ts头可以和Typescript兼容。

测试暂时没有，但在复杂工程中过了很久了所以也算是得到了最好的测试。关于纯前端视图层的单元测试必要性问题这个见仁见智，我的观点是模型可以测，视图方面测试纯属吃力不讨好。

请帮助我们！

不过想必大家也发现了，现在UIKit整体的设计有些地方还有些糙，这个我们也很无奈。我不知道公司如何定位我们这个组件库，当时（现在也是）处于弱势的我们部门并没有为这个组件库争取到设计资源，所以设计也是我们三个自己操刀的。

让前端来做设计嘛，和让设计来写前端差不多，做到这样我们已经尽力了，所以在这里如果有专业的设计师死宅同学给出帮助我们是再欢迎不过了。

不过由于不被重视，所以这个库的开源和B站毫无关系，完全是hana-group自行维护，自由度也高一些。

二次元本就是一个去中心化的创作集群，由无数有爱人士共同贡献，在这一点上hana-ui也是一样的。
个人力量毕竟有限，所以希望大家能积极参与！

GGJ2018作品-EternalFlame

dtysky — Sunday, 28 Jan 2018 23:00:00 -00:00

第四次参加GameJam，职位从抱大腿的变成了主程（233

不过遗憾的是这次魔都居然分为了四个场子。。。人也分散开了，感觉氛围比上此心动的GGJ差（没有女装（逃

本来这次想休闲搞个20小时能做出来的，没想到还是爆肝到四五点了...虽然最后完成度还是有问题，不过好歹DEMO算是完整，也算不错了。

果然老了啊，选择自己基本没用过的引擎（phaser）现学现做（各种暴力代码）还是有点“i'm fucked”的感觉，不过好歹结果不错www

官网地址：

Eternal Flame

游戏地址：

Eternal Flame

源代码：

dtysky/EternalFlame

操作：

建议PC，PC打开后窗口拖到 9/16的大小，用键盘上下左右控制加速度。

移动端的话就用那几个按钮吧，不过注意要连续点按（时间不够没做完长按的

（下次在下一定要做黄油（每届都这么说的（逃

D2-现代前端-对视觉和交互的探索

dtysky — Sunday, 17 Dec 2017 23:00:00 -00:00

今年我作为分享者参与了阿里D2会议，做了一个关于B站近来对视觉和交互方面探索的分享。在这里，我将以一篇文章的方式，将分享里PPT的内容再论述一遍，算是加深印象，也方便未来鞭策自己。

PPT在此：现代前端-对视觉和交互的探索
 视频在此

圈内的大家想必都明白一个现状——现在的WEB前端圈子、尤其是国内的前端圈子，工程师们自己对前端工作的评价和用户对前端工作的评价其实是脱节的。也就是说，很多时候，我们自己觉得用了一个十分牛逼的技术，做了很多工程、架构上的突破，但用户却要么没什么感觉、要么反而觉得还不如原来的。诚然，我们可以用所谓用户的“惯性”或者“不懂”来麻痹自己，但这并不能解决任何问题。

个人来看，这其实和近年来前端的飞速发展和从传统领域一下搬运了很多概念有关。飞速发展并非不好，但现在来看，相比传统前端“直接服务于用户感官”的方向，大前端方向显然吸引了更多前端从业者的目光。这也不难理解，毕竟对于个人发展而言，掌握更多的技术资源总是好的，而且相较于传统前端的视觉和交互方向，大前端看起来能做更多事、更能被老板重视。可悲的是，这一点在国内很多时候也确实是事实——这样导致的结果就是我上面所言，前端从业者逐渐脱离了用户、不再去研究用户观感和交互，而是一窝蜂向着后端侵袭。

这使得当下的WEB前端处于一个尴尬的位置——抛弃了老本行，和后端抢饭碗。但本质上，在后端领域，我们其实也就是二把手，根本接触不到核心、也做不到核心。所以，我觉得抛弃“视觉”和“交互”这两个属于我们本职的技术是不合理的。我知道很多程序员都会觉得单纯粗暴的逻辑、优雅的工程架构更加有亲和性，这一点曾身为FPGA工程师的我也十分清楚。但我们也不能为做效果、探索交互麻烦就不去研究它，如果失去了这两样，我们前端的核心竞争力又到底是什么——毕竟只是写逻辑的话，后端或者算法同学不一定比我们差，对吧。

工程化确实要研究，如何让系统更加鲁棒也是必要的，代码规范、设计模式、基本数据结构和算法、FP等也确实需要学习，但那些是每个程序员都应该做到的，和前后端并无太大关系。我们真正的核心竞争力还是在于研究如何让用户更好地体验到新技术带来的感官冲击、带来的交互便捷，这才是我们的老本行。

所以这一年来，我在B站的工作基本完全由活动后台系统转到了大型活动开发，在这样的一些活动上，我得以运用一些新的技术、去做一些新的尝试。其中一个明显的例子在于在这些活动上我干掉了IE全家桶、安卓5以下、iOS8.3以下，这使得在做活动的时候也可以伸展拳脚。

而这也是我本次分享主题的来源——《现代前端——对视觉和交互的探索》。

本次分享分为几部分：

第一部分是我关于前面所做活动的回顾，技术分析我以前也放过了，主要是BML2017主视觉技术剖析、Bilibili《七夕之约 - Double;7》技术剖析还有下周要上线的圣诞活动（活动文章已经写好，等上线放出）。毕竟是一场技术分享，所以还是要有一些干货的。不过受限于时间，无法讲的太细，所以可能会有些同学觉得太散了，这一点可以利用我前面所写的文章补齐。
第二部分是对前端老本行在过去和现在状态的一个总结，描述了前端从单调页面到现在的SPA发展了许久，并且有了Electron和RN等使得WEB前端逐渐和桌面应用和APP等分担压力，抛出了一个问题——Web前端的下一步应该怎么走？能不能像大前端方向一样，从传统领域搬点东西？
第三部分则承接前面的问题，论述了本人在其他领域的一些见闻，道出了桌面应用、移动应用、数据分析和艺术几个领域一直以来的发展和趋势，指明了前端能走的路子。
第四部分则是审视自己，表明了Web前端的潜力和责任——我们拥有最普及的平台，所以有把新技术带给用户的责任，而且现在Web各种标准一个接一个出现，也带给了我们这些能力。
最后是以一个桌面、移动、VR三端适配，具有物理引擎的DEMO为例的展望，并分享了一些我觉得酷炫的网页例子。

综上，其实本人是有一个诉求、也希望前端大家能回归初心，不要放弃前端的传统任务、也就是那个初心（这么看起来这个分享更适合上一届2333）。当然，人各有喜好，不过其实一种技术的发展普及是必然依靠广泛从业者的努力的，如果大家都不去做了，那么——

当然，大前端方向还是要学习的，这已经成为了前端工程师的一个门槛，但在此之外，我么能做的、应该做的，还有更多。

【React/Flask】BlogReworkPro-Rework the BlogRework

dtysky — Friday, 14 Oct 2016 22:00:00 -00:00

Github工程在此：BlogReworkPro

重构BlogRework，这是此Blog迎来的第四次重构了，和上一次的间隔比预期要早一些，不过这种事早点没啥坏处。这次重构主要是重写了前端、修了一些后端的BUG，跟进ES6，用Eslint和Flow约束代码规范，上了React最佳实践全家桶并且实现了完美的服务端渲染，加了Memory Cache，样式换成了less，DOM语义化也做了，构建工具也换成了gulp，也就是说，上一次遗留的Feature基本都搞定了。这次重构对个人的能力提升显著，还是很值得的。

基础架构

添加了一些Bash和Npm脚本，并采用了新的以环境变量为基础的配置文件，二者配合使得开发发布更加轻松和工程化。
跨域访问控制。
正确使用了Forever.js使得进程守护更加完备。

后端

在生产环境下，使用tornado的wsgi框架来替代Flask自己的server，增强性能和稳定性。
使用virtualenv构建独立的python来隔离系统原生的python，屏蔽系统差异（虽然不如docker），详见install.sh。
增强了日志管理器，使其更加完善，详见Back/utils/logger。
将watchdog.observers.Observer替换为watchdog.observers.polling.PollingObserver，消去了一些BUG。
修复了一些写入数据库时的对比BUG。
实现了Memory cache，详见此文章：【Flask/React】此博客服务端的缓存实现。

前端

上了React + Redux + React-router + Immutable全家桶，详见此文章：【React/Redux/Router/Immutable】React最佳实践的正确食用姿势。
Less带我飞，取代了原生CSS，详见此文章：【Less】实现可选参数以及各种autoprefixer。
完全使用ES6语法，并使用Eslint和Flow来进行代码规范化约束，详见Front/.eslintrc。
将回调基本全部用Promise替换，回调地狱Bye~
消除了Jquery，改用superagent来做ajax请求，比如Front/src/action/source.js，消去了JS动画库的依赖，完全使用CSS3动画替代。
用Katex替换了MathJax来做Tex解析，自己写了自动渲染文章的转换器，详见Front/src/utils/renderWithKatex。
DOM结构语义化。
用Gulp替换了Grunt来构建Task，详见Front/gulpfile.js。
重绘了一些SVG图标，使其完美化，比如playstation.svg。
增强了主题，优化了很多细节，使其更加有设计感，比如pagenation，文章列表的样式。
将一些资源进行打包或者内嵌，对图片进行压缩，减少向服务端的请求次数，使得渲染更加流畅，比如字体和小图标这种就打入了两个文件并内嵌为base64，用webpack实现自动内嵌。
完美的服务端渲染，详见此文章：【React/Redux】深入理解React服务端渲染。
实现了Memory cache，详见此文章：【Flask/React】此博客服务端的缓存实现。

彩蛋

404页面：任意一个找不到的页面
打开控制台。

MoeNotes

dtysky — Friday, 20 May 2016 10:00:00 -00:00

MoeNotes

演示：
演示视频

Github:
MoeNotes

下载：
下载

介绍

MoeNotes是一个简单的日记写作软件（当然，我也用其写一些不是特别复杂的小说和文章），不同于印象笔记、Onenote、Leanote等，本软件没有这么大的野心，它所要解决的问题仅仅是“本地展示”，也就是在本地管理你的日志文件，并提供一个类似于Onenote的分类体验。
本软件使用Markdown作为笔记编写语言，适配GFM语法并增加语法高亮和数学公式，每一篇日记都会以.md文件的形式保存到本地而不是数据库中，用户可以自行选择如何同步这些文章以及将它们同步到多少地方，完全不依赖于平台，这也是我编写本软件而不使用现成日记软件的一个主要的原因。当然，对文章和分类进行拖动排序也是被支持的。除此之外，本软件还支持“即写即看”，“专注写作”和“专注阅读”三种模式，也可以进行主题的切换和自定义，还支持PDF和HTML的导出，由于是基于web进行得开发，所以扩展起来也十分方便和简单。

许可

[Flask/React/MongoDB]BlogReworkIII-如何搭建一个动态Blog

dtysky — Saturday, 12 Mar 2016 22:00:00 -00:00

项目源在这里
这是此Blog迎来的第三次重构了，使用Flask、React、Mongo、Express等将原先的静态网站完全替换为了单页应用，当然是响应式设计。重构的理由非常简单—这种简单也是源于我习惯性的随性而为。当然，虽然理由简单，一开始设想得也很简单，但实际做起来却又是另外一番景象了。通过这次重构，我最大的收获或许并不是技术上的提升，而是对工程周期的评估和把握能力的提升—作为唯一的管理和执行者，亲眼见证了一个工程是如何从两天的预想周期膨胀为一周、随后膨胀为半个月、最后膨胀为一个月的。作为一个能力平平的平常人综合征患者，或许只有这点坚持的精神还能拿的出手了吧（笑

Blog发展历程

建博客，也是要按照基本法的，你不能说建，你就建，总是想搞个大新闻，又没什么干货，这样，还不如纯粹装个逼，你说是不是？当年的我啊，还是太年轻，图样图森破，上台拿衣服，没什么审美，也没什么技术，所以，搞出的那个东东啊，自己觉得一颗赛艇，其实，在删的时候，比谁都快，搞得连个底子都没有留，到时候后悔了，我还是要负责的吧？

2014.05

由于未来找工作的考虑以及当时泛滥的助人之心，用初步可用的Python功底加上刚上手的Html + Css技术，在Pelican框架的帮助下用十天左右首次将Blog搭建起来。此次使用的是默认主题中的一个基于bootstrap的主题，嘛，标准的技术博客风格吧。当时还没有服务器和域名等等的概念，所以这个Blog只是被简单地托管到了dtysky.github.io上（现在已经无效）。

2014.06

对HTML+CSS有了更加深入的认识，第一次的重构开始。由于当时的审美还停留在一个比较low的水准，加上当时的中二还没有经过否定之否定这个螺旋上升的过程，所以无论是主题还是分类都比较不堪入现在的目，而且当时对很多东西还是不了解，基本所有的布局都是用静态图像完成的。不过值得一提的是，在这一次，我初步使用了JS—我对这个语言的初步影响并不好，觉得他的语法就是SHIT。
原始设计已经遗失，唯一还存在的就是这一篇当时的记录233：世界线启动。
看看当时的分类www（其实现在看来也蛮带感的，我还是挺喜欢的：

经验而谦逊的现实

雅致而耗散的诗人

矛盾而真诚的世界

纯粹而残缺的歌姬

平凡而美丽的生活

2015.02

半年后的春节期间完成。随着技术的进一步提升和更进一步的审美，加上中二的否定之否定的螺旋上升（不要在意期间发生了什么），便有了这一次的重构。此次重构主要是样式上的变更，首先将分类转换，然后修改了整体的布局，并基于jquery实现了一些动画。此次重构后的界面和现在的界面十分接近，不同的只有左侧动画（原先是先滑出左侧，再划回来）、播放器和一些载入动画，当然，最大的不同自然还是静态网站和动态网站的区别了。
不仅使界面上的修改，在此次重构中我注册了现在使用的dtysky.moe这个域名，同时将网站搬移到了DigitalOcean的VPS上，用NGINX作为服务器。此外还加入了Disqus的评论系统、bshare的分享系统以及各个搜索引擎的SEO。
这次做好了保留工作，老样式的网站保留在这里：
old.dtysky.moe

2016.02

又是春节期间，也是毕业后的第一个春节。在毕业的这半年内，我完成了一次离职，并从FPGA工程师转为了软件工程师（现在是WEB）。
某日，我发现我还是想要加一个音乐播放器在网站上的，所以也就需要将Blog变成动态网站，这就是为什么我花了一个月的业余时间的理由。。。

To(Never www)Do list

Server端的Cache

在现在的设计下，前端每一次的请求都会导致后端的一次数据库查询操作，并且对于那些有分页的、列举文章的页面，Client端会先从服务端拉取所有的文章简介，然后存储在前端的Cache中。这其实是不太好的，首先这可能会浪费一些带宽（当然，在GZIP的压缩下，对比JS和CSS文件这些数据量都是小CASE），其次比较重要的一点是会造成后端端数据库的查询压力，对于性能不那么强的VPS，这对并发还是有比较大的影响的。考虑到Blog的文章更新还是相对较慢的，所以一个简单Cache的存在还是可以允许的。
具体的设计，无非就是在某些数据被请求时先去找Cache，如果没有就查询数据库并将其加入Cache，然后在文章有更新时将Cache清空即可。

用Redux和ES7对前端再次重构

现在的设计对SEO并不友好（虽然我已经使用了React-router的服务端渲染（由于有AJAX存在，所以单独使用对SEO并没什么用）并且使用了fragment这个meta tag提示搜索引擎这是一个ajax页面（但这毕竟只能对谷歌有效）），所以我需要一个方法来解决React服务端渲染和客户端的数据同步问题，这个可能只能看看REDUX这样的框架了。
至于ES7么。。。我觉得我暂时无法用ES5写出干净的前端代码，而下一次重构的时候ES7也差不多出来了。。。

本次设计

后端

架构

用Python实现。
作为Blog的后端，无非由六个方面需要考虑，其一是对原始文章的解析，其二是数据库管理，其三是文件监控，其四是Sitemap和RSS的生成，其五是WEB服务器，最后一个就是作为辅助的日志管理了，以下是一张基本的设计框架图，然后根据这张图来简单介绍我此次的设计和用到的技术。 //src.dtysky.moe

文章解析

手写HTML文章是笨蛋才会去做的事情（虽然我的确手写过一段时间233），现在一般Blog文章的编写都是使用Markdown或者Restructuredtext，冰鞋比起常常用于Documents编写语言的后者，前者由于语法简洁等原因使用范围更广，所以本Blog的文章使用也是Markdown。
Markdown固然足够满足文章正文的需求，但有一些meta元素，比如文章标题、作者、分类、时间等要素还是需要自己去想办法添加的，我这里借鉴、或者说是延续了Pelican的设计，将所有的meta元素添加到了文章头，和正文用空行隔开，分别对meta和正文进行解析，最后汇总，所以最后编写的文章实际上是这样的：

Title:test
Authors:dtysky,x
Tags:test1,test2

#h1
...

要注意的是这里并没有Category这个标签，这是因为为了延续之前的设计，并且为了简化工作（其实就是懒...），所以直接将该文章所在的目录作为了分类；除此之外，Authors这个标签也不是必须的，如果没有，解析器会使用配置文件中的default_author代替。

Meta解析

Meta解析的实现是十分简单的，无非就是将meta的tag和value作为键值对写入一个hashtable中，单考虑到日后的可扩展性，如上面的结构图所示，我将其分为了两个部分：

MetaParsers：用于将原始的以字符串的形式存在的meta文本解析为一个hashtable或者任何需求的数据形式，所有parsers都继承自MetaDataParser父类，文章解析程序在初始化的时候会载入每一个子类并创建一个对象，并在解析时调用该对象的parse方法，对该对象对应的meta元素的值进行解析，并返回被解析过的数据。

SlugWrappers：用于生成已经解析过的metadata的url，也就是会在最终的url里出现的、表征该metadata的唯一定位符，这个可以按照喜好自己来，我大部分是默认为不转换（也就是url和原始数据一致），诚然这可能会带来一些SEO问题，但为了防止冲突和便于日后管理，我舍弃了原先Pelican自带的大写转小写、汉字转拼音的做法。这一步会在parse完成后执行，所有子类对应对象的warp方法会被调用，将输入的每一个单个的meta元素转换为url。

通过这两部的解析，原始的meta文本就被转换为了可以供后续流程处理的数据，在我自身的设计中，可能会出现在url中的metadata都会有view和slug两个元素，一个用于显示，一个用于定位。
得益于这种设计，meta都是可扩展的，如果我想添加一个meta，只需要分别从MetaDataParser和SlugWrapper继承一个子类，简单重写一下其中的某些成员函数便可以实现。

Markdonw解析

这里直接使用了Python的Markdown库，但另外加入了Pygments语法高亮插件，有需要的时候也可以加入其他插件（比如表格）。

数据库管理

文章解析之后便需要存到地方，这个地方自然就是数据库了（当然静态页面也可以，不过那并不是此Blog的做法），这里选取的是MongoDB，原因么...最近用得比较多，顺手就这么选了。这个数据库本身没有什么说的，用起来还是很简单，这部分主要难度还是在于如何管理数据库的写入（这可后面要说到的文件监控有很大关系），考虑解耦的原则，这一部分只负责接受数据和指令对数据库进行操作，不负责决策。
和上面的设计一样，我设计了一个DatabaseWriter父类，所有的Meta和正文的写入类都继承自这个父类，之后可以重写父类的方法来完成逻辑，在最基本的设计中，每个子类都拥有三个对外的接口函数insert、update和delete，分别用于想数据库中插入一篇文章、更新一篇文章或者删除一张文章，这是一种增量式的设计，保证每次只会对北改动过的文章进行解析和写入。这一步在文章解析后被执行，最终被调用的就是上面提到的那几个方法，接受解析过的完整文本，将数据写入子类对应的表中。
这里提一句，被写入数据库中的记录是包含文章文件的路径的，这会在后面用到。数据库的设计在此：
Database desigin

文件监控

文件解析和数据库管理都搞定之后，缺少的就是提供输入激励的东西了。这里采用的数据驱动的设计，程序监听文件的状态，在状态发生变化时响应这些变化并作出响应的处理。
这里选取的是Watch dog这个系统状态监听库，其中的FileSystemEventHandler这个模块中提供了良好文件状态事件支持，只需要指定一个监听的文件夹并去重写它预设的on_create等方法便可以实现逻辑（这里需要注意，在OSX和LINUX下事件触发的状况不同，所以配置文件中才会有is_linux这个选项），设计如下：

当文件新建时，触发on_create事件，解析文章并将其insert入数据库。

当文件被删除时，触发on_delete事件，通过文件名找到数据库中该文章对应的记录，反向找到正文和所有meta，随后调用所有writer的delete 方法。

当文件被修改时，触发on_modified事件，解析文章并将其update入数据库。

当文件被移动时，等价于一次删除和一次新建。

如此，文件的解析部分基本就完成了。

Sitemap和RSS

这两个基本是Blog的标配了，一个用于SEO一个用于用户订阅，其实也没什么难度，就是每次文本解析完毕后读取数据库中所有的文章根据格式生成几个XML文件，稍微研究一下二者的各市标准就行，不过这其中还是稍微有点坑的：
在XML中插入HTML需要转义：

entity_ref = {
    "<": "&lt;",
    ">": "&gt;",
    "&": "&amp;",
    "'": "&apos;",
    '"': "&quot;"
}

考虑到这二者实在没有什么扩展性的必要，我就直接写死了，RSS生成的有全站、作者和分类。

WEB服务器

数据源准备好之后就是想前端给数据的事了，所以需要开一个WEB服务器。这里选取了Flask作为服务器框架，路由规则也比较简单不再赘述。和上面大多数设计一样，每一条路由规则都对应一个继承自WebHandler的父类，这个父类又继承自Flask中的View类，父类通过重写View类的dispatch_request方法来响应请求（采用这种方式来做路由而不是装饰器的方式是为了便于后面路由的统一管理）。
程序初始化时，程序首先会找到WebHandler的所有子类并注册路由，之后接收到请求时，程序首先会找到该条路由规则对应的handler对象，然后调用它的dispatch_request方法，dispatch_request方法又会调用_handle方法进行最终响应的实现。

日志管理

在主体功能之外还有一个重要的功能是被需求的——日志管理。系统需要有全局的logger来记录关键的信息同步打印并输出到文件，由于这个比较简单我就自己造轮子了：

logger输出的信息有三个等级—error、info和warnning，分别打印为不同的颜色并输出到不同的文件。

每天新建一个log文件便于分析。

至此，后端的实现基本完成。

前端

Node.js实现。前端主要分为两部分—Client和Server，其中Client是大头，负责和用户进行交互，Server负责将Client端需求的数据传送到用户设备。在本设计中Server还有服务端渲染和SEO的职能。
当然，一时由于经验，而是由于。。。ES5也没规范到哪去，感觉JS这个语言还是有很多缺陷的，ES6似乎好了很多，嘛。。。先凑合着吧，code style的确很烂我承认。

工具链

前端开发最好还是有一个用于开发测试的工具链，这对于效率的提升是立竿见影的。这里我选择了Grunt和Webpack，前者用于自动化事务管理，后者用于打包和测试项目。我的设计如下：
//src.dtysky.moe

其中debug、server-build、client-build三个事务分别用于测试、打包Server端程序和打包Client端程序，build事务包含了前两者，简化操作。

Client

Client负责的是用户交互，使用了React和React-router作为View和前端路由，具体的设计如下：

View

基础显示，包括整体视图的布局和一些动画效果，页面属于响应式设计，为PC和移动端分别走了适配，页面组件包括：

Home，显示所有文章的列表。

Authors，显示所有作者的列表。

Tags，标签云。

Author，显示某个作者所有文章的列表。

Tag，显示某个标签所有文章的列表。

Category，显示某个分类所有文章的列表。

Article，显示文章。

Title，标题栏，显示所有分类。

Left-image，左侧图像滑窗。

Menu和Menu-phone，前者在PC端的右下角，后者在移动端的上面。

Footer，移动端的最下方。

Music-player，音乐播放器。

动画效果包括：

元素色彩和基本位移操作，使用CSS中的transition实现。

元素旋转和特殊运动，使用animation和keyframe实现。

左侧的图像滑动，使用Velocity-react库实现。

在页面资源方面，将原来的png图标全部封装成了字体和svg文件，找不到线程的就自己手撸...最终素材大小和请求次数的确降低了许多，封装工具在这里。

等待、错误和404

这些细节的地方也是需要关注的，具体是什么效果就自己试吧www：

等待界面，自己的log加上半圆边框不断旋转，“少女祈祷中”是什么梗就不说了，这里其实是想搞一个抽象的、机械齿轮转动的效果。

一般错误界面，未知错误的界面，一般看不到的，基本就是机械齿轮卡壳的感觉。

404界面，直接在这看吧

Meta修改

虽说是单页应用，但每个不同的页面有自己的meta tag还是很重要的，比如title、keywords之类的，这里我是用了React-helmet组件对他们进行了修改（当然，本质上应该还是DOM操作就是，图个方便。）

分享组件

在每篇文章的右上角都会有一个分享的图标，本次重构去掉了对bshare的依赖，自己写了个分享组件，觉得设计的还成，九大社交网站+本页面二维码。

音乐播放器

这也是导致本次重构的元凶了，这个播放器基于APlayer，并做了些许的定制性修改。播放源需要自己在配置文件中进行配置，在当前设计中每次修改完音乐列表就必须重新打包发布一遍Client端的代码，不过把它提出来也不是什么难事，有时间吧。。。
在我自己的设计中，这个播放器还和文章meta中的music标签关联，当文章中存在这个标签时，播放器会重新载入文章中制定的音乐列表进行播放，否则就会载入配置中默认的列表。

前端路由

这个是用React-router实现的，也是单页应用的精髓，有了它，伪静态的页面便是轻而易举，他会抓取浏览器的历史并完成响应的路由，页面每次只会更新路由指定的区域。

缓存

为了避免请求过多，这里建立了一个Cache用于缓存之前向后端请求过的数据，在页面每次加载之前程序会首先从Cache里取数据，如果没有才会请求并将获得的数据加入Cache中。

其他

Google analysis和Mathjax的支持以及......彩蛋。
我认为彩蛋是一个网站必须的东西，它可以出现在Meta里，也可以出现在Code的Comments里，而我，则是将其放在了Console...

Server

Server框架是Express，也算是从主流了，主要完成：

静态资源

用Express自带的static中间件实现，此条规则用于访问静态资源。

服务端渲染

对所有的正常页面请求，使用React的renderingToString方法在服务端进行首页渲染，遗憾的是对于本设计这并不能解决SEO问题（前面说到过），所以，就当是提升用户体验吧。

针对搜索引擎的页面

每一条正常的url都对应着一条特殊的url -> (/xxx -> /jade/xxx)，这个页面是为搜索引擎（或者说就是谷歌）提供的，具体原理是在正常页面的meta中加入一个fragment的tag，谷歌找到这个tag后就会在原始url后加上?_escaped_fragment_，我们可以在Server捕捉它并将准备好的另外一个页面提交给谷歌。我所准备的页面是用jade作为模板的，并用requests向后端发起请求来获取数据。这些页面去掉了动画和播放器，基本可以看做纯粹由HTML+CSS构成的静态页面了。

日志管理

这里同样需要一个Logger，我选取的是Tracer这个库，将其封装为了一个中间件。

到此，前端基本完成。

其他

NGINX作为反向代理服务器，Forever.js做进程守护。

毕设PPT

dtysky — Sunday, 07 Jun 2015 16:00:00 -00:00

将鼠标指向框内即可。
设计的是到一定的步骤按"Return"返回，点下一个大分类。
没有可以按的时候按空格或者方向键。

毕设项目V1.0发布

dtysky — Tuesday, 02 Jun 2015 22:00:00 -00:00

这部分是致谢，放在这里算了。。。虽说最后论文从六万被砍到一半。。。嘛，没经验废话太多吧。

项目主页在这里：
FPGA-Imaging-Library

论文在这里：
F-I-L 论文

在写完论文的最后一个字时，我感到了莫大的喜悦和恐惧，喜悦的是作为毕业设计的部分终于算是比较完美得被完成，恐惧的是这个开源项目要想存活下去，还有很多东西需要完成，而我不知道自己是否有这个精力和决心。
四年前，我来到了这个东南大学，一年的懵懂和迷惘之后，感谢黄安杰同学的引导和鼓励，我走了出来，开始利用学校基于的资源和平台认真学习技术。一晃便是三年，三年间，我完成了一个大型SRTP项目，在本院张小国老师、电子学院刘新宁老师和机械学院邓老师的热心指导下，自学了软件、机械、硬件设计方面的众多知识，这也为我的毕业设计打下了良好的基础。
十二个月前，我参加了本校和Xilinx合作的暑期学校，在一个月的学习和研究后主动成为了Xilinx的实习生，在做了一些工作之后，最终决定在Xilinx完成毕业设计，这要感谢王立辉老师和陆家华经理，给我提供了去做自己想做的东西的机会。
这个项目最初是以设计一个五子棋系统为导向的，但是很遗憾由于摄像头设备的原因无法完成完美的去噪，而当意识到之时时间已经不足以从头再来了，所以我选择进行转型，世界上有用轮子的人，但也有造轮子的人，而在FPGA的图像处理方面，虽然已经有了一些公司，比如NI的FPGA图像库，但是基本都是闭源的，都需要在支付不菲的费用之后获得授权。所以，出于对开源项目的热情，我选择去实现一个开源的FPGA图像处理库，并竭尽所能让其标准化和规范化，对用户提供友好的测试流程，这也算是对将进入的工程界做一次前置演练吧。在协议方面，我选择了LGPL协议，选择这个协议的原因是——我希望有更多的人可以使用它，但是拒绝将其本质上的商业化，虽然可能也只是我的一厢情愿吧。发布选择了建立博客所使用的Pelican框架，波形图使用了Wavedrom进行绘制，同时感谢Github的Student Developer Pack，提供了一年免费的Digital Ocean的VPS，用于搭建项目主页。
再次感谢王立辉老师、陆家华经理和和Xilinx中前辈的指导，让我能够最终完成计划中的任务。
最后，向提供了测试图像的画师表示感谢：

月岡月穂 LM7 cotta 041 H2SO4 パセリおにねこ色原みたびぜろきち方向錯亂あきのん初心社

Message board for FPGA-Imaging-Library

dtysky — Monday, 04 May 2015 02:00:00 -00:00

Progress:

Building documents...

What ?

F-I-L is a open source library for image processing on FPGA, it already contents many useful operations, and is updating. All the operations are packaged to IPCores, and of course they follow a same and standardized interface, moreover, each of them can work on piplines-mode and req-ack mode.
F-I-L是一个FPGA平台的开源的图像处理库，已经拥有了许多常用操作，并在不断更新中。这些操作被以IP核的形式进行了封装，遵循同一种规范化的接口，同时具有流水线和请求响应两种使用模式。

How ?

Certainly, all IPCores have their software simulations, functional simulations and testing on board, the same folder structure and interface can make user do simulations and testing conveniently.
大部分IP都拥有自己的软件仿真、功能仿真和板上测试，并且具有相同的文件结构和接口，能够让使用者很方便得进行测试和仿真。目前IP形式只支持Xilinx的Vivado套件，不排除未来会向Quartus搬移的可能。

More informations are here.
更多信息请看这里。

My Resume

dtysky — Tuesday, 28 Apr 2015 10:00:00 -00:00

Tianyu Dai

E-Mail : dtysky@outlook.com

Homepage : dtysky.moe

Github : dtysky

Skills

Platform:

FPGA, PCB, Software, Machine

Tools：

Expert : VHDL, Verilog, SystemVerilog, Python, Html, Css, Cadence
Competent : C, C#, JS, Matlab, AutoCad
Average : Unity3d, AE, PR, PS

Knowledge background：

Machine vision, CPU, Embedded system

Major Projects

梦见星空之诗 - Aria der Freiheit und des Seins：

Discription：An indie game。
Size: Large
Role：Planner, Writer, Programmer
Progress：Refactoring the scenario
Used skills:
Writing, Python, Ren'py
Source: Closed source
Completed work：

Game script parser

Manuscript for game, 700000 words

system and GUI for game

3D Displayer：

Discription：An 3d displayer based on a high-speed rotation led array
Size: Large
Role：Work individually
Progress：Basically finished
Used skills:
PCB, FPGA, C, C#, Autocad
Source: Controller，PCB，Machine
Completed work：

mastered Cadence suite, designed a 120*114 LED array composed by 0603LED, PMOS, NMOS the pixel density is 15.2d/cm^2. At the same time, I finished the controlling circuit that integrates trigger, register, power, and the control of the LED array. It has a 4-layer structure with high density wiring. The manuscript is mainly wrote by python, which improved the mapping efficiency

learned to use FPGA; using a series of Cyclone IV components provided by Altera, with VHDL, I've finished:
1) DDR2 controller, starting from sketch. Coding with Testbench, completed the packaged data testing with Modelsim, also succeed the on-board test
2) LED controller, starting from sketch. Using ROM completed the on-board test
3) Learned to utilize the high-speed USB chip cy68013 on slave-fifo mode, finished the FPGA controlling component and tested on board

With C#, using the API that is provided by cy68013 chip .net, utilizing object-oriented, multi-tasking ability, etc programmed the host computer

With C, designed the firmware for Cy68013

Designed the mechanical parts, includes the base, the coupling, and the scaffold for the LED array (AutoCAD)

Matlab based 3d images slicing

Game script parser：

Discription：An parser which can convert a DSL(Domain Specific Language) to Ren'py scripts, the DSL was designed by myself.
Size: Normal
Role：Work individually
Progress：Basically finished
Used skills:
Python, Ren'py
Source: Gal2Renpy
Completed work：

Learning ren’py(a game engine) and python

Designing a DSL(Domain Specific Language), completed the source parsing and mapping with ren’py script, then migrating the User Interface, it has good expandability

A plug-in for sublime-text, improving the input efficiency

FPGA Imaging Library：

Discription：An indie game。
Size: Large
Role：Work individually
Progress：Building
Used skills:
FPGA, Verilog, Systemverilog, Python, Image processing
Source: FPGA-Imaging-Library , and will be published here: fil.dtysky.moe
Completed work：

Graying, Threshold, Enhancement

Character output (Paused)

Frame controller, Rows generator, Window generator

Mean fitter, Rank fitter, Erosion, Dilation, Template matching, Auto threshold

Harris

Pan, Scale, Mirror, Crop, Roate, Shear, Affine transform

More...

My Homepage：

Discription：A blog for recording my learning experience
Size: Small
Role：Work individually
Progress：Done
Used skills:
Writing, Python, Ren'py
Source: Closed source
Completed work：

Learning about pelican(Based on jinjia2), css, html, js, bulit on VPS。

A sample MIPS CPU：

Discription：A sample single cycle MIPS CPU, designed with verilogHDL, bulit on xilinx vivado, for XUP(Xilinx uinversity project)
Size: Small
Role：Work individually
Progress：Done
Used skills:
FPGA, Verilog, Systemverilog, Python
Source: SIMPLE_MIPS_CPU
Completed work：

Designed and tested ALU, REGFILE, CONTRLO_UNIT, DATAPATH, INST_MEM, DATA_MEM modules, and connected them for a CPU which is used for functional simulation

Designed and tested KEY2INST, SHOW_ON_LED modules, and connected them for a CPU which is used for testing on board

Education

2011.08 - Now
Bachelor Southeast University(China), Instrument Science And Engineering College – Control Technology And Instruments

Record

2014, HackShanghai No.3 (OpenTTT, Member)
2014, 36kr Nanjing hachathon No.4 (Stars, Leader)
2014.10 - Now, Xilinx R&D Intern

Hobby

Reading, Music, Writing。

体三维显示器-FPGA控制部分

dtysky — Sunday, 22 Mar 2015 19:00:00 -00:00

此部分代码在：
https://github.com/dtysky/3D_Displayer_Controller/tree/master/VHDL_PLANB
体三维显示器为真三维显示的一种，即可以在真是的空间内显示一个三维的图像，图像占据一个真实的三维空间，不需要借助任何辅助视觉器件，我采用的方案是二维LED点阵的旋转，LED点阵为自行设计，最后是FPGA的控制部分。
名为PLANB，顾名思义，这其实是一个妥协的方案，原本方案是USB（cy68013）+DDR2，本来也实现的差不多了，但一开始忽略的某个问题直接延续到了最后，嘛，usb那块的教程以前写过了:
http://dtysky.github.io/tag/68013.html
至于DDR2控制器的编写教程和仿真，有时间再说吧。

1.LED阵列控制

LED阵列控制需要配合LED阵列的电路设计，也就是buffer到trigger的模型，同时还要考虑到由于电路板不完美造成的噪声等等。
1.扫描流程:
配合LED阵列电路的设计，刷新需要按照以下流程进行：

2.状态机：
根据扫描流程和整体方案设计状态机,由于没有什么特别的需求，所以只设计以下几种状态：

rst：复位
free：IDLE状态，初始化或者复位后的状态
work：工作状态

初始化时进行复位，复位结束跳转free状态，在free状态时如果接收到begin信号则跳转到work状态，开始工作。

3.扫描注意事项：
扫描时，由于电路设计不完美所以可能会出现串扰现象，也就是当某一行有效时可能会让其他行同时有效，行和列之间也可能会出现这样的现象，为了避免这样的情况发生，需要采取一些软件上的措施，我采用的方案是在每一次进行列变换前先对前一行进行消隐，由于行有效是在某个信号上升沿的时候送出（trigger的时钟信号），所以在正常显示时下保证此信号为高电平，在切换时或者消隐时在进行一下High->Low->High的变换，构造一个上升沿，经测验，该方案有着很大的效果，噪声大大减小。

LED控制部分的代码在这里：
https://github.com/dtysky/3D_Displayer_Controller/blob/master/VHDL_PLANB/LED/LED.vhd

2.图像解码

图像解码，也就是对三维切片编码后的每一帧压缩图像进行解码，由上一篇文章：
体三维显示器-Matlab的三维切片
可知，每一帧图像存的实际上是发亮点的坐标值，这就需要一个解码单元来这样的数据进行解码，转换成可以LED可以显示的位图。

1.解码流程： 解码基本流程如下：

2.状态机：

整体流程可以分为以下状态：

read_next：读下一个坐标点，转入judge状态
judge：判断当前点坐标是否与上一个坐标的纵坐标相等，如果是转入set状态，否则转入do_write状态
do_write：将上一行写入fifo，同时跳转到clear状态
set：将当前行的x置1
clear：对当前行，当前x坐标前的所有点写0

如此，便可以完成解码。
代码在这里：
https://github.com/dtysky/3D_Displayer_Controller/blob/master/VHDL_PLANB/DECODER/DECODER.vhd

3.整体

整体，即把解码单元和扫描单元连接起来，这里采用的是双缓存模式，也就是说：

实例化fifoA和fifoB两个fifo，当A填充完成后开始扫描，A在提供扫描数据时B填充数据，B扫面时A填充，这样可以保证总是有数据输出，这其实是一个宏观上的流水线：

然后，整个控制部分就完成了。

体三维显示器-机械部分

dtysky — Sunday, 22 Mar 2015 14:10:00 -00:00

体三维显示器的机械工程：
https://github.com/dtysky/3D_Displayer_Machine

体三维显示器为真三维显示的一种，即可以在真是的空间内显示一个三维的图像，图像占据一个真实的三维空间，不需要借助任何辅助视觉器件，我采用的方案是二维LED点阵的旋转，LED点阵为自行设计，这里记录了如何设计一个机械结构让LED阵列旋转起来。

1.设计

机械部分分为底座、联轴器、电刷以及PCB支架四个部分，同时还涉及电机的选型。
1.电机:
电机主要要考虑的是负载问题，本装置轴向负载大约为2KG，大约10cm的旋转半径，考虑到成本和够用就行的理念，最终选择了一个120W的直流电机作为驱动源。

2.底座：
底座，也就是放置电机的机械结构，考虑到一般的钢板物理属性（5mm厚度)，如果将电机的底部触地，直接放在底座之上，肯定会导致不稳妥的情况出现，所以这里选择了使用拱形吊桥结构，也就是将电机吊在底座上面，以此稳底座的下盘。后来出于需求，又在底座下面加了一个大钢板，进一步稳定。

3.支架：
支架的作用是稳固LED阵列，给其提供支撑，基本设计是一个L型的折弯，由于面积比较大，如果直接上的话会有相当的重量，导致负载过大，所以对其实行了挖空工艺，将主要版面的中间部分挖空来减轻重量。
支架的主要部分是为了配合LED的螺丝孔固定阵列，下面的部分则是为了和联轴器进行连接。

4.联轴器：
顾名思义，连接电机的轴和PCB支架，这个的设计主要考虑到电机轴的构造。联轴器分为两部分，上面是和支架连接，下面则是和电机的轴连接，和支架连接的部分只需要根据支架底部的孔钻孔即可，和轴连接的部分也需要打几个孔，不过是为了和轴做紧固连接，这个轴属于一侧削平靠摩擦力禁锢的那种，所以可以用逻辑拧紧进行固定。
联轴器上下两个部分的连接可以使用螺丝进行，没什么特别的。

5.电刷：
为了解决旋转供电问题，解决这个问题一般有电刷和无限供电两种方式，考虑到风险和电流问题，最终选择了电刷的方案。在联轴器上面放一个集电环，然后通过自己设计的电刷与集电环的连接来供电，集电环是铜质材料，电刷是石墨，实测效果良好。

2.生产

大学好的一点就是工培中心，以下皆在工培中心和学校工厂加工。

1.电机:
购买所得：

2.底座：
注意各个部分的尺寸都必须到位！

3.支架：
挖空由于并不要求十分精确，所以采用了很一般的工艺，没有必要上线切割：

4.联轴器：
分成两个部分！CAD图纸和最后成品有区别：

5.电刷：
可调节式设计：

3.合体

机械部分总共花费约800，整体良好，整体如下：

体三维显示器-Matlab的三维切片

dtysky — Sunday, 22 Mar 2015 13:00:00 -00:00

体三维显示器为真三维显示的一种，即可以在真是的空间内显示一个三维的图像，图像占据一个真实的三维空间，不需要借助任何辅助视觉器件，我采用的方案是二维LED点阵的旋转，LED点阵为自行设计，这里记录了三维切片方面的东西。
老实说这只是一个无奈的方案，因为各种各样的原因吧，比如时间和优先级之类的，现在只能切规则几何体，并且要手动输入坐标对。
同时由于没有使用矩阵运算，所以切片会很慢。。。嘛，暂时就这样了，基本所有切片算法的思路都是这样的。

1.实现

分为定义端点、获取边界、构造边方程、构造切片平面并切片、平面坐标映射、坐标系变换、去归一化几个部分
1.端点定义:
这段代码定义了一个规则正方体的十二条边：

p=zeros(12,2,3);
p(1,:,:)=[[-1.6079,-0.4078,-0.4982];[-0.4690, 1.0140,-1.3235]];
p(2,:,:)=[[-0.4690, 1.0140,-1.3235];[ 1.0920,-0.2363,-1.3235]];
p(3,:,:)=[[-0.0470,-1.6582,-0.4982];[ 1.0920,-0.2363,-1.3235]];
p(4,:,:)=[[-0.0470,-1.6582,-0.4982];[-1.6079,-0.4078,-0.4982]];
p(5,:,:)=[[-1.6079,-0.4078,-0.4982];[-1.0920, 0.2363, 1.3235]];
p(6,:,:)=[[ 0.0470, 1.6582, 0.4982];[-0.4690, 1.0140,-1.3235]];
p(7,:,:)=[[ 1.0920,-0.2363,-1.3235];[ 1.6079, 0.4078, 0.4982]];
p(8,:,:)=[[ 0.4690,-1.0140, 1.3235];[-0.0470,-1.6582,-0.4982]];
p(9,:,:)=[[-1.0920, 0.2363, 1.3235];[ 0.0470, 1.6582, 0.4982]];
p(10,:,:)=[[ 1.6079, 0.4078, 0.4982];[ 0.0470, 1.6582, 0.4982]];
p(11,:,:)=[[ 0.4690,-1.0140, 1.3235];[ 1.6079, 0.4078, 0.4982]];
p(12,:,:)=[[-1.0920, 0.2363, 1.3235];[ 0.4690,-1.0140, 1.3235]];

2.获取边界：
确定整个立方体的边界范围，以此作为方程解的定义域：

tmpx=p(:,1,1);
tmpy=p(:,1,2);
tmpz=p(:,1,3);
tmpx2=p(:,2,1);
tmpy2=p(:,2,2);
tmpz2=p(:,2,3);
xmax=max([max(tmpx),max(tmpx2)]);
xmin=min([min(tmpx),min(tmpx2)]);
ymax=max([max(tmpx),max(tmpx2)]);
ymin=min([min(tmpy),min(tmpy2)]);
zmax=max([max(tmpz),max(tmpz2)]);
zmin=min([min(tmpz),min(tmpz2)]);

3.构造边的方程组：
由于任意一条空间直线的方程都可以表现为：

a11*X + a12*y + a13*0 = a14
a21*x + a22*0 + a23*z = a24

这样的形式的方程组，所以对于每一个边，需要算6个系数：

a=zeros(length(p(:,1,1)),3,4);
for i = 1:length(p(:,1,1))
    x1=p(i,1,1);
    x2=p(i,2,1);
    y1=p(i,1,2);
    y2=p(i,2,2);
    z1=p(i,1,3);
    z2=p(i,2,3);
    %x,y
    a(i,1,1)=y2-y1;
    a(i,1,2)=-(x2-x1);
    a(i,1,3)=0;
    a(i,1,4)=(x2-x1)*y1-(y2-y1)*x1;
    %y,z
    a(i,2,1)=0;
    a(i,2,2)=-(z2-z1);
    a(i,2,3)=y2-y1;
    a(i,2,4)=(z2-z1)*y1-(y2-y1)*z1;
end

4.构造切面并切片：
由于本设备是按绕中轴旋转，所以构造的切面应当符合“每旋转i度”构造一次的规则，本次设置为没旋转一度切一次，总共360切片，由于旋转过程中出现的对称现象，所以实际上只需要切一半（180度）即可：

res=[];
ii=1;
for i = 1:180
    b=[tan(deg2rad(i)),-1,0,0];
    for j = 1:length(a(:,1,1))
        f1=strcat( num2str(a(j,1,1)),'*x+',num2str(a(j,1,2)),'*y+',num2str(a(j,1,3)),'*z+',num2str(a(j,1,4)));
        f2=strcat( num2str(a(j,2,1)),'*x+',num2str(a(j,2,2)),'*y+',num2str(a(j,2,3)),'*z+',num2str(a(j,2,4)));
        f3=strcat( num2str(a(j,3,1)),'*x+',num2str(a(j,3,2)),'*y+',num2str(a(j,3,3)),'*z+',num2str(a(j,3,4)));
        f4=strcat( num2str(b(1)),'*x+',num2str(b(2)),'*y+',num2str(b(3)),'*z+',num2str(b(4)));
        [x,y,z]=solve(f1,f2,f4,'x','y','z');
        if ~isempty(x) && ~isempty(y) && ~isempty(z)
            if (x>=xmin && x<=xmax) && (y>=ymin && y<=ymax) && (z>=zmin && z<=zmax)
                res(ii,:)=[x,y,z];
                ii=ii+1;
            end
        end 
    end
    res(ii,:)=[0 0 0];
    ii=ii+1;
end

5.平面坐标映射：
这个比较容易理解，由于切得的坐标是空间坐标，而在LED显示的是平面坐标，所以要进行一下坐标映射，基本思路就是保留空间矢量的Z分量，将其作为新平面矢量的Y分量，而后取空间点相对于中轴的距离作为新的X分量即可：

tymax=max(abs(zmax),abs(zmin));
res2=[];
for i = 1:length(res)
    if res(i,1)==0 && res(i,2)==0 && res(i,3)==0
        res2(i,:)=[0 0];
    else
        x=res(i,1);
        y=res(i,2);
        z=res(i,3);
        tx=sqrt(x^2+y^2);
        if y<0
            res2(i,1)=-tx;
        else
            res2(i,1)=tx;
        end
        ty=z;
        res2(i,2)=zmax-ty;
    end
end

注意，这里同时进行了Y轴坐标系的变换。
之后进行对称操作，便可以得到另一半的切片：

len=length(res2);
for i=1:length(res2)
    res2(len+i,1)=-res2(i,1);
    res2(len+i,2)=res2(i,2);
end

6.坐标系变换和去归一化：
这个没什么好说的，根据自己实际的情况选取参数，对切片结果进行X向的坐标系变换和方大取整：

resfin=[];
for i =1:length(res2)
    resfin(i,:)=round(res2(i,:)*36);
    if resfin(i,1)==0 && resfin(i,2)==0
    else
       resfin(i,1)=resfin(i,1)+59;
    end
end

2.结果

以下是上面例子的输出，由于上面所言的边界问题有些瑕疵：

完整代码看这里：

https://github.com/dtysky/3D_Displayer_Controller/blob/master/VHDL_PLANB/DECODER/CreatMif/test.m

游戏人物文字设定

dtysky — Saturday, 21 Feb 2015 14:20:00 -00:00

这里记录了原创游戏人物的原始设定，方便日后交流，由于是人设，所以暂且不包括表情和姿势（和画师详谈），服装统一为第一服装（大多是校服）。

我方主要角色

戴寒苍/戴天宇

特性：
虚无/耗散

形式0：
年龄：18岁（现实）
性格：吐槽别扭受
服装：校服
眼色：黑
发色：银带黑
发型：待定
身高：177cm
肤色：正常色

形式1：
年龄：10岁（“梦”）
性格：沉着
服装：特殊—小（类似西服）
眼色：黑
发色：银带黑
发型：待定
身高：150cm
肤色：正常色

Meteor/命月晗樱

特性：
谎言/真实

形式0：
年龄：18岁（现实）
性格：冰山毒舌
服装：校服
眼色：深红
发色：银
发型：双马尾
身高：174cm
肤色：纯白
胸围：B-

形式1：
年龄：10岁（“梦”）
性格：元气温柔
服装：特殊—小（白色连衣裙）
眼色：淡红
发色：银
发型：双马尾
身高：140cm
肤色：纯白
胸围：A--

苓苏.蒲兰特

特性：
泉

形式0：
年龄：17岁（现实）
性格：天然（前）小恶魔（后）
服装：校服
眼色：淡绿
发色：浅绿
发型：单侧马尾
身高：168cm
肤色：白偏微黄
胸围：A

形式1：
年龄：17岁（梦界）
性格：腹黑小恶魔
服装：哥特风
眼色：深绿
发色：深绿
发型：单侧马尾
身高：168cm
肤色：纯白
胸围：A

月雏末

特性：
幻想

形式0：
年龄：18岁（现实）
性格：软妹弱气（前）正常（后）
服装：校服
眼色：浅粉
发色：粉
发型：散短发
身高：166cm
肤色：白偏微黄
胸围：F（外观B）

形式1：
年龄：18岁（梦界）
性格：冷漠强气
服装：童话骑士风
眼色：橙
发色：橙黄
发型：散短发
身高：163cm
肤色：白偏微黄
胸围：B

玖暮

特性：
理

形式0：
年龄：18岁（现实）
性格：强气傲娇（前后）
服装：校服
眼色：淡紫
发色：紫
发型：单马尾
身高：178cm
肤色：白偏中黄
胸围：C

形式1：
年龄：18岁（梦界）
性格：弱气/病娇
服装：魔女风
眼色：深紫
发色：火红
发型：单马尾
身高：179cm
肤色：苍白
胸围：C

恒晓

特性：
道

形式0：
年龄：18岁（现实）
性格：伪装笨蛋（前）豪爽透彻（后）
服装：校服
眼色：黑
发色：苍蓝
发型：越帅越好
身高：181cm
肤色：一般

形式1：
年龄：18岁（梦界）
性格：阴暗/冷静
服装：中国古代神话风
眼色：深蓝（戴眼镜）
发色：苍白
发型：越帅越好
身高：181cm
肤色：苍白

弗莱士.待暮.斯代达斯特

特性：
星空（未知）

形式0：
年龄：18岁（现实）
性格：沉着温柔自我厌恶伪装（前）冷静温柔（后）
服装：校服
眼色：淡黄
发色：金
发型：贵族式正统
身高：178cm
肤色：白

形式1：
年龄：18岁（梦界）
性格：疯狂/冷静
服装：正装
眼色：深黄
发色：金
发型：贵族式正统
身高：178cm
肤色：白

无名

特性：
空

形式0：
年龄：22岁（立绘破损一）
性格：平凡
服装：无
完全纯色

形式1：
年龄：22岁（立绘破损二）
性格：平凡
服装：
破损程度1

形式2：
年龄：22岁（立绘破损三）
性格：神秘
服装：
破损程度2

形式3：
年龄：22岁（完整）
性格：冷静
服装：校服
眼色：蓝
发色：白
发型：帅
身高：180cm
肤色：白

散夜

特性：
实感

形式0：
年龄：黑影
性格：神秘
服装：无
无

形式1：
年龄：外观12岁（灵魂）
性格：情感渴求（前）温柔（后）
服装：黑色连衣裙
眼色：黑带紫
发色：黑
发型：黑长直
身高：145cm
肤色：苍白
胸围：B

其他主要角色

霍普.蒲兰特

特性：
执念

形式0：
年龄：40岁
性格：完全理智
服装：正统西服
眼色：蓝
发色：白金
发型：待定
身高：180cm
肤色：白

莱特.休斯.斯代达斯特

特性：
奉献

形式0：
年龄：外观9岁（灵魂）
性格：沉着温柔
服装：休闲西服
眼色：淡黄
发色：淡黄
发型：正统偏帅
身高：145cm
肤色：白

应龙

特性：
爱

形式0：
年龄：外观18岁（异世界神）
性格：浩然之气
服装：神话服装
眼色：深蓝
发色：苍白
发型：越帅越好
身高：181cm
肤色：苍白

斯诺

特性：
荣耀

形式0：
年龄：40岁
性格：死板强压
服装：正统西服
眼色：深黄
发色：金
发型：完全正统
身高：180cm
肤色：白

Ghost

特性：
复仇

形式0：
年龄：外观20岁（复仇集合体）
性格：仇恨戏谑
服装：待定
眼色：绿
发色：无（小丑面具）
发型：待定
身高：175cm
肤色：中黄

戴麟

特性：
彼方

形式0：
年龄：外观30岁
性格：超越善恶
服装：休闲
眼色：黑
发色：黑
发型：规矩偏帅
身高：178cm
肤色：正常色
性感胡渣

“零”

特性：
正义

形式0：
年龄：？？？岁
性格：全知，全不知
服装：无
无立绘

其他角色

花夜月

特性：
平凡

形式0：
年龄：18岁
性格：略害羞，开朗
服装：校服
自由发挥

菲克

特性：
善意之伪

形式0：
年龄：外观40岁
性格：好人
服装：家居服
和善中年大叔

中年男人

特性：
救赎

形式0：
年龄：40岁
性格：压抑
服装：西服
中年男人

体三维显示器-PCB部分-LED控制板

dtysky — Thursday, 19 Feb 2015 19:20:00 -00:00

体三维显示器的PCB工程：
https://github.com/dtysky/Led_Array

体三维显示器为真三维显示的一种，即可以在真是的空间内显示一个三维的图像，图像占据一个真实的三维空间，不需要借助任何辅助视觉器件，我采用的方案是二维LED点阵的旋转，LED点阵为自行设计，这里记录了控制板的设计心得。

1.指标

既然LED阵列已经设计完毕，那么其控制电路也就可以开始考虑了。这个控制电路应当是怎样的一种形式？但LED打样成功后我思索着这个问题，思考的约束主要来自于如下几个部分：

1.IO数量:
LED阵列被分成了三块（为了最低的亮度考虑），每块分辨率为120x38，这也就是说按照逐行扫描的方案我需要(120+38)x3个IO去控制整个电路，一开始是想直接用FPGA芯片的IO去搞，甚至花了相当的时间去考虑如何设计一个FPGA核心板（太年轻了），当经历了漫长的选型、设计之后，甚至连原理图都快要完成的并且芯片已经买到手的时候，我发现了一个事实——这是不可能的任务。一个如此多IO脚的FPGA核心板至少十层以上，并且对于我这种菜鸟一次成功率基本为0，而我的经费和时间是有限的。
经过了基友和老师的劝告，我放弃了执念，选用了现成的开发板——黑金某个板子，IO口二百多个，这也让我不得不去考虑别的方案。
这个方案是大家所熟悉的，一百LED点阵都会用这种方式——Latch。
当然，出于某些原因我并没有用Latch，而是用了Trigger。
利用Trigger锁存数据来达到多路复用的目的，第一个周期将行送出锁存、第二个周期送出列这种形式，当然实际控制会复杂一些（消隐之类的）。

2.负载：
我选用了Trigger复用IO口的方案，这样一个IO就要对多个Trigger进行驱动，这是不被允许的，因为一般而言这种主控芯片可以负载的电容都是有限的，所以我不得不去考虑其他的方案。这时候，就要Buffer出场了，Buffer即为缓冲器，一个Buffer带载Latch的能力一般在4-6个，完全满足我的要求。
要注意的是，Buffer仅仅起到提高负载的作用，不对逻辑产生任何影响。

3.特殊引脚：
特殊引脚就是Trigger的时钟引脚，相对于一般的数据引脚，时钟引脚的错误带来的后果更为严重，所谓牵一发而动全身，所以我在布线的时候为其做了特别的保护，加大线宽和线距以及让附近的走线尽量少。

2.设计

指标了解之后便可以开始电路设计。

1.选型：
Buffer选用TI的SN74alvch162827，Trigger选用TI的SN74alvch16721，保证质量。

2.电源：
除了LED电流之外还要解决这些芯片的供电问题，和LED阵列一样，选择了一个TI的电源模块，按照建议进行了布局。

3.电路：
电路实际设计的过程比较痛苦，因为走线很多约束不少而面积被LED阵列限制所以双层板肯定不够，最终敲定了四层板。

3.生产

1.布局布线：
很痛苦，由于布线很紧张所以没有办法自动化，只有手慢慢拉，而且国内的打样厂一般不给打盲孔，所以无法让每一层物尽其用，但还是勉强布完了，如下：

2.打样：
难度比较高，被第一家打样厂拒了之后第二家打样的，花了1K5，比LED阵列还贵。

3.焊接：
焊接也是蛋疼，找的师傅焊接，花了500。

4.总结

板子总共花费约2K5，整体良好。
说实话，作为一个菜鸟的第一块四层板，我感到十分庆幸。
板子如下：

体三维显示器-PCB部分-LED阵列

dtysky — Wednesday, 18 Feb 2015 17:20:00 -00:00

1.指标

既然要设计一个LED点阵，要考虑的无非就是颜色、大小、密度、亮度，以及无法避免的成本问题了。对于这些指标，当然是越高越好，比如全彩、1080p、400ppi、高亮啥的，一开始我也是这么想的，但越往后设计越感受到自己的天真。

1.密度:
对于密度而言，通常的led封装到0402已经是封底了，而0402LED的大小能达到的最高密度也就是1/(0.4x0.2)=12.5ppi，而且这个理论密度是根本不可能达到，因为我们必须要为焊盘与布线预留间距（国内PCB打样厂的线宽线距一般要求不低于0.2mm），so...吹了

2.大小：
PCB的大小直接受到密度和成本的限制，对于PCB而言成本主要收到层数、大小和孔数的限制，再加上板子最后是要被电机带动旋转的，所以太大将会有风阻和力矩等问题。当然，最后选择的120x114（要知道这个分辨率的LED数量是1w+）实际上还是大了（以我当时的水准驾驭程度和成本的综合考虑而言是相当冒险的）。那么为什么我还要选择这么大的分辨率呢？当然是为了爱，因为当时实验所得这个分辨率下刚好可以显示一个萌妹子的轮廓www。

3.色彩：
颜色方面也是十分尴尬，能实现全彩自然是好的，但对于一个体三维显示器，彩色要考虑的事情非常多。
首先需要明白，RGB的LED的色彩是通过不同色彩通道的光混合而成，如果仅仅依靠“亮”与“不亮”来进行调色，三个通道最多出现8种颜色的光，更多的色彩是通过PWM来实现的，即调节一个大周期内每个通道的光的占空比，也就是调节每种颜色的光在一个发光周期中的能量（平均功率），这一点直接回影响控制器件的选择，因为如果想要实现全彩就必须在一个发光周期内至少进行256次PWM输出，加上LED扫描（后面会提到）的所占用的周期，这个要求的速度是比较高的，就算先不考虑控制部分，这一点也直接影响了LED的亮度，不停的变换会让LED的有效亮度减少，由于环境光的影响，LED的亮度将会随着扫描次数（包括色彩调节）大幅下降，由于分辨率已经定的比较大，导致扫描已经占用了不少周期，如果在这种情况下再加上色彩调节，不但会使亮度可能下降到一个不可见的等级，就算可见，色彩在此等亮度下可分辨的程度也是极低的，毫无意义。
当然我们说如果换一种扫描方式，加上优秀的供电（LED的接受电流极限一般是几ma到几十ma）和牛X的LED（最高亮度可达几千LM），全彩也不是不可能，但这时候就会遇到其他的问题了——钱，和PCB布局的难度。
对于一个全彩LED显示电路，6层的PCB是至少的（想要完全解决EMIEMC问题），而EMIEMC问题的解决是需要大量经验和理论的，本人无能，暂时无法解决。同时对于PCB工艺的要求也比较高，再者全彩SMD LED的价格比较高，PCB的价格又是随着层数成几何级上升的，对于一个新手而言失败概率极高，所以对于当时作为一个菜鸟的我，还是妥协了。
综合考虑，我选择了0603单色翠绿的LED，灰度暂时没有考虑。

4.亮度：
亮度虽然在上面说过了，不过还是有其他的部分没有提到。
亮度不仅仅要考虑LED本身，还要考虑供电部分，一开始是准备直接用控制芯片的IO脚来驱动LED，但很快就被否决了。由于显示条件的限制，我并不可能给每一个LED都加上单独的驱动源，所以肯定是以行扫描或者列扫描的方式来驱动，这也就是说每一行LED共阳，每一列LED共阴。
在这种情况下，驱动电流明显不够不说，每个引脚都以最大功率输出会使得芯片整体负载过高。
所以我只有进行迂回战术，选用中转的电源来驱动LED电路，这将会在下面说明。

2.设计

指标了解之后便可以开始电路设计。

1.LED：
LED是显示的核心，目标是亮度高、功耗低、便宜，最终我选择了国内某厂的LED，其最大电流是20mA，亮度也算可以。

2.驱动源：
由于不能够用控制芯片的IO脚驱动，但仍然要用其进行控制，所以我们需要考虑用间接的方法实现IO脚对LED的控制，这样我们就会自然地想到三极管，用PMOS作高端驱动控制阳极，NMOS做低端驱动控制阴极，MOS管的栅极链接到IO上，便可以实现IO对LED的间接控制，这样也解决了LED供电不足的问题。
当然,MOS管的选取需要考虑到LED的驱动电压和IO的输出电压，否则阈值范围不匹配就完蛋了www

3.电源：
电源部分的要求是稳定和足够的功率，在本例中可以预见到的最大瞬时电流输出为3.3V下的120x20=2.4A,我选择的是TI的某个电源模块，最大输出电流5A，宽电压输出，使用简单，十分满足需求。
这里提一下良心的TI，一百来块的东西就这么随便申请成功还包顺丰www

4.电路：
综合下来，LED、电源、MOS管全部选型完毕，接下来就是实际电路的设计了。
实际电路设计要考虑到的东西不少，但最主要的还是以下几点：

器件间距：每个器件的焊盘肯定是不能够直接在一起的，而且厂家也有最低间距限制，所以必须确定好器件间距。

线宽线距：和上面出于相似的考虑，而且走线相比器件而言，更多地不是工艺而是干扰等问题。

电源网络线宽：这个单独拿出来说是因为电源网络比较特殊，一般的走线不需要考虑电流大小的问题，而电源网络由于电流很大不得不考虑，网上有专门的计算器，可以用来估算一下，给电源网络一个比较宽的线宽。那么如果线宽受到板子的限制无法加宽怎么办？方法还是有的，也是我所采用的保险措施——将电源网络的铜皮裸漏出来，放在丝印层之上，这样可以手动给它加锡，从厚度上解决问题。

孔径：过孔的直径，主要约束因素也是电流大小，同样可以通过计算器来计算，另外厂商也有一定的限制，比如内孔0.2mm，外孔0.3mm。

设计结束后便可以开始绘制电路板了。

3.生产

生产的第一步是电路板绘制，首先是原理图的设计，这点不在赘述，教程可以看本博客的PCB系列帖子，需要注意的是以下几点：

1.布局布线：
LED的数量达到五位数的级别，手动布局是完全不可取的做法，面对此等难题只能够借助于自动化的工具，好在Allegro支持脚本，所以我选择了用Python生成了.scr脚本，之后再运行脚本即可，脚本的内容如下：

add  connect;
pick  201.3  424.3;
pick  201.3  423.7;
done;
add  connect;
pick  203.3  424.3;
pick  203.3  423.7;
done;
add  connect;
pick  205.3  424.3;
pick  205.3  423.7;
done;
add  connect;
pick  207.3  424.3;
pick  207.3  423.7;
......

这样一来，五位数的约束性“半自动布局”便很快完成了（其实也用了一个来小时），接下来可以用同样的方式去布线，整体的板子很快就可以完成:

2.模块化：
分割越细查错越容易，这是不变的真理，面对如此庞大的一个设计，模块化是必须的。
我将LED阵列作为了一个模块，将所有控制引脚全部引出到排针，降低风险。

3.个性化：
好不容易做出了个大东西，而且是个人的作品，你是否想要加点个性标志呢？
对于我而言当然是想的，而且是非常想，所以我花了一些功夫研究如何在PCB上印图案，也获得了成功，具体的方法将会在PCB教程系列写到。

4.打样：
联系打样厂家，注册账号，上传完整的设计文件（包括各层的Gerber文件、钻孔文件），算清费用，之后等待几天便拿到了产品。我这个板子的打样费总共1K+

5.贴片：
这么多的SMD芯片不可能自己焊，我找了一家贴片厂去进行焊接。
由于只是个人的一个板子，一般的厂家是不给焊的，最后好不容易连蒙带骗游说了一家，为我进行了焊接。
当然最后板子来回几次后还是有问题，我也懒得继续纠缠了，再继续下去说不定有更多其他的岔子，所以我保守了一下。
板子贴片费2K6。

4.总结

板子总共花费约5K，整体良好，有些许行列的MOS管缺焊。
说实话，作为一个菜鸟的第一块板子，我感到十分庆幸。
板子如下：

博客重构

dtysky — Monday, 09 Feb 2015 16:44:00 -00:00

概要

这次重构博客的主要原因是因为找到了未来的方向，以及对自身价值的进一步认定，博客的分类将会简化，从平时的点滴积累，大部分仍然会是技术和文化类的东西。另外，也将作为原创游戏进度更新的地点。同时，由于原来博客的界面并不友好且繁杂，所以我对整个页面进行了重新的设计，为移动端和PC端分别做了样式，enjoy it!

分类说明

Create：
原创游戏更新，以及自己的技术作品展示。

Skill
技术文章，探讨自己的一些技术经验和心得。

Art
一些对世界的感悟，以及一些文学拙作。

Life
日常琐事。

两年来的总结

dtysky — Friday, 19 Dec 2014 23:00:00 -00:00

体三维显示器相关

1. PCB：

https://github.com/dtysky/Led_Array

电路部分，其中转接板-Expand默认为黑金某核心板的转接板。
LED阵列侧边的引脚预留给光电传感器，防止误差积累，转接板侧边引脚预留给USB开发板和蓝牙设备。

2. 机械部分：

https://github.com/dtysky/3D_Displayer_Machine

其中作为整体的那个dwg文件中没有替换后面修改的联轴器。

3. 控制部分：

https://github.com/dtysky/3D_Displayer_Controller

70%完成度，只需要把DDR2控制器完成或者替换就90%了，做法都有着良好的注释，不过代码写的比较早，不怎么好看，也懒得重构了。
包含USB和PC通信的上位机、固件、FPGA部分，LED的FPGA控制部分（包括双缓存），DDR2控制器（缺少PHY）。

4. DDR2控制器：

https://github.com/dtysky/DDR2_CONTROLLER

缺少PHY，包括控制器主体、分别用VHDL和Systemverilog完成的Testbench，其中SV的具有随机测试功能，同时包含修改好的1G DDR2模型，直接在Modelsim内混合仿真即可。

剧本解析器

https://github.com/dtysky/Gal2Renpy
文档坑爹中，等有时间+心情补完。

感言

两年前，我是个什么都不会、生活没有方向的菜鸟。
这时候，学姐出现在了我的面前，她那与我相似的性格吸引了我，我们谈了很多，黄油哲学人生物理耳机无所不谈，最后，我做出了一个选择——将梦想继续下去。
我翻出了高二时写的设定稿，将其不断重构，使其逐渐完整，然后在某人引导下看培根霍布斯休谟尼采海氏康德等等，都是为了在了解世界的同时，让作品有一些深意，这也导致后来我完成了某选修课的5W字民哲论文和被人吐槽剧本写得像论文，但是，我的确在进步。
进步是必要的，也是必然的，在以上的前提下，我找到了目标，回归了那个拼搏和努力的我。
“不懂怎么做，不会做，怕做不完，怎么办？”
舍友：“先接了再说，东西可以学，机会只有那么点。”
这里感谢我的舍友给了我这些鼓励和帮助，大一就带领学长学姐拿国奖的他毫无疑问为我提供了强大的技术支援和信心（舍友就是拍视频那个）。
FPGA不会？学
PCB不会？学
CAD不会？学
C不会？学
C#不会？学
Python不会？学
只要有心学，这些东西都不是问题。
托他们的福，我也能够在如此低的GPA下找到一个还好的工作，也赢得了每一个面试官的尊重。

以上是鸡血正能量，以下是现实

现实的分界线

并不是你想做到什么就能做到，可行性分析是重要的。
综合才能、财力、时间，以及现有科技水准才能得到一个最终的答案。
这个项目在我看来，最终无疑是失败的。
不但距离一开始天马行空的“三片DMD全彩投影体三维”等想法相去甚远，甚至连妥协后的计划都没有完成。
因为我的热情已经被一次又一次的琐事磨灭了。
企划、采购、联络外包，亲自跑工厂和别的装作自己要批量，唯唯诺诺，为了价格磋商，为了成本计算每一笔小开支，这些东西都是完成这个东西必要的，但却是我不想去做的。
我只是想搞技术而已，我不想管什么和商人的交流。
但现实是残酷的，你不得不去做这些事情，或者说这些事情必须有人去做。
然而我选择了单打独斗。
我牺牲了所有课余活动，学到了很多，代价是自身能力不足没有完成作品。
我不希望这件事再发生在我现在唯一的梦想——那个GAL上。

我曾也以为我一直能够作为一个中二少年在自己的世界奔跑下去
但果然还是无法抵挡外面那宽广的世界
就像那通往银河的列车
在永恒孤独的铁道，向着路过行者致敬

Thanks

感谢学校提供的机会和资金，感谢舍友的技术支援，感谢在米帝读PHD的学姐的引导（嫁给我吧），感谢TI的样片支持，感谢老师们的一些指导，感谢Cypress蛋疼的片子和支持。

Over。