作者：钱唐
从何而来
来到2021年，5G从2019年商用那刻起，算是「元年」了3年。随着Android 10/11两个版本的迭代，iPhone12以及iOS14的出现，移动蜂窝网络的最大群体总算开始梦想照进现实，虽然5G本身针对「手机」用户现阶段带来的提升并不是3G->4G那样的肉眼可见，并且这一代的突破从现阶段看也不仅只是做给手机用户的，从2019年到今天，依然还是那一句“时延”“带宽”在寻找新的业务场景和赛道。
代码滚滚，App的开发码工们带着他们的历史包袱，迎接这新技术、新硬件的到来，这里打算聊聊5G来了后，“传统”的移动应用开发中的坑。
现状
Changing world never stops changing.如下现状仅截止文章更新时间点。
现状1：用户看到手机5G图标不代表他用的一定是5G
用户看到NR/5G标记不代表当前用的一定是「开发同学」认为的5G-NR。
对于最终用户的体感，看到信号栏上出现了5G/5G+/NR的时候，就认为5G来了。但是放在大背景下，这个图标的显示其实隐匿了一系列技术边界问题：
- NR+NSA是5G不？要不要区分SA和NSA来显示？
- 覆盖不足或者功率考量下，是否需要真实的频繁更新状态？
这类问题通信界的大神和运营商、设备商商业大师都把排列组合思考进去，整体来看针对在5G相关的通讯设施中，如果你的手机支持NR的情况下，你接入的网络如果是5G-SA组网模式，妥妥的显示5G。针对NSA则可能碰到的类型如下，这边统一搬运下：
基于上述的可能性，终端显示是否5G的情况，目前国内的配置根据各大运营商定制的需求，当前5G图标的显示策略主推“D+A”方案 ：
- 在空闲态（没有数据业务的状态，例如：待机）使用“D方案”；
- 在连接态（有数据业务使用的状态，例如：看视频、聊微信、待机后台在下载文件等）使用“A方案”；
方案具体逻辑介绍如下：
如果进一步深究，这个是基于什么规范和标准做的？一句话总结：3GPP标准参考+*法规的基础上，运营商落地对应配置文件，终端设备读取配置展示。如果有兴趣的可以参考这篇文章详解国内运营商当前配置的细节：「5G图标显示策略」引用[2]
现状2：Android开发者没有直接获取5G_NSA的状态
基于现状1，我们知道当用户看到5G标记的情况略复杂，但是作为应用开发者，咱其实不care它的复杂度，只要我们的代码能跟着用户界面的变化去变化就行，反正咱跑的是代码不怕变化多。但是，坏消息是咱还没法获取真正的排列组合……
支付宝网络终端团队，2018年起一直在追踪AOSP仓库中针对NewRadio相关的适配支持，在国内最早的华为手机支持5G空口时，Android-9本身有5G相关的网络类型状态-TelephonyManager#NETWORK_TYPE_NR，但是关于这个枚举的一系列变化，也能发现Google内部对于5G网络类型的适配工作中直至今日尚不明确，譬如：
1、直至2020年10月才添加明确注释，NETWORK_TYPE_NR指的是NR_SA，如果是NR_NSA, 对不起，TelephoneManger会告诉你是LTE。
https://android.googlesource.com/platform/frameworks/base/+/a49fb9831e2133f7fb3452bcc62c0e6802fbd36d%5E1..a49fb9831e2133f7fb3452bcc62c0e6802fbd36d/
@@ -2802,7 +2802,11 @@
/** Current network is LTE_CA {@hide} */
@UnsupportedAppUsage
public static final int NETWORK_TYPE_LTE_CA = TelephonyProtoEnums.NETWORK_TYPE_LTE_CA; // = 19.
/** Current network is NR(New Radio) 5G. */
/**
* Current network is NR (New Radio) 5G.
* This will only be returned for 5G SA.
* For 5G NSA, the network type will be {@link #NETWORK_TYPE_LTE}.
*/2、NETWORK_TYPE_NR算什么？TelephonyManger.getNetworkClass()接口摇摆不定
2018年底，我们就在AOSP group中针对NETWORK_TYPE_NR在网络类型分类接口中的未适配给Google提了issue。Android-10的中间版本针对这个问题修复适配上了: public static final int NETWORK_CLASS_5_G = 4，例如Android_10_r38引用[3]。
但是在后续的版本中，这个类型分类又移除了，例如Android_10_r47 引用[4]。
甚至2020年3月的master，这个隐藏方法直接被删除了。
基于类似的改动，意味着，当一款Android设备在发布的时刻，他引用的实际release分支中带入的TelephonManger对于NETWORK_TYPE_NR的网络类型归类，在系统中可能是4G，可能是UNKNOWN，可能是5G。
小结下现状2上述的分析，对于开发者而言：
- 用户看到5G，但是你代码看不到；
- 你拿到了SA的NR标，NETWORK_TYPE_NR，但是你反射系统的分类，告诉你可能是3个答案。
现状3：iOS14对于5G标识的支持还不错，但是...
Android因为支持5G比较早，加上机器碎片度高，难免出现各种不适。iOS平台自从iOS14起开始支持5G且设备直接基于iPhone12开始支持。系统中添加了这两个常量：
CORETELEPHONY_EXTERN NSString * const CTRadioAccessTechnologyNRNSA API_AVAILABLE(ios(14.0)) API_UNAVAILABLE(macos);
CORETELEPHONY_EXTERN NSString * const CTRadioAccessTechnologyNR API_AVAILABLE(ios(14.0)) API_UNAVAILABLE(macos);
通过适配Reachability库，iOS14上能够区分NSA和SA的5G，棒棒的！
不过，你在iOS14.2上试试？灰度过程中发现部分闪退的场景，推测是部分运行时提供的常量在设备中不存在。14.3目前看妥妥的！
影响和解法
用户侧手机5G趋势
毫无疑问，5G即使再搞几个元年，对于用户生态的渗透是毫无疑问的，从支付宝网络技术的雷达上看，我国2021年1月上旬，SA网络部署速度明显加快，目前已经「高」达5‰的访问PV比例，上月同期仅徘徊在1‰。
如果你要问我NSA的占比如何，请仔细阅读前文：
建议与解法
1 无法提供用户感知一致的网络服务
产品设计层面，需要充分考虑当前移动App底层系统、用户设备的上述现状，针对需要做「5Gxxx功能」时，确保用户的认知5G状态和我们的服务一致性。避免「为什么我在5G网络，但是xxx功能没生效」的问题。
短期内，应用生态或许也不会有这类述求？
2 基础网络框架收口复杂度
业务开发需要了解上述差异，但是更好设计还是在网络基础SDK层面提供接口屏蔽，避免直接使用系统接口甚至反射调用隐藏的接口。
上述适配目前停留在纯粹的系统接口包装类型，针对「我就是想针对Android NSA也要能识别」，目前网上也有各路大神针对不同的厂商提供的各种隐藏接口提供封装。假若未来真的有强的此类需求，我们也可能会需要做类似的探索。同时也欢迎大家提供宝贵建议和优秀的方案。
3 持续观察
回到文首，真正针对5G行业对于网络的关注，其实不应该仅仅局限于手机App的开发本身，还是需要持续关注新技术背后的新接入架构、应用场景等等。但是随着运营商不断推进，首当其冲的App们，我们真的准备好了吗？
欢迎大家一起探讨 5G 高大上背后的各种实际痛处，排雷扫雪，先让用户们用的开心，用的无感。
引用资源
[1] https://zhuanlan.zhihu.com/p/111538019
[2]https://mp.weixin.qq.com/s/CHtnNU4pFXAM3OlXijwO0w
[3]http://aosp.opersys.com/xref/android-10.0.0_r38/xref/frameworks/base/telephony/java/android/telephony/TelephonyManager.java
[4]http://aosp.opersys.com/xref/android-10.0.0_r47/xref/frameworks/base/telephony/java/android/telephony/TelephonyManager.java
[5]https://android.googlesource.com/platform/frameworks/base/+/0f0432c1f6ed99db3a607df63909bc6a2a445506
关注我们，每周 3 篇移动技术实践&干货给你思考！