又到了一年的年末,翻开去年的记录,吃惊的发现去年竟然只看过 16 本。今年年初的时候,计划阅读 100 本书,也的的确确一直坚持了一年,中途可能因为工作耽误了一些进度,但也一直坚持到现在。然而遗憾的是到目前为止,距离 2016 年结束还有短短一个礼拜的时候,又发生了和去年一样的问题,欠下了 10 本左右的债。
耳边总有人说,“为什么总要在意那几个数字?”,而对我而言,那不仅仅是那几个数字,他是年初的一句承诺,对整个年度的一句承诺,如果不能达到这个承诺,那过去说过的话还有什么意义。
今年的书单印证了一句话“因为一本书,爱上一个人,迷上一个类型”,我也曾经在 G+ 上说过,多少年了,还是在三年级到初中的那段时间疯狂的迷过 Verne,多少年的时间里因为学业,因为各种,再难爱上一位作家,再难爱上一段文字。而今年因为一本《解忧杂货铺》让我知道了东野圭吾,也打开了我认知的另一扇窗户。今年的近 90 本中有很大一部分都是东野的作品。而有趣的事,和东野的经历一样,让我们结识悬疑推理的经历竟然如此的相似,这一段经历可以参考 《我的晃荡的青春》,东野的青春竟然也如此的淘气和真实。
而我从年初,从东野最著名的小说开始读《嫌疑人 X 的献身》、《白夜行》在到加贺恭一郎系列,再甚至到不怎么出名,甚至默默无闻的早期作品《以眨眼干杯》《沉睡森林》,再到毒舌三部曲《毒笑小说》《黑笑小说》《怪笑小说》,东野圭吾的书读不到尽头也几乎没有重复,这让我佩服的五体投地。
按时间排序读过
今年的书摘如果都放到这边可能有些多,甚至没有什么必要,有些内容经过整理和摘录,我都放到了 Evernote 中。有些比较长的内容,也有格式化。
其他小说
但回头看自己今年的书单,深感技术类书籍占比略少,去年至少系统的看过 Bash,和基础 Linux,而今年除了看一些基础的 Java 知识,再没有系统地学习一项内容,除了年末恶补了一些 Spring MVC 和 Redis, HBase 的相关知识。因此在制定明年的计划时要讲技术书籍内容比例提高到 10% 左右,有些书值得反复阅读思考和实践,技术类的书既有消费品也有值得反复品味的内容。
今年读过的技术类书:
而其他摄影的类:
还有一些就不列 了。
今天突然收到 Google Play Store 发来的邮件通知,说违反社区准则,原因是没有隐私政策说明。全文如下:
Our records show that your app, {Application Name}, with package name {package name}, currently violates our User Data policy regarding Personal and Sensitive Information.
Policy issue: Google Play requires developers to provide a valid privacy policy when the app requests or handles sensitive user or device information. Your app requests sensitive permissions (e.g. camera, microphone, accounts, contacts, or phone) or user data, but does not include a valid privacy policy.
Action required: Include a link to a valid privacy policy on your app’s Store Listing page and within your app. You can find more information in our help center.
Alternatively, you may opt-out of this requirement by removing any requests for sensitive permissions or user data.
仔细研读几遍之后发现其实只要增加一条链接,说明一下隐私政策。其实主要的原因就是应用中使用到了 android.permission.GET_ACCOUNTS,android.permission.READ_CONTACTS
这俩权限,都是 Firebase SDK 里卖弄登陆要用到的。
仔细研究了一番 Google 的隐私政策, Instagram 的隐私政策 。
然后随着大概意思拷贝了一份。
Pdnsd 是用来缓存本地DNS信息的 DNS 服务器。和 BIND 和 dnsmasq 相比,Pdnsd 在重启之后依然可以保存 DNS 缓存,名字中的 p 表示 persistent。
Ubuntu/Debian 系下使用如下命名安装:
sudo apt install pdnsd
Ubuntu 18.04 中 pdnsd 似乎并没有在仓库中。
默认配置地址 /etc/pdnsd.conf
。
下面配置示例,后面的分号不可缺少。
配置示例:
global {
perm_cache=1024; # 要缓存多少DNS信息
cache_dir="/var/pdnsd";
# pid_file = /var/run/pdnsd.pid;
run_as="nobody";
server_port = 1053;
server_ip = 127.0.0.1; # Use eth0 here if you want to allow other
# machines on your network to query pdnsd.
status_ctl = on;
# paranoid=on; # This option reduces the chance of cache poisoning
# but may make pdnsd less efficient, unfortunately.
# query_method=udp_tcp;
query_method=tcp_only; # 使用 TCP 方式去查询 DNS 服务器
min_ttl=15m; # Retain cached entries at least 15 minutes. 缓存 DNS 最短有效期
max_ttl=1w; # One week. 缓存 DNS 信息最长有效期
timeout=10; # Global timeout option (10 seconds).
neg_domain_pol=on;
udpbufsize=1024; # Upper limit on the size of UDP messages.
}
server {
label= "googledns";
ip = 8.8.8.8, 8.8.4.4;
timeout=30;
interval=30;
root_server = on;
uptest = ping;
ping_timeout=50;
purge_cache=off;
exclude=.cn, .douban.com, .taobao.com
}
Pdnsd 读取配置时,优先级从上到下,上面的 DNS 服务器配置优先于下一层。
pdnsd 需要至少知道一个上游 DNS 服务器用来收集信息
/etc/resolve.conf
中指定了一些DNS服务器地址,在配置 pdnsd 的时候,修改为
nameserver 127.0.0.1
启动 pdnsd 服务
/etc/init.d/pdnsd start
nslookup www.douban.com 127.0.0.1
或者
dig @localhost -p port www.douban.com
如果返回正常,和 webdnstools 比照,则说明配置成功
清空本地缓存
sudo pdnsd-ctl dump # Print information stored in the cache about name.
sudo pdnsd-ctl empty-cache
查看端口占用
sudo netstat -anp | more
pdnsd 只能优化 DNS 解析,并不能避免 DNS 污染。
最近 Evernote, WizNote 纷纷宣布收费,一时间让我手足无措,原本按部就班的一些流程纷纷被打破。但是笔记和摘录总是那样的顺其自然,在翻看自己曾经摘录过得一些整理法则的时候,发现其中有些问题确实自己也已经犯下,在电脑玩物的《Evernote 超效率数位笔记术》书中,作者总结了“Evernote 用户最容易犯的 10 个错误”:1
对于这些错误,最严重的就是第一条,因为 Evernote 和 WizNote 的网摘插件实在太好用,在摘录了大片的内容之后,就忘记整理总结,躺在笔记本中就“死亡”了。幸而这些天这么折腾让我想起了那些笔记墓地,也正好抽出时间来整理一下。正像最后写的那样,”笔记是为了在以后用到,如果用不到,那便是在做无用功”。
早之前就总结过分类和标签,这两者在使用上还是有些区别的,最直观的区别就是一篇笔记只能属于一个分类,而可以归属于多个标签。分类是方便我们整理,而标签是便于我们检索和记忆,同样分类是给我们自己看的,而标签是给机器看的。因而建立一个合理的分类是非常必要的。之前看电脑玩物使用标签整理法,在我个人使用一段时间之后便放弃了,转而使用分类管理,而在过程中打上标签。
根据自己的使用,可以将笔记划分为不同的分类:
等等分类,每篇文章,在未处理之前都在未分类中,在处理完之后都有自己的归属。
这里使用购物清单来作比喻,对于使用记事本来做类似 TODO list 这样的事情来说,没有比使用标签来得更加方便的事情。大部分人可能已经习惯了 List 这样的 Todo 清单,但是对于一件需要长期进行的计划来说,单一的清单可能已经完全不能满足需求。因此才出现了 Trello 这样的多 Board 的清单列表。而对于记事软件比如 Evernote 或者 Wiznote 来说,没有了 Trello 这样的多列待办清单,使用 Tag 来模拟也是可以轻易的实现的。
我的标签命名方式从电脑玩物学来,使用如下:
对于这样的分类能够一目了然并且能轻松快速的找到想要的内容。而使用“!”这样的方式不仅增加了趣味,也让标签更加形象,”$” 就表示和购物相关。
而对于购物清单的子标签中分成想要,调查,不需要,满足四个标签,对于我自己,当在平时浏览网页,阅读 RSS,或者好友推荐,甚至广告中获取某一个产品时,优先添加到想要的标签中。而第二个调查标签为自己在调查想要的产品时可能主动浏览或者搜索的重要内容。而调查的内容可能有两种归宿,一种是在调查过程中发现确实不需要,最后将内容添加到不需要中,另外一种就是为最后列出了需要购买的几点理由,而不得不买时,将内容拖到满足中,并完成购物。当且仅当物品出现在调查中,并且有几点强烈需求时才能将其拖入到满足中。
对于文档标题,使用物品内容 + 型号 + 价格来标识。对于同一件物品使用尽量同一个文档来保存。比如文档” Dji Marvic Pro 6999“ 在想要中记录。然后可能会调查他的摄像分辨率,飞行高度等等参数然后记录。当然最重要的是列出需要购买的理由,不单纯仅限于玩一玩啊。
前段时间处理和广告相关的业务,接触到一些名词,网上也有一些解释,归纳下也好。
Mille is Latin for “thousand” ,千人浏览计费(impressions), 1000人观看价值。 1元/CPM 表示,每千人次观看 banner 广告,则收费1元。每CPM 收费标准不一,国际每 CPM 收费 5美元到200美元不等。一般网络中热门位置广告横幅,视频插播广告,移动端 banner 广告等等通常使用 CPM 收费模式。
对于广告载体,如果有大流量并且广告投放商更加关注品牌曝光率而不是直接进行交易,CPM比较合适。
点击一次计费,对于大品牌广告投放商来说,这明显是不划算的方式,不可预估广告花费。CPC 是购买广告低风险的一种方式,只需要为有效点击付费。 Google 的 AdSense 就是最大的 CPC 市场。
按广告投放实际效果,按有效订单或者有效回访问卷或者有效注册会员等等而定,不限制广告投放的数量。CPA 方式下会计算 effective CPA,简称 eCPA,用来计算投资回报。也就是说,如果通过广告卖出了 5 份产品,那么 eCPA 是 $50 / 5 sales = $10 per sales. 如果能够从每笔交易中获取超过 $10 的利润那将是一份成功的广告投放,而如果没有,那么则需要重新思考市场策略。
每次安装成本计费,常见于手机App 安装。
秒针,admaster, Double Click 等。
根据 Tampermonkey 在Google Code页面的介绍,Tampermonkey 是一款在 Google Chrome 和 Chromuim 浏览器中提供“油猴子脚本”支持的工具。Tampermonkey 是 Google Chrome 中最流行的一款脚本管理插件。它的 API 完全兼容“油猴子脚本”,它还加入更多的 Chrome 本身不支持的用户脚本功能,比如 GM_registerMenuCommand
和 GM_xmlhttpRequest
这两个函数。
安装地址: Chrome Web Store
Tampermonkey is a tool that provides Greasemonkey script support for Google Chrome and Chromium Browser. It's API is fully compatible to Greasemonkey, including GM_registerMenuCommand, GM_xmlhttpRequest with cross domain support and access to the unsafeWindow object.
当用户浏览网页时,会从服务器上下载脚本,并在本地运行,这种脚本我们会称之为网页脚本。与网页脚本不同的,用户脚本本身就在客户机上,不需要下载,而且如果不对其做限制,可用在所有网页上。浏览器用户脚本通常使用 Javascript 语言编写。
通过编写用户脚本,可以很大程度上提高上网体验。譬如使用 Userscript 可以实现网页自动翻页、文字翻译、页面预读、看图增强等等有用、有趣的功能。
Userscript 虽然很自由很强大,但出于安全性原因,使用的时候会有些限制,如 Userscript 不能操作文件、不能操作剪贴板等。
参考
Features:
- manage and edit all your userscripts
- enable and disable your scripts with 2 clicks
- easily sync you scripts between different Chrome instances
- search scripts from userscripts.org by URL (with TamperFire enabled)
Tampermonkey 何时同步:
1) before every TM update check
2) whan a script is changed locally
3) when TM starts
4) every 5h (will become configurable)
参考
找到你想要安装的用户脚本,例子中使用“Download YouTube Videos as MP4”脚本,更多推荐脚本可以看我这篇文章,一下在 Chrome 中执行。
到了这个界面可以点击右上角的“Install”,然后会自动调用 Tampermonkey
点击“OK”
这个界面可以看到脚本要求的权限和版本信息等等信息。点击“OK”整个安装过程就结束了。
最后晒晒我的脚本
如果想要深入了解一下油猴子用户脚本,可以参考一下这本书《深入浅出 Greasemonkey》
作为一个坚定的 Android 使用者,最近想要尝试一下 iOS,只有尝试过之后才有对比,有对比才能比较出好坏。于是乎记录下从一个 Android 重度使用者,转用 iOS 遇到的一些问题和解决方案。以下行文的结构按照提出问题,寻求解决的过程及最后的解决方案来规划。
通过设置 Google 账号同步联系人,但是短信和通话记录暂时无法找到方法备份恢复。幸而我的所有通讯录都有云备份,轻松的通过账号登陆就可以完成通讯录的迁移,但是因为短信和通话记录相对不是太重要,所以暂时还不需要迁移过去。并且 Android 端的短信和通话记录通过 SMS Backup+ 备份到了 Gmail 和 Google Calendar,所以也不存在丢失问题。
直接使用苹果AppleId官网,可以轻松注册美区账号。在手机首次登陆时,选择 none,不使用信用卡登陆即可。原本有一个美区的账号的,但是手贱转回了国内,无奈只能再注册一个了。
而苹果 iTunes 账号分区和 Google Play Store 分区的困难程度也还是差不多的,但是明显 iOS 上切换账号起来比较麻烦。
最重要的部分都在于此,但是因为平时使用的应用,基本都是跨平台的,因此也没有遇上什么比较困难的问题,登陆应用内的账号,云同步一下数据基本就完事了。这里要分享一些 must have app,基本都是跨平台的
所有的这些,我登陆一下账号,我想要的数据都来了。而剩下的其他社交类,工具类,修图类基本都能找到。
对于iPhone 的Home 键,我实在是无法习惯,可能是我被 Android 的 back 键和多任务切换的 recent 键惯坏了。但在 iOS 上返回操作和多任务切换在我看来是非常费劲的一件事情。iOS 的返回操作在我努力使用一天之后,大部分的情况下可以使用“从屏幕左边缘向右滑动“来进行返回操作,但对于我这样一个右手使用者来说,单手操作非常非常吃力,并且有的时候,比如在照片浏览的时候这样的操作却又是无用的。而对于弹出窗口,完成返回的操作按钮可能出现在左边,也可能出现在右边,这让返回操作异常困难,经常需要双手或者异常困难的手势去完成一个返回或者完成的操作。
比如下面的几张截图,需要完成一个返回或者完成的操作,左边,右边,滑动都出现了。并且当从一个应用跳转到另外一个应用的时候,你会注意到状态栏多出一个返回来,而那个返回”竟然是可点击“的,可以用来返回上一个应用。这对于我这个 Android 重度使用者来说完全无法适应,原本使用 Back 键能够完成的事情,现在需要我选择三四种方式,还需要分不同场合选择使用。
再说回到 Home 键本身, Home 键有如下的操作方式:
这些操作在 Android 系统上分别为四个按键,而在 iOS 端全部糅合到一个按键中,难怪我实在无法适应 Home 键。当然 Android 的 Back 键在推出的时候,也有很多人,甚至开发者也会产生疑惑,甚至开发文档有整整一页说明返回按键的流程,但是依然不妨碍用户使用它。甚至在很早的时候我在看到 Android 和 Chrome 中按钮设置的时候,就感觉到 Android 和 Chrome 的按钮设置太像了。Chrome 很简洁,保留的按钮并不多,但是返回按钮,主页按钮,以及标签页都在非常重要的位置,而这三个按钮也正是 Android 得以保留的三个按钮。
而 Android 的这个按钮让用户得以在应用中跳转而不会迷失,我甚至给举例,比如我在 Google+ 中看到有一个 YouTube 视频,我点开会自动跳转到 YouTube App 播放该视频,然后我看到说明区域有链接,我点击查看详情,跳转到 Chrome App,在查看文章的时候,我看到有活动申请,于是点击邮箱地址跳转到 Gmail App,写完邮件,我甚至可以使用 back -> Chrome -> back -> YouTube -> back -> Google+,来返回到原来浏览的地方。而这一点我是无法在 iOS 上完成的,也不敢想象,我要多累才能回去。当然那个例子是一个极端的情况,但是日常中我会经常需要跳转。
总之在最后,iOS 和 Android 各有各的优劣,而最近几年的更新也是相互借鉴,Android 借鉴 iOS 的权限管理, iOS 借鉴 Android 的通知系统,而对于我们消费者来说,两者只要适合我们,为我们所用,都是很好的 Smart Phone。
而下面是几点 iOS 让我刚到非常惊喜的
界面和整体非常流畅,动画几乎没有卡顿,但也有遇到在 Setting 界面卡住不动,在 App Store 列表卡住的情况。但是总体来说较 Android 而言,确实非常顺滑。并且一直被提及的跟手程度,其实也是稍微有优势的,只是近年来差距越来越小了。
这也是非常赞的一点,这当然和 Apple 收紧通知发送有关,PC,iOS,Android 三端相同网络环境,经常是 iOS PC 受到消息很久之后 Android 才能受到消息。
这一点确实令人比较惊喜, Siri 在中文支持上竟然还可以,可能 Apple 给中文适配的比较多吧,同时功能也很稳定,不像 Google Now,有的时候就不理我了。
在移动设备上有很多方式来追踪用户的地理位置信息,下文会展开。然而并没有一种方式能够很容易作弊,对于日常普通用户而言模拟地理位置可以实现但是相对成本较高。因而综合使用以下的定位方法,可以让模拟地理位置信息变得非常困难。
有以下技术可以用来实现GPS定位:
GPS Reporting ,这是相对来说成本较“昂贵”的定位方法,一般来说 GPS 需要消耗更多的电量来提供GPS芯片读取卫星信号。GPS 信号可以编程通过修改GPS芯片驱动来改变获取到的位置,这种方式甚至不需要修改设备。
GSM Reporting 通常是最常见的定位方法,通过距离最近的三个信号塔,三角定位。在这种方式下,模拟位置相对较难。或许可以通过修改设备硬件,或者通过伪造基站来达到伪造定位,当成本也相对较高。并且,一般来说通信是加密的,也会造成不少困扰。
LAN Reporting 这种方式通常能够提供高精度的室内定位。
WAN Reporting 这种方式就是简单的 IP 定位,这种方式也是最容易破解的。这种方式也是通常移动设备上网页常见的定位用户方法。
Others 除了以上提到的常见定位方法,还有一起其他的定位方法,比如“惯性导航系统” , 这种方式不需要额外的传输手段,它使用内部的传感器和地图来确定位置,具体来说就是“使用加速器和陀螺仪来测量物体加速度和角速度,并使用计算机来连续估算 运动物体的位置、姿态和速度。通常不需要外部参考系,常被用在飞机,导弹, 潜艇和各种航天器中。” 摘自维基 。
其他可以考虑的因素是,大部分的地理位置数据会保存在移动设备的某个地方。因此开发者可以通过获取用户上一次的地理位置信息来判断当前的位置信息是否正确。比如你可能1min前还在北京海淀,然后现在定位信息在美国华盛顿,这样的位置变化可能有些问题。
以上翻译自Security StackOverflow (Bluetooth, RFID, Inertial nav, experimental, etc)
在讲完实现定位方式之后,探讨一下 Android 对于模拟 GPS 的检测方法。
在 6.0 以前在开发者选项中有模拟位置的选项可选,开发者可以用过模拟位置来伪造地理位置信息。这种方式可以被很多方法检测到。比如:
public static boolean isMockSettingsON(Context context) {
// returns true if mock location enabled, false if not enabled.
if (Settings.Secure.getString(context.getContentResolver(),
Settings.Secure.ALLOW_MOCK_LOCATION).equals("0"))
return false;
else
return true;
}
第二种方式是检测安装的应用中是否有应用使用了 android.permission.ACCESS_MOCK_LOCATION
权限。
public static boolean areThereMockPermissionApps(Context context) {
int count = 0;
PackageManager pm = context.getPackageManager();
List<ApplicationInfo> packages =
pm.getInstalledApplications(PackageManager.GET_META_DATA);
for (ApplicationInfo applicationInfo : packages) {
try {
PackageInfo packageInfo = pm.getPackageInfo(applicationInfo.packageName,
PackageManager.GET_PERMISSIONS);
// Get Permissions
String[] requestedPermissions = packageInfo.requestedPermissions;
if (requestedPermissions != null) {
for (int i = 0; i < requestedPermissions.length; i++) {
if (requestedPermissions[i]
.equals("android.permission.ACCESS_MOCK_LOCATION")
&& !applicationInfo.packageName.equals(context.getPackageName())) {
count++;
}
}
}
} catch (NameNotFoundException e) {
Log.e("Got exception " + e.getMessage());
}
}
if (count > 0)
return true;
return false;
}
通过这两个方法能够减少一定程度非 root 机模拟位置的可能性。
而对于root机型,几乎无法从根源上反作弊,对于出来四年的 Ingress 也几乎无法避免作弊的问题,目前可知的 Ingress 对于位置欺骗的反作弊方式有:
而对于这两种方式 Ingress 官方并没有明确的文档指出,基本通过玩家黑盒测试得出。而对于最新出的 Pokemon Go,在全球作弊成风的情况下官方直接禁用了 Root 机型。因此目前对于 root 机型的反作弊我还是没有找到可用的方法。
Android 应用程序打包之后生成的 apk 文件包含了运行 Android 所需要的所有资源,APK 文件大小影响用户下载应用的时间,在早先流量非常珍贵的时候非常重要,如今虽然 wifi 速度大大的提升了,但是 APK 文件的大小也依然很重要。
通常一个 APK 包括以下目录:
META-INF/
包括 CERT.SF 和 CERT.RSA 证书文件, MANIFEST.MFassets/
包含 App 的资源文件,可以通过 AssetManager 获取res/
包括 App 图片等等资源文件,不会被编译进 resources.arsclib/
包括编译的库文件,该目录包括一系列为不同平台打包的子目录,比如 armeabi, armeabi-v7a, arm64-v8a, x86, x86_64, 和 mipsAPK 还包括以下文件,AndroidManifest.xml
是强制必须的:
resources.arsc
包括编译过的资源文件。这个文件包含了 /res/values/ 目录下定义好的所有的 XML 内容。Packaging Tool 提取 XML 内容,并压缩到二进制。该文件包含了不同语言的字符串,样式,还有不包含在 resources.arsc 文件中的资源路径,比如 layout 文件和图片。class.dex
包含编译过后的代码文件,可以被 Dalvik/ART 识别。如果开发者使用 multidex 来避免 the 65536 method limit 那么包中可能存在多个 Dex 文件。AndroidManifest.xml
包含 Android 的 manifest 文件。该文件包含了应用的名字,版本,权限申请和引用的库文件。在谈到具体缩减 APK 大小步骤之前,可以使用 Android Studio 内置的 APK 分析工具来分析现有 APK 内容文件。入口位置在:Build -> Analyze Apk ,然后选择 APK 即可,然后会显示:
APK 文件的大小影响着应用的加载,内存的使用,消耗多少电力。减小 APK 大小的最简单的方法就是减少资源文件数量和大小。比如,可以移除程序内不再使用的资源图片,或者可以使用可变大小的 Drawable 来代替现有的图片文件。下面是一些常用做法。
使用 ProGuard 来缩减代码大小,ProGuard 还有其他一些优化,混淆等等的功能,可以参考 sourceforge 或者参考之前整理的文章。具体优化配置如下:
在 buildTypes 下开启 minifyEnabled 和 shrinkResources
buildTypes {
debug {
minifyEnabled false
}
release {
minifyEnabled true
shrinkResources true
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-project.txt'
}
}
在开启 shrinkResources 之后效果还是挺明显,经过我的尝试,30M 的 App,能够缩减 1M~3M 大小,而只需要增加一行代码,何乐不为。而在平时开发中,如果遇到删减代码的时候,最好将资源文件一同删去,免去在打包时无用文件占用资源。
具体参照 https://developer.android.com/studio/build/shrink-code.html
关闭 png cruncher 在下面 PNG 手动压缩之后,关闭该压缩选项
aaptOptions {
cruncherEnabled = false
}
可以使用上面提到的 shrinkResources
来在发布 release 版本时让 Gradle 自动剔除没有使用的资源文件,也可以通过 android-resource-remover 这个脚本来移除无用资源文件,这个脚本基于 Android Lint 工具 。通过 Gradle 在打包时并没有从本地磁盘上删去文件,而使用后一种方法可以从根本上删除无用文件。
在 Android Studio 2.0 以后,使用菜单中 Refactor -> Remove Unused Resources .. 可以用来在项目中移除不在引用的资源。实际操作感觉 Android Studio 会列出不正确的无用资源,在使用时需要特别注意。对于不再需要的图片一定要及时删除,例如因功能更新老的图片不再使用等情形。
在 build.gradle 中定义
android {
defaultConfig {
...
resConfigs "en", "fr"
}
}
可以只打包指定语言的资源文件。
而缩减 PNG 图片大小的方法又可以细分为以下几类:
尽量多使用 WebP 格式,能用 JPEG 图片的就用 JPEG 图片
减少帧动画中图片帧,帧动画会明显的增加包大小,一般在 App 中使用一张 PNG 来表示动画的一帧。如果动画只有 15 FPS,那么在设计导出图片时尽量减少图片的数量,而不是使用 30 张图片来做 15 帧的动画,比如在程序中有个动画是用了 60 帧,后来使用 bash,删去一般图片,并调整代码,而效果几乎看不出区别。
for((a=1;a<62;a=a+2))
do
rm "filename"$a".png"
done
基本原理就是讲 24-bit 的图片压缩到 8-bit ,对于程序中小 icon 或者 低分辨率的图片几乎无法看出区别。
When you upload a PNG (Portable Network Graphics) file, similar colours in your image are combined. This technique is called “quantisation”. Because the number of colours is reduced,24-bit PNG files can be converted to much smaller 8-bit indexed colour images. All unnecessary metadata is stripped too. The result: tiny 8-bit PNG files with 100% support for transparency. Have your cake and eat it too! It turns 24-bit RGB files into palettized 8-bit ones. You lose some color depth, but for small images it’s often imperceptible.
网上有很多压缩工具,比如 tinypng ,pngquant ,Pngcrush ,OptiPNG ,zopflipng from Google 。下面分别简单介绍下。
对于 tinypng 网上有人编写了脚本 在他们的开发者网站上 申请 API key 就能够使用,不过免费的版本每个月只能压缩 500 张图片,对于小程序可能已经足够使用了,但是对于稍微大一些的 App,可能需要付费或者用其他的 API key。
对于 JPG 的图片可以使用 Paint.NET 或者 官方建议的 packJPG
可以从以下方面避免程序使用重复内容:
避免资源重复是最显而易见可以减少 APK 大小的方法,而如果产生了重复代码,则一定要考虑是否代码抽象不够,重复的内容是否能够抽象出单独的方法,然后重构产生重复的地方。
ProGuard 可以对 Java 进行优化,但是对于 Android 资源文件无能为力。因此,如果图片在 res/drawable 下, Proguard 可以从 R class 中移除引用,但是图片文件依然还在原地方。
Lint 是一个静态代码分析工具,帮助检测无用资源文件。使用命令 ./gradlew
来生成 Lint 报告,在 UnusedResources: Unused resources
section 下就能查到所有没有被引用的资源文件。
Lint 工具分析 resources 比如 /res 下的文件,但是会跳过 assets 目录下的文件。事实上, assets 文件可以通过他们的名字而不是 Java 或者 XML 引用来在代码中使用,所以 Lint 工具不能决定 asset 目录下的文件是否被引用。所以在 assets 目录下的文件则需要开发者自己维护,保持干净和整洁。
在 Android Studio 中配置 Android Lint ,使用 Lint 工具检测在菜单 Analyze -> Inspect Code… ,点击之后等待分析完成即可查看分析报告。配置 Lint 工具检查内容可以在 Android Studio –> Preferences –> Editor –> Inspections (currently on Android Studio) 下配置。比如想要关闭 “Image without contentDescription” 检查,可以直接搜索并且关闭即可。
之前说过 resource.arsc 文件包含了 res/value/ 目录下定义的资源,还有 layout 和 string 等资源的路径。因此随着 App 的不断更新,该文件会越来越大。
资源混淆压缩以及 resource.arsc 文件,工具可以使用 andresguard https://github.com/shwenzhang/AndResGuard/blob/master/README.zh-cn.md ,但因为风险较大,目前并没有集成。
通过混淆资源,将 r/drawable/login_background.png
混淆为 r/d/a.png
这样就可以减少 resource.arsc 文件的大小极限压缩 jpg、png、resource.arsc 等文件,采用 7z 来对这类文件进行进一步的压缩,极大的降低包尺寸使用 andresguard 时清楚自己 app 哪些是不能混淆的,例如 facebook_id
、crashlytics key
这些对应的 string 就不能混淆了,必须加入白名单;利用 getIdentifier 来获取的资源也必须加入白名单
Images: PNG or JPEG. Use PNGs; since it is a lossless format it is very suitable for textures and artwork as there will be no visual artefacts from the compression. If there are space constraints, use JPEGs or a combination of PNGs and JPEGs. A high quality JPEG image may work fine for large photo-realistic images, which the JPEG compression scheme is optimised for.
Audio: AAC Audio is recommended for all audio resources. AAC achieves better compression at a given quality, compared to mp3 or Ogg Vorbis. Raw formats such as WAV should never be used. The common rational for using the WAV format is that decoding compressed audio streams usually means high latency at playback. However, Android provides the Sound Pool API which enables applications to use compressed audio streams without the penalty of high latency.
Video: Use H264 AVC. Encode the video to a resolution no larger than the screen resolution of the target device (if known).
AAC-LC is the default for all of the AAC encoders supported by ffmpeg.
可以使用如下 ffmpeg 转码:
ffmpeg -i input.wav -codec:a aac output.aac
Calculate the bitrate you need by dividing 1 GB by the video length in seconds. So, for a video of length 16:40 (1000 seconds), use a bitrate of 1000000 bytes/sec:
ffmpeg -i input.mp4 -b 1000000 output.mp4
Additional options that might be worth considering is setting the Constant Rate Factor, which lowers the average bit rate, but retains better quality. Vary the CRF between around 18 and 24 — the lower, the higher the bitrate.
ffmpeg -i input.mp4 -vcodec libx264 -crf 20 output.mp4
决定 dex 文件尺寸主要有两个方面(归根结底都是代码文件)
依赖的库文件,包括 gradle 依赖、引用的 jar 包、aar 包等自己的代码
针对 Google Play Service,在依赖时尽量分开,使用到某一部分时尽量只依赖使用到的部分,而不是把整个库都 pull 下来。比如在项目中只需要使用到 GCM,和 Ads,那么在申明依赖时只引用两个即可。各个部分的依赖在 developers.google.com 上可以查到。
compile 'com.google.android.gms:play-services-gcm:8.4.0'
compile 'com.google.android.gms:play-services-ads:8.4.0'
在总结完以上方法之后,我才发现这一系列文章,这系列的文章非常值得一看,几乎完全覆盖了上面提到的方法。
Gradle 是 Android 新的编译环境。随着 Android Studio 的发布,编译 Android 的环境逐渐转移到了 Gradle。
an advanced build toolkit, to automate and manage the build process, while allowing you to define flexible custom build configurations
根据 Android 官网 的介绍,Gradle 是一个进阶的编译工具包,能够自动管理编译过程,并且允许用户配置编译过程。并且在后序的学习中可以通过大量的配置来对 Android 进行多渠道打包,自动打包持续集成。
Gradle 和它响应的 Android 插件可以独立于 Android Studio 运行,这也就意味着开发者可以在 Android Studio 内部编译生成应用,也可以通过命令行来打包 APK。
对于新建的 Android 工程,一般会产生多个 gradle 文件,下面依次介绍。
Android 项目最顶层,在项目根目录下的 build.gradle
如下:
buildscript {
repositories {
jcenter()
}
dependencies {
classpath 'com.android.tools.build:gradle:1.0.0'
}
}
apply plugin: 'android'
allprojects {
repositories {
jcenter()
}
}
各个字段含义:
jcenter():声明使用 maven 仓库。在老版本中,此处为 mavenCentral(),远端仓库地址。
项目根目录下的 settings.gradle
中配置当前项目的 module
默认为:
include ':app'
如果 module 不在 project 根目录下,可以设置:
include ':app2'
project(':app2').projectDir = new File('path/to/app2')
如果有多个 module ,可以依次在 include 后加入,比如 include ':app', ':module1', ':module2'
这样。
在 module 下的 build.gradle 默认内容:
apply plugin: 'com.android.application'
android {
compileSdkVersion 21
buildToolsVersion "21.1.2"
defaultConfig {
applicationId "cc.bb.aa.myapplication"
minSdkVersion 10
targetSdkVersion 21
versionCode 1
versionName "1.0"
}
buildTypes {
release {
minifyEnabled true
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
}
}
}
dependencies {
compile fileTree(dir: 'libs', include: ['*.jar'])
compile 'com.android.support:appcompat-v7:21.0.3'
}
apply plugin: ‘com.android.application’: 表示使用 com.android.application 插件。也就是表示,这是一个 android application module 。 注:如果 Module 本身是一个依赖库,那么此时的 apply plugin 为 ‘com.android.library’ 相应的,若是一个 Java project,apply plugin 为 ‘java’。对于库项目,与普通项目仅仅是 app plugin 不同,其他完全相同。
android: 配置所有 Android 构建过程需要的参数。
defaultConfig: Android 项目默认设置。
buildTypes: 编译类型。默认有两个: release 和 debug 。我们可以在此处添加自己的 buildTypes ,可在 Build Variants 面板看到。Android 项目规定必须至少定义一个 buildTypes。
minifyEnabled: 是否使用混淆。在老版本中为 runProguard ,新版本之所换名称,是因为新版本支持去掉没使用到的资源文件,而 runProguard 这个名称已不合适了。
proguardFiles: 使用的混淆文件,可以使用多个混淆文件。此例中,使用了 SDK 中的 proguard-android.txt 文件以及当前 module 目录下的 proguard-rules.pro 文件。更多关于代码混淆的以及 ProGuard 的内容可以参看我的另外一篇文章。
dependencies: 用于配制引用的依赖。
compile fileTree(dir: ‘libs’, include: [‘*.jar’]) : 引用当前 module 目录下的 libs 文件夹中的所有 .jar 文件。
compile ‘com.android.support:appcompat-v7:21.0.3’: 引用 21.0.3 版本的 appcompat-v7 (也就是常用的 v7 library 项目)。
在 Eclipse 中,使用 android support ,需要在 SDK 中下载 Android Support Library 。在 Android Studio 中,使用 android support ,需要在 SDK 中下载 Android Support Repository ,且项目中使用的版本不能大于 SDK 中的版本。
默认情况,Android Studio 会给项目设置 debug 和 release 两个 buildTypes,当然开发者也可以定义自己的 buildTypes。
buildTypes 在 Gradle 中有如下作用:
可以使用 buildTypes 来给 application id 增加后缀,比如
buildTypes {
release {
debuggable false
}
development {
debuggable true
applicationIdSuffix ".dev"
}
testing {
debuggable true
applicationIdSuffix ".qa"
}
}
最后得到的 applicationId 会是这样:
com.package.android
for releasecom.package.android.dev
for developmentcom.package.android.qa
for testing如果想要使用 Gradle 来自动签名打包,可以使用这样的配置,避免在版本控制中提交密码。
在 ~/.gradle/gradle.properties
中配置:
RELEASE_STORE_FILE={path to your keystore}
RELEASE_STORE_PASSWORD=*****
RELEASE_KEY_ALIAS=*****
RELEASE_KEY_PASSWORD=*****
并修改 build.gradle
文件:
android {
...
signingConfigs {
release {
storeFile file(RELEASE_STORE_FILE)
storePassword RELEASE_STORE_PASSWORD
keyAlias RELEASE_KEY_ALIAS
keyPassword RELEASE_KEY_PASSWORD
}
}
buildTypes {
release {
signingConfig signingConfigs.release
}
}
....
}
之后就可以使用命令或者 Gradle 面板中的 gradle assembleRelease
来生成签名的 apk 文件
关于 ProGuard 的内容可以参考这篇文章
buildTypes {
debug {
minifyEnabled false
proguardFile('proguard.cfg')
}
release {
minifyEnabled true
proguardFile('proguard.cfg')
}
}
以下是一些 buildTypes 的基本配置,举例:
release {
minifyEnabled false
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.txt'
signingConfig signingConfigs.myConfig
debuggable false
jniDebuggable false
versionNameSuffix ".suffix"
zipAlignEnabled true
pseudoLocalesEnabled true
renderscriptDebuggable true
}
buildTypes 支持的配置:
配置名称 | 作用 |
---|---|
minifyEnabled | 是否开启 Minify ,包括混淆和压缩代码 |
debuggable | 是否编译出可调试的 apk |
applicationIdSuffix | 添加 application id 后缀 |
proguardFiles | 添加 ProGuard 配置文件 |
jniDebuggable | Whether this build type is configured to generate an APK with debuggable native code. |
renderscriptDebuggable | Whether the build type is configured to generate an apk with debuggable RenderScript code. |
renderscriptOptimLevel | Optimization level to use by the renderscript compiler |
versionNameSuffix | Version name suffix. |
zipAlignEnabled | Whether zipalign is enabled for this build type. |
testCoverageEnabled | Whether test coverage is enabled for this build type. |
pseudoLocalesEnabled | Whether to generate pseudo locale in the APK. |
embedMicroApp | Whether a linked Android Wear app should be embedded in variant using this build type. |
引用一个外部依赖需要使用 group, name 和 version 属性。根据你想要使用的库,group 和 version 可能会有所差别。
有一种简写形式,只使用一串字符串 "group:name:version"
.
在 build.gradle 中,如下方式引入依赖:
dependencies {
compile fileTree(dir: 'libs', include: ['*.jar'])
compile 'com.android.support:appcompat-v7:22.2.1'
compile files('libs/liba-3.4.5.jar')
compile project(':libraryName')
}
代码解析:
compile fileTree(dir: 'libs', include: '*.jar')
,可以将 libs 目录下所有 jar 文件进行编译打包。也可以使用 compile fileTree(dir: 'libs', include: ['*.jar'], exclude: ['xx.jar'])
中 exclude 这样的语法来排除某些指定的 jarcompile file、compile project、compile fileTree 都可以看成是 compile 的子命令,
dependencies {
provided files('libs/libb.jar')
provided 'com.squareup.dagger:dagger-compiler:1.2.1'
// 在测试环境下引用依赖。
// 引用 jar 文件。
androidTestCompile files('libs/xx.jar')
// 引用 Maven。
androidTestCompile 'junit:junit:4.11'
// 在 release buildTypes 分支下引用依赖。
// 引用 jar 文件。
releaseCompile files('libs/xx.jar')
// 引用 Maven。
releaseCompile 'aaa:bbb:x.x.x'
}
如果使用的是 provided
则表示该依赖只在编译时使用,不在最后打包时使用。
Product Flavors 用来管理不同的 release 版本,比如免费版和收费版。可以通过自定义 product flavors 来使用为不同的发行版设置不同的资源文件和代码,同时共享相同部分的资源和代码。 Product Flavor 设置是可选的,具体步骤可参考官网。