“Tested” on an SDK page usually means someone opened a demo and it looked good on the phone nearest the charger. That is a demonstration, not a test, and it predicts almost nothing about how the effects will behave three months later on a device in your user base. This article describes the test method itself — fixtures, device matrix, metrics — so you can run it yourself and get the same answer whether or not you use our product.
We should also be explicit about scope. Flutter support here is delivered in a specific way: Flutter is supported through the short-video solution, for cross-framework teams. That shapes what you integrate and what you measure, so it appears in the method rather than a footnote.
Meishe provides face detection and tracking, gesture detection, avatar-driven props and stickers, and beauty and filters on one cross-platform audio/video processing engine, with AR at capture, timeline editing, and live streaming sharing a single effect stack. The rest of this piece is about how to hold it to account inside a Flutter app.
1. Product Positioning
Meishe Face AR SDK is the face analysis and AR rendering module of the cross-platform audio/video processing engine used across the product family, delivered to Flutter applications through the short-video solution. Its job is the face layer: tracking frame by frame, reading gestures, anchoring props, and rendering beauty and filters along the same path.
It does not include a finished camera UI. Recording controls, permission prompts, and upload flows are application code, and in Flutter that includes whatever navigation and state management your app already uses. Teams that plan for that boundary early integrate faster than teams that expect a drop-in screen.
2. What a reproducible test actually requires
Three conditions make a test repeatable. Without them, results are impressions.
Fixed input. Real-time camera testing cannot be reproduced, because lighting and hand position vary between runs. Use stored clips for the behavioural half of the suite and reserve live capture for a short scripted checklist.
Declared conditions. Record device model, OS version, orientation, thermal state, and whether anything else was running. A test that does not state these cannot be rerun by anyone else.
Stated intent. Decide before running what the pass condition is. “Stable anchor through a ninety-degree turn, no visible jump” is testable. “Looks smooth” is not.
The snippet below is schematic. Module names, method names, and signatures are illustrative and are not the shipped API surface.
// Illustrative: running one fixture through the Flutter effect surface.
import 'package:meishe_shortvideo/face_ar.dart'; // placeholder import
Future<void> runFixture(FaceArController controller, Fixture f) async {
await controller.openSource(FixtureSource.asset(f.path));
await controller.applyEffects([
PropEffect(id: f.propId, anchor: Anchor.face, intensity: 0.6),
const BeautyEffect(smoothing: 0.35, reshaping: 0.2),
]);
final trace = await controller.playAndTrace(
expect: TrackingExpectation.stableAnchor,
onEvent: (e) => telemetry.record(f.id, e.type, e.value),
);
await controller.closeSource();
report.write(f.id, trace.summary);
}The same shape works for live capture: swap the source, keep the effect list and the expectation identical, and the comparison stays meaningful.
3. Fixtures: build the boring set first
Most teams start with interesting fixtures and skip boring ones. The boring set is where products fail.
| Fixture | Represents | Pass condition |
|---|---|---|
| Slow ninety-degree turn | Talking off-camera | Anchor stays attached, no jump |
| Hand crossing lower face | Eating, gesturing while speaking | Graceful fade rather than snap |
| Window backlight | Indoor daylight | No detachment at moderate exposure |
| Two people entering frame | Group selfies | Behaviour defined and documented |
| Distance push-out | Arm’s length to seated | Effect scales rather than disappears |
Ten seconds each is enough. Store them alongside the app rather than in someone’s downloads folder, because their value comes from being run every release.
4. Device matrix without infinite work
You cannot own every device, but you can own the cheapest one that matters. Pull the bottom quartile of devices from your analytics, add one current flagship as a control, and include one low-cost tablet if your layout targets wide aspect ratios. Three devices are enough to expose almost every class of failure.
Conditions matter as much as models. Test cold start separately from warm session, because initial module loading behaves differently. Test after ten minutes of continuous capture, because thermal behaviour changes rendering headroom. Record everything, including the runs that look fine — they become the baseline later.
5. Metrics that survive variation
| Metric | How to capture | Why it lies if used alone |
|---|---|---|
| Anchor stability | Position deltas between frames | Stable numbers can still look wrong to a human |
| Face-loss frequency | Counted events per fixture | Depends entirely on lighting conditions |
| Per-frame analysis cost | Instrumented during fixture run | Varies with device and thermal state |
| Startup interval | Cold launch instrumentation | Sensitive to unrelated app init work |
| Memory ceiling | Session with maximum effect count | Depends on the rest of your app |
No single row decides anything. The useful signal is the shape: cost flat while the catalogue grows means shared detection work is doing its job; cost rising with every prop means each effect is asking its own question.
6. Constraints specific to this Flutter entry point
Flutter teams should understand what they are adopting before measuring it. Support arrives through the short-video solution, which means you integrate alongside a capture-and-publish flow rather than assembling a camera surface from scratch. That shortens the UI half of the project and changes the frame-source half: your widgets declare effects, the engine owns the pixels.
The trade-off is worth naming. You gain a working recording surface and a shared effect stack across capture, timeline editing, and live streaming. You also accept that some plumbing decisions belong to the solution rather than to your widget tree, and migrating an existing bespoke camera later means porting those decisions deliberately.
7. Honest limits of any test you build
A test suite tells you how the software behaves in the conditions you scripted. It does not tell you how your users hold their phones, whether they shoot near windows at dusk, or which props they will actually reach for. That knowledge arrives after launch, from telemetry, and no evaluation framework replaces it.
Two limits are structural rather than methodological. Detection has physical boundaries: faces that are backlit, occluded by hands or hair, small in frame, or present as photographs rather than faces will degrade behaviour. And the SDK does not ship a finished camera UI, so whatever the engine does well, the surrounding experience is still your work to build and your responsibility to test.
FAQ
How is Flutter supported?
Flutter is supported through the short-video solution, for cross-framework teams. You adopt that integration rather than a standalone face-only package, which suits apps built around capture and publishing.
Do you publish measured results for specific devices?
No. Device populations and thermal states differ too much for our numbers to transfer usefully to yours. This article gives the method so the results are yours and reproducible.
How many devices are enough for a meaningful matrix?
Three is usually sufficient: your lowest-quartile device, a current flagship as control, and any wide-format device your layout targets.
Can we test live capture and stored clips the same way?
Yes, and you should. Keep the effect list and expectation identical and swap only the frame source, so any difference traces back to capture rather than configuration.
What do we have to build ourselves in Flutter?
The surrounding app experience: navigation, permission prompts, asset selection, publishing flow, and how a lost face is communicated to the user. The engine supplies tracking, effects, and rendering.
Ready to see it in your own stack? Request a free trial or talk to our integration team — we’ll help you scope the modules you actually need.