企业官网建设流程全解析

图像视图（Image views）大概是所有 UI 体系里最容易被低估的控件。大多数时候我们只是把它当作一个展示位图图片的容器：UIImageView.image = xxx、ImageView.setImageResource(xxx)，然后就没有然后了。但我前阵子做一个带图形编辑功能的演示模块时，偏偏被困在"怎么让图像视图里显示一个三角形"这种听起来简单到离谱的问题上。用设计稿导出的三角形 PNG 当资源？放大就发虚；改成填充色要重新出图；想要旋转动画和状态高亮就更麻烦。最后我把绘制逻辑从"找图"改成了"画图"，让图像视图直接消费几何路径而不是像素图片，整个方案才彻底顺畅。这篇文章算是一次完整复盘，把在图像视图里"画出三角形"的几种主流做法、底层逻辑、还有那些不试一次很难发现的坑都摊开讲清楚。

1. 为什么"画"三角形比"放一张三角形图"更靠谱

先说个反直觉的结论：如果只是想让屏幕上出现一个三角形，最差的办法恰恰是设计师给一张三角形的透明 PNG。在 1x、2x、3x 屏幕适配还没普及的年代，贴图确实是唯一选择，但现在再这么干，你会被下面几个问题反复折磨。

第一是清晰度。一张 64x64 的三角形 PNG 放在大屏上被拉伸到 256x256，边缘的锯齿和模糊会非常明显。就算设计师给到 1024 甚至更大的原图，不同屏幕的 DP（density-independent pixel）换算还是会在部分机型上出现缩放比例不是整数倍的情况，一旦图像视图在运行时因为布局约束改变而调整尺寸，位图就要重新插值，效果看运气。第二是动态交互。三角形如果要支持填充色随状态变化（比如选中变蓝、禁用变灰），通过tint或者预置多套图片虽然能解决一部分，但遇到渐变、描边粗细变化、圆角控制这类需求，贴图方案会瞬间陷入无穷无尽的资源维护。第三是数据驱动。在 MVP 或 MVVM 架构里，三角形的颜色、旋转角度、尺寸往往来自服务端或本地配置，如果这些参数一变就要重新下发图片资源，既浪费流量又没法实时刷新。

所以更合理的做法是：让图像视图只负责"显示"，三角形的产生走绘制链路。绘制链路可以在 CPU 上生成一张三角形位图然后塞给图像视图，也可以让图像视图直接加载矢量路径，甚至可以在视图的 Layer 层级上挂一条路径。这三种方式各有取舍，但共同的核心是同一个：三角形不再是一张静态资源，而是一段可计算、可演变的几何描述，Presentation 层只需要把几何状态喂给视图即可。

2. 三条主流绘制路线：位图、矢量资源与图层路径

我想重点拆三种被验证过的实现方案。它们在 iOS（UIImageView）和 Android（ImageView）上都有对应版本，但要注意：iOS 的 UIKit 和 Android 的 View 体系在坐标系、像素密度处理上有差异，直接翻译代码容易踩坑，我会把两端的关键点都标出来。

2.1 路线一：在位图画布上描点成图

这是最符合直觉的做法：用 Canvas / GraphicsContext 绘制一个三角形，得到一张 Bitmap / UIImage，然后赋值给图像视图。iOS 用UIGraphicsImageRenderer要比老式的UIGraphicsBeginImageContext更推荐，因为它自动处理 device scale 和 color space，并且 API 更安全。

func triangleImage(size: CGSize, color: UIColor) -> UIImage { let renderer = UIGraphicsImageRenderer(size: size) return renderer.image { context in let path = UIBezierPath() path.move(to: CGPoint(x: size.width / 2.0, y: 0)) path.addLine(to: CGPoint(x: size.width, y: size.height)) path.addLine(to: CGPoint(x: 0, y: size.height)) path.close() color.setFill() path.fill() } } // 使用 imageView.image = triangleImage(size: CGSize(width: 64, height: 64), color: .systemBlue)

Android 端对应法是创建Bitmap，用Canvas和Path绘制，然后imageView.setImageBitmap(bitmap)：

