前前段时间，要开发一个小程序，需要选一个跨平台的框架，为此做了一些调研，在这里记录一下。

目前的跨平台方案大致是以下三种类型，各有优劣。

结合项目自身情况，我选择了第三种类型的框架，再结合支持多平台的要求，重点锁定在了Taro和uni-app之间。

Taro

开发者：

京东

优缺点：

Taro在App端使用的是React Native的渲染引擎，原生的UI体验较好，但据说在实时交互和高响应要求的操作方面不是很理想。

微信小程序方面，结合度感觉没有那么顺滑，有一些常见功能还是需要自己去封装。

另外就是开发环境难度稍高，需要自己去搭建iOS和Android的环境，对于想要一处开发到处应用的傻瓜式操作来讲，稍显繁琐。

但Taro 3的出现，支持了React 和 Vue两种DSL，适合的人群会更多一点，并且对快应用的支持也更好。

案例：

学习成本：

React、RN、小程序、XCode、Android Studio

uni-app

开发者：

DCloud

优缺点：

uni-app在App渲染方面，提供了原生渲染引擎和小程序引擎的双选方案，加上自身的一些技术优化（renderjs），对于高性能和响应要求的场景展现得更为流畅。

另外它整体的开发配套流程也做得很容易上手。比如有丰富的插件市场，使用简单，支持大量常用场景。

还比如它的定制IDE——HBuilder，提供了强大的整合能力。在用HBuilder之前，我心想：“还要多装一个编辑器麻烦，再好用能有VS Code好用？”用过之后：“真香！”

虽然用惯了VS Code对比起来还是有一些痛点没有解决，但是对于跨平台开发太友好了，其他缺点都可以忍受。HBuilder里支持直接跳转到微信开发者工具调试，支持真机实时预览，支持直接打包小程序和App，零门槛上手。

不过，uni-app也还是不够成熟，开发中也存在一些坑，需要不时到论坛社区去寻找答案。

代表产品：

学习成本：

Vue、小程序

总结

跨平台方案目前来看都不完善，适合以小程序、H5为主，原生APP（RN）为辅，不涉及太过复杂的交互的项目。

uni-app 开发简单，小项目效率高，入门容易debug难，不适合中大型项目。
Taro 3 开发流程稍微复杂一点，但复杂项目的支持度会稍好，未来可以打通React和Vue，已经开始支持RN了。

1. 不考虑原生RN的话二者差不多，考虑RN目前Taro3不支持，只能选uni-app；


2. 开发效率uni-app高，有自家的IDE（HBuilderX），编译调试打包一体化，对原生App开发体验友好；


3. 个人技术栈方面倾向于Taro/React，但项目角度uni-app/Vue比较短平快，社区活跃度也比较高。

背景：

每次前端更新，重新部署后，用户还停留在更新之前的页面，当请求页面数据时，会导致页面白屏，报错信息如下：

Uncaught ChunkLoadError: Loading chunk {n} failed.

原因

每次更新后，用户端的html文件中的 js 和 css 名称就和服务器上的不一致导致，导致加载失败。

解决方案

1.对error事件进行监听，检测到错误之后重新刷新

      window.addEventListener(

        'error',

        function (event) {

          if (

            event.message &&

            String(event.message).includes('Loading chunk') &&

            String(event.message).includes('failed')

          ) {

            window.location.replace(window.location.href);

          }

        },

        true,

      );

2.对window.console.error事件监听，效果同上

      window.console.error = function () {

        console.log(JSON.stringify(arguments), 'window.console.error'); // 自定义处理

      };

3.其他方案

如：HTTP2.0推送机制 / fis3 构建 /webSocket通知等，未尝试

注:有好的方案可以在下面评论讨论哈

本篇收录在个人工作记录专栏中，专门记录一些比较有意思的场景和问题。

后记

在之后的某一天，该问题再次暴露出来。源于一位同事在使用过程中，会不定页面的出现报错情况，报错如下：

很明显，还是资源加载问题，按道理讲应该可以走入我们逻辑进行刷新。但是当时用户反馈：刷新也不能解决问题，强制刷新才可以解决。

分析：刷新为什么不能解决问题？其实还是因为当用户第一次因为网络原因未成功加载到资源，后续刷新均走的缓存，因此让用户手动去刷新解决不了问题。

解决方案：

不知道大家发现没有，上面对error事件进行监听代码中，并没有包括css失败的情况，因此匹配上css加载失败的情况即可。

更新代码如下：

      window.addEventListener(

        'error',

        function (event) {

          if (

            event.message &&

            String(event.message).includes('chunk') &&

            String(event.message).includes('failed')

          ) {

            window.location.replace(window.location.href);

          }

        },

        true,

      );

可能有人会问，既然刷新解决不了问题，那window.location.replace(window.location.href)可以解决吗？

其实刷新的方法有很多，根据MDN的说法，Location.replace() 方法会以给定的URL替换当前的资源，因此可解决此问题。

完

平常我们在开发和维护项目的过程中，如果我们跑的项目有点大啊，或者数据太多，导致项目跑起来弊蜗牛还要慢，然后用户体验还不友好，对于新手程序员来说！老板天天都要你加班改！你还不敢辞职！这种时候，就很让人头痛了，怎么办！

但是！也不是没有办法的！骚年！你当时学vue的时候可不是这样说的！

接下来我来给你浓重介绍几个优化性能的小技巧，让你的项目蹭蹭蹭的飞起来！老板看了都直呼内行！

1.v-if和v-show的使用场景要区分

v-if 是条件渲染，当条件满足了，那肯定是渲染哇!如果你需要设置一个元素随时隐藏或者消失，然后用v-if是非常的浪费性能的，因为它不停的创建然后销毁。

但是它也是惰性的，如果你开始一给它条件为 false，它就害羞不出来了，跟你家女朋友一样天天晚上都不跟你回家，甚至你家里都没有你女朋友的衣物！然后结构页面里也不会渲染出来，查不到这个元素，不知情的朋友以为你谈了个虚拟女友，直到你让它条件为 true ，它才开始渲染，也就是拿了结婚证才跟你回家。

v-show 就很简单，他的原理就是利用 css 的 display 的属性，让他隐藏或者出现，所以一开始渲染页面哪怕我们看不到这个元素，但是它在文档的话，是确确实实存在的，只是因为 display：none； 隐藏了。

就像是你的打气女朋友，平常有人你肯定不敢打气哇！肯定是等夜深人静的时候，才偷偷打气，然后早上又继续放气藏起来，这样是不是很方便咧！所以这个元素你也就是你打气女朋友每天打气放气，是不是也没有那么费力咧！白天就可以藏起来快乐的上班啦！

好啦划重点啦！不要瞎鸡巴想什么女朋友了，女朋友只会影响我码项目的速度！

所以这样看来，如果是很少改变条件来渲染或者销毁的，建议是用 v-if ，如果是需要不断地切换，不断地隐藏又出现又隐藏这些场景的话， v-show 更适合使用！所以要在这些场景里合适的运用 v-if 和 v-show 会节省很多性能以达到性能优化。

2.v-if和v-for不能同时使用

当 v-if 与 v-for 一起使用时， v-for ****比 v-if 更高的优先级。这样就意味着 v-if 将分别重复运行于每一个 v-for 循中，那就是先运行 v-for 的循环，然后在每一个 v-for 的循环中，再进行 v-if 的条件对比，会造成性能浪费，影响项目的速度 。

如果按照下面的写法（我是用vue3写的），好家伙！直接不工作了，没有报错也没有页面，诡异的很

<template>

  <div id="app">

        <div v-for="item in list" v-if="list.flag" :key="item">{{item.color}}</div>

  </div>

</template>

<script>

export default {

  data(){

    return{

       list:[

            {

                color:"red",

                flag:true

            },

            {

                color:"green",

                flag:false

            },

            {

                color:"blue",

                flag:true

            },

        ],

    }

  }}

</script>

当你真的需要根据条件渲染页面的时候，建议是采用计算属性，这样及高效且美观，又不会出问题，如下面的代码展示

<template>

  <div id="app">

        <div v-for="item in newList" :key="item">{{item.color}}</div>

  </div>

</template>

<script>

export default {

  data(){

    return{

       list:[

            {

                color:"red",

                flag:true

            },

            {

                color:"green",

                flag:false

            },

            {

                color:"blue",

                flag:true

            },

        ],

    }

  },

  computed:{

    newList(){

      return this.list.filter(list => {

        return list.flag

      })

    }

  }

  }

</script>

3.computed和watch使用要区分场景

先看一下计算属性computed，它支持缓存，当依赖的数据发生变化的时候，才会重新计算，但是它并不支持异步操作，它无法监听数据变化。而且计算属性是基于响应式依赖进行缓存的。

再看一下侦听属性watch，它不支持缓存，它支持异步操作，当需要在数据变化时执行异步或开销较大的操作时，这个方式是最有用的。这是和computed最大的区别。

