有以下两种原因：
　　(1) 在线时间只有在笔记联网下才会增长，如果您的笔记没有联网的话是无法增长的。
　　(2) 在线时间的增长是以KB为单位的，而总空间的单位是以GB为单位的，1GB=1048576KB。短期的增长是无法显示在总空间中的，但是在线空间的增长会在我们后台为您添加上的，请放心使用。印象笔记和有道云笔记哪个好用？印象笔记与有道云笔记手机版对比
作者：佚名
字体：[ ] 来源：互联网 时间：12-24 08:53:44
文字笔记软件可以随时记录下我们的感受，手写，语音，拍照，涂鸦的出现弥补了一般文字笔记的不足，印象笔记和有道云笔记哪个好用？下面小编就给大家带来印象笔记与有道云笔记手机版的对比评测，一起来看看吧
地铁里，公交上，我们随时会有工作的灵感、生活的感悟，而在我们的碎片化时间里，文字笔记软件可以随时记录下我们的感受，手写，语音，拍照，涂鸦的出现弥补了一般文字笔记的不足，让记录更便捷更及时。如记者记录现场，作家记录灵感，仅仅是文字记录的话一是时间来不及二是不可能完全还原此刻的情况。今天小编为大家带来两款笔记记录软件的对比，印象笔记与有道云笔记手机版是较为常用的软件。
&印象笔记&即Evernote的中国版，使用国内的服务器，删减分享至Facebook功能后的版本。有道云笔记为国内主流笔记应用。
一、记录笔记使用对比
软件名称：印象笔记中国版 生活必备应用 for android v7.8.2 安卓版软件大小：31.4MB更新时间：
1、印象笔记
印象笔记需要登录或者注册才能使用。
印象笔记首屏清新、简洁，让人心生好感。
首屏加号包括手写、路由、提醒、附件、拍照、文字等多种功能。
首页导航分为工作群聊、所以笔记、笔记本等选项。
印象笔记手写页面
可给笔记添加地点、自动加标题等
记录文字时，有多种选择
文字记录是可选择添加图片与文件，也可创建手写、扫描、录音、语音转文本等。
印象笔记功能非常强大，但操作键不是很方便，在页面顶部，不如有道云笔记附加功能固定于底部更清晰，不太符合中国人的习惯。
2、有道云笔记
软件名称：有道云笔记 for Android V5.9.2 安卓客户端版软件大小：54.0MB更新时间：
有道云笔记添加笔记时，点击首屏的加号，即开始记录笔记，分为手写、添加图片、拍照、录音等。
有道云笔记添加笔记非常方便。
手写采用非常快速
小编格外喜欢这一功能，在手写完一个字后，可立刻在一个框内写第二个字，第二个字未完成时，第一个字已经显示好了，整体优化得相当流畅，小编在使用时没有卡顿，甚至来不及在第二个字时截到第一个字的图。
插入图片效果，也可插入待办事项
在更多选项中，有添加附件与涂鸦的功能
印象笔记：功能强大、多样，但选择略繁复，需要一段时间使用后才能熟悉
有道云笔记：记录笔记流程简洁，可在记录是插入图片、文件、涂鸦等，操作简单。
从纯粹的&记录笔记&这一使用上，有道云笔记无疑比印象笔记做得更简单，更符合国人的习惯。
另外，安卓版印象笔记没有自带的图片简单编辑(旋转裁切)功能，必须下evernote的&Skitch圈点&才能编辑，编辑完保存超级慢，平均一分钟以上左右，你还不能放下手机等，因为手机自动休眠会中断保存进度，下次唤醒手机还要从新保存!! 有道笔记Android版在添加照片时可以作简单的编辑(图像纠偏，裁剪，旋转)，这使添加照片的行为变得更加流畅，但有道不能过后编辑图片，evernote圈点就可以。
二、页面对比
首屏对比(左印象笔记，右有道云笔记)
印象笔记：首页布局主次分明，清晰，绿色清新可人，
有道云笔记：官方的广告与小编的笔记混在一起，第一眼很难看到小编所留下的笔记
小结：页面布局上，小编认为印象笔记更为适合。
3、工作合作对比
印象笔记：
印象笔记的工作协作主要表现为工作群聊，可以与多人沟通，移动端功能没有PC端强大，目前仅支持文字聊天。且邀请朋友聊天过于复杂，需要手打入朋友的邮箱帐号才可以。
有道云笔记：
有道云的工作协作主要表现为&云协作&，仍然为与朋友在工作中聊天的功能，但优于印象笔记的是，有道云笔记可搜索有道云账号或者复制链接发给朋友，朋友点入链接即为加入群聊。
有道云笔记导航有道云笔记邀请好友有道云笔记&云协作&页面
小结：所谓的&云协作&较为鸡肋，聊天功能并没有突出的地方，不如PC端强大，特别是印象笔记邀请好友较为麻烦，需要询问好友的邮箱地址才能邀请，因此小编勉强觉得有道云笔记较好。
如果你比较在意文章的排版，笔记中有大量的图片需要存放，或者你以前没有接触过云笔记产品，希望找一款简单易上手限制少的免费笔记，有道云笔记比较适合你。如果你是一位需要讲求效率的重度文字用户，需要随时快速查找笔记来满足工作需要。印象笔记比较适合你。
大家感兴趣的内容
12345678910
最近更新的内容推荐两款电脑里必装的软件：云盘和有道云笔记
为什么我专门写篇文章推荐？因为它俩确实给我解决了困扰多时的问题。
现在提供云盘服务的公司有很多，有名气的当属360云盘和百度云。360云盘不仅提供的容量超级大（我目前有37T，可以说是天文数字了），而且客户端软件一次性可上传不大于5G的单个文件。基于这两点，我选择了360云盘。根据我的经验，云盘有以下好处。
妈妈再也不担心我的文件丢失了。我所有的文件都上传到云盘上，备份在云端，只要有互联网的地方，我就可以查看到我的文件，相当于一个无线容量的U盘啊，亲！
有时给别人发一个超级大的软件（比如4G的），一般邮件发不了的。可以上传到云盘然后跟别人分享，其他人就可以下载到了。
云盘安装后就像是一个普通的硬盘，可以像对计算机硬盘一样对里面的文件进行操作。还可以在电脑里面设置一个专门文件夹，以后文件只要放进去，就相当于备份到网上，再也不会丢失了。
2、有道云笔记
有道云笔记是网易公司开发的一款解决个人资料和信息跨平台跨地点管理的软件。有以下功能。
可以在软件里面写文章，文章时时同步到网上备份，不仅省略了点击保存操作，也避免文件以外丢失。
②可以对文件进行树状管理。对你的每一类文件分别进行整理，有层次。
③网页保存功能。也是最近发现的非常赞的功能，以前网上看到的文章常常把文字复制出来再到其他地方使用，麻烦。如果仅仅保存网页断网后有时看不了，而且一般保存后再次查看时大家不太喜欢去点浏览器再查看。那么有道云可以直接保存网页到笔记中，只需鼠标右键点一下即可，还能自动过滤到所有广告，只保留核心文章。灰常好用。
已投稿到：
以上网友发言只代表其个人观点，不代表新浪网的观点或立场。作者：蒋炜航 链接：/p/ 来源：知乎 著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
1. Scrum不是万能药，要在时机成熟时推行。
什么时候算时机成熟呢？我们的经验是需要两点：一、团队有三名或以上的研发工程师 ；二、 团队内有一名合适的Scrum Master 。
刚开始的时候，一个开发团队可能只有一名或者两名研发工程师。这时候并没有全面推行scrum的必要 ，而可以借鉴scrum中的一些做法。比如有道云笔记的Web团队最初就是这个情况。当Web团队只有一名研发工程师时，我们就尽可能地尊重他的工作方式。同时为了保证项目进度可控，我们引入了scrum的sprint机制--以sprint为开发周期，每个sprint进行一次Web产品演示。这不但能够让工程师有一个以sprint为期限的压力，还能够让其他同事即时地了解项目的进展，以便做出相应调整。当Web团队扩充为两名工程师时，我们又引入了结对编程、持续集成、相互代码审核等做法。直到Web团队的规模进一步扩张时，我们才开始考虑全面启用scrum。
当团队内无法找到合适的Scrum Master时，不要轻易推行敏捷。如果你的团队是由新人组成，或者即使有资深员工但是他并不了解或认同敏捷开发的话，那么你需要等待合适的Scrum Master出现。合适的Scrum Master需要具备几个特质：首先，他要认可敏捷开发这种方式；其次，他要熟悉业务，起到教练的作用，能带领团队走正确的流程；并且，当团队遇到问题时，他要有能力和担当引导团队做出决定，在团队成员遇到困难时，他要协助成员解决； 最后，他要能识别重要和紧急的事情，而并不是事无巨细的反馈到Product Owner那里。敏捷开发虽然希望团队自我管理，但是这需要一个过程，开始的时候，一个合适的Scrum Master至关重要。有道云笔记的Web团队在成立一年多以后才开始推行Scrum，很大的一个原因是在培养合适的Scrum Master。依据我们的经验，最胜任Scrum Master的人选是Tech Lead。我们也曾尝试过让产品经理担任Scrum Master，但是由于产品经理本身往往担当Product Owner，兼任Scrum Master会影响他在产品机会和产品体验等方面的投入。
2. 限制Scrum团队的规模，建立Scrum团队之间的协作机制。
随着业务的发展，团队会变大。这个时候不拆分团队的话，效率会变低。有道云笔记Mobile团队就经历过这样一个过程。很长一段时间Android和iOS的研发工程师组成一个scrum团队，有共同的Product Owner和Scrum Master。但是随着Mobile团队人数的增长，scrum会的效率却降低了。 虽然scrum会议只有不到半小时，但是当说一个平台的事情的时候，另一个平台的工程师会觉得无所事事。发现了这个情况后，我们把Mobile团队按照平台拆分成了两个scrum团队，以确保scrum会议上说的是每一名参与者都关心的事情。总的来说，参加scrum会议的所有人，包括产品、开发和测试，不应该超过9个人。
按照平台拆分团队，限制了scrum团队的规模，提高了scrum的效率。与此同时，多个scrum团队之间必须进行有效的协作。在初期，我们鼓励研发工程师通过面对面地商量，快速推进来处理平台之间协作的需求 。但是随着业务的发展，这样的协作越来越多，也越来越复杂，这样面对面的讨论往往会疏忽细节需求。比如说，有道云笔记3.0版本中的待办事项功能，就需要PC、Web、Android、iPhone以及Server多个scrum团队一起对这个功能进行产品定义和确定技术方案。这样复杂的协同需求需要额外的机制来保证。这个机制就是scrum master的定期会议。在这个会议上，我们会讨论各个scrum团队相互依赖的项目，安排好各scrum团队的开发顺序。对某一件具体的事情，其中的一位scrum master会被指定为具体负责人来驱动跨scrum团队的协作。同样，只有当scrum团队间的协作任务比较复杂的时候才需要引入这个机制。
3. 产品经理和研发工程师要拥抱scrum带来的变化
在引入scrum之前，一般的项目管理方式是版本式（瀑布）的，产品经理决定下一个版本做什么，预期发布的时间，然后由产品负责人或者技术负责人来兼做项目经理。这个时候遇到的问题是项目往往会延期，但是产品经理会有一种对项目把控的感觉。引入敏捷开发之后，这个事情变了，发布是跟着sprint走的。基于持续交付的原则，一次发布包含一个或者多个sprint的内容，而这些内容是由团队整体决定的，而不是产品经理个人决定。产品经理只是定义了功能需求的优先级，这些功能需求与代码重构、开发工具、以及市场运营等的推广支持等需求一起排期，最后由整个团队决定一个sprint做哪些东西。从表面上看起来，产品经理对产品的把控小了，为此，团队一位资深产品经理有过质疑。最后，我们还是说服了他接受敏捷。事实上，接受scrum并不困难。这样，产品经理可以把重心放在对产品需求的把握上，而不必整天问这个咋样了那个咋样了。而且，团队的开发效率，功能点完成的速度并没有因此而降低。
研发工程师同样要拥抱scrum，调整自己的工作方式。Scrum不鼓励过度设计，而采用涌现式设计。这意味着开始往往不会把技术架构做得大而全，而是鼓励快速出成果。当然这并不是说程序架构能够设计得很糟糕，而是说不要花太多的精力在未知的事情上，小步快跑。为此，代码重构是必须的。我们并不建议整个sprint都去做重构，更建议持续重构，把代码调整也分解成任务，每个sprint做一些。在一些大版本发布之后，重构任务的比例可以适当高一些。
4. 量化衡量团队的执行力的指标：完成度、评估准确度、计划合理度 。
当scrum团队不大的时候，可以依靠主观感觉来评估执行力。有道云笔记团队在初创的一年内，对sprint的完成情况是没有量化的评估的。
Scrum教材对执行力的量化评估用的是故事点和速率。由于团队成员实际上都是有道云笔记的用户，能够直观理解产品经理提出的需求。因此我们省去了用户故事，由产品经理提产品需求，而团队把需求分解成任务。经过一段时间的探索，我们定义了几个量化指标，其中最重要的是完成度，我们用这个指标来衡量团队的执行力。完成度 = 1 - 计划内未完成任务的剩余时间/计划内任务评估时间 。完成度的数值在80~90%之间比较好。过高的完成度说明sprint计划过于保守。有些管理者会怀疑完成度的准确性，第一是团队是否会把计划内任务的评估时间评估得过长，使得完成度看起来高？事实上根据我们的经验，团队对计划内任务的评估往往是偏乐观的。第二是计划内未完成任务的剩余时间是如何出来的？这个是由团队在sprint末尾评估出来的，因为这时技术设计多已完成，这个时间是比较准确的。我们也曾尝试过燃尽图，发现并不如完成度来得直观。
另外，我们还定义了两个指标来作为辅助参考。一个是评估准确度（计划内任务评估时间/实际使用时间），一个是计划合理度 （计划内任务使用时间/计划外任务使用时间）。这两个指标的历史数值可以让我们更加了解团队执行的情况。
5. 高效的sprint计划会的要素：预先梳理需求、合适的任务粒度、随机认领任务、运营调研任务、任务评估。
Scrum开发中，最重要的会议是sprint计划会。但是在这之前，产品经理和研发工程师可以预先梳理一下需求，以保证sprint计划会可以更加高效和准确。我们尝试过多种方式来预先梳理需求：发邮件、产品与研发面对面沟通、开需求梳理会。哪种方式更好，目前还没有定论。
Sprint计划会主要讨论几件事情：将需求分解成任务、评估每个任务的工作量、分配任务。每件事情都有各自的技巧。
首先，任务分解的粒度应该如何？Scrum开发一般认为任务分解得越细越好，但是在实际操作中我们发现如果分得太细的话是有问题的。比如说，认领任务、记录每个任务的工时和完成情况，都会带来时间消耗。我们经过较长时间的实践，发现0.5~3天一个任务是一个合适的粒度范围。
如何评估工作量和分配任务这两个事情是关联的，不同的人做同一个任务，往往时间会相差很大。所以这时候有一个艰难的选择，是让大家做自己熟悉擅长的事情，还是随机认领任务以达到团队人员对所有模块都很熟悉的状态。一个短期见效，另一个长期可发展。有道云笔记PC平台的scrum团队经历了一个从前者转向后者的过程。在开始很长一段时期里，scrum团队把自己PC客户端按模块进行拆分，每个模块由一位研发工程师负责，工作量的评估也以这个人判断为准。这个办法帮助团队快速开发了PC的第一个版本和后续几个小版本。但是慢慢的，这种做法的瓶颈就出现了。之前的模块划分随着项目发展变得有些过时，有的模块出现了瓶颈。在最近的几个sprint里，PC平台的scrum团队已经开始随机认领任务的方式。
此外，在实际研发工程中，往往会有一些由于团队没有相关的经验而比较不确定的事情。对于这样的事情，我们会先安排一个调研任务，并且将这个任务尽量安排在sprint的早期，并且凭借经验会在计划会上留出后续实际开发的时间。如果调研任务确定这个事情的复杂度可控，我们会在后续的sprint会议上根据调研成果分解出详细的任务，另一方面，如果这个事情的复杂度太大，那么我们会把完不成的内容放到下个sprint。
任务评估的办法，或者用纸笔写下后同时公布或者用估算扑克，两者本质上没有区别。当有较大分歧时经过讨论后再次评估，次数不宜过多，一般1-2次就好，不超过3次。如果讨论不清楚，scrum master不妨先定一个时间，让会议进行下去。后面实际开发过程中会越来越清楚。敏捷开发本来就是渐进的过程。
6. 流水化安排开发环节与测试环节。
如何安排测试与开发从项目一开始就是我们反复思考和尝试的问题。经过一段时间的实践，我们目前采用流水化的方式来安排开发环节与测试环节。具体来说，就是在开发sprint结束后再开始测试这个sprint的产出版本；而在开发的sprint内，开发团队fix上一个sprint的产出版本测试出的bug。虽然这意味着开发团队要在测试环节还未开始之时（Sprint计划会上）就要估计并预留出上个sprint的产出版本的bug的修改时间，在实际操作中，开发团队能够通过历史数据做出比较准确的估计。因此这种方式的效果是良好的。
7. 版本发布基本按照sprint周期。
我们通常在一个或者多个sprint之后（在测试环节之后）发布版本。具体选取几个sprint往往会参考一些市场情况的考虑，比如说将一个做了较多重构的sprint与一个做了较多新功能开发的sprint打包作为一个新版本发布出来。我们基本上不会为某个大版本打乱我们的sprint周期。
8. Scrum需要配备合适的工程实践，例如，单元测试、代码审核、持续集成、项目管理工具。
我们要求研发工程师必须要写单元测试和相互审核代码。测试驱动开发和结对编程目前还有许多争议，我们也不建议贸然尝试。在实践中，我们采用了简化版本，对可以写单元测试的模块都要求测试覆盖，并且通过测试覆盖率来量化单元测试的力度。此外我们将研发工程师两两结对，相互review对方的代码，只有经过review的代码才能最终提交。
此外，我们对代码进行了持续集成。每天凌晨持续集成系统会自动下载前一天的代码，进行编译和部署。Web端会直接部署到Web测试服务器，而客户端（PC、iPhone、iPad、Android）会自动拷贝到一个内部服务器上。测试人员或者感兴趣的人每一天一上班就可以用到最新的版本。
关于scrum的任务管理，我们采用过不同的项目管理工具，包括白板、开源软件等等。总的来说，工具只是简化了一些统计，scrum最重要的还是敏捷开发本身的思想。
阅读(...) 评论() &