fun createTriangleBitmap(width: Int, height: Int, @ColorInt color: Int): Bitmap { val bitmap = Bitmap.createBitmap(width, height, Bitmap.Config.ARGB_8888) val canvas = Canvas(bitmap) val paint = Paint(Paint.ANTI_ALIAS_FLAG).apply { this.color = color style = Paint.Style.FILL } val path = Path().apply { moveTo(width / 2f, 0f) lineTo(width.toFloat(), height.toFloat()) lineTo(0f, height.toFloat()) close() } canvas.drawPath(path, paint) return bitmap }

这个方案的好处是通用性极强：生成的图可以用在任何UIImageView/ImageView上，可以走UIImage(named:)之外的任意图片链路，比如保存到相册、上传服务器、传给跨平台层。代价也非常明显：它是像素副本，图一旦生成，旋转变化就需要重新生成，缩放会失真，并且每个尺寸/颜色组合都会占用一份内存。

优化点时可以从位图复用出发。不要每次draw都新建 Bitmap，最好在内存里维护一个以(width, height, colorHash)为 key 的轻量缓存。在 Android 上尤其要注意，Bitmap.createBitmap的ARGB_8888格式下每像素占 4 字节，一张 256x256 的三角形图就是 256KB，频繁创建会引发 GC 卡顿。

2.2 路线二：矢量资源直接让图像视图加载

矢量方案更符合"涨缩自如"的预期。Android 里最常见的是 VectorDrawable，一个 XML 文件就能描述三角形的pathData：

<vector xmlns:android="http://schemas.android.com/apk/res/android" android:width="64dp" android:height="64dp" android:viewportWidth="64" android:viewportHeight="64"> <path android:pathData="M32 0 L64 64 L0 64 Z" android:fillColor="#2563EB" android:strokeColor="#00000000" android:strokeWidth="1"/> </vector>

然后代码里一行imageView.setImageResource(R.drawable.ic_triangle)就能生效。VectorDrawable 的渲染由 Android 的VectorDrawable类在 GPU/CPU 协作下完成，是真正的矢量描述，不会因为 ImageView 的scaleType调整而模糊。

iOS 里没有直接等价的"把 XML 路径当图片设进去"的控件，但有两个接近的替代。其一是使用系统自带的 SF Symbols，比如三角形的 symbol 是"triangle.fill"：

let config = UIImage.SymbolConfiguration(pointSize: 20, weight: .regular, scale: .medium) let image = UIImage(systemName: "triangle.fill", withConfiguration: config) imageView.image = image imageView.tintColor = .systemBlue

SF Symbol 是基于字体和贝塞尔曲线的矢量符号，也支持动态颜色和 size，但形状是固定的，自定义三角形顶点需要另想办法。其二是借助 PDF 矢量资源，Xcode 的图片资源目录支持 PDF 单矢量图谱写入，运行时 UIImage 会自动按 point size 缩放，这也是很多团队处理图标的方式。但 PDF 资源改动起来不如图标字体灵活，只适合形状稳定的三角形。

矢量方案的坑在于：Android 的 VectorDrawable 在 API 24 以前需要兼容处理，支持库有开销；iOS 的 PDF 静态矢量图如果动画需求复杂（比如顶点位置变化），反而失去优势。总体看，矢量资源适合"三角形作为一个不变的品牌元素或图标"，不适合"用户能拖拽顶点"的编辑器场景。

2.3 路线三：在图像视图的图层上直接绘制路径

第三条路线可能是最"工程化"的一条。它不生成任何新图片，而是直接在图像视图已有的 layer 上挂一条路径。iOS 里最常见的是CAShapeLayer配合UIBezierPath，可以做到无损缩放、流畅动画：

let shapeLayer = CAShapeLayer() let path = UIBezierPath() path.move(to: CGPoint(x: 32, y: 0)) path.addLine(to: CGPoint(x: 64, y: 64)) path.addLine(to: CGPoint(x: 0, y: 64)) path.close() shapeLayer.path = path.cgPath shapeLayer.fillColor = UIColor.systemBlue.cgColor imageView.layer.addSublayer(shapeLayer) // 或者把它作为 mask 裁剪 imageView 的内容 imageView.layer.mask = shapeLayer