所以说，如果你的需求是写像购物车那种的，一个属性受其他属性影响的，用计算属性 computed 。 就像是你家的二哈，你不带它出去玩，你一回家就发现你家能拆的都被二哈拆掉了，因为你不带它出去跟你女朋友逛街！

如果是像写那种像模糊查询的，可以用侦听属性 watch ，因为可以一条数据影响多条数据。 比如你双12给你女朋友买了很多东西，那双十二之后，是不是很多机会回不去宿舍咧！

用好这两个，可以让你的代码更加高效，看起来也更加简洁优雅，让项目蹭蹭跑起来！这样都是一种优化性能的方式！

4.路由懒加载

当Vue项目是单页面应用的时候，可能会有很多路由引入 ，这样的话，使用 webpcak 打包后的文件会非常的大，当第一次进入首页的时候，加载的资源很多多，页面有时候会出现白屏的情况，对用户很不友好，体验也差。

但是，当我们把不同路由对应的组件分割成不同的代码块，然后当路由被访问的时候才加载对应的组件，这样就很高效了。会大大提升首屏加载显示的速度，但是可能其他的页面的速度就会降下来。有利有弊吧，根据自己业务需求来使用，实现效果也非常的简单，在 router 的 index.js 文件下，如下所示

import Home from '../views/Home'



const routes = [

 {

  path:'/home',

  name:"Home",				//这里没有用懒加载

  component:Home

 },

 {

path:'/about',

name:'About',

component:()=>import(/*webpackChunkName:"about"*/ '../views/About.vue')  //这里用了懒加载

 }

]

打开浏览器运行，当我没有点击进入 about 组件的时候包的大小就如蓝色框住的那些，当我点击了 about 组件进入后，就增加了后面红色圈住的包，总的大小是增加了

所以，使用路由懒加载可以降低首次加载的时候的性能消耗，但是后面打开这些组件可能会有所减慢，建议是如果体积不大的又不用马上展示的页面可以使用路由懒加载降低性能消耗，从而做到性能优化！

5.第三方插件按需引入

比如我们做一个项目，如果是全局引入第三方插件，打包构建的时候，会将别人整个插件包也一起打包进去，这样的话文件是非常庞大的，然后我们就需要将第三方插件按需引入，这个就需要自己去根据每个插件的官方文档在项目配置，始终就是一句话，用什么引什么！

6.优化列表的数据

当我们遇到哪些，一开始取的数据非常的庞大，然后还要渲染在页面上的时候，比如一下子给你传回来10w条数据还要渲染在页面上，项目一下子渲染出来是非常的有难度的。

这个时候，我们就 需要采用窗口化的技术来优化性能，只需要渲染少部分的内容（比如一下子拿多少条数据），这样就可以减少重新渲染组件和创建dom节点的时间。可以看看下面代码

<template>

  <div>

    <h3>列表的懒加载</h3>

    <div>

      <div v-for="item in list">

        <div>{{ item }}</div>

      </div>

    </div>

    <div>

      <div v-if="moreShowBoolen">滚动加载更多</div>

      <div v-else>已无更多</div>

    </div>

  </div>

</template>

<script>

export default {

  name: 'List',

  data() {

    return {

      list: [],

      moreShowBoolen: false,

      nowPage: 1,

      scrollHeight: 0,

    };

  },

  mounted() {

    this.init();

    // document.documentElement.scrollTop获取当前页面滚动条的位置,documentElement对应的是html标签,body对应的是body标签

    // document.compatMode用来判断当前浏览器采用的渲染方式,CSS1Compat表示标准兼容模式开启

    window.addEventListener("scroll", () => {

      let scrollY=document.documentElement.scrollTop || document.body.scrollTop; // 滚动条在Y轴上的滚动距离

      let vh=document.compatMode === "CSS1Compat"?document.documentElement.clientHeight:document.body.clientHeight; // 页面的可视高度

      let allHeight = Math.max(

        document.body.scrollHeight,

        document.documentElement.scrollHeight

      ); // 整个页面的高度

      if (scrollY + vh >= allHeight) {

        // 当滚动条滑到页面底部的时候触发这个函数继续添加数据

        this.init2();

      }

    });

  },

  methods: {

    init() {

      //一开始就往list添加数据

      for (let i = 0; i < 100; i++) {

        this.list.push(i);

      }

    },

    init2() {

      for (let i = 0; i < 200; i++) {

        // 当滑动到底部的时候，继续触发这个函数

        this.list.push(i);

      }

    },

  },

};

</script>

这样的话，就可以做到数据懒加载啦，根据需要，逐步添加数据进去，减少一次性拉取所有数据，因为数据是非常庞大的，这样就可以优化很多性能了！

分享一个自己封装的 axios 网络请求

主要的功能及其优点：

将所有的接口放在一个文件夹中管理（api.js）。并且可以支持动态接口，就是 api.js 文件中定义的接口可以使用 :xx 占位，根据需要动态的改变。动态接口用法模仿的是vue的动态路由，如果你不熟悉动态路由可以看看我的这篇文章：Vue路由传参详解（params 与 query）

1.封装请求：

0. 首先在 src 目录下创建 http 目录。继续在 http 目录中创建 api.js 文件与 index.js 文件。


1. 然后再 main.js 文件中导入 http 目录下的 index.js 文件。将请求注册为全局组件。


2. 将下面封装所需代码代码粘到对应的文件夹

2.基本使用：

//示例：获取用户列表

getUsers() {

  const { data } = await this.$http({

    url: 'users' //这里的 users 就是 api.js 中定义的“属性名”

  })

},

3.动态接口的使用：

//示例：删除用户

deleteUser() {

  const { data } = await this.$http({

    method: 'delete',

    //动态接口写法模仿的是vue的动态路由

    //这里 params 携带的是动态参数，其中 “属性名” 需要与 api 接口中的 :id 对应

    //也就是需要保证携带参数的 key 与 api 接口中的 :xx 一致

    url: {

      // 这里的 name 值就是 api.js 接口中的 “属性名”

      name: 'usersEdit',

      params: {

        id: userinfo.id,

      },

    },

  })

},

4.不足：

封装的请求只能这样使用 this.$http() 。不能 this.$http.get() 或 this.$http.delete()

由于我感觉使用 this.$http() 这种就够了，所以没做其他的封装处理

如果你有更好的想法可以随时联系我

如下是封装所需代码：

• api.js 管理所有的接口

// 如下接口地址根据自身项目定义

const API = {

  // base接口

  baseURL: 'http://127.0.0.1:8888/api/private/v1/',

  // 用户

  users: '/users',

  // “修改”与“删除”用户接口（动态接口）

  usersEdit: '/users/:id',

}



export default API

• index.js 逻辑代码

// 这里请求封装的主要逻辑，你可以分析并将他优化，如果有更好的封装方法欢迎联系我Q：2356924146

import axios from 'axios'

import API from './api.js'



const instance = axios.create({

  baseURL: API.baseURL,

  timeout: '8000',

  method: 'GET'

})



// 请求拦截器

instance.interceptors.request.use(

  config => {

    // 此处编写请求拦截代码，一般用于加载弹窗，或者每个请求都需要携带的token

    console.log('正在请求...')

    // 请求携带的token

    config.headers.Authorization = sessionStorage.getItem('token')

    return config

  },

  err => {

    console.log('请求失败', err)

  }

)



// 响应拦截器

instance.interceptors.response.use(

  res => {

    console.log('响应成功')

    //该返回对象会绑定到响应对象中

    return res

  },

  err => {

    console.log('响应失败', err)

  }

)



//options 接收 {method, url, params/data}

export default function(options = {}) {

  return instance({

    method: options.method,

    url: (function() {

      const URL = options.url



      if (typeof URL === 'object') {

        //拿到动态 url

        let DynamicURL = API[URL.name]



        //将 DynamicURL 中对应的 key 进行替换

        for (const key of Object.keys(URL.params)) {

          DynamicURL = DynamicURL.replace(':' + key, URL.params[key])

        }



        return DynamicURL

      } else {

        return API[URL]

      }

    })(),

    //获取查询字符串参数

    params: options.params,

    //获取请求体字符串参数

    data: options.data

  })

}

• main.js 将请求注册为全局组件

import Vue from 'vue'



// 会自动导入 http 目录中的 index.js 文件

import http from './http'



Vue.prototype.$http = http

AES 前后端加解密方案

背景

最近有一个需求：后端对敏感数据进行加密传输给前端，由前端解密后进行回显。在讨论之后，定下了AES加解密方案

概念

AES: 密码学中的高级加密标准（Advanced Encryption Standard，AES），又称Rijndael加密法，是美国联邦政府采用的一种区块加密标准，是最为常见的对称加密算法

密码说明

AES算法主要有四种操作处理，分别是：

1. 密钥轮加（Add Round Key）


2. 字节代换层（SubBytes）


3. 行位移层（Shift Rows）


