Android 系统架构
3. 碎⽚化
Android历经10余年的迭代，在流畅性、内存、续航、安全、隐私等⽅⾯都取得很⼤的进步，但Android系统的碎⽚化⼀直是痛点问题，带来不⼀致的⽤户体验。Android的开放性，是其长久发展的主要原因，让⼤多数的⼚商都选择Android系统，但开放性的背后是碎⽚化，从Android诞⽣⾄今问题就⼀直存在，Google⼀直在努⼒从技术⾓度来解决碎⽚化问题。从Android 8.0提出Treble项⽬，重新架构系统将system与vendor 解耦合，⽤于加快Android新版本的适配，效果并不明显，Google继续在后续的Android P以及Android Q⼀直在不遗余⼒地持续完善Treble项⽬，⼒争加快系统升级速度。如下图，⽬标是希望在保持Vendor不变的情况下，可以独⽴升级System模块。
Android 碎⽚化
Android系统碎⽚化，让安全、隐私问题存在风险，且存在体验不⼀致性问题，但⽼版本⼿机的OTA维护升级对⼚商来说成本是昂贵的，Ｇoogle 感觉到对Android系统掌控⼒度不⾜，要想彻底改变，除⾮不让各⼤⼚商定制化，这势必导致Android⼿机完全同质化，⼿机⼚商就没法玩了，等于⾃掘坟墓，Google肯定不会这么⼲。于是，Google在Android 10.0提出了”Project Mainline“，将对隐私、安全、兼容性造成重⼤影响的少数模块独⽴成module，每个module打包成APEX格式（⼀种类似于APK的新
格式），由Google通过应⽤商店定期来升级，从⽽保证低版本的⼿机不会因为碎⽚化⽽得不到隐私、安全与兼容性的更新。这些module是由Google维护的主线，各⼤⼚商只能跟Google沟通并将代码upstream到AOSP主线。Google花费了⼤量的⼈⼒在努⼒完善并推⾏Mainline，Google希望统⼀管控的机制，⼚商希望最⼤的⾃由定制空间，这是⼀场有趣的⾓逐，笔者跟团队⼀起跟Google协商落地module的落地计划，最终将某些module影响较⼤模块争取Android 11再上
线，Mainline更新机制如下图。
Mainline更新机制
4. 应⽤演进
Android系统离不开各App来提供丰富的功能，下⾯再来简单说⼀说应⽤的⼀些技术演进。
移动端跨平台技术：从最开始以Cordova为基础(依赖于WebView)的Hybrid混合开发技术，到React Native的桥接（将JS转为Native）的技术，再到最新的Flutter技术。Flutter是Google发布的全新的移动跨平台UI框架，渲染引擎依靠跨平台的Skia图形库来实现，依赖系统的只有图形绘制相关的接⼝，可以在最⼤程度上保证不同平台、不同设备的体验⼀致性，逻辑处理使⽤Dart语⾔，执⾏效率⽐JavaScript⾼。另
外，Google内部正在开发的另⼀个操作系统Fuchsia的UI layer采⽤的是Flutter，也就是说Flutter天然可以⽀持Android、IOS以及未来的Fuchsia。在⼤前端⽅向，对于跨平台开发中⼀直在不断迭代中寻更好、更优的解决⽅案，⽬前来看Flutter还是更有优势。
google官方下载app应⽤架构：MVC模式（Model–view–controller）但Activity类过于臃肿，为解决这个问题，有了MVP（Model–view–
presenter），presenter不仅要操作数据，⽽且要更新view；再到MVVM（Model-View-ViewModel）
解决了MVP⼤量的⼿动View和Model同步的问题，提供双向绑定机制。
热修复与插件化技术：热修复的主要应⽤场景是为了让⽤户⽆感得修复线上缺陷，⽐如Tinker，Andfix，Sophix等。插件化是为了减少模块耦合，可减少主程序的规模，可按需加载，⽐如DroidPlugin，OpenAtlas等。关于各个热修复与插件化的细节不再展开，这⾥就说⼀点，Android 7.0对Native的NDK的调⽤限制是⼿铐，尤其是Android 9.0对Java层SDK的调⽤限制就是脚铐，那么对于Android应⽤想再搞插件化之类的⿊科技便是带着脚⼿铐跳舞，能跳但舞姿可能不太美观。
App Bundle：随着应⽤不断演讲，功能越来越复杂，且应⽤针对不同屏幕设备、不同国家语⾔资源都打包在同⼀个App，导致应⽤包不断增⼤，据统计⾃2012年以来应⽤包⼤⼩增长5倍。虽然现在⼿机的存储空间越来越⼤，但⽤户照⽚、视频等媒体⽂件品质在逐渐提升，导致设备可⽤空间逐渐紧缩。为此Google在去年Google I/O⼤会讲述Android引⼊新的App动态化框架（即Android App Bundle，缩写为AAB）。利⽤Split
Apk完成动态加载，使⽤AAB动态下发⽅式，可显著缩⼩应⽤体积，减少对存储空间的占⽤。
Kotlin：是Google推荐的官⽅静态编程语⾔，与Java互通，可相互转换。Kotlin编译成Java字节码，也可以编译成JavaScript，运⾏在没有JVM 的设备上，简洁安全。使⽤Kotlin更快速地编写Android应⽤，可以提⾼开发者的⼯作效率，少编写样板代码，被称之为 Android 世界的Swift。⾕歌开发者社区
做过⼀个问卷调查，⼤概有40%的Android开发者已使⽤过Kotlin。这⾥并⾮⿎励⼤家⼀定都要使⽤Kotlin，学习新语⾔就像⼀次投资，要权衡团队成本与收益之间的利弊。
5. Fuchsia
2016年开始，Google有⼀超过百⼈的⼯程师团队秘密研发⼀款名为Fuchsia的新系统，该团队很豪华，有来⾃Android、iPhone、WebOS、Chrome、Flutter等核⼼⼯程师，这么多优秀的⼈在⼀起研发这个项⽬，的确值得期待。Fuchsia的内核采⽤Zircon，UI层采⽤Flutter框架，底层渲染Escher，⽀持Vulkan作为底层Graphics API。
提到Vulkan，顺便说⼀下，去年笔者在美国跟Android团队讨论到并问及Vulkan未来的规划，Google表⽰未来⼏年会⼤⼒推⼴Vulkan技
术，Vulkan是⼀种跨平台的⾼性能低开销的图形接⼝，在移动设备上⽐OpenGL ES有着更出⾊的表现。Vulkan将会是未来Android平台的⼀个发展⽅向，尤其是游戏领域，⽐如王者荣耀Vulkan版本。
在2017年5⽉，Google的Android⼯程副总裁Dave Burke称Fuchsia是早期实验项⽬，⽽在⾕歌内部有很多这类实验项⽬，存在很⼤未知变数。2017年11⽉，Google研发⼈员表⽰Fuchsia⽀持Swift，⾜见打造统⼀操作系统的野⼼。在过去的Google I/O⼤会只字未提及
Fuchsia，Google官⽅回应不清楚Fuchsia会在出现在什么设备。
Fuchsia会是Android的终结者吗? 笔者认为⾄少未来五年内不太可能取代Android。当年为了和苹果iOS抗衡，Android系统研发作为Google重中之重，在这种情况下，Android诞⽣依然花费了Google 3年时间。⽽Fuchsia只是公司⽬前的实验项⽬，且Fuchsia并⾮基于业界成熟Linux内核，⽽是采⽤全新Zircon内核，项⽬⼯程路还很远。
笔者简单研究了⼀下Fuchsia系统源码，总结了⼀下Fuchsia的整个技术架构图如下所⽰。
Fuchsia技术架构图
从Fuchsia技术架构来看，内核层zircon的基础LK是专为嵌⼊式应⽤中⼩型系统设计的内核，代码简洁，适合嵌⼊式设备和⾼性能设备，⽐如IOT、移动可穿戴设备等，⽬前这些领域标准化级别的垄断者。以及在框架层中有着语⾳交互、云端以及智能化等模块，由此笔者揣测未来

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。