企业官网建设流程全解析

1. 先说结论:Unity里做二维码,难点根本不在"生成"

接到"在项目里加个二维码功能"这个需求时,我第一反应是"这不就是调个库的事吗"。真正动手之后才发现,生成二维码确实简单,扫描二维码才是埋坑最多的地方。如果你只是想在界面上显示一个码,那Zxing或者轻量级的生成库二选一,十分钟就能跑通。但如果你是像我一样,要做的是"App扫描屏幕上/纸质上的二维码,然后拿到里面的数据去做业务",那后面有一连串的坑等着你:相机授权、画面方向、识别率、CPU开销、多平台行为差异……每一个都能让你调上半天。

这篇文章不打算写成API文档式的流水账,而是把我实际做Unity二维码生成与扫描的完整过程、选型理由、踩坑记录、以及最终稳定运行的方案整理出来。适合这几类人看:刚接需求不知道从哪下手的Unity新手、已经用某个库跑通了Demo但识别率不稳定的中级开发者、以及想在性能和多平台适配上传少走弯路的人。你不需要提前懂二维码的编码原理,我会从"够用"的深度讲起。

2. 选库的底层逻辑:为什么最终选了功能合并的方案

2.1 先聊聊二维码的本质:不是图片,是一段二进制数据的可视化

很多人在生成二维码的时候只关心"怎么把字符串变成一张图",但二维码本质上是把字符串(或者任意字节流)进行编码,然后映射到一个矩阵里。每个黑色方块代表二进制1,白色方块代表0,配合三个角上的定位图案(就是那个"回"字),让扫描端能快速找到并读取。

理解这一点很重要,因为它直接影响你后面选库和调参。比如:

• 二维码能容纳的数据量是有限的。纯数字最多能塞几千个字符,但一旦混入中文、特殊符号,容量会急剧下降。别指望把一个几万字的日志塞进一个二维码里,那不是二维码的活。
• 纠错等级(Error Correction Level)越高,二维码被遮挡、破损后越容易识别,但能装的数据越少。做商业落地项目时,我一般默认用M级或Q级,后面会细说。
• 版本(Version)越高,矩阵越密,识别对清晰度要求越高。同样内容,版本越高的码越难扫,所以不要无脑把数据密度拉满。

2.2 生成端:轻量级方案的实际体验

生成二维码的库,我用过两种方案,这里直接说结论。

第一种是完全独立的生成库,比如QrCodeGenerator这类。它的特点是纯粹负责"把字符串变成纹理",没有扫描功能,代码简单,依赖少,在Unity里用得很顺。核心逻辑大概长这样:

// 以常见的生成库为例,伪代码风格 var qrCode = QrCodeGenerator.Generate(text, size: 512, errorCorrection: ErrorCorrectionLevel.M); Texture2D texture = qrCode.ToTexture2D();

这套方案的好处是轻、快、可控。生成一张512x512的码,毫秒级完成,完全不用担心性能。如果你只是需要把一段文本变成图,生成端选这种方案就够了。

但问题是,项目往往不只是要生成,还要扫描。如果你生成用一个库、扫描用另一个库,来回切换API风格、数据结构,体验很割裂。尤其扫描库通常更复杂,配置更多,你在生成端省的那点时间,会在扫描端加倍还回去。

2.3 扫描端:为什么生成和扫描合并成一个库更省心

我最终用的是Zxing的Unity移植版本,原因很简单:

• 它同时覆盖生成和扫描,数据结构统一,API风格一致,写完生成端再写扫描端,思维不用切换。
• 它对二维码解码的兼容性是我试过的几个方案里最好的,尤其是表现不佳的场景(反光、模糊、倾斜、小尺寸)下,它给的结果更可靠。
• 它的BarcodeReader接口设计得比较灵活,可以直接喂像素数据,这让我能自己控制采样分辨率,这是性能优化的关键。