4. 列混淆层（Mix Column）

主要是讲使用方案，所以这里不说太多废话了，对算法感兴趣的同学移步这里, 讲的非常详细，不过文章里的代码是使用C语言写的，为此找到了github上aes.js 的源码，感兴趣的同学移步这里

前端实现

现在简单说一下前端的实现：

我先找到了github上的源码，看了一下大概800行的样子。本来打算直接改吧改吧，封装成一个加解密的工具方法，直接扔在utils目录里的。本来也很成功的改好了，本地加解密试了一下，效果也很不错。根据github链接上的readme文档说明，封装了如下函数：

// 省略了改完的aes.js的代码。。。



// 加密 text 需要加密的文本 key 密钥

const toAESBytes = (text, key) => {

  const textBytes = aesjs.utils.utf8.toBytes(text);

  const aesCtr = new aesjs.ModeOfOperation.ctr(key, new aesjs.Counter(5));

  const encryptedBytes = aesCtr.encrypt(textBytes);

  const encryptedHex = aesjs.utils.hex.fromBytes(encryptedBytes);

  console.log('加密后的文本：', encryptedHex);

  return encryptedHex;

};



// 解密

const fromAESBytes = (text, key) => {

  const encryptedBytes = aesjs.utils.hex.toBytes(text);

  const aesCtr = new aesjs.ModeOfOperation.ctr(key, new aesjs.Counter(5));

  const decryptedBytes = aesCtr.decrypt(encryptedBytes);

  const decryptedText = aesjs.utils.utf8.fromBytes(decryptedBytes);

  console.log('解密后的文本：', decryptedText);

  return decryptedText;

}

但是这个方法在和后端对接的时候出现了一点偏差，死活也不能将后端加密后的数据成功解密。于是又向后端同学请教了一下，发现原因如下：

在AES加解密算法中，除了加解密的密文，也就是key需要一样之外，还有几样东西也非常重要：

• 
  

  AES 的算法模式需要保持一致

  
  

  关于算法模式，主要有以下几种：

  
  

    1. 电码本模式 Electronic Codebook Book (ECB)；
  
    2. 密码分组链接模式 Cipher Block Chaining (CBC)
  
    3. 计算器模式Counter (CTR)
  
    4. 密码反馈模式（Cipher FeedBack (CFB)
  
    5. 输出反馈模式Output FeedBack (OFB)
  

  
  

  这么看的话，我上面的demo应该使用的就是计算器模式了！关于算法模式的介绍，感兴趣的同学请移步这里

  
  


• 
  

  补码方式保持一致

  
  

  关于补码方式，我查到的以下几种：

  
  

    1. PKCS5Padding PKCS7Padding的子集，块大小固定为8字节
  
    2. PKCS7Padding 假设数据长度需要填充n(n>0)个字节才对齐，那么填充n个字节，每个字节都是n;如果数据本身就已经对齐了，则填充一块长度为块大小的数据，每个字节都是块大小。
  
    3. ZeroPadding 数据长度不对齐时使用0填充，否则不填充
  

  
  


• 
  

  密钥长度保持一致

  
  

  AES算法一共有三种密钥长度：128、192、256。这个前后端的密钥长度确实是保持一致的。

  
  


• 
  

  加密结果编码方式保持一致

  
  

  一般情况下，AES加密结果有两种编码方式：base64 和 16进制

  
  

所以到底是哪里出了问题呢？后端同学好心发给了我他后端的代码：

/**

 * aes 加密 Created by xingxiping on 2017/9/20.

 */

public class AesUtils {

    private static final String CIPHER_ALGORITHM = "AES"; // optional value AES/DES/DESede



    private AesUtils(){



    }

    /**

     * 加密

     *

     * @param content

     *            源内容

     * @param key

     *            加密密钥

     * @return

     */

    public static String encrypt(String content, String key) throws Exception {

        Cipher cipher = getCipher(key, Cipher.ENCRYPT_MODE);

        byte[] byteContent = content.getBytes(StandardCharsets.UTF_8);

        byte[] result = cipher.doFinal(byteContent);

        return Base64Utils.encode(result);

    }



    /**

     * 解密

     *

     * @param content

     *            内容

     * @param key

     *            解密密钥

     * @return

     */

    public static byte[] decrypt(String content, String key) throws Exception {

        Cipher cipher = getCipher(key, Cipher.DECRYPT_MODE);

        byte[] bytes = Base64Utils.decode(content);

        bytes = cipher.doFinal(bytes);

        return bytes;

    }



    private static Cipher getCipher(String key, int cipherMode) throws NoSuchAlgorithmException, NoSuchPaddingException, InvalidKeyException {

        Cipher cipher = Cipher.getInstance(CIPHER_ALGORITHM);

        SecretKeySpec secretKey = new SecretKeySpec(key.getBytes(), "AES");

        cipher.init(cipherMode, secretKey);

        return cipher;

    }

}

破案了，后端老哥对加密后的结果进行了base64编码，然后我又仔细去看了一下aes.js源码，根本没有找到base64的影子啊！

于是在查找一翻资料以后，决定使用crypto-j,使用 Crypto-JS 可以非常方便地在 JavaScript 进行 MD5、SHA1、SHA2、SHA3、RIPEMD-160 哈希散列，进行 AES、DES、Rabbit、RC4、Triple DES 加解密。真是方便呀，老规矩，感兴趣的同学可以移步这里

以下是我又一轮的解决步骤：

1. 
   

   npm install crypto-js

   
   


2. 
   

   在utils目录下新建一个文件aes.js

   
   


3. 
   

   封装如下代码：

   
   

   // aes 解密
   
   import CryptoJS from 'crypto-js';
   
   
   
   // 解密 encryptedStr待解密字符串 pass 密文
   
   export const aesDecode = (encryptedStr, pass) => {
   
     const key = CryptoJS.enc.Utf8.parse(pass); // 通过密钥获取128位的key
   
     const encryptedHexStr = CryptoJS.enc.Base64.parse(encryptedStr); // 解码base64编码结果
   
     const encryptedBase64Str = CryptoJS.enc.Base64.stringify(encryptedHexStr);
   
     const decryptedData = CryptoJS.AES.decrypt(encryptedBase64Str, key, {
   
       mode: CryptoJS.mode.ECB,
   
       padding: CryptoJS.pad.Pkcs7
   
     });
   
     return decryptedData.toString(CryptoJS.enc.Utf8);
   
   }
   

   
   


4. 
   

   然后就可以正常调用了！

   
   

最后，终于成功解密！

一点点小感悟

在日常工作中真的很少使用算法，对称加密在学校里听起来好像非常简单的样子，但是真的应用到生活中，特别是安全领域，还是非常复杂的。哎，学无止境吧～

感谢大家的阅读！

ThreadLocal是什么？

试想以下情况：

在多线程的情况下，对一同一个变量操作可能会出现冲突，解决的办法就是对这个变量加锁。但是我们有时候其实就是想要一个全局变量，不想让多个线程去干扰。那么能不能有一个变量，名字相同，但是多个线程操作的时候又不会相互影响呢？

从另外一个角度来说，对于一个变量，在一个线程的任何一个地方都可能需要用到，但是通过传参的方式又比较麻烦，有没有一个变量是贯穿整个线程，我们想取就能取到的呢。

ThreadLocal就是这么一个变量，那么这个变量是怎么实现的呢？

ThreadLocal源码分析

ThreadLocal github地址

首先看用法

public class Client {

    private static final ThreadLocal<String> myThreadLocal = ThreadLocal.withInitial(() -> "This is the initial value");



    public static void main(String[] args) {



        for (int i = 0; i < 6; i++){

            new Thread(new MyRunnable(), "线程"+i).start();

        }



    }



    public static class MyRunnable implements Runnable {



        @Override

        public void run() {

            String name = Thread.currentThread().getName();

            System.out.println(name + "的threadLocal"+ ",设置为" + name);

            myThreadLocal.set(name);

            try {

                Thread.sleep(1000);

            } catch (InterruptedException ignored) {}

            System.out.println(name + ":" + myThreadLocal.get());

        }



    }

}



------

  

线程0的threadLocal,设置为线程0

线程3的threadLocal,设置为线程3

线程4的threadLocal,设置为线程4

线程2的threadLocal,设置为线程2

线程1的threadLocal,设置为线程1

线程5的threadLocal,设置为线程5

线程0:线程0

线程4:线程4

线程5:线程5

线程2:线程2

线程1:线程1

线程3:线程3

例子中有六个线程，myThreadLocal里存的都是自己线程独有的变量。这样就实现了变量的线程隔离，而且如果不向传参数，在另外一个函数里直接就能get到这个变量，这对于很多场景下都非常有用。

我们下面来分析一下源码：

1. 首先每一个Thread，都有一个ThreadLocalMap，变量名字叫做threadLocas，里面保存的是多个ThreadLocal，所以每一个线程才能保存属于自己线程的值。


