文章目录

项目设计开发bug记录：
Android新技术应用：

项目设计开发bug记录：

Android Studio 项目设计开发bug记录

（1）打包时出错

问题描述：
打包时出现报错：All flavors must now belong to a named flavor dimension
解决方案：
点开主app的build.gradle的，加入 flavorDimensions “versionCode” 使其处于同一个维度下

在这里插入图片描述

（2）关闭项目自启动

问题描述：
Android studio设置启动时如何不自动打开上次关闭的项目
解决方案：
点击File—>Settings—>System Settings—>去掉勾选“Reopen last project on startup”

（3）显示工具栏

问题描述：
上层的工具栏被隐藏了
解决方案：
勾选View里的Toolbar一栏

（4）怎么导入jar包

问题描述：
在android studio中导入外部jar包
解决方案：
（1）切换成“project"模式，方便看见libs目录。

（2）将jar包拖入libs目录。

（3）方法一：
打开工程所在Project Structure,然后选择Dependencies，点击那个加号选择File Dependency ，然后再在Libs文件夹中选择要导入的jar包。

方法二：在project选中jar包点击右键"Add as library"，定位到项目的根目录，即build.gradle所在的目录。
dependencies
{
compile files(‘libs/android-support-v4.jar’)
compile files(‘libs/xxxx.jar’)
}
（4）以上两种方法：最终都是在module的build.gradle文件
里dependencies结点多了这样一句话compile files(‘libs/xxxx.jar’)

（5）导入工程出现异常

解决方案：
http://stackoverflow.com/questions/35153112/gradle-version-2-10-is-required-current-version-is-2-8-error

（6）run项目出现异常：

解决方案：
http://www.jianshu.com/p/4768fe43079a
http://my.oschina.net/polarw/blog/494046?p={ {page}}

（7）修改包名

解决方案：
http://www.cnblogs.com/Kyouhui/p/4632813.html

（8）导入项目

问题描述：
导入他人的项目运行时需要修改一定配置才可以正常运行
解决方案：
（1）修改build.gradle文件，把以下内容改成自己相对应的的Android studio版本号

（2）修改gradle-wrapper.properties，把以下内容改为自己电脑上的gradle-x.x.x-all.zip

（3）修改app/build.gradle改为各自使用的SDK以及buildTools版本
在这里插入图片描述

（9）stackoverflow

问题描述
app:transformDexArchiveWithExterLibsDexMergeForDebug
解决方案：
将电脑中的.gradle目录删除掉（清除掉gradle缓存）重新build
参考stackoverflow

Android新技术应用：

Android 开发奇思妙想小应用

（1）lancet ：一个 hook 库

https://github.com/eleme/lancet

这个库是饿了么对外开源的，但是目前来讲开发者关注度并不高，传统意义上 hook 的想法，都是换掉某个实现。
比如 A 类，有个 b 方法，我们需要修改 b方法返回值，我们一般会考虑 hook 一些对象，由这些对象导致 b 方法的执行返回逻辑发生改变，但是这种hook 并不是那么容易找到突破口。
而 lancet 的概念就很有意思了，它不修改 b方法，他修改所有调用 b 方法的地方，把对b 方法的调用hook 到你准备好的方法中，所以你可以随意的控制返回值，当然这种 hook 肯定是基于编译期修改字节码的，优势就是一定能换到，只要是参与编译的代码。

可以深入这个库的原理，确实是 hook 的一个非常好的新思路。

（2）西瓜技术团队

AwCookieManager.nativeGetCookie crash 排查

分享了西瓜的一个CookieManager.getCookie(String url) 过程中的 native crash，分析过程较为复杂，不过给出了解决方案，解决方案涉及到 hook，西瓜用了自研的方案，开源的 lancet 应该也能做到，这篇文章也会提到 lancet。

（3）字节跳动技术团队

抖音包大小优化-资源优化

可以看下抖音团队为了减少 apk 的体积，针对资源这一方面做了哪些极致的事情。

另外 apk 体积优化也可以看下 jsonchao 的文章：
吹爆系列：深入探索Android包体积优化

在 Android 性能优化的知识体系当中，包体积优化一直被排在优先级比较低的位置，从而导致很多开发同学对自身应用的大小并不重视。但事实上，包体积优化能够给我们带来很多意想不到的收益。

