android技术介绍

A. Android无线开发的几种常用技术（阿里巴巴资深

完整的开发一个android移动App需要经过从分解需求、架构设计到开发调试、测试、上线发布等多个阶段，在发布后还会有产品功能上的迭代演进，此外还会面对性能、安全、无线网络质量等多方面的问题。
移动App的产品形态各不相同，有的是内容类，有的是工具类，有的是社交类，所以它们的业务逻辑所偏重的核心技术有些差别，但它们都会用到一些常用的技术方案。今天我们就先来简单介绍一下这些常用技术，以后会专门分专题来详细介绍这些技术的原理和使用场景。

1. Multidex
在Dalvik虚拟机所使用的dex文件格式中，用原生类型short来索引文件中的方法数，也就是最多只能有4个字节65536个method，在打包apk的过程中会把工程所需要的全部class文件都合并压缩到一个dex文件中，也就是说自己开发的代码加上外部引用的库的方法总数不能超过65535。
随着业务逻辑的不断增长，很容易就会超过这个限制，在编译期间就会遇到这样一个错误：

还好google官方给出了一个解决方案Multidex，它会把dex文件拆成两个或多个，第二个dex文件叫classes2.dex，在Application实例化后会从apk中解压出classes2.dex并将其拷贝到应用的目录下，通过反射将其注入到当前的ClassLoader中。但是这个方案非但不能解决一切问题也不能直接拿来用，而要加入自己的一些改造，来解决NoClassDefFoundError、INSTALL_FAILED_DEXOPT等问题，以保证自己的dex被顺利的加载流畅的执行。

2. Plugin
Multidex虽然可以解决方法数的限制，但随着业务逻辑越来越多，apk的大小也变得越来越多，而且有一些功能并非全部用户都想用的，所以会把一些功能模块独立出来做成插件，让用户可以按需下载更新，这样既减小了包大小，又改善了用户体验。

插件类似于windows的dll文件，放在某个特定目录，应用程序主框架会用LoadLibrary加载各dll文件，按插件接口去访问插件。Android的插件技术也是这样，利用一个进程可以运行多个apk的机制，用ClassLoader将宿主apk之外的类加载进来，插件的context可以通过createPackageContext方法创建。因为插件中的activity，service等组件如果没有在AndroidManifest.xml中声明将不能运行，所以需要预先在AndroidManifest.xml中声明一个代理类（ProxyActivity），将这个ProxyActivity传给插件，让插件的activity也有访问资源的能力。

3. Hot Patch
有时一些严重的crash bug或漏洞需要紧急修复，但有些用户不会或不愿意立即升级，而且频繁升级，没有特别的功能更新只是修复bug的升级，对活跃用户是一种伤害。热补丁就可以解决这样的窘境，它是一种可以线上修复的技术方案，有动态改变方法的能力，一般大型的移动应用都会使用热补丁来处理紧急事件。

Hot Patch可以通过hook来修改java的method，注入自己的代码，实现非侵入式的runtime修改，或者采用正向编程，通过工具生成patch文件，通过jni bridge指向补丁文件中的方法。还有就是利用ClassLoader，在dex中查找class时，如果找到类则返回，找不到就从下一个dex文件中继续查找，由此可以想到，在把问题修复后，可以单独生成一个dex，通过反射插入到dexElements数组的最前面，这样就能让dalvik加载补丁里的类了。

4. Push通道
Push是移动App常用的一种无线技术，基础是基于TCP的心跳机制，和客户端维持一个长连接。用处是向客户端推送消息，或者代替客户端定时去从服务器pull的策略，改为客户端接收到push消息后再去pull。
如果每个应用都自己实现push通道的话，cpu就会不定时地经常被唤醒，耗电量达到难以容忍的程度，而且自己搭建push平台的成本也很大，实时性和效率也存在问题，一般都直接使用一些服务商提供的push方案，这些push平台一般都经过了优化设计，在跨平台和网络穿透性、长连接心跳包、多客户端App链路复用、服务和连接保活等技术上做了优化。比如Agoo最初是淘宝无线事业部开发的push服务，在逐渐完善和支撑淘系其他app后，通过服务端容量、通讯协议优化、业务和开放能力的拓展改进后，与友盟等合作，开始向第三方提供推送服务。

