说下鸿蒙
昨天有人提鸿蒙是抄袭AOSP的.是android换皮.不说懂不懂鸿蒙.肯定是不懂aosp的
系统架构分析
是不是看不懂.当然英文部分就不翻译了.只说其中差异部分
实际上来说android的SystemApp+FrameworkLayer的上部分对应的是鸿蒙的Application-Layer
Ｎatvie C/C++ 和Android RunTime对应的是鸿蒙的FrameworkLayer+SystemLayer
HAL对应的是Driver SubSystem
Kernel Layer对应的是LinuxKernel(不懂linux和android关系的可以认真学下)
这两张图最大的区别是什么．
鸿蒙简化了上层(JavaAPI Framework/System App)和底层(驱动)．突出了中层．而实际上中层代表的哪一块了（Android Runtime+Core Libraries）这部分在Android中就一点
这就突出了鸿蒙系统关键和华为的商业目的.重写和统一中间层.在中间层做扩展.以及玩出花出来.
Android当时开发的时候.是为了赶上ios进度.成为第二个系统．架构上设计重点是Java Framework+Android Runtime.其他部分用的都是开源成熟项目.图形库用的是google买的skia.runtime部分搞了针对移动设备的虚拟机(Davlik).内核直接对应最成熟的linux.
实际上当时android工作量太多来自于系统和第三方的C++的调用并暴露接口和Java图形库的实现. 难点在于Java虚拟机和Runtime模型跟Linux模型的冲突．以及图形库的调优(性能方面)．
说点题外话．google被Linux那帮家伙弄的很不爽后搞了个HAL.用来解决开源社区对驱动的要求和手机商对于驱动保密的矛盾．这个东西惹毛了Linus.直接Linux不再接收Android版的Linux修改需求.
即Google自己维护了一套Android版本的Linux内核分支
鸿蒙愿景
鸿蒙的商业目标是实现万物互联．它核心的关注点在于System service Layer那一块.核心在于那些Ｄ开头的服务．
是用来做万物互联分布式的东西．即现在做iot即（智能手表．智能家电）的开发者只需要再上层调用鸿蒙的服务就可以实现万物互联．
这就是鸿蒙的愿景.
那相应的就得说说现在的物联网开发模式是什么．
实现端用单片机/嵌入式+LiteOs/Linux/Nuttx等系统实现．集成相应服务商的网络api.
手机端也绑定相应的网络api.实现网络调用．
优点是现有系统集成简单.实现简单.除了调试优化部分.缺点嘛．各个iot的服务良莠不齐.
具体可以参考小米IOT设计部分:https://iot.mi.com/vela
那再回到鸿蒙上．鸿蒙搞成大一统的最大优势是什么．是扩展．是服务的简易扩展．这个是相比android和其他iot厂商而言的.
因为RunTime耦合度很深.假如底端芯片商开发什么新的能力模块(比如指纹模块出来的时候).想实现这个功能．正常的是要向上游google提交这个需求和实现．集成相应的代码到Aosp再发布Java Framework.
或者自己魔改Android framework或者实现一个第三方驱动库让用户调用.其实这两个实现都不太好.
鸿蒙的问题
说实际的.假如是其他公司(除google和华为以外)丢个这个图给我.说要做这样一个系统.我直接看都不看.因为工作量太大．没有任何公司有这种能力做这么大工作量．三星也不行
而且假如是google.我相信他们不会做这种事情．因为他们没有这动力搞这样一个大一统的东西.因为这样搞的商业收益太低了.
只有华为敢这么干.而且华为敢一直这么干.这一招其实在手机端的芯片成功过（毕竟华为自主芯片搞了很久才到高端）．所以再来一次到系统横推．
这里面工作量最大的部分肯定是Android Java Framework兼容部分.即api兼容．至于使用了aosp代码没．肯定用了．不要想.这部没必要重复开发．只需要把aosp系统调用的c++库换成鸿蒙的就行(adapter模式).
技术最难的就是抹平各个底层内核的特性．因为每一个系统是针对其使用环境实现了相应的性能最优.非常多的细节和实现逻辑不一样．抹平差异调到最优非常不容易．要求巨高和工作量巨大.
至于各个基础框架服务.完全不要关心．
商业上最大的问题就是上层对于鸿蒙os的api接受程度(android其实api层很稳定了)下层最大的问题是驱动Driver SubSystem的接受程度和愿意贡献驱动的人