为了获得更好的性能，我应该使用九补丁还是可绘制的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）次，但仍然没有得到到每个节点的最短路径？ 假设算法正确，我们真的能做得更好吗？我
-
我读过很多地方说HTTP补丁是非幂等的。有人能解释一下为什么它是非幂等的吗？因为根据定义,幂等方法可以改变资源状态,也可以不改变资源状态,但是重复的请求在第一个请求之后应该不会有进一步的副作用。重复的补丁请求如何改变资源状态？
-
问题内容： 我正在使用c / c 为osx和linux开发命令行界面可执行文件。该项目将链接到opencv。我应该使用libc 还是libstdc ++？ 问题答案： 我会为每个操作系统使用本机库，即GNU / Linux上的libstdc 和Mac OS X上的libc 。 libc 在GNU / Linux上不是100％完整的，而libstdc 更完整时使用libc并没有真正的优势。另外，如果