在微信早期，我们内部就有这样的诉求，在微信打开的H5可以调用到微信原生一些能力，例如公众号文章里可以打开公众号的Profile页。所以早期微信提供了Webview到原生的通信机制，在Webview里注入JSBridge的接口，使得H5可以通过它调用到原生能力。 [图片] 我们可以通过JSBridge微信预览图片的功能： [代码]WeixinJSBridge.invoke('imagePreview', { current: https://img1.gtimg.com/1.jpg', urls: [ 'https://img1.gtimg.com/1.jpg', 'https://img1.gtimg.com/2.jpg', 'https://img1.gtimg.com/3.jpg' ] }) [代码] 早期微信官方是没有暴露这些接口的，都是腾讯内部业务在使用，很多外部开发者发现后，就依葫芦画瓢地使用了。 从另外一个角度看，JSBridge是微信和H5的通信协议，有一些能力可能要组合不同的能力才能完整调用。如果我们直接开放这套API，相当于所有开发者都要直接理解这样的接口协议，显然是很不合理的。 所以在2015年初的时候，微信就发布了JSSDK，其实就是隐藏了内部一些细节，包装了几十个API给到上层业务直接调用。 [图片] 前边的代码就变成了： [代码]wx.previewImage({ current: https://img1.gtimg.com/1.jpg', urls: [ 'https://img1.gtimg.com/1.jpg', 'https://img1.gtimg.com/2.jpg', 'https://img1.gtimg.com/3.jpg' ] }) [代码] 开发者可以用JSSDK来调用微信的能力，来完成一些以前H5做不到或者难以做到的事情。 能力上得到了更多的支持，但是微信里的H5体验却没有改善。 第一点是加载H5时的白屏。在微信里打开链接后会看到白屏，有一些H5的服务不稳定，这个白屏现象会更严重。 [图片] 第二点是在H5跳转到其他页面时，切换的效果也很不流畅，只能看到顶部绿色进度条在走。 [图片] 随着JSSDK的开放，还出现了更不好对付的问题。 微信上越来越多干坏事的人，有人做假红包，有人诱导分享，有伪造一些官方活动。他们会利用JSSDK的分享能力变相的去裂变分享到各个群或者朋友圈，由于JSSDK是根据域名来赋予api权限的，运营人员封了一个域名后，他们立马用别的域名又继续做坏，要知道注册一个新的域名的成本是很低的。 [图片] [图片] [图片] 龙哥在2016年微信公开课上提出了应用号的概念，我们要重新设计一个新的移动应用开发模式，同时我们要解决刚刚提到的一些问题。 至此，我们回顾一下目前移动应用开发的一些特点： Web开发的门槛比较低，而App开发门槛偏高而且需要考虑iOS和安卓多个平台； 刚刚说到H5会有白屏和页面切换不流畅的问题，原生App的体验就很好了； H5最大的优点是随时可以上线更新，但是App的更新就比较慢，需要审核上架，还需要用户主动安装更新。 我们更想要的一种开发模式应该是要满足一下几点： 像H5一样开发门槛低； 体验一定要好，要尽可能的接近原生App体验； 让开发者可以云端更新，而且我们平台要可以管控。 很多人可能会第一时间想到Facebook的React Native(下边简称RN)，是不是RN就能解决这些问题呢？ 是的，React Native貌似可以解决刚刚那些问题，我们也曾经想用RN来做。但是仔细分析了一下，我们发现了采用RN这个机制做开放平台还是存在一些问题。 RN只支持CSS的子集，作为一个开放的生态，我们还要告诉外边千千万万的开发者，哪些CSS属性能用，哪些不能用； RN本身存在一些问题，这些依赖RN的修复，同时这样就变成太过依赖客户端发版本去解决开发者那边的Bug，这样修复周期太长。 RN前阵子还搞出了一个Lisence问题，对我们来说也是存在隐患的。 [图片] 所以我们舍弃了这样的方案，我们改用了Hybrid的方式。简单点说，就是把H5所有代码打包，一次性Load到本地再打开。这样的好处是我们可以用一种近似Web的方式来开发，同时在体验上也可以做到不错的效果，并且也是可以做到云端更新的。 [图片] 现在留给我们的最后一个问题就是，平台的管控问题。 怎么理解呢？我们知道H5的界面结构是用HTML进行描述，浏览器进行一系列的解析最终绘制在界面上。 [图片] 同时浏览器提供了可以操作界面的DOM API，开发者可以用这些API进行一些界面上的变动，从而实现UI交互。 [图片] 既然我们要采用Web+离线包的方式，那我们要解决前边说过的安全问题，我们就要禁用掉很多危险的HTML标签，还要禁用掉一些API，我们要一直维护这样的白名单或者黑名单，实现成本太高了，而且未来浏览器内核一旦更新，对我们来说都是很大的安全隐患。 [图片] 这就是小程序一开始遇到的问题，在下篇文章《小程序架构设计(二)》，我们再详细展开一下小程序是如何解决以上这个问题的。

我们知道小程序的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算法：完整性 来一张完整的图： [图片]

今年开始各路刘海和全面屏手势的手机已经开始霸占市场，全面屏和刘海屏的适配也必须提上日程。 相信大家也一定会有第一次将未适配的小程序放到全面屏或刘海屏手机上的尴尬体验。 尤其是在导航栏设置为custom时，标题与胶囊对不齐简直逼死强迫症。。 微信官方也没有出一个官方的指导贴帮助开发者。 这里仅总结一下个人关于这个问题的一些处理方式，如有疏漏烦请指正补充。 适配的关键在两个位置即额头和下巴，头不用说自然是关于刘海的。 小程序的头的高度主要分为2个部分 1.statusBarHeight 该值可以在app onLaunch 调用wx.getSystemInfoSync() 获取到     a）刘海 高度44     [图片]     b）无刘海 ios高度20 安卓各不相同     [图片] 2.胶囊高度 即下图高度          [图片]     在查阅社区问答后了解到小程序给到的策略是ios在模拟器下统一是44px，ios在真机下统一是40px（感谢指正@bug之所措 ），而安卓下统一是48px，因此我们又可以在wx.getSystemInfoSync() 中获取到系统之后得到胶囊高度。     总的导航栏高度即这两个高度之合。本人项目中是将导航做成组件并给到slot，方便各个页面配置。 开发者工具 1.02.1810190 及以上版本支持在 app.json 中声明 usingComponents 字段，在此处声明的自定义组件视为全局自定义组件，在小程序内的页面或自定义组件中可以直接使用而无需再声明。     目前小程序还支持在单个页面配置custom，也可以配合使用~ 另一个需要关注的则是底部，参考的文章是 https://www.jianshu.com/p/a1e8c7cf8821 重点是在于在全面屏的手机的底部需要流出34px的空白给到全面屏返回手势操作，此外由于全面屏屏幕圆边还可能使一些按钮或功能无法正常使用。 那么首先如何判断是否是全面屏呢？个人的做法是判断屏幕高度是否大于750，iphone的plus系列高度在736，正好在这个范围之内，当然750不一定准确，如果出现疏漏烦请补充。 涉及到底部的主要是弹出的操作菜单、tabBar和底部定位的按钮等。这里做了一个简单的代码片段。 https://developers.weixin.qq.com/s/fnU0n8mv7o5M 希望能够帮助到大家，也欢迎交流~

好的经验必须要分享：chooseImage后转base64 现在网上各种帖子的解决方案存在各种各样的问题，不说了，直接贴代码，手机亲测，没有问题 const fileManager = wx.getFileSystemManager(); [图片]