当shapeLayer作为imageView.layer.mask时，图像视图里原本的正方形图片会被裁剪成三角形——这个做法特别适合"图片头像三角形化"或者"视频画面三角形切割"这种需求。如果只是想显示三角形而不关心图像内容，直接把shapeLayer挂在 layer 层级上作为子图层即可。

Android 没有完全等价的 mask 方案，但思路可以用自定义Drawable实现。一个简单的做法是继承Drawable并重写draw，用Path绘制三角形：

class TriangleDrawable(private val color: Int) : Drawable() { private val paint = Paint(Paint.ANTI_ALIAS_FLAG).apply { this.color = color style = Paint.Style.FILL } override fun draw(canvas: Canvas) { val path = Path() val w = bounds.width().toFloat() val h = bounds.height().toFloat() path.moveTo(w / 2f, 0f) path.lineTo(w, h) path.lineTo(0f, h) path.close() canvas.drawPath(path, paint) } override fun setAlpha(alpha: Int) { paint.alpha = alpha invalidateSelf() } override fun setColorFilter(colorFilter: ColorFilter?) { paint.colorFilter = colorFilter invalidateSelf() } override fun getOpacity(): Int = PixelFormat.TRANSLUCENT } // 使用 imageView.background = TriangleDrawable(Color.BLUE)

这种方案在三个维度上都更接近"图像视图作为画布"的本质：不占用 image 属性，不影响scaleType对已有图片效果的控制，还能参与到视图动画中。缺点是割断了"ImageView.image"这个最直观的语义，很多人看代码会困惑：这哪里是 image view？所以如果团队里其他人要维护，务必把这段绘制代码封装成专门的TriangleShapeLayer/TriangleDrawable，不要裸写在业务控制器里。

3. 三角形里那些要命的坐标系、像素对齐与抗锯齿细节

画了几年图形界面，我最大的体会是：三角形本身很简单，难的是一堆看不见的边界条件。坐标、密度、缩放和半透明像素，任何一个出问题，三角形都会出现诡异的残边或者模糊。

先说坐标系。iOS 的UIGraphicsImageRenderer默认以 point 为逻辑单位，但底层渲染到像素，UIImage有scale属性。Android 的Bitmap内部以物理像素为单位，但Canvas绘制时坐标也是物理像素。所以如果你写size.width / 2时，脑海里必须清楚这个数值对应的是逻辑点还是物理像素。在 iOS 上如果不做特殊处理，UIGraphicsImageRenderer(size:)生成的是 scale 等于当前屏幕 scale 的图，也就是说 64 点的 size 会生成 128 像素的实际位图。这本身是合理行为，但如果你把这个 UIImage 再赋值给一个contentMode = .scaleToFill的 image view，view 的 frame 又和图像 size 不一致，那系统就会做插值重采样，结果会产生轻微模糊。

像素对齐比想象中更常被忽略。一个圆三角形的顶点如果落在小数坐标上，比如CGPoint(x: 32.4, y: 0)，Core Graphics 和 Android Canvas 都会用灰色过渡像素去填补亚像素位置，视觉上就是边缘不够锐利。对只有三条直边的三角形尤其敏感，因为人的视觉系统对斜线边缘的锯齿非常敏感。建议在生成路径时就把坐标取整，或者统一内缩 0.5 像素到栅格中心。具体到三角形，很多图形库（包括 iOS 的 PaintCode）会建议做一个 pixel alignment：x = round(x) + 0.5或者在0.5pixel 处画线。如果你用CAShapeLayer，可以设置shapeLayer.contentsScale = UIScreen.main.scale，帮助图层在物理屏上对齐。

