ITFreeMan

分析APK大小工具 Analyz APK Android Studio 2.2自带的 Analyz APK  工具，可以查看 APK 各组成部分所占用的空间大小 使用  Build -> Analyz APK  选择 APK 文件，或者双击 APK 文件。

If you have ever tried to run a Cocos2d-x app in an Android emulator, you might be familiar with this error: INSTALL_FAILED_NO_MATCHING_ABIS. This happens because your emulator is using one architecture while your app is compiled for a different architecture. Specifically, most people use x86 Android emulators, because they’re faster than their ARM counterparts. In Cocos2d-x 3.15.1, the default architecture is armeabi. Let’s explore how to fix this. The Fix We need to tell our project to compile for other architectures. In order to do so, we need to edit two files. First, head over to your  application.mk . Open it up and find this line. APP_ABI := armeabi Change it to the following. APP_ABI := armeabi armeabi-v7a x86 Now find your  gradle.properties , and locate the following line. PROP_APP_ABI=armeabi Add the other architectures, separated by colons, and we’re good to go! PROP_APP_ABI=armeabi:armeabi-v7a:x86 Time to Recompile Open up Terminal and navigate...

原文： http://android.eoe.cn/topic/android_sdk 多种apk的支持是一个特点在Google Play，它允许你发布不同的APKs为你的应用匹配不同尺寸的设备。每个APK是您的应用程序的完整和独立的版本，但它们共享同一应用程序在Google Play上市，必须共享相同的包的名称，并签署具有相同的release key。此功能用在您的应用不能通过单一的APK来兼容所有设备的情况。 Android提供了许多的方式，您提供给尽可能多的设备。Android应用程序通常最兼容的设备上运行，用一个单一的APK，通过提供不同的配置替代资源（例如，不同的布局，为不同的屏幕尺寸）和Android系统的设备在运行时选择适当的资源。然而，在少数情况下，一个单一的APK是不能支持所有设备的配置，因为替代资源的APK文件太大（大于50MB）或其他技术的挑战，阻止了一个APK在所有设备上工作。 虽然我们鼓励您开发和发布一个单一的APK，支持尽可能多的设备配置，但是这样做有时是不可能。为了让您的apk尽可能多的支持不同的设备，Google Play允许你发布多种的应用，在相同的应用列表下面。Google Play 然后根据你在每个APK的manifest文件中声明的版本信息，适配出相对应的apk。 通过发布多个您的版本的apks应用，您可以： 不同的OpenGL纹理压缩格式，支持每个的APK。 支持APK的每个不同的屏幕配置。 每个的APK支持不同的平台版本。 目前，这是唯一的设备的特点，Google Play 支持 发布相同的应用程序有多个APKs支持。 注意：只有当你的APK是太大（大于50MB），你应当使用多个APKs支持不同的设备配置。使用单一的APK，以支持不同的配置的设备始终是最好的做法，因为它使简单的应用程序更新的应用的途径和让用户很明白该怎样操作（也让你的开发变的简单，避免开发和发布的复杂性） Read the section below about Using a Single APK Instead to consider your options before publishing multiple APKs 在发布前注意的内容 在你发布多个apks为同一个应用在Google Play，你必须理解一些关于怎样...

基本概念 RTT: 发送一个数据包到收到对应的ACK，所花费的时间 RTO: 发送数据包，启动重传定时器，重传定时器到期所花费的时间，称为RTO 对于segment的重传，重传的时间RTO设定是非常重要的，如果设置太短，可能会导致并没有丢包而重传，如果设置太长了，可能因为等待ACK而浪费掉很多时间，牺牲传输的效率。从思想上来讲，其实我们还是希望重传的时间需要稍稍的大于RTT就可以了。但是这个RTT没有什么可以使用的定值，他是不断变化的。 我们只能动态的进行设置，所以RTO只能是更加RTT来进行动态的设置，看下前辈们研究的RTT的计算方法 经典的算法 RFC793 1. 首先计算一个平滑的RTT称置为SRTT， alpha是一个平滑因子，取值为0.8或者0.9 SRTT = ( ALPHA * SRTT ) + ((1-ALPHA) * RTT) 2. 基于SRTT，计算出对应的RTO       RTO  = min[UBOUND,max[LBOUND,(BETA*SRTT)] 其中UBOUND是最大值，一般情况下为120s，LBOUND是最小重传值，一般情况下为1s，Beta取值为1.3~2.0. [ RFC793 ] 其实这个算法，在目前Linux系统协议栈的实现中并没有使用了，原因是存在着一些不足之处，具体弊端没有认真研究，有文章指出不明确是使用第一次发送ACK的时间，还是使用重传ACK的时间采样RTT， 也有文章指出在RTT变化比较大的网络，性能表现非常不好... 总之有缺点 Jacobaon/Karels 算法 1988年，Van Jacobson和Karels在Congestion Avoidance and Control这篇论文中提出一种新的算法[ RFC6298 ]， 第一次RTO计算方法, 假设RTT = R 1.  SRTT = R 2.  RTTVAR = R/2 3.  RTO = SRTT + max(G, K*RTTVAR) , K = 4 后续的RTO计算,假设当前的RTT为R'           RTTVAR = (1 - beta)*RTTVAR + beta*|SRT...