2. ThreadLocal封装了getMap()、Set()、Get()、Remove()4个核心方法。主要是对ThreadLocalMap来进行操作。


3. ThreadLocalMap是一个ThreadLocal的内部类，它实现了一个自定义的Map，ThreadLocalMap中的Entry[]数组存储数据。


4. Entry的键是threadLocal变量本身，值就是设置的变量的值。Entry的key是对ThreadLocal的弱引用，当ThreadLocal不再有强引用的时候，就会清理掉这个key，防止内存泄漏（然而并不能，后面会说）

get方法

public T get() {

        Thread t = Thread.currentThread();

        ThreadLocalMap map = getMap(t);

        if (map != null) {

            ThreadLocalMap.Entry e = map.getEntry(this);

            if (e != null) {

                @SuppressWarnings("unchecked")

                T result = (T)e.value;

                return result;

            }

        }

        return setInitialValue();

}



 ThreadLocalMap getMap(Thread t) {

        return t.threadLocals;

}

1. 获取当前的Thread对象，通过getMap获取Thread内的ThreadLocalMap，ThreadLocalMap的定义如下：ThreadLocal.ThreadLocalMap threadLocals = null;


2. 如果map已经存在，以当前的ThreadLocal为键，获取Entry对象，并从从Entry中取出值


3. 否则，调用setInitialValue进行初始化。

setInitialValue

private T setInitialValue() {

    T value = initialValue();

    Thread t = Thread.currentThread();

    ThreadLocalMap map = getMap(t);

    if (map != null)

        map.set(this, value);

    else

        createMap(t, value);

    return value;

}

1. 首先是调用initialValue生成一个初始的value值，深入initialValue函数，我们可知它就是返回一个null；


2. 然后还是在get以下Map，如果map存在，则直接map.set,这个函数会放在后文说；


3. 如果不存在则会调用createMap创建ThreadLocalMap，这里正好可以先说明下ThreadLocalMap了。

ThreadLocalMap

createMap

void createMap(Thread t, T firstValue) {

    t.threadLocals = new ThreadLocalMap(this, firstValue);

}

static class ThreadLocalMap {

    static class Entry extends WeakReference<ThreadLocal<?>> {

        Object value;

        Entry(ThreadLocal<?> k, Object v) {

            super(k);

            value = v;

    	}

	}

    private static final int INITIAL_CAPACITY = 16;



    private Entry[] table;



    private int size = 0;



    private int threshold; // Default to 0



    private void setThreshold(int len) {

        threshold = len * 2 / 3;

    }



    private static int nextIndex(int i, int len) {

        return ((i + 1 < len) ? i + 1 : 0);

    }



    private static int prevIndex(int i, int len) {

        return ((i - 1 >= 0) ? i - 1 : len - 1);

    }

	...

}

1. 首先是Entry的定义，前面已经说过；


2. 初始的容量为INITIAL_CAPACITY = 16；


3. 主要数据结构就是一个Entry的数组table；


4. size用于记录Map中实际存在的entry个数；


5. threshold是扩容上限，当size到达threashold时，需要resize整个Map，threshold的初始值为len * 2 / 3；


6. nextIndex和prevIndex则是为了安全的移动索引，后面的函数里经常用到。

map.getEntry

private Entry getEntry(ThreadLocal<?> key) {

    int i = key.threadLocalHashCode & (table.length - 1);

    Entry e = table[i];

    if (e != null && e.get() == key)

        return e;

    else

        return getEntryAfterMiss(key, i, e);

}

1. 计算索引位置


2. 获取Entry，如果Entry存在，且key和threadLocal相等，那么返回


3. 否则，调用getEntryAfterMiss。

getEntryAfterMiss

private Entry getEntryAfterMiss(ThreadLocal<?> key, int i, Entry e) {

    Entry[] tab = table;

    int len = tab.length;



    while (e != null) {

        ThreadLocal<?> k = e.get();

        if (k == key)

            return e;

        if (k == null)

            expungeStaleEntry(i);

        else

            i = nextIndex(i, len);

        e = tab[i];

    }

    return null;

}

1. 如果k==key,那么代表找到了这个所需要的Entry，直接返回；


2. 如果k==null，那么证明这个Entry中key已经为null,那么这个Entry就是一个过期对象，这里调用expungeStaleEntry清理该Entry。

为什么会需要清理呢？

如果说ThreadLocal变量被人为的置为null了，ThreadLocal对象只有一个弱引用指着，就会被GC，Entry的key没有了，value可能会内存泄漏。ThreadLocal在每一个get，set的时候都会清理这种过期的key。

为什么需要循环查找key?

这是一种解决hash冲突的手段，这里用的是开放地址法，既有冲突之后，把要插入的元素放在要插入的位置后面为null的地方。HashMap则采用的是链地址法。

expungeStaleEntry

private int expungeStaleEntry(int staleSlot) {

    Entry[] tab = table;

    int len = tab.length;



    // expunge entry at staleSlot

    tab[staleSlot].value = null;

    tab[staleSlot] = null;

    size--;



    // Rehash until we encounter null

    Entry e;

    int i;

    for (i = nextIndex(staleSlot, len);

         (e = tab[i]) != null;

         i = nextIndex(i, len)) {

        ThreadLocal<?> k = e.get();

        if (k == null) {

            e.value = null;

            tab[i] = null;

            size--;

        } else {

            int h = k.threadLocalHashCode & (len - 1);

            if (h != i) {

                tab[i] = null;



                // Unlike Knuth 6.4 Algorithm R, we must scan until

                // null because multiple entries could have been stale.

                while (tab[h] != null)

                    h = nextIndex(h, len);

                tab[h] = e;

            }

        }

    }

    return i;

}

1. expunge entry at staleSlot：这段主要是将i位置上的Entry的value设为null，Entry的引用也设为null，那么系统GC的时候自然会清理掉这块内存；


2. Rehash until we encounter null: 这段就是扫描位置staleSlot之后，null之前的Entry数组，清除每一个key为null的Entry，同时若是key不为空，做rehash，调整其位置。

这里rehash的作用是什么？

我们清理的过程中会把某个值设置为null，如果之前这个值后面的区域是和前两连起来的，那么下次循环查找的时候，就会只查到null为止。比如三个hash值碰撞的key，中间的那个被删除了，那么第三个key在查找的时候会从第一个开始查找，查找到第二个就停止了，第三个就查不到了。

set

public void set(T value) {

    Thread t = Thread.currentThread();

    ThreadLocalMap map = getMap(t);

    if (map != null)

        map.set(this, value);

    else

        createMap(t, value);

}

map.set

private void set(ThreadLocal<?> key, Object value) {

    Entry[] tab = table;

    int len = tab.length;

    int i = key.threadLocalHashCode & (len-1);

  

    for (Entry e = tab[i];

         e != null;

         e = tab[i = nextIndex(i, len)]) {

        ThreadLocal<?> k = e.get();

  

        if (k == key) {

            e.value = value;

            return;

        }

  

        if (k == null) {

            replaceStaleEntry(key, value, i);

            return;

        }

    }



    tab[i] = new Entry(key, value);

    int sz = ++size;

    if (!cleanSomeSlots(i, sz) && sz >= threshold)

        rehash();

}

1. 首先还是根据key计算出位置i，然后查找i位置上的Entry，


2. 若是Entry已经存在并且key等于传入的key，那么这时候直接给这个Entry赋新的value值。


3. 若是Entry存在，但是key为null，则调用replaceStaleEntry来更换这个key为空的Entry


4. 不断循环检测，直到遇到为null的地方，这时候要是还没在循环过程中return，那么就在这个null的位置新建一个Entry，并且插入，同时size增加1。


5. 最后调用cleanSomeSlots，这个函数就不细说了，你只要知道内部还是调用了上面提到的expungeStaleEntry函数清理key为null的Entry就行了，最后返回是否清理了Entry，接下来再判断sz>thresgold,这里就是判断是否达到了rehash的条件，达到的话就会调用rehash函数。

rehash

private void rehash() {

    expungeStaleEntries();



    // Use lower threshold for doubling to avoid hysteresis

    if (size >= threshold - threshold / 4)

        resize();

}





private void resize() {

    Entry[] oldTab = table;

    int oldLen = oldTab.length;

    int newLen = oldLen * 2;

    Entry[] newTab = new Entry[newLen];

    int count = 0;



    for (int j = 0; j < oldLen; ++j) {

        Entry e = oldTab[j];

        if (e != null) {

            ThreadLocal<?> k = e.get();

            if (k == null) {

                e.value = null; // Help the GC

            } else {

                int h = k.threadLocalHashCode & (newLen - 1);

                while (newTab[h] != null)

                    h = nextIndex(h, newLen);

                newTab[h] = e;

                count++;

            }

        }

    }



    setThreshold(newLen);

    size = count;

    table = newTab;

}

1. 首先，size大于threshold的时候才会rehash。


