http://wx1.sinaimg.cn/large/a32300cdly1g3hanc7jpkj20ll0h87fr.jpg

看得过去

既然是 im，不但要发送，还要有推送。基本上可以不用考虑去 https?里面找了😂

fiddler 里面看看有没有 websocket，有就双击打开可以看到收发的数据。😒

不过用的 websocket 的可能性也比较低，可能是 app 里面的普通的一个 socket 长连接。😁

@dobelee #5 看起来像 java 的库，但我看 https://www.jianshu.com/p/bb9ad9b8720f 里面的解释，发帖子的时候就把锅甩给了 Android，抄录一段：

““““
然后 google 了一下，从回答中探索答案，发现 HttpURLConnection 从 Android 5.0 后其 http 和 https 是使用 okHttp 实现的,引用作者的回答：

......

根据上边英文，我们知道 Android 重新导出了新的 jar，jar 中将 com.squareup 这两级目录改成 com.android。所以我们直接找 com.squareup.okhttp.HttpsHandler，在源码中果真找到了改 java 文件：
”””

可以发现他记录的 HttpURLConnection 底层实现会根据 Android 版本不同而不同，因此 Android 的锅可能性比较大。

============

另外“底层”算是一个相对概念吧，我们上面在写业务代码，用到了 Android 里面的东西，那么那些东西应该就算底层了吧，我是这样理解的。

============

这是一个缺陷（至少我现在用到的语言中，只发现 Android 里面有这个问题）。

@nicevar 被你一眼看穿了，打错了一个字

@nicevar 被你一样看穿了😁 刚特意翻译了一下 HttpURLConnection 这个类的注释，里面确实写了 `http 不会跳转到 https 反之亦然`。不是不看文档，只是出现这种问题的时候往往难以找到能快速解决问题的位置。

针对这样的低级、另类的缺陷，喷一喷也无妨。妄想想通过寥寥数笔的注释把底层的无能转嫁给上层的开发者，这是难以理解的。

在没有因为这个问题而产生问题的时候，估计很少有开发者在用到 HttpURLConnection 时候会关注到这个问题。

但这锅是 Android 还是 java 的，我不知道，目测 Android 的锅可能性比较大。

就帖子标题来看：

这是一道阅读理解题目而已，哪有唯一、标准答案？

说不定特定场景下，调用了一下接口，然后人工 拿 U 盘拷数据 是最佳解决方案也不一定呢？

你已经回答了，但“被告知不对” ，此时你应该怼回去😊

在用了第三方的代码时：同意“这个机制就是个败笔”，俩种类型谁都可以用（存在选择性往往代表存在歧义），最后成了一锅乱炖😂

鬼才知道有没有人往外面扔了个 Runtime Exception 炸弹😒😒😒，不该用 try catch 的地方也被迫要套个套子才安全😁

最终结果就 java 会趋向于和 C#类似异常机制，任何异常几乎不看源码压根不知道要不要捕获😒

“传大文件”。。“语言 java ； 自己写的老丢包”

既然是自己写的，稍微改改：

分片，每片 10m，2 个线程并行发数据，每片单独校验 hash，发完最后一片再校验一遍整个文件的 hash

注：接收端创建一个同等大小的大文件，收到数据就写入到对应位置，省去了合并文件这个慢操作。

（原生支持断点续传）

@beryl #7 呆板😂

根据单点或集群分别实现 MyRedisClient 底层调用逻辑
MyXXOO_RedisClient implements MyRedisClient 里面调用了 RedisClient 底层逻辑
MyXXOO_RedisClusterClient implements MyRedisClient 里面调用到了 RedisClusterClient 底层逻辑

通过配置给 client 动态赋值
private MyRedisClient redisClient=new (MyXXOO_RedisClient or MyXXOO_RedisClusterClient)

interface MyRedisClient{
定义需要的 redis 功能操作方法
}

根据单点或集群分别实现 MyRedisClient 底层调用逻辑
RedisClient implements MyRedisClient
RedisClusterClient implements MyRedisClient


通过配置给 client 动态赋值
private MyRedisClient redisClient=new (RedisClient or RedisClusterClient)


别说我现在用的就是这么干的。。。不过我用 c#写的一套
http://wx4.sinaimg.cn/large/a32300cdly1g3emjkxd4ij20vd0al75w.jpg

@viakiba base64 编码也算是一种加密！不信来一段试试：

5oiR5LiN5L+h5L2g6IO95LiA55y855yL5Ye65oiR5Yqg5a+G55qE5q2k5q615YaF5a65

在不知道解密算法的前提下，要得到明文是很困难的，哈哈😉

----------------


此后端分页要求在合理的场景下不算奇葩。也许是增加别有用心的人的利用难度而已，算是低成本高回报；加密算法也许哪天可以不用 base64 了，换成别的，或者算法一天一换。

另一个心里安慰：用户看不到 url 里面的页码。。。看起来蛮高大上😂

目测 “拖拽” 方式改变文字的 “位置、大小、颜色” 是一个伪需求（同一种证书应该书写 位置 大小 是固定的吧😒 颜色就不知道了，如果不是，那每次都要拖来拖去，那也太好玩了）。简单点的给个输入框、下拉框 供填写和选择就 ojbk 了。制作好证书背景图和对应的坐标、字体配置，外加一个 canvas、一个导入 file input、一个导出 button，再加一个 jszip 打压缩包。纯原生手撸 js。一个 html 文件足以，服务器也可以省了😜

（ v2 的 append 咋不见了）其实能做出功能，用谁家的都无所谓，但花了几天功夫对接的友盟太让我失望了，文档再烂一点也无所谓，但主要问题在于 sdk 代码内部的问题（ sdk 的 jar 已被混淆了，勉强能看），对接摸黑的开发过程中，发现了他们家的太多 bug：
https://ws2.sinaimg.cn/large/006Xmmmgly1g36r30agjej30q60fy40n.jpg
https://ws4.sinaimg.cn/large/006Xmmmgly1g36r3r4hkej30r60f70u5.jpg


昨天晚上看了一下他们家的混淆配置，还没发现哪家的敢这么写，太霸道了：
https://ws3.sinaimg.cn/large/006Xmmmgly1g36r2zub3qj30le0a8jrw.jpg

今天下午又研究了一下，实在忍无可忍了，心脏不好，还是砍掉保平安。

@devjia #10 这波操作够骚😉

那些冒绿光的 统统买进 再不买人家就倒闭了😂

没有作品，但也算是参与了微软.Net Core 开发（修了一个 bug ）。。。不知道算不算是个优势，虽然只多写 3 个字符
https://github.com/dotnet/corefx/commit/94b1f1eae84fd4823cfa2bbdde6fc87c46b57908 😉

我写的这几个字符已经正式发布了：
https://source.dot.net/#System.Net.Mail/System/Net/Mail/SmtpClient.cs,967 😎

用 zip 读自身 apk 文件内容，不知道可不可行

目测是把数据分片发送到就近的 N 台服务器（然后下载方又连到了另外他那边就近的 N 台服务器）。。感觉好像还是有使用者实际的物理带宽限制吧。。所以通篇都是远距离数据传输，因为平时传文件蛮难跑满，就近加一下速感觉飙升明显，不知道猜的对不对。我用 FileZilla Server😎

@DouO #12 和人家比惨，我从来没输过。。不过看在你开源了一年半这么久的份上，好像你的这个库更惨些，马上达到两位数 star😉

GitHub： https://github.com/xiangyuecn/Android-UsesPermission

方便好用的权限处理库。