其实在启动 XyKey 之前我并不知道市面上已经存在为数不少的密码管理软件，而且已经有了1Password、LastPass、Safe In Cloud 这样完备的产品，于是乎空白的我才脑洞大开开发了一个这么另类的 XyKey 。
那时的我单纯是因为在与 XyCard 的一些热心用户交流中，发现了不少人会喜欢将自己的很多账号保存在 XyCard 的自定义信息里面，然后设置为私密不公开，权当为云记录。为了是记忆自己众多网站和软件的账号，有甚者竟然记录了六十多条信息。
他们给我的理由是：方便记录、单条管理、快速复制。
而这，让我第一次深刻感受到了现在账号密码太多难以记忆管理的问题。
然而 XyCard 主打的是云共享的联系网络，不合适也并不推荐用户用来记录账号密码信息。本着为那部分用户解决需求的冲动，我萌发了另外开发一个新APP的想法，也就有了后来的 XyKey 。
既然是一个专注于管理账号密码的软件，那么其安全性就毋庸置疑必须优先保障了。
首当其冲的就是加密算法的选择，其实这一点反而是最不用考虑的，因为著名的 AES 算法已经是事实上的标准，几乎所有常见的加密软件都标榜自己使用了 AES ，所以其安全性就不需要顾虑了。
这个核心的算法倒不是值得拿来大书特书的优势，这只不过是业内标配的加密算法而已。有兴趣的童鞋可以自己查阅相关资料。
AES 的原理普通用户可以不用深究，但是它的使用方式是在这里非常必要说明一下，这里用简单的伪公式代表一下（并不是实际运算公式）。
加密： 明文 + 密码 = 密文
解密： 密文 + 密码 = 明文
有了这个基础，下面可以开始正文了。XyKey 的一切设计其实都围绕着上面两条公式展开的。
为了让用户能相信 XyKey 的安全性，我定下了“所见即所得”这个设计目标。
我个人非常相信当用户能够亲眼看见 明文 被加密成 密文 显示出来的时候，更能够体会到真真实实的安全性。这种做法远比设计了一个主密码入口，输错了就无法进入应用的方式更来的透明更值得信任。
以往那种封闭入口的黑盒方式，你无法判断它是否仅仅只是在入口做了输入验证处理，而里面的内容是直接明文保存还是加密保存你并不知道，因此我决定对 XyKey 采用完全开放的挂载方式。它仅仅只作为一个自动执行加密解密算法的器具，帮助用户把 明文 加密成 密文 ，或者反之。
用户可以直接看到加密后的结果，无论你在入口输入的主密码是否能正确解密，你都可以直接进入应用看到它的数据。是的，它就是一堆密文，就在那里，就以这样的形式保存起来，没有任何明文，不正确解密你得不到有用的信息。
而主密码也是不保存的，它只有在软件开启的时候才临时挂载，它并不是作为一个入口验证手段，而是真正的上面所述 AES 算法伪公式里的密码，只有这个才能正确解开你原来保存的数据。只要 AES 本身的安全性是有效的，那么原理上就只有你能解开你自己的数据。
这种“所见即所得”的数据简单粗暴的展示给了用户它的安全性。我加密前是这样的，我加密后是这个样子的，你加密后也会跟我一样。Duang Duang
如下图所示，第二条即是没能正确解开的密文。
先说说坏处吧，最大的坏处是——“挂载”这个词居然有非常多用户不认识。
由于我本人取名字和用词习惯可能比较奇异，于是我默默地忽略了这个问题。。。
其实这种开放式的挂载倒并没有带来真正意义上的大问题，最多的反馈是用户上手时对这个词认知比较困难。但是操作之后其实就明白与常规的方式没有多少区别，很快就能习惯。
依然是设置一个主密码 > 进入页面&其它操作。只是输错了也能继续操作，而不是不给进入。而且另外在设置页面也留了一个额外的锁定码模式，可以禁止操作没正确解密的数据，锁定之后与传统密码管理应用的区别就更小了。
而它的好处是显而易见的——是的！你可以同时对不同的数据使用不同的加密了！这提供了非常好的拓展性，让那些希望进一步提升安全性和有不同类别分别加密的需求得以满足。
这个特性倒是让 XyKey 与同类软件有了非常大的差异性，目前主流的密码管理软件都没有这个功能，只提供了统一更改主密码的功能。
“所见即所得”决定了 XyKey 异类的开放式挂载，而“无权限” 则让 XyKey 走向了更加异类的极端。
因为我个人开发习惯比较倾向于“权限干净”，不是非必要权限都不申请，尽量保持干净无后台，只做好该做的任务。虽然在安全性上会降低（无法反监听，无法禁止截屏），但是权限干净却能依然很好完成任务的 APP 更容易赢得用户的信赖。
所以 XyKey 从一开始就没有权限，只用了系统自带的数据库保存数据之外就没做任何其它的事情。与此随着而来的是备份的难题—— 作为密码管理软件，不能备份的话就失去了使用的意义。
常规的备份，要么上传到云服务器，要么导出一个独立的文件，这意味着需要网络权限或者文件挂载权限。而与此同时云服务器会带来一定安全性问题（相信会有人记得某个泄露事件），文件的管理在手机上一直都不是非常方便。
基于这两个问题，和我的意气用事，XyKey 放弃了这两种方案。
在一番考虑后，我借用了在 XyCard 上的网络开发经验，那就是 “JSON” 化数据。它其实就是一种信息的格式标准，在网络上通信经常会使用这一种格式来排列信息，非常易于处理，在每个平台上都有很好的原生API来支持。
基于JSON，我模仿了网络通信的形式，将本地数据转以JSON的形式打包成一段文本。于此，就得到了这样一个结果——
这是一段方便传输的信息，在任何支持文本的地方都能使用它，甚至是短信和邮件；
这也是一段非常易于处理的信息，在任何平台上都能通过原生支持解析使用，即使是不支持操作文件的地方，依然可以实现备份还原，具有良好的跨平台性；
这还是一段不损失安全性的信息，它打包的仍然是密文，依然只有你自己才能正确解密这些数据。
如下图所示，虽然看起来像是乱码，其实是非常整齐的JSON。
其实用过 XyCard 的人会非常有体会，XyKey 从 XyCard 身上直接借鉴了非常多功能。
包括对颜色分类的处理、独立显眼的复制按钮、同样的过渡动画、底栏文字按钮的设计、独立编辑页面等等，这些功能就是一模一样的，我还是放到以后关于 XyCard 的分享里面再细说吧。
很显然，这并不是一个以UI设计见长的产品，它并不是基于UI方面的创新成为了这个样子，而是由于它的功能逻辑，导致它必然会是这个样子。
其实以设计主导的开发团队倒不太可能采用这种偏向程序员思维的方案，无论是基于加密算法本质的挂载，还是JSON化的备份还原处理，都需要有编程经验为前提。
虽然 XyKey 以编程思维有效解决了问题，但确实相比常规的设计方式而言非常挑战理解能力，包括 XyCard 对联系信息的处理思路，也是被不少用户反映难以理解。不过我认为这也是它们的价值所在，它们展示了虽另类但是同样有效的方案，提供了不一样的可能性。
我非常希望能见到更多的脑洞大开的产品和思路分享，吸收来自各种各样不同人群不同职业的思维方式，这样能启发出更多有趣的东西。
于是我带来了今天这篇分享，希望少数派里的其他开发者小伙伴也有机会也分享一下自己的历程，互相交流，互相成长，共勉~
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。