wx.saveImageToPhotosAlbum 在安卓手机上企业微信上保存图片显示成功，但是找不到图片 微信相同功能没问题 安卓机型：华为mate40pro、红米k30、红米note8Pro等

我们知道小程序的wx.request网络接口只支持HTTPS协议（文档-小程序网络说明），为什么HTTPS协议就比HTTP安全呢？一次安全可靠的通信应该包含什么东西呢，这篇文章我会尝试讲清楚这些细节。 Alice与Bob的通信 我们以Alice与Bob一次通信来贯穿全文，一开始他们都是用明文的形式在网络传输通信内容。 [图片] 嗅探以及篡改 如果在他们的通信链路出现了一个Hacker，由于通信内容都是明文可见，所以Hacker可以嗅探看到这些内容，也可以篡改这些内容。 [图片] 公众号的文章之前就遇到很多被挟持篡改了内容，插入广告。 [图片] 加密解密 既然明文有问题，那就需要对明文进行加密处理，让中间人看不懂内容，于是乎要对原来的内容变成一段看不懂的内容，称为加密，反之则是解密。而本质其实就是一种数学运算的逆运算，类似加法减法，例如发送方可以将 abcd…xyz 每个字母+1映射成 bcd…yza，使得原文的字母变成看不懂的序列，而接收方只需要将每个字母-1就可以恢复成原来的序列，当然这种做法规律太容易被破解了，后边会有个案例示意图。 [图片] 对称加密 如果对2个二进制数A和B进行异或运算得到结果C, 那C和B再异或一次就会回到A，所以异或也可以作为加密解密的运算。 [图片] 把操作数A作为明文，操作数B作为密钥，结果C作为密文。可以看到加密解密运用同一个密钥B，把这种加解密都用同一个密钥的方式叫做对称加密。 [图片] 可以看到简单的异或加密/解密操作，需要密钥跟明文位数相同。为了克服这个缺点，需要改进一下，把明文进行分组，每组长度跟密钥一致，分别做异或操作就可以得到密文分片，再合并到一起就得到密文了。 [图片] 但是这种简单分组的模式也是很容易发现规律，可以从下图看到，中间采用对原图进行DES的ECB模式加密（就是上边提到简单分组的模式） [图片] 很明显，原图一些特征在加密后还是暴露无遗，因此需要再改进一把。一般的思路就是将上次分组运算的结果/中间结果参与到下次分组的运算中去，使得更随机混乱，更难破解。以下图片来自维基百科： [图片] 经过改良后，Alice与Bob如果能提前拿到一个对称加密的密钥，他们就可以通过加密明文来保证他们说话内容不会被Hacker看到了。 [图片] 非对称加密 刚刚还引发另一个问题，这个对称加密用到的密钥怎么互相告知呢？如果在传输真正的数据之前，先把密钥传过去，那Hacker还是能嗅探到，那之后就了无秘密了。于是乎出现另外一种手段： [图片] 这就是非对称加密，任何人都可以通过拿到Bob公开的公钥对内容进行加密，然后只有Bob自己私有的钥匙才能解密还原出原来内容。 [图片] RSA就是这样一个算法，具体数学证明利用了大质数乘法难以分解、费马小定理等数学理论支撑它难以破解。相对于前边的对称加密来说，其需要做乘法模除等操作，性能效率比对称加密差很多。 [图片] 由于非对称加密的性能低，因此我们用它来先协商对称加密的密钥即可，后续真正通信的内容还是用对称加密的手段，提高整体的性能。 [图片] 认证 上边虽然解决了密钥配送的问题，但是中间人还是可以欺骗双方，只要在Alice像Bob要公钥的时候，Hacker把自己公钥给了Alice，而Alice是不知道这个事情的，以为一直都是Bob跟她在通信。 [图片] 要怎么证明现在传过来的公钥就是Bob给的呢？在危险的网络环境下，还是没有解决这个问题。 [图片] 一般我们现实生活是怎么证明Bob就是Bob呢？一般都是政府给我们每个人发一个身份证（假设身份证没法伪造），我只要看到Bob身份证，就证明Bob就是Bob。 网络也可以这么做，如果有个大家都信任的组织CA给每个人出证明，那Alice只要拿到这个证明，检查一下是不是CA制作的Bob证书就可以证明Bob是Bob。所以这个证书里边需要有两个重要的东西：Bob的公钥+CA做的数字签名。 [图片] 前边说到用公钥进行加密，只有拥有私钥的人才能解密。数字证书有点反过来：用私钥进行加密，用公钥进行解密。CA用自己的私钥对Bob的信息（包含Bob公钥）进行加密，由于Alice无条件信任CA，所以已经提前知道CA的公钥，当她收到Bob证书的时候，只要用CA的公钥对Bob证书内容进行解密，发现能否成功解开（还需要校验完整性），此时说明Bob就是Bob，那之后用证书里边的Bob公钥来走之前的流程，就解决了中间人欺骗这个问题了。 这种方式也是一种防抵赖的方式，让对方把消息做一个数字签名，只要我收到消息，用对方的公钥成功解开校验这个签名，说明这个消息必然是对方发给我的，对方不可以抵赖这个行为，因为只有他才拥有做数字签名的私钥。 [图片] CA其实是有多级关系，顶层有个根CA，只要他信任B，B信任C，C信任D，那我们基本就可以认为D是可信的。 [图片] 完整性 上边基本上已经解决了保密性和认证，还有一个完整性没有保障。虽然Hacker还是看不懂内容，但是Hacker可以随便篡改通信内容的几个bit位，此时Bob解密看到的可能是很乱的内容，但是他也不知道这个究竟是Alice真实发的内容，还是被别人偷偷改了的内容。 [图片] 单向Hash函数可以把输入变成一个定长的输出串，其特点就是无法从这个输出还原回输入内容，并且不同的输入几乎不可能产生相同的输出，即便你要特意去找也非常难找到这样的输入（抗碰撞性），因此Alice只要将明文内容做一个Hash运算得到一个Hash值，并一起加密传递过去给Bob。Hacker即便篡改了内容，Bob解密之后发现拿到的内容以及对应计算出来的Hash值与传递过来的不一致，说明这个包的完整性被破坏了。 [图片] 一次安全可靠的通信 总结一下，安全可靠的保障： 对称加密以及非对称加密来解决：保密性 数字签名：认证、不可抵赖 单向Hash算法：完整性 来一张完整的图： [图片]