2. 清理空key，如果size大于3/4的threshold，调用resize()函数。


3. 每次扩容大小扩展为原来的2倍，然后再一个for循环里，清除空key的Entry，同时重新计算key不为空的Entry的hash值，把它们放到正确的位置上，再更新ThreadLocalMap的所有属性。

remove

private void remove(ThreadLocal<?> key) {

    Entry[] tab = table;

    int len = tab.length;

    int i = key.threadLocalHashCode & (len-1);

    for (Entry e = tab[i];

         e != null;

         e = tab[i = nextIndex(i, len)]) {

         if (e.get() == key) {

            e.clear();

            expungeStaleEntry(i);

            return;

        }

    }

}

先计算出hash值，若是第一次没有命中，就循环直到null，在此过程中也会调用expungeStaleEntry清除空key节点。

什么是内存泄漏？

当程序分配了空间但是却忘了回收导致以后的程序都无法或暂时无法使用这块空间，就发生了内存泄漏。和内存溢出不一样，内存溢出是内存不足的时候出现的。这块要理解清楚，才能明白ThreadLocal为什么会导致内存泄漏。

Java 引用类型

要说到ThreadLocal引起内存泄漏，还得从java的四种引用类型说起。

java中有四种引用类型，分别是强软弱虚。

强引用

一个对象被强引用，那么他就不会被回收。

软引用

如果一个对象只具有软引用，那么它的性质属于可有可无的那种。如果此时内存空间足够，垃圾回收器就不会回收它，如果内存空间不足了，就会回收这些对象的内存。只要垃圾回收器没有回收它，该对象就可以被程序使用。

软引用可以和一个引用队列联合使用，如果软件用所引用的对象被垃圾回收，Java虚拟机就会把这个软引用加入到与之关联的引用队列中。

    Object obj = new Object();

    ReferenceQueue queue = new ReferenceQueue();

    SoftReference reference = new SoftReference(obj, queue);

    //强引用对象滞空，保留软引用

    obj = null;

当内存不足时，软引用对象被回收时，reference.get()为null，此时软引用对象的作用已经发挥完毕，这时将其添加进ReferenceQueue 队列中

如果要判断哪些软引用对象已经被清理：

    SoftReference ref = null;

    while ((ref = (SoftReference) queue.poll()) != null) {

        //清除软引用对象

    }

弱引用

弱引用和软引用的区别就是，如果一个对象只有弱引用，那么只要GC，不管内存够不够，都会回收他的内存。注意这里的”只有弱引用“。如果这个对象还被其他变量强引用，那么他是不会被回收的。

虚引用

如果一个对象与虚引用关联，则跟没有引用与之关联一样，在任何时候都可能被垃圾回收器回收。虚引用主要用来跟踪对象被垃圾回收的活动。

为什么要有四种引用类型？

1. 可以让程序员通过代码的方式来决定某个对象的生命周期。


2. 有利于垃圾回收


3. 能够实现一些复杂的数据结构。

ThreadLocal什么情况下会出现内存泄漏？

threadlocal里面使用了一个存在弱引用的map,当释放掉threadlocal的强引用以后,map里面的value却没有被回收.而这块value永远不会被访问到了. 所以存在着内存泄露。

如果这个时候还会去调用get set方法，那么这块内存可能会被清理掉。

如果没有去调用get set方法，如果这个线程很快销毁了，那么也不会内存泄漏。

最坏的情况就是，threadLocal对象设置成null了，然后使用线程池，这个线程被重复使用了，但是有一直没有调用get set方法，这个期间就会发生真正的内存泄漏。

其实ThreadLocal发生内存泄露的条件还是比较苛刻的，只要是使用规范，那么就没有什么问题。

ThreadLocal最佳实践

1. 每次使用完手动调用remove函数，删除不再使用的ThreadLocal.


2. 可以将ThreadLocal设置成private static的，这样ThreadLocal会尽量和线程本身一起消亡。

ThreadLocal应用案例

管理数据库连接。

  假如A类的方法a中，会调用B类的方法b和C类的方法c，a方法开启了事务，b方法和c方法会去操作数据库。我们知道，要想实现事务，那么b方法和c方法中所使用的的数据库连接一定是同一个连接，那怎么才能实现所用的是同一个数据库连接呢？答案就是通过ThreadLocal来管理。

MDC日志链路追踪。

MDC（Mapped Diagnostic Contexts）主要用于保存每次请求的上下文参数，同时可以在日志输出的格式中直接使用 %X{key} 的方式，将上下文中的参数输出至每一行日志中。而保存上下文信息主要就是通过ThreadLocal来实现的。
假如在交易流程每个环节的日志中，你都想打印全局流水号transId，流程可能涉及多个系统、多个线程、多个方法。有一些环节中，全局流水号并不能当做参数传递，那你怎么才能获取这个transId参数呢，这里就是利用了Threadlocal特性。每个系统或者线程在接收到请求时，都会将transId存放到ThreadLocal中，在输出日志时，将transId获取出来，进行打印。这样，我们就可以通过transId，在日志文件中查询全链路的日志信息了。

InheritableThreadLocal

使用ThreadLocal时，子线程获取不到父线程通过set方法保存的数据，要想使子线程也可以获取到，可以使用InheritableThreadLocal类。

RPC调用时使用 @Validated进行参数校验不起作用

球球了，RPC之间调用别再使用 if-else做参数校验了。众所周知，@Validated 是一款非常好用的参数校验工具。但在RPC调用时不可用，在当前的微服务大环境下，微服务之间的调用怎么做到优雅的参数校验呢？

话不多说，直接上干货

引包

<dependency>

    <groupId>org.springframework.boot</groupId>

    <artifactId>spring-boot-starter-validation</artifactId>

</dependency>

1. 参数校验 这里我们先要定义一个注解来代替来继承 @Validated

import org.springframework.validation.annotation.Validated;



@Validated

public @interface RPCValidated {

}

2. 然后使用AOP来解析参数，进行参数校验。

import lombok.extern.slf4j.Slf4j;

import org.aspectj.lang.ProceedingJoinPoint;

import org.aspectj.lang.annotation.Around;

import org.aspectj.lang.annotation.Aspect;

import org.aspectj.lang.reflect.MethodSignature;

import org.hibernate.validator.messageinterpolation.ResourceBundleMessageInterpolator;

import org.hibernate.validator.resourceloading.PlatformResourceBundleLocator;

import org.springframework.stereotype.Component;

import wangjubao.base.common.extend.Response;



import javax.validation.ConstraintViolation;

import javax.validation.Validation;

import javax.validation.Validator;

import java.util.ArrayList;

import java.util.List;

import java.util.Set;



@Aspect

@Component

@Slf4j

public class ValidatedAop {

    private static Validator validator;



    static {

        validator = Validation.byDefaultProvider().configure()

                .messageInterpolator(new ResourceBundleMessageInterpolator(

                        new PlatformResourceBundleLocator("validationMessages")))

                .buildValidatorFactory().getValidator();

    }



    @Around("@annotation(com.qiaoba.annotation.RPCValidated))")

    public Object around(ProceedingJoinPoint joinPoint) {

        Object[] args = joinPoint.getArgs();

        MethodSignature signature = (MethodSignature) joinPoint.getSignature();

        // 执行方法参数的校验

        Set<ConstraintViolation<Object>> constraintViolations = validator.forExecutables().validateParameters(joinPoint.getThis(), signature.getMethod(), args);

        List<String> messages = new ArrayList<>();

        for (ConstraintViolation<Object> error : constraintViolations) {

            messages.add(error.getMessage());

        }

        if (!messages.isEmpty()) {

            return Response.paramError("参数错误:", messages.get(0));

        }

        try {

            return joinPoint.proceed(args);

        } catch (Throwable e) {

            e.printStackTrace();

            return Response.error("操作失败:", e.getMessage());

        }

    }

}

3. 使用方法,在接口Impl实现类加上定义的@RPCValidated

@Override

@RPCValidated

public Response create(MessageSmsRechargeDto dto) {

    //todo：业务逻辑......

}

4. 在Interfaces接口层加上@Valid注解

Response create(@Valid MessageSmsRechargeDto params);

5. 实体类

@Data

public class MessageSmsRechargeDto implements Serializable {





    /**

     * 充值公司

     */

    @NotNull(message = "充值公司不能为空 ")

    private Long companyId;



    /**

     * 充值备注

     */

    @NotEmpty(message = "充值备注不能为空 ")

    private String rechargeRemark;

 }

--- 至此，整个流程完成，加上自定义的参数校验注解@RPCValidated后，就可以优雅的进行参数校验，不用再写各种if-else 做参数校验了

组件库可参考：flutter.dev、bruno(贝壳开源组件库)

以下从部分GetX文档转载 用于记录。
框架： Flutter GetX

GetX 是 Flutter 上的一个轻量且强大的解决方案：高性能的状态管理、智能的依赖注入和便捷的路由管理。

