遇到这个问题的场景是，在react-native容器里，我们可以通过react-native-canvas绘制图片，并且拿到图片的base64信息。但是怎么把这个base64上传到服务端呢。谷歌搜索一番，一般的做法是通过类似于react-native-fs储存到本地，然后通过给地址的方式从formdata上传文件。由于我们的react-native容器有一套几乎和微信小程序一样的请求api，我们也搜索了小程序一般上传base64文件的方式——通过filesystemmanager储存到本地，然后通过uploadfile桥上传。

一般现代ReactNative二次封装框架除了处理bundle热更新，下发等，有一个设定是考虑到大量混合开发的情况，RN的应用级使用会改成页面级使用，以降低应用颗粒度的同时更自然的混合运行。但是这样做有一个存在疑问的地方，即每一个页面都会是用一个RN引擎即一个JSCore，内存占用高不说，每个页面的引擎创建成本也是相当高的，从性能/用户体验上均难以接受。因此会做“引擎复用”，即直观理解jscore复用这个事情。如果不对facebook的RN本身做大改而是基本基于其现有的api做二封的形式来完成，那引擎复用的方案/实现/与限制显然受到RN本身影响。因此本笔记讨论的是ReactNative到底做了啥，可以做到啥，哪儿来的限制。

最近和不同的Native开发者与Web前端开发者之间聊天，发现大家的意识或者理念上的沟壑比我们想象中的深很多。都说大前端一家人，不过很多事情不同心共体的话，团队上细微的裂痕在项目或者组织动荡期会有非常大的风险导致团队成员的割裂。因此，需求其中的原因与寻找其中发展之道是本文讨论的关键。

在实际项目踩坑过程中，我们主要到Set-Cookie存在多个的情况。有两种做法：

- 一种是一条Set-Cookie，但是这一条中有多个cookie key-value，通过逗号“,”连接。
- 一种是haeder中有多条Set-Cookie字段，

当然也有上面两条组合的情况，但是一般就是这样了。不过这次讨论的是，在实际开发过程中，这两种情况都有踩坑的问题。

偶尔会遇到前端访问遇到httpcode431和414的错误。具体情况划分起来，会遇到以下三种：

- 414 Request-URI Too Large：即URL过长
- 400 Request Header Or Cookie Too Large：即Header过长
- 431 Bad Message reason: Request Header Fields Too Large：即Header Fields过长（HTTP整个前半部分，包括url+header）

虽然明白意思，但是实际遇到的时候晕乎乎的，特别是431的情况。因此梳理这几个异常的来源。

背景

在我们电商企业应用开发过程中，不可避免的遇到了现在行业里常用的蓝牙热敏票据打印机，这类打印机不同于标准的ESC/P编程打印机，往往会自定义自己的简化的TSPL操作指令并进行相对固定的动作，一方面是本事功能受限，另一方面也能让小票打印编程更简单。我们使用的一款打印机的指令设计就很直接，纯字符的：

//初始化打印区域
SIZE 58 mm,30 mm
GAP 2 mm
//清除图像缓冲区全部数据
CLS
//往图像缓冲区填写数据
TEXT 50,50,"4",0,1,1,"这是一行文字"
BITMAP 200,200,2,16,0,xxxxxxxxxxxxxxxxx //这是一张图片，图片是二值图二进制数据
BOX 100,100,200,200,5 //这是一个矩形框
QRCODE 20,20,L,4,A,0,"这是一个二维码"
//打印缓冲区图像1次
PRINT 1

背景：我们做一些辅助工具库时，为了对目标库进行最小的入侵，往往会通过方法交换来实现特定的节点完成特定的操作。这样的代码假设我们有一个Utils要入侵A，只需要U依赖A即可。但是偶尔会有这种情况，我们的Utils适配了ABCDE五个库，比如我是一个流量统计库，对这五个库的网络操作进行了抓取。但是我Utils并不适合直接依赖这五个库，而是期望用户实际引用到啥，我就统计啥。

因此，需要实现的是Utils不依赖目标库，也不依赖目标类，来实现方法交换。

在iOS项目开发过程中，我们总是会加入一些开发者工具相关的代码，通过DEBUG/TEST宏或者其他形式防止相关代码引入到线上。但是随着我们做组件二进制化对相关类进行编译后pod沉淀，相关代码的处理就麻烦起来了。

- 首先明确，组件二进制化是iOS工程化的整体趋势，不可阻挡

那对应的，对于有开发者工具区分的二进制pod，我们如何进行管理呢？

上一话http://lrdcq.com/me/read.php/106.htmWidgetKit是从StaticConfiguration入手的，而避开了实际上应该更常用的IntentConfiguration。而理解在WidgetKit中出现的Intent，显然不能按照Siri中的Intent去理解了。在WidgetKit中，Intent更多的是用来呈现长按配置菜单中的选项，简单的来说，Intent是一个配置表。如下图：

iOS14开放给开发者的大一统的小控件WidgetKit出来了。作为“抄袭安卓”的必不可少的一步。初探下苹果如何在偏向于安卓的高自由度，高可配，和自己风格的安全，隐私，高性能之间作出平衡，最终设计出的这个WidgetKit呢。

概览