又又又要来滑轨道歉了，这两周我一篇报告都没出，实在是肥肠抱歉，一来是长期的工作学习不运动不控制饮食导致了脂肪肝，一直在医院来回跑，二来是这莫名其妙就染上了跟前两年症状很相似的病导致无法工作到现在还没完全恢复，多重Debug算是给我叠满咯（ 各位大大一定 一定 一定 要注意身体啊，秃头在器官疾病面前都是轻的了 ），当然，这几周我也没闲着，虽然没办法工作，但是休病也是能进行学习滴，而且这也快到试用的Deadline了，这要是没拿到板子那后面开发就必须得搁置了，所以现在就来给大家汇报结果以及给各位画免费的大饼来了，多一篇文章多一份希望嘛
正如我的标题所说，我所利用飞腾派实现的是一个 智能座舱系统 ，那么先不论智能，要想实现一个合格的系统，要具备： 应用拉起能力 、 窗口管理能力 、生态支持等等
那么在笔者所认知下的车机系统开发厂商的路线有：
基于Android或部分组件自研的深度定制实现车机以继承Android的原始生态以及窗口管理能力的
有选择完全自研车机系统让开发者专门为其定制软件生态的
还有一种则是使用3D引擎来做车机系统的开发的，这种通常来说系统的应用拉起与窗口管理还是基于宿主能力，最近Unity搞的团结引擎就有车机版的2B支持
笔者作为一个菜鸡开发者自然是没有哪些具备自研能力厂商的号召力，同时本人也对Android相关开发并不了解，那么给到我们的选择其实相当之有限
同时呢如果不去考虑商业化而是以学习的态度去追求更新的技术，去尝试重复的造轮子，无疑是能够精进我们的技术水平的，因此笔者选择了 走Linux去集成Linux的系统软件生态，而在窗口管理上则是选择了OpenEuler社区开源的FT_engine方天视窗引擎
这里可能读者就要有疑问了，你咋这么善变呢，前文你还说走Wayland Weston，现在你又说要去整FT_engine，这不两边都想吃啥都吃不着嘛
欸欸欸，此言差异，笔者固然也不会把宝全然压在一个初出茅庐的显示服务协议的，正如早年实现的Wayland其推进替代X11的事也不过这两年，这事有风险但可控，在FT_engine的设计理念中提到它们同样会 对Wayland协议进行支持 ，同时也会 基于XWayland再去兼容X11 （很套娃），我们可以先根据它们的服务协议去开发Wayland的基本系统能力，如果后期这个项目发展不错，那么此时我们已经能把整个服务框架吃透了，之后我们再去迁移到FT协议上就相对轻松很多
那这能带来什么收益呢？
这收益可就大了，首先FT_engine设计支持的方向是针对OpenHarmony的
倘若FT_engine初步工程有所进展，那么就能实现对OpenHarmony原生应用的显示支持（及ArkUI）
如果发展势头良好，则有替代当前OpenHarmony的Wayland显示协议
试想下，我们用一个学习项目的可控代价去换取一个未来潜力极大的新生态接入，这是波红利我觉得我得拿捏一下
上面就是笔者给各位画的一个大饼，有人可能不理解，但我觉得可以赌一赌，成了咱跟OH喝汤，败了Remake成本不高
为啥略呢，因为这是一个预移植，基于飞腾派的OpenEuler支持不知道还要等多久，所以咱们先用虚拟机做开发，但是呢，这里即便略，也要略的优雅一些，以防很多小伙伴跟着走可能会踩坑
因为咱们是开发虚拟机，虽然在内存上消耗不大，但是一系列编译环境如Qt之类对硬盘容量还是有要求的，由于笔者的工作站是4T的开发盘因此这边直接给到了128G
实际情况下32G未必不够，但VMWare默认是8G，这就铁打的不够，我光Qt都得1-2G了吧 。当然啦只是想试试FT_engine的使用32G即可，未来还有开发打算的尽量再高点
还有一点需要注意，在部分视窗下如Gnome是需要启动VMWare的3D加速功能的，否则会报错，FT_engine也是如此
在这启动：
那么在访问操作系统，尤其是要对桌面环境进行开发的，可以选择切换tty或是采用多远程连接，笔者这边为了方便截图选择了通过远程连接来进行开发
其实这里也是可以略的，基本还是上期的那些东西，但这里还是要提一下，没用过OpenEuler的可能不了解，它所用的包管理器并不是Ubuntu下的apt，而是与红帽系相同的yum，因此安装时不再是apt install 而是yum install，部分的包名也不一定相同，使用时要多用search指令，我相信这难不到各位，毕竟它比起Clear Linux那swupd要容易上手的多
我这里也给几个示例，各位如果遇到缺库就按照这个方式来安装：
安装qt5基础环境：sudo yum install qt5
安装gcc/g++：sudo yum install g++ gcc
这里只是演示怎么安装环境包，后面就不再演示了
FT_engine的代码仓是在gitee上面的，我们需要拉取两个仓，一个是项目本体：
仓库链接：https://gitee.com/openeuler/ft_engine.git
这个本体项目的编译有针对新手的编译流程指导和环境配置脚本
但是也存在一个不足，很多细节会没有更新，也不讲全，比如下面这个页面：
其实在本体项目里是不存在runFT_wayland.sh及相关环境配置的文件的，同时wiki也没有告知我们是要自己创建还是在哪拉取，这就是新项目没有做好项目管理的一个比较常见的问题，那么笔者也是找到了这个Wayland的支持仓：
仓库链接：https://gitee.com/openeuler/ft_wl_fwk.git
这个仓库就没有编译讲解了，不过编译方法都是相同的，先检查环境配置，再进行编译
两个仓库都拉下来我们就可以进行编译相关了
首先进到ft_engine仓里，执行环境检查命令：./build/prebuild.sh -b debug -i
这个过程会相对比较漫长，建议先去喝杯咖啡
执行完后就进行编译：./build.sh -b debug -i
到这本体项目就算编译完成了，但是我们此时还需要去编译Wayland支持
进入ft_wl_fwk项目根目录进行环境配置检查：./build/prebuild.sh
之后进行编译：./build.sh -b debug -i
都完成之后我们的编译就大功告成了，接下来就是尝试启动一些demo了
先在ft_engine中启动方天视窗：./runFT.sh
然后进入ft_wl_fwk中启动Wayland服务支持：./runFT_wayland.sh
当我把这些服务都启动完之后就可以通过补齐我们程序所需的开发编译/解释环境然后显示我们原来的Qt程序了：
那么这里我没有使用我们前面所做的车机交互测试，主要是因为在openEuler上不对Python2支持的，但是Qt的Webengine是全版本都需要Python2，OpenEuler便移除了这个子组件，而我们原先的程序Live2D又刚刚好用上了，因此，在我补齐缺失的组件之前先用PyQt进行验证
更多回帖
