qmsggg_BlogCollect
qmsggg_BlogCollect copied to clipboard
qmsggg
仅仅只是用于学习和记录使用,里面包括了自己学习android的点点滴滴，希望自己在以后的时间能把之前由于时间原因没有完成的完成了，以此自勉。
# 编译篇 [自己动手编译Android 8.0源码](https://blog.csdn.net/dl6655/article/details/78869501) [清华大学开源软件镜像站](https://mirrors.tuna.tsinghua.edu.cn/help/AOSP/)
[转-学习使用，自己逐步增加](https://juejin.im/entry/59df172f6fb9a04522067f98?utm_source=gold_browser_extension) # 综述 毫无疑问，混淆是打包过程中最重要的流程之一，在没有特殊原因的情况下，所有 app 都应该开启混淆。 首先，这里说的的混淆其实是包括了代码压缩、代码混淆以及资源压缩等的优化过程。依靠 ProGuard，混淆流程将主项目以及依赖库中未被使用的类、类成员、方法、属性移除，这有助于规避64K方法数的瓶颈；同时，将类、类成员、方法重命名为无意义的简短名称，增加了逆向工程的难度。而依靠 Gradle 的 Android 插件，我们将移除未被使用的资源，可以有效减小 apk 安装包大小。 本文由两部分构成，第一部分给出混淆的最佳实践，力求让零基础的新手都可以直接使用混淆；第二部分会介绍一下混淆的整体、自定义混淆规则的语法与实践、自定义资源保持的规则等。 ## 一、Android混淆最佳实践 ### 1. 混淆配置 一般情况下，app module 的 build.gradle 文件默认会有如下结构： ``` android { buildTypes {...
>Android Studio打包应用默认生成的apk名称是：app-release.apk 、如果我们要让生成的apk名跟我们版本包名有联系的话，那我们就要自定义生成的apk名了，要怎么做呢。 我们只需要再build.gradle文件下android{ }下添加： ``` android.applicationVariants.all { variant -> variant.outputs.all { output -> def outputFile = output.outputFile outputFileName = "qmsggg_" + defaultConfig.versionName + "." + defaultConfig.versionCode + "_${releaseTime()}_" +...
## 前言 前几天帮人做一个关于App读取_扫描枪_数据的demo，在完成的时候需要生成一个release包，之前公司的都是在服务器上打包的，怎么使用android studio来生成一个正式包，我还真是一脸蒙逼，于是“普通程序员+google”的理念出现了，赶紧打开ss，google一下，接下来一步一步的记录一下自己在生成app release包的步骤。 ## 新建Key Store >Android Studio工具栏 Build -> Generate Signed APK  >next  >如果没有就要create new  >填好信息后就直接next and finish  >Project Structu中配置Signing  ## Signing...
- 使用篇 [你真的理解AccessibilityService吗](https://www.jianshu.com/p/4cd8c109cdfb) [Android进阶——学习AccessibilityService实现微信抢红包插件](https://blog.csdn.net/qq_30379689/article/details/53242953) [AccessibilityService分析与防御](https://lizhaoxuan.github.io/2017/11/29/AccessibilityService%E5%88%86%E6%9E%90%E4%B8%8E%E9%98%B2%E5%BE%A1/) - 官网（翻墙） [AccessibilityService](https://developer.android.com/reference/android/accessibilityservice/AccessibilityService.html#SERVICE_META_DATA)
## Android类装载机制 ### 前言 上两篇文章分析了资源的加载和进程，Activity启动相关的内容，这篇是Dex加载相关的内容了，本篇结束，我们也就可以开始对于一些热修复，插件化框架的实现剖析了。 #### Android中ClassLoader ##### ClassLoader  上图为Android中ClassLoader的类图，与JVM不同，Dalvik的虚拟机不能用ClassCload直接加载.dex，Android从ClassLoader派生出了两个类：DexClassLoader和PathClassLoader。而这两个类就是我们加载dex文件的关键，这两者的区别是： DexClassLoader：可以加载jar/apk/dex，可以从SD卡中加载未安装的apk。 PathClassLoader：要传入系统中apk的存放Path，所以只能加载已经安装的apk文件。 Dalvik虚拟机如同其他Java虚拟机一样，在运行程序时首先需要将对应的类加载到内存中。而在Java标准的虚拟机中，类加载可以从class文件中读取，也可以是其他形式的二进制流。因此，我们常常利用这一点，在程序运行时手动加载Class，从而达到代码动态加载执行的目的。 只不过Android平台上虚拟机运行的是Dex字节码,一种对class文件优化的产物,传统Class文件是一个Java源码文件会生成一个.class文件，而Android是把所有Class文件进行合并，优化，然后生成一个最终的class.dex,目的是把不同class文件重复的东西只需保留一份,如果我们的Android应用不进行分dex处理,最后一个应用的apk只会有一个dex文件。  laodClass.png PathClassLoader和DexClassLoader都继承自BaseDexClassLoader,其中的主要逻辑都是在BaseDexClassLoader完成的。 可以看出在加载类时首先判断这个类是否之前被加载过，如果有则直接返回，如果没有则首先尝试让parent ClassLoader进行加载,加载不成功才在自己的findClass中进行加载。这和java虚拟机中常见的双亲委派模型一致的，这种模型并不是一个强制性的约束模型，比如你可以继承ClassLoader复写loadCalss方法来破坏这种模型，只不过双亲委派模是一种被推荐的实现类加载器的方式，而且jdk1.2以后已经不提倡用户在覆盖loadClass方法，而应该把自己的类加载逻辑写到findClass中。 #### ClassLoader源码分析 ``` BaseDexClassLoader public class BaseDexClassLoader extends ClassLoader {...
[https://github.com/xitu/tensorflow-docs](https://github.com/xitu/tensorflow-docs)
写在前面 不管是开发、测试、运维，每个技术人员心里多多少少都有一个成为技术大牛的梦，毕竟“梦想总是要有的，万一实现了呢”！正是对技术梦的追求，促使我们不断地努力和提升自己。 然而“梦想是美好的，现实却是残酷的”，很多同学在实际工作后就会发现，梦想是成为大牛，但做的事情看起来跟大牛都不沾边，例如，程序员说“天天写业务代码还加班，如何才能成为技术大牛”，测试说“每天都有执行不完的测试用例”，运维说“扛机器接网线敲shell命令，这不是我想要的运维人生”。 我也是一位程序员，所以我希望通过以下基于程序开发的一些例子，帮助大家解决这些困惑。大道理是相通的，测试、运维都可以借鉴。 几个典型的误区 拜大牛为师 有人认为想成为技术大牛最简单直接、快速有效的方式是“拜团队技术大牛为师”，让他们平时给你开小灶，给你分配一些有难度的任务。 我个人是反对这种方法的，主要的原因有几个： 大牛很忙，不太可能单独给你开小灶，更不可能每天都给你开1个小时的小灶；而且一个团队里面，如果大牛平时经常给你开小灶，难免会引起其他团队成员的疑惑，我个人认为如果团队里的大牛如果真正有心的话，多给团队培训是最好的。然而做过培训的都知道，准备一场培训是很耗费时间的，课件和材料至少2个小时（还不能是碎片时间），讲解1个小时，大牛们一个月做一次培训已经是很高频了。 因为第一个原因，所以一般要找大牛，都是带着问题去请教或者探讨。因为回答或者探讨问题无需太多的时间，更多的是靠经验和积累，这种情况下大牛们都是很乐意的，毕竟影响力是大牛的一个重要指标嘛。然而也要特别注意：如果经常问那些书本或者google能够很容易查到的知识，大牛们也会很不耐烦的，毕竟时间宝贵。经常有网友问我诸如“jvm的-Xmn参数如何配置”这类问题，我都是直接回答“请直接去google”，因为这样的问题实在是太多了，如果自己不去系统学习，每个都要问是非常浪费自己和别人的时间的。 大牛不多，不太可能每个团队都有技术大牛，只能说团队里面会有比你水平高的人，即使他每天给你开小灶，最终你也只能提升到他的水平；而如果是跨团队的技术大牛，由于工作安排和分配的原因，直接请教和辅导的机会是比较少的，单凭参加几次大牛的培训，是不太可能就成为技术大牛的。 综合上述的几个原因，我认为对于大部分人来说，要想成为技术大牛，首先还是要明白“主要靠自己”这个道理，不要期望有个像武功师傅一样的大牛手把手一步一步地教你。适当的时候可以通过请教大牛或者和大牛探讨来提升自己，但大部分时间还是自己系统性、有针对性的提升。 业务代码一样很牛逼 有人认为写业务代码一样可以很牛逼，理由是业务代码一样可以有各种技巧，例如可以使用封装和抽象使得业务代码更具可扩展性，可以通过和产品多交流以便更好的理解和实现业务，日志记录好了问题定位效率可以提升10倍等等。 业务代码一样有技术含量，这点是肯定的，业务代码中的技术是每个程序员的基础，但只是掌握了这些技巧，并不能成为技术大牛，就像游戏中升级打怪一样，开始打小怪，经验值很高，越到后面经验值越少，打小怪已经不能提升经验值了，这个时候就需要打一些更高级的怪，刷一些有挑战的副本了，没看到哪个游戏只要一直打小怪就能升到顶级的。成为技术大牛的路也是类似的，你要不断的提升自己的水平，然后面临更大的挑战，通过应对这些挑战从而使自己水平更上一级，然后如此往复，最终达到技术大牛甚至业界大牛的境界，写业务代码只是这个打怪升级路上的一个挑战而已，而且我认为是比较初级的一个挑战。 所以我认为：业务代码都写不好的程序员肯定无法成为技术大牛，但只把业务代码写好的程序员也还不能成为技术大牛。 上班太忙没时间自己学习 很多人认为自己没有成为技术大牛并不是自己不聪明，也不是自己不努力，而是中国的这个环境下，技术人员加班都太多了，导致自己没有额外的时间进行学习。 这个理由有一定的客观性，毕竟和欧美相比，我们的加班确实要多一些，但这个因素只是一个需要克服的问题，并不是不可逾越的鸿沟，毕竟我们身边还是有那么多的大牛也是在中国这个环境成长起来的。 我认为有几个误区导致了这种看法的形成： 1）上班做的都是重复工作，要想提升必须自己额外去学习 形成这个误区的主要原因还是在于认为“写业务代码是没有技术含量的”，而我现在上班就是写业务代码，所以我在工作中不能提升。 2）学习需要大段的连续时间 很多人以为要学习就要像学校上课一样，给你一整天时间来上课才算学习，而我们平时加班又比较多，周末累的只想睡懒觉，或者只想去看看电影打打游戏来放松，所以就没有时间学习了。 实际上的做法正好相反：首先我们应该在工作中学习和提升，因为学以致用或者有实例参考，学习的效果是最好的；其次工作后学习不需要大段时间，而是要挤出时间，利用时间碎片来学习。 正确的做法 Do more 做的更多，做的比你主管安排给你的任务更多。 我在HW的时候，负责一个版本的开发，这个版本的工作量大约是2000行左右，但是我除了做完这个功能，还将关联的功能全部掌握清楚了，代码（大约10000行）也全部看了一遍，做完这个版本后，我对这个版本相关的整套业务全部很熟悉了。经过一两次会议后，大家发现我对这块掌握最熟了，接下来就有趣了：产品讨论需求找我、测试有问题也找我、老大对外支撑也找我；后来，不是我负责的功能他们也找我，即使我当时不知道，我也会看代码或者找文档帮他们回答。最后我就成了我这个系统的“专家”了。虽然这个时候我还是做业务的，还是写业务代码，但是我已经对整个业务都很熟悉了。...