分类 软件 下的文章

相比于用C++写Qt,PyQt更加适合小项目入手,在单文件/单窗口的情况下更容易入手。

静态加载.ui文件需要使用pyuic5进行编译,然后作为库引入,使用一个类去继承该类即可使用。在这个类中,组件可以通过使用ui中指定的objectName直接进行获取,类似于Android中的findViewById

接下来是一些坑:

  1. 组件具有线程绑定性,只能在主线程内更新组件(包括设置组件内容),否则好的情况抛出Exception,坏的情况直接Segmentation Fault退出了,此时只能通过Qt的信号/槽机制来;
  2. 即便是新建QMessageBox也最好在主线程中进行(同样是信号/槽机制),否则可能可以展示信息,但是会出一些奇奇怪怪的错误,我这里遇到的情况就有诸如包含空格就段错误的情景。

简单码两句。

主要是解决了对于Android多线程机制默认操作的疑惑。

学过Android开发的大概大部分知道,Android的前台线程是UI线程。但是根据开发组的意图来看,这个线程应该是空闲率越高越好。如果学过计算机网络的话,这点可以很轻松的理解,越高的资源占用率意味着越大的延迟,只有当占用率尽可能低的时候,才能满足快速、及时响应的需求。

而多线程在解决了线程占用率问题(通过将大部分高时延的任务下放到后台线程完成,这些线程的响应实验要求相对较小)的同时,也带来了同步问题。Android解决同步问题的方法非常简单粗暴,“谁创建,谁拥有”。换个说法,只有创建线程不安全对象的线程本身才具有修改线程数据的权利。

那么,如果外界有修改线程不安全对象数据的需求的话,那么就必须由所有者线程主动提供一个入口,以所有者线程的身份对资源进行操作。Android为这个理论提供的时间就是Message, MessageQueue, Looper, Handler四件套。四件套的具体功能就不做赘述了,网上到处都是,而其中最为关键的,也是最常见到的组件之一,就是Handler。作为外部线程来说,调用Handler的各类message方法可以向所有者线程发送申请以修改资源;作为所有者线程来说,实现handleMessage方法可以从外部接收,并且自定义地处理请求。

然后困惑之处就在于,按照书上的方法,只要实现一个Handler类就能完成对这种资源的访问。四个组件既然是一套,那为什么只要四分之一就能完成功能呢?最重要的绑定线程的工作,又是在何处完成?

带着这个疑问,去网上转了一圈,最后在官方文档找到了答案( https://developer.android.com/reference/kotlin/android/os/Handler )。其中的奥妙就在于,我们的确只需要实现Handler就行了,在Handler类实体化的时候,内部就定义了一系列的操作,包括创建四件套中除Message外的其他两件(Message在四件套中主要作为数据型,而非逻辑型组件,只用于传递Handler请求)。根据书上所说,Looper类的构造器甚至还是私有的,一看就是不希望别人去动的那种。在IDE中多按几次ctrl看看源码,就能发现Handler的无参构造器会调用Looper.myLooper()方法,继续刨的话可以看见,Looper对象已经被ThreadLocal作为线程私有变量保管得好好的了。

总而言之,在日常使用Android Handler的时候,只要实现这个类就行了,其他工作其实是已经由Android框架本身完成了的,放心大胆使用即可。

在CentOS 8上配置Kubernetes。

步骤可以大致简述如下:

  1. 如果在国内,换源
  2. 安装Docker(需要手动添加repo)
  3. 安装Kubernetes配置工具Kubeadm,会自动顺带完成其他Kubernetes配件的安装(也需要手动添加repo)
  4. 决定一个CNI(容器网络接口)组件
  5. 使用kubeadm init初始化集群,记得带上CNI可能会需要指定的参数(至少FlannelCalico在默认情况下是要求手动显式指定默认的CIDR的)
  6. 使用kubectl apply(更新)或者kubectl apply(重置)安装对应CNI组件的Pod
  7. 使用kubectl taint nodes --all node-role.kubernetes.io/master-取消集群master节点的“特殊地位”,允许在master节点上部署应用容器 Google传统艺能

然后关于Kubernetes的镜像,默认用的是Google的GCR仓库,显然在国内是访问不到的,在拉取镜像的时候会报超时错误。网上有不少的解决方法,比如建立私有仓库,换源,但是要么太复杂,要么说的含糊不清。还是弄个透明代理最爽了

参考:https://coreos.com/flannel/docs/latest/kubernetes.html

最近在研究编码参数的时候,随手点开了某番剧的MediaInfo作为参考。结果一看,虽然MediaInfo上显示是AVC(H.264的一种)编码,但是居然没有编码参数Encode Settings

然后很是疑惑,遂到网上寻找隐藏H.264编码参数的方法。H.264的没找到,不过H.265的好像倒是有。

http://forum.doom9.org/archive/index.php/t-171681.html
这里有一群外国人讨论过这个问题,从中能够获取的信息之一是,x264编码器的开发者们本意似乎是希望编码参数跟随视频一同流传的,从某种程度上还能方便大家相互学习参数的调整。也就是说,AVC编码的视频本身没有携带编码参数是一种不正常的现象(视频编码程序本身并没有提供这种功能)。

然后仔细对比了一下MediaInfo里的参数,也没有发现什么猫腻。

不过后来用WinHex查看了一下文件头,发现这个文件的类型是ftypmp42,和常见的自带编码参数的ftypavc1有区别。说不定是因为数据流版本太老,所以不支持记录编码参数?(问题是,上个世纪的DV编码格式都能记录编码参数的啊)

难道是,失传已久的S级记忆消除秘术?

坑+1

Haskell家的软件简直是巨坑,我就说之前怎么只要编译和GPU有关的代码就失败= =

这次编译darknet终于发现,是Leksah的头文件和Windows SDK的头文件有重定义冲突,把Leksah的路径从PATH里去掉,问题就解决了

具体报啥错我忘了,反正是一个x开头的头文件有重定义