Android碎片化是开发人员将应用程序推向市场的最大困难。 Android远不是一个统一的平台，它拥有与iOS一样的一些设备。
一些数字上的碎片
为了了解 Android 的分裂程度，我们可以看一个真实的用例。有几家公司发布了广泛使用的应用程序，然后收集使用数据。其中之一是 OpenSignal，它最近发表了最新研究。
数字是毁灭性的：
- 今年共有18.796种不同的Android设备，去年为11.868种（增长58％）。
- 三星是领先的领先制造商，拥有43％的设备。 其余的由80多个不同的制造商分发。
- 有6种不同版本的操作系统处于活动状态，用户数量众多，可以忽略。
- 还有很多不同的分辨率和屏幕尺寸。 当然，高度和宽度之比也不同。
对于这些数据，我们必须添加不同的硬件元素，例如一组传感器可能会因设备而异，或者需要使OpenGL游戏开发人员必须涵盖所有传感器的不同图形处理器。
简而言之，一场噩梦，就是如果我们不能适当地控制它，那会使我们付出的代价超过不满。 在Android上找到项目的情况并不少见，在该项目中，完成第一个版本后，与第一个版本本身相比，最终花费更多的时间来移植不同的模型。 这可能非常令人沮丧。
面临碎片化
尽管这是一项复杂的任务，但是如果我们遵循一定的开发准则，那么我们可以在合理的时间内取得良好的结果。 为此，我们将从几个初步考虑开始。
从一开始就处理碎片
首先为特定的移动设备创建特定的版本，然后再进行移植是一个常见的错误。 通常只看一下我们现有的设备是很舒服的，但是如果我们要在广阔的市场上发布我们的应用程序，那么最后的分散将迫使我们对项目进行昂贵的更改。 我们将花费更长的时间并犯更多的错误。 例如，如果我们不将视图设计为灵活的以适应各种屏幕尺寸，则稍后必须重做。 与发生的事情类似 资源位置.
从这个意义上讲，在开始之前我们可以问自己一系列问题，这将有助于我们制定路线图。
- 我要支持什么版本的操作系统？ 仅适用于最新的手机，还是我希望我的应用程序适用于较旧的型号？
- 我只想支持手机，平板电脑，还是两者都支持？
- 我想在哪个国家/地区发布我的申请？ 我要支持哪些语言？
关于第一个问题，我们可以问自己要在应用程序中包含哪些功能。 如果我们支持旧版本，则必须在牺牲新版本Android的功能或发布应用程序的不同版本之间进行选择。 我的个人建议是第一选择，除非您有足够的资源和开发人员来使用同一产品的两个不同版本。
在第二篇中，我们将清楚我们将如何发展我们的观点，而又不会忽视 我们图形资源的不同版本。 最后，除了文本的位置外，我们还必须牢记，根据发布应用程序的国家/地区，会有更旧或更现代的手机。
假设并非所有手机都可以覆盖
如此分散，总会有一些“稀有”案例，我们将不值得讨论。 总是会有一个模型在记录或再现声音或执行某种视频格式...或任何其他可能性时出现问题。 Android是免费系统，这一事实允许每个制造商在一定程度上实现自己喜欢的操作系统，这将不可避免地导致我们拥有难以涵盖的模型。
在这里，良好的实用主义至关重要。 覆盖少数用户使用的少数设备是不可行的，与覆盖普通设备相比，这将花费我们更多的时间。 最好的策略是确保当时市场上存在最多的设备，这反过来又将帮助我们使其他设备也能正常工作。 然后，我们将继续完善我们的应用程序，直到获得相当好的覆盖率-完善的应用程序很容易超过80％的覆盖率。
有了这些，我们就可以开始工作了。 尽管我们已经引用了一些有用的技术，但现在我们将对其进行详细介绍。
- 我们的观点将永远是灵活的。 我们绝不会将绝对值用于像素大小，更不用说AbsoluteLayout了。 我们所有的测量将以相关像素或dp为单位，并且在可能的情况下，我们将使用相对比例和测量。
- 我们将在不同的屏幕尺寸下测试视图。 为了不必全部尝试，一种好的方法是尝试一种最大的设备，另一种最小的设备，以及两者之间的设备。
- 我们将确保为所有屏幕密度提供所有可用的图形资源，这将使我们更轻松地获得100％的灵活视图。
- 我们将确保有单独的代码文本来支持国际化。
- 我们将选择要使用的最低版本的操作系统，并仅在可能的情况下使用它进行开发。 如果没有，我们将为不同的操作系统创建不同的版本，尽管数量越少越好。 有时，我们会找到实现最新版本功能而无需直接使用它们的第三方库，这是一个值得考虑的有趣选择。
- 我们将不可避免地进行测试。 在市场上，有专门致力于测试的公司，并且以相当合理的价格，我们可以获得针对各种设备的自动测试。
- 最后，我们不会排除用户错误报告，这将不可避免地到达我们。 有了他们，我们一定会发现我们错过的细节。
