哎，发现都不怎么会跟人打交道了…

说白了，与人交流是种能力，就是需要锻炼的。做的多了，才能更熟练；少了，连保持都难啊。

赶快找人面基吧！

下水管漏水了，不开心…
需要把时间花在项目以外的、自己不愿意花的地方，不开心…
搞定了 iKindle 解析格式能力的自动更新，开心…
宝宝手开始抓东西了，开心…

恩，生活就是这样吧。

获取新用户，难

这一现象有很多的原因，比如，分散用户时间的产品太多了，将产品触达用户面前太难了，能在第一时间打动用户不容易，等等。

尤其是，人口红利的消失。之前，哪怕你的产品没有任何变化，每年新的手机、Mac 电脑用户，都有可能成为你的新用户。而现在，这些新用户的增加停止了，分到自己头上的红利自然也消失了。

存量用户，值得珍惜

经过前面讲的层层困难，最终成为你的用户，已经是非常宝贵的。如果让这些已有用户流失，那实在是太可惜了。

要服务好，可以有很多方面；比如，

• 改进产品本身的体验；
• 增加与用户的直接沟通，让他们觉得自己使用的产品是有温度的、有故事的；
• 增加用户的参与感。
  • 比如用户提了新需求，新版本满足这一新需求后，及时通知用户。
  • 注意，最好是一对一的沟通，这样更有效。虽然这样做成本很高，但得到的用户也更忠诚。

不能做朋友的用户，放弃

比如，单纯因为价格而给差评的用户，我想说：请走开。说的难听点，他不值得拥有我辛苦做出的、好的产品；说的实在点，他的消费能力还没有上来（恩，就是没钱）。毕竟，明码标价、童叟无欺，如果这都要骂，那请移步奢侈品牌，够他骂个够。

其实，也并非单纯因为他们消费能力差而放弃，而是他们缺乏对他人的包容、理解、支持、尊重。与其把时间花在这样的人身上，不如服务好那些值得服务的用户。

我相信，靠自己努力吃饭的手艺人，值得拥有体面的收入。

历时 18 天、105.6 小时，iKindle 终于要出来见人啦！

其实，本来只是想随意整整，没想到做着做着觉得还挺有意思，就越来越想把这个小工具做好了。

为什么我知道 105.6 小时这么「精确」的时间？因为我有记录时间的习惯啦，这样就可以对自己在各个项目上投入的时间更清楚。对于自由职业者，时间就是最宝贵的资源，当然要好好把握了。

其实，以 iKindle 目前的规模，13 个工作日的开发时间确实长了些。换个角度看，真正在设计、开发 iKindle 本身业务的时间，可能只有一半的时间。更多的时间是在学习，比如 UI 开发、SQLite 使用、等等。这次开年的小项目，也算是为未来可能的「中程序」练练手。

最后，还比较满意这次设计的 Logo，虽然又是简陋的文字版，谁让咱就这水平呢，也算是和 i 家族的小工具们相响应吧…

都说浓缩是精华，那这句一定是精华中的精华：

明确目标、有效行动

不管是协作、还是竞争，不管是与人相处、还是自我提高，都离不开这句话。如果展开来说，就感觉像是拿沙子把珍珠盖住，反而淹没了重点。

另，感觉状态有「大小天」的切换：昨天效率还行，干到凌晨 2 点；结果，今天愣是上午 11 点才起床，今天的时间立马少了、变成「小天」了。

发现果然还是对界面开发不熟悉啊。今天在做 iKindle 开发时，在界面上花了很多时间。简单回顾了下，主要有以下几个方面。

不熟悉控件的用法

对比较直觉的用法，自然没有问题。但对于一些较隐晦，却就不知道了。全部看一遍文档，没时间；于是撸起袖子直接开始代码。

于是，要么很容易碰到不会的点、或者问题，然后搜索解决，比较花时间。要么就会有简单接口封装成系统已经支持的复杂接口，做了无用功。

等项目不紧了，慢下来，还是以项目为契机，完整地学习界面编程；相比于遇到问题、解决问题，整体会省时间。

对多线程缺乏经验

在后台编程中，多线程用的相对较少。而在界面开始中，多线程就相当之普遍了。

多线程的这两个点很容易引发问题：

• 数据一致性。即多个地方都有可能修改一个值，那到底值是什么呢？
• 执行的先后顺序。这个是最要命的。
  • 不习惯多线程的人（比如我），很可能会想当然地理解为程序的执行顺序，即是代码的顺序。但实际上，看似一个简单的接口，也可能会因为多线程的原因推后执行。
  • 而一旦代码的先后顺序错乱、或没有保证，就会有各种奇怪、难重现的问题，修改起来难、且花时间。

不过没事，等过了这一关，就不再对界面开发有心理阴影了。