思维导图大纲在这里插入图片描述
对于apk“瘦身”原因：
1、下载转化率
APK 瘦身优化在实际的项目中优先级是比较低的，因为做了之后它的好处不是那么明显，尤其是那些还没有到稳定期的项目，我们都知道，App 的发展历程是从项目初期 => 成长期 => 稳定期，对于处于发展初期与成长期的项目而言，可能会做启动优化、卡顿优化，但是一般不会做瘦身优化，瘦身优化最主要的好处是对应用下载转化率的影响，它是 App 业务运营的重要指标之一，在项目精细化运营的阶段是非常重要的。因为如果你的 App 与其它同类型的 App 相比 Apk 体积要更小的话，那么你的 App 下载率就可能要高一些。而且，包体积越小，用户下载等待的时间也会越短，所以下载转换成功率也就越高。所以，安装包大小与下载转化率的关系大致是成反比的，即安装包越大，下载转换率就越小。一个 80MB 的应用，用户即使点了下载，也可能因为网络速度慢、突然反悔导致下载失败。而对于一个 20MB 的应用，用户点了下载之后，在犹豫要不要下的时候可能就已经下载完了。
而且，现在很多大型的 App 一般都会有一个 Lite 版本的 App，这个也是出于下载转化率方面的考虑。

2、应用市场
Google Play 应用市场强制要求超过 100MB 的应用只能使用 APK 扩展文件方式上传。当使用 APK 扩展文件方式上传时，Google Play 会为我们的应用托管扩展文件，并将其免费提供给设备。扩展文件将保存到设备的共享存储位置（SD 卡或可安装 USB 的分区；也称为“外部”存储），应用可以在其中访问它们。在大多数设备上，Google Play 会在下载 APK 的同时下载扩展文件，因此应用在用户首次打开时便拥有了所需的一切。但是，在某些情况下，我们的应用必须在应用启动时从 Google Play 下载文件。如果您想避免使用扩展文件，并且想要应用程序的下载大小大于100 MB，则应该使用 Android App Bundles 上传应用程序，此时应用程序最多可提供150 MB的压缩下载大小。Android App Bundles 就是 Android 应用程序捆绑包，它能够让 App 以添加动态功能模块的方式去解决 APK 大小较大的问题。

3、渠道合作商的要求
此外，还有一个原因，当我们的 App 做大之后，可能需要跟各个手机厂商合作预装，这些渠道合作商会对你的 App 做详细的要求，只有达到相应的要求后才允许你的 App 预装到手机上。而且，越大的 App 其单价成本也会越高。所以，瘦身也是我们项目做大之后一定会遇到的一个问题。
体积过大对 App 性能的影响
此外，包体积除了会影响应用的下载转化率之外，主要还会对 App 三个方面的性能有一定的影响，如下所示：

1）、安装时间：比如文件拷贝、Library 解压，并且，在编译 ODEX 的时候，特别是对于 Android 5.0 和 6.0 系统来说，耗费的时间比较久，而 Android 7.0 之后有了混合编译，所以还可以接受。最后，App 变大后，其签名校验的时间也会变长。
2）、运行时内存：Resource 资源、Library 以及 Dex 类加载都会占用应用的一部分内存。
3）、ROM 空间：如果应用的安装包大小为 50MB，那么启动解压之后很可能就已经超过 100MB 了。并且，如果闪存空间不足，很可能出现“写入放大”的情况，它是闪存和固态硬盘（SSD）中一种不良的现象，闪存在可重新写入数据前必须先擦除，而擦除操作的粒度与写入操作相比低得多，执行这些操作就会多次移动（或改写）用户数据和元数据。因此，要改写数据，就需要读取闪存某些已使用的部分，更新它们，并写入到新的位置，如果新位置在之前已被使用过，还需连同先擦除；由于闪存的这种工作方式，必须擦除改写的闪存部分比新数据实际需要的大得多。即最终可能导致实际写入的物理资料量是写入资料量的多倍。

（4）携程技术

新版本适配一直是 Android 开发者的痛楚之一，但是这件事如果长期不升就会越来越困难。加上现在应用市场比较强势，所以保持一个较高的版本的适配是有必要的。

携程旅行分享了他们从API 26 到 29 的适配经验，就将关注点聚焦在了暗黑模式上。暗黑模式也最近的一个非常热门的话题，甚至微信支持暗黑模式都成为热点了。

在 2019 年，随着 iOS 13 与 Android Q 的推出，Apple 和 Google 同时推出主打功能暗黑模式，分别为 Dark Mode(iOS)/Dark Theme(Android) ，下文我们统称为 Dark Theme。在前期预研中，我们发现 66% 的 iOS 13 用户选择打开Dark Theme，可见用户对暗黑模式的喜爱和期待。

那么 Dark Theme 能带来哪些好处呢？

1）更加省电，当代手机大部分都是OLED屏（OLED屏黑色下不发光更省电），配合Dark Theme 能耗更低；
2）提供一致性的用户体验，当用户从Dark Theme的环境切换到我们的App，仍然能够享受黑色的宁静，避免亮眼的白色带来的刺激感；
3）提升品牌形象，及时跟进系统新特性，在享受新特性带来美好之外还能获得Apple Store和Google Play推荐位机会，提升整体品牌形象；
4）为弱视以及对强光敏感的用户提高可视性，让用户在暗环境中轻松使用App。

在这里插入图片描述