当然,合并方案也不是没有代价。Zxing的库体量要比纯生成库大不少,并且初始化解码器时会有一点内存开销。但对一个Unity项目来说,这个代价完全可以接受。我的建议是:如果需求只是"能生成就行",用轻量生成库没问题;但只要有一天你要做扫描,直接上Zxing这类合并方案,省得以后重构。

3. 生成二维码:看似简单,其实藏着三个能让你返工的细节

3.1 基础流程:从字符串到屏幕上的码

生成端的完整流程,其实就四步:字符串预处理 → 编码成矩阵 → 转为纹理 → 显示。下面是Zxing生成部分的核心代码,我按实际项目里能直接用的标准写:

using UnityEngine; using ZXing; using ZXing.QrCode; public static class QRCodeGenerator { public static Texture2D Generate(string text, int pixelSize = 512, int margin = 2) { var writer = new BarcodeWriter { Format = BarcodeFormat.QR_CODE, Options = new QrCodeEncodingOptions { Width = pixelSize, Height = pixelSize, Margin = margin, ErrorCorrection = ZXing.QrCode.Internal.ErrorCorrectionLevel.M } }; var color32 = writer.Write(text); var texture = new Texture2D(pixelSize, pixelSize, TextureFormat.RGBA32, false); texture.SetPixels32(color32); texture.Apply(); return texture; } }

这段代码里,最容易被忽略的是Margin参数。它对应二维码的"静区"(quiet zone),也就是码四周必须留白的区域。扫描端识别时,需要靠这片空白来确定码的边界。Margin默认是4,但对于在屏幕上显示的码,2通常也够用;如果是打印出来贴在反光材质上,建议保留4甚至更大。

3.2 坑一:中文字符和特殊符号的编码逻辑

这是新手最容易踩的坑。你把"你好,世界"丢给编码器,得到的码可能扫不出来,或者扫出来是一堆乱码。原因不是库的问题,而是字符编码没对齐。

Zxing内部默认会用ISO-8859-1之类的编码去处理字符串,遇到中文字符时,它没法直接表示,结果就会出现乱码或生成失败。解决方法是明确指定UTF-8编码,先手动把字符串转成字节数组,再交给编码器:

var contentBytes = Encoding.UTF8.GetBytes(text); var hint = new Dictionary<EncodeHintType, object> { { EncodeHintType.CHARACTER_SET, "UTF-8" } };