5. 应用加固
一款热门的移动app或游戏发布后会受到很多的关注，经常会遇到二次打包的盗版行为，破解者要么修改游戏的资源文件、道具、分值甚至直接把访问的站点指向自己架设的服务器，损害了开发者的利益；要么偷偷植入自己的恶意代码，表面上看起来跟正版的app完全一样，在后台却盗取用户隐私，植入木马；要么通过反向工程学习原app的核心技术，打破技术上的竞争壁垒。
为了防止被破解只通过混淆是远远不够的，即使是在native层混淆也还是会被人熟练的反编译，所以需要一套对apk的保护方案来反调试、防逆向和防篡改。一般的加固方法都是对原apk先进行加密，然后和壳合并生成新的apk。壳是用来解密apk的dex文件。当应用启动时，壳先解密原apk，准备好自己定义的ClassLoader，然后获取源程序中的Application名称，通过反射找到正确的Application对象，运行它的onCreate方法，这样原apk才能被真正运行。其他一些反调试的方法有针对反编译工具，在源程序中加入一些无效的指令或无效的指针，引发反编译工具的崩溃，还有就是加花指令，利用一些跳转，堆栈操作等指令，让破解者无法清楚地理解反汇编后的内容。

6. 其他
除了上述几点外，在服务端还会涉及灰度策略、链路流量优化、动态更新配置、防DNS劫持等技术，在客户端会涉及用户埋点上报、在线监控、进程保活、H5和native混合开发、注入框架等。

B. Android 多返回栈技术详解

用户通过系统返回按钮导航回去的一组页面，在开发中被称为返回栈 (back stack)。多返回栈即一堆 "返回栈"，对多返回栈的支持是在 Navigation 2.4.0-alpha01 和 Fragment 1.4.0-alpha01 中开始的。本文将为您展开多返回栈的技术详解。

无论您在使用 Android 全新的 手势导航 还是传统的导航栏，用户的 "返回" 操作是 Android 用户体验中关键的一环，把握好返回功能的设计可以使应用更加贴近整个生态系统。

在最简单的应用场景中，系统返回按钮仅仅 finish 您的 Activity。在过去您可能需要覆写 Activity 的 onBackPressed() 方法来自定义返回操作，而在 2021 年您无需再这样操作。我们已经在 OnBackPressedDispatcher 中提供了 针对自定义返回导航的 API。实际上这与 FragmentManager 和 NavController 中 已经 添加的 API 相同。

这意味着当您使用 Fragments 或 Navigation 时，它们会通过 OnBackPressedDispatcher 来确保您调用了它们返回栈的 API，系统的返回按钮会将您推入返回栈的页面逐层返回。

多返回栈不会改变这个基本逻辑。系统的返回按钮仍然是一个单向指令 —— "返回"。这对多返回栈 API 的实现机制有深远影响。

在 surface 层级，对于 多返回栈的支持 貌似很直接，但其实需要额外解释一下 "Fragment 返回栈" 到底是什么。FragmentManager 的返回栈其实包含的不是 Fragment，而是由 Fragment 事务组成的。更准确地说，是由那些调用了 addToBackStack(String name) API 的事务组成的。

这就意味着当您调用 commit() 提交了一个调用过 addToBackStack() 方法的 Fragment 事务时， FragmentManager 会执行所有您在事务中所指定的操作 (比如 替换操作 )，从而将每个 Fragment 转换为预期的状态。然后 FragmentManager 会将该事务作为它返回栈的一部分。

当您调用 popBackStack() 方法时 (无论是直接调用，还是通过系统返回键以 FragmentManager 内部机制调用)，Fragment 返回栈的最上层事务会从栈中弹出 -- 比如新添加的 Fragment 会被移除，隐藏的 Fragment 会显示。这会使得 FragmentManager 恢复到最初提交 Fragment 事务之前的状态。