抗锯齿则是一把双刃剑。开了抗锯齿，三角形的斜边会平滑很多，但如果你需要三角形边缘恰好和另一个矩形边缘贴合，抗锯齿产生的半透明像素会让拼接处出现一条浅色的"水线"。我的做法是：当三角形作为独立可见图形时，一定开抗锯齿；当三角形只是某个大图形的蒙版或遮罩时，则建议关掉抗锯齿，让边缘完全硬切。Android 的Paint默认不抗锯齿，需要显式设置ANTI_ALIAS_FLAG；Path本身没有抗锯齿属性，抗锯齿能力来自Paint。iOS 的UIBezierPath默认就开了抗锯齿，要关闭可以给上下文设置context.setShouldAntialias(false)。

另一个容易被忽略的是留白边界。如果三角形的顶点 x=0、y=0 紧贴图像区域左上角，那么在生成位图时，三角刚好贴边的位置可能会被裁剪掉 1 像素，视觉上像是一个斜角被切掉。给路径加一个 padding 是稳妥的做法：把三角形整体放到内容区域的中心，四周留出至少1 * scale的透明边距。比如宽高 64，顶点坐标(32, 4)、右下(60, 60)、左下(4, 60)，这样既不贴边又能容纳描边线宽。

4. 实际性能与动态效果对比：同一张三角形，代价差很多

如果你以为三种画法之间只是代码风格差异，那就错了。它们的性能特征和适用边界完全不同。我专门用同一块 120x120pt 的区域做了简单实测，把结果整理成表格：

这表格是我在模拟器 + 真机上都验证过的。位图方案如果在viewDidLoad一次性生成还好，但如果三角形要跟随状态变颜色，每变一次颜色生成一张新的位图，那么快速切换状态的场景下（比如 60fps 的连续交互），内存抖动和 CPU 开销都会立刻暴露，iPhone 上会更快感受到掉帧。

矢量资源的动态颜色是它最亮眼的优势。Android 的 VectorDrawable 可以直接通过imageView.setColorFilter或者tint修改颜色，iOS 的 SF Symbol 也可以通过withTintColor处理，成本极低。但如果你想要三角形顶点从等腰三角形变形为直角三角形，矢量资源的pathData虽然理论上可以动态改，但 iOS 的 SF Symbol 根本不开放这个能力，VectorDrawable 动态改 pathData 需要自定义AnimatedVectorDrawable或者写大量兼容代码，通常得不偿失。

最后胜出的往往是图层路径方案。CAShapeLayer的 path 可以随时替换，颜色用fillColor直接赋值，bounds变化时重新计算 path 也就几行代码。Android 端自定义 Drawable 后同样可以在onBoundsChange里重算，配合invalidateSelf()实现重绘。如果你未来想要给三角形加圆角、描边虚线、甚至贝塞尔曲线变形，图层路径方案是最有扩展性的。

5. 别让"画三角形"变成内存事故：缓存与容量设计

图形绘制的隐性成本往往在内存。尤其是位图方案，很多人随手写一个createTriangleBitmap(width, height, color)，然后每次视图出现都调一次，一个三角形还好，如果列表里有 20 个不同颜色的三角形，内存就直接上去了。我们实际项目中就出现过一次因为频繁创建 Bitmap 导致的OutOfMemoryError，定位后发现在滚动列表里每个 item 都会创建一张三角形图作为占位背景，而且是全分辨率。

解决办法分两层。第一层，能走矢量/图层方案就走矢量/图层方案，它们的显示体积和内存占用几乎跟像素无关。第二层，非要位图不可时，一定要做缓存。一个可复用的思路是：以(width, height, 颜色值)作为 key，维护一个 NSCache 或者 LruCache。颜色不多时，这个缓存基本不会失效，带来的内存收益非常明显。

Android 上还可以结合inSampleSize控制位图尺寸，但前提是你知道自己需要的物理大小。iOS 上要小心UIGraphicsImageRenderer与UIImageView的尺寸不匹配问题：如果 view 显示大小为 80x80，而你生成一张 800x800 的图，就会白白浪费一个数量级的内存。正确做法是let renderer = UIGraphicsImageRenderer(size: view.bounds.size, format: .init())，让生成尺寸和最终显示尺寸尽量一致。

