为了获得更好的性能，我应该使用九补丁还是可绘制的xml资源？
为某些视图设置背景的最佳方法是什么？例如，后轮的 2 个变体：
-
< li >带有渐变、圆角和边框的背景 < li >只有一种颜色和圆角的背景
那么，九个补丁还是可绘制的xml资源，哪种变体更好呢？
共有1个答案
我的猜测是，< code>NinePatch在大多数情况下会稍微快一些。这是我的发现。
GRadientDrawable（用于xml中的rects）使用此代码调用Canvas，后者反过来使用本机调用，导致SkCanvas、SkDraw并最终SkScan和SkBlitter。
另一方面，在对九帕奇的本机调用之前，九帕奇的 draw（） 几乎没有 Java 代码.cpp它很快将九帕奇调用.cpp - NinePatch_draw（） ---这就是神奇之处。那里的代码遍历标记的区域，在经过多次后续调用后，使用与 SkDraw 中大致相同的逻辑（只有 drawRect（） 而不是 drawPath（））绘制内容，但最终是相同的 SkScan 和 SkBlitter 执行工作。
所有这些代码都很难让我立即回过头来，但吸引我眼球的是，GradientDrawable对整个本机堆栈进行了两次调用，如果它同时具有背景和笔划（请看这里），而在任何情况下，NinePatch只调用一次。
所以如果不实际测量这两种方法的时间，我感觉到在大多数情况下，NinePatch赢得了比赛：如果我们[非常]粗略地假设drawRect（）anddrawPath（）的本机调用堆栈使用了几乎相同的逻辑和[另一个可怕的简化]参数集，这些参数集在那里传递，并由ninenpatch创建GradientDrawable不会对方法的复杂性产生太大影响，那么NinePatch，在填充和轮廓方面的速度大约是gradintDrawable的2倍。好吧，只要你使用一个常规的9段9补丁（即，不要用太多的标记撕碎你的9补丁，这会让你的迭代过于费劲）。
任何偶然发现这一点并对此有更多了解(和/或更好地估计本机代码的复杂性)的人，如果我错了，请纠正我。
是的，我知道这不是一个直截了当的回答
-
我是否应该将我的终点设计为 或
-
问题内容： 我正在尝试在Android的Canvas对象上绘制九个补丁。看起来很奇怪的是，尽管我使用draw9patch工具生成了我的九个补丁，但NinePatch的构造函数需要一个额外的字节数组“ chunk”来构造这九个补丁。 为什么这样不简单？什么是“块”？如果您自己完成此操作，您是如何进行的？ 任何帮助表示赞赏。 问题答案： 您可以通过以下方式轻松实现：
-
我正在尝试读取包含以下字段和值的csv文件： 引用字段是唯一的，选择字段可能为空。在此场景中，对于我的实体定义： 1.我应该为字段使用吗，因为它在csv文件中可能为空（空字符串）？ 2.我应该使字段PK还是即使它是唯一的，我认为最好使用id字段并为字段添加。对吗？ 3、对于开始日期字段，我认为应该使用本地日期，而不是日期，因为它已被弃用。这是真的吗？
-
我了解到Bellman-Ford算法的运行时间为O（| E |*| V |），其中E是边的数量，V是顶点的数量。假设图没有任何负加权圈。 我的第一个问题是，我们如何证明在（| V |-1）迭代中（每次迭代检查E中的每条边），它更新到每个可能节点的最短路径，给定一个特定的起始节点？有没有可能我们已经迭代了（|V |-1）次，但仍然没有得到到每个节点的最短路径？ 假设算法正确，我们真的能做得更好吗？我
-
我是否正确理解了这一点： 所有android设备都属于以下4个密度桶之一：ldpi、mdpi、hdpi、xhdpi。 因此，如果为这些密度中的每一个提供了可绘制资源（这些文件夹中的每一个都存在可绘制资源或具有相同名称的可绘制资源），那么就没有必要在/res/drawable或/res/drawable nodpi中提供具有相同名称的可绘制资源。 我的理解正确吗？ 那么，为什么在/res/drawa
-
我读过很多地方说HTTP补丁是非幂等的。有人能解释一下为什么它是非幂等的吗？因为根据定义,幂等方法可以改变资源状态,也可以不改变资源状态,但是重复的请求在第一个请求之后应该不会有进一步的副作用。重复的补丁请求如何改变资源状态？