GetX 有3个基本原则：

性能： GetX 专注于性能和最小资源消耗。GetX 打包后的apk占用大小和运行时的内存占用与其他状态管理插件不相上下。效率： GetX 的语法非常简捷，并保持了极高的性能，能极大缩短你的开发时长。 结构： GetX 可以将界面、逻辑、依赖和路由完全解耦，用起来更清爽，逻辑更清晰，代码更容易维护。 GetX 并不臃肿，却很轻量。

三大功能

状态管理

目前，Flutter有几种状态管理器。但是，它们中的大多数都涉及到使用ChangeNotifier来更新widget，这对于中大型应用的性能来说是一个很糟糕的方法。你可以在Flutter的官方文档中查看到，ChangeNotifier应该使用1个或最多2个监听器，这使得它们实际上无法用于任何中等或大型应用。

Get 并不是比任何其他状态管理器更好或更差，而是说你应该分析这些要点以及下面的要点来选择只用Get，还是与其他状态管理器结合使用。

Get不是其他状态管理器的敌人，因为Get是一个微框架，而不仅仅是一个状态管理器，既可以单独使用，也可以与其他状态管理器结合使用。

Get有两个不同的状态管理器：简单的状态管理器（GetBuilder）和响应式状态管理器（GetX）。

响应式状态管理器

响应式编程可能会让很多人感到陌生，因为觉得它很复杂，但是GetX将响应式编程变得非常简单。

• 你不需要创建StreamControllers.


• 你不需要为每个变量创建一个StreamBuilder。


• 你不需要为每个状态创建一个类。


• 你不需要为一个初始值创建一个get。

使用 Get 的响应式编程就像使用 setState 一样简单。

让我们想象一下，你有一个名称变量，并且希望每次你改变它时，所有使用它的小组件都会自动刷新。

这就是你的计数变量。

var name = 'Jonatas Borges';

要想让它变得可观察，你只需要在它的末尾加上".obs"。

var name = 'Jonatas Borges'.obs;

而在UI中，当你想显示该值并在值变化时更新页面，只需这样做。

Obx(() => Text("${controller.name}"));

这就是全部，就这么简单。

关于状态管理的更多细节

关于状态管理更深入的解释请查看这里。在那里你将看到更多的例子，以及简单的状态管理器和响应式状态管理器之间的区别。

你会对GetX的能力有一个很好的了解。

路由管理

如果你想免上下文（context）使用路由/snackbars/dialogs/bottomsheets，GetX对你来说也是极好的，来吧展示：

在你的MaterialApp前加上 "Get"，把它变成GetMaterialApp。

GetMaterialApp( // Before: MaterialApp(

  home: MyHome(),

)

导航到新页面

Get.to(NextScreen());

用别名导航到新页面。查看更多关于命名路由的详细信息这里

Get.toNamed('/details');

要关闭snackbars, dialogs, bottomsheets或任何你通常会用Navigator.pop(context)关闭的东西。

Get.back();

进入下一个页面，但没有返回上一个页面的选项（用于闪屏页，登录页面等）。

Get.off(NextScreen());

进入下一个页面并取消之前的所有路由（在购物车、投票和测试中很有用）。

Get.offAll(NextScreen());

注意到你不需要使用context来做这些事情吗？这就是使用Get路由管理的最大优势之一。有了它，你可以在你的控制器类中执行所有这些方法，而不用担心context在哪里。

关于路由管理的更多细节

关于别名路由，和对路由的低级控制，请看这里。

依赖管理

Get有一个简单而强大的依赖管理器，它允许你只用1行代码就能检索到与你的Bloc或Controller相同的类，无需Provider context，无需inheritedWidget。

Controller controller = Get.put(Controller()); // 而不是 Controller controller = Controller();

• 注意：如果你使用的是Get的状态管理器，请多注意绑定api，这将使你的界面更容易连接到你的控制器。

你是在Get实例中实例化它，而不是在你使用的类中实例化你的类，这将使它在整个App中可用。 所以你可以正常使用你的控制器（或类Bloc）。

提示：  Get依赖管理与包的其他部分是解耦的，所以如果你的应用已经使用了一个状态管理器（任何一个，都没关系），你不需要全部重写，你可以使用这个依赖注入。

controller.fetchApi();

想象一下，你已经浏览了无数条路由，现在你需要拿到一个被遗留在控制器中的数据，那你需要一个状态管理器与Provider或Get_it一起使用来拿到它，对吗？用Get则不然，Get会自动为你的控制器找到你想要的数据，而你甚至不需要任何额外的依赖关系。

Controller controller = Get.find();

//是的，它看起来像魔术，Get会找到你的控制器，并将其提供给你。你可以实例化100万个控制器，Get总会给你正确的控制器。

然后你就可以恢复你在后面获得的控制器数据。

Text(controller.textFromApi);

「这是我参与11月更文挑战的第4天，活动详情查看：2021最后一次更文挑战」

在iOS开发中，如果能够对一些稳定的组件能够二进制化，那么将大大的缩减我们在开发过程中的编译时间。在基于Cocaopods工程，快速实现Swift组件二进制一文中，我们讲述了，借助Pods工程和Shell脚本，一步实现二进制打包，但需要我们手动更改podspec文件，采用这种方式，如果作为依赖项加入到其他工程中，还会出现二进制和源码共存的情况，今天介绍一个cocoapods插件 cocoapods-binary，可以实现组件预编译，该工程已经两年多没维护了，随着pods更新，有了一些小bug。基于源码，我对该插件做了几点更改，又可以开心的玩耍了.在了解该插件之前，我们先大概了解下，输入pod install之后发生了什么？

Pod install

如果你想调试cocoapods工程，可以查看之前的文章Ruby和Cocoapods文章合集 。

一图胜千言，当输入Pod install后

• 1，首先校验是否有Podfile文件，并解析为Podfile对象


• 2，准备阶段，安装插件，调用pre_install阶段的插件


• 3，解析依赖，通过 当前的Podfile文件 和 上一次的Pofile.Lock,Manifest.Lock文件进行比对，确认哪些文件需要更新。


• 4，下载依赖，更新需要更改的文件，并执行Podfile里面定义的pre_installhook函数。


• 5，集成阶段，生成新的Pods.xcodeproj工程文件，并执行Podfile里面的post_installhook函数。


• 6，写入新的Lockfile信息。


• 7，执行 post_install阶段的插件，并输出安装信息。

cocoapods-binary是以插件的形式，在Pod工程的pre_install阶段进行预编译的，

cocoapods-binary工作流

pre_install 插件

在 cocoapods-binary中的，通过HookManager来注册插件的执行时机

Pod::HooksManager.register('cocoapods-binary', :pre_install) do |installer_context|



end

主流程

主要流程如下图所示

• 1，必须使用framework的形式，也就是use_frameworks。


• 2，在Pods文件夹下，创建一个名为_Prebuild的文件夹，作为预编译沙箱。


• 3，在当前环境下，读取Podfile文件，并创建Podfile对象。


• 4，读取Podflie.lock文件，创建 Lockfile对象。


• 5，创建预编译安装器，沙箱地址为 预编译沙箱。


• 6，对比Podfile和 Podfile.lock，得到已更改的pod_name。


• 7，使用预编译安装器将 pod_name的源代码下载到预编译沙箱中，并生成新的Pods.xcodeproj文件。开始编译需要更新的framework。


• 8，回到主工程，继续执行 pod install的后续流程，在这一步修该需要二进制文件的podspec文件。

解析自定义参数

在插件中，有两个自定义的参数 :binary和all_binary!，是通过自定义DSL来实现的，有对这一块不熟悉的，可以参考我的这篇文章Cocoapods之 Podfile文件。

创建Podfile对象时，通过 method swizzling来hook:parse_inhibit_warnings方法，拿到我们在Podfile文件中写入的配置选项。将需要预编译的pod，保存到数组中。

old_method = instance_method(:parse_inhibit_warnings)

define_method(:parse_inhibit_warnings) do |name, requirements|

    variables = requirements

    parse_prebuild_framework(name, requirements)

    old_method.bind(self).(name, variables)

end

复制代码

在Ruby中，Method Swizzling主要分为三步：

• 1，获取parse_inhibit_warnings实例方法。


• 2，定义一个相同名字的方法。


• 3，调用原来的方法。

对比Lockfile

在这里 Podfle.lock和预编译沙箱中Manifest.lock是一样的，通过对比可以一个Hash对象

<Pod::Installer::Analyzer::SpecsState:0x00007f83370c61a8 @added=#<Set: {}>, @deleted=#<Set: {}>, @changed=#<Set: {}>, @unchanged=#<Set: {"Alamofire", "SnapKit"}>>

可以很清楚的知道哪些pod库发生了更改。如果有改动，则就在预编译沙箱进行install。

binary_installer.install!