如果你要生成的内容里混合了中文、URL参数、特殊符号(比如&,?,#),建议统一走UTF-8字节数组这一步,不要直接传原始字符串。我在这上面返工过一次,后来养成了习惯:凡是生成端处理文本,一律先显式声明编码。

3.3 坑二:Texture2D的纹理格式和过滤模式

生成的Texture2D,如果直接拖到UI的Image上显示,默认的过滤模式是双线性(Bilinear)。这会导致黑白交界的边缘出现灰色过渡像素,呈现一种"毛边"效果。毛边本身不影响扫码,因为解码是看二值化之后的明暗分布,但这种灰边会让小尺寸二维码在屏幕上显示得更糊,从而降低识别距离。

我的习惯是强制把过滤模式设为Point(点采样),并关闭mipmap:

texture.filterMode = FilterMode.Point; texture.wrapMode = TextureWrapMode.Clamp;

这样显示出来的码边缘干净利落,尤其是缩放到很小尺寸时,识别率会明显提升。还有一个相关坑:TextureFormat不要用带压缩的格式(比如ASTC、ETC),压缩会引入色块,严重时会在解码端产生误判。用RGBA32最稳。

3.4 坑三:没想清楚的"生成内容"

这个坑属于需求层面的。需求方说"生成一个二维码",但从不主动说"里面放什么数据"。你花两小时把图生成得漂漂亮亮,交付时对方才说"我要的不是一个URL,而是把设备编号、订单号、时间戳拼在一起的字符串"。

所以在写生成端之前,一定要先确认数据协议。比如做设备绑定,二维码内容可能是DEVICE_ID=xxx&TYPE=xxx这样的结构化字符串;做支付场景,可能是对方服务器签过名的URL。字符串的语义不同,决定了你要不要做URL编码、要不要控制长度以匹配二维码容量。这个看似无关紧要的决策,往往决定整个功能是否能用。

4. 扫描二维码:从相机画面到识别结果,完整链路拆解

4.1 整体架构:相机、采样、解码、回调各管各的

扫描端比生成端复杂一个量级。逻辑上可以拆成四层:

1. 相机层:负责拿到摄像头画面,以WebCamTexture的形式供Unity使用。
2. 采样层:每一帧(或每N帧)从画面里取出一小块像素数据。
3. 解码层:把像素数据交给Zxing的BarcodeReader,尝试解析二维码。
4. 业务层:拿到解析结果,做回调、UI响应、业务跳转。

每层独立才方便排查问题。比如识别率低,你先看是采样层图片太糊,还是解码层设置不对;相机黑屏,先看授权层,不要一股脑去调解码参数。

4.2 相机初始化的细节:不只是"打开摄像头"而已

Unity里开摄像头很简单,WebCamTexture一行代码就能启动。但实际项目里,你要面对三个问题:

第一个问题是摄像头权限。在Android和iOS上,直接调用摄像头会弹授权框。不要等到用户点拒绝之后你才发现没有处理回调,那体验太糟了。建议在初始化前先主动请求权限,比如用原生层的权限API,或者Unity的NativeCamera封装。拿到授权结果后再初始化和启动摄像头。

第二个问题是摄像头朝向。手机竖屏拿着,摄像头画面默认是横向的,直接贴到UI上会转90度。Unity的WebCamTexture在部分平台上可以通过videoRotationAngle属性拿到画面旋转角度,但你依然要自己在UI层面处理旋转和对齐。前置摄像头还会镜像,如果做的是"扫描自己屏幕上的码"这种AR类应用,镜像处理不对会出现扫码方向反了的诡异现象。

第三个问题是选择哪颗摄像头。后置摄像头识别纸质码更清晰,前置摄像头适合"扫屏幕上显示的码"这种面对面场景。Unity里枚举WebCamTexture.devices,按isFrontFacing区分前后摄,按name或支持的分辨率来指定具体设备。

初始化代码的参考骨架:

WebCamDevice targetDevice = default; foreach (var device in WebCamTexture.devices) { if (!device.isFrontFacing) // 优先后置 { targetDevice = device; break; } } var webCamTexture = new WebCamTexture(targetDevice.name, 1280, 720, 30); webCamTexture.Play();

分辨率选择上,别一上来就选4K。解码并不需要那么高的分辨率,反而会拖慢采样和识别速度。我更偏好720p或1080p,既能保证识别距离,又不会让CPU坐火箭。

4.3 采样策略:每帧GetPixels32是最贵的写法

初学者最常见的写法是:每帧从webCamTexture.GetPixels32()拿全部像素,然后丢给解码器。这个写法能跑,但会让帧率惨不忍睹。

GetPixels32()的消耗和分辨率成正比。一张1920x1080的画面,一次调用就要拷贝六百万个像素的数组。如果每帧都搞一次,还要配合解码,CPU根本扛不住,手机会发热,耗电极快,甚至卡到摄像头画面都在掉帧。

推荐做法是降采样 + 定时采样。具体来说:

• 只在固定的时间间隔(比如500毫秒)触发一次解码,而不是每帧都解。扫码不是打游戏,人不至于在100毫秒内把二维码从画面里移走,500毫秒的轮询频率完全够用。
• 在调用GetPixels32之前,先只截取画面中心区域的数据。二维码通常会被用户主动放到画面中央,你可以直接按比例裁剪WebCamTexture的像素区域,减小拷贝量。
• 更进一步,可以在采样前先缩放画面。方法是用Texture2D的ReadPixels配合RenderTexture做一次二次采样,把画面从720p缩到360p甚至更低。这样做解码照样能识别,但速度会快好几倍。

我最后采用的是: 720p输入 → 按中心区域裁剪 → 把裁剪结果再等比缩到约300x300以内 → 提取RGB像素 → 交给解码器。实测下来,解码一次大概稳定在10-30毫秒之间,每500毫秒轮询一次,完全不影响UI流畅度。

4.4 解码与回调:识别一次成功还是连续多次确认

解码部分的代码相对直观:

var reader = new BarcodeReader { AutoRotate = true, TryHarder = true, Options = new DecodingOptions { TryInverted = true, PossibleFormats = new List<BarcodeFormat> { BarcodeFormat.QR_CODE } } }; var result = reader.Decode(pixels, width, height); if (result != null) { // 拿到 result.Text,触发业务回调 }

这里有两个参数值得说明:

• TryHarder = true会让解码器在初次失败后尝试更耗时的算法路径,比如对图像做插值缩放、增强边缘检测等。代价是耗时更高。只要选用了定时采样,这里开着一般没压力。
• TryInverted = true用于处理"反色二维码"——有些场景(比如黑色背景上印白色二维码)整体明暗反转,默认解码逻辑按黑底白码处理会失败。开启后会自动尝试反色再解一次。

还有一个业务层的坑:不要识别到一次就立刻回调并停止。因为用户可能只是从摄像头前晃过,你识别到了一个值,但这不是他最终想扫的那个码。我在项目里采用"连续N次识别到同一个结果才触发回调"的策略,比如连续3次、每次间隔500毫秒,拿到相同的文本,才认为用户确实对准了。这样能大幅降低误触发率。

4.5 扫码完成后的停止逻辑

扫码成功后要停止相机并释放资源。这个环节虽然简单,但容易漏。特别是WebCamTexture的Stop()不等于释放内存,频繁进出扫码页还会让内存只增不减。我在项目里的处理方式是:扫码页启动时初始化相机,页面销毁或业务完成后,不仅Stop(),还要把webCamTexture置空引用,手动调用Resources.UnloadUnusedAssets()(视情况,不必每次)。另外,从Android返回桌面再回到App时,摄像头状态可能被系统重置,重进扫码页时最好重新Play()。

5. 识别率上不去?按这个顺序逐层排查

5.1 先从最基本的:画面里二维码的显示尺寸

识别率低,九成原因不是代码问题,而是二维码在画面里太小。解码器能不能认出来,取决于二维码在采样图像里占据多少个像素。一个经验值是:二维码在采样图像中的边长最好不要少于120像素。如果采样分辨率本身就低,二维码在画面里又只占一角,那神仙算法来也没用。

排查方式:让用户把手机靠近二维码,或者调整UI的扫码框大小,确保码尽量填满画面中央区域。如果条件允许,在UI层面加一个"扫码框"指示,引导用户把码放进框里,识别率会显著提升。

5.2 光照与反光:纸质二维码的隐形杀手

纸质二维码在实际场景里最大的敌人是反光。打印在铜版纸、覆膜卡片、甚至手机屏幕上的二维码,在被灯光直射时会出现局部高光或镜面反射,导致部分区域过曝,变成一片白,恰好吃掉定位角或纠错区域。

对策分三档:

• 低阶:提示用户调整角度,避开光源。这是最原始的,但很有效。
• 中阶:在解码前对图像做预处理,比如自适应阈值二值化,让明暗不均的画面也能被正确处理。Zxing内部有自己的二值化逻辑,TryHarder也会增强这部分能力,但效果有限。
• 高阶:如果你用的是自己控制的采样管线,可以在采样时尝试多曝光策略。比如连拍两张,一张偏暗一张偏亮,分别解码,提高命中率。这个方案我实际验证过,对反光场景提升明显,但会额外消耗性能,适合高端扫码设备或固定工位场景。

5.3 采样分辨率与图像裁剪的平衡

前面提到我建议把采样图缩小到300x300以内,但这并不是绝对的。如果二维码本身打印得很小、或距离较远,缩小采样会直接把码给缩没了。在识别距离和性能之间需要取一个平衡:

• 用户离码近、码较大:降低采样分辨率,性能优先。
• 用户离码远、码较小:提高采样分辨率,识别优先。

我在项目里用了动态策略:先以低分辨率尝试解码,失败后抬高分辨率再试一次。这样大多数情况下性能好,少数远距离场景也兜得住。

5.4 注意二维码自身的版本与纠错设置

还有一个排查方向是二维码本身。生成时如果用L级纠错(最低等级),码的抗损能力差,稍有反光或污渍就废了。生产环境中用M或Q级是最标准的做法。另外,内容越长二维码版本越高,模块越密集,同样尺寸的码更难识别。如果业务允许,尽量压缩二维码内容长度。

比如设备编号这种固定格式,尽量用短字符串+约定的分隔符,而不是把一长串JSON塞进去。我发现有些同事喜欢把整个配置对象序列化塞进二维码,结果码上全是密密麻麻的小方块,打印出来根本扫不动。

5.5 别忽略摄像头对焦问题

手机摄像头自动对焦在多数情况下没问题,但遇到低光照或近距离场景,对焦会很犹豫,画面会持续"拉风箱"。有些机型可以通过原生接口强制设定对焦距离,但这个处理比较平台化。

折中方案是:在UI上做"点击画面重新对焦"的交互,用户手动点一下扫码框区域,触发一次对焦(通过原生层的Camera APIs)。这个功能实现成本不高,但能解决大量近距离扫码的痛点。我在Android端用原生封装做过,效果立竿见影;iOS端用AVFoundation的focusPointOfInterest也能达到同样效果。

6. 性能优化与内存管理:扫码页不能成为帧率杀手

6.1 每帧解码 vs 定时解码:实测数据对比

我在一个中端Android设备上做过对照组测试。同样是720p的摄像头画面:

• 每帧都GetPixels32+ 每帧解码:帧率从60fps掉到15fps左右,CPU占用飙升,手机明显发热。
• 每帧GetPixels32+ 500ms定时解码:帧率恢复50fps左右,但每帧的像素拷贝仍然在拖累UI,滚动卡顿。
• 500ms才采样一次 + 500ms定时解码:帧率稳定60fps,CPU占用几乎无感。

结论很清楚:解码频率要降,采样频率同样要降。不要想着每帧都拷贝像素然后"只解码一次"——拷贝本身的代价你省不掉。

6.2 避免频繁创建Texture2D和数组

如果你的采样代码每次都new Texture2D、每次都new Color32[],内存会被频繁分配和回收,GC压力巨大,帧率在长时间运行后会周期性卡顿。

正确的做法是:预先分配好一块Color32[]数组和一张Texture2D,每次采样只是SetPixels或直接往预分配数组里写入数据,解码完成后复用它。这样长时间扫码也不会出现明显的GC Spike。我在扫码页内存曲线上的对比是:优化前每几秒就一个GC峰值,优化后全程平直。

6.3 解码线程:该不该开Thread

Zxing的解码本身是CPU密集操作。在Android上,如果你在主线程跑解码,哪怕只花20毫秒,也足够让UI产生掉帧感。更稳的做法是把解码放到后台线程。

Unity里开线程要注意一点:不要在子线程里访问WebCamTexture的像素数据,Unity的纹理接口不是线程安全的。我的做法是:主线程负责采样,把像素数组拷贝到一个独立Buffer,然后扔给后台线程解码。后台线程完全操作Color32[]数组,不碰任何Unity API。解码完成后,通过一个线程安全的队列或ConcurrentQueue把结果传回主线程,在主线程触发业务回调。

这套"主线程采样 + 子线程解码 + 主线程回调"的架构,是扫码功能不拖累游戏主循环的关键。如果你的Unity版本支持Unity.Jobs或AsyncGPUReadback,也可以考虑更现代的方案,但传统Thread法够用且可控。

6.4 UI层的Tips:扫码框的绘制别用太多重叠纹理

扫码框一般会做半透明遮罩、四角边框、扫线动画。遮罩如果是一张半透明全屏图还好,但扫线动画如果用高频率的transform移动,并且每帧重绘,会额外消耗GPU。更稳的做法是:扫线用Shader或UI的简单Image做位移动画,不要叠加多层模糊阴影特效。别让一个扫码页因为UI特效把自己做成"性能杀手"。

7. 多平台适配:Android、iOS、模拟器与WebGL的差异汇总

7.1 Android:权限和生命周期是重灾区

Android上摄像头权限声明和运行时授权缺一不可。如果你用的Unity版本较旧,可能需要手动在AndroidManifest.xml里声明CAMERA权限,然后在代码里用Android的权限API请求运行时授权。新版Unity有内置权限请求接口,直接用就行,但要注意:如果用户拒绝授权,你不能只弹一次就放弃,至少要能引导用户去系统设置里开启。

Android生命周期还有一个坑:从后台切回App时,WebCamTexture可能已经处于错误状态(底层Camera被系统回收),画面会一直黑屏。我在OnApplicationPause里做处理,切回前台时判断摄像头是否仍可用,不可用就重新初始化。

7.2 iOS:隐私描述和相机行为差异

iOS端如果你没有在Info.plist里配置NSCameraUsageDescription,系统会直接闪退而不是弹授权框。这个描述文案最好写清楚用途,比如"用于扫描二维码进行设备绑定",因为审核和用户都会看到它。

iOS的WebCamTexture在部分机型上,渲染旋转角度和画面方向的处理和Android不同。我的建议是:不要试图在代码里写一套"通用旋转逻辑"去覆盖所有平台,而是分别在两端做方向和镜像的适配。逻辑分开写虽然麻烦,但稳定。

7.3 手机模拟器和WebGL:能跑,但别当基准

Unity编辑器里的摄像头模拟,会使用你电脑上的摄像头。因为电脑摄像头通常没有"后置/前置"之分,且画面方向和手机差异很大,编辑器下扫码的表现和真机没有直接可比性。如果要在编辑器里测试,建议选择带高分辨率的主摄像头,并且在识别逻辑上留出更大容错。

WebGL端的摄像头走的是浏览器权限体系,且浏览器要求页面在HTTPS环境下才能调用摄像头。另外WebGL的WebCamTexture性能表现一般,像素采样耗时偏高,定时采样的间隔建议放得更开一些。如果你要发布WebGL版本,务必在真机浏览器上多测几轮,别拿编辑器表现说事。

7.4 屏幕亮度的一个物理细节

扫手机屏幕上显示的二维码时,屏幕亮度太低会导致画面过暗,识别率急剧下降。这不是代码问题,但却是实际落地时最常见的用户投诉来源。如果产品允许,可以在扫码页提供"增加屏幕亮度"的提示,或直接调用原生亮度API把屏幕调到最高亮度。用户扫完再恢复原亮度。这个细节很讨喜,也很容易成为竞品差异化。

8. 进阶玩法:不只是"生成一个普通黑白码"

8.1 给二维码加Logo:漂亮与识别的平衡

很多产品想在二维码中间放一个Logo。技术上很简单,在生成的Texture2D上再画一个小图就行。但要注意:Logo本质是遮挡,遮挡区域的纠错信息会被破坏。如果Logo尺寸超过二维码模块的30%,识别率会大幅下降。我的建议是:

• 生成时用最高纠错等级(H级),给码留足冗余。
• Logo尺寸控制在二维码边长的20%-25%。
• Logo形状尽量居中,避开三个定位角。

实测下来,只要掩码区域不碰定位点和定时图案,加上H级纠错,识别成功率基本不受影响。

8.2 自定义样式:圆角、渐变、彩色的实现思路

黑白方块是二维码的标准形态,但很多产品会要求"把二维码做得好看一点"。这里给出完全可落地的两个方案:

• 简单方案:生成黑白码之后,用Shader对特定色值区域做颜色替换。黑色块换成品牌色,白色块保持白色,视觉上就很统一。
• 复杂方案:在编码阶段拿到二维码矩阵数据,自己用Mesh或图片绘制每一个模块,做圆角、阴影、渐变色。这需要你自己维护矩阵数据,工作量大一些,但样式自由度最高。

需要提醒的是:美观升级别动定位角。二维码的"回"字定位角是解码器识别方向的基准,改样式时最容易出的问题就是把定位角做得太艺术,结果扫码软件直接认不出。稳妥做法是只换数据区的颜色和圆角,定位角保持标准形态。

8.3 多二维码共存与大表单数据

有些业务会要求一个画面里同时出现多个二维码,比如取餐屏上同时显示多个不同桌台的码。这时要注意:多个码之间要保持足够间距,不要让静区互相重叠。解码端的BarcodeReader默认一次只返回一个结果,如果要做"一次识别多个码",需要遍历解码器内部的候选结果集合。代码上要自定义解码路径,复杂度上了一个台阶。

另外,二维码能承载的数据量有限,不要把大JSON塞进去。如果确实要传递大量结构化数据,业内通用做法是:二维码里只放一个短ID或短URL,真实数据由服务器或本地数据库通过这个ID去换。既压缩了码的内容,也让数据更新更灵活。

8.4 配合AR与现实场景:扫屏 vs 扫纸

扫码距离不同,最优参数完全不同。

• 扫屏幕(比如用户拿手机去扫电脑显示器上的码):屏幕本身会反光,亮度不稳定,距离近但经常产生摩尔纹。对策是降低采样分辨率、增大纠错等级、尽量避免缩小采样图。
• 扫纸质码(比如设备表面的铭牌):距离和角度变化大,光照复杂。对策是保留较高采样分辨率、开启TryHarder、并配合多点对焦。

如果你的产品两种场景都要覆盖,建议把参数做成可配置的,在进入扫码页时根据业务场景动态切换,而不是全用一套参数硬扛。这点在产品验收时特别有用——需求方如果发现某个场景扫不出,你至少能快速调参解释原因,而不是现场干着急。

9. 最后补充一段实战经验:测试别只在编辑器里自嗨

二维码功能,尤其是扫描端,是那种"纸上谈兵完全没用,必须真机多测"的功能。以下是我经过反复折腾后总结的测试要点:

• 至少测试三台不同档次、不同屏幕尺寸、不同摄像头素质的真机,别只在旗舰机上测。中端机的摄像头对焦速度、低光表现和旗舰机差距很大,识别率体验可能会从"流畅"直接跌到"扫不出来"。
• 打印出来测纸质二维码,屏幕码和纸质码各测一轮。同一套参数在两端的表现可能完全不同。
• 测试环境要包含强光反光、弱光、手抖、距离变化、斜角度扫码这些情况。别只在办公桌灯光均匀的情况下测,需求方一定会拿一个反光强烈的场景来验收。
• 生成端要多测中文字符、特殊符号、超长文本、前后台切换后重新生成这几类。我遇到过生成端在编辑器里正常、打包到Android上中文乱码的诡异问题,最后排查下来是编码声明不彻底。

功能上线后,如果你还想继续优化,可以考虑收集扫码失败时的采样图像做日志回传,分析用户到底是在什么情况下失败的。这个数据驱动思路,比闷头调参有用得多。

我自己的体感是:Unity二维码的生成与扫描,门槛不高,但坑很深。只要把"选库、生成细节、采样架构、平台适配、测试策略"这五个维度都想清楚,它就能成为一个非常稳定可靠的功能模块。希望这篇分享能让你少走一些我走过的弯路。