写在前面的话 大家看到这个文章时一定会感觉这是在炒剩饭，社区中已经有那么多分享自定义导航适配的文章了，为什么我还要再写一个呢？ 主要原因就是，社区中大部分的适配方案中给出的大小是不精确的，并不能完美适配各种场景。 社区中大部分文章给到的值是 iOS -> 44px , Android -> 48px 思路 正常来讲，iOS和Android下的胶囊按钮的位置以及大小都是相同且不变的，我们可以通过胶囊按钮的位置和大小再配合 wx.getSystemInfo 或者 wx.getSystemInfoSync 中得到的 [代码]statusBarHeight[代码] 来计算出导航栏的位置和大小。 小程序提供了一个获取菜单按钮（右上角胶囊按钮）的布局位置信息的API，可以通过这个API获取到胶囊按钮的位置信息，但是经过实际测试，这个接口目前存在BUG，得到的值经常是错误的（通过特殊手段可以偶尔拿到正确的值），这个接口目前是无法使用的，等待官方修复吧。 下面是我经过实际测试得到的准确数据： 真机和开发者工具模拟器上的胶囊按钮不一样 [代码]# iOS top 4px right 7px width 87px height 32px # Android top 8px right 10px width 95px height 32px # 开发者工具模拟器（iOS） top 6px right 10px width 87px height 32px # 开发者工具模拟器（Android） top 8px right 10px width 87px height 32px [代码] [代码]top[代码] 的值是从 [代码]statusBarHeight[代码] 作为原点开始计算的。 使用上面数据中胶囊按钮的高度加 [代码]top[代码] * 2 上再加上 [代码]statusBarHeight[代码] 的高度就可以得到整个导航栏的高度了。 为什么 [代码]top[代码] * 2 ？因为胶囊按钮是垂直居中在 title 那一栏中的，上下都要有边距。 扩展 通过胶囊按钮的 [代码]right[代码] 可以准确的算出自定义导航的 [代码]左边距[代码]。 通过胶囊按钮的 [代码]right[代码] + [代码]width[代码] 可以准确的算出自定义导航的 [代码]右边距[代码] 。 通过 wx.getSystemInfo 或者 wx.getSystemInfoSync 中得到的 [代码]windowWidth[代码] - 胶囊按钮的 [代码]right[代码] + [代码]width[代码] 可以准确的算出自定义导航的 [代码]width[代码] 。 再扩展 wx.getSystemInfo 或者 wx.getSystemInfoSync 中得到的 [代码]statusBarHeight[代码] 每个机型都不一样，刘海屏得到的数据也是准确的。 如果是自定义整个页面，iPhone X系列的刘海屏，底部要留 [代码]68px[代码] ，不要问我为什么！ 代码片段 https://developers.weixin.qq.com/s/Q79g6kmo7w5J