在这一阶段，主要是在预编译沙箱中拉取framework源码和修改Pods.xcodeproj文件，在 Manifest.lock成功写入预编译沙箱，通过hook run_plugins_post_install_hooks函数，在预编译沙箱中，使用 xcodebuild命令，编译每一个需要更新的pod_target，并将编译好的framework放至GeneratedFrameworks目录下。

回到主工程执行pod install

编译完成后，就回到了主工程里面的 Pod install流程中。对:resolve_dependencies方法进行Method Swizzling，对需要更改的pod_target进行修改。通过修改内存中的Pod::Specification对象的vendored_frameworks、source_files、resource_bundles和resources属性，来引用已经编译好的framework。

工作流总结

通过对每一个阶段的了解，我们了解了作者的思路是这样的：
1，先将源码和Pods.project安装到预编译沙箱中 。
2，借助于Pods.project工程，使用xcodebuild编译需要预编译的scheme。
3，巧妙的利用Method Swizzling，在分析依赖阶段，修改Pod::Specification对象，完成二进制的引用等工作。

现有问题

1，:binary => true 无效

在 ruby 2.6.8p205 (2021-07-07 revision 67951) [universal.x86_64-darwin21]版本中，使用:binary => true无效，无法编译为framework。在D ebug模式下生效，在发布后就失效了。

def set_prebuild_for_pod(pod_name, should_prebuild)

    Pod::UI.puts("pod_name: #{pod_name} prebuild:#{should_prebuild}")

    if should_prebuild == true

        @prebuild_framework_pod_names ||= []

        @prebuild_framework_pod_names.push pod_name

    else 

        @should_not_prebuild_framework_pod_names ||= []

        @should_not_prebuild_framework_pod_names.push pod_name

    end

end

在ruby 2.6.8中,release模式下，执行了两次，参数还不一致，导致 @prebuild_framework_pod_names和@should_not_prebuild_framework_pod_names相等，最终需要预编译的数组为[]

pod_name: SnapKit, should_prebuild:true

pod_name: SnapKit, should_prebuild:

2，pod update没有及时更新最新的framework

在frameworkA依赖frameworkB，在 Podfile中，只引入了 frameworkA

target xxx do 

    pod "frameworkA", :binary => true

end

当 frameworkB有新版本时，没有更新最新的frameworkB，对于我们自己的组件，我们期望有新版本发布时，能及时更新。

解决办法：
在检测更新的方法中，读取最新的Manifest.lock文件，读取已编译的framework的plist文件，比较两个版本号是否一致，不一致则重新编译。

cocoapods-binary-bel

为了能充分利用该插件，我根据实际产生的问题，对源码进行了一些修改，增加了 plist版本校验。使用方式和cocoapods-binary一致。
源码github链接cocoapods-binary-bel

安装

sudo gem install cocoapods-binary-bel

流程图

在 cocoapods-binary的基础上增加了版本校验工程，总的流程图如下所示：

一键转源码

1，:binary => false，指定某一个framework为源码

2， 新增 --hsource选项，输入 pod install --hsource，可以将所有的framework转为源码。

去除了依赖分析

在实际运用的工程中，如果 A 依赖 B 和C, B又依赖D,如果 A需要预编译，那么 B、C 和 D都需要重新编译，实际上此时B、C、D已经有了已经编译好的版本，无需重新编译。在Podfile指明 B、C、D即可。

pod "A"

pod "B"

pod "C"

pod "D"

增加静态库的resource处理

在 cocoapods中，如果使用 resource_bundle 处理资源文件，会生成一个相对应的target来处理资源文件，如果是动态库，会在动态库的Target，添加资源工程依赖，使用 xcodebuild命令制作二进制会将bundle文件编译至xxx.framework目录下，使用 resources同样也会将资源文件编译至xxx.framework目录下。

对于静态库而言，如果是使用resource_bundle，也同样生成一个会生成一个相对应的target来处理资源文件，但对资源文件的拷贝，是由主工程做的，无需静态库工程处理， 如果使用 resources，则需要将资源文件从源码中，拷贝到 xxx.framework下，在主工程编译时，由主工程处理即可。

属性 提供了更多关于声明和类型的信息。在 Swift 中有两种类型的属性，一种用于声明，一种用于类型。例如，

required 属性－当用于类的指定或者便利初始化声明时－指明每个子类都必须实现它的初始化函数。noreturn 属性

－当用于函数或者方法的类型时－指明函数或者方法无需返回值。

咋们一起好好看，好好学

你可以用字符 @ 加上属性名和属性参数来指定一个属性：

@属性名
@属性名(属性参数)

含有参数的声明属性可以为属性指定更多的信息，可以用于特殊的声明。这些属性参数 被包含在圆括号里，参数的格式由属性决定。

声明属性

声明属性只能用于声明，当然，你也可以使用 noreturn 属性作为函数或者方法的类型。

assignment

此属性可用于修饰重载复合赋值运算符的函数。这个重载复合赋值运算符的函数必须用 inout 来标记初始输入参数。assignment属性示例参见复合赋值运算符。

class_protocol

此属性可用于定义类类型协议。

如果你使用 objc 属性的协议， 那么这个协议就隐式含有 class_protocol 属性，你无需显式标记 class_protocol 属性。

exported

此属性可用于内部声明，可以将当前模块的内部模块、子模块或者声明暴露给外部其他模块。如果另一个模块引用了当前模块，那么这个模块就可以访问当前模块中暴露出来的部分。

final

此属性可用于修饰类或者类的属性、方法或成员下标运算符。用于一个类的时候，表明这个类是不能被继承的。用于类的属性、方法或成员下标运算符的时候，表明这个类的这些成员函数不能在任何子类中重写。

lazy

此属性可用于修饰类或者结构体中的存储变量属性，表明这个属性在第一次被访问时，其初始值最多只能被计算和存储一次。lazy 属性示例参见惰性存储属性。

noreturn

此属性用于函数或者方法的声明，表明其函数或者方法相应的类型T是@noreturn T。当一个函数或者方法无需返回其调用者时，你可以用这个属性来修饰其类型。

你可以重写没有标示noreturn属性的函数或者方法。也就是说，你不能够重写有noreturn属性的函数或者方法。当你实现此类型的协议方法时，也有相似的规则。

NSCopying

此属性可用于修饰类中的存储变量属性。被修饰的这个属性的赋值函数是由这个属性值的拷贝组成－由copyWithZone方法返回－而不是这个属性本身的值。此属性类型必须符合NSCopying协议。
NSCopying属性类似于Objective-C中的copy属性。

NSManaged

用于修饰类中的存储变量属性，此类继承于NSManagedObject，表明这个属性的存储和实现是由Core Data基于相关的实体描述实时动态提供的。

objc

此属性可用于能用Objective-C表示的任何声明中－例如，非嵌套的类、协议、类和协议的属性和方法(包括取值函数和赋值函数)、初始化函数、析构函数以及下标运算符。objc属性告诉编译器此声明在Objective-C代码中可用。

如果你使用objc属性修饰类或者协议，它会显式的应用于这个类或者协议中的所有成员。当一个类继承于标注objc属性的另一类时，编译器会显式的为这个类添加objc属性。标注objc属性的协议不能够继承于不含有objc属性的协议。

objc属性可以接受由标识符组成的单个属性参数。当你希望暴露给Objective-C的部分是一个不同的名字时，你可以使用objc属性。你可以使用这个参数去命名类、协议、方法、取值函数、赋值函数以及初始化函数。下面的示例就是ExampleClass的enabled属性的取值函数，它暴露给Objective-C代码的是isEnabled，而不是这个属性的原名。

1.  @objc

2.  class ExampleClass {

3.  var enabled: Bool {

4.  @objc(isEnabled) get {

5.  // Return the appropriate value

6.  }

7.  }

8.  }

optional

此属性可用于协议的属性、方法或者成员下标运算符，用来表明实现那些成员函数时，此类型的不是必需实现的。

optional属性只能用于标注objc属性的协议。因此，包含可选成员的协议只有类类型适用。更多的关于怎样使用optional属性，以及怎样访问可选协议成员的指导－例如，当你不确定它们是否实现了此类型时－参见可选协议需求。

required

此属性用于类的指定或者便利初始化函数时，表明这个类的每个子类都必须实现这个初始化函数。

需求的指定初始化函数必须被显式的包含。当子类直接实现所有超类的指定初始化函数时(或者子类使用便利初始化函数重写了指定初始化函数时)，需求的便利初始化函数必须被显式的包含或者继承。

使用Interface Builder声明属性

Interface Builder属性就是使用Interface Builder声明属性以与Xcode同步。Swift提供了如下几种Interface Builder属性：IBAction，IBdesignable，IBInspectable以及IBOutlet。这些属性理论上与Objective-C中相应的属性一样。

IBOutlet和IBInspectable属性可用于类的属性声明，IBAction属性可用于类的方法声明，IBDesignable属性可用于类的声明。

类型属性

