① 鸿蒙OS即将发布，会给我们带来什么变化，与安卓有哪些区别
随着各种预热的到来，华为的自主研发操作系统终于要面向消费者用户提供服务。在五月二十四日更是将网络平台的EMUI账号名称更改为了HarmonyOS。在如今智能时代迅速发展的时代背景下，物联网的快速发展促使华为正式把鸿蒙推向了 历史 舞台，而这也是华为推出的“1+8+N”全场景布局的系统支持，你对此有哪些期待？
在今年的四月底鸿蒙OS开发者公测版就已经开始上线，所以已经有了很多使用体验，原本的神秘面纱也已经逐渐展开。鸿蒙面对消费者来说它有着不变的地方和改变的地方，不变是为了更好地迎合当下消费者的使用习惯，而变化则是为了突出自身特色。
不变之处
1、在系统的交互逻辑以及UI设计上和当下华为用户的emui 11并没有太大的出入，在上手体验上有着同样的简洁性和稳定性。
2、并不需要担心，安卓应用无法使用的情况可以完美地兼容原有的安卓APP，在应用市场的下载过程中，所使用的APP版本也都均为安卓版本。
在原因上，第一为了照顾目前拥有的用户群体的使用习惯节约了换机成本。第二，不同于iOS以及安卓系统开创性，鸿蒙应用生态还尚未建立起来，如果封闭性的设计无法使用安卓APP的话，在生态的发展过程中会造成很大的流量成本影响。
改变之处
1、在通知栏方面下滑板块的设计会有不同的展示，比较符合当下统一设计潮流，但是这并不是根源性的改变。
2、鸿蒙版APP软件体积相对较小在安装包上有着很大的差距。另外去除了大部分的广告，并且让页面设计更为的流畅动画效果十分出色。
其实在更深层次的改变上是我们无法看到的，鸿蒙OS是打开物联网全场景的一把钥匙。这样基于微内核面对生活、运动、办公、开车等等多场景的分布式操作系统，根据你的需要来进行不同的架构部署。三层架构分别是内核基础服务和程序架构，一个系统可以适配于手机、平板、电脑、智能 汽车 和可穿戴设备的多终端设备进行连接。
在现有的在现有的emui系统中，我们就体验到了华为的多屏协同功能，以及现在已经是用的华为HiCar和手机的过度上感受到了分布式操作系统的便利。而在之后的过程中，也会融入到 健康 生活运动，智慧驾驶等多个方面，一碰即传一个摄像头可以展示多个设备的内容等等。
而让我最有感触的就是在运动 健康 方面，华为所做出的努力，随着华为智能手表的不断推陈出新再加上鸿蒙OS的助力。在之后的过程中我们可以在智慧屏乃至 汽车 的中控屏幕上都能够实时地了解到自己的运动 健康 。
但是了解了很多鸿蒙OS公测版的具体使用感之后看到了很多人对他的评价是安卓套皮，虽然兼容了安卓APP，那么就等同于两者大体相同吗？
安卓操作系统与鸿蒙操作系统都是基于Linux进行开发的，但是二者所采用的架构却是不同的，译者是手机终端操作系统的开创者之而鸿蒙OS则是作为物联网的打开的钥匙他们的定位以及驱动型都是具有差异感的。 安卓系统采用的是Linux宏内核设计，鸿蒙系统则是采用的微内核设计。
二者的主要差别，其一是功能性和模块的权限设计上，以及系统的稳定性区分上。在这其中看到了华为新研发的方舟编译器，可以保证模块的出错率降低，鸿蒙系统加上编译器可以取代虚拟机来进行底层的通信功能。
而这样的微内核设计，也正好是适应了分布式的场景设计，而同样谷歌也正在开发基于微内核的分布式系统，但鸿蒙无疑是先行者，他的上限有多高？也需要我们在之后的使用中来进行体验。
② android 手机应用开发一般采用什么框架
android应用开发框架是 Application Framework. 其系统架构由5部分组成，分别是：Linux
Kernel、Android Runtime、Libraries、Application
Framework、Applications。第二部分将详细介绍这5个部分。下面自底向上分析各层。
Android架构
1、Linux Kernel
Android
基于Linux 2.6提供核心系统服务，例如：安全、内存管理、进程管理、网络堆栈、驱动模型。Linux
Kernel也作为硬件和软件之间的抽象层，它隐藏具体硬件细节而为上层提供统一的服务。
如果你学过计算机网络知道OSI/RM，就会知道分层的好处就是使用下层提供的服务而为上层提供统一的服务，屏蔽本层及以下层的差异，当本层及以下层发生
了变化不会影响到上层。也就是说各层各尽其职，各层提供固定的SAP（Service Access Point），专业点可以说是高内聚、低耦合。
如果你只是做应用开发，就不需要深入了解Linux Kernel层。
2、Android Runtime
Android
包含一个核心库的集合，提供大部分在Java编程语言核心类库中可用的功能。每一个Android应用程序是Dalvik虚拟机中的实例，运行在他们自己
的进程中。Dalvik虚拟机设计成，在一个设备可以高效地运行多个虚拟机。Dalvik虚拟机可执行文件格式是.dex，dex格式是专为Dalvik
设计的一种压缩格式，适合内存和处理器速度有限的系统。
大多数虚拟机包括JVM都是基于栈的，而Dalvik虚拟机则是基于寄存器的。两种架构各有优劣，一般而言，基于栈的机器需要更多指令，而基于寄存器的机
器指令更大。dx 是一套工具，可以将 Java .class 转换成 .dex
格式。一个dex文件通常会有多个.class。由于dex有时必须进行最佳化，会使文件大小增加1-4倍，以ODEX结尾。
Dalvik虚拟机依赖于Linux 内核提供基本功能，如线程和底层内存管理。
3、Libraries
Android
包含一个C/C++库的集合，供Android系统的各个组件使用。这些功能通过Android的应用程序框架（application
framework）暴露给开发者。下面列出一些核心库： 系统C库--标准C系统库（libc）的BSD衍生，调整为基于嵌入式Linux设备
媒体库--基于PacketVideo的OpenCORE。这些库支持播放和录制许多流行的音频和视频格式，以及静态图像文件，包括MPEG4、
H.264、 MP3、 AAC、 AMR、JPG、 PNG 界面管理--管理访问显示子系统和无缝组合多个应用程序的二维和三维图形层
LibWebCore--新式的Web浏览器引擎,驱动Android 浏览器和内嵌的web视图 SGL--基本的2D图形引擎
3D库--基于OpenGL ES 1.0 APIs的实现。库使用硬件3D加速或包含高度优化的3D软件光栅 FreeType
--位图和矢量字体渲染 SQLite --所有应用程序都可以使用的强大而轻量级的关系数据库引擎
4、Application Framework
通
过提供开放的开发平台，Android使开发者能够编制极其丰富和新颖的应用程序。开发者可以自由地利用设备硬件优势、访问位置信息、运行后台服务、设置
闹钟、向状态栏添加通知等等，很多很多。 开发者可以完全使用核心应用程序所使用的框架APIs。应用程序的体系结构旨在简化组件的重用
，任何应用程序都能发布他的功能且任何其他应用程序可以使用这些功能（需要服从框架执行的安全限制）。这一机制允许用户替换组件。
所有的应用程序其实是一组服务和系统，包括：
视图（View）--丰富的、可扩展的视图集合，可用于构建一个应用程序。包括包括列表、网格、文本框、按钮，甚至是内嵌的网页浏览器
内容提供者（Content Providers）--使应用程序能访问其他应用程序（如通讯录）的数据，或共享自己的数据
资源管理器（Resource Manager）--提供访问非代码资源，如本地化字符串、图形和布局文件 通知管理器（Notification
Manager）--使所有的应用程序能够在状态栏显示自定义警告 活动管理器（Activity
Manager）--管理应用程序生命周期,提供通用的导航回退功能
5、Applications
Android装配一
个核心应用程序集合，包括电子邮件客户端、SMS程序、日历、地图、浏览器、联系人和其他设置。所有应用程序都是用Java编程语言写的。更加丰富的应用
程序有待我们去开发！ 从上面我们知道Android的架构是分层的，非常清晰，分工很明确。Android本身是一套软件堆迭(Software
Stack)，或称为“软件迭层架构”，迭层主要分成三层：操作系统、中间件、应用程序。从上面我们也看到了开源的力量，一个个熟悉的开源软件在这里贡献
了自己的一份力量。
③ 移动APP开发框架盘点2：Web移动前端框架大全
开源项目其实有一个成熟周期，这个周期大概是三年左右，自React框架在2013年发布并引爆了前端框架的大潮，这个属于前端的周期就此开始了。
之后在2015年5月开源的React Native又开启了属于Web移动前端的周期，15-16年，18-19年，21-22年正好就是属于移动前端的三个爆发点。
三年前，在第一个成熟收获期，我盘点了移动开发框架。在这第二个成熟收获期，理所当然要来盘点一波。
不过，当我点开github项目的code-frequency时，还是被这个准到吓人的周期猜想惊呆了，先给你们看一波，剩下的自行验证。
1、https://github.com/youzan/vant/graphs/code-frequency
2、https://github.com/quasarframework/quasar/graphs/code-frequency
再来说第二个比较有意思的发现，停止维护的项目绝大多数是Vue框架项目。
盘点开始的时候我还觉得React框架处于绝对劣势，到完成时我发现React无论在选择面还是成熟度上都超过了Vue。
原因我这里就不分析了，反正大家都有自己的看法。
网页类框架就是前端组件框架，这一次虽然有大量项目停止维护，但是也有很多项目坚持了下来，而且还涌现出了一批新项目。
大厂占了主导，因为这些年大厂在移动开发上的需求，远高于其它方面。个人项目要坚持确实不易。
本来是想要做一个验证项目，把所有框架都试用一遍并给出推荐度的。由于进度太慢，还是下一次再发吧。
这次的重点是渐进类框架，就是所谓多端同构框架（小程序框架）。这几年国内的重点的各种小程序平台，所以多端框架的需求很是旺盛。
不过大多数先行者都没挺过来还是让我很意外，只有Taro成功了，想想还是有很多让人唏嘘的东西。
在这里还是先预测一波吧，因为这一类框架最变化最大，最终还是有很多框架要出局的。
渐进类框架是一个过渡性的产品，最终会变成桥接类框架的一部分，所以，与桥接类框架协同才是框架的出路。
这个赛道基本全是大厂了。
腾讯新一代跨端开发框架Hippy
Hippy一看就是淘宝Weex的对标项目，Kpi功能全面压制。所以官方支持 React 和 Vue 两种主流前端框架。在Weex2019年实质停更后发布，要不要这么卷？
Hippy 2.x 架构主要分成三层，UI(JS) 层 Hippy-React 和 Hippy-Vue 负责驱动 UI 指令生成；中间层 C++ HippyCore 负责抹平平台差异性和提供高性能模块；渲染层 Android 和 iOS 负责提供终端底层模块、组件，并与布局引擎通信。
对Weex惨遭遗弃，我上次就说过：“ReactNative提供工具，Weex提供框架，将平台差异化屏蔽（Write Once, Run Everywhere）。所以Weex则注定功能相对弱小，并且坑比较多。”Weex最终下马也是必然的，淘宝又发布升级版北海，为了实现（Write Once, Run Everywhere），它采用自绘，而且是基于Flutter自绘。
所以Hippy3.x就一如既往的Kpi功能层层加码，很有腾讯风格。在未来的 3.x 中业务与渲染层中的具体实现可根据用户实际场景进行切换：业务层上不再局限于 JS 驱动，还可选择（如：DSL/Dart/WASM 等）其它语言进行驱动；在渲染层中，渲染引擎除了支持现有原生（Native）渲染之外，还可以选择其他渲染 Renderer，如 Flutter(Voltron) 渲染。
“Kraken 北海”是一款高性能Web渲染引擎。底层基于 Flutter 进行渲染。
Kraken 不限制上层开发者使用的框架，无论你是使用 Vue 、Rax 还是 React 都可以开发 Kraken 应用。
Kraken 的 runtime 通过 JS Engine Binding 的方式提供了一系列 Web 标准的 API 接口，调用相应 API 会执行相关逻辑并创建一系列需要发送给 Dart 层处理的指令。
Kraken 其实就是一个小程序平台，而且追求全平台完全一致。我虽然认为各平台不一致是很自然的事情，但是也表示理解，毕竟别人吹牛有当真的传统（KFC表示认同）。
Kraken 现在也是一个小号浏览器，所以它的主要工作就是抠标准，毕竟它是一款基于 W3C 标准的高性能渲染引擎。
最后，我劝淘宝领导定Kpi要理智些，毕竟Hippy4我还蛮期待的。
滴滴出品的超轻量级动态化跨端开发框架，主打轻量和实用。
Hummer 以 JS 引擎为基石，目前已支持 JavaScriptCore、Hermers、QuickJS 等业内知名 JS 引擎（这里本来还有个V8的，我删除了，源码里面没有，Kpi需要）。再配合经过调优的 Yoga 布局引擎，抹平了两端视图布局差异（性能更佳的自研布局引擎开发中）。顺便提一下，Hippy采用V8（功能更强）自研布局引擎（性能更佳）。
Hummer 的特点是抛弃了业界其他动态化跨端框架普遍使用的DSL层和VDOM层，因此原生 Hummer 不具备前端开发常用的响应式编程的能力，但同时换来的是接近原生开发的体验和性能。再以原生 Hummer 为基础，在此之上开发了一套基于MVVM架构的开发框架 —— Tenon ，通过 Tenon，可以把使用 Vue/React 编写的代码，转换成原生 Hummer 的代码。
Hummer也是一个小程序平台，而且超轻量。如果想要无限提升自己APP的能力，可以考虑嵌入Hummer。
Web移动前端框架正在迎来第三个高速发展期，各类框架得到极大繁荣。
个人在具体项目的贡献已经微乎其微了，创新、架构创新是唯一制胜的手段，这也是我看好React的根本原因。
最后，还是想做点微不足道的 探索 ，现在前端组件库层出不穷，更换组件库带来的代价有点大。想创建一个框架，来实现上次说的组件公约数和公倍数，无缝切换组件库。理论上支持所有组件库 ，也能为后来者提供弯道超车的机会。我想大厂可能没有需求，也不会愿意发布这种框架，毕竟都是平台部门说了算。
这个库就是useMobile，当然分为useMobileReact和useMobileVue。下次先发布useMobileReact。等我发布后，再来填上面表中缺的推荐度。
原文地址： https://www.cnblogs.com/windfic/p/16019457.html
④ Android与iOS的区别
1、优先级别不同：iOS最先响应屏幕
当我们使用iOS或者是Android手机时，第一步就是滑屏解锁找到相应程序点击进入。而这个时候往往是所有操控开始的第一步骤，iOS系统产品就表现出来了流畅的一面，但Android产品却给人一种卡顿的现象，更别说后续深入玩游戏或者进行其它操控了。这是为什么?
其实这与两个系统的优先级有关，iOS对屏幕反应的优先级是最高的，它的响应顺序依次为Touch--Media--Service--Core架构，换句话说当用户只要触摸接触了屏幕之后，系统就会最优先去处理屏幕显示也就是Touch这个层级，然后才是媒体(Media)，服务(Service)以及Core架构。而Android系统的优先级响应层级则是Application--Framework--Library--Kernal架构，和显示相关的图形图像处理这一部分属于Library，你可以看到到第三位才是它，当你触摸屏幕之后Android系统首先会激活应用，框架然后才是屏幕最后是核心架构。
可以看到优先级的不同导致了iOS产品以及Android手机在操控过程中的表现差异，当你滑动屏幕进行操控的时候，iOS系统会优先处理Touch层级，而Android系统则是第三个才响应Library层级，这是造成它们流畅度不同的因素之一。不过优先级对系统流畅性有有影响不假，但并不是最绝对的，造成两系统之间流畅性不一的现象还有其它因素。
2、硬件工作配置不同：iOS基于GPU加速
目前智能手机硬件装备竞赛当中，其实处理器等配置已经达到了一个瓶颈期，各大旗舰产品在硬件比拼当中基本上没有太大的区别，而这时候GPU就成为了一个凸显差异的重要因素。一些大型软件像是3D游戏对GPU性能要求都会比较高，苹果iPhone产品采用的Power VR SGX系列GPU在当下来说非常的主流，跑分测试数据证明了它并不会比一些旗舰级别的Android产品差劲。
而iOS系统对图形的各种特效处理基本上正好都是基于GPU硬件进行加速的，它可以不用完全借助CPU或者程序本身，而是通过GPU进行渲染以达到更流畅的操控表现。但是Android系统产品则并非如此，因为Android需要适应不同的手机硬件，需要满足各种差异配置，所以很多图形特效大多都要靠程序本身进行加速和渲染，并严重依赖CPU运算的操作自然会加大处理器的负荷，从而出现卡顿的问题。虽然Android 4.0以及4.1等更高版本中进行了改进将硬件加速设为默认开启，但依旧无法做到所有特效全部都靠GPU进行加速。在很多Android手机里面都自带有;是否开启GPU渲染;这个功能选项，不过开启之后的改善也是微乎其微。
屏幕最先响应的优先级关系，再加上iSO本身GPU加速程序的特性，使得大家在操控过程中感觉iOS手机拥有着不错的流畅性。因为它本身的整个流程都是在为最大化的流畅做服务，不管是第一印象的滑动接触屏幕，还是你进一步使用程序之后的更深层操作都是如此。而GPU加速这点特性，应该是它优于Android系统流畅性的又一个因素。
3、开发机制不同：安卓机制效率低
Android的编程语言是JAVA，而iOS的则为Objective-C，不过要是说Android系统之所以有些卡顿是因为JAVA开发语言的关系，或者是拿它和Objective-C对比肯定会有人提出质疑。Objective-C的优势是效率高但比较;唯一;，而JAVA的优势则是跨平台不过运行效率相对偏低，其实这两个编程语言所带来的机制不同，就已经造成了各自系统之间的流畅性差异化。
iOS的Objective-C，编译器gcc，而这个gcc编译出来的代码又被苹果专为iOS架构优化到了极致，运行过程中也不需要虚拟机在中间插手，执行效率自然很高--引自网络。这一段话应该是iOS系统本身运行程序的执行过程，而Android是通过JAVA虚拟机来执行，并且系统需要占用大量内存来换取执行速度，再加上不定期的内存自动回收机制，从而直接导致了卡顿现象的出现。
Android的JAVA编程本身运行效率比Objective-C低一些，而且再加上内存自动回收的机制，所以造成了一些卡顿不流畅的现象出现。但根据技术人员讲解，现代的JAVA虚拟机效率已经不再是最大的瓶颈，Android 4.0系统版本之后的卡顿现象明显得到了改善，所以这也是有用户并没有发现自己新买的Android手机出现太多卡顿现象的.原因。看来编程语言和机制已经被Android进行了改善，这同样也不是造成它与iOS流畅性偏差的唯一因素，不过影响却是实实在在存在着。
4、系统设计不同：安卓APP无法统一
有了优先级的关系，有了GPU加加速的影响，还有两个系统各自编程以及机制的问题，似乎已经可以说明为什么iOS相比Android更为流畅的原因。但最终还有一个问题是就是应用程序，很显然用户觉得卡顿都是在运行软件的过程中产生，毕竟没有安装任何应用的初始出厂手机基本上都不存在不流畅或者延迟等现象，而且一款智能手机不安装任何应用程序那也不符合用户的购买初衷和使用行为。所以归根结底，Android相比iOS的应用程序，到底出了什么问题?
因为iOS产品的封闭性，所以所有的APP运行对象都比较单一，因为每个应用程序都是被运行在iPhone，iPad等iOS产品当中，它们有着很高的硬件利用效率。因为iOS系统的配件供应商只有那么几家，CPU也是一年换一次，这点不像Android终端年年变月月变，开发者很难遇见未来终端分辨率会包含多少种，GPU驱动会包含哪些等等，所以相对来说Android应用开发成本较高且收益较慢。而iOS应用开发则因为软硬件垂直整合而受益，这样一来苹果自然就保证了应用本身其与硬件产品之间的完美结合程度。
其实Android和iOS两大系统APP开发情况的不同，也正是它们开发和不开放的特性所造成的。如果要是拿旗舰Android手机加上一个专为这款旗舰产品设计的游戏，来和苹果iPhone 5运行对比的话，你真的不会遇到Android旗舰机出现卡顿延迟的问题，为什么因为这款游戏针对这款手机设计，在软硬等方面都达到了最大化的兼容和优化，自然就不会出现停滞的现象。
而Android系统程序要被安装在各种符合要求的手机上面，开发者也不可能针对所有的机器型号进行开发，只能在比较主流的机器上进行测试并保证运行效果，所以他们为了兼顾整个产品线只能不得不降低游戏体验以达到高中低产品可以共用的效果。最后那些占据了Android终端份额的大量大众用户们由于自己的手机不是旗舰产品而得不到流畅的使用体验，自然而然就会产生Android产品不如iOS流畅的抱怨。