1.NAV2-Velocity Smoother 速度平滑器理解
2.从VVeboTableViewDemo到YYAsyncLayer（一）
3.MyBatis-Plus代码生成器（3.5.1版本）
4.请问谁会在fluent中用UDF编一个进口速度为抛物线或对数分布，源码麻烦了

NAV2-Velocity Smoother 速度平滑器理解

       NAV2 Velocity Smoother 是源码一个用于平滑由 NAV2 框架发送给机器人控制器速度的功能包。主要目的源码是通过平滑加速减少机器人电机和硬件控制器的磨损。平滑处理包括对速度、源码加速度和死区的源码控制。个人理解其核心功能有以下几点：

       1. 确保发布的源码php微信分销系统源码速度在容许的速度区间内。

       2. 保证指令速度与机器人当前速度所计算得到的源码加速度在容许的区间内。

       3. 在[x,源码 y, theta]坐标轴上考虑同比例变化。

       4. 考虑闭环控制，源码通过使用 odometry 数据来保证平滑过程的源码准确性。

       Velocity Smoother 参数设定如下：

       1. **smoothing_frequency**：设置平滑频率（Hz），源码决定如何使用最后接收到的源码速度命令进行速度、加速度和死区约束的源码捕鱼达人辅助 源码平滑处理。根据局部轨迹规划器的源码速率调整平滑效果，设置较高频率时进行插值并提供平滑的源码硬件控制命令。

       2. **scale_velocities**：是否按照同比例调整其他速度组件，以适应加速限制带来的变化。确保所有组件方向一致，同时严格遵守加速限制，即使这意味着稍微偏离命令轨迹。

       3. **feedback**：使用当前状态反馈，OPEN_LOOP 模式下使用上一次发布的速度作为当前速度，适合开环控制；CLOSED_LOOP 模式下使用 odometry 信息估计速度，要求 odometry 高速率低延迟。

       4. **max_velocity**：在[x,pytorch module类源码 y, theta]轴上的最大速度。

       5. **min_velocity**：在[x, y, theta]轴上的最小速度，且为负值，表示逆向。

       6. **deadband_velocity**：发送给硬件控制器的最小速度，防止由于无法达到该速度而损坏硬件控制器的情况。

       7. **velocity_timeout**：速度接收的超时时间，即原始速度接收频率。

       8. **max_accel**：每个轴[x, y, theta]上的最大加速度。

       9. **max_decel**：每个轴[x, y, theta]上的最小减速度，应为负值。

       . **odom_topic**：用于闭环控制的 odometry 主题。

       . **odom_duration**：在闭环模式下，易源码做成品缓冲 odometry 命令以估计机器人速度的时间。

       源码注解涉及的主要函数为 void VelocitySmoother::smootherTimer()，该函数接收由局部路径规划器或运动控制器发布的速度指令，并发布经过平滑处理后的速度。

从VVeboTableViewDemo到YYAsyncLayer（一）

        知道 VVeboTableViewDemo 其实很久了，一直想研究一下，最近终于有时间了，将 VVeboTableViewDemo 用Swift做了一遍（ VVeboTableViewDemo.swift ）,花了两个周对iOS优化的一系列文章通读了至少一遍，发现它们对优化的点总结的很散，而且大多不适合我这样的小菜。

