Flutter原生插件开发实战：从MethodChannel到PlatformView的完整指南
直接说结论：Flutter做跨端业务，UI层面再花哨也只是冰山一角，真正把App推向生产环境的，一定是那根连接Dart与原生系统的“脐带”。标题里“原生插件开发”这几个字，看着是几条MethodChannel的事，实际牵扯到工程结构、类型系统、异步模型、生命周期管理、打包构建，甚至还包括和Android/iOS系统框架的博弈。这篇实战指南，我就从零开始拆一个插件项目，把该踩的坑提前帮你踩一遍，适合已经能跑通Flutter基础App、但想深入平台层做定制能力的开发者参考。
1. 原生插件到底解决什么问题
1.1 为什么Flutter需要原生插件
先想清楚一个本质问题：Flutter的Dart代码跑在Skia/Impeller渲染引擎之上，它根本不直接持有系统能力。你调SharedPreferences、拿电池电量、扫描二维码、唤起系统分享面板，这些能力的源头都在Android的Java/Kotlin层和iOS的Objective-C/Swift层。Flutter官方把这些能力抽象成了plugin机制，让Dart通过异步消息和原生代码对话。
但很多项目走到一半会发现：官方插件覆盖不了业务需要。比如你要对接某个硬件SDK，厂商只给了Android AAR和iOS Framework，压根没有Flutter封装；比如你要做iOS的Live Activity灵动岛实时更新，官方插件根本没有现成的；再比如你想在Flutter页面里嵌入原生地图SDK，UiKitView的承载能力和性能都要自己调配。这些场景下，光会用插件不够，你必须自己写插件。
我自己最深的感受是，很多人一听说“写插件”就紧张，觉得是两套语言都要懂的大工程。实际上插件开发的核心难度不在语言，而在理解Dart与原生侧的数据通道协议、生命周期同步、线程模型转换这三件事。把这三件事理清楚，插件开发就是一套固定套路。
1.2 方法通道机制是你的第一块拼图
方法通道（MethodChannel）是Flutter与原生通信的门户。你可以把它理解成一条管道，Dart侧往里扔“请求”，原生侧拆包处理后扔回“响应”。通道靠名字区分，名字本质上是一个字符串标识，两端只要用同一个名字绑定，就能互相找到对方。
一条标准的方法通道长这样：
Dart侧：
Android侧（Kotlin）：
iOS侧（Swift）：
看清楚这个结构：invokeMethod("getBatteryLevel") 传的字符串是方法名，call.method 拿到同一个字符串，两端是一一对应的。方法名看似随意起，但你最好按业务模块前缀区分，否则几十个插件堆在一起，连自己都会搞混。
有一个非常重要但是容易忽略的细节：MethodChannel的调用默认跑在平台主线程。也就是说，你在Dart侧发起一次调用，原生侧的MethodCallHandler是主线程执行的。如果你在这个handler里做了耗时操作，比如读数据库、解析大JSON、访问网络，Android上直接就是ANR，iOS上就是UI卡顿。所以原生侧接到方法调用后，必须快速把耗时任务丢到子线程，再切回主线程返回结果。
1.3 什么时候该自己写插件，什么时候不该
写插件是有成本的。每写一个自定义插件，你就凭空多了一个Android工程和iOS工程的维护负担，版本迭代、API适配、异常监控全都要跟。所以动手之前先做判断。
我的判断标准是这样的：官方插件或者信誉良好的第三方插件能覆盖80%以上需求，就别自己写；但如果遇到下面几种情况，必须自己动手：
- 业务强依赖特定原生SDK，第三方Flutter封装不维护或质量堪忧。
- 需要高频、低延迟的系统数据流，比如传感器数据、后台定位回调，通用插件的数据传递效率不够。
- 要做系统级集成，比如通知栏快捷操作、桌面小组件、Live Activity、周边设备通信。
- 想给团队沉淀通用的业务基础组件，避免不同项目重复写类似的桥接代码。
还有一种容易被忽略的情况：现有插件功能能做，但性能不达标。比如某地图插件在低端机上初始化要好几秒，你检查发现是插件在主线程做了大量初始化工作，这时候值得重写一个优化版。
2. 从零搭建一个原生插件项目
2.1 用命令行创建插件工程
Flutter官方提供了插件工程的脚手架命令，可以直接在命令行生成：flutter create --template=plugin。注意，这里一定要指定--template=plugin，不是普通的--template=app。另外还有两个很重要的参数：
--platforms：指定你要支持哪些平台。默认会生成Android、iOS、Linux、macOS、Windows、Web一堆目录。如果你的业务只需要Android和iOS，务必加上--platforms=android,ios，省得目录里一堆用不上的平台代码。--org：指定包名前缀，比如com.example。这个值会直接写进Android的namespace和iOS的bundle id，后期修改非常麻烦，前期想好再定。
创建完成后的目录结构大致是这样的：
lib/下是Dart接口，android/和ios/是原生壳工程，example/是一个独立可运行的示例App，用来开发和调试插件。这里有个很实用的操作习惯：所有的插件调试都在example工程里进行，不要单独建一个测试App。因为example工程已经帮你把插件的本地依赖配好了，改一行原生代码，热重载或重新运行就能看到效果。
2.2 插件工程目录结构深度解析
很多新手对插件工程的目录结构很迷惑，总觉得多出来的那些文件是噪音。我拆开讲一讲关键部分。
Android侧的入口文件是android/src/main/kotlin/下的MyPlugin.kt。插件类要实现FlutterPlugin接口，里面有两个关键方法：onAttachedToEngine和onDetachedFromEngine。前者是Flutter引擎和你插件建立连接的时机，后者是解绑的时机。所有的资源申请和释放都要放在这两个回调里，尤其注意：不能把资源泄漏到插件实例之外，否则Hot Restart的时候会崩溃。
iOS侧对应的是ios/Classes/下的MyPlugin.swift，实现FlutterPlugin协议。同样有register(with registrar:)方法和detach(from registrar:)方法。iOS侧还有个特殊文件my_plugin.podspec，这是CocoaPods的描述文件，里面除了版本号，有一个字段很关键：s.dependency。如果你的插件要依赖第三方的iOS原生库，就必须在这里声明依赖关系。同理，Android侧如果依赖AAR或JCenter库，要在android/build.gradle里添加dependencies。
Dart侧的文件是lib/my_plugin.dart，这里定义你暴露给业务方的API。我强烈建议你在这层做“门面模式”——对外只暴露高层次的业务方法，内部再拆方法通道、事件通道、平台视图等细节。业务方越不需要关心底层通信，你的插件接口就越好用。
example/目录下的lib/main.dart是插件开发阶段的主战场，你可以在里面快速写测试代码调原生能力，也可以用来复现问题。说句实在话，很多时候排查插件Bug，不是看原生代码写错了，而是样例代码压根没触发那条分支。
2.3 暴露原生能力的Dart API设计
设计插件接口时，最容易犯的错是照搬原生API。比如原生有一个startScan(options)方法，你就直接映射成Dart的startScan(options)，参数还是一个Map。这种接口让业务方写起来很难受，因为他们不知道Map里要传什么key。
我习惯的写法是定义强类型Input对象，或者至少定义具名参数：
接收返回值也一样，不要直接返回Map让业务方自己解析。封装一个结果类，比如ScanResult，把字段解析逻辑放在插件内部。这样一来，以后原生侧如果改了序列化字段名，你只需要在插件内部适配，不用通知所有业务方修改代码。
再强调一点：Dart侧永远使用Future和Stream作为异步接口，不要让业务方接触MethodChannel底层对象。Future对应一次性请求，Stream对应原生侧持续推送的事件流。把这两个模型设计好，业务方的代码就能保持简洁。
2.4 平台侧原生代码的接入写法
Android侧如果你用的是Kotlin，上面那个setMethodCallHandler是基础写法。但实际项目中你会遇到拿不到FlutterEngine实例的问题，尤其是插件在后台被创建时。这时候依赖FlutterPlugin的onAttachedToEngine回调，把flutterEngine.dartExecutor.binaryMessenger缓存成一个属性，后面所有通道都基于这个messenger创建。
iOS侧要注意registrar的生命周期。新版Flutter插件API已经废弃了旧的register方法里的FlutterPluginRegistry，统一走FlutterPlugin协议。注册方法通道时，要从registrar.messenger()获取FlutterBinaryMessenger。如果你的插件要同时支持旧版的App Extension（比如通知扩展），可能需要额外的初始化分支，这属于进阶话题，后面单独展开。
原生侧代码的组织也有讲究。不要把所有业务逻辑都堆在插件入口类里，入口类只负责解析MethodCall、分派任务。把耗时操作、回调逻辑、数据模型拆到独立的类或文件中，一来是代码清晰，二来也方便写单元测试。插件工程一样有测试，只是很多人忽略了。
3. 方法通道的进阶：类型映射与异步处理
3.1 标准消息编解码与类型映射规则
MethodChannel底层的消息是二进制序列化数据，Flutter使用StandardMethodCodec做标准的编码解码。这意味着Dart和原生侧传递的类型必须符合一套表：
Dart类型会映射成对应的原生类型。比如Dart的null对应Java的null/Swift的NSNull；bool对应Boolean/NSNumber；int在Android对应Integer，在iOS对应NSNumber；double在Android对应Double，在iOS对应NSNumber；String对应String/NSString；List对应List/NSArray；Map对应HashMap/NSDictionary。字节数组Uint8List对应byte[]/FlutterStandardTypedData。
这里有个高频坑：Dart侧的int在Android原生侧，可能被序列化成Long而不是Integer。如果你的Kotlin代码写死了call.argument("id") as Int，而Dart侧传的值超过了Int范围，直接就是ClassCastException。正确写法是拿到Number类型再转换，或者直接取Long：
还有个容易踩的坑是Map的key类型。Dart侧的Map默认是HashMap，key不保证顺序，这和JSONObject不一样。如果你的业务逻辑依赖字段顺序，要么序列化成JSON字符串传过去，要么在Dart侧用LinkedHashMap并明确插入顺序。我的经验是接口设计尽量扁平化，嵌套Map虽然灵活，但是序列化和排查问题都更麻烦。
3.2 异步请求与耗时任务的正确打开方式
回到前面说过的问题：MethodCallHandler跑在主线程。但有一个例外情况，result.success()必须回到主线程才能生效，否则Flutter引擎收不到数据或者异常。所以耗时操作的标准套路是：先在主线程接收调用，然后丢到后台线程执行任务，任务完成后再切回主线程返回结果。
Android侧Kotlin典型写法是：
iOS侧GCD写法：
有人问，这会不会太原始？其实插件开发里保持线程控制权在手，比依赖框架的隐式切换更可靠。你永远不知道调用方会在什么线程发起请求，所以原生侧主动控制线程是安全底线。
另外注意一个细节：Result对象是一次性的，调用完success或error之后，再调用会直接抛异常。所以分支逻辑里要确保每条路径都只会调用一次Result；用try-catch包住所有可能抛异常的分支，catch里调用result.error。
3.3 事件通道：原生主动推送数据
MethodChannel只适合“业务方主动拉取”的场景，如果要原生持续推送数据，比如电量变化、传感器数值、后台下载进度，就得用EventChannel。EventChannel的机制是Dart侧创建一个EventChannel.receiveBroadcastStream()，原生侧通过EventSink推送数据。
初始化方式稍微不同。Dart侧：
原生侧创建时，先定义EventChannel.StreamHandler，在onListen时把EventSink存起来，后面业务逻辑直接调用sink.success(data)就行。Android实现如下：
EventChannel和MethodChannel一样，数据推送默认也在主线程。如果你要在后台线程推送数据，同样要切到主线程再调用sink.success。
关于热词里提到的“Future的then回调是放入微任务队列吗”这个问题，确实和插件机制相关。在Dart侧，Future.then的回调默认是同步微任务，不会创建新的EventLoop事件，所以你在then里写代码，只会影响当前Isolate的执行顺序，不会阻塞原生线程。在实际插件开发中，这意味着一件事：如果你在Dart侧连续调用多个原生方法，它们之间的执行顺序是确定的，不要以为会并行乱序执行。
3.4 避免标准方法通道的性能陷阱
一个容易忽视的问题：每个MethodChannel调用都有序列化和反序列化的固定开销，频繁调用时这个开销会被放大。比如你要每秒钟刷新一次原生控件100次，这种高频调用就不适合走MethodChannel。
我的经验原则是：高频数据流优先用EventChannel，低频一次性请求用MethodChannel，需要共享大块内存时考虑直接用FFI（Dart Native Extension）。FFI是另一个话题，但插件开发者要心里有数——不是所有通信都要走MethodChannel，这是一个性能和架构的权衡问题。
4. 高难度场景：PlatformView与混合视图
4.1 原生视图嵌入Flutter的原理
现实业务里经常遇到一个需求：地图、视频播放器、AR相机这类原生控件，要直接嵌入Flutter页面。Flutter为此提供了PlatformView机制，Android上叫AndroidView，iOS上叫UiKitView。它的本质是让Flutter引擎在一个独立的纹理上渲染原生视图，再把这个纹理合成到Flutter的渲染树中。
这里涉及一个重要的背景：Flutter用Impeller渲染引擎时，PlatformView的合成方式和旧版Skia不同。热搜词里有个典型的报错形如“flutter impeller”，实际上Impeller对PlatformView的纹理注册时机更敏感。如果你在Impeller模式下遇到原生视图黑屏，一个快速验证方法是临时关闭Impeller，看是否恢复正常。但要清楚，这只是一个排查手段，最终还是要适配Impeller的合成链路。
PlatformView的创建代码大致这样：
原生侧要做的核心事情是实现一个PlatformViewFactory。Android侧继承PlatformViewFactory，重写create方法返回一个PlatformView实例；iOS侧实现FlutterPlatformViewFactory协议。工厂里的creationParams会自动帮你解析成原生侧的Map。
4.2 PlatformView性能调优与手势冲突
PlatformView最头疼的问题有两个：一个是性能，一个是手势。先说性能。原生视图每帧都要和Flutter纹理做合成，如果原生视图太重（比如高帧率视频），画面会掉帧。我的做法是尽量让原生视图保持简化，比如地图控件能去掉的图层就提前设置关闭；另外避免在同一页面堆叠多个PlatformView，能合成一个原生容器就合成一个。
手势冲突也是一个经典问题。Flutter的GestureDetector和原生控件的触摸事件是两条事件流，默认情况下，Flutter页面会先拦截手势，导致原生控件的点击、滑动偶尔失灵。解决办法是在原生侧主动拦截，Android上重写PlatformView的getTouchIntercepter返回true，iOS上实现gestureRecognizers返回指定手势的代理。
这样设置之后，原生控件的触摸事件完全掌握在原生侧手里。但注意，这么做会牺牲部分Flutter侧的手势能力，比如页面级横向滑动和地图滑动的冲突。所以手势拦截策略一定要结合页面结构设计，建议在插件层暴露一个配置项，让业务方按需开关。
4.3 PlatformView在导航状态下的生命周期
热词里有个“flutter navigator切换页面后，会丢失状态吗”的问题，在PlatformView场景里尤其突出。当Flutter页面被压栈或切走时，PlatformView的dispose可能被调用，状态丢失。默认的AndroidView在Flutter引擎销毁预览上下文时会释放，但如果你依赖原生视图内部的一些UI状态（比如地图中心点坐标），这段状态不会自动保留。
我的建议是：不要在PlatformView内保存关键UI状态，状态一定要提升到Dart侧或持久化存储层。比如地图的中心点、缩放级别，在onPlatformViewCreated之后通过方法通道设置一次，切走页面回来前再重新设置。这看起来多写了几行代码，但避免了状态丢失导致的极其难查的Bug。
还有一种情况是页面频繁进出，PlatformView反复创建和销毁，性能很糟糕。如果业务确实需要高频切换，建议用PageView或者在页面栈里缓存整个Flutter页面，而不是缓存PlatformView本身。因为PlatformView的创建开销，比Flutter普通Widget大一个量级。
5. 打包、发布与常见报错排查
5.1 打包时Gradle配置的几个大坑
插件开发完，集成到正式App工程时，最常见的问题出在Gradle配置上。热词里那句“you are applying flutter's main gradle plugin imperatively using the apply s...”，就是一个非常典型的报错：你自己的插件的build.gradle里，在模块级别用apply plugin: 'com.android.library'，但是和Flutter的插件机制冲突了。
新版Flutter的Android插件构建系统，要求你使用声明式的插件DSL，而不是命令式apply。解决办法是把：
替换成：
同时确认android块里有namespace设置，比如namespace 'com.example.my_plugin'。旧版插件工程可能没有这个字段，但Android Gradle Plugin 8.0以后强制要求，缺失会直接编译失败。
另一个高频报错是“could not close iterator”或“java.lang.AssertionError”，这类问题和AGP版本、Flutter版本、JDK版本混配有关。我的排查顺序是：先统一JDK版本（推荐JDK 17），再统一Gradle和AGP版本。用Flutter 3.x的稳定版时，AGP建议8.1以上，Gradle建议8.3以上。这些版本不是越高越好，要以你的Android项目原本的配置为基准，跨大版本升级时最容易莫名其妙报错。
5.2 回调队列与消息线程带来的诡异问题
插件开发中有一类极其隐蔽的问题：原生侧回调导致Dart侧收不到数据，或者拿到脏数据。这些问题的根源往往不是逻辑错误，而是消息线程和队列顺序。
热词里提到的“flutter future的then回调是放入微任务队列吗”，在插件场景下的实际映射是：原生侧调用result.success()时，消息回到Dart侧后，await后面的代码进入微任务队列执行。如果你在微任务里又立刻调另一个原生方法，相当于在同一个消息处理循环里嵌套了新的消息发送。这在大多数场景下没问题，但如果你在原生侧使用了同步返回大量数据的方式，就可能出现栈溢出或者时序错乱。
我的经验做法是，跨原生方法调用之间，尽量留出一次事件循环的空隙，比如强制加一个await Future.delayed(Duration.zero)，让消息处理队列有机会消化中间状态。这个方法看似有点“脏”，但它能解决大量由于插件消息时序导致的隐性Bug。
5.3 Navtive状态丢失与其他运行时异常
插件运行时异常有很多种，我挑几个典型的讲。Android侧最常见的崩溃是MissingPluginException，Dart侧调用了一个原生侧根本没注册的方法。这个报错出现的原因，往往是插件没有在onAttachedToEngine时重新注册，而App在热重启后引擎重建，但插件注册流程没有正确执行。排查方式很简单：在onMethodCall入口打印日志，确认方法名是否到达原生层。
iOS侧常见的问题是插件没有正确register。新版Swift插件如果忘了在register(with registrar:)里调用registrar.register(pluginInstance)，通道根本没生效。调试时可以加断点确认register方法被触发。
如果插件的方法通道和某个已存在的插件重名，也会导致不可预期的行为。这是一个防不胜防的坑：通道名必须全局唯一，建议命名格式是com.公司名.产品名/功能名，命名空间长一点没坏处。
5.4 发布到pub.dev的规范与注意事项
插件开发完成后，如果你希望让团队其他人用pubspec.yaml依赖，就要发到pub.dev（私有仓库也可以搭）。发pub包有几点硬性要求：
pubspec.yaml里的version必须符合语义化版本规范，比如1.2.0，不能是1.2。- 插件必须有良好的
README.md，说明支持的平台、环境要求、使用示例。pub.dev的审核很看重文档质量。 - 如果有原生代码，务必提交
CHANGELOG.md，每次发布都要更新变更记录。 - 上传前执行
dart pub publish --dry-run，它会自动检查格式、许可证、遗漏文件等。
发布之后还有一个维护点：API变更要遵循deprecation流程，不能在1.0里有一个方法，1.1里直接删掉。因为下游用户可能锁版本，破坏性变更会对他们造成很大的升级痛苦。我的习惯是任何破坏性变更都把主版本号加一，这样pubspec的version constraint才能正确控制风险范围。
6. 关于调试手段与工具链的补充
6.1 日志体系是插件开发的第一生产力
插件开发调试时，Dart侧的打点最多是业务流是否走通，但问题往往在原生侧。所以原生侧务必加上结构化日志。Android侧的Logcat看板，过滤Tag建议用PluginTag_功能名，iOS侧用统一的子系统名加分类，这样Xcode控制台才能快速隔离插件日志。
我自己的习惯是给插件做一个日志开关，默认关闭，Debug模式下通过Dart侧透传一个配置开启。这样崩溃或者异常行为发生时，让测试人员方便地开启日志、复现、收集，大大加快排查速度。日志要包含：方法名、参数摘要、线程编号、耗时、错误堆栈ID。这些信息组合起来，才能快速定位是通信问题还是业务问题。
6.2 原生调试器和Flutter DevTools双轨并行
调试插件联调问题时，我强烈建议双轨并行：用Android Studio或Xcode的原生断点调原生代码，同时用Flutter DevTools看Dart侧的逻辑和时序。很多人只开其中一个，结果问题出在对方那侧时完全无感知。
有几次我排查一个“原生侧明明收到数据，Dart侧却报空”的问题，就是靠DevTools的Timeline面板，看到消息往返时间异常，再倒推回原生侧找到了一个线程阻塞。光靠断点根本看不出这种跨线程的时序问题。
6.3 巧用Example工程做最小复现
前面说了插件调试都在example工程。它的价值不只是开发调试，更是Bug定位的关键工具。当你收到一个“插件不工作”的报告时，第一反应不是去翻Dart代码，而是在example里写一个最小复现用例，把原生调用参数固定下来，然后单独跑通。如果最小用例能复现，问题在插件内部；如果不能，问题在业务方的集成方式。
这个习惯帮我省掉了太多无意义的排查时间。插件不是黑盒，但它的调试链路很长，任何一个环节都能掉链子，只有用可控的最小复现来缩小范围，才能把时间花在真正的问题上。
7. 插件架构演进与其他扩展
7.1 从单通道到多通道的架构演进
插件规模一大，就不能把所有方法都堆在一个MethodChannel里。我这里说的规模大，不是指方法数量多，而是指业务域多。比如一个插件同时管设备信息、电池、蓝牙、传感器，这四个域放在一个通道里，方法名靠前缀区分，只会让代码越来越难维护。
我的做法是在插件内部按业务域拆分多个MethodChannel：
Dart侧每个业务域一个独立的Manager类，插件入口只做分发。这看起来增加了文件数量，但每增加一个新域，你只需要新增一组通道和类，不用去动原有代码，符合开闭原则。
7.2 插件与Flutter的新架构演进
Flutter官方这几年一直在推“Federated Plugins”架构，也就是把平台接口、默认实现、平台特定实现拆成独立的包。简单说，业务方依赖一个顶层接口包，不同平台通过依赖注入组合实现。这样做的最大好处是，以后你可以用不同的底层实现替换默认实现，做成可插拔架构。
如果你的插件要开源给社区用，我建议从一开始就按Federated架构来组织。虽然前期工作量多了一个抽象层，但后期维护和扩展成本反而更低。如果只是公司内部用，直接单包实现，不必过度设计。
另外有一个新趋势值得关注：Dart的FFI调用能力越来越成熟，部分原本必须走MethodChannel的功能，可以用FFI直接调原生代码，省掉序列化开销。比如需要在内存里快速处理大量数据时，FFI的优势非常明显。但FFI的缺点是学习成本更高、跨平台适配更麻烦，所以要因场景而异。
7.3 插件开发中的测试策略
最后聊一下测试。很多人认为插件测试就是连接真机跑一遍，其实插件的Dart侧逻辑是可以做单元测试的。把MethodChannel的调用封装在一个可注入的通信层里，Mock通信层就能测业务逻辑；原生侧也可以写单元测试和集成测试，Android的InstrumentedTest和iOS的XCTest都支持。
CI上一定要跑插件集成测试。假的模拟器连不上真机能力，但至少能验证插件的注册、通道建立、基本方法调用不会崩。插件这种跨端组件，一旦回归都是连锁反应，自动化测试是最后一道防线。
一点实际体会
做插件开发时间长了，有个很深的体会：真正决定插件质量的，不是你会不会写Kotlin和Swift，而是你有没有建立“通信思维”。所谓通信思维，就是时刻清楚数据从哪里来、经过哪些线程、缓冲在哪个队列、最后由谁消费。Dart侧抛出来的错误，往往只是原生侧深埋问题的表象。如果你每次遇到问题都能沿着消息通道链走一圈，先看原生侧有没有注册，再看线程有没有阻塞，最后看消息序列化是不是符合类型，至少能解决一大半疑难杂症。
还有一点想多说一句：不要迷信“插件越薄越好”的说法。插件层的职责不是越少越好，而是边界要清晰。把序列化解析、错误码转换、入口分发放在插件层，把真正的业务逻辑放在业务层，这个边界比单纯“薄”重要得多。插件哪怕代码量大一点，只要每个文件职责明确，维护起来并不会痛苦。怕就怕把所有代码糊在入口类里，最后变成一个谁也看不懂的“通信大杂烩”。
1085 875 3949 1809 880 695 327 4428 849 294 1063 1570 470 452 204 610 1309 408 161 1149