计时机器开发日志
2021年10月19日
应用开源了 https://github.com/timer-machine/timer-machine-android
2021年9月12日
下一版本将会是6.0：
- 增加了一些新功能、新提醒方式、新设置等。
- 应用将不再支持Android 5，最低支持将会是Android 6。
- 出于缩小版本差别的考虑，移除了国内版本的开发日志和赞赏选项。
- 出于Google Play付款的一些问题，应用内购将对未购买用户关闭。已购买内容不受影响。
最近也在进行一些开源的准备。具体开源时间应该在会在6.0发布之后，今年底到明年初。
同时，本开发日志也就不更新了啦，以后的问题和规划就放到Github Issues区。
2021年8月22日
开源的意外出现了！因为懒工作量太大了，还是慢慢来吧。
2021年8月10日
因为遇到了种种困难，我正在考虑开源本应用。不出意外的话，年底前开源。
2021年7月8日
5.7.0的Google Play测试版已发。正如之前所提，现在的更新内容都算比较细枝末节。
Jetpack Compose快要出了，因此现在积压的各种界面相关的修改和优化都变成了“等Jetpack Compose出了后，再重写吧”。
2021年4月24日
一直以来都在酷安上回复评论，但最近酷安的开屏广告越来越烦，所以懒得开酷安了。有需求的各位请善用应用内的“帮助与反馈”-“反馈”来发邮件联系。
2021年4月18日
因为Android上的闹钟机制（计划任务所依赖的接口）实在不靠谱，在不同厂商的系统上有的能有、有的不能用，而且Android 12又得继续和系统API斗智斗勇，因此暂时不打算为计划任务增加新功能，只进行Bug修复。
2021年3月16日
从前段时间Flutter 2.0发布开始，由于馋Flutter不仅覆盖移动端，还是覆盖Web和桌面端，所以最近一直都看一些Flutter的内容。感觉就是，我要转方向了。。
虽然缝合怪Dart难写又难用、各平台特性难以利用、配套工具少得可怜、继承了Google代码的拆东墙坏西墙的特性等等，Flutter还是不错的。
2021年2月8日
各位！突然发现这个项目的代码成屎山了！上一次遇到类似的情况，我决定另起炉灶，于是有了计时机器。不过这次，我打算慢慢优化，所以接下来的更新虽然代码改了不少，但日志会乏善可陈。
2021年2月3日
今年的大年三十没有新版本了。要说可以增加或优化的地方，有很多，但我决定细水长流慢慢来。另外，我也在计划一些其他的项目。
2020年11月30日
5.2已发。迁移到了Firebase，统计似乎可以正常用，崩溃似乎偶尔可以用。而今天才发现AppCenter十一月初活了过来，或许未来可以混用。
想要加的功能还很多，一步一步来吧。
2020年10月31日
5.0前几天已发，几天下来一切正常。应用的大更新告一段落。
5.1将会更新：可互动的使用教程、更详细的白名单指南。再之后的更新就是一些小修小补了。
如果AppCenter在年底前无法恢复正常，我将会在应用中统一使用Firebase，因为虽然Firebase的主服务被屏蔽，但开发者圈子中一直有它的统计和崩溃服务还能用的流言，索性死马当活马医了。
2020年10月16日
下个版本是5.0，主要是计时器合集（就是之前提到的文件夹）功能。基本已完成，接下来就是测试，各种测试了。
未来的5.1的计划是换一套新的使用教程，现在的还是不够简单明了；在订阅计划中增加一些无关痛痒的小功能。
2020年10月7日
文件夹功能比预想中快了很多，就作为十一月的更新吧。
2020年9月27日
我有三点要发表：
Android 11
虽然Android 11已经出了，但我决定过段时间，到年底或明年年初，等待配套的AppCompat稳定了再适配，或者计时机器在11上出了问题再适配也不晚，吧。
新版本
新版本加了一些小功能，预计十一期间可以放出。之后就要正式开始文件夹功能了。
国内版统计问题
计时机器在Fabric被Google Firebase收购后，出于Firebase可能国内连不上的缘故，就切换到微软的AppCenter进行崩溃统计，可是最近发现，AppCenter最近在国内也无法访问了。如果这个情况无法得到解决的话，计时机器的国内版可能要裸奔了，这样我将无法看到并解决任何国内版的应用问题。
国内的替代品？我能找到的都是流氓服务，相比之下宁愿裸奔。
2020年9月7日
关于计时机器在Google Play渠道引入订阅制云备份的决定
2020年8月27日
云备份一直在测试，各种小错误不断。
另外，文件夹功能已经在做了，这里是仅有的一张设计图：
2020年7月27日
应用数据云端备份和保存的功能终于完成了基础部分，都拖了一个月了，不过距离最终完成还需要一段时间。
除了代码，我还需要处理UI、文案、服务器等等。像是前段时间写了个小应用，代码半天搞定，图标却活活憋了三天，而且最后看起来也很一般。ㄟ( ▔, ▔ )ㄏ
2020年7月24日
最近买了一个电子闹钟，因为根据我个人对Andorid的使用体验，加上几年来的Android开发经验，觉得Andorid手机里的闹钟实在难以被信任。听着电子闹钟发出的刺耳铃声，我再一次感受到了现代科技的伟大。
之所以提这个，是因为计时机器的计划任务使用了和手机闹钟同样的实现方式，所以在使用前自行测试，并做好不少系统上可能失效的准备。
2020年7月1日
下一版本是小修小补的小版本，之后是云端备份，将会以Google Play渠道独占的每年订阅制的形式登场。
想了几天的UI都不满意，最后发现还是直接抄一个别人的好看(。﹏。)
2020年6月14日
最近在做运行记录的图表显示，又是饼状图又是柱状图的，真好（复）看（杂）呀！
还要给数据处理写测试 (。_。)
2020年5月17日
4.4.0将会加一些小功能，然后接下来计划是四个大工程：多语言、更详细的运行记录展示、数据云端备份、文件夹（包括排序）。因为文件夹是最繁琐的，所以放在最后。其他三个看心情和时间逐步推进。
2020年5月16日
关于不做无限循环功能的决定：一个5分钟的步骤，循环1000次就有83小时，循环最大20亿（2147483647）。此外，如果循环不够还可以设置计时器结束后，启动自己，这样可以做到无限循环。而无限循环的功能不仅会榨干手机电量，还会导致运行记录无法被统计。综上所述，此功能暂不考虑。
2020年5月12日
现在计划任务只能设置一次、一周的某几天或每隔几天。考虑到闹钟在短时间内一直触发会导致应用达到系统最大限制，进而导致闹钟失效，因此决定不添加每隔几小时和更小时间尺度的循环模式。考虑到复杂的循环需求数不胜数（设置在多个时刻运行、根据不同日子进行不同循环等），这里还是建议使用Tasker、Automate等应用。
2020年5月7日
新版本一般会在Google Play的beta测试中放一个礼拜再放正式版出来，想尝新的可以点页面顶端的Google Play链接去参加。
2020年4月21日
设计真是痛点。最近寻思着在编辑页面显示计时器总时间，死活整不出一个又漂亮又方便的方案😂
2020年3月14日
嘿嘿！最近发现同为流程控制应用，Automate比Tasker好用且漂亮多了。它们都支持计时机器的插件。
2020年1月19日
2020年1月18日
如果未来增加任何涉及联网的服务（比如同步等），打算都用Firebase，这意味着它们只会在Google Play渠道上线，而且绝大多数情况下需要魔法。Google Play和国内（酷安）两个渠道用的不同包名，所以可以同时装，数据迁移也只需要导出然后导入。两个渠道现在的不同仅在于包名和国内可以看到开发日志。
2019年11月4日
自动夜间模式的确有问题，这个东西实现起来比我想象地要复杂。
2019年11月2日
重新试了一下，自动夜间模式没问题呀。。那马上就发4.0.0。
2019年10月28日
GooglePlay渠道上架了4.0.0的beta版，但自动夜间模式似乎有点问题，有时间了就修。
2019年10月20日
我，再一次，误删掉了我自己的应用数据。。。该做联网同步了。。
幸运的是，我在另一台测试上找到了遗留的备份文件，舒服了！
2019年10月14日
下个版本4.0.0有一个长长长长长的测试列表，我这几天慢慢测一下。测完了先会丢到GooglePlay的beta测试里，之后才能正式上线。
2019年9月11日
嘿嘿，摸了。。主要是Android 10的夜间主题不好弄，逻辑有点乱，容我整一整。
2019年9月4日
既然Android 10出了，那就适配一下再出4.0.0吧。
2019年8月31日
各位，新版本4.0.0近期发布，能赶得上Andorid 10的话就顺便适配一下。因为是取消专业版后的第一个版本,而且最近也在一直重构代码库，所以新功能不多。
另外，在2018年10月21日曾提到的内存泄露中，其中一个泄露被证实是Android相关SDK的问题，于是我在汇报为这个问题贡献了一个百分百重现的Demo。然后前段时间收到一份邮件说要感谢我为AS 3.5质量提升做出的贡献，本来以为只是个像捐款签个名之类普通的感谢，但最近3.5发布后，在发布日志页，发现我的用户名出现在了仅有的几十个人之中。。受宠若惊 ====> https://developer.android.com/studio/releases#3-5-community-contributors 名字是DeweyReed。
2019年8月25日
XP用户要小心了，Xposed可能会导致应用的通知无法显示，进而导致崩溃。我现在还没有找到能从应用代码层面解决这个问题的办法。
另外，今天看了一下后台统计，发现朗读居然是最受欢迎的行为之一。本来以为TTS在国内系统都阉割地差不多了，但意外的有很多人用。
2019年8月14日
下个版本是4.0.0，修修过去一个月成吨的的Bug、清理清理专业版的遗产、加几个小功能。更新时间未知，所以现在这里给大伙儿拜个早年啦!
2019年7月18日
在计时器运行在后台播放音乐时，大伙儿遇到过音乐播放突然暂停的情况吗？正常情况下，计时器的各种行为会临时暂停音乐播放，行为结束后就恢复音乐播放，但最近遇到过好几次暂停后就不恢复、没有行为也会暂停的情况。如果各位也遇到了，请通过反馈/邮件告诉我（虽然我不知道该怎么解决。。。
2019年7月12日
下次更新的时间说不好，哪天Bug积累的差不多了就更新。
今天看某up主的视频提到了一个名词：自嗨式开发。这不就是我一开始的更新思路吗233。但后来变好了一些，会根据用户的呼声和关键的体验进行更新，但还是很容易陷入自嗨的境地。
2019年7月8日
服务器已经停掉了。都给我升级到最新版。
2019年7月6日
在今晚放出的3.8.0，将取消专业版。具体的解释在这里：https://github.com/DeweyReed/site/blob/master/source/_posts/timer-death.md
2019年7月3日
这个美好的世界，每一天都充满了希望 (✿◕‿◕✿)
很抱歉，您的应用未通过审核，原因是：
- 详情如下：
- 应用设计较为粗糙，应用整体质量未达到小米应用商店收录标准，请丰富应用功能、提高应用质量后再上传
2019年7月1日
最近新功能的开发先停一停，我需要：为Android Q适配、试着把应用上架到更多的应用商店、清理一下代码库为4.0做准备。
2019年6月29日
如果不能用LeanCloud，那么其实AppCenter也可能被搞（更不用提它的Auth和Data还在Preview中），要不打游击？把现有的账号注册体系，换成激活码体系，然后打一枪换一个地方。头大。。
2019年6月26日
LeanCloud又送来一个坏消息：未来需要一个备过案的域名作为API接口。这个就有点强人所难了，个人域名备案流程很复杂、很多样、很混乱、坑很深，这趟浑水我是真的不想趟。但各位的数据又不能丢掉，我需要想个办法。
2019年6月22日
3.7.0发布了，有不少新功能，也修复了LeanCloud的问题。没法登陆、注册的现在必须更新了。
另外，刚刚手贱，在测试应用的时候，把我自己用的应用的数据给清了。。心疼我的运行记录啊！！！为此我要加一个数据自动备份的功能，不过这咋下手呢？
2019年6月20日
今天的LeanCloud（各位的数据都保存的他们的服务器上）的域名出问题了，意味着登录、注册、激活等等都会停摆。只能等它们那边修了。根据它们的博客似乎是被有关部门安排了。。
另外，GooglePlay的版本是接入了GooglePlay的支付渠道的，出现类似问题的几率低得多。不想受此类苦而且有本事的，可以迁移到那边。但注意两边账号是不共通的，所以专业版的问题给我发邮件就可以，不需要各位花第二份钱。
还有，我已经在思考把数据迁移到AppCenter了。
我会在明天或后天发一个新版本，按他们官网提供的临时解决方式的搞一搞。
2019年6月15日
下个版本的新功能：微调时间的第二个主按钮，应用内的使用手册。
2019年6月14日
新的测试功能，时间标签，基本能用。但无论是微调一下时间或者使用了挂起行为，都会让时间出问题，未来几个版本慢慢改。
2019年6月12日
正在做六个可选的时间表盘：当前计时器已用时间、已用时间占计时器总时间的百分比、计时器总剩余时间、总剩余时间占计时器总时间的百分比、步骤的预计结束时间、计时器的预计结束时间。
这六个时间的计算都涉及到当前计时器的已用时间，但现在有个问题，我没法精确地算出它。。
2019年6月10日
诸事不顺，回来更新了。
接下来的更新计划，首先要更新一下应用内的使用指导，因为还是有不少新用户不会用；添加一些计时器示例；显示当前计时器已用时间、剩余时间和预计完成时间（UI怎么设计是个问题，越来越挤了）。
2019年6月4日
最近新功能加的有点多，失去了灵魂，要歇一歇，找找方向。
接下来的更新计划，首先是3.5.1修修Bug（但似乎没什么大问题），同时更新一下应用介绍、截图和使用指南。然后我要去学一些另外的东西，回来后再决定下一步吧。
2019年5月31日
3.5.0会有了新的测试中的“通知”行为，也修了一些Bug。然后我要去学ASO了，所以下个版本是3.5.1，继续修Bug。
2019年5月23日
过半和倒数新版本就发，因为步子有点大，放到了实验室里，需要到设置里手动打开。另外因为时间问题，通知下下个版本再加。3.4.0已经进入测试阶段了，预计周末能放出吧。
2019年5月21日
倒计时需要+1s。。现在情况时，比如5秒钟的计时器，显示的内容是“4，3，2，1，0”，每个持续一秒。但这个样子并不合适，尤其是最后一个0，它虽然代表时间已经结束，但实际上在看到它后，再过一秒，计时器才算结束。所以想让它显示“5，4，3，2，1”，但这样又有个问题，看不到0了，因为最后一个1会在一秒后，直接跳转到下一步骤，比如直接从1跳到10。这可咋整啊。
2019年5月17日
接下来的更新计划，三个新行为（名字还没想好）：半路（在步骤中途朗读内容）、倒数（在步骤最后数秒）、通知（在步骤开始时显示一个通知，试着适配手环）。另外，这么多行为，添加时就会显示一个很长的对话框，寻思着把它们分两列显示，但这我需要得从头写一个。还有，音乐选择器得更新了，一方面是因为它需要更多的功能，另一方面是为了适配Android Q。
2019年5月6日
今天或明天放出一个版本修修Bug，然后就要肝一年一度的画饼大会Google IO啦。
2019年5月3日
Fabric要凉凉后，我就迁移到了微软的AppCenter。当初的AppCenter只有一些简单的功能，崩溃、统计、推送、云端编译……今天的AppCenter-SDK-Android有了认证和数据。虽然文档还找不到，但是不是意味着AppCenter要进军Baas啦，这样的话，我在考虑将之前保存在LeanCloud的数据，迁移到AppCenter啦。
2019年4月29日
3.3.0的Code Review结束啦，测试完就可以找小白鼠啦。另外新的使用手册和应用介绍也快完成了。
2019年4月25日
3.3.0将有的内容：设置来电时是否暂停计时器的设置选项、运行记录将包含开启时间、更好的悬浮窗界面、修理Bug。因为最近在研究前端的内容，还要更新使用手册，估计下个礼拜才能发布。
2019年4月24日
在Android O及以后的系统上，通过计划任务或Tasker停止计时器时，可能会出现程序未响应的问题。因为Android的规矩是，我要在启动服务后5秒后，必须显示一个通知，否则程序未响应。但是，既然是停止计时器，5秒内计时器已经都停止了，所以在5秒时服务已经关闭了，哪来的通知？结果就未响应了。这可咋整啊？
2019年4月21日
花了一礼拜恶补了很多前端的知识。相比只有十年的Android，发展了几十年的前端可真是遍地开花。现在到了各种框架的阶段，看得我头疼。
2019年4月15日
白名单呀白名单，至少给个“锁屏清理”的绿灯吧。要用Tasker的话，可能还需要个“被唤醒”的绿灯。不然计时器跑着跑着没响儿了，得多难受。然后你也可以再给个差评，让我陪你一块儿难受。
3.2.0重做了底层链接计时器的逻辑，测试过程中一切顺利。就看各位先更新的小白鼠的使用体验了。
2019年4月13日
突然想加个Dropbox, Google Drive, OneDrive的云备份，这可是个大坑。
2019年4月11日
3.2.0的新功能将会有：挂起行为可以正向计时，朗读行为可以自定义内容并可以朗读当前循环次数，嘟嘟行为的暂停其他背景音选项。有Bug的话，3.2.1将只会修修Bug。然后我又要岔出去学点新的东西了。
2019年4月9日
Android在对话框里弹出个软键盘怎么就怎么难？
2019年4月2日
为了支持正向计时和解决昨天提到的问题，现在要重做整个计时器链接的逻辑。初步定在3.2.0。
2019年4月1日
嗯。。之前2019年3月21日提到的问题，终于重现了一次。这个问题会造成两种崩溃，都是涉及运行多个计时器时，通过通知终止所有计时器（或许还有其他情况？），造成一些情况下应用崩溃。修起来比较棘手，只能从底层重构链接计时器的整个逻辑。找不到现成的轮子，只有自己来了。
2019年3月31日
3.1.0会有两个专业版的功能：设置一个计时器结束后自动启动下一个的设置，Tasker支持。
2019年3月27日
3.0.0 有个大Bug，争取今天中午能发出安装包。暂时把酷安应用下架了避免没更新的各位更新。虽然好像找不到重新上架的按钮了。。。有条件升级的都给我升级。
2019年3月21日
看到几个莫名其妙、理论上不可能发生但的确发生了的崩溃，一直都没头绪。它是关于停止所有计时器的，反正停止所有计时器和直接崩溃的效果都差不多，我就先搜集一下相关信息，未来几个版本再想办法解决。
2019年3月15日
一直狂按下一步，会有极小几率崩溃，原因不明，估计是在快速显示新步骤和隐藏旧步骤时，RecyclerView处理不过来了。因此才有的双击步骤序号快速跳转的功能呀。
2019年3月14日
重构差不多了。清理清理就上马3.0，虽然并没有什么特别激动人心的新功能。新功能留到3.1吧。
2019年3月13日
重构代码就跟捅了马蜂窝一样，这个比喻真形象。现在已经有了16个Module了。。
2019年3月8日
问：为什么这个应用无论怎么改，UI都透露着一股贫穷和简陋？
2019年2月13日
发现了一些Bug：在有任意对话框打开的情况下，旋转屏幕，很大几率崩溃。不过不急着修，大伙儿又不会没事儿转着手机玩。另外Android传数据是真的繁琐。
2019年2月12日
APK逐渐膨胀快到4MB了，东西越加越多是这个样子的。
2019年2月11日
2.1.0已经在测试了。之后还是规矩，清理清理代码，需要的话出个2.1.1修Bug。然后我要岔出去搞搞应用介绍、应用截图和造一些其他轮子。
2019年2月9日
一个有意思的现象：开始/暂停按钮显示的是它要执行的动作（运行时显示暂停图标，暂停时显示运行图标），但锁定按钮显示的是当前状态（锁定时显示锁定图标，解锁时显示解锁图标）。
2019年2月8日
打算再加一个快速修改计时器步骤的功能就可以出2.1.0啦。
本来计划添加一个可以选99小时或更长时间的选择器的，但这种情况呀，最好还是手动设一个系统闹钟或一个计划任务，因为设置那么长的一个步骤会很费电。因此99小时选择器的计划延后。
很多手机在使用计划任务时，要想在手机重启后让计划任务继续生效，是需要在系统设置进行单独设置的。
2019年2月6日
我们已经尽力了.jpg
因为UI设计和大量数据的显示本来就不怎么配合，加上又不怎么会UI设计，结果只能注重实用性，而减小UI的权重。
2019年2月4日
在Dribbble找了很多设计图，但只能说对UI优化有了个大概预想。不过在改完UI后，我估计还得优化一下内存，总感觉应用是不是吃得太多了？希望是错觉。
我决定今天争取发一个2.0.1修一下当前的Bug。
2019年2月3日
接下来的计划：如果2.0.0有严重的Bug，就会有2.0.1来专门修理它们。如果没有，下个版本会是2.1.0，主要更新有美化UI和快速设置当前步骤和循环（居然现在才加这个功能），也会重做一下应用介绍和截图。
另外，激活专业版的各位记得把用户名附上呀，不能我只能等各位的邮件啦。下个版本给那几个字**加粗放大**。
2019年2月1日
要什么beta版，再测一测就上正式版。大不了打补丁嘛。
已知Bug：
- 运行N(N > 1)个计时器，在其中一个嘟嘟时，每次嘟嘟音会响N次。。涉及到对嘟嘟音的重新设置，下个版本修复。
2019年1月24日
内容做的差不多了。接下来的任务是1. 测试。因为改动太大，需要把整个应用都舔一遍。2. 引用了两个还在alpha和beta的第三方库，担心不稳定造成崩溃。3. 组的UI显示还是不怎么满意，但不知道怎么改进。
2019年1月18日
如果创建很多个计时器（3个及以上吧），都打开，然后点击总管通知的开始暂停，这时总管通知就更新不过来了，原因是Android限制了一个应用一秒内可以更新通知的次数（据说是10次）。而在开始暂停时，每个计时器的通知都得更新名称和按钮选项。这个问题理论上无法彻底解决。能缓解问题的方法是把一些计时器的通知显示关掉。。。
2019年1月14日
2.0.0还差几个小feature需要做，UI也需要提升一下。但最后的测试估计会很费劲且费时。
但接下来的版本已经有畅想了。2.0.1将会修理Bug。2.1.0将会加三个新功能：不需要进入编辑界面就可以快速编辑的功能、计时器排序（这个还不知道怎么做）、设置毫秒级的步骤时长。此外还会努力优化一下UI。
2019年1月12日
现在的步骤编辑布局，一大串儿行为，选择打开哪个。我寻思着可以改成，默认什么都没有，加个可以选择添加哪个行为的按钮。这个样子就干净多了。
发布前，我得写篇很详细的使用说明。
另外，放弃设计了，能跑起来就不错了。Keyline对齐就已经胜利了。
嗯。现在组的实现差不多完成了，该收拾收拾其他东西了。
2019年1月11日
在编辑界面，加入组之后，拖拽就变得很复杂。尤其是把一个步骤拖进组里或拖出组外。为了省事，新版本里打算不做这个功能了。需要的可以通过删除+新建来实现调整步骤的效果。
2019年1月9日
新的组里多了一个限制：一个计时器步骤大于了2万，或一个组里的步骤大于了10万，计时器运行界面的步骤显示可能会出现错误。如果有哪位超人不够的话，跟我说，我再改改。
2019年1月6日
比预料的快但也更磨人。编辑界面凑活能用了，但是丑，很过分地丑。跑了一圈Dribbble也莫得灵感。
2019年1月5日
我要放弃组中组的功能开发了。一方面因为这有点过于复杂，不仅仅是数据层面（如何保存一个可以在子树中循环的多叉树的状态？），还有界面层面（编辑时，组就需要一个单独页面；运行时，将会比文件树视图还要复杂）。
所以2.0.0的变动将会有:
- 在现有四种步骤类型的基础上，新增一个“组”步骤类型。组里可以放多个步骤，并可以有自己的循环。但组里不能嵌套另外的组。
- 数据导入导出的格式升级为.tmd2，将不会兼容之前的版本。需要的可以在升级到2.0.0之后，重新导出一次数据。
在2.0.1会有一些UI上的优化。
2019年1月4日
数据层的工作完成了。比想象中的快了不少。接下来就是UI层。头疼，不知道怎么塞进新的“组”的概念。
2018年12月31日
比想象中的复杂。现在的方法是把计时器的状态（在哪一步骤运行中）保存到一个整数里，是把计时器“捋平”后再记录。为了适应更复杂的结构，原来的方法就显得太臃肿了。现在得想个更好的办法，这可就不好弄了。有没有现成的轮子啊啊啊。
过了一会后
重做计时驱动层吧，现在计时器们也有跟Android一样的lifecycle啦。
2018年12月30日
2.0.0在做了，主要任务就是一个特殊步骤：组。组有自己的名字和循环，组里也可以放步骤。
然后这玩意儿现在成了多叉树，这可就复杂了。。为了记录当前步骤，就要一个迭代遍历多叉树的操作，头大。
另外的问题是UI，我该怎么显示一个多叉树的步骤视图和它的编辑页面？初步构想是先不支持“组里组”的这种结构（这样复杂的任务可能分成两个计时器更好)，这样UI就可以简化为步骤+带标题的步骤。
2018年12月25日
1.1.1差不多了，主要是修修补补。该准备2.0.0了，虽然连规划还没开始。
2018年12月23日
做好了，但是好丑啊啊啊。。等未来的版本再用吧。
2018年12月20日
打算重做一下运行时所有步骤的那个控件，为了解决前面提到的Bug，应该做起来比较简单吧。。
2018年12月15日
APK爆炸了。。最大的到了5.1MB。不行，我得想想办法，争取限制在4MB里。之所以是4MB，估计和当时Instnat App最大只能4MB有关，虽然现在10MB了，但心里的那条线已经画好了。
过了一会
啊，回炉重做吧。
2018年12月14日
发现一个Bug：如果创建很多步骤，7、8个吧，然后疯狂点下一步，很快就会崩溃。暂时解决不了，可能的话会在1.1.1里重写一下控件。
2018年12月13日
1.1.0，有一些新功能和一个高级付费版，来维持开发。
1.1.1，修理Bug，引入Material Design 2。
2.0.0，引入组的概念，可以把步骤放到组里，组有单独的名字和循环。
2018年12月2日
十五分钟内的多个计划任务就会失效，这也就是为什么奥利奥上循环计时器不能用的原因。
1.0.6还没出，我已经在畅想2.0.0怎么做了。。
2018年11月29日
最近其实加了不少新功能，但在新版本里其实都把入口隐藏了，因为最近一直在加东西，有点迷茫。
2018年11月21日
有个Bug：加1分钟后，计时条会失效。因为加1分钟是临时的，所以计时条找不到当前步骤的总时间。那这可怎么解决哩？
2018年11月20日
用了evernote的android-job来实现计划任务了，虽然底层都差不多，但总比自己造轮子好。不过最近我的手机闹钟都不响了，其他第三方应用设置的闹钟靠谱才怪哩。
这次的发布不怎么顺利啊，发现了不少Bug。
2018年11月15日
打算加一个每秒播放提示音的步骤行为，但好肝啊。
2018年11月12日
开发者吃狗粮体验：别用自己喜欢的音乐作为步骤音乐，会把它听毁掉的。可以考虑用手机自带的提示音或者朗读步骤名称。
2018年11月11日
代码难产啦。倒不是没有要做的东西，相反，要做的太多了。
过了一会
有位哥们儿反馈了一个默认铃声无法停止循环的Bug，试了一下，没什么头绪，好像是Android的Bug吧，我再试一试。 真凶抓到了，.ogg自带无限循环，换成.mp3就好啦。
2018年11月7日
如果一切顺利的话，跑完测试就可以放出1.0.4了。新版本主要对UI进行了不少优化，还为下一步做了不少铺垫。
什么？APK大小破3MB了？
2018年10月31日
代码又难产了。。。
发现居然循环计时器在有的奥利奥设备上居然能运行，这究竟是手机厂商的宽容大度还是谷歌的过于严格？
2018年10月28日
接下来要做的工程都很复杂呀。。
过了一会。
什么？支持平板？谷歌爸爸的平板都停产绝版了。。如果以后闲到无事可做，我可能会考虑适配一下平板。。
2018年10月25日
1.0.3丢去测试了，不出大问题今天出。修改了计划任务的实现，不知道会不会影响到正常使用。。这之后又要重构了，这次重构UI，新功能的添加搁置一段时间。
2018年10月23日
我估计还得再来几天，因为现在IDE都坏掉了。
2018年10月22日
修了一整天内存泄露。。
2018年10月21日
研究了一会OCR，回来鼓捣计时机器啦。估计这个月能更新一下下。
过了一会儿：
以前LeakCanary一直在报告有内存泄漏，但因为之前很多次都是Android系统的泄露，所以一直都忽视了。今天稍微用了一会发现泄露的通知怎么挤爆了。。。我才发现应用的内存泄露有点严重，现在正在修理中。。都怪Android系统。
2018年10月16日
最近在造一个动态主题的轮子，真正地在造轮子。。
2018年10月7日
有用户提醒我PIP没做，因为PIP比悬浮窗简单，就顺手做了一下，却发现在暗色主题下，显示不出来？？？会不会又发现了Android的坑啦。
2018年10月3日
Bug越测试越多可还行。整个应用败絮其中，只能缝缝补补才能过日子的样子。
2018年10月2日
加了一波小功能，测试过了就放出1.0.2，然后我要去试着写一个悬浮窗 + OCR的应用原型，其中用到的悬浮窗也算为计时机器的下一步打基础了。
2018年10月1日
有些设置该放到工具箱里呢，还是设置里呢？我要想一想。
2018年9月28日
之前提过循环计时器是系统闹钟机制，计时机器是前台服务机制，所以一直想着把闹钟机制的功能移植到计时机器中。但现在突然想到闹钟机制只能在棒棒糖、棉花糖和牛轧糖上运行啊，对奥利奥及以后根本不起作用，同时新设备也越来越多。这么看来，闹钟机制的添加冒着支持旧设备 + 可能失效的危险，这么想就懒得添加闹钟机制了。
什么，循环计时器不灵了？可以用计时机器呀。什么，怕前台服务费电？可以用循环计时器呀。什么，循环计时器功能不够多？可以用计时机器呀。
不过，还没人跟我抱怨过应用费电的问题，估计是杞人忧天了。
2018年9月25日
虽然在主题、导入导出上遇到一些问题，但成功解决了。可喜可贺。
接下来？清理一下代码库，向AndroidX迁移，然后可能要考虑悬浮窗和付费功能了。付费功能不好做啊。
2018年9月18日
在思考数据导出的问题，文件格式叫TimeR Machine Data，后缀可以简称.tmd。
2018年9月14日
主题搞定，造了一个大轮子，下一步先收拾收拾、整理整理任务，定一些计划。
2018年9月5日
1.0.0差不多了，处理处理文案之类的工作就要放粗来啦。
2018年8月30日
最近在造一些轮子，完了之后就着手给计时机器修理漏洞、添加使用指导之类的东西，准备1.0。
1.0之后打算先全面支持一下Android派，然后再想办法增加新功能、新界面和更多的自定义属性。
2018年8月18日
0.3.3发布了，对通知和多计时器进行了大量改动，可能出现不少问题，也会在最近陆续修复。漏洞修光光后，就发布到正式版1.0.0，然后又是新增更多功能。
2018年8月17日
在思考要不要加些付费功能，Google那边就很简单。国内的话，考虑到用户量不多，最可行的还是依赖一个后端存储信息 + 手动确认。
2018年8月13日
commit过千了。
为了庆祝，我想实现一个功能，首先在任何运行的时候，至少有一个通知。然后当有一个计时器时，只显示一个通知；两个及以上时，显示多个计时通知 + 一个总管通知。这个逻辑 + 每个计时器都有可能不显示通知 + 任何计时器都会在任何时候开始和结束，就诞生了一个炒鸡复杂的管理机制。这个复杂的通知管理，有五个状态，任何计时器开始都会让状态切换。挖了一个好大的坑呀。(ノへ￣、)
2018年8月12日
最近代码洁癖犯了，处理了很多第三方Library。要么重写，要么优化。
2018年7月30日
最近想用一个方便的RecyclerView，找遍了Arsenal和Github都找不到一个顺手的。顺便试了一下Flutter，的确很舒服，虽说Dart不熟练，但开发过程挺舒服，只可惜没什么想写的应用。
2018年7月21日
在确保现有功能不出问题的前提下，就要发布1.0.0了，然后又是一大波新功能的添加。
2018年7月11日
加了几个新功能。我估计新功能稳定后就可以发布1.0.0版本了，毕竟Beta也半年多了。
2018年7月2日
0.3.1修复了一个在一些设备上无法选择音乐的Bug。但在Moto G4 Play上会出现Native Crash，莫名其妙，能不能解决随缘吧。
2018年6月29日
正在准备0.3.0的发布，新内容不多，但算是给新内容的添加打好了基础。
但现在有很多很多Bug得修理。
2018年6月28日
考虑关闭通知时间提醒的功能，在手机上更新通知并算不上多么好的体验和实践。
2018年5月23日
重构基本完成了。等加点新功能在放出新版本吧，打算撸个好看点儿的UI。
2018年5月6日
最近在重构整个应用，导致Bug攒了一大堆。。
2018年4月24日
手痒又想重构了。重构==新功能暂时加不了，旧功能各种出问题+以后会爽到。
2018年4月13日
2017年12月18日 那天的日志中提到的问题又重现了。应用被冻结，不是被杀，而是被执行暂停。只有在屏幕再次打开时，应用才会继续执行下一步。
这是一个跟国内厂商斗智斗勇的故事。计时器既然需要精确地计时，就要让CPU一直运行，这一点用WakeLock很容易解决。但这样阿猫阿狗都可以让CPU一直运行，不久流氓应用遍地了吗？于是各厂商就增加了应用冻结（或其他名字）的功能，如果应用让CPU一直运行，但又没有做什么实质性的工作，就会冻结它，不是杀了它，是暂停它。这样屏幕一打开，应用又可以继续工作了。
把应用添加到各个厂商手机中的白名单、保护应用、后台执行之类设置中，可以一定程度解决问题。至少我在测试中这么做，清空后台后，原本3分钟就被冻结的应用，现在3分钟、5分钟、10分钟也没问题了。
我在思考通过一些机制让应用正常工作。
2018年4月12日
本来打算今天发布0.2.0了，但决定给计时器执行实现加一些测试，过几天再发布吧。
2018年4月6日
重构数据层。下个版本可能要丢数据了。。。因为忘了给Model加Proguard。。
2018年4月4日
又要开始爆肝更新了。任务出奇的多啊，数据层也打算重构一下。Beta测试放飞自我，更新之后丢一些数据也是很正常的。
2018年4月3日
最近在充电，学各种东西，也在新功能开发各种库。
2018年3月24日
最近只修了一些Bug。重新搭了一下博客，研究了一会儿自动化脚本。。
2018年3月12日
正在重构代码库。改一改就要跑一遍测试确保不会大崩坏。不过这Gradle Building + 测试可要了命了，跑一遍测试就等几分钟。。都能摸出鲸鱼了。
2018年3月8日
昨天发布了0.1.2。内容有步骤颜色、朗读步骤名称、电子表显示。接下来要清理一下代码库为下一步更多自定义功能做准备了。
似乎支持手环需要各个厂商的API，拿不到就支持不了了。
2018年3月3日
把朗读步骤名称做好了，也做了一些控件。文字转语音还是得用户自己想办法装一个能用的引擎并下载语音数据。
2018年2月25日
要加朗读步骤名称的行为了。在系统设置里配置好文字转语音（TextToSpeech，TTS）后，用起来还算方便，但国内各系统肯定各有各的阉割。
2018年2月23日
第二个Beta版本发布，解决了不知道计时器是否已经开始或结束的问题。接下来就要处理棘手的界面问题了。
2018年2月18日
现阶段主要在研究增强后的步骤选项，有点复杂，焦头烂额。
2018年2月14日
Beta阶段的任务就很多了。比如增强后的步骤选项（自定义的提醒步骤、只运行一次的启动和结束步骤）、更理想更多的计时器详细页面、朗读步骤名称。。。
最近刚刚重写了选取时间的控件。
2018年2月8日
可以进入Beta测试了。虽然有很多小细节可以改进，还有几个重要功能需要加入，但核心功能已经基本齐备了。
2018年2月7日
计时器流水线工作解决的差不多了，但发现计划任务在Android O上失效的问题，应该和最新的后台限制有关，暂时解决不了。Beta阶段试一试第三方Library。
2018年2月5日
发现现有的计时器的流水线工作存在一些小Bug，比如不停地暂停、+1分钟、前进、后退……就有可能把计数器玩儿坏。我得专门再次重构一下这块，年前发布不了不过年。
2018年2月4日
试着向下兼容KitKat，但会出现multiDex与lifecycle无法兼容导致崩溃的迷之Bug。或许在使用Proguard后可以继续在KitKat上使用，但Debug起来就很费事。找不到解决方案前可能无法支持Android 4.4了。
2018年2月2日
增加了夜间主题和介绍页。
2018年1月27日
0.0.5修复了无法正常保存的问题
2018年1月26日
想解决一个问题：在通知栏右侧显示一个类似于系统闹钟的小图标，提示未来有计划任务。研究了一下，那个小图标似乎是全系统的唯一且共享的。这意味着，如果手机上既有闹钟也有计划任务，两个就重叠了，只能看到一个，其实这也起不到原先的目的了。那就先不加入这个功能了，给系统让路。
2018年1月25日
- 发现计划任务的重复设置可能有些Bug，一次性的似乎没问题。
- 发布了0.0.4。更新有：临时为计时器增加一分钟；钦定的紫蓝主题色；增加帮助和相关页面；修复了计划任务的Bug。
- 在加入一些小功能、跑一些测试、确保程序正常运行后，就可以进入Beta测试了。
2018年1月24日
增加了帮助与反馈。
在考虑需不需要增加一个单独的计时器启动和结束步骤。不然计时器启动或结束了都不知道。加入的话，需要加一个步骤还是多个步骤，是使用专门的Field保存，还是整合到已有的Steps中？
2018年1月22日
- 在支持多主题（皮肤）的过程中遇到诸多困难，放弃了。可能会在加入夜间模式，但自定义颜色的设置可能要放在很久以后了。
- 研究了一下其他应用的多主题原理。Todoist使用预定颜色，通过recreate() Activity实现。Telegram似乎是吧所有用到的Paint, Drawable等等都罗列在一个三千行的Theme类中，通过直接修改颜色来实现（看呆了)。都不是很理想的方法，最后可能使用前者。
- 先给计时机器钦定了紫蓝的主题色。
2018年1月14日
0.0.3发布。现在可以新建计划任务了：按预定时间开启或关闭一个计时器，一次性的或者按星期几重复。
安装新版本前要写手动卸载旧版本（既然是Alpha测试，数据库结构改动就随心所欲放飞自我了）。
2018年1月12日
初步完成了计划任务的功能。可以像定闹钟一样设置，什么时候开启或停止一个计时器。
理想情况下，这是可以按预期工作的。但Android系统上，所有跟闹钟搭上边的应用都面临一个无法按时触发的问题。
一方面，系统为了优化电池性能而优化（推迟）闹钟触发时间。这一点可以调用在Android 6.0及以后的setExactWhileIde（似乎叫这个）来最大程度绕过，但4.4-5.1只有setExact，4.3及以前只有set了。效果当然是依次递减了。
另一方面，也是最担心也最没办法的。国内各厂商自定义的各个系统，为了应对国内众多流氓应用，会在清理应用后台时，把我设定的计划任务的闹钟也给清理掉，结果自然是没法触发。如果用户清理了最近使用的应用话，这个情况就会发生。
补充：Android O的后台限制也会极大影响能否触发。
2018年1月10日
Alpha 0.0.2更新了，主要加入了一些无法打开的正常开发的功能选项，也修复了很多计时器方面的问题。别的不能保证，但不删除旧版就直接安装，肯定崩溃。
2018年1月9日
决定暂时停止对Android 5.0(API Level 21)以下的支持，兼容老版本过于浪费精力和时间。在正式版发布后再考虑兼容老版本的问题。
真是谜一般的Bug，在8.1上使用Ringtone就播放无声音，非得使用MediaPlayer才可以。
2018年1月4日
计时器的定时开启和关闭和闹钟的设置差不多，但由于国内各厂商的设置，设置的这些闹钟不一定能唤醒。
2017年12月29日
由于疏忽，导致当前的测试版本在Android O(8.0, API Level 26)及以上无法创建Notification Channel，也就是会无法通知渠道。下个版本修复。
2017年12月26日
计划在正式版发布前加入定时启动和停止的功能。多计时器的查看功能整合在计时器列表中。
2017年12月18日
最担心的事情发生了，Foreground Service无法准时唤醒手机，又得找黑科技解决。FML
似乎用WakeLock解决了，这意味了必须用ForegroundService + WakeLock == 一直保持CPU唤醒状态 == 消耗更多的电量。
不过我为什么不设计一个结合两个应用优点的应用呢，既可以使用AlarmManager省电但稍有不准，也可以使用ForegroundService + WakeLock
耗电但准时提醒？当然是能力不够啦。或许TimerMachine做的差不多后，可以在考虑添加AlramManager的实现方式。
2017年12月14日
| 应用比较 | Cycle Timer | Timer Machine |
|---|---|---|
| 实现原理 | 系统闹钟(AlarmManager.setExact…) | 前台服务(Foreground Service) |
| 准确度 | 少数特定手机、少数特定情况可能失效 | 非常准确 |
| 可能的失效原因 | 权限、系统限制一定时间内的唤醒次数 | 权限、内存及其不够时服务被杀 |
| 可自定义内容 | 名称、循环、节点及其名称、是否振动、提醒音乐 | 名称、循环、每个节点的名称音乐振动唤醒屏幕 |
| 耗电 | 系统分配唤醒时间，影响小 | 需保持计时器一直运行，影响大 |
| 生命周期 | 维护尾声 | 正在开发 |
2017年12月11日
提醒方式将会有音乐、振动、弹出屏幕、朗读节点名称。各自的自定义会陆续加入。
2017年12月10日
循环计时器+计时机器的开发日志。
之所以打算放弃维护循环计时器，重新开发新的计时机器，是因为前者是第一个正式上架的应用，用的还是MVC，代码库很乱，数据库储存格式更乱，
考虑到更多新功能的加入，决定写一个技术更前卫，使用更灵活的计时器。