列如这样的问题：

        首先看一下VVeboTableViewDemo的结构（由于我已经把它翻译成了Swift，我下面是用Swift版分析的，和原版的逻辑是一致的。）

        其中 DataPrenstenter 是我从 VVeboTableView 中抽离出来的，他其实就是读取数据的，你不用关心。

        以上这张图是 VVeboLabel 中所有的内容，高亮的那个方法是 VVeboLabel 的核心所在。

        这里属于Core Text技术，主要是对文本的特殊处理，采用了逐行绘制

        其余方法主要是对文本高亮和清除内容处理，不是重点，可以不关心。

        在 VVeboTableViewCell 中，高亮的方法为核心部分。其实同 VVeboLabel 的思想是一模一样的，就是将内容异步绘制在一张图上，然后显示出来，到达减少混合，以减小GPU压力。就不贴出源码，下面会放出Demo。

        这是一个设计很巧妙的类，在开始研究这个类的思路之前，我建议你看看这篇 文章 。当然如果你对 UIScrollView 足够熟悉，并且熟悉这个方法 func scrollViewWillEndDragging(_ scrollView: UIScrollView, withVelocity velocity: CGPoint, targetContentOffset: UnsafeMutablePointer<CGPoint>) ,那么对 VVeboTableView 的思路可以一目了然了。

        该方法从 iOS 5 引入，在 didEndDragging 前被调用，当 willEndDragging 方法中 velocity 为 CGPoin.zero （结束拖动时两个方向都没有速度）时， didEndDragging 中的 decelerate 为 false，即没有减速过程， willBeginDecelerating 和 didEndDecelerating 也就不会被调用。反之，当 velocity 不为 CGPoin.zero 时，scroll view 会以 velocity 为初速度，减速直到 targetContentOffset 。值得注意的是，这里的 targetContentOffset 是个指针，没错，你可以改变减速运动的目的地，这在一些效果的实现时十分有用。

        以上文字 来源

        微信读书的那种横滑居中效果，除了重写 UICollectionViewFlowLayout ，

        也通过控制targetContentOffset就可以实现

        图中高亮方法为核心部分

        cell绘制判断逻辑

        以上 VVeboTableViewDemo 源码已经全部解析完成了，那么你在惊叹作者巧妙思路的同时，肯定也很想知道这种技术的来源，和改进过程。(以下为个人猜想)

        通过本文，我觉得应该了解Core Text、Core Graphics、Hit-Test View、异步绘制这几项内容，你可以通过以下推荐的文章来掌握前三种技术，异步绘制在下一节YYAsyncLayer源码分析中，我相信你不知不觉就掌握了这项技术。

        最初来源

        这种技术的出现是为了减轻GPU的压力，因为图层的混合是GPU做的，而在这是CPU几乎是没事可做的，所以吧GPU的混合移到CPU的 func draw(_ rect: CGRect) 去完成需求。

        此技术的demo fastscrolling

        技术淘汰原因

        由于retina屏幕的出现,原来单位面积的像素增加，而CPU做的事情也变得多了起来，导致效率反而不及subViews方法。

        AsyncDisplayKit YYKit 等新技术出现

        我觉得VVeboTableViewDemo 的出现应该也是遵循以上过程的

        Core Text：

        Swift之CoreText排版神器

        官方文档

        Core Graphics：

        iOS绘图教程

        Swift之你应该懂点Core Graphics

        官方Demo

        官方Demo Swift版本

        Building Concurrent User Interfaces on iOS

        响应链

        iOS事件响应链中Hit-Test View的应用

        iOS 事件处理 | Hit-Testing

        异步绘制

        /ios-concurrency/

MyBatis-Plus代码生成器（3.5.1版本）

       MyBatis-Plus（简称 MP）是Mybatis的增强工具，在 MyBatis 的基础上只做增强不做改变，为简化开发、提高效率而生。

       特性：pom配置，依赖准备好后，创建Java类，在main()方法中：配置连接mysql数据库信息+调用自动生成API并设置各类参数，压力测试监控源码根据自定义策略，执行自动生成代码操作。这里新建一个MpGenerator.java，提供主方法main()。

       templateConfig我禁用了MP提供的模板，设置成了自己定义的。先看下MP自带的模板。

       包路径，一共支持三种引擎，Velocity对应vm后缀；Beetl对应btl后缀；Freemarker对应ftl后缀

       MP自带的模板service，controller等太简单，只是一个文件并没有提供增删改查功能，可以自己配置一个模板替换到自带的。就需要在templateConfig中配置一下。（自带的模板就不贴代码了，有兴趣的自己看一下）

       拿controller举例，贴一下我自己配置的。

       其实就是把增删改查的外壳设置好，把参数配置成动态的。$ 里面这些参数是哪里来的呢？接下来分析一下

       由于我用的是Velocity，看一下它的引擎源码

       一共4个方法，看名字大概分析一下，大概率是writer这个方法是主要功能，接下来断点看一下。

       模板中配置的动态参数，都是从objectMap取的。

       table数据格式，可以看到生成的entity，mapper，service，controller名称，fields取的数据库中字段信息。

       是否为主键，字段类型，名称等等。可以根据这些参数来配置我们需要的模板样式。

       如果objectMap中的参数不满足我们的要求，可以自己写一个引擎继承VelocityTemplateEngine重写他的writer方法。

       我把主键的信息单独取出来了，避免每次循环调用。

       自定义配置模板文件，根据MP提供的功能，可以生成entity，mapper，mapperXML，service，serviceImpl，controller。我们可能还需要用到BO，VO等，这时候就需要自定义配置模板了。

       模板的定义跟上面说的一样。

       简单记录一下自己使用过程的学习，大家有啥想法互相学习。

       各个参数详细说明： mybatis-plus代码生成器及配置 - BlogMemory - 博客园

请问谁会在fluent中用UDF编一个进口速度为抛物线或对数分布，麻烦了

       网页链接

       在圆管中，入口水流速通过以下公式描述：

       这个公式说明在壁面上速度为0，圆管中心线的速度为0.5m/s，而圆管入口面上的速度符合抛物线分布。

       下面的UDF就是把上述的抛物线分布的入口速度与Fluent求解器结合起来，从而可以在Fluent求解器中把入口速度指定为抛物线形。

       此例的C源代码如下：

       //