From b560749b7c930571072a8600e8c8879ac9099e3e Mon Sep 17 00:00:00 2001 From: wanganxp Date: Tue, 26 Dec 2023 00:44:06 +0800 Subject: [PATCH] =?UTF-8?q?=E8=B7=A8=E5=B9=B3=E5=8F=B0=E6=AF=94=E8=BE=83?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- docs/select.md | 51 +++++++++++++++++++++++++++++++++++++++----------- 1 file changed, 40 insertions(+), 11 deletions(-) diff --git a/docs/select.md b/docs/select.md index 129ea05c..d326ef21 100644 --- a/docs/select.md +++ b/docs/select.md @@ -191,6 +191,8 @@ flutter最大的优势是dart操作UI不需要通信，以及强类型，而改 不过自渲染由于无法通过Android的开发者工具查看GPU呈现模式，所以无法从条状图直观反应出掉帧。 +> 注意ArkUI-x不支持`Android8.0`以下的手机，不要找太老的手机测试。 + 很多人以为自渲染是王道，但其实自渲染是坑。因为flutter的UI还会带来混合渲染问题。 也就是说，js+flutter渲染，和js+原生渲染，这2个方案相比，都是js弱类型、都有逻辑层和渲染层的通信问题、都有原生API通信问题，而js+flutter还多了一个混合渲染问题。 @@ -256,15 +258,18 @@ uts语言是基于typescript修改而来强类型语言，编译到不同平台 - 之前的js要改成uts。uts是强类型语言，上面的示例恰好类型都可以自动推导，不能推导的时候，需要用`:`和`as`声明和转换类型。 - uni-app x支持css，但是css的子集，不影响开发者布出所需的界面，但并非web的css全都兼容。 -hello uni-app x是示例应用，源码在：[https://gitcode.net/dcloud/hello-uni-app-x/](https://gitcode.net/dcloud/hello-uni-app-x/)；打包后的apk扫描下面的二维码。 -![](https://qiniu-web-assets.dcloud.net.cn/unidoc/zh/uni-app-x/hello-uniappx-apkqrcode.png) +了解了uni-app x的基本原理，我们来看下uni-app x下的100个slider效果怎么样。 -在这个示例中，组件-表单组件下有slider100，100个滑块跟随手指移动，大家可以体验看看流畅度。 +项目[https://gitcode.net/dcloud/test-cross/-/tree/master/test_uniappx_slider_100](https://gitcode.net/dcloud/test-cross/-/tree/master/test_uniappx_slider_100)下有源码工程和编译好的apk。 -打开GPU呈现模式，可以看到没有一条竖线突破那条红色的掉帧安全横线，也就是没有一帧掉帧。 +如下视频，打开了GPU呈现模式，可以看到没有一条竖线突破那条红色的掉帧安全横线，也就是没有一帧掉帧。 +uni-app x在app端，不管逻辑层、渲染层，都是kotlin，没有通信问题、没有混合渲染问题。不是达到了原生的性能，而是它本身就是原生应用，它和原生应用的性能没差别。 + +这也是其他跨平台开发框架做不到的。 + uni-app x是一次大胆的技术突破，分享下DCloud选择这条技术路线的思路： DCloud做了很多年跨平台开发，uni-app在web和小程序平台取得了很大的成功，不管规模大小的开发者都在使用； @@ -283,7 +288,7 @@ DCloud做了很多年跨平台开发，uni-app在web和小程序平台取得了 在web端编译为js，在小程序端编译为wxml等，在app端编译为kotlin。 每个平台都只是帮开发者换种一致的写法而已，运行的代码都是该平台原生的代码。 -另外，同样业务功能的app，使用vue的写法，可比手写纯原生快多了。也就是uni-app x对开发效率的提升不只是因为跨平台，单平台它的开发效率也更高。 +而且，同样业务功能的app，使用vue的写法，可比手写纯原生快多了。也就是uni-app x对开发效率的提升不只是因为跨平台，单平台它的开发效率也更高。 其实google自己也知道原生开发写法太复杂，关于换种更高效的写法来写原生应用，他们的做法是推出了compose UI。 @@ -296,22 +301,46 @@ DCloud做了很多年跨平台开发，uni-app在web和小程序平台取得了 -uni-app x在app端，不管逻辑层、渲染层，都是kotlin，没有通信问题、没有混合渲染问题。不是达到了原生的性能，而是它本身就是原生应用，它和原生应用的性能没差别。 +既然已经把不同开发框架的slider-100应用打包出来了，我们顺便也比较了不同框架下的包体积大小、内存占用： -这也是其他跨平台开发框架做不到的。 +| |包体积（单位:M） |内存占用（单位:Kb）| +|-- |-- |-- | +|flutter |18 |141324.8 | +|ArtUI-x |45.7 |133091.2 | +|uni-app x |8.5 |105451.2 | +|compose ui |4.4 |98575.2 | + +包体积数据说明： +- 包含3个CPU架构：arm64、arm32、x86_64。 +- flutter的代码都是编译为so文件，支持的cpu类型和包体积是等比关系，1个cpu最小需要6M体积，业务代码越多，cpu翻倍起来越多。 +- ArtUI-x的业务代码虽然写在js里，但除了引用了flutter外还引用了js引擎，这些so库体积都不小且按cpu分类型翻倍。 +- uni-app x里主业务都在kotlin里，kotlin和Android x的兼容库占据了不少体积。局部如图片引用了so库，1个cpu最小需要7M体积，但由于so库小，增加了2个cpu类型只增加了不到1M。 +- compose ui没有使用so库，体积裁剪也更彻底。 +- uni-app x的常用模块并没有裁剪出去，比如slider100的例子其实没有用到图片，但图片使用的fesco的so库还是被打进去了。实际业务中不可能不用图片，所以实际业务中uni-app x并不会比compose ui体积大多少。 + +内存占用数据说明： +- 在页面中操作slider数次后停止，获取应用内存使用信息VmRSS: 进程当前占用物理内存的大小 +- 表格中的内存数据是运行5次获取的值取平均值 +- 自渲染会占据更多内存，如果还涉及混合渲染那内存占用更高 + +## 后记 + +跨语言通信、弱类型、混合渲染、包体积、内存占用，这些都是过去跨平台框架不如原生的地方。 + +这些问题在uni-app x都不存在，它只是换了一种写法的原生应用。 当然uni-app x刚刚推出，还有很多不成熟的地方，比如前文diss微信的暗黑模式，其实截止到目前uni-app x还不支持暗黑模式。甚至iOS版现在只能开发uts插件，还不能做完整应用。 但这个技术路线是产业真正需要的东西，随着产品的迭代完善，它能真正解决开发者开发效率和性能兼得的问题，**让跨平台开发不如原生，成为历史**。 -再次欢迎体验uni-app x的示例应用，感受它的启动速度，渲染流畅度。 +欢迎体验uni-app x的示例应用，感受它的启动速度，渲染流畅度。 -这里面有几个例子非常考验通信性能： -- 一个是组件-表单组件-slider100，100个滑块跟随手指移动。 -- 另一个是模版-scroll-view自定义滚动吸顶，在滚动时实时修改元素top值始终为一个固定值，一点都不抖动。 +源码在：[https://gitcode.net/dcloud/hello-uni-app-x/](https://gitcode.net/dcloud/hello-uni-app-x/)；打包后的apk扫描下面的二维码。 ![](https://qiniu-web-assets.dcloud.net.cn/unidoc/zh/uni-app-x/hello-uniappx-apkqrcode.png) +这个示例里有几个例子非常考验通信性能，除了也内置了slider-100外，另一个是“模版-scroll-view自定义滚动吸顶”，在滚动时实时修改元素top值始终为一个固定值，一点都不抖动。 + 我们不说服您使用任何开发技术，但您应该知道它们的原理和差别。 欢迎指正和讨论。 \ No newline at end of file -- GitLab