8月不支持64位，App将无法上架Google Play！需要怎么做？
|
副问题[/!--empirenews.page--]
一. 序 工作是这样的，前几天收到 Google Play 的关照邮件，这才想起来有几款在 Google Play 上架的 App，还没有支持 64 位 CPU 架构。
早在本年一月份，Google 就宣布关照，在本年 8 月 1 日开始，上架的 App，除了提供 32 位的版本之外，还必要提供 64 位的版本。 这眼看着离逼迫进级窗口，只剩下最后两个月的时刻，许多第三放来历的 so 支持库，假如没有提供 64 位的版本，还必要同步鼓舞相助方更新。 那本日就来聊聊 Android APK 进级 64 位 CPU 架构的细节，看看你的应用是否必要支持 64 位 CPU 架构，假如要支持，必要做什么? 二. Android CPU 架构细节 2.1 这是逼迫类型 早在 2015 年 Google 宣布 Android 5.0 版本时，就插手了 64 位处理赏罚器的支持，其时就提出了以 19 年 8 月为最后的更新支持限期，并在本年又重申了这个逼迫要求。 只要你的 App 存在国际版，必要上架 Google Play，这个划定都必需准守。 2.2 那些 APK 必要支持 64 位? 那若是你有一个国际化的 App 必要维护，在本年 8 月 1 日之后，更新 Google Play 时，就必需提供 64 位的版本。 那这里说的 64 位版本支持，到底是什么? 假如你的应用，完满是行使 Java 可能 Kotlin 编写代码，不包括任何原生(Native)的支持，那么就暗示这个应用已经支持 64 位。 可是应用内行使了任何原生(Native)的支持(so 库)，就必要针对这些 so 文件，针对差异的 CPU 架构提供差异的版本的 so 支持。 必要留意的是，有些时辰，在我们自身的代码中，确实没有效到原生的支持，可是在 App 中行使的一些第三方库中却包括了。 此时最稳妥的方法，就是针对最终打包天生的 APK 文件举办说明，来判定是否必要提供 64 位架构的支持。 那 CPU 架构是什么?什么又是 ABIs? 在 Android 中，固然 ARM 的 CPU 架构是主流，可是今朝至少支持几类 CPU 架构，ARM 下的 ARMv5/ARMv7/ARMv8，x86 下的 x86/x86_64，以及很不常见的 MIPS 类架构。这里的每一种 CPU 范例对应了一种 ABI(Application Binary Interface)，譬喻 armeabi-v7a 中的 "armeabi" 指的就是 ARM 这种范例的 ABI，后头的 “v7a” 指的是 ARMv7。 凡是我们可以简朴的领略：
这三个观念是相通的，凡是在技能接头中，说的是一个对象。 2.3 为什么是逼迫的? 谷歌之以是会有逼迫更新的要求，很大一方面缘故起因是由于作为开拓者，更新补全 ABIs 的动力并不敷。 首要缘故起因来自以下几个方面： 1. APK 体积增大 针对差异 CPU 架构提供对应的 so 库，虽然是服从最高的做法。可是这种做法，最直接的影响，就是 APK 文件的增大，有些时辰补全这些 so 支持，会导致整个 APK 体积有几 MB 到几十 MB 的增幅。 APK 体积优化，许多公司都将其算做是一个 KPI 指标，插手一个新特征，导致 APK 体积的增大，在许多时辰都是不应承的，为此换技能方案都是常有的事。 从增添的角度来看，越小的 APK，用户下载的意愿就更大，转化率就越高。 可是跟着此刻流量越来越自制，近期 iOS 已经将 蜂窝数据下载限定从 150MB 放宽至 200MB，针对安装包的体积优化尺度，也可以恰当的放宽了。 2. 自己有必然的兼容性 应用市场中，许多 APP 着实都只有 armeabi 可能 armeabi-v7a 的支持，而市面上的装备，支持的并不是只有这两种 CPU 架构。 可是这并没有影响在这些装备上运行这些 App，这就是 CPU 架构的兼容性。 差异架构，并不料味着之间必然是不兼容的，在差异版本下，着实提供了两种 ABI 支持，别离是
这种兼容计策就不在这里睁开说了，最简朴的就是 64 位的 arm64-v8a 在支持自己的 CPU 架构之外，还兼容支持 armeabi-v7a、armeabi;x86_64 同时也兼容支持 X86 和 armeabi。 你看，固然添加 64 位的支持，可以有用的行使硬件的上风，晋升机能，但大部门时辰，回收兼容方案，是一种更简朴的方法。 3. 没有对应架构的 so 文件 这个缘故起因就较量忧伤了，我们 App 中行使到的原生代码，着实有两种。 一种是我们本身编写的，源码在手，想提供对应的支持，修改设置从头编译一下就办理了。 另一种来自第三方提供的，这种时辰我们没有源码，无法做到从头编译，只能和第三方雷同，看能不能提供一个对应 CPU 架构的 so 库。这种环境就很是的不行控了。 譬喻较量常见的一个 WebView 的替代方案，腾讯 X5 内核，自己就不提供 X86 的库。
官方给的提议是行使 armeabi 可能 armeabi-v7a。 在前文有提到，ABIs 自己是有一些兼容法则的，可是这种兼容法则，是有前提的。 举个例子：64 位的 arm64-v8a 是可以向下兼容的，可是这有个条件，那就是假如你的项目中，有 armeabi-v7a 和 arm64-v8a 两个目次，就必要担保这两个目次下支持的 so 库文件保持同等。
在左边的环境下，假如 arm64-v8a 的手机用到 b.so 时，就会去 arm64-v8a 目次下找，虽然是找不到 b.so 文件的，就会直接抛非常，而不会再去 armeabi-v7a 目次下继承探求。 假如必要提供多套 ABIs 的支持，就必要担保全部 ABI 目次下，对应的 so 文件保持同等。 而在一些非凡的环境下，我们无法提供对应平台的 so 库，譬喻腾讯 X5 内核这种环境，就必要做个弃取了。 （编辑：湖南网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
