网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。
一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
注意：你不应该把和 一起使用。同时使用增加了机会，你会引入一个错误，因为它们之间的冲突。为帮助决定使用哪一个，请阅读 Distributing to Specific Screens。如果你不能避免同时使用，be aware that for any conflicts in agreement between agiven size, “false” will win.
- * API Level*
这是基于您的manifest文件元素。你可以使用android：minSdkVersion和android：maxSdkVersion 属性来指定不同的API级别的支持。
例如，你可以发布你的应用程序一个APK的支持API level 4 - 7（Android 1.6 - 2.1），使用唯一的API level 4或者更低，如果支持的API level 8及以上（Android 2.2 + ）使用API的level为8 或者更低。
注意：
-
If you usethis characteristic as the factor to distinguish multiple APKs, then the APKwith a higherandroid:minSdkVersion value must have a higher android:versionCode value. This is also true if two APKs overlap their devicesupport based on a different supported filter. This ensures that when a devicereceives a system update, Google Play can offer the user an update for yourapplication (because updates are based on an increase in the app version code).This requirement is described further in the section below about Rules for multiple APKs.
-
你应该避免使用android：maxSdkVersion在一般情况下，因为只要你正确使用public API开发您的应用程序，它始终是与未来版本的Android兼容。如果你想发布一个较高的API level不同的APK，你还没有需要到指定的最高版本，假如一个android：minSdkVersion是4，另一个是8，这个设备是8或者更高，那么这个设备将会选择android：minSdkVersion是8的APK。
Othermanifest elements that enable GooglePlay filters—but are not listed above—arestill applied for each APK as usual. However, Google Play does not allow you topublish multiple APKs based on variations of them. Thus, you cannot publishmultiple APKs if the above listed filters are the same for each APK (but theAPKs differ based on other characteristics in the manifest file). For example,you cannot provide different APKs that differ purely on the characteristics
发布multiple APKs的规则
在你发布您的应用程序的multiple APKs之前，你需要了解以下的规则，关于发布multiple APKs如何定义：
-
相同的应用程序发布的所有APKs你必须有相同的包的名称，并使用相同的证书密钥签署。
-
每个的APK 必须有一个不同版本的代码，由指定的 android：versionCode属性。
-
每个的APK 不能完全匹配的配置支持，另外的APK（也就是说，一个apk不能包含支持别的配置的设备）。
That is, each APK must declare slightly different support for at least one of the supported Google Play filters (listed above).
通常情况下，你会区分你的APKs基于一个特定的特性（如支持的纹理压缩格式），因此，每个的APK将申明为不同的设备支持。然而，它确定发布他们的支持略有重叠的多个APKs。当两个APKs做重叠（他们支持一些相同的设备配置），将接收设备属于重叠的范围内具有较高的版本代码（通过定义的APK android：versionCode）。
-
你不能启动一个新的APK取代一个版本的代码较低。例如，假设你有一个active 的屏幕尺寸小的APK - 正常版本代码是0400，然后尝试更换一个版本代码为0300相同屏幕尺寸的APK。这就出现了一个错误，因为这意味着以前的APK的用户将无法更新的应用程序。
-
需要一个较高的APK level 必须有一个更高的版本的代码。
这是true的，只有当：1、APKs不同，仅仅根据支持的API的levels（没有其他支持的过滤器， 区分彼此的APKs） 2、APKs时使用另一个支持的过滤器为基础，但有该过滤器内的APKs之间的重叠。
这是重要的，因为用户的设备收到来自谷歌的应用程序更新版本的代码只有Google play的APK高于目前在设备上的APK版本。这将确保，如果设备收到一个系统的更新，然后限定它以较高的API级别的APK安装，设备接收应用程序更新，因为该版本代码增加。
注：该版本的代码增加的大小是无关紧要的，它只是需要在更大的版本，支持更高的API levels。
下面是一些例子：
1、If an APK you’ve uploaded for API levels 4 and above (Android 1.6+) has a version code of 0400, then an APK for API levels 8 and above (Android 2.2+) must be 0401 or greater. In this case, the API level is the only supported filter used, so the version codes must increase in correlation with the API level support for each APK, so that users get an update when they receive a system update.
2、If you have one APK that’s for API level 4 (and above) and small - large screens, and another APK for API level 8 (and above) and large - xlarge screens, then the version codes must increase. In this case, the API level filter is used to distinguish each APK, but so is the screen size. Because the screen sizes overlap (both APKs support large screens), the version codes must still be in order. This ensures that a large screen device that receives a system update to API level 8 will receive an update for the second APK.
3、If you have one APK that’s for API level 4 (and above) and small - normal screens, and another APK for API level 8 (and above) and large - xlarge screens, then the version codes do not need to increase in correlation with the API levels. Because there is no overlap within the screen size filter, there are no devices that could potentially move between these two APKs, so there’s no need for the version codes to increase from the lower API level to the higher API level.
如果，未能遵守上述规则将会在Google Play上出现错误，要想激活您APKs，直到你解决这个错误，否者您将无法发布您的应用程序。
还有其他您激活您的APKs时可能发生的冲突，但是这将导致警告，而不是错误。警告，可以由以下原因引起：
1、当你修改的APK设备的特点，并没有其他APKs支持的??设备，然后属于支持的范围以外的“缩水”的支持。例如，如果目前的APK支持small和normal大小的屏幕，你改变它仅支持small屏幕，那么你已经减少了对设备的支持 ，在Google Play一些设备将再也看不到你的应用程序。您可以通过增加另外的APK，支持正常大小的屏幕 ，这样所有设备便支持了，这个问题便得到了解决。
2、当有两个或更多APKs之间的“重叠”。例如，如果支持的APKsizes small, normal, and large，而另外的APK支持large和XLARGE，有重叠，因为两个APKs支持large。如果不解决这个问题，那么large 设备都将收到的z这两个APK具有最高的version code。
当发生这种冲突时，你会看到一条警告消息，但仍然可以发布您的应用程序。
创建 Multiple APKs
================
一旦你决定发布 Multiple APKs，你可能需为每个发布的应用，要创建单独的Andr??oid项目，可以适当分开开发的APK。你可以通过简单的复制现有的项目，并给它一个新名称。（另外，你可能会使用 build系统，可以输出为不同的资源 -如textures --根据不同build的配置。）
提示：一种方式，以避免重复您的应用程序代码的大部分是使用 library project。 library project.持有共享代码和资源，其中可以包括在您的实际应用项目。
相同的应用程序创建多个项目，这是一个好的做法，以确定每个人的名字，表示设备上的APK限制，所以你可以很容易地识别它们。例如“HelloWorld_8”可能是API 8级及以上的设计了一个应用程序的一个好名字。
注：相同的应用程序发布的所有APKs 必须具有相同的包的名称，并使用相同的证书密钥签署。可以肯定你也了解每个多APKs规则。
指定版本的代码
每个相同的应用程序的APK，必须有一个独特的 version code,，通过指定的android:versionCode属性。当你发布multiple APKs ，一定要小心的指定version code,，因为他们每个人都必须是不同的，但在某些情况下，必须或应该被定义在一个特定的顺序，根据配置每个APK的支持。
定制version code
通常需要较高的API级别的APK必须有一个更高的版本代码。例如，如果您创建两个APKs以支持不同的API级别，较高的API级别的APK必须有更高版本的代码。这将确保，如果设备receiver系统的更新，然后限定它以较高的API级别安装的APK，用户接收到一个更新的应用程序的通知。如何为更多的信息关于怎样要求apples，请参阅上面有关节多个APKs规则。
你也应该考虑版本代码的顺序如何，可能会影响它的APK用户收到任何因重叠覆盖的不同APKs或未来的变化，你可能使你的APKs。
例如，如果你有不同APKs根据屏幕上 size, such as one for small - normal and one for large - xlarge，但预见到的时候，你会改变的APKs是一个为小型和一个normal - XLARGE，然后你应该做的大版本的代码 - XLARGE的APK是较高的。这样，一个正常大小的设备将得到相应的更新，当你做出改变，因为版本的代码增加从现有的APK新的APK，支持现在的设备。
此外，创建多个不同根据不同的OpenGLtexture compression formats的支持AmultiplePKs时，要知道，许多设备支持多种格式。由于设备接收到的APK时有重叠覆盖两APKs的最高版本的代码，你应该之间的APKs order版本的代码，以便，首选的压缩格式的APK具有最高的版本代码。例如，您可能要执行单独的版本，您的应用程序使用的PVRTC，ATITC，和ETC1压缩格式。如果你喜欢这些格式，在这个确切的顺序，然后PVRTC应当是高版本的代码，接着ETC1应该是最低版本的代码。因此，如果设备支持PVRTC和ETC1，它接收PVRTC的APK，因为它具有最高的版本代码。
使用一个版本的代码scheme
为了让不同APKs以更新其版本他人的独立代码（例如，当你修复了一个bug仅为一个apk，并不需要更新所有APKs），你应该使用scheme 为您的版本的代码，它提供的计划足够的空间，使彼此之间的APK可以增加一个代码，而不需要增加在其他。你还应该包括你的代码的实际版本的名称（就是，用户可见的分配机android：versionName），所以很容易为您关联的版本代码和版本名称。
注意：当您增加的APK版本的代码，Google Play 会提示用户以前的版本更新程序。因此，为了避免不必要的更新，你不应该增加为APKs版本代码。
我们建议用至少7位数的版本代码：interger表示支持的配置，是在更高的序位，the lower order bits的名称（从android：versionName）。例如，当应用程序版本的名称是3.1.0版本的代码，API level 4的APK和API level 11的APK ，分别为0400310和1100310类似。前两个数字是该API的等级（4和11，分别）保留的中间2位是无论屏幕大小或的GL纹理格式（在这些例子中不使用），个数字为应用程序的版本名称（3.1.0）。图1显示了两个例子，基于两个平台版本（API level），屏幕尺寸size。
http://developer.android.com/images/market/version-codes.png
图1 一个版本代码的建议方案，使用API级别的前两个数字，第二和第三位的最大和最小的屏幕尺寸（1 - 4表示四个zizes）或者表示 the texture formats ，应用程序版本的最后三个数字。
这个版本的代码的计划仅仅是一个建议，你应该如何建立一个模式，它是可变化的， 为你你的应用程序的evolves。特别是，这个计划并没有提出解决、确定不同的纹理压缩格式的方案。可One option might be to define your own table that specifies a different integer to each of the different compression formats your application supports (for example, 1 might correspond to ETC1 and 2 is ATITC, and so on).
您可以使用任何你想要的方案，但您应该谨慎考虑您的应用程序的未来版本将需要增加他们的版本代码，并可以接收设备如何更新设备配置更改（例如，由于系统更新）时，或当修改配置为了 一个或几个APKs的支持。
Using a Single APK Instead
==========================
创建多个APKs发布在Google Play上面是个不正常的步骤。在大多数情况下，你应该大多数发布您的应用程序，是一个单一的APK，我们鼓励你这样做。当你遇到一个情况，在一个单一的APK变得很困难，你应该仔细考虑所有的选择，然后才决定发布多multiple APKs。
首先，只发布 一个single APK，遍支持所有设备的几个关键的好处：
- 发布和管理您的应用程序更容易。
只有一个APK的担心在任何特定时间，你不太可能成为混淆APK是什么。你也没有保持跟踪多个版本的代码，每个机构APK-只使用一个APK的，你可以简单地增加与每个发行版本的代码完成。
- 你需要管理只有一个的代码库。
虽然你可以使用一个 library project 多个Android项目之间共享代码，它仍然有可能在每个项目中，你会重现一些代码，这可能会变得难以管理，尤其是在解决Bug。
- 您的应用程序能够适应设备配置变化。
通过创建一个单一的APK，其中包含所有的资源为每个设备配置，应用程序可以适应配置在运行时发生的变化。例如，如果用户docks 或其他手机设备连接到一个更大的屏幕，还有一个改变，这将调用系统配置的变化，以支持更大的屏幕。如果你有不同的屏幕配置在相同的APK的所有资源，那么你的应用程序将为新的interface加载替代资源和优化用户体验。
- App restore across devices just works.
If a user has enabled data backup on his or her current device and then buys a new device that has a different configuration, then when the user’s apps are automatically restored during setup, the user receives your application and it runs using the resources optimized for that device. For example, on a new tablet, the user receives your application and it runs with your tablet-optimized resources. This restore process does not work across different APKs, because each APK can potentially have different permissions that the user has not agreed to, so Google Play may not restore the application at all. (If you use multiple APKs, the user receives either the exact same APK if it’s compatible or nothing at all and must manually download your application to get the APK designed for the new device.)
以下各节描述了一些其他的选项，在你决定发布multiple APKs支持不同配置的设备。
支持multiple GL textures
为了一个apk支持multiple GL textures，您的应用程序应该查询设备支持的GL纹理格式，然后使用appropriate（合适）的资源，或从Web服务器上下载。例如，为了保持你的APK体积小，可以查询不同的GLtextures格式的设备的支持，应用程序启动时第一次，然后只下载你需要该设备的textures。
为了获得最大的性能和兼容性，只要不影响视觉质量,应用程序应该使用ETC1 textures。然而，因为ETC1不能色度的急剧变化，如 line art 和 文本（大多数），图像处理，不支持Alpha，它可能不是最好的纹理格式。
单一的APK，你应该尝试使用ETC1 textures和未压缩的textures,只要合理，当使用ETC1不满足使用的需求时，考虑使用的PVRTC，ATITC，或DXTC。
下面是支持纹理压缩格式，从里面例如查询 GLSurfaceView.Renderer的：
public void onSurfaceChanged(GL10 gl, int w, int h) {
String extensions = gl.glGetString(GL10.GL_EXTENSIONS);
Log.d(“ExampleActivity”, extensions);
}
这将返回一个字符串，它列出了每个支持的压缩格式
支持多个屏幕
除非你的APK文件超过Google Play50MB大小的限制，支持多个屏幕应该始终做一个单一的APK。由于Android 1.6，Android系统的管理大部分各种屏幕尺寸和密度上所需的工作,以支持你的应用在不同设备下运行。
为了进一步优化您的应用程序，在不同屏幕尺寸和密度上运行，你应该提供alternative resources ，在不同的分辨率和不同屏幕尺寸的不同布局设计，如位图的drawable。
既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上Go语言开发知识点，真正体系化！
由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新
.(img-R5kymYKl-1715666193116)]
[外链图片转存中…(img-5gyHI0AM-1715666193117)]
[外链图片转存中…(img-3uRX2E9Y-1715666193117)]
既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上Go语言开发知识点，真正体系化！
由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新
718
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