类型属性可以只用于类型。当然noreturn属性也可以用于函数或者方法的声明。

auto_closure

此属性用于延迟表达式的赋值计算，将表达式自动封装成一个无参数的闭包。此属性还可作为函数或者方法的类型，此类型无参数并且其返回的是表达式类型。auto_closure属性示例参见函数类型。

noreturn

此属性用于函数或者方法时表明此函数或者方法无返回值。你也可以用此属性标记函数或者方法的声明，以表明其函数或者方法相应的类型T是@noreturn T。

属性语法
attribute → @­attribute-name attribute-argument-clause opt
attribute-name → identifier
attribute-argument-clause → (balanced-tokens­ opt)
attributes → attribute­ attributes­ opt­
balanced-tokens → balanced-token ­balanced-tokens­ opt­
balanced-token → (­balanced-tokens­ opt­)­
balanced-token → [balanced-tokens­ opt­]­
balanced-token → {balanced-tokens­ opt­­}­
balanced-token → 任意标识符，关键字，常量，或运算符
balanced-token → 任意的标点符号 (­， )­， [­， ]­， {­， 或 }­

由于文章篇幅有限，只能点到即止地介绍当前一些工作成果和思考，各个 Swift 还有一些新的方向在探索，如果你对 iOS 底层原理、架构设计、构建系统、如何面试有兴趣了解，你也可以关注我及时获取最新资料以及面试相关资料。如果你有什么意见和建议欢迎给我留言！

写的不好的地方欢迎大家指出，希望大家多留言讨论，让我们共同进步！

喜欢iOS的小伙伴可以关注我，一起学习交流！！！

链接：juejin.cn/post/698169…

一般说,iOS界面的一些长列表,比如首页,活动页,长的会比较长,那么写起来总感觉没有那么优雅,那么如何才能做到优雅呢?
我在实践工作利用swift枚举的关联值和自定义组模型方法来实现了

• 下面是gif图效果

可以看到,有些组是杂乱无章的排列着,而且运营那边要求,他们可以在后台自定义这些组的顺序
这可怎么办!🥺
下面看我的实现方式

定义一个组模型枚举

• 包含可能的定义,每个枚举关联当前组需要显示的数据模型,有可能是一个对象数组,也有可能是一个对象

/// 新版首页组cell的类型

enum OriginGroupCellType {

    case marquee(list: [MarqueeModel]) // 跑马灯

    case beltAndRoad(list: [GlobalAdModel]) // 一带一路广告位

    case shoppingCarnival(list: [GlobalAdModel]) // 购物狂欢节

    case walletCard(smallWelfare: WelfareSmallResutlModel) // 钱包卡片

    case wallet(list: [HomeNavigationModel]) // 钱包cell

    case otc(list: [GlobalAdModel]) // OTC

    case hxPrefecture(list: [GlobalAdModel]) // HX商品专区

    case middleNav(list: [HomeNavigationModel]) // 中部导航

    case bottomNav(list: [HomeNavigationModel]) // 底部导航

    case broadcast(topSale: HomeNavigationModel, hot: OriginBroadcastModel, choiceness: OriginBroadcastModel) // 直播cell

    case middleAd(list: [GlobalAdModel]) // 中间广告cell

    case localService(list: [LocalServiceModel]) // 本地服务cell

    case bottomFloat(headerList: [OriginBottomFloatHeaderModel]) // 底部悬停cell

}

• 考虑到要下拉刷新等问题,可以这些枚举都得遵守Equatable协议

  extension OriginGroupCellType: Equatable {

    public static func == (lhs: OriginGroupCellType, rhs: OriginGroupCellType) -> Bool {

        switch (lhs, rhs) {

        case (.marquee, .marquee): return true

        case (.beltAndRoad, .beltAndRoad): return true

        case (.shoppingCarnival, .shoppingCarnival): return true

        case (.walletCard, .walletCard): return true

        case (.wallet, .wallet): return true

        case (.otc, .otc): return true

        case (.hxPrefecture, .hxPrefecture): return true

        case (.middleNav, .middleNav): return true

        case (.bottomNav, .bottomNav): return true

        case (.broadcast, .broadcast): return true

        case (.middleAd, .middleAd): return true

        case (.localService, .localService): return true

        case (.bottomFloat, .bottomFloat): return true

        default:

            return false

        }

    }

}

接下来就是组模型的定义

• 同时我抽取一个协议GroupProvider,方便复用

protocol GroupProvider {

    /// 占位

    associatedtype GroupModel where GroupModel: Equatable

    

    /// 是否需要往组模型列表中添加当前组模型

    func isNeedAppend(with current: GroupModel, listMs: [GroupModel]) -> Bool

    /// 获取当前组模型在组模型列表的下标

    func index(with current: GroupModel, listMs: [GroupModel]) -> Int

}



extension GroupProvider {

    func isNeedAppend(with current: GroupModel, listMs: [GroupModel]) -> Bool {

        return !listMs.contains(current)

    }

    

    func index(with current: GroupModel, listMs: [GroupModel]) -> Int {

        return listMs.firstIndex(of: current) ?? 0

    }

}

• OriginGroupModel,同样也遵守Equatable协议,防止重复添加

func addTo(listMs: inout [OriginGroupModel]) 

• 这个方法是方便于下拉刷新时,替换最新数据所用

public struct OriginGroupModel: GroupProvider {

    typealias GroupModel = OriginGroupModel

    

    /// 组模型的类型

    var cellType: OriginGroupCellType

    /// 排序

    var sortIndex: Int



    /// 把groupModel添加或替换到listMs中

    func addTo(listMs: inout [OriginGroupModel]) {

        if isNeedAppend(with: self, listMs: listMs) {

            listMs.append(self)

        } else {

            let index = self.index(with: self, listMs: listMs)

            listMs[index] = self

        }

    }

}



extension OriginGroupModel: Equatable {

    public static func == (lhs: OriginGroupModel, rhs: OriginGroupModel) -> Bool {

        return lhs.cellType == rhs.cellType

    }

}

• 考虑要自定义顺序,所以需要定义一个排序的实体

// MARK: - 新版首页组模型的排序规则模型

struct OriginGroupSortModel {

    /// 搜索历史的排序

    var marqueeIndex: Int

    var beltAndRoadIndex: Int

    var shoppingCarnivalIndex: Int

    var walletCardIndex: Int

    var walletIndex: Int

    var otcIndex: Int

    var hxPrefectureIndex: Int

    var middleNavIndex: Int

    var bottomNavIndex: Int

    var broadcastIndex: Int

    var middleAdIndex: Int

    var localServiceIndex: Int

    var bottomFloatIndex: Int



    static var defaultSort: OriginGroupSortModel {

        return OriginGroupSortModel(

            marqueeIndex: 0,

            beltAndRoadIndex: 1,

            shoppingCarnivalIndex: 2,

            walletCardIndex: 3,

            walletIndex: 4,

            otcIndex: 5,

            hxPrefectureIndex: 6,

            middleNavIndex: 7,

            bottomNavIndex: 8,

            broadcastIndex: 9,

            middleAdIndex: 10,

            localServiceIndex: 11,

            bottomFloatIndex: 99)

    }

}

控制器里定义一个 组模型数组

• 这里有关键代码是

listMs.sort(by: { return $0.sortIndex < $1.sortIndex }) 

• 所有的数据加载完毕后,会根据我们的自定义排序规则去排序

    /// 组模型数据

    public var listMs: [OriginGroupModel] = [] {

        didSet {

            listMs.sort(by: {

                return $0.sortIndex < $1.sortIndex

            })

            collectionView.reloadData()

        }

    }

    

    /// 组模型排序规则(可以由后台配置返回,在这里我们先给一个默认值)

    /// 需要做一个请求依赖,先请求排序接口,再请求各组的数据

    public lazy var sortModel: OriginGroupSortModel = OriginGroupSortModel.defaultSort

网络请求代码

func loadData(_ update: Bool = false, _ isUHead: Bool = false) {

        // 定义队列组

        let queue = DispatchQueue.init(label: "getOriginData")

        let group = DispatchGroup()

        

        // MARK: - 文字跑马灯

        group.enter()

        queue.async(group: group, execute: {

            HomeNetworkService.shared.getMarqueeList { [weak self] (state, message, data) in

                guard let `self` = self else { return }

                self.collectionView.uHead.endRefreshing()

                

                defer { group.leave() }

                let groupModel = OriginGroupModel(cellType: .marquee(list: data), sortIndex: self.sortModel.marqueeIndex)

                guard !data.isEmpty else { return }

                

                /// 把groupModel添加到listMs中

                groupModel.addTo(listMs: &self.listMs)

            }

        })

        

        /// .... 此处省略其它多个请求



        group.notify(queue: queue) {

            // 队列中线程全部结束,刷新UI

            DispatchQueue.main.sync { [weak self] in

                self?.collectionView.reloadData()

            }

        }

    }

collectionView的代理方法处理