此外，位图方案的 scale 也是一个内存放大器。Bitmap.Config.ARGB_8888在 2x 屏幕上如果按 point 生成再交给 image view，系统又会放大到实际像素，等于多一次插值。建议在需要生成位图时，直接用物理像素尺寸绘制：size * screenScale，生成后设置imageView.image = bitmap时imageView的 DP 与实际像素匹配，清晰度和内存都最优。

6. Presentation 层怎么设计：三角形数据不该在视图里硬编码

标题里有 Presentation，我认为这不是偶然。真正项目里三角形不会凭空出现，它往往来自业务层的一个配置：比如规则引擎输出一个"顶点 A 到顶点 B 的连线 + 填充色 #2563EB + 旋转 30 度"的描述。如果你直接在 VC 里写死路径坐标，那做出来的图形控件基本没法复用。

我更推荐的做法是定义独立的展示模型（Presentation Model），把"画成什么样"和"怎么画"分离。比如 iOS 端可以建立一个TrianglePresentationModel：

struct TrianglePresentationModel { enum Style { case outline(color: UIColor, width: CGFloat), filled(color: UIColor) } let size: CGSize let style: Style let rotation: CGFloat let cornerRadius: CGFloat }

然后由一个专门的TriangleShapeFactory把这个模型转换为CAShapeLayer、UIImage或者一行UIBezierPath。这样视图层只依赖抽象模型，不关心三角形具体是怎么渲染的。想从图层方案切到位图方案，只需要改工厂内部实现，业务代码一行不动。Android 端同理，ViewModel 暴露的应该是TrianglePresentationModel，而不是ImageView、Bitmap这些具体类型。UI 层拿到 model 后，用ShapeDrawable还是Bitmap完全由自己的适配层决定。

如果你在做一个可复用的图像视图组件，我建议直接把"展示数据"和"图像视图"绑定在一个TriangleImageView里，对外暴露var model: TrianglePresentationModel?。内部收到 model 后自动走一遍坐标计算、颜色应用、路径重建、动画更新。调用方永远不需要知道CGPoint和Path。

这个设计的最大价值是让图像视图彻底成为"容器"，三角形只是容器里的一个渲染对象。后续哪怕要加矩形、多边形、星形，都能复用同一套 Presentation 模型和工厂逻辑，只需要新增一个PolygonPresentationModel并在工厂里加分支，风险被控制在很小的范围内。

7. 关于绘制时机的再提醒：别在 layout 之前急着拿尺寸

写到这里必须补一个很多人掉的坑：不管是生成位图还是计算CAShapeLayer的 path，都需要图像视图的最终尺寸。如果你在viewDidLoad或onCreate里直接拿imageView.frame.size/imageView.bounds，大概率拿到的是 storyboard 或者布局里给出的初始宽高，还没算上约束。等自动布局完成以后，实际 frame 变了，你按旧尺寸生成的三角形就会偏离中心或者被拉伸。

iOS 上正确时机是viewDidLayoutSubviews或者重写layoutSubviews，在那里读取最终bounds再更新shapeLayer.path。Android 相对简单一些，可以在onSizeChanged或post { }里取 View 的实际宽高。如果对实时性要求高，建议在组件内监听布局变化，一旦 bounds 变化就重新计算，这样也能自然适配旋转屏。

我习惯把"几何计算"和"渲染提交"拆成两个方法：calculateTrianglePath(in bounds: CGRect) -> UIBezierPath只算路径，applyShapeLayer(path: UIBezierPath)只把路径挂到 layer 上。这样子在旋转屏幕或者不同设备上测试时，可以很明显排查出是算错还是显示错。

三角形从几何上讲是最简单的多边形，但把它塞进图像视图这个容器里，牵扯到的坐标系、矢量/位图性能差异、缓存与布局时机，全都是图形开发的基本功。如果你正打算在项目里做类似的自定义形状展示，可以从图层路径方案起步，把模型层和视图层分开，再逐步引入缓存和动画。这应该是一条最稳妥、也最值得长期依赖的路径。