首屏 一般情况下，在首屏数据未拿到之前，为了提升用户的体验，会在页面上展示一个loading的图层，类似下面这个 [图片] 其中除了菊花图以外网上还流传这各种各样的loading动画，在PC端上几乎要统一江湖了，不过最近在移动端上面看到不同于菊花图的加载方式，就是这篇文章需要分享的Skeleton Screen，中文称之为"骨架屏" 概念 A skeleton screen is essentially a blank version of a page into which information is gradually loaded. 在H5中，骨架屏其实已经不是什么新奇的概念了，网上也有各种方案生成对应的骨架屏，包括我们经常使用的知乎、饿了么、美团等APP都有应用骨架屏这个概念 图片来源网络，侵删 [图片] 方案 先从H5生成骨架屏方案开始说起，总的来说H5生成骨架屏的方案有2种 完全靠手写HTML和CSS方式给每个页面定制一套骨架屏 利用预渲染的方式生成静态骨架屏 第一套方案，毫无疑问是最简单最直白的方式，缺点也很明显，假如页面布局有修改的话，那么除了修改业务代码之外还需要额外修改骨架屏，增加了维护的成本。 第二套方案，一定程度上改善了第一套方案带来的维护成本增加的缺点，主要还是使用工具预渲染页面，获取到DOM节点和样式，保留页面结构，覆盖样式，生成灰色块盖在原有文本、图片或者是canvas等节点上面，最后将生成的HTML和CSS打包出来，就是一个带有骨架屏的页面。最后再利用webpack工具将生成的骨架屏插入到HTML里面，详细的话可以看看饿了么的分享，这里就不多描述了。 调研了下H5生成骨架屏的方案，对于小程序生成骨架屏的方案也有了一个大致的想法，主要有2个难点需要实现 预渲染 获取节点 预渲染 再说回饿了么提供的骨架屏的方案，使用 puppeteer 渲染页面（或者使用服务端渲染，vue或者react都有提供相应的方案），拿到DOM节点和样式，这里有一点需要注意的是，页面的渲染是需要初始化的数据，数据的来源可以是初始化的data（vue）或者mock数据，当然小程序是无法直接使用 puppeteer 来做预渲染（有另外的方案可以实现），需要利用小程序初始化的 data + template 渲染之后得到一个初始化结构作为骨架屏的结构 [代码]//index.js Page({ data: { motto: 'Hello World', userInfo: { avatarUrl: 'https://wx.qlogo.cn/mmopen/vi_32/SYiaiba5faeraYBoQCWdsBX4hSjFKiawzhIpnXjejDtjmiaFqMqhIlRBqR7IVdbKE51npeF6X1cXxtDQD2bzehgqMA/132', nickName: 'jay' }, lists: [ 'aslkdnoakjbsnfkajbfk', 'qwrwfhbfdvndgndghndeghsdfh', 'qweqwtefhfhgmjfgjdfghaefdhsdfgdfh', ], showSkeleton: true }, onLoad: function () { const that = this; setTimeout(() => { that.setData({ showSkeleton: false }) }, 3000) } }) //index.wxml <view class="container"> <view class="userinfo"> <block> <image class="userinfo-avatar skeleton-radius" src="{{userInfo.avatarUrl}}" mode="cover"></image> <text class="userinfo-nickname skeleton-rect">{{userInfo.nickName}}</text> </block> </view> <view style="margin: 20px 0"> <view wx:for="{{lists}}" class="lists"> <icon type="success" size="20" class="list skeleton-radius"/> <text class="skeleton-rect">{{item}}</text> </view> </view> <view class="usermotto"> <text class="user-motto skeleton-rect">{{motto}}</text> </view> <view style="margin-top: 200px;"> aaaaaaaaaaa </view> </view> [代码] 有了上面的 data + template 之后，就有了一个初始化的页面结构，接下来就需要拿到节点信息 节点 小程序基础库1.4.0之后小程序基础库提供了一组新的API，可用于获取节点信息，具体API戳这里。 跟H5方式一样，根据class或者id获取节点信息，不同的是只能获取到当前的节点信息，无法获取到其父或者子节点信息，所以只能手动给需要渲染骨架屏的节点添加相应的class或者id [代码]<view class="container"> <view class="userinfo"> <block> <image class="userinfo-avatar skeleton-radius" src="{{userInfo.avatarUrl}}" mode="cover"></image> <text class="userinfo-nickname skeleton-rect">{{userInfo.nickName}}</text> </block> </view> <view style="margin: 20px 0"> <view wx:for="{{lists}}" class="lists"> <icon type="success" size="20" class="list skeleton-radius"/> <text class="skeleton-rect">{{item}}</text> </view> </view> <view class="usermotto"> <text class="user-motto skeleton-rect">{{motto}}</text> </view> <view style="margin-top: 200px;"> aaaaaaaaaaa </view> </view> [代码] 约定2个特殊的class作为获取节点信息的标记[代码]skeleton-rect[代码]和[代码]skeleton-radius[代码]，在页面中获取相应的[代码]top[代码]、[代码]left[代码]、[代码]width[代码]、[代码]height[代码]进行骨架屏的绘制 结果 [图片] 具体的调用方式和源码，请看 github ，最后求start 总结 上文有说到小程序也可以使用 page-skeleton-webpack-plugin 方式一样生成骨架屏，最重要的一点就是需要将小程序跑在chrome上面，后面的流程就一样了，至于怎么将小程序跑在chrome上面呢？可以利用 wept ，缺点就是目前作者已经停止维护这个工具了，不支持新版小程序的API。 说回来我这个生成骨架屏的方案，其实跟 page-skeleton-webpack-plugin 有点相似，不同的是，page-skeleton-webpack-plugin 采用离线渲染的方式生成静态骨架屏插入路由中，而我采用运行时先渲染页面默认结构，然后根据默认结构再绘制骨架屏。从性能角度出发确实不如 page-skeleton-webpack-plugin，但是也差不了多少了，主要还是小程序并没有提供类似服务端渲染的方案。目前从使用上来讲，还是有点小麻烦，需要默认数据撑开页面结构，需要给相应的节点添加class，后面有时间再研究下有没有更好的方案吧~~~