在hacker news上看到一条评论，觉得很有道理就贴过来：
公司主营业务：网站建设、成都做网站、移动网站开发等业务。帮助企业客户真正实现互联网宣传，提高企业的竞争能力。创新互联建站是一支青春激扬、勤奋敬业、活力青春激扬、勤奋敬业、活力澎湃、和谐高效的团队。公司秉承以“开放、自由、严谨、自律”为核心的企业文化，感谢他们对我们的高要求，感谢他们从不同领域给我们带来的挑战，让我们激情的团队有机会用头脑与智慧不断的给客户带来惊喜。创新互联建站推出南郑免费做网站回馈大家。
Seems everyone here is panicking because they think that this means Chrome OS will be killed and Android will be made to run on Chromebooks - but I actually think the signs point to the opposite - Chrome OS becoming the Phone/Tablet OS under a new guise. I wouldn't read too much into a leak filtered through journalists, and instead look at what Google's actually working on:
- Google has Chromium developers working on a DART-based Mobile UI framework and execution engine, Flutter (Flutter). It's looking to be far better than the existing Android UI system - built for touch and 120fps from the start. This uses the Dartium VM and a bridge to allow the DART apps to use all the native features of the platform, it's much more than just another web framework. Development on this is very active right now, clearly a sizable team working fulltime - and they're building new developer tools also. There was a talk on this a while ago: .
- Google has built a Runtime to allow existing Android Java-based apps to run on Chrome OS, and is currently testing this and working with developers to get their apps to run on it. It doesn't make much sense to invest in building that out just for chromebooks, since the experience on a Chromebook with Android apps is pretty awful (can't resize etc), but it makes total sense if it's going to be how legacy Java/Android apps run on the new Chrome based phone OS.
The sad truth is that Android simply isn't a very well engineered system - it's been improved over time, but problems persist - like the complex update process leading to unsatisfied users and security problems, poor UI performance (even now, Android can barely do simple animations at a steady 60fps on the latest Nexus devices, and has little hope of allowing for the beautiful animations the Material Design team has come up with), and poor battery life. Google's also at a dead-end with Java given the ongoing legal battles, and with Apache Harmony dead they have to maintain the standard library implementation themselves.
On the other hand, Chrome OS performs great, has awesome battery life on Chromebooks, is quite possibly the most secure end-user OS ever, and Chromebooks get speedy updates for at least 5 years. I know which one I'd choose as the basis for a merged OS.
我的看法和预测：
从市场角度去看显然android胜出了；
从技术角度去看，不论是UI，安全性以及碎片化问题，自动更新方面去看，chromeOS都优于android。
而且正如上面贴的评论中指出的，chrome团队搞得这几个项目(开发人数和活跃度都是非常高的，说明不是玩笑)，预示着：chrome OS的技术会占据android。
Android的优势是大量的app，品牌影响力和认知度，所以最终的融合可能会是：android的表，chrome OS的芯。
维护两套OS本身就耗费大量的人力物力，而且还都是linux内核，太蛋疼。以后汽车，家居，各种穿戴式设备等等难道再各自开发一套系统？显然不可行。随着移动化浪潮，web的演化发展，整合出一套通用的OS不再是梦。苹果以前时不时就传出过ios会最终融合osx，我个人觉得是迟早的。微软率先大胆的迈出了一步，但可惜做得很糟糕，也许是用户，市场以及各方面都还没有准备好。有点像之前vista和windows7截然不同的命运。还记得ipad之前微软就搞出个一个类似平板的东西最终惨败。在这里有必要提一下Google眼镜的失败，也是这个问题。以上这些失败都是好事，同样的例子：facebook第一次在html5上的尝试以失败告终，但最终搞出了react。
对于任何一款应用来说，页面的流畅度是用户体验最重要的几个指标之一。我们需要用数据的形式标识出页面的流畅程度。
对于大部分人而言，当每秒的画面达到60，也就是俗称60FPS的时候，整个过程就是流畅的。一秒 60 帧，也就意味着平均两帧之间的间隔为 16.7ms。但并不意味着一秒低于60帧，人眼就会感觉到卡顿。小轰将查阅到的资料列出如下：
官方SDK为开发者提供的帧率检测工具，使用非常简单，在 MaterialApp 下添加属性 showPerformanceOverlay:true 。
如图，PerformanceOverLay 会分别为我们展示了构建（UI）耗时和渲染（Raster）耗时。
一款pub上的开源工具，链接地址： fps_monitor
在Java之外，Android是否需要一门新的开发语言，长久以来一直都是业内茶余饭后时常提起的话题，特别是苹果推出了Swift语言，以及Oracle和Google关于Java的专利纠纷，让这一问题备受关注。恰逢国内Google技术社区盛事北京GDG Devfest 2015在北航举办，InfoQ记者邀请到大会上的几位讲师对这一问题发表了自己的看法。
在讨论这一问题之前，先让我们了解一下问题的背景。从去年以来，Swift、Go、Dart语言的社区都对Android开发表示了兴趣：
今年早些时候有一个Silver项目致力于用Swift来开发跨平台的应用，不过在Android平台是通过将Swift转换为Java代码实现的。而另一些人则在等待Swift开源以便将其移植到Android，有人已经做了一些前期的研究，在Android上运行Swift代码，表明这至少在理论上是可行的。
Go语言对Android开发的支持更加官方，在去年发布的Go 1.4中就已经支持了Android开发，Go语言也是在各种Android新语言的流言中最常出场的一位。但Go语言从目前的趋势来看，在服务端发展的可能性更大，它的部分特性也更适用于服务端编程。
Dart语言自今年Google宣布Chrome不再内置Dart VM之后遭遇重大挫折，很多人认为它最终将被抛弃，但这门语言背后有多位优秀的开发者和语言设计者，自从不再将替代JavaScript作为目标后，Dart反而迎来了更广阔的施展空间。今年Dart峰会上Google宣布了用于Android开发的Sky框架（现更名为Flutter），更用120fps的流畅性打消了人们对这个曾被用于前端开发的脚本语言的疑虑。
除了这三门已经有一定历史积累的语言，另一个被认为可能替代Java的是Kotlin语言。Kotlin是开发工具公司JetBrains设计的一门新语言，旨在替代Java，其风格更加贴近现代语言，一经推出便受到Android开发社区的注意，声势也越来越大。
1.动画原理：在一段时间内快速的多次改变UI外观，由于人眼会产生视觉暂留所以最终看到的就是一个连续的动画。
UI的一次改变称为一个动画帧，对应一次屏幕刷新。
FPS：帧率，每秒的动画帧数。
flutter动画分为两类：
常见动画模式：
是一个抽象类，主要的功能是保存动画的值和状态。常用的一个Animation类是Animation double ,是一个在一段时间内依次生成一个区间之间的值的类，可以是线性或者曲线或者其他。
可以生成除double之外的其他类型值，如：Animation Color 或 Animation Size 。
是一个动画控制器，控制动画的播放状态，在屏幕刷新的每一帧，就会生成一个新的值。
包含动画的启动forward()、停止stop() 、反向播放 reverse()等方法，在给定的时间段内线性的生成从0.0到1.0（默认区间）的数字。
curve:描述动画的曲线过程。
curvedAnimation:指定动画的曲线。
常用Curve：
继承自Animatable T ，表示的就是一个 Animation 对象的取值范围，只需要设置开始和结束的边界值(值也支持泛型)。 它唯一的工作就是定义输入范围到输出范围的映射。
例如，Tween可能会生成从红到蓝之间的色值，或者从0到255。
Tween.animate:返回一个Animation。
映射过程：
1). Tween.animation通过传入 aniamtionController 获得一个_AnimatedEvaluation 类型的 animation 对象(基类为 Animation)， 并且将 aniamtionController 和 Tween 对象传入了 _AnimatedEvaluation 对象。
2). animation.value方法即是调用 _evaluatable.evaluate(parent)方法， 而 _evaluatable 和 parent 分别为 Tween 对象和 AnimationController 对象。
3). 这里的 animation 其实就是前面的 AnimationController 对象， transform 方法里面的 animation.value则就是 AnimationController 线性生成的 0.0~1.0 直接的值。 在 lerp 方法里面我们可以看到这个 0.0~1.0 的值被映射到了 begin 和 end 范围内了。
接收一个TickerProvider类型的对象，它的主要职责是创建Ticker。
防止屏幕外动画消耗资源。
[图片上传失败...(image-115b94-1636441483468)]
过程：
回调：
不使用addListener()和setState()来给widget添加动画。
使用AnimatedWidget，将widget分离出来，创建一个可重用动画的widget，AnimatedWidget中会自动调用addListener()和setState()
AnimatedModalBarrier、DecoratedBoxTransition、FadeTransition、PositionedTransition、RelativePositionedTransition、RotationTransition、ScaleTransition、SizeTransition、SlideTransition
如何渲染过渡，把渲染过程也抽象出来：
AnimatedBuilder的示例包括: BottomSheet、 PopupMenu、ProgressIndicator、RefreshIndicator、Scaffold、SnackBar、TabBar。
MaterialPageRoute：平台风格一致的路由切换动画
CupertinoPageRoute：左右切换风格
自定义：PageRouteBuilder
1.要创建交织动画，需要使用多个动画对象（Animation）。
2.一个AnimationController控制所有的动画对象。
3.给每一个动画对象指定时间间隔（Interval）
可以同时对其新、旧子元素添加显示、隐藏动画.
当AnimatedSwitcher的child发生变化时（类型或Key不同），旧child会执行隐藏动画，新child会执行执行显示动画。
希望大家支持一下，感谢