也就是说 popBackStack() 变成了销毁操作: 任何已添加的 Fragment 在事务被弹出的时候都会丢失它的状态。换言之，您会失去视图的状态，任何所保存的实例状态 (Saved Instance State)，并且任何绑定到该 Fragment 的 ViewModel 实例都会被清除。这也是该 API 和新的 saveBackStack() 方法之间的主要区别。 saveBackStack() 可以实现弹出事务所实现的返回效果，此外它还可以确保视图状态、已保存的实例状态，以及 ViewModel 实例能够在销毁时被保存。这使得 restoreBackStack() API 后续可以通过已保存的状态重建这些事务和它们的 Fragment，并且高效 "重现" 已保存的全部细节。太神奇了！

而实现这个目的必须要解决大量技术上的问题。

虽然 Fragment 总是会保存 Fragment 的视图状态，但是 Fragment 的 onSaveInstanceState() 方法只有在 Activity 的 onSaveInstanceState() 被调用时才会被调用。为了能够保证调用 saveBackStack() 时 SavedInstanceState 会被保存，我们 还 需要在 Fragment 生命周期切换 的正确时机注入对 onSaveInstanceState() 的调用。我们不能调用得太早 (您的 Fragment 不应该在 STARTED 状态下保存状态)，也不能调用得太晚 (您需要在 Fragment 被销毁之前保存状态)。

这样的前提条件就开启了需要 解决 FragmentManager 转换到对应状态的问题，以此来保障有一个地方能够将 Fragment 转换为所需状态，并且处理可重入行为和 Fragment 内部的状态转换。

在 Fragment 的重构工作进行了 6 个月，进行了 35 次修改时，发现 Postponed Fragment 功能已经严重损坏，这一问题使得被推迟的事务处于一个中间状态 —— 既没有被提交也并不是未被提交。之后的 65 个修改和 5 个月的时间里，我们几乎重写了 FragmentManager 管理状态、延迟状态切换和动画的内部代码，具体请参见我们之前的文章《全新的 Fragment: 使用新的状态管理器》。

随着技术问题的逐步解决，包括更加可靠和更易理解的 FragmentManager ，我们新增加了两个 API: saveBackStack() 和 restoreBackStack() 。

如果您不使用这些新增 API，则一切照旧: 单个 FragmentManager 返回栈和之前的功能相同。现有的 addToBackStack() 保持不变 —— 您可以将 name 赋值为 null 或者任意 name 。然而，当您使用多返回栈时， name 的作用就非常重要了: 在您调用 saveBackStack() 和之后的 restoreBackStack() 方法时，它将作为 Fragment 事务的唯一的 key。

举个例子，会更容易理解。比如您已经添加了一个初始的 Fragment 到 Activity，然后提交了两个事务，每个事务中包含一个单独的 replace 操作:

也就是说我们的 FragmentManager 会变成这样:

比如说我们希望将 profile 页换出返回栈，然后切换到通知 Fragment。这就需要调用 saveBackStack() 并且紧跟一个新的事务:

现在我们添加 ProfileFragment 的事务和添加 EditProfileFragment 的事务都保存在 "profile" 关键字下。这些 Fragment 已经完全将状态保存，并且 FragmentManager 会随同事务状态一起保持它们的状态。很重要的一点: 这些 Fragment 的实例并不在内存中或者在 FragmentManager 中 —— 存在的仅仅只有状态 (以及任何以 ViewModel 实例形式存在的非配置状态)。

替换回来非常简单: 我们可以在 "notifications" 事务中同样调用 saveBackStack() 操作，然后调用 restoreBackStack() :

这两个堆栈项高效地交换了位置:

维持一个单独且活跃的返回栈并且将事务在其中交换，这保证了当返回按钮被点击时， FragmentManager 和系统的其他部分可以保持一致的响应。实际上，整个逻辑并未改变，同之前一样，仍然弹出 Fragment 返回栈的最后一个事务。

