From 462d4c07882faf80b8aa4e4d9ec39ebd466e5910 Mon Sep 17 00:00:00 2001 From: Santiago Castro Date: Mon, 17 Apr 2017 23:22:50 -0300 Subject: [PATCH] Fix broken Markdown headings --- 2015-09-03/weixin_android1.md | 4 +-- 2015-09-03/weixin_android2.md | 54 +++++++++++++++++------------------ 2015-09-13_1.md | 12 ++++---- he_ji.md | 14 ++++----- 4 files changed, 42 insertions(+), 42 deletions(-) diff --git a/2015-09-03/weixin_android1.md b/2015-09-03/weixin_android1.md index b5cb4ed..ecb340b 100644 --- a/2015-09-03/weixin_android1.md +++ b/2015-09-03/weixin_android1.md @@ -1,11 +1,11 @@ -#[微信ANDROID客户端-会话速度提升70%的背后][reflink] +# [微信ANDROID客户端-会话速度提升70%的背后][reflink] 转载自：WeMobileDev -#背景 +# 背景 * 打开会话速度慢 * 在同一个会话有较多的历史消息下，各种查询，更新,删除等操作，速度明显下降。 diff --git a/2015-09-03/weixin_android2.md b/2015-09-03/weixin_android2.md index b02d3ba..add37b3 100644 --- a/2015-09-03/weixin_android2.md +++ b/2015-09-03/weixin_android2.md @@ -1,6 +1,6 @@ -##Android微信智能心跳方案 +## Android微信智能心跳方案 转载自：WeMobileDev @@ -27,18 +27,18 @@ 好了，废话了很多，下面分享一下微信的智能心跳方案细节。由于字数比较多，建议大家使用PC版微信查看。 -##1.主要目标## +## 1.主要目标 ## 本方案的主要目标是，在尽量不影响用户收消息及时性的前提下，根据网络类型自适应的找出保活信令TCP连接的尽可能大的心跳间隔，从而达到减少安卓微信因心跳引起的空中信道资源消耗，减少心跳Server的负载，以及减少部分因心跳引起的耗电。 主要方法是参考WhatsApp和Line中有价值的做法，结合影响TCP连接寿命的因素，实现Android微信后台自适应心跳算法，同时使用GCM作为辅助通道增加新消息通知的可靠性。 -##2. WhatsApp、Line、微信的Push策略分析 -###2.1 WhatsApp +## 2. WhatsApp、Line、微信的Push策略分析 +### 2.1 WhatsApp 在不支持GCM的设备上，采用和微信类似的长连接+心跳策略，WIFI和手机网络下的心跳间隔都为4分45秒，心跳5次后，主动断开连接再重连。 在支持GCM的设备上，主要靠GCM来激活WhatsApp，WhatsApp启动后，会建立一个与服务器的长连接，直接通过此长连接发送Push消息，这个长连接10分钟无消息就会主动断掉，且这十分钟内不做心跳，断掉后WhatsApp客户端和它的服务器不再有连接。当有消息时候，服务器发现没有长连接会发送GCM消息，手机收到GCM消息后，会重新建立长连接来收取消息，10分钟无消息会再断开，如此循环。 -###2.2 Line +### 2.2 Line 从测试中发现Line在国内、台湾、美国使用了不同的策略。 @@ -61,10 +61,10 @@ **3、台湾（不使用GCM）：** 从IBG同事win和guang提供的测试数据中看到，台湾使用的策略跟国内的轮询策略类似。 -###2.3 微信 +### 2.3 微信 微信没有使用GCM，自己维护TCP长连接，使用固定心跳。 -###2.4心跳典型值 +### 2.4心跳典型值 | | WhatsApp | Line | GCM | | -- | -- | -- | -- | @@ -72,14 +72,14 @@ | 手机网络| 4分45秒 | 7分钟 | 28分钟 | -###2.5Line、WhatsApp、微信Push策略的优点 +### 2.5Line、WhatsApp、微信Push策略的优点 **a）微信：**当前心跳间隔比竞品短，所以微信在新消息提醒上会最及时。 **b）使用GCM：**Line和WhatsApp使用GCM策略的最大优点就是省电，以及减轻系统负荷（减少后台应用数目）。 **c）Line：**Line的轮询策略，优点是当Line处于活跃状态时，及时收消息。当Line处于不活跃状态时，省电。 -###2.6Line、WhatsApp微信Push策略的不足 +### 2.6Line、WhatsApp微信Push策略的不足 a）微信当前心跳频率相对竞品较大，在耗电、耗流量，占用信令通道等方面有所影响。 @@ -88,8 +88,8 @@ b）Line的轮询策略，导致的问题是消息可能会延迟接收，测试 c）WhatsApp和Line使用Push拉起一个定时长连接策略，缺点是要依赖Google的Push服务，如果Google的Push服务不稳定，消息也会延迟接收。 d）在国内的移动和联通2G网络下，由于运营商的策略，GCM长连接频繁断连，WhatsApp的Push消息很不及时，体验非常差。 -##**3. GCM研究** -###3.1 GCM特点 +## **3. GCM研究** +### 3.1 GCM特点 a）Android2.2以下的手机不支持GCM，2.2到3.0需要安装Google Store并设置Google帐号，4.04及以上版本不需要设置帐号也能支持。 @@ -98,14 +98,14 @@ b）GCM只传递数据（可以传递小于4kb的数据），对这些数据的 c）Android应用不需要运行就可以接收消息(通过Android广播)。 d）GCM不保证发送的消息的顺序，也不保证消息一定能够推送到手机。 -###3.2 GCM心跳策略以及存在的问题 +### 3.2 GCM心跳策略以及存在的问题 a）用心跳保活长连接，心跳间隔为WIFI下15分钟，数据网络下28分钟。 b）Google可以改变所有Android设备的心跳间隔值（目前还未改变过）。 c）GCM由于心跳间隔固定，并且较长，所以在NAT aging-time设置较小的网络（如联通2G，或有些WIFI环境下）会导致TCP长连接在下一次心跳前被网关释放。造成Push延迟接收。 -##3.3 GCM的可用性及稳定性 +## 3.3 GCM的可用性及稳定性 目前测试发现GCM在国内可用性不高，原因有： @@ -120,14 +120,14 @@ d）某些运营商可能限制了5228端口，移动3G/2G下，发现几乎无 在美国3G网络下抓包的24小时，GCM的连接极其稳定，24小时内GCM长连接未曾断过，在台湾3G网络下抓包14个小时，GCM连接也只断过一次。WhatsApp用户在此类地区网络下客户端可以获得很及时的Push通知。 在中国电信3G下抓包，大部分时间GCM连接都比较稳定，只会因为偶尔的DHCP造成断连现象，由于频率很低(平均数小时才发生一次)，对Push体验的影响不大。 -###3.4 GCM Server类型 +### 3.4 GCM Server类型 GCM提供两种Server模型： **a）HTTP Server : **使用同步接口发送HTTP请求，一次请求可以发给最多1000个设备。 **b）XMPP Server :**使用异步接口发送请求，只支持对单个设备（或同一个用户的多个关联设备发送），发送请求并发数须小于1000，支持设备到云端Server发送数据。需要Google将我们的发送Server加入白名单。 -##4.微信可能的改进点探讨 +## 4.微信可能的改进点探讨 微信Push的优化主要有几个优化点： @@ -136,14 +136,14 @@ a） 公共Push通道 b） 使用GCM Push作为辅助通道 c）自适应心跳间隔优化 -###4.1 公共Push通道 +### 4.1 公共Push通道 由于GCM在国内的可靠性很低，现在国内Android上的Push基本上是各自为政，很多软件都自己实现Push。导致手机被经常性的唤醒，耗电耗流量严重。 市面上已经有很多第三方的公共推送服务，大家可以选择一个适合自己应用的推送服务。腾讯也有信鸽和维纳斯组件，大家在选择方案的时候可以对比下。 最终因为我们国内外使用一套方案，并且是辅助公道，所以我们选择使用GCM。 -###4.2 使用GCM Push作为辅助通道 +### 4.2 使用GCM Push作为辅助通道 当前使用GCM的成本不大，可以使用GCM作为辅助通道来增加新消息的及时性。 @@ -152,9 +152,9 @@ c）自适应心跳间隔优化 微信Server在发现长连接失效的情况下，可以使用GCM 作为辅助通道通知客户端有新消息，客户端收到push通知后做一次sync。 只利用GCM来激活微信，不传递消息的具体数据，要控制给同一设备发送GCM通知的时间间隔(如五分钟)。 -###4.3 自适应心跳间隔优化 +### 4.3 自适应心跳间隔优化 -####4.3.1影响TCP连接寿命的因素 +#### 4.3.1影响TCP连接寿命的因素 在Android下，不管是GCM，还是微信，都是通过TCP长连接来进行Push消息的，TCP长连接存活，消息Push就及时，所以要对影响TCP连接寿命的因素进行研究。 @@ -170,7 +170,7 @@ c）自适应心跳间隔优化 手机网络和WIFI网络切换、网络断开和连上等情况有网络状态的变化，也会使长连接变为无效连接，需要监听响应的网络状态变化事件，重新建立Push长连接。 -####**4.3.2 心跳范围选择** +#### **4.3.2 心跳范围选择** 1、**前后台区分处理**： @@ -232,7 +232,7 @@ successStep——稳定期后的探测步长 ü **successHeart是NAT超时临界值：**因为我们现在选择的是一个比successHeart稍小的值作为稳定值，所以在计算过程中可以避开临界值。当运营商在我们后台稳定期将NAT超时调整为我们当前计算值，那么由于我们每周会去向下探索，所以下一周探测时也可以及时调整正确。 -####**4.3.5 冗余Sync和心跳** +#### **4.3.5 冗余Sync和心跳** 在用户的一些主动操作以及联网状态改变时，增加冗余Sync和心跳，确保及时收到消息。 @@ -241,17 +241,17 @@ successStep——稳定期后的探测步长 2、当微信切换到前台时，做一次Sync。 3、联网时重建信令TCP，做一次Sync -##**5. 可能存在的风险及预防措施** -###5.1 DHCP租期因素 +## **5. 可能存在的风险及预防措施** +### 5.1 DHCP租期因素 1、**问题：**根据目前的测试结果显示，安卓不续约到期的IP Bug，会导致TCP连接在不确定的时间点失效，从而会导致一次心跳失败。 2、**预防：**统计后台稳定期的心跳成功率，上报给后台。后台可以按地区分网络监控这个指标的波动，并且后台可以根据不同的波动，动态调整某区域特定网络下可选的心跳区间。 -###5.2 其他影响TCP寿命的因素 +### 5.2 其他影响TCP寿命的因素 是否有遗漏的因素？欢迎各位联系我反馈。 -##**6 附录** -###6.1 附录A——NAT超时介绍 +## **6 附录** +### 6.1 附录A——NAT超时介绍 因为 IP v4 的 IP 量有限，运营商分配给手机终端的 IP 是运营商内网的 IP，手机要连接 Internet，就需要通过运营商的网关做一个网络地址转换(Network Address Translation，NAT)。简单的说运营商的网关需要维护一个外网 IP、端口到内网 IP、端口的对应关系，以确保内网的手机可以跟 Internet 的服务器通讯。 @@ -272,7 +272,7 @@ NAT 功能由图中的 GGSN 模块实现 长连接心跳间隔必须要小于NAT超时时间(aging-time)，如果超过aging-time不做心跳，TCP长连接链路就会中断，Server就无法发送Push给手机，只能等到客户端下次心跳失败后，重建连接才能取到消息。 -###6.2 附录B——安卓DHCP的租期（lease time）问题 +### 6.2 附录B——安卓DHCP的租期（lease time）问题 目前测试发现安卓系统对DHCP的处理有Bug： diff --git a/2015-09-13_1.md b/2015-09-13_1.md index db7417c..429e406 100644 --- a/2015-09-13_1.md +++ b/2015-09-13_1.md @@ -1,10 +1,10 @@ -#编写一个无法卸载的App – 设备管理器漏洞 +# 编写一个无法卸载的App – 设备管理器漏洞 原文出处： [BQ Zhang（@2BAB）](http://2bab.me/2015/02/09/app-cannot-be-uninstalled/) 前两天某朋友发现手机有个app无法卸载，后知其因设备管理器激活导致，遂去尝试取消，但却在取消那刻卡机。反复折腾之后，只能重刷。后来他发了一篇关于设备管理器bug的文章给我，便有了如下一番折腾。 -##尝鲜 +## 尝鲜 文章[《Android 学习 设备管理器勾选后不能再取消了》](http://androidmaster.iteye.com/blog/2035381)（作者：带个回家）大致意思是： @@ -23,7 +23,7 @@ public CharSequence onDisableRequested(Context context, Intent intent) { 在此之前，我并没有接触过设备管理器的功能，参考了 API Guides 的 [Device Administration ](http://developer.android.com/guide/topics/admin/device-admin.html)，以及 [DeviceAdminReceiver](http://developer.android.com/reference/android/app/admin/DeviceAdminReceiver.html) 的 API 后，试着写了一个跟上述文章一样的 app，4.4 & 5.0均测试失败，可以正常取消激活。 -##再战 +## 再战 搜索，找到[《Android设备管理器漏洞》](http://blog.csdn.net/androidsecurity/article/details/9124747)（作者：Jack_Jia）另一篇讲解此问题的文章。文章提到： @@ -47,7 +47,7 @@ public CharSequence onDisableRequested(Context context, Intent intent) { 4.4 & 5.0测试失败，设备管理器无法激活（代码激活不会弹出，设备管理器又找不到）。 -##三战 +## 三战 继续搜索，发现百度安全实验室一篇文章[《Android设备管理器漏洞2》](http://blog.csdn.net/androidsecurity/article/details/39962571)。文章提到： @@ -107,11 +107,11 @@ public CharSequence onDisableRequested(Context context, Intent intent) { 而文章开头提到的流氓软件，实则是跳转到一个所有按钮无效的自定义全屏界面（不是我这样跳到设置界面），使用数字软件无法解决问题。 -##总结 +## 总结 日后看到设备管理器激活申请定要小心三分，本文提及内容请勿不正当使用。 -##相关下载 +## 相关下载 [源码Gist](https://gist.github.com/2BAB/786513de79b7bfd82c3f) diff --git a/he_ji.md b/he_ji.md index db0e431..1fa53ad 100644 --- a/he_ji.md +++ b/he_ji.md @@ -1,24 +1,24 @@ # 合集 -##ReactNative合集 +## ReactNative合集 * [React-Native学习指南](https://github.com/ele828/react-native-guide) * [Awesome React Native](https://github.com/jondot/awesome-react-native) * -##Javascript合集 +## Javascript合集 * [FEX技术周刊](http://fex.baidu.com/weekly/) * [JavaScript 资源大全中文版](https://github.com/jobbole/awesome-javascript-cn) -##C/C++合集 +## C/C++合集 * [C 语言资源大全中文版](https://github.com/jobbole/awesome-c-cn) -##Java合集 +## Java合集 -##Android合集 +## Android合集 -##iOS合集 +## iOS合集 -##Python合集 \ No newline at end of file +## Python合集 \ No newline at end of file