这些 API 都特意按照最小化设计，尽管它们会产生潜在的影响。这使得开发者可以基于这些接口设计自己的结构，而无需通过任何非常规的方式保存 Fragment 的视图状态、已保存的实例状态、非配置的状态。

当然了，如果您不希望在这些 API 之上构建您的框架，那么可以使用我们所提供的框架进行开发。

Navigation Component 最初 是作为通用运行时组件进行开发的，其中不涉及 View、Fragment、Composable 或者其他屏幕显示相关类型及您可能会在 Activity 中实现的 "目的地界面"。然而，NavHost 接口 的实现中需要考虑这些内容，通过它添加一个或者多个 Navigator 实例时，这些实例 确实 清楚如何与特定类型的目的地进行交互。

这也就意味着与 Fragment 的交互逻辑全部封装在了 navigation-fragment 开发库和它其中的 FragmentNavigator 与 DialogFragmentNavigator 中。类似的，与 Composable 的交互逻辑被封装在完全独立的 navigation-compose 开发库和它的 ComposeNavigator 中。这里的抽象设计意味着如果您希望仅仅通过 Composable 构建您的应用，那么当您使用 Navigation Compose 时无需任何涉及到 Fragment 的依赖。

该级别的分离意味着 Navigation 中有两个层次来实现多返回栈:

仍需特别注意那些 尚未 更新的 Navigator ，它们无法支持保存自身状态。底层的 Navigator API 已经整体重写来支持状态保存 (您需要覆写新增的 navigate() 和 popBackStack() API 的重载方法，而不是覆写之前的版本)，即使 Navigator 并未更新， NavController 仍会保存 NavBackStackEntry 的状态 (在 Jetpack 世界中向后兼容是非常重要的)。

如果您仅仅在应用中使用 Navigation，那么 Navigator 这个层面更多的是实现细节，而不是您需要直接与之交互的内容。可以这么说，我们已经完成了将 FragmentNavigator 和 ComposeNavigator 迁移到新的 Navigator API 的工作，使其能够正确地保存和恢复它们的状态，在这个层面上您无需再做任何额外工作。

如果您正在使用 NavigationUI，它是用于连接您的 NavController 到 Material 视图组件的一系列专用助手，您会发现对于菜单项、 BottomNavigationView (现在叫 NavigationRailView ) 和 NavigationView ，多返回栈是 默认启用 的。这就意味着结合 navigation-fragment 和 navigation-ui 使用就可以。

NavigationUI API 是基于 Navigation 的其他公共 API 构建的，确保您可以准确地为自定义组件构建您自己的版本。保证您可以构建所需的自定义组件。启用保存和恢复返回栈的 API 也不例外，在 Navigation XML 中通过 NavOptions 上的新 API，也就是 navOptions Kotlin DSL，以及 popBackStack() 的重载方法可以帮助您指定 pop 操作保存状态或者指定 navigate 操作来恢复之前已保存的状态。

比如，在 Compose 中，任何全局的导航模式 (无论是底部导航栏、导航边栏、抽屉式导航栏或者任何您能想到的形式) 都可以使用我们在与 底部导航栏集成 所介绍的相同的技术，并且结合 saveState 和 restoreState 属性一起调用 navigate() :

对用户来说，最令人沮丧的事情之一便是丢失之前的状态。这也是为什么 Fragment 用一整页来讲解 保存与 Fragment 相关的状态，而且也是我非常乐于更新每个层级来支持多返回栈的原因之一:

如果您希望了解 更多使用该 API 的示例，请参考 NavigationAdvancedSample (它是最新更新的，且不包含任何用于支持多返回栈的 NavigationExtensions 代码)。

对于 Navigation Compose 的示例，请参考 Tivi。

如果您遇到任何问题，请使用官方的问题追踪页面提交关于 Fragment 或者 Navigation 的 bug，我们会尽快处理。