[ { "path": ".gitattributes", "content": "# Auto detect text files and perform LF normalization\n* text=auto\n\n# Custom for Visual Studio\n*.cs diff=csharp\n\n# Standard to msysgit\n*.doc\t diff=astextplain\n*.DOC\t diff=astextplain\n*.docx diff=astextplain\n*.DOCX diff=astextplain\n*.dot diff=astextplain\n*.DOT diff=astextplain\n*.pdf diff=astextplain\n*.PDF\t diff=astextplain\n*.rtf\t diff=astextplain\n*.RTF\t diff=astextplain\n" }, { "path": ".gitignore", "content": "*.project\n*.classpath\nbin/\ngen/\n*.DS_Store\n*/bin/\n*/gen/\n.settings/\n" }, { "path": "LICENSE", "content": "Apache License\n Version 2.0, January 2004\n http://www.apache.org/licenses/\n\n TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION\n\n 1. Definitions.\n\n \"License\" shall mean the terms and conditions for use, reproduction,\n and distribution as defined by Sections 1 through 9 of this document.\n\n \"Licensor\" shall mean the copyright owner or entity authorized by\n the copyright owner that is granting the License.\n\n \"Legal Entity\" shall mean the union of the acting entity and all\n other entities that control, are controlled by, or are under common\n control with that entity. For the purposes of this definition,\n \"control\" means (i) the power, direct or indirect, to cause the\n direction or management of such entity, whether by contract or\n otherwise, or (ii) ownership of fifty percent (50%) or more of the\n outstanding shares, or (iii) beneficial ownership of such entity.\n\n \"You\" (or \"Your\") shall mean an individual or Legal Entity\n exercising permissions granted by this License.\n\n \"Source\" form shall mean the preferred form for making modifications,\n including but not limited to software source code, documentation\n source, and configuration files.\n\n \"Object\" form shall mean any form resulting from mechanical\n transformation or translation of a Source form, including but\n not limited to compiled object code, generated documentation,\n and conversions to other media types.\n\n \"Work\" shall mean the work of authorship, whether in Source or\n Object form, made available under the License, as indicated by a\n copyright notice that is included in or attached to the work\n (an example is provided in the Appendix below).\n\n \"Derivative Works\" shall mean any work, whether in Source or Object\n form, that is based on (or derived from) the Work and for which the\n editorial revisions, annotations, elaborations, or other modifications\n represent, as a whole, an original work of authorship. For the purposes\n of this License, Derivative Works shall not include works that remain\n separable from, or merely link (or bind by name) to the interfaces of,\n the Work and Derivative Works thereof.\n\n \"Contribution\" shall mean any work of authorship, including\n the original version of the Work and any modifications or additions\n to that Work or Derivative Works thereof, that is intentionally\n submitted to Licensor for inclusion in the Work by the copyright owner\n or by an individual or Legal Entity authorized to submit on behalf of\n the copyright owner. For the purposes of this definition, \"submitted\"\n means any form of electronic, verbal, or written communication sent\n to the Licensor or its representatives, including but not limited to\n communication on electronic mailing lists, source code control systems,\n and issue tracking systems that are managed by, or on behalf of, the\n Licensor for the purpose of discussing and improving the Work, but\n excluding communication that is conspicuously marked or otherwise\n designated in writing by the copyright owner as \"Not a Contribution.\"\n\n \"Contributor\" shall mean Licensor and any individual or Legal Entity\n on behalf of whom a Contribution has been received by Licensor and\n subsequently incorporated within the Work.\n\n 2. Grant of Copyright License. Subject to the terms and conditions of\n this License, each Contributor hereby grants to You a perpetual,\n worldwide, non-exclusive, no-charge, royalty-free, irrevocable\n copyright license to reproduce, prepare Derivative Works of,\n publicly display, publicly perform, sublicense, and distribute the\n Work and such Derivative Works in Source or Object form.\n\n 3. Grant of Patent License. Subject to the terms and conditions of\n this License, each Contributor hereby grants to You a perpetual,\n worldwide, non-exclusive, no-charge, royalty-free, irrevocable\n (except as stated in this section) patent license to make, have made,\n use, offer to sell, sell, import, and otherwise transfer the Work,\n where such license applies only to those patent claims licensable\n by such Contributor that are necessarily infringed by their\n Contribution(s) alone or by combination of their Contribution(s)\n with the Work to which such Contribution(s) was submitted. If You\n institute patent litigation against any entity (including a\n cross-claim or counterclaim in a lawsuit) alleging that the Work\n or a Contribution incorporated within the Work constitutes direct\n or contributory patent infringement, then any patent licenses\n granted to You under this License for that Work shall terminate\n as of the date such litigation is filed.\n\n 4. Redistribution. You may reproduce and distribute copies of the\n Work or Derivative Works thereof in any medium, with or without\n modifications, and in Source or Object form, provided that You\n meet the following conditions:\n\n (a) You must give any other recipients of the Work or\n Derivative Works a copy of this License; and\n\n (b) You must cause any modified files to carry prominent notices\n stating that You changed the files; and\n\n (c) You must retain, in the Source form of any Derivative Works\n that You distribute, all copyright, patent, trademark, and\n attribution notices from the Source form of the Work,\n excluding those notices that do not pertain to any part of\n the Derivative Works; and\n\n (d) If the Work includes a \"NOTICE\" text file as part of its\n distribution, then any Derivative Works that You distribute must\n include a readable copy of the attribution notices contained\n within such NOTICE file, excluding those notices that do not\n pertain to any part of the Derivative Works, in at least one\n of the following places: within a NOTICE text file distributed\n as part of the Derivative Works; within the Source form or\n documentation, if provided along with the Derivative Works; or,\n within a display generated by the Derivative Works, if and\n wherever such third-party notices normally appear. The contents\n of the NOTICE file are for informational purposes only and\n do not modify the License. You may add Your own attribution\n notices within Derivative Works that You distribute, alongside\n or as an addendum to the NOTICE text from the Work, provided\n that such additional attribution notices cannot be construed\n as modifying the License.\n\n You may add Your own copyright statement to Your modifications and\n may provide additional or different license terms and conditions\n for use, reproduction, or distribution of Your modifications, or\n for any such Derivative Works as a whole, provided Your use,\n reproduction, and distribution of the Work otherwise complies with\n the conditions stated in this License.\n\n 5. Submission of Contributions. Unless You explicitly state otherwise,\n any Contribution intentionally submitted for inclusion in the Work\n by You to the Licensor shall be under the terms and conditions of\n this License, without any additional terms or conditions.\n Notwithstanding the above, nothing herein shall supersede or modify\n the terms of any separate license agreement you may have executed\n with Licensor regarding such Contributions.\n\n 6. Trademarks. This License does not grant permission to use the trade\n names, trademarks, service marks, or product names of the Licensor,\n except as required for reasonable and customary use in describing the\n origin of the Work and reproducing the content of the NOTICE file.\n\n 7. Disclaimer of Warranty. Unless required by applicable law or\n agreed to in writing, Licensor provides the Work (and each\n Contributor provides its Contributions) on an \"AS IS\" BASIS,\n WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or\n implied, including, without limitation, any warranties or conditions\n of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A\n PARTICULAR PURPOSE. You are solely responsible for determining the\n appropriateness of using or redistributing the Work and assume any\n risks associated with Your exercise of permissions under this License.\n\n 8. Limitation of Liability. In no event and under no legal theory,\n whether in tort (including negligence), contract, or otherwise,\n unless required by applicable law (such as deliberate and grossly\n negligent acts) or agreed to in writing, shall any Contributor be\n liable to You for damages, including any direct, indirect, special,\n incidental, or consequential damages of any character arising as a\n result of this License or out of the use or inability to use the\n Work (including but not limited to damages for loss of goodwill,\n work stoppage, computer failure or malfunction, or any and all\n other commercial damages or losses), even if such Contributor\n has been advised of the possibility of such damages.\n\n 9. Accepting Warranty or Additional Liability. While redistributing\n the Work or Derivative Works thereof, You may choose to offer,\n and charge a fee for, acceptance of support, warranty, indemnity,\n or other liability obligations and/or rights consistent with this\n License. However, in accepting such obligations, You may act only\n on Your own behalf and on Your sole responsibility, not on behalf\n of any other Contributor, and only if You agree to indemnify,\n defend, and hold each Contributor harmless for any liability\n incurred by, or claims asserted against, such Contributor by reason\n of your accepting any such warranty or additional liability.\n\n END OF TERMS AND CONDITIONS\n\n APPENDIX: How to apply the Apache License to your work.\n\n To apply the Apache License to your work, attach the following\n boilerplate notice, with the fields enclosed by brackets \"{}\"\n replaced with your own identifying information. (Don't include\n the brackets!) The text should be enclosed in the appropriate\n comment syntax for the file format. We also recommend that a\n file or class name and description of purpose be included on the\n same \"printed page\" as the copyright notice for easier\n identification within third-party archives.\n\n Copyright {yyyy} {name of copyright owner}\n\n Licensed under the Apache License, Version 2.0 (the \"License\");\n you may not use this file except in compliance with the License.\n You may obtain a copy of the License at\n\n http://www.apache.org/licenses/LICENSE-2.0\n\n Unless required by applicable law or agreed to in writing, software\n distributed under the License is distributed on an \"AS IS\" BASIS,\n WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.\n See the License for the specific language governing permissions and\n limitations under the License.\n\n" }, { "path": "README.md", "content": "# Android开发技术前线 ( android-tech-frontier )\n\n> 一个定期翻译、发布国内外Android优质的技术、开源库、软件架构设计、测试等文章的开源项目,让我们的技术跟上国际步伐。 \n> 我们翻译的文章在能够联系到作者的情况下都会在获得作者授权后进行翻译，并且公开发布。发布的文章中都会保留原文链接、作者名，如有相关的版权协议我们也会一并附上。目前已经联系到的作者列表请参考[授权文档](authorization.md);\n\n---------\n\n[Android App内存泄漏自动分析工具 - MMAT发布](https://github.com/hehonghui/mmat)\n\n\n## 可阅读文章列表\n\n* [请移步到wiki](https://github.com/bboyfeiyu/android-tech-frontier/wiki)\n\n\n## 其他学习资源\n* [Android 源码设计模式分析 地址](https://github.com/simple-android-framework-exchange/android_design_patterns_analysis)\n* [Android优秀学习资料整理](the-bad-guys/)\n* [软件架构模式](https://raw.githubusercontent.com/bboyfeiyu/android-tech-frontier/master/software-architecture-patterns/%E8%BD%AF%E4%BB%B6%E6%9E%B6%E6%9E%84%E6%A8%A1%E5%BC%8F.pdf)\n\n\n## 版权信息\n\"知识共享许可协议\"
该项目下的所有作品由Android开发技术前线团队翻译，采用知识共享署名-非商业性使用-相同方式共享 4.0 国际许可协议进行许可。\n\n" }, { "path": "android-blog/Android性能优化系列/readme.md", "content": "## Android 应用性能优化系列\n\n>原文链接分别为 : \n>\n>* [https://www.youtube.com/playlist?list=PLWz5rJ2EKKc9CBxr3BVjPTPoDPLdPIFCE](https://www.youtube.com/playlist?list=PLWz5rJ2EKKc9CBxr3BVjPTPoDPLdPIFCE)\n* [https://www.udacity.com/course/ud825](https://www.udacity.com/course/ud825)\n* 译者 : [胡凯](http://hukai.me)\n\n\n1. [Android性能优化典范](http://hukai.me/android-performance-patterns/)\n2. [Android性能优化之渲染篇](http://hukai.me/android-performance-render/)\n3. [Android性能优化之运算篇](http://hukai.me/android-performance-compute/)\n4. [Android性能优化之内存篇](http://hukai.me/android-performance-memory/)\n5. [Android性能优化之电量篇](http://hukai.me/android-performance-battery/) " }, { "path": "android-blog/Google+ 团队的 Android UI 测试/readme.md", "content": "Google+ 团队的 Android UI 测试\n---\n\n>\n* 原文链接：[How the Google+ Team Tests Mobile Apps](http://googletesting.blogspot.sg/2013/08/how-google-team-tests-mobile-apps.html)\n* 译者：[allenlsy](http://allelsy.com)\n* 译者博文地址：[http://allenlsy.com/android-ui-tests-in-google-plus-team/]()\n* 校对者:\n\nAndroid 测试主要分为3个类型：\n\n#### 单元测试（Unit Test)\n\n区分UI代码和功能代码在Android开发中尤其困难。因为有时Activity既有Controller的功能，又有View的功能。[Robolectric](http://pivotal.github.io/robolectric/)是一个很优秀的Android测试框架，它提供了一个Android框架的stub，这样测试运行时实际上是在JVM上运行，而不是在Android平台（比如Robotium和Instrumentation都是在Android平台运行测试），从而提高了速度。另外请参考[Gradle 对 Unit tests的支持](http://tools.android.com/tech-docs/unit-testing-support)。\n\n#### 封闭UI测试 （Hermetic UI Test)\n\n这个测试方法使得测试不需要外部依赖和网络请求。这样做的主要目的是提高测试速度，减少测试时的外部影响，毕竟网络调用是相对很慢的。[Espresso](http://www.youtube.com/watch?v=T7ugmCuNxDU)可以用来模拟用户的UI操作。\n\n#### Monkey Test\n\nMonkey Test 就好像一只猴子在测试app一样，没有任何规律的在你的app上胡按。计算机运行monkey test的时候，每秒钟能做出几千个UI动作（可以配置这个频率），比如点击和拖拽。所以这个测试可以算是一个压力测试，用来检测[ANR](http://developer.android.com/training/articles/perf-anr.html)。\n\n---\n\nGoogle+ 团队总结了一些 UI 测试时的经验和策略。\n\n#### 策略1： 不要使用 End-to-end 测试作为UI测试\n\n先看一些定义：__UI 测试__ 是为了确保对于用户的UI动作，app能返回正确的UI输出。__End-to-end测试（E2E test)__ 是通过客户端和后台服务器的交互测试整个系统。下面这个图在展示了测试步骤：\n\n![](http://img.my.csdn.net/uploads/201503/28/1427507159_1836.png)\n\n通常做UI测试，你需要后台服务器，所以可能产生网络调用。所以UI测试和E2E测试很像。但是在E2E测试中会遇到很多困难：\n\n* 测试速度缓慢\n* 网络请求会失败\n* 难以Debug\n\n下面看看如何解决这些问题。\n\n#### 策略2：使用伪服务器做封闭UI测试\n\n这个策略中，你可以通过假的后台服务器来避免网络请求，以及其他外部依赖。技术上，你就需要在app本地提供返回数据了。有很多办法可以做到，比如手动做一次网络请求，把response保存下来，在测试的时候重复这个response。这样你就做了一个封闭在本地的伪服务器\n\n当你有了这个伪服务器，你还需要给这个伪服务器写测试。于是这是，你的E2E测试就分为了服务器测试，客户端测试和集成测试。\n\n![](http://img.my.csdn.net/uploads/201503/28/1427507159_8354.png)\n\n现在这样的解决方案，你需要自己维护伪服务器，本地数据库和tests了。\n\n下面这是E2E 测试的示例图：\n\n![](http://img.my.csdn.net/uploads/201503/28/1427507160_4776.jpg)\n\n这是使用了伪服务器的封闭UI测试\n\n![](http://img.my.csdn.net/uploads/201503/28/1427507167_8779.jpg)\n\n其区别在于：Frontend Server的几个数据源变了。由原来的真实后端，变成了封闭服务器，或者是mock服务器。这个在测试调用网络API的时候非常有用。\n\n#### 策略3：使用Dependency Injection\n\nDependency Injection（依赖注入）可以帮助生成测试数据。我推荐选择使用[dagger](http://square.github.io/dagger/)作为依赖注入框架。\n\n依赖注入在UI test和unit test都中都可以用于生成假数据。在instrumentation test框架中，测试用的apk文件和测试时运行的app，是在同一个进程下面，所以测试代码可以调用app代码。你还可以覆盖app的classpath，通过这种方式注入假数据。比如你可以用依赖注入来伪造一个网络连接的实现，调用这个网络连接的时候就可以提供假数据。\n\n![](http://img.my.csdn.net/uploads/201503/28/1427507159_6700.png)\n\n\n### 策略4：把app分为小的libraries\n\n这个方法可以更好地模块化你的app。你的app被分为更小的类库之后，你可以为这些类库添加他们自己的UI依赖或gradle库依赖。\n\n当你有了自己的库，并提供依赖注入的支持，那么你可以为各个库写测试app。最后，可以写__集成测试__来确保类库直接的合作正确。\n\n比如我们有一个登陆功能的库，那么我可以写一个测试app只为这个登陆功能库：\n\n![](http://img.my.csdn.net/uploads/201503/28/1427507160_4803.png)\n\n#### 总结：\n\n1. 不要用E2E测试来代替UI测试。更好的做法是用单元测试 + 集成测试 + UI测试。\n2. 使用封闭测试策略\n3. 使用依赖注入\n4. 把app分为不同的小组件小类库，并分别写测试，然后再写集成测试来确保各组件之间的交互正确。\n5. 模块化 UI 测试已经被证明了比E2E测试快，并且十分稳定。这样的测试又能极大的提高开发效率。\n" }, { "path": "android-blog/readme.md", "content": "## Android官方博客" }, { "path": "androidweekly/Android中的人脸检测入门.md", "content": "Android中的人脸检测入门\n---\n\n> * 原文链接 : [An Introduction to Face Detection on Android](http://code.tutsplus.com/tutorials/an-introduction-to-face-detection-on-android--cms-25212?utm_source=Android+Weekly&utm_campaign=15ee59bb7a-Android_Weekly_181&utm_medium=email&utm_term=0_4eb677ad19-15ee59bb7a-337955857)\n* 原文作者 : [Paul Trebilcox-Ruiz](http://tutsplus.com/authors/paul-trebilcox-ruiz)\n* 译文出自 : [开发技术前线 www.devtf.cn](http://www.devtf.cn)\n* 转载声明: 本译文已授权[开发者头条](http://toutiao.io/download)享有独家转载权，未经允许，不得转载!\n* 译者 : [LangleyChang](https://github.com/LangleyChang) \n* 校对者: [desmond1121](https://github.com/desmond1121) \n* 状态 : 已完成\n\n\n\n随着Play服务8.1中引入了视觉库，作为一个开发者，Face Detection让你可以更容易的通过分析视频或图像来定位人脸(face)。一旦有了一个图像中人脸的列表，你就能获取到每个人脸的相关信息，比如方向，笑脸的概率，某人是睁眼还是闭眼，还有他们脸上特定的关键点(landmark)。\n\n\n这些信息在很多应用中都有用，比如一个相机应用，它可以在每个人都在睁着眼笑的时刻拍一张照片，或者给图片加一些搞笑的效果，比如牛角什么的。有一点很重要，注意人脸检测(Face Detection)并不是人脸识别(facial recognition)。尽管都是在获取一张脸的信息，(Play服务中的)视觉库并不会用这些信息来分辨两张脸是不是来自同一个人。\n\n\n这个教程会使用一张静止的图片来跑Face Detection API，然后获取有关照片中人物的信息。同时，还会在其上覆盖图形来展示获取到的信息。这个教程的所有代码都可以在[GitHub](https://github.com/tutsplus/Android-PlayServices-FaceDetection)上找到。\n\n\n![](https://cms-assets.tutsplus.com/uploads/users/798/posts/25212/image/unicorn.png)\n\n搞笑效果的例子，在人脸上添加牛角\n\n## 1. 建立项目\n\n\n为了把视觉库添加到你的项目中，你需要把Play服务8.1或更高版本导入到你的项目。这个教程仅仅导入了Play服务视觉库(Play Servcies Vision library)。打开你项目的**build.gradle**文件，把如下的编译行添加到`dependencies`结点中\n```groovy\ncompile 'com.google.android.gms:play-services-vision:8.1.0'\n```\n\n一旦你在你的项目中包含了Play服务，你就可以关掉**build.gradle**文件，然后打开**AndroidManifest.xml**。你需要在`manifest`的`application`结点添加一个`meta-data`项来定义人脸检测的依赖。\n```xml\n\n```\n\n完成了`AndroidManifest.xml`的建立，你就可以直接关掉它了。接着，你需要创建一个叫`FaceOverlayView.java`的新类。这个类继承了`View`，并且包含着项目中人脸检测的逻辑，其中包括显示分析的位图并且在图像上绘制用以示意的点。\n\n\n现在，在类的开头添加一个成员变量并且定义构造函数。`Bitmap`对象用来存储被分析的位图，`Face`对象中的`SparseArray`用来存储位图中发现的每张人脸。\n\n```Java\npublic class FaceOverlayView extends View {\n \n private Bitmap mBitmap;\n private SparseArray mFaces;\n \n public FaceOverlayView(Context context) {\n this(context, null);\n }\n \n public FaceOverlayView(Context context, AttributeSet attrs) {\n this(context, attrs, 0);\n }\n \n public FaceOverlayView(Context context, AttributeSet attrs, int defStyleAttr) {\n super(context, attrs, defStyleAttr);\n }\n}\n```\n\t\n\n\n接着，在`FaceOverlayView`中添加一个新的方法叫`setBitmap(Bitmap bitmap)`。这个方法当前只是简单把传给他的位图存起来，一会儿你要用这个方法来分析图像。\n\n```Java\npublic void setBitmap( Bitmap bitmap ) {\n mBitmap = bitmap;\n}\n```\n\n下一步，你需要一个位图。我已经在[GitHub](https://github.com/tutsplus/Android-PlayServices-FaceDetection)上的示例项目中包含了一张，但是你也可以拿你喜欢任何图片和Face Detection玩玩，看看哪些好使，哪些不好使。这个教程假设你的图片名为`face.jpg`。\n\n\n把你的图片放在`res/raw`目录下之后，打开`res/layout/activity_main.xml`。这个布局包含了一个`FaceOverlayView`引用，这样就可以把它显示在`MainActivity`中。\n\n```xml\n\n\n```\n\n布局定义好了，现在打开`MainActivity`，在`onCreate()`中建立`FaceOverlayView`。怎么建立呢？你先获取一个这个view的引用，接着从raw目录的输入流中读取`face.jpg`文件，然后把它转换成一个位图。一旦你拿到了这个位图，你就可以调用`FaceOverlayView`的`setBitmap()`方法把这幅图像传给你自定义控件了。\n\n```Java\npublic class MainActivity extends AppCompatActivity {\n \n private FaceOverlayView mFaceOverlayView;\n \n @Override\n protected void onCreate(Bundle savedInstanceState) {\n super.onCreate(savedInstanceState);\n setContentView(R.layout.activity_main);\n mFaceOverlayView = (FaceOverlayView) findViewById( R.id.face_overlay );\n \n InputStream stream = getResources().openRawResource( R.raw.face );\n Bitmap bitmap = BitmapFactory.decodeStream(stream);\n \n mFaceOverlayView.setBitmap(bitmap);\n \n }\n}\n```\n\n## 2.检测人脸\n\n既然你的项目已经建立完成了，现在就该开始检测人脸了。在`setBitmap(Bitmap bitmap)`中你需要创建一个`FaceDetector`。可以通过用一个`FaceDetector.Builder`来创建。它允许你定义多个参数，这些参数影响着你多快能检测出人脸和`FaceDetector`还能生成其他什么数据。\n\n你选择什么设置取决于你想在应用中做什么。如果你开启了关键点(landmark)搜索，那么检测人脸的速度就会慢一些。这和程序设计的大多数时候一样，鱼和熊掌不可兼得。想了解更多关于`FaceDetector.Builder`中的可用选项，你可以查看Android开发网站的官方文档。\n\n```Java\nFaceDetector detector = new FaceDetector.Builder( getContext() )\n .setTrackingEnabled(false)\n .setLandmarkType(FaceDetector.ALL_LANDMARKS)\n .setMode(FaceDetector.FAST_MODE)\n .build();\n```\n\n同时，你也需要看看`FaceDetector`是否可用。当一个用户第一次在他的设备上使用人脸检测的时候，Play服务需要跳出来加载一系列小的原生库来处理你的请求。虽然大多数情况下这都能在你的应用结束前完成，你还是需要处理加载失败的意外情况。\n\n如果`FaceDetector`是可用的，那你就可以把你的位图转成一个`Frame`对象，然后把它传给检测器来获取图像中关于人脸的数据。完成了以后，你需要释放检测器，防止内存泄漏。当人脸检测完成了以后，你就可以调用`invalidate()`来触发这个控件的重绘了。\n\n```Java\nif (!detector.isOperational()) {\n //Handle contingency\n} else {\n Frame frame = new Frame.Builder().setBitmap(bitmap).build();\n mFaces = detector.detect(frame);\n detector.release();\n}\ninvalidate();\n```\n\n既然你已经从图像中检测到了人脸，现在就该用它们了。在这个例子中，你简单的在每个脸周围画一个绿框。因为`invalidate`已经在检测完人脸后调用了，所以你可以在`onDraw(Canvas canvas)`中添加必要的逻辑。这个方法得确保位图和人脸都已经设置好了，然后就开始在画布上绘制位图，再在每个脸的周围绘制一个框。\n\n因为不同的设备有不同的显示尺寸，你需要跟踪位图的缩放大小，让整个图片在不同的设备上都时刻可见，上面的覆盖物也要合适的绘制。\n\n```Java\n@Override\nprotected void onDraw(Canvas canvas) {\n super.onDraw(canvas);\n \n if ((mBitmap != null) && (mFaces != null)) {\n double scale = drawBitmap(canvas);\n drawFaceBox(canvas, scale);\n }\n}\n```\n\n`drawBitmap(Canvas canvas)`将你的位图绘制在画布上，并且把它的大小调整合适。同时，它还会返回一个系数以正确调整其他尺寸的比例。\n\t\n```Java\nprivate double drawBitmap( Canvas canvas ) {\n double viewWidth = canvas.getWidth();\n double viewHeight = canvas.getHeight();\n double imageWidth = mBitmap.getWidth();\n double imageHeight = mBitmap.getHeight();\n double scale = Math.min( viewWidth / imageWidth, viewHeight / imageHeight );\n \n Rect destBounds = new Rect( 0, 0, (int) ( imageWidth * scale ), (int) ( imageHeight * scale ) );\n canvas.drawBitmap( mBitmap, null, destBounds, null );\n return scale;\n}\n\n```\n\n每一个检测出的人脸都有一个其左上角的位置信息。`drawFaceBox(Canvas canvas, double scale)`这个方法比较有趣，它会用利用这个位置按照每张脸的宽度和高度画一个绿色的矩形把它们都圈出来。\n\n你需要定义你的`Paint`对象，然后循环遍历`SparseArray`的每一个`Face`找到它的位置，宽度和高度，然后用这些信息在画布上画出矩形。\n\n\n```Java\nprivate void drawFaceBox(Canvas canvas, double scale) {\n //paint should be defined as a member variable rather than \n //being created on each onDraw request, but left here for \n //emphasis.\n Paint paint = new Paint();\n paint.setColor(Color.GREEN);\n paint.setStyle(Paint.Style.STROKE);\n paint.setStrokeWidth(5);\n \n float left = 0;\n float top = 0;\n float right = 0;\n float bottom = 0;\n \n for( int i = 0; i < mFaces.size(); i++ ) {\n Face face = mFaces.valueAt(i);\n \n left = (float) ( face.getPosition().x * scale );\n top = (float) ( face.getPosition().y * scale );\n right = (float) scale * ( face.getPosition().x + face.getWidth() );\n bottom = (float) scale * ( face.getPosition().y + face.getHeight() );\n \n canvas.drawRect( left, top, right, bottom, paint );\n }\n}\n```\n\n现在，你的应用应该能跑了，并且你能看到图像中每一个检测出来的脸上都用矩形框了起来。注意，现在Face Detection API仍然相当稚嫩，所以它可能不会检测出每一张脸。你可以折腾折腾`FaceDetector`中的其他设置，看看能不能获得一些数据，尽管我也不能保证。\n\n![](https://cms-assets.tutsplus.com/uploads/users/798/posts/25212/image/facebox.png)\n\n人脸被检测了出来并用矩形框出\n## 3.理解关键点\n\n关键点是一个人脸中一些感兴趣的点。Face Detection API不用关键点来检测人脸，但是可以检测到脸的整体轮廓之后再寻找关键点。这就是为什么发现关键点在是一个可以用`FaceDetector.Builder`开启的可选选项。\n\n你可以把这些关键点作为一个额外的信息源，比如对象的眼睛在哪里，这样你就可以在你的应用中恰当的交互。可被找到的关键点共有十二个：\n\n* 左右眼\n* 左右耳\n* 左右耳廓尖\n* 鼻子基部\n* 左右脸颊\n* 嘴的左右角\n* 嘴基部\n\n哪些关键点是可用的取决于检测到的脸的角度。举个例子，某人的侧脸中只能检测到一个可见的眼睛，这意味着另一个眼睛是检测不到的。下面的表格概括了基于人脸的欧拉Y角度(左右方向)哪些关键点是可以被检测到的\n \n| 欧拉 Y 角度 | 可见的关键点 | \n| ------------- |:-------------:| \n| < -36° | 左眼，嘴的左半边，左耳，鼻子基部，左脸颊 | \n| -36° to -12° | 嘴的左半边，鼻子基部，嘴的底部，右眼，左眼，左脸颊，左耳尖 | \n| -12° to 12° | 右眼，左眼，鼻子基部，左脸颊，右脸颊，嘴的左半边，嘴的右半边，嘴的底部 | \n| 12° to 36° | 嘴的右半边，鼻子基部，嘴的底部，左眼，右眼，右脸颊，右耳尖|\n| > 36° | 右眼，嘴的右半边，右耳，鼻子基部，右脸颊 |\n\n\n不管你信不信，在你的应用中使用关键点也是非常的容易，因为你已经在人脸检测的时候把它们包含到了你的项目中了。你只需要调用一个`Face`对象的`getLandMarks()`就能获取到一个`LandMark`对象的`List`，这样你就能使用它了。\n\n\n你这个教程中，你将会在每个检测出的关键点上绘制一个小圆圈，只需调用一个新的方法`drawFaceLandmarks(Canvas canvas, double scale)`。这个方法是在`onDraw(Canvas canvas)`调用，而不是`drawFaceBox(Canvas canvas)`。它会获取每个关键点的位置，根据位图的比例调整它的大小，然后绘制出示意关键点的圆圈。\n\n```Java\nprivate void drawFaceLandmarks( Canvas canvas, double scale ) {\n Paint paint = new Paint();\n paint.setColor( Color.GREEN );\n paint.setStyle( Paint.Style.STROKE );\n paint.setStrokeWidth( 5 );\n \n for( int i = 0; i < mFaces.size(); i++ ) {\n Face face = mFaces.valueAt(i);\n \n for ( Landmark landmark : face.getLandmarks() ) {\n int cx = (int) ( landmark.getPosition().x * scale );\n int cy = (int) ( landmark.getPosition().y * scale );\n canvas.drawCircle( cx, cy, 10, paint );\n }\n \n }\n}\n```\n\n在调用了这个方法之后，你应该能看到许多绿色的小圆圈覆盖在检测到的人脸上，如下面的例子所示。\n![](https://cms-assets.tutsplus.com/uploads/users/798/posts/25212/image/landmarks.png)\n\n在检测到的关键点之后放置圆圈\n\n## 4.额外的人脸数据\n\n\n人脸的位置和关键点是很有用，但是你还可以通过一些`Face`对象的内置方法在检测到的人脸中发现更多的信息。`getIsSmilingProbability()`,`getIsLeftEyeOpenProbability()`和`getIsRightEyeOpenProbability()`方法会返回一个0.0到1.0的浮点数，你可以用其确定眼睛是否睁开或者检测到的这个人是否在笑。返回值越接近1.0，这个人就越有可能在小或者他的左右眼越有可能是睁开的。\n\n你也可以通过检查图像的欧拉值找出一张图像中人脸在Y轴和Z轴上的角度。Z欧拉值的一直都能收到。但是，要想接受到X值你必须使用精确模式。在下面的代码片段中你会看到如何获取这些值。\n\n```Java\nprivate void logFaceData() {\n float smilingProbability;\n float leftEyeOpenProbability;\n float rightEyeOpenProbability;\n float eulerY;\n float eulerZ;\n for( int i = 0; i < mFaces.size(); i++ ) {\n Face face = mFaces.valueAt(i);\n \n smilingProbability = face.getIsSmilingProbability();\n leftEyeOpenProbability = face.getIsLeftEyeOpenProbability();\n rightEyeOpenProbability = face.getIsRightEyeOpenProbability();\n eulerY = face.getEulerY();\n eulerZ = face.getEulerZ();\n \n Log.e( \"Tuts+ Face Detection\", \"Smiling: \" + smilingProbability );\n Log.e( \"Tuts+ Face Detection\", \"Left eye open: \" + leftEyeOpenProbability );\n Log.e( \"Tuts+ Face Detection\", \"Right eye open: \" + rightEyeOpenProbability );\n Log.e( \"Tuts+ Face Detection\", \"Euler Y: \" + eulerY );\n Log.e( \"Tuts+ Face Detection\", \"Euler Z: \" + eulerZ );\n }\n}\n```\n## 结论\n\n在这个教程中，你已经学到了Play服务视觉库的一个主要组件，**Face Detection**。你现在知道如何在一张静止的图像中检测人脸，如何获取其中的信息，然后从每张人脸中找到重要的关键点。\n\n用你学到的东西，你应该可以在你自己的应用中添加一些很棒的特性，比如添加静态图像、在视频中跟踪人脸或者你能想到的任何创意。\n" }, { "path": "androidweekly/Android性能案例研究续集/readme.md", "content": "# Android性能案例研究续集\n---\n> * 原文链接 : [Android Performance Case Study Follow-up](http://www.curious-creature.com/2015/03/25/android-performance-case-study-follow-up/?utm_source=Android+Weekly&utm_campaign=0692ef161b-Android_Weekly_146&utm_medium=email&utm_term=0_4eb677ad19-0692ef161b-337914749)\n> * 译者 : [shenyansycn](https://github.com/shenyansycn)\n> * 校对 : [Mr.Simple](https://github.com/bboyfeiyu)\r\r两年前，我发表了名为Android Performance Case Study的文章来帮助Android开发者了解什么工具和技术能被应用到识别、追踪和解决性能问题上。\r\r这篇文章的示例程序叫Falcon Pro，是由Joaquim Vergès设计和开发的一个Twitter客户端。感谢Joaquim让我以Flacon Pro为例来处理我做演示。一切都很顺利，直到Joaquim开始开发Falcon Pro 3，在发布他新的应用之前不久，Joaquim因为需要解决一个影响滚动的性能问题他联系到了我（这一次我依然没有他的源码可以参考）。\r\rJoaquim使用了所有工具来检测问题所在，但是都发现与之前猜测的原因无关。比如，他发现并不是overdraw引发问题。于是他将范围缩小到ViewPager类，他发给我如图1-1：\r \r![image](http://androidperformance.com/images/android-performance-case-study-follow-up/falconpro3.png) \n图1-1 \n\rJoaquim使用系统的GPU图形分析工具发现了帧速的下降。左边的截图展示了没有Viewpage的滚动性能时间轴，右边的展示了有Viewpager的时间轴（他使用2014年的Moto X获得这些数据）。这个问题根源看起来非常明显。\n\r我的第一反应是ViewPager是不是误用了硬件加速。我们观察到的这个性能问题可能在List滚动时每一帧硬件层都被更新了。系统的 hardware layers updates debugging tool 没有提供有价值的信息。我检查了两次HierarchyViewer， 但ViewPager表现令我感到满意。（相反，我认定它不太可能出现问题）\n\r我转而使用了另一个强大的、不常用的工具: Tracer for OpenGL。我前一篇文章解释了这个工具的更多细节。这个工具收集了所有你想知道的UI工具发送给GPU的绘画命令。\n\rAndroid4.3及以前：从Android4.3我们引进了reordering and merging of drawing commands后，Tracer变得难以使用。reordering and merging of drawing commands是一个令人惊讶的有用优化，但是他阻止了来自view的组绘画命令。使用如下命令（在启动你的应用前）你可以通过关闭显示list优化来恢复旧的行为。\n\r分析OpenGl Traces：蓝色的命令显示屏幕上绘制像素的GL操作。其他所有被用于传输数据或者设置状态命令能很容易的被忽略掉。每次你点击蓝色的命令，Tracer会更新Detail选项卡，在你点击的被执行后立即显示当前渲染对象的内容。通过一个接一个的点击，你可以重建每一帧。这几乎就是我用Trace分析性能问题的流程。了解被渲染的一帧都提供了什么。\r\r当仔细看收集到的traces时，我惊奇的发现了一些SaveLayer/ComposeLayer命令块，r如图1-2。\r \r![](http://androidperformance.com/images/android-performance-case-study-follow-up/glTrace.png) \n图 1-2 \r\r\r这些块表明创建和合成了临时性的硬件层。这些临时硬件层被不同的Canvas.saveLayer()创建。当下面的特殊条件被满足时，UI 系统调用 Canvas.saveLayer()函数来绘制视图，并且alpha值小于1：\n\r* getAlpha() 返回一个小于1的值\r* onSetAlpha() 返回 false\r* getLayerType() 返回LAYER_TYPE_NONE\r* hasOverlappingRendering() 返回 true\n\r在一些演讲中，Chet和我解释了为什么要谨慎使用alpha的原因 ( 译者注 : 关于alpha问题可以参考这篇文章 [Android Tips: Best Practices for Using Alpha](http://imid.me/blog/2014/01/17/best-practices-for-using-alpha/))。那就是每一次UI系统必须使用临时硬件层时，绘画命令发送给不同的渲染对象，对于GPU来说切换不同的渲染对象是非常耗时的操作。对于用tiling/deferred 架构的GPU是一个硬伤(例如ImaginationTech’s SGX, Qualcomm’s Adreno等等)。直接渲染架构更好在这种情况下的表现会稍微好一些，例如：Nvidia。但是Joaquim和我使用的手机都是使用了Qualcomm Adreno GPU 的Moto X 2014版，因此多个临时硬件层的使用可能是引起这个性能问题的根源。\n\r更重要的问题是：是什么创建了这些临时层？Tracer给了我们答案。如果你看到了Tracer的截屏，你能看到仅是一组OpenGL的SaveLayer命令在一个小的渲染对象循环调用了。现在让我们看下应用截图， 如图1-3：\r\r![](http://androidperformance.com/images/android-performance-case-study-follow-up/before.png) \n图1-3\n \r你看到顶部的几个小圆点了么？这是ViewPager指示器，用于显示使用者的页面位置。Joaquim使用了一个第三方库来画这些指示器。当前页面的指示器是一个白色的圆点，其他页面的指示器是一个灰色的圆。我说“什么导致了它显示为灰色”，因为这些圆实际上是半透明的白色圆点。这个库中对于每一个圆都用了一个View（这本身就是浪费）并调用setAlpha()改变他们的颜色。\r\r这里有一些修复这个问题的几个解决方案：\r\r* 使用一个可定制的颜色来代替在View上设置不透明度;\r* 使hasOverlappingRendering()返回false，然后系统会为你设置一个适当的alpha值到画笔上；（译者注 : 对于有重叠内容的View，系统简单粗暴的使用 offscreen buffer来协助处理。当告知系统该View无重叠内容时，系统会分别使用合适的alpha值绘制每一层。）\r* 使onSetAlpha()返回true，并设置Paint的alpha来绘画灰色的圆。\n\r最合适的是第二种方法，但最低支持API level 16.如果你必须支持老版本，可以使用另外两个方法中的一个。我相信Joaquim会抛弃第三方库并使用他自己的指示器。\r\r我希望这篇文章中市我们能够意识到性能问题很可能出现在看似无害的操作上。请记住：不要假设，实践出真理！\r \r" }, { "path": "androidweekly/Kotlin for Android (II)创建一个工程/readme.md", "content": "Kotlin for Android (II)创建一个工程\n---\n\n>\n* 原文链接 : [Kotlin for Android (II): Create a new project](http://antonioleiva.com/kotlin-android-create-project/)\n* 译者 : [Lollypo](https://github.com/Lollypo) \n* 校对者: [chaossss](https://github.com/chaossss)\n* 状态 : 校对中\n\n\n当我从[what Kotlin is and what it can do for us](http://antonioleiva.com/kotlin-for-android-introduction/)获得一些启发之后,觉得是时候配置下 Android Studio来帮助我们使用Kotlin开发Android应用程序了. 其中有些步骤只需要在初次使用时完成一次, 但是其他一些Gradle配置需要为每一个新项目做一遍. ( 译者注 : 如果你对Kotlin还不了解，可以先看看[kotlin-for-android简介](https://github.com/bboyfeiyu/android-tech-frontier/blob/master/androidweekly/kotlin-for-android%E7%AE%80%E4%BB%8B)这篇文章 )\n\n对于本系列文章, 我将创建一个我早些时候创建的[Bandhook](https://play.google.com/store/apps/details?id=com.limecreativelabs.bandhook)的简化版本, 它基本上就是连接到一个基于RESTful的音乐API然后接收一些乐队的信息. 链接到 [Bandhook Kotlin on Github](https://github.com/antoniolg/Bandhook-Kotlin) 查看源代码.\n\n\n###创建一个新项目然后下载Kotlin插件###\n\n就像你平常做的那样，我们只需要用Android Studio创建一个带Activity的基本Android项目。\n\n一旦完成,我们需要做的第一件事就是去下载Kotlin插件. 去到Android Studio的系统设置中然后查找plugins.之后，再次使用搜索找到Kotlin插件，安装并重启IDE。\n\n![kotlin-plugin](http://7xi8kj.com1.z0.glb.clouddn.com/kotlin-plugin-e1424632570741.png)\n\n###添加Kotlin插件的依赖到的应用程序的build.gradle中###\n\n该项目的build.gradle需要添加一个新的依赖，这个依赖将会被Kotlin插件要求以在主Module中使用:\n```gradle\nbuildscript {\n repositories {\n jcenter()\n }\n dependencies {\n classpath 'com.android.tools.build:gradle:1.1.3'\n classpath 'org.jetbrains.kotlin:kotlin-gradle-plugin:1.0.0'\n }\n}\n```\n\n\n\n###配置Module的build.grade###\n\n首先, 应用Kotlin插件:\n```gradle\napply plugin: 'com.android.application'\napply plugin: 'kotlin-android'\n```\n接着, 添加Kotlin库到你的依赖:\n```gradle\ndependencies {\n compile fileTree(dir: 'libs', include: ['*.jar'])\n compile 'org.jetbrains.kotlin:kotlin-stdlib:1.0.0'\n}\n```\n最后, 你需要添加我们在下一个步骤创建的Kotlin文件夹:\n```gradle\nandroid {\n compileSdkVersion 22\n buildToolsVersion \"22.0.0\"\n \n ...\n \n sourceSets {\n main.java.srcDirs += 'src/main/kotlin'\n }\n}\n```\n或者,你可以跳过这一步,当做完下一个步骤时，使用这个Android Studio的操作:\n\n![configure-kotlin-project](http://7xi8kj.com1.z0.glb.clouddn.com/configure-kotlin-project.png)\n\n我更倾向于手动去做以保持我的Gradle文件有整洁有序, 但第二个选项可能较为容易些。\n\n\n\n###创建Kotlin文件夹###\n\n如果你将项目的视图从‘Android’转到‘Project’，那将会非常容易。依次选择‘app->src->main’ 然后创建一个名为 ‘kotlin'的文件夹:\n\n![kotlin-folder](http://7xi8kj.com1.z0.glb.clouddn.com/kotlin-folder.png)\n\n\n\n###将Java activity转换成Kotlin文件###\n\nKotlin插件能将Java转换为Kotlin类. 我们可以轻松的通过‘Code’菜单中的‘Convert Java File to Kotlin File'选项转换当前的Activity到Kotlin类 :\n\n![convert-java-to-kotlin](http://7xi8kj.com1.z0.glb.clouddn.com/convert-java-to-kotlin-e1424633562637.png)\n\nIDE将建议你移动新文件到Kotlin文件夹，点击‘Move File’(或者手动完成，假如你没看到这个选项).\n```java\npublic class MainActivity : ActionBarActivity() {\n \n override fun onCreate(savedInstanceState: Bundle?) {\n super.onCreate(savedInstanceState)\n setContentView(R.layout.activity_main)\n }\n \n \n override fun onCreateOptionsMenu(menu: Menu): Boolean {\n // Inflate the menu; this adds items to the action bar if it is present.\n getMenuInflater().inflate(R.menu.menu_main, menu)\n return true\n }\n \n override fun onOptionsItemSelected(item: MenuItem): Boolean {\n // Handle action bar item clicks here. The action bar will\n // automatically handle clicks on the Home/Up button, so long\n // as you specify a parent activity in AndroidManifest.xml.\n val id = item.getItemId()\n \n //noinspection SimplifiableIfStatement\n if (id == R.id.action_settings) {\n return true\n }\n \n return super.onOptionsItemSelected(item)\n }\n}\n```\n\n\n\n###主要区别###\n\n看一看之前的代码, 我们可以看到一些明显的差异。 其中很大一部分我们将会在下一篇文章讲解到:\n\n- 使用冒号，而不是'extends'。\n- 显式使用‘override': 在Java中, 我们可以使用一个注释使我们的代码更清晰,但它不是必要条件. Kotlin将迫使我们使用它.\n- 函数则使用‘fun’关键字: Kotlin是一个面向对象的函数式语言, 因此可能会与其他语言类似，例如Scala. Java方法被函数的形式表示。\n- 函数参数命名规则不同: 类型和名称都写在相反的位置,并用冒号隔开。\n- 分号可选: 我们不需要在行的结尾处加上分号。如果我们想要也可以加上, 但如果我们不这样做，它就可以节省大量的时间,并使我们的代码整洁。\n- 其他小细节: 在简介一文中, 我已经说到了 ‘?’ 的意义. 这表明参数可以为空。NULL的处理方式不同于Java。 \n\n\n\n###总结###\n\n也许我们会认为使用一门新语言将会非常困难, Kotlin被JetBrains团队开发出来的，要成为最容易和可交互的语言用来覆盖那些Java的不足之处。由于Android Studio也是基于JetBrains的产品，这将让集成到这个IDE中并且开始工作非常简单。\n\n下一篇文章将介绍一些让我们在使用Kotlin开发Android应用程序时，能让开发过程更简单的奇巧淫技。\n" }, { "path": "androidweekly/Kotlin for Android (III)-扩展函数与默认值/readme.md", "content": "Kotlin for Android (III)/ 扩展函数与默认值\n---\n\n>\n* 原文链接 : [Kotlin for Android (III): Extension functions and default values](http://antonioleiva.com/kotlin-android-extension-functions/)\n* 译者 : [Lollypo](https://github.com/Lollypo) \n* 校对者: [Mr.Simple](https://github.com/bboyfeiyu)\n* 状态 : 校对完成\n\n现在你已经了解[Kotlin基础](http://antonioleiva.com/kotlin-for-android-introduction/)与[如何配置你的项目](http://antonioleiva.com/kotlin-android-create-project/),是时候谈论Kotlin能为我们做哪些Java做不到的有趣的事情了.请记住,如果你对Kotlin语言有任何疑问,可以参考[官方文档](http://kotlinlang.org/docs/reference/).这份文档条理分明、简单易懂, 而且我这篇文章不会涉及到语言的基础部分.\n\n\n\n### 扩展函数\n\nKotlin的扩展函数功能可以让我们添加新的函数到现有的类上而不必去修改它本身.例如,我们可以轻松的的通过扩展函数语法将一个显示Toast的函数添加到Activity类中:\n\n```java\nfun Activity.toast(message: CharSequence, duration: Int = Toast.LENGTH_SHORT){
\n Toast.makeText(this, message, duration)
\n}\n```\n\n我们可以在任意的地方声明这个函数(例如一个工具类文件), 并在我们的Activities中当作一个普通方法使用:\n\n```java\noverride fun onCreate(savedInstanceState: Bundle?) { \n super.onCreate(savedInstanceState)
 \n toast(\"This is onCreate!!\")
\n}\n```\n\n声明一个扩展函数跟添加类名到函数名上一样简单.这个函数将被作为导入的类使用. \n\n这可以帮助我们简化代码而且让封闭的类打破局限.但是我们必须小心和适度的使用.最后,这些函数通常会替代工具类.工具方法通常是静态的且不能被修改. 因此,过度使用通常是表示我们懒得创建一个委托类.\n\n这里是另一个有趣的例子,让我解释另一个有趣的概念:具体类型(reified types).\n\n```java\ninline public fun Activity.navigate(id: String) {
\n val intent = Intent(this, javaClass())\n
 intent.putExtra(\"id\", id)\n
 startActivity(intent)
\n}\n```\n\n内联函数可以使用具体类型,这意味着我们可以从内部函数取得类而不用通过将类类型作为参数.\n\n> 内联函数的有点不同于一般的函数.内联函数将会在编译过程中替换代码而不是真的调用一个函数. 这会简化某些场景.例如,如果我们将一个函数作为参数,常规函数将在内部创建一个包含该函数de对象,.另一方面,内联函数会在函数被调用的地方替换掉,因此它真的不需要一个内部对象.\n\n > ```java\n navigate(\"2\")\n ```\n\n使用具体类型,我们可以在函数内部创建一个意图, 并使用扩展函数,我们可以直接调用startActivity().\n\n\n\n### 可选参数与默认值\n\n\n由于有参数默认值和构造函数,你永远不需要重载函数了.一个声明可以满足你所有的需求.回到Toast示例:\n\n```java\nfun Activity.toast(message: CharSequence, duration: Int = Toast.LENGTH_SHORT){
\n Toast.makeText(this, message, duration)
\n}\n```\n\n第二个参数指的是Toast的持续时长.它是可选参数,在没有指定的情况下,将使用Toast.LENGTH_SHORT作为默认值.现在你有两种方法调用这个函数:\n\n```java\n toast(\"Short Toast!!\")\n toast(\"Long Toast!!\", Toast.LENGTH_LONG)\n```\n\n对于第二个示例,我们也许想添加一些转换棒棒糖的参数:\n\n```java\ninline public fun Activity.navigate(\n
 id: String,
\n sharedView: View? = null,\n
 transitionName: String? = null) {
 
 \n ...\n
}\n```\n\n我们现在有两种不同的方式调用相同的函数:\n\n```java\nnavigate(\"2\")\nnavigate(\"2\", sharedView, TRANSITION_NAME)\n```\n\n甚至是第三种,虽然在大多数情况没什么意义,但是可以帮助我们理解另一种概念:我们可以使用参数名来决定我们想调用哪些参数:\n\n```java\nnavigate(id = \"2\", transitionName = TRANSITION_NAME)\n```\n\n可选参数可以被用于默认构造函数,因此你可以通过一个声明实现许多的重载方法.自定义视图是一个特例, 因为在Java中它们需要多个构造函数才能够正常工作.我将会在下一篇文章讲解到.\n\n\n\n## 总结\n\n通过这两个优势,我们可以简化大量的代码甚至可以做那些Java中不可能的事情.Kotlin真的是简洁明了.下一篇文章将会讲解Kotlin的Android拓展,这可以让我们在Activities中自动注入视图,与如何在Kotlin中自定义View.\n\n记得浏览一下[示例库](https://github.com/antoniolg/Bandhook-Kotlin)来看一下它的实际应用." }, { "path": "androidweekly/ListView或者RecycleView滚动时隐藏Toolbar-part-1/readme.md", "content": "ListView或者RecycleView滚动时隐藏Toolbar (1)\n---\n\n>\n* 原文链接 : [How to hide/show Toolbar when list is scroling (part 1)](http://mzgreen.github.io/2015/02/15/How-to-hideshow-Toolbar-when-list-is-scroling%28part1%29/)\n* 译者 : [chaossss](https://github.com/chaossss) \n* 校对者: [这里校对者的github用户名](github链接) \n* 状态 : 校对中\n\n\n今天我打算写一篇博文给大家介绍Google+ App的一个酷炫效果——向上/向下滚动ListView/RecyclerView时，Toolbar和FAB（屏幕右下方的小按钮）会隐藏/出现。这个效果也被Google视为符合 Material Design 规范的效果哦，详情参见： [Material Design Checklist](http://android-developers.blogspot.com/2014/10/material-design-on-android-checklist.html) 。\n\n\n> 如果可以的话，我们希望当屏幕向下滚动时，App的Toolbar和FAB将离开屏幕，从而在垂直方向上为可显示区域腾出更大的空间来显示我们的内容。而当我们的屏幕向上滚动时，App的Toolbar和FAB会再次出现。\n\n我们做出来的最终效果应该是下面这样的：\n\n![](http://img.my.csdn.net/uploads/201503/27/1427447324_1070.gif)\n\n在这篇博文的讲解中，我们将会用RecyclerView作为我们的list，但这不代表其他可滚动的容器就不能实现这样的效果了，只是其他的可滚动容器（如：ListView）需要要多花一些功夫才能实现这个效果。那么我们要怎么去实现呢？我想到了两个办法：\n\n- 对list容器加一个Padding\n- 对list容器加一个Header\n\n就我个人而言，我更想用第二种方法去实现，因为在设计代码的过程中我发现：为RecyclerView添加Header会产生几个问题，这给了我很好的机会去思考如何解决它，与此同时，在这个思考和解决问题的过程中我还能学习到更多的知识，何乐而不为呢？不过我还是会给大家简要地介绍如何使用第一种方法实现的啦！\n\n## 那就让我们开始今天的讲解吧！ \n\n首先，我们需要创建一个工程和添加必要的工具库：\n\n接着我们需要定义 styles.xml ，以确保我们的App没有添加Actionbar（因为我们将会使用Toolbar），同时我们App的设计风格要符合Google的 Material Design 规范。\n\n最后我们就要创建我们activity中显示的布局：\n\n事实上，我们只需要一个简单的布局，其中包含了：RecyclerView，Toolbar和ImageButton。但需要注意的是：我们需要把它们放在一个FrameLayout里，否则当我们隐藏Toolbar时list的上方将会出现一个空白区域，这显然不会是我们想要的效果。我们理想的效果应该是：当Toolbar被隐藏，list能在屏幕的可见区域中显示出一整个列表，而这就需要通过使Toolbar覆盖在RecycleView上面来实现。\n\n接着来看看我们MainActivity代码吧：\n\n就像你看到的那样，这是一个只重写了OnCreate()方法，非常非常非常简单的Activity。而且OnCreate()方法也只做了下面三件事情：\n\n1. 初始化Toolbar\n\n1. 获取mFabButton的引用（mFabButton是FAB的对象哦，也就是屏幕右下方的小按钮）\n\n1. 初始化RecyclerView\n\n为了在list中显示出内容，我们现在就要为RecyclerView创建一个Adapter啦。但在此之前，我们应该为我们list中的item添加相应的子布局以及对应的ViewHolder：\n\nlist的每一个item只需要一个text用来显示文字，非常简单！\n\n那RecyclerAdapter该怎么实现呢：\n\n就像你看到的这样，这是一个非常普通的RecycleView.Adapter，没有任何特别的地方，是不是感觉被骗了呐 23333～（如果你想要了解更多有关RecyclerView知识，我强烈建议你去看大牛 Mark Allison's 巨巨写的这些优秀文章 [series of posts](https://blog.stylingandroid.com/material-part-4/)）\n\n经过上面的努力，我们已经把车子的小零件组装的七七八八啦，是时候让小车子上路跑一跑，展现真正的技术了！\n\n![](http://img.my.csdn.net/uploads/201503/27/1427447324_5421.png)\n\nWTF，谁能告诉我这是什么鬼……？\n\n我相信只要不是瞎子都会发现，App的Toolbar竟然把我们的item挡住了！！！或许部分机智的小伙伴已经发现了问题所在：出现这样的问题是因为我们在activity_main.xml里使用了FrameLayout，正是FrameLayout导致了这样的问题，而这就是我开头所提到的问题之一了。\n\n第一个解决办法是为我们的RecyclerView添加一个PaddingTop，并将PaddingTop的值设置为Toolbar的高度。但有一个细节我们不能忽略，那就是RecyclerView会默认裁剪到子View的Padding区域，所以为了我们伟大的事业，我们必须把这个特性关掉。\n\n经过这些修改之后，我们就能实现我们想要的效果，这就是我所说的第一种方法。但如我所说，我写这篇博文的目的，不仅仅只是教你实现这个效果，然后就完了。我想教给你实现同一个效果各种各样的方法，并且为你介绍其中的思想，让你接触到平常很难接触到的问题并教你如何解决它。有些方法固然会更加复杂（在本文中是为list添加一个Header），但你在实现过程中也能学到更多的知识，毕竟授人以鱼不如授人以渔嘛。\n\n## 为RecycleView添加一个Header\n\n\n要用第二种方法去实现这个效果，首先我们要做的就是稍微修改一下我们的Adapter：\n\n下面是其实现原理：\n\n我们需要定义一个常量来区分Recycler展现的item的类型。这里我需要为你介绍的是:RecyclerView是一个非常灵活的组件,RecyclerView 完全能实现你想要让list的item具有各种各样不同的布局的愿望，而此时，我们定义来区分item类型的常量就会被利用到。而这样的特性正是我们想要的——让Header成为RecyclerView的第一个item，显然这会与其余的item不一样。（第3-4行）\n\n因而我们需要让Recycler知道它需要展示的子布局是什么类型的，在本文中我们用作类型区分的常量则是TYPE_ITEM和TYPE_HEADER。（第49-54行）\n\n接着，我们需要修改onCreateViewHolder()和onBindViewHolder()方法，如果item的类型是TYPE_ITEM的话，使它们返回和绑定一个普通的item；如果item的类型是TYPE_HEADER的话，则返回Header。（第14-34行）\n\n此外，由于我们的list并不仅仅只有普通的item，我们还在list中添加了Header，因此我们需要修改getItemCount()方法的返回值，让我们的返回值是普通item的总数量 + 1（第43-45行）\n\n最后让我们来为Header布局创建一个layout和一个ViewHolder，但出乎意料的是，我们需要为Header创建的layout和ViewHolder都非常简单，唯一需要注意的是：Header的高度必须和Toolbar的高度一致。\n\n那么这样我们就把布局弄好啦～不信你看图！\n\n![](http://img.my.csdn.net/uploads/201503/27/1427447325_8379.png)\n\n所以总的来说，我们为RecyclerView添加了一个和Toolbar有相同高度的Header，而现在我们的Toolbar把header隐藏起来了（因为header现在是一个空的view)，同时，我们所有的普通item都是可见的。那么现在就让我们来实现滚动时改变Toolbar和FAB的出现和隐藏吧！\n\n## 滚动时控制Toolbar和FAB的出现和隐藏 \n\n\n为了实现这个效果，我们为RecyclerView再创建一个——OnScrollListener类就够了你敢信？\n\n我现在还要告诉你，在OnScrollListener类里，我们只需要重载onScrolled()方法就能让这个酷炫的效果成为App中秒杀用户的黑魔法！其中，onScrolled()方法的参数——dx,dy分别是水平和垂直方向上的滚动距离。但大家需要注意的是：这里dx，dy并不是代表屏幕上的物理距离，而是两个事件的相对距离。\n\n具体的实现算法大体如下：\n\n只有当list向上滚动且Toolbar和FAB被隐藏，抑或是当list向下滚动且Toolbar和FAB出现，我们才会计算总的滚动距离，因为这两种情况下的滚动距离才是我们实现这个效果所需要关心的。\n\n总的滚动距离需要超过我们展现/隐藏Toolbar和FAB所在的方向的极限值才能将其展现/隐藏（你把极限值调整的越大，通过滚动展示/隐藏Toolbar和FAB需要的距离就越大）（dy>0意味着我们在向下滚动，dy<0意味着我们在向上滑动）\n\n实际上我们并没有在我们的滚动监听类里面展现/隐藏Toolbar和FAB，我们是通过调用show()/hide()方法来展现/隐藏Toolbar和FAB的，所以调用者可以通过接口实现它。\n\n现在我们需要为RecyclerView添加它的监听：\n\n下面是我们通过动画改变我们的视图的方法：\n\n当我们隐藏Toolbar和FAB的时候，我们必须把Padding也考虑进去，不然的话视图并不能够完全被隐藏。\n\n是骡子是马，让我们拉出来溜一溜！\n\n![](http://img.my.csdn.net/uploads/201503/27/1427447325_8449.gif)\n\n虽然现在看起来已经很nice了，但其实这里有一个小小的bug——如果你在list的顶部，此时临界值非常小，因而你能隐藏Toolbar，但你在list的顶部会看到有一个空白的区域。不过幸好这里有一个很简单的方法可以解决这个bug：我们可以通过检测当前list的第一个item是否为可见的，只有当它不可见，才使用我们设计的展示/隐藏逻辑。\n\n在这样的修改后，即使第一个item是可见的并且有item被它挡住了，我们也在展示它们，除此以外的情况我们都像之前说的那样实现我们的效果。\n\n各位观众，接下来，就是见证奇迹的时刻：\n\n![](http://img.my.csdn.net/uploads/201503/27/1427447326_5458.gif)\n\n太棒了思密达！感觉之前的失败都如雨后甘霖温润我脆弱的心灵呐～\n\n其实羞羞地说一句……这篇文章是我人生中的第一篇博文呐，如果你觉得很无聊或者我有哪里讲解错误的话千万不要喷我哦。我会在未来变得更棒哒，然后尽我所能为大家贡献更多的文章！\n\n如果你看到这里还是通过添加Header来实现这个效果很恼火的话，用第一种方法结合HidingScrolllistener 也是可以实现这个效果的～\n\n如果你有什么疑问的话，可以在评论区问我哦，我都会尽我所能为你解答的！\n\n## 源码 \n\n整个项目的源码在GitHub上面都有，大家可以在这看 [repo](https://github.com/mzgreen/HideOnScrollExample)\n\n感谢Mirek Stanek帮我校对文章，么么哒！爱你的好基友Michal Z～\n\n如果你喜欢这篇博文的话，你可以[在Twitter上分享给你的小伙伴](https://twitter.com/intent/tweet?url=http://mzgreen.github.io/2015/02/15/How-to-hideshow-Toolbar-when-list-is-scroling(part1)/&text=How%20to%20hide/show%20Toolbar%20when%20list%20is%20scroling%20(part%201)&via=mzmzgreen)或者[在Twitter上关注我哦](https://twitter.com/mzmzgreen)!\n" }, { "path": "androidweekly/ListView或者RecycleView滚动时隐藏Toolbar-part-2/readme.md", "content": "ListView或者RecycleView滚动时隐藏Toolbar( Part 2 )\n---\n\n>\n* 原文链接 : [How to hide/show Toolbar when list is scrolling (part 2)](http://mzgreen.github.io/2015/02/28/How-to-hideshow-Toolbar-when-list-is-scrolling(part2)/)\n* 译者 : [chaossss](https://github.com/chaossss) \n* 校对者: [这里校对者的github用户名](github链接) \n* 状态 : 校对中\n\n\n\n\n\nHello，各位小伙伴，俺胡汉三又来了！！！今天我打算接着上一篇博文继续给大家讲解展现/隐藏Toolbar的效果。我建议没有读过 [ListView或者RecycleView滚动时隐藏Toolbar](https://github.com/bboyfeiyu/android-tech-frontier/blob/master/androidweekly/ListView%E6%88%96%E8%80%85RecycleView%E6%BB%9A%E5%8A%A8%E6%97%B6%E9%9A%90%E8%97%8FToolbar/readme.md) 这篇文章的小伙伴先去看看那篇博文再来看这篇博文，不然会跟不上我的讲解节奏的哦。在上一篇博文里，我们学习了如何去实现Google+那个酷炫的展现/隐藏Toolbar的效果，今天，我将会给大家讲解怎么让上一篇博文的效果进化成Google Play Store Toolbar那样，废话不多说，我们现在进入正题吧：\n\n在我们开始之前，我想先告诉大家的是我已经对这个项目进行了一些重构——我继承项目的 MainActivity 实现了两个新的子类：PartOneActivity 和 PartTwoActivity。源码在包 partone 和 parttwo里，你可以在这两个包里挑选你喜欢的那一个使用\n\n下面是我们的最终效果图，我把它和 Google Play Store Toolbar 放在一起比较，大家可以感受一下：\n\n![](http://img.my.csdn.net/uploads/201503/27/1427447727_3335.gif)\n![](images/playstore.gif)\n\n## 准备工作 ##\n\n在这里我不会再给大家展示 build.gradle 文件，因为这和第一部分的 build.gradle 文件是一样的，所以我们将会从这个步骤开始——为我们的Activity创建一个layout：\n\n同样的，layout里面只有一个 RecyclerView 和一个 Toolbar （稍后再加上 Tabs）。值得注意的是，我这里的实现是使用之前说的第二种方法（为RecyclerView添加Padding）\n\n同样的道理，由于我们的布局文件、list、RecyclerAdapter 都和之前是一样的，我在这里都不会再给大家讲解了。\n\n那现在我们来看看 PartTwoAcitivty 的代码吧：\n\n在 PartTwoActivty 里面仍然是简单地对 RecyclerView 和 Toolbar 进行初始化，但大家一定要记得设置 OnScrollListener 哦（第27行）\n\n感觉大家看到这里也感觉昏昏欲睡了，因为前面提到的内容大体上都和上一篇相似。但是莫慌！俺接下来就要讲这篇博文中最有趣的部分 —— HidingScrollListener 了，请大家紧紧抱住我，跟上节奏！\n\n如果你看过第一篇博文可能会觉得此情此景很熟悉（可能还会感觉简单一些）。我们在 HidingScrollListener 里耍了什么 tricks 呢？那就是存了与 Toolbar 的高度相关联的屏幕滚动偏移量 —— mToolbarOffset。为了简化其中的逻辑，只有当 mToolbarOffset 的取值在[0 , Toolbar的高度]之间时，我们才会实现我们的逻辑：当我们向上滚动时，mToolbarOffset的值会增加（但不会超过Toolbar的高度）；当我们向下滚动时，mToolbarOffset 的值会减少（但不会低于0）。大家现在可能会有许多疑问：为什么要引用 mToolbarOffset 呀？为什么要让 mToolbarOffset 的取值范围介于那两者之间呐？别怕！你马上就会理解为什么我们要这样限制mToolbarOffset的取值了。我们必须知道的是，尽管我们极力去避免意外的发生，但现实总会出人意料，在这里也不例外，有时候 mToolbarOffset 的值就是会不可避免地在我们的取值范围之外，但由于我们的逻辑设计的限制，最终的显示效果会是闪烁一下。（例如：在屏幕上快速的挥动、滑动）这样的结果显然不是我们这些有格调的 Android 工程师想要的，因而我们需要对 mToolbarOffset 进行一定程度的裁剪，以规避这样的风险。基于这样的考虑，我们重载了 onMoved()方法 —— onMoved() 方法是一个当我们滚动视图时被调用的抽象方法。可能会吓到你，但是莫慌，继续抱住我！\n\n接下来，我们就要回到我们 PartTwoActivity 设计之中，并且在我们的滚动监听器中实现 onMoved()方法。\n\n是的，这就是所有内容啦。我们运行 App 后可以看到我们的最终效果：\n\n![](http://img.my.csdn.net/uploads/201503/27/1427447725_3945.gif)\n\n是不是感觉自己棒棒哒～就像我们想象的那样，Toolbar 完美的随着list的滚动实现了展现/隐藏的效果。其中的功劳都得归功于我们对 mToolbarOffset 取值范围的限制。如果我们省略掉检查 mToolbarOffset 是否在[0 , Toolbar的高度]范围中取值的过程，带着完成控件的喜悦向上滚动我们的list，Toolbar 确实会如你所期望的那样离开屏幕，但与此同时，Toolbar 还会远远地，远远地，离开视图，再也不回来。然后当你满是期许地向下滚动时，你就会发现刚刚那一声再见，竟是永远。如果你想再次遇见它，你就必须想下滚动，直到 mToolbarOffset = 0。\n\n再脑补第二种情况吧，现在你正好把 Toolbar 滚动到 mToolbarHeight = mToolbarOffset 的位置，不偏不倚。那么现在Toolbar就刚好“坐”在了list顶部，如果你向上滚动的话，无论你怎么滚，它都不会动，只会静静地坐在那儿笑看人世沧桑。而如果你向下滚动，它又成为许多年前那个明亮、可爱的小女孩了。\n\n虽然最终的实现效果看起来非常赞，但这并不是我想要的。因为我们能在滚动过程中停止整个效果，使得 Toolbar 有一部分是可见的，另一部分又是不可见的。但悲伤的是，Google Play Games 就是这么干的，而我一直认为这是一个Bug……\n\n## 在某一点停下 Toolbar ##\n\n就我的认知来说，我认为滚动的Views是能够如丝般顺滑地对齐相应的位置的，就像 Chrome 应用里的 Logo/SearchBar 又或者是 Google Play Store应用里那样。我很确定我在 Material Design 的guidelines/checklist 或者是 以前听过的Google I/O 大会上听过类似的规范。\n\n那我们现在再来看看 HidingScrollListener 的代码吧：\n\n虽然为了实现上面提到的效果我们会让 HidingScrollListener 的代码变得更复杂一些，但是我再说一次，莫慌，抱紧我！我们现在只需要重载 RecyclerView.onScrollListener 类的 onScrollStateChanged()方法，然后按照下面那样干就行了：\n\n首先，我们需要检查list是否处于 RecyclerView.SCROLL_STATE_IDLE 状态，以确保list没有在滚动或者挥动（因为如果list如果正在滚动或者挥动的时候，我们就需要像第一篇博文那样去考虑 Toolbar 的Y方向位置哦）\n\n如果我们抬起了手指，而且list已经停止移动了（）我们就要去检查Toolbar是不是可见的，如果是可见的，我们就需要考虑 mToolbarOffset 的值了。如果此时 mToolbarOffset 的值大于 HIDE_THRESHOLD 我们就必须把 Toolbar 隐藏起来；mToolbarOffset 的值小于 HIDE_THRESHOLD，我们则需要让 Toolbar 显示出来。\n\n如果 Toolbar 不是可见的，我们就需要做相反的事情 —— 如果 此时mToolbarOffset（此时计算 mToolbarOffset要从顶部位置来考虑了，也就是 mToolbarHeight - mToolbarOffset） 大于 SHOW_THRESHOLD 我们就让 Toolbar显示；相反，如果 mToolbarOfffset 小于 SHOW_THRESHOLD ，我们就要再次将 Toolbar隐藏起来。\n\nonScrolled()方法和第一篇博文的一样，我们并不需要作什么改变。我们现在最后需要做的就是在 PartTwoActivity 类里实现我们的两个抽象方法：\n\n那么，你准备好看魔术了吗？\n\n![](http://img.my.csdn.net/uploads/201503/27/1427448161_2643.gif)\n\nhey，派大星你看，是不是很酷！\n\n现在你可能在脑补添加 Tabs 会有多麻烦了，可是兄弟啊，生活很多时候都是出人意料的呐，不信你继续往下看呀\n\n## 添加 Tabs ##\n\n为了添加 Tabs，首先要做的当然是为我们的 Activity 布局添加一个 tabs.xml啦\n\n你可以从源码那发现，我并没有添加真正的 Tabs，只是在布局里面模拟了 Tabs。而以上的一切不会改变任何之前的实现，你能在里面放任何你想要放的View。下面是一些 GitHub 上符合 Material Design规范的 Tabs 实现，当然你也可以自己实现啦。\n\n添加 Tabs 意味这他们会稍微覆盖我们的list，所以我们需要增加Padding。为了减少代码的操作复杂度，我们不会在 xml 里进行这个操作（注意把 RecyclerView 在 part_tuo_activity里的padding删掉哦），因为 Toolbar 可能会在不同的设备中切换方向时拥有不同的高度（例如在平板中），这样的话我们需要创建一大堆的 xml 去解决这些乱七八糟的烦人问题。所以我决定在代码中解决这个问题：这是非常简单的，我们只需要和 Tabs高度的总和。如果我们把 Padding设置为 Toolbar 的高度现在运行起来的话，就会发现这样的东西：\n\n![](http://img.my.csdn.net/uploads/201503/27/1427448162_3352.png)\n\n看起来很正常的样子……我们第一个item刚刚好是可见的，我们也能移动跟随着它。实际上我们在 HidingScrollListener 类里什么也没干，唯一需要的改变都是在 PartTwoActivity 里做的：\n\n你能发现什么发生了改变吗？我们现在不妨创建一个 mToolbarContainer 的引用，但是大家要注意哦， mToolbarContainer 是 LinearLayout 对象而不是 Toolbar对象，而且在 onMove()，onHide()，和 onShow()方法中，我们都把 Toolbar 改成了 mToolbarContainer。这会使得包含了 Toolbar 和 Tabs 的Container被移动，这恰恰就是我们想要做的。\n\n如果我们把修改后的代码运行起来会发现，实际的运行效果正好就是我们所期望的，但如果你看的认真一些你会发现，里面其实有一个小Bug。在 Tabs 和 Toolbar 之间有时候会有一条白线，虽然时间非常短，但还是很惹人讨厌呐。我个人觉得这大概是因为当Toolbar 和 Tabs被显示的时候，他们并没有像我们期望的那样同步在一起。不过万幸这不是什么无法解决的Bug～\n \n解决办法非常简单，就是让 Toolbar 和 Tabs 的背景和父布局保持一致：\n\n现在即使 mToolbarContainer 在显示过程中没有很好的同步在一起，白线也不会出现了。正当我打算吃根辣条庆祝我们伟大战役的胜利的时候，又出现了一个Bug………………这个Bug和我们在第一篇博文里遇到的Bug是一样的，如果我们在list的顶部，我们可以向上滚动一丢丢，如果此时 HIDE_THRESHOLD 足够小，Toolbar 就会藏起来，导致那里有一块空白区域（其实就是我们设置的Padding）在list的顶部，但是我相信你到了现在应该不会慌了，因为你已经知道所有Bug在我眼里都是非常容易解决的：\n\n我们只需要再增加一个变量用于存储list的总滚动偏移量，当我们准备去检查我们是否应该展现/隐藏 Toolbar的时候，我们首先应该检查我们的滚动距离是否比 Toolbar 的高度要大（如果不是的话，我们再让 Toolbar 出现）\n\n这就是今天博文要讲的一切了，让我们来看一看实际效果！\n\n![](http://img.my.csdn.net/uploads/201503/27/1427447727_3335.gif)\n\n现在运行的效果简直完美啊大兄弟～即使用其他的 LayoutManagers 也不需要改变任何东西的哦：\n\n![](http://img.my.csdn.net/uploads/201503/27/1427448162_7185.png)\n\n评论区有好学的同学问了个有关存储滚动状态的问题，这确实是个小麻烦。如果我们list的item中的文字在垂直方向达到2行，在水平方向达到1行的话，我们的item高度就会变得很奇怪了……举个例子吧，如果我们滚动到垂直方向100的位置，然后旋转我们的设备，同时存储 mTotalScrolledDistance的值，在旋转之后，我们会滚动到list的顶部，然后我们会发现 mTotalscrolleddistance 的值不等于0。这个时候即使全能如我也想不到简单的办法来解决这个问题了，但是在我们的使用场景中，这样的小问题并不会有什么影响。如果你真的想要解决这个问题的话，我个人的做法是：在旋转之后把 mTotalScrolledDistance 的值重设为0 并且显示 Toolbar。\n\n感觉今天写了好多内容啊，大家看到这里应该感觉很累了吧？不过今天这篇博文就是这个系列的最后一篇文章啦，大家能在第一篇博文中学习到知识我真的很高兴呢。大家鼓励和夸奖的话也让我很感动，我会继续写我的博客，为大家传授更多的知识，不过我也不知道下一篇博文会在什么时候写 2333。\n\n除此以外我还想说的是，在这两篇博文中我提到的方法可能看起来运行的很好，但其实我并没有进行非常严谨的测试，所以我也不确定它们能不能被用于企业级应用中（你看我们不就遇到了好几个Bug了嘛）。这个系列的博文的初衷只是想告诉你，即使只使用标准API里面的一两个简单方法，也能够实现酷炫的效果。同时，我在写博文的过程中也发现了这些方法还有其他有趣的用法（例如：利用视差背景制作有粘性的 Tabs，就像在 Google+ 个人页面那样）。不管怎样，祝大家在写代码的过程中找到更多的快乐！\n\n## 源码 ##\n\n整个项目的源码都已经被上传到 [GitHub](https://github.com/mzgreen/HideOnScrollExample) ，大家可以去下载和使用哦，爱你们的 Michal Z。\n\n如果你喜欢这篇博文的话，你可以 [在Twitter上分享给你的小伙伴](https://twitter.com/intent/tweet?url=http://mzgreen.github.io/2015/02/28/How-to-hideshow-Toolbar-when-list-is-scrolling(part2)/&text=How%20to%20hide/show%20Toolbar%20when%20list%20is%20scrolling%20(part%202)&via=mzmzgreen) 或者 [在Twitter上关注我哦](https://twitter.com/mzmzgreen) 。" }, { "path": "androidweekly/Square 开源库Flow和Mortar的介绍/readme.md", "content": "Flow和Mortar的调查\n---\n>\n* 原文链接 : [Architecting An Investigation into Flow and Mortar](http://www.bignerdranch.com/blog/an-investigation-into-flow-and-mortar/)\n* 译者 : [sundroid](https://github.com/sundroid)( [chaossss](https://github.com/chaossss) 协同翻译)\n* 校对者: [chaossss](https://github.com/chaossss)、[Mr.Simple](https://github.com/bboyfeiyu) \n* 状态 : 完成\n\n“在 App 开发过程中尽可能使用 Fragment 替代 Activity”，Google 官方的这个建议无疑让万千 Android 开发者开始关注、使用 Fragment。但随着使用 Fragment 的人数增多，Fragment 存在的各种问题也开始暴露，在各种 Android 社区中，已经开始有人质疑用 Fragment 替代 Activity 在应用开发中是否真的像 Google 说的那样有益。质疑 Fragment 的理由大体如下：\n\n- 在使用 Fragment 时，我们只能选择使用默认的构造方法，而不能自由地构造我们想要的构造方法。\n\n- 嵌套使用 Fragment 很容易出现各种奇奇怪怪的 Bug，抑或是受到种种让人郁闷的限制。\n\n- Fragment 自身的生命周期非常复杂。\n\n更让人哭笑不得的是，让这部分开发者坚定地站在“反 Fragment”队伍中的原因竟然是：在开发过程中使用 Fragment 完全不能让这部分 Android 开发者感受到使用 Fragment 能给他们带来的便利和愉悦；相反，使用 Fragment 给他们带来的是无尽的困然和烦恼。真不知道 Google 看到这些批评 Fragment 的帖子会想什么…………\n\n但在我们的 Android 学习社区 [Big Nerd Ranch](http://www.bignerdranch.com/) 中，我们制作的 [Android bootcamp](https://training.bignerdranch.com/classes/android-bootcamp) 课程一直坚持使用 Fragment ，并且为大家介绍 Fragment 给我们带来的种种便利和好处（特别是 Android 开发的新手），此外，我们还在我们做的 [资讯项目](http://www.bignerdranch.com/we-develop) 中广泛地使用了 Fragment。\n\n然而，虽然我们是 Fragment 的忠实粉丝，但本着不断学习和探索新知识的心态，我们还是对现有的 Android 库进行了相当多的研究和探索，以求能够找到 Fragment 的最佳替代物，帮助这些备受煎熬的 Android 开发者早日脱离苦海，走向 Android 开发的美丽新世界。\n\n## 进入Flow和Mortar \n奉行着想毁灭世界上所有 Fragment 的信条，Square 大概在一年前介绍了两个全新的库： Flow 和 Mortar。作为反 Fragment 教主，Square 还创造了许多很好的库：\n\n*\t[Dagger](http://square.github.io/dagger/)\n*\t[Retrofit](http://square.github.io/retrofit/)\n*\t[Picasso](http://square.github.io/picasso/)\n*\t[Otto](http://square.github.io/otto/)\n*\tAnd so many [more](https://github.com/square)\n\n我只想说，我相信他们，我认为任何来自Square的资源可能是有用的或者至少是有趣的，所以他们的项目都值得一看。\n\n在我们深入了解这些库之前我想提醒大家的是，Square只在他们内部的一小部分项目中使用这些库，并且我在写本文章时这些库还在预发布阶段。也就是说，这两个库在最近几个月取得了积极的进展，这预示着一个值得尊敬的未来，虽然库就像流沙，随时可能改变，崩溃甚至停止发布，但库所依赖的核心架构原则是一成不变的。\n\n##体系架构\n 首先，我们先来看下 Android 应用的体系架构，在 Android Honeycomb 被使用之前，甚至在Fragment 出现之前，开发 Android 应用的标准模式是创建许多 Activity。在那个时候最常见的现象是：大多数开发者都没有规范地遵循 MVC模式进行开发，不过这也很正常。因为模型(Model)依赖于数据，传统的一些数据库或者是以 JSON 的形式存储的 Web 请求，抑或是各种各样的java对象枚举。开发者们很高兴地通过 XML 布局去为 Activity 设置 View ，而且 View 的控制器就是每一个屏幕显示的 Actvitiy 自身。\n\n虽然这只是一个简要的概述，但是你能从中了解到 Android 与 MVC 模式是如何自然契合的。\n![mvc-pre](http://www.bignerdranch.com/img/blog/2015/02/mvc-pre.png)\n\n随着 Fragment 在 Honeycomb 中的出现，Android 团队也让处理不同形式的事件变得更简单。到了今天，标准的 Android 应用架构已经转变为由一小部分的 Activity 和 许多 Fragment 构成，使得我们的 App 能够在 手机、平板、智能手表甚至是太空船上跨平台使用。\n![mvc-post](http://www.bignerdranch.com/img/blog/2015/02/mvc-post.png)\n\n在这样的愿景下，有关 Fragment 的一切都是美好的，Fragment 变得流行起来，将一个 Activity 分解为几个 Fragment 是被提倡的。除此以外，即使 Activity 常常被简化为 Fragment 的持有者，或者是 Fragment 和 系统之间的接口，Android 应用的架构仍然遵循着 MVC 模式。\n\n但到底是 Activity 不能实现我们 App 跨平台使用的愿望，还是我们没有用正确的方式使用 Activity呢？也许，如果将 Activity 与 自定义 View结合在一起使用，说不定不需要 Fragment 就能让 Activity 实现跨平台使用的目标呢。使用 Flow 和 Mortar库背后的关键目的就是探索这个问题，并得到确切的答案。Flow 和 Mortar 的工作通过用自定义 View 代替 Fragment，并使用注入自定义 View 中的特定 Controller 对象，控制视图，以此允许我们通过 View 来代替 Fragment 完成工作。\n![mvc-no-fragments](http://www.bignerdranch.com/img/blog/2015/02/mvc-no-fragments.png)\n\n我们将在我们的讨论中构建这个图的中间部分，弄清楚如何在不使用 Fragment 的情况下把不同的视图碎片拼凑到一个 Activity 里。我们会看着标准MVC架构演变成完全不同的东西，这将大量涉及到咱们的Flow和Mortar。\n\n那么，Flow和Mortar到底是什么？它们又是如何起作用的呢？\n\n##Flow\nFlow 将一个应用分成一个逻辑上的 Screen组合，Screen不是任何形式的特殊的库对象，而是一个被创造来代表我们应用视图的普通java对象（POJO）。每一个Screen是这个app里面自包含的段，他们有自己的功能和意图。一个Screen的用处和传统Activity的用处没有什么不同，应用程序中的每一个Screen都对应于一个特定的位置，有点像一个Android中的URL网页或者是特定的隐式Intent。所以，Screen类可以被看作是应用中某个部分自带的可读定义。\n\n我们应用中的每一个Activity将会成为一个 Flow 对象，Flow对象在返回栈中保存了 Screen 的记录，和 Activity 或者 FragmentManager 的返回栈有些类似，通过这样的设计允许我们在 Screen 之间通过简单地实例化就可以轻松的切换，而不需要在应用中包含很多Activity。这里有一小部分 Activity（最好是一个）来持有这些 Screen。他们之间的关系下图类似：\n![screen](http://www.bignerdranch.com/img/blog/2015/02/screen.png)\n\n如果我们想切换到一个新的 Screen，我们只需简单地实例化这个 Screen，并且告诉我们 Flow 对象帮助我们切换为这个 Screen。除此以外，正如我们所期待的，Flow 被实例化后也会实现 goBack() 和 goUp() 方法。然而，许多开发者都把 Java 中的 goto 语句看作洪水猛兽，但事实上 Java 中的 goto 语句并没有它听起来那么恐怖。\n![flow](http://www.bignerdranch.com/img/blog/2015/02/flow.png)\n\n从本质上看，Flow 的作用仅仅是在 App 中告诉我们将要切换到哪一个 Screen。而这样设计的好处在于，Flow 通过这样的设计让我们能够方便地在我们定义的各种不同的自定义 View 中切换，并使我们免受在 Activity 或 Fragment 需要考虑的种种麻烦，让我们把注意力都集中在处理 View上。Flow 为我们创造了一个简单，方便，以 View 为中心的应用架构。\n\n##Mortar\nMortar是一个专注拖拽和依赖注入的库，Mortar 用以下几个不同的部分将一个应用分为可组合的模块：Blueprints, Presenters and a boatload of custom Views。\n\nMortar App里的每一个部分（在这里指的是每一个 Screen，因为我们在使用 Flow）都由 Blueprint 定义，并赋予他们一个私有的 Dagger 模块。它看起来有点像是下面这样的\n\n![blueprint](http://www.bignerdranch.com/img/blog/2015/02/blueprint.png)\n\nFlow 和 Mortar 结合在一起使用的效果很好，我们只需要调节我们的 Screen 类实现去 Mortar 提供的 Blueprint 接口，然后它就会给我们一个可以自由使用的 Dagger 作用域。\n\n![presenters](http://www.bignerdranch.com/img/blog/2015/02/presenters.png)\n\nPresenter 是一个拥有简单生命周期和伴随其生命周期的 Bundle 的 View 私有对象，主要被用作该 View 的控制器。每一个 View 都有存在于对应的 Screen （还有 Blueprint）中，与 View 自身相关联的 Presenter。因为 Presenter 只能作用于他所在的 Screen，所以当我们使用 Flow 进入一个新的 Screen，Presenter（在我们这个架构中非常重要的一环） 很可能会被 Java 的垃圾回收机制自动回收掉。此外，在 Mortar 作用域中的 Dagger 将与自动垃圾回收机制结合在一起，使得我们 App 能更好的管理、使用其内存——其中原因当然是：当前没有被使用的控制器对象都被我们回收掉了。而在传统的 Activity 开发中，Fragment 和 Activity 的切换过程中，不经意的垃圾回收并不能很好的被注意和提防。\n\n由于自定义 View 在我们的架构中被频繁地使用，以至于我们只需要通过 Dagger 简单地注入所有重要的模型数据，然后使用与 View 关联的 Presenter 去控制 View 本身。即使配置被改变，Presenters 也不会消失，而且我们还非常了解与 Activity 生命周期相关的知识，使得 Presenters 在进程被杀死之后还能被恢复。事实上，Presenter 与 Activity onSavedInstanceState() 方法的 bundle 钩连在一起，使得它能够用与 Activity 相同的机制储存和读取配置改变后产生的数据。而 Presenter 的生命周期非常简单，只有四个回调方法：\n\n- onEnterScope(MortarScope scope)\n- onLoad(Bundle savedInstanceState)\n- onSave(Bundle outState)\n- onExitScope()\n\n完全没有 Fragment 那样复杂的生命周期，这可不是我吹的！\n\n文章写到这里，你会发现在 Flow 和 Mortar 中有许多发生改变的部分，新的术语和类，还有新的使用规范，这难免会让人一头雾水。所以为了方便大家的理解，总的来说，我们需要重视的是下面几个部分：\n\n- Screen: 在应用导航层次结构中的一个特殊存在，用来代表我们视图的对象\n- Blueprint: 应用中具有私有的 Dagger 模块的部分\n- Presenter: 一个 View 控制器对象\n- Custom Views: 通过 Java 代码定义的 View，当然，用 XML 定义也是很常见的\n\nHere’s what our final Mortar and Flow architecture looks like:\n\n我们 Mortar 和 Flow 整个体系架构将会如下所示：\n\n![](https://www.bignerdranch.com/img/blog/2015/02/mortar-and-flow.png)\n\n抛弃了对 MVC 模式的执念，这个架构在完成之后变得更像 MVP 模式。这样巨大的转变使得新的架构需要关注如何处理应用在运行时配置信息改变的问题，例如：旋转。在 MVC 模式中，我们的控制器（Activity 和 Fragment）会随着我们的 View 一起被杀死。然而，在 MVP 模式中，我们只有 View \n被杀死，又在需要它的时候重现它。挺有趣的对吧？\n\n![](https://www.bignerdranch.com/img/blog/2015/02/mvp.png)\n\n## 积极的反馈 \n\n为了摆脱 Fragment，Square 付出了无数的汗水去进行重新架构和设计，并完成了 Mortar 和 Flow库，他们当然会获得相应的回报，接下来我就给大家介绍这两个库给我们带来的好处吧。\n\n使用 Mortar 和 Flow 库强迫我们创建了一个符合 MVP 模式设计的模块化 App 结构，通过这样做能有效地帮助我们保持代码的整洁。\n\n通过对我们自定义 View 和 Presenters 的依赖注入，测试变得更简单了\n\n动画能够在 View 层被处理，而不用像从前在 Activity 和 Fragment 中使用时那样担心动画会出现Bug\n\nMortar 在 View 和 Presenter 层中自动进行垃圾回收以处理其作用域，意味着应用能更有效地利用内存\n\n## 可优化的空间 \n尽管 Flow 和 Mortar 给我们带来了许多好处，但是它们也还存在一些问题：\n\n**想要熟练使用 Flow 和 Mortar，需要面对一条陡峭的学习曲线。**在你真正理解这两个库的设计思想和原理之前，它们的使用模式看起来非常复杂，如果你想要将他们用的得心应手，无疑需要大量的探索和实验，此外，这些库并不是为初学者提供的，我们更建议初学者先学习如何正确和有效地使用 Activity 和 Fragment，我可不是吓唬你们，这样跟你们说吧，就算是 Android 开发大神，在面对这些库时仍需要花费大量的精力和时间去学习有关设计模式的知识，才能真正理解这个库。\n\n**如果你正准备使用 Mortar 和 Flow 库，你真的要全面了解它们的用法。**因为让它和标准的“少使用 Fragment”开发模式相互作用是很困难的。如果你想修改一个已经写好的项目，让它使用 Mortar 和 Flow，虽然不是不可能的，但是完成这个目标的过程会是非常漫长和艰难的。\n\n**这里还存在无数的模板和配置信息需要被处理。**而这正是我最大的担忧，在使用这些新的类和接口时，我常常觉得被淹没在无趣的代码海洋里，因为这些代码都被设计成和其中的各个类、接口钩连在一起，而这也的设计让我觉得这两个库并没有像我期待的那样有趣。\n\n## 接下来呢 \n不过现在 Mortar 和 Flow 库都处于预发布阶段，现在也没有官方发布的版本。这意味着 Square 还在处理这两个库存在的问题，改动和更新，但这同样也意味着它们还需要许多时间作改进，才能真正投入到使用中。\n\n使用 Mortar 和 Flow 库是个有趣的体验，我非常享受使用各种新的库和寻找官方以 Fragment 为导向的应用结构的替代品，但我并不认为 Mortar 和 Flow 是 Android 寻找的替代 Fragment 的办法，毕竟 Fragment 可能在接下来的几个月或者几年中被修改。但我仍然希望这些项目能够引起更多人关注，并且继续优化，我肯定会继续关注他们的最新进展的，希望大家继续关注我的博客哦。\n" }, { "path": "androidweekly/kotlin-for-android简介/readme.md", "content": "kotlin-for-android简介(1)\n---\n\n>\n* 原文链接 : [Kotlin for Android (I): Introduction\n](http://antonioleiva.com/kotlin-for-android-introduction/)\n* 译者 : [canglangwenyue](https://github.com/canglangwenyue) \n* 校对者: [Mr.Simple](https://github.com/bboyfeiyu) \n* 状态 : 完成\n\nKotlin是众多基于JVM的语言之一，它一开始是作为android 开发中java语言的可能的代替者出现的。java是世界上使用最多的语言之一，而伴随着其他语言的发展使得程序员编程越来越容易，但是java并没有尽快地向预期目标发展。\n\n###Kotlin简介\nKotlin是JetBrains创造的基于JVM的语言，JetBrains是IntelliJ的缔造团队。\t\nKotlin是一个拥有很多函数编程特点的面向对象的编程语言。\n\n###为什么要用Kotlin\n我首先声明我并没有使用Kotlin很长时间，我几乎是在学习的同时写了这些文章的。我并没有尝试任何其它的替\t代语言，例如Go和Scala，所以如果你是真的考虑换一种开发语言的话，我建议你去搜索一下其他人对这些\t语言的评价。一个使用Scala开发android的例子可以在[47deg Github site](http:/\t\n47deg.github.io/translate-bubble-android/)找到。\n\n\n以下是我选择学习Kotlin的原因： \n* **学习曲线相对较快**：以Scala作为例子进行比较，我们是向着更简单的方向前进。Kotlin有更多的限制，但是如果你没有学习过一门现代编程语言的话，Kotlin更容易学习。\n* **轻量级**：与其他语言相比Kotlin的核心库更小。这很重要，因为android函数数量限制(函数数量不能大于64k)是一个问题，虽\n然有一些选择来解决这个问题，例如proguard 或 multidexing，但是这些解决方案会加复杂度，并导\n致调试时花费更多的时间。引入Kotlin核心库添加了不到7000个方法，大致和support－v4一样。\n* **高交互性**：Kotlin和其它java库协调使用的特别好，并且交互操作很简单。这是Kotlin团队\n在开发新语言是的主要理念之一。他们想在使用Kotlin开发时并不用重写之前所有用java写的代码，所以，Kotlin和java交互的能力必须非常高。\n* **与AS和Gradle完美结合**：我们有一个IDE的插件和另一个属于Grade的插件，因此，用Kotlin进行\n\tandroid编程并不困难。\n\n在开始任何争论之前我建议你看一下Jake Wharton写的一个有趣的文档[the use of Kotlin for Android development](https://docs.google.com/document/d/1ReS3ep-hjxWA8kZi0YqDbEhCqTt29hG8P44aA9W0DM8/edit?hl=es&forcehl=1&pli=1)。\n\n###Kotlin的优点\n\n####1. 可读性更高，更简洁\n使用Kotlin，可以更容易的避免创建模版型代码，因为大多数经典的情景都默认包含在Kotlin中。 \n例如，在java中，我们想要创建一个典型的data class时需要这样做： \n\n```java\t\n\tpublic class Artist {\n private long id;\n private String name;\n private String url;\n private String mbid;\n \n public long getId() {\n return id;\n }\n \n public void setId(long id) {\n this.id = id;\n }\n \n public String getName() {\n return name;\n }\n \n public void setName(String name) {\n this.name = name;\n }\n \n public String getUrl() {\n return url;\n }\n \n public void setUrl(String url) {\n this.url = url;\n }\n \n public String getMbid() {\n return mbid;\n }\n \n public void setMbid(String mbid) {\n this.mbid = mbid;\n }\n \n @Override public String toString() {\n return \"Artist{\" +\n \"id=\" + id +\n \", name='\" + name + '\\'' +\n \", url='\" + url + '\\'' +\n \", mbid='\" + mbid + '\\'' +\n '}';\n }\n}\n```\n\n那么在Kotlin需要多少代码呢？仅仅是下面这个简单的数据类： \n\n```java\n\n\tdata class Artist(\n var id: Long, \n var name: String, \n var url: String, \n var mbid: String)\n```\n\n####2. 空指针安全\n当我们用java开发时，我们的大多数代码是要进行类型检查的，如果我们不想出现**unexpected\nNullPointerException**的话,我们就要在运行代码之前持续的检查是否有对象为null。Kotlin，和其它语\n言一样，是空指针安全的，因为我们可以通过安全的调用操作来准确的声明一个object可以为null。\n\n我们可以这样做：\n\n```java\n\t\n\t//This won´t compile. Artist can´t be null\n\tvar notNullArtist: Artist = null\n \n\t//Artist can be null\n\tvar artist: Artist? = null\n \n\t// Won´t compile, artist could be null and we need to deal with that\n\tartist.print()\n \n\t// Will print only if artist != null\n\tartist?.print()\n \n\t// Smart cast. We don´t need to use safe call operator if we previously checked \tnullity\n\tif (artist != null) {\n\t artist.print()\n\t}\n\t \n\t// Only use it when we are sure it´s not null. Will throw an exception otherwise.\n\tartist!!.print()\n \n\t// Use Elvis operator to give an alternative in case the object is null\n\tval name = artist?.name ?: \"empty\"\n```\n\n####3. 扩展方法\n我们可以给任何类添加新方法。这比我们在project中使用的工具类可读性更高。例如：我们可以给Fragment添加一个新方法来显示Toast。\n\n```java\nfun Fragment.toast(message: CharSequence, duration: Int = Toast.LENGTH_SHORT) {\n Toast.makeText(getActivity(), message, duration).show()\n}\n```\n我们可以这样使用：\n\n```java\n\tfragment.toast(\"Hello world!\")\n```\n\n####4. 支持函数式编程\n如果我们可以不用在我们需要的时候每一次都创建一个listener，就像创建一个click listener那样的操作，\n而是仅仅定义我们想要做什么？这种想法的确可以实现，它的实现得益于**lambda**d的使用： \n\n```java\n\tview.setOnClickListener({ toast(\"Hello world!\") })\n```\t\n\t\n###Kotlin目前存在的限制\nKotlin 依旧在发展，虽然它相对稳定，并且final release版本就很快发布，但是Kotlin在进行android相关开发的时候还是有些限制的。 \n\n* **交互性与自动代码生成**：一些有名的android Libraries，例如Dagger 或 Butterknife，他们依赖于自动\n代码生成，这种情况下如果有名字冲突的话将无法进行代码生成。Kotlin正在解决这个问题，所以这个问题也许\n会很快解决。无论如何，我将在接下来的文章里阐明，Kotlin语言的表达能力会让我们觉得不再需要那么多的\nLibraries。\n\n* **声明自定义View比较困难**：Kotlin类只能声明一个构造函数，然而自定义View通常需要三个。如果我\n们使用代码来创建View的话可以避免这个问题，但对于使用XML文件来声明View的话就不能满足需求了。最容易的变通方式是用java来声明这些\n自定义View的实现类，然后通过Kotlin来使用它们。Kotlin团队许诺将在M11 release解决这个问题。\n**Update: Kotlin M11 is out and now includes [secondary constructors](http://kotlinlang.org/docs/reference/classes.html#constructors)**\n\n* **android 下Junit测试**：AS 1.1中介绍的新特性并不适用与Kotlin。顺便说说，系统测试和Junit 测试对于纯Kotlin项目是完全可用。\n\n###结论\n对于android apps 开发，Kotlin是一个非常有趣的java替代者。下一篇文章将会描述如何用Kotlin新建一\n个project，和如何更好的适用Kotlin来使得android开发更加简单。敬请关注！\n\n" }, { "path": "androidweekly/readme.md", "content": "# 不要将文章放到这个文件夹下啦!请放到最新的issue文件夹中,谢谢大家。\n" }, { "path": "androidweekly/一个支持多设备的Android参考应用/readme.md", "content": "一个支持多设备的Android参考应用\n---\n>\n* 原文链接 : [a-new-reference-app-for-multi-device](http://android-developers.blogspot.com/2015/03/a-new-reference-app-for-multi-device.html)\n* 译者 : [Mr.Simple & Sophie.Ping](https://www.github.com/bboyfeiyu)\n\n现在你可以把你的app的好用之处分享给你的用户，不管他们身处何地，手上拿着何种设备。今儿我们会发布一个参考示例，展示一下如何把这种服务运用到一个在多个Android form-Factor运作的app上。这个示例叫做Universal Music Player，它是一个准系统但是参考功能齐全，在单个代码库里支持多种设备和形式因素。它能与Android Auto、Android Wear和Google Cast设备兼容。你可以试试把你的app适配到你的用户，无论他在哪里，无论他手上拿的是手机，手表，电视，汽车还是其他的设备。\n![android](http://img.blog.csdn.net/20150322112056022) \n\n锁屏时的播放控制和专辑封面\n应用toolbar上的Google Cast 图标\n\n![auto](http://img.blog.csdn.net/20150322111453169) \n使用Android Auto控制播放\n\n![watch](http://img.blog.csdn.net/20150322111518047) \n通过Android Wear Watch控制播放\n\n\n本示例运用了Android 5.0 Lollipop的几个新功能，比如MediaStyle通知，MediaSession和MediaBrowserService.这几个新功能使得在多个设备上使用单一app版本操作媒体浏览和回放变得更容易。\n一起来看看源代码吧，让你的用户以他们的方式爱上你的app。\n作者：Renato Mangini，高级开发工程师，Google开发者平台团队成员" }, { "path": "androidweekly/一种在android中实现MVP模式的新思路/readme.md", "content": "一种在android中实现MVP模式的新思路\n---\n\n>\n* 原文链接 : [android-mvp-an-alternate-approach](http://blog.cainwong.com/android-mvp-an-alternate-approach/)\n* 译者 : [FTExplore](https://github.com/FTExplore)\n* 校对 : [sundroid](https://github.com/sundroid)\n\n今天我想分享我自己在Android上实现MVP模式的方法。如果你对MVP模式还不熟悉或者你不清楚为什么要在Android应用中使用MVP模式，我建议你先阅读以下[这篇维基百科的文章](http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93presenter)和[这篇博客](http://antonioleiva.com/mvp-android/)。\n\n## 使用Activity和Fragment作为视图层(View)真的合适么?\n\n目前很多使用了MVP模式的android 项目,基本上都是将activity和fragment作为视图层来进行处理的.而presenters通常是通过继承自被视图层实例化或者注入的对象来得到的. 诚然,我同意说,这种方式可以节省掉很多让人厌烦的\"import android.*.*\"语句, 并且将presenters从activity的生命周期中分割出来以后, 项目后续的维护会变得简便很多.这种思路是正确的， 但是,从另一个角度来说, activity 有一个很复杂的生命周期(fragment的生命周期可能会更复杂), 而这些生命周期很有可能对你项目的业务逻辑有非常重大的影响. Activity 可以获取上下文环境和多种android系统服务. Activity中发送Intent，启动Service和执行FragmentTransisitons等。而这些特性在我看来绝不应该是视图层应该涉及的领域(视图的功能就是现实数据和从用户那里获取输入数据，在理想的情况下，视图应该避免业务逻辑). \n\n基于上述的原因，我对目前的主流做法并不赞同，所以我在尝试使用Activity和Fragment作为Presenters。\n\n## 使用Activity和Fragment作为presenters的步骤\n### 1. 去除所有的view \n\n将Activity和Fragment作为presenter最大的困难就是如何将关于UI的逻辑抽取出来.我的解决方案是: 让需要作为presenter的activity 或者 fragment来继承一个抽象的类(或者叫\"基类\"), 这样关于View 各种组件的初始化以及逻辑,都可以在继承了抽象类的方法中进行操作，而当继承了该抽象类的class需要对某些组件进行操作的时候，只需要调用继承自抽象类的方法，就可以了。 \n\n那么抽象类怎么获取到的view组件呢？在抽象类里面会有一个实例化的接口，这个接口里面的init()方法就会对view进行实例化，这个接口如下：\n\n```java\npublic interface Vu {\n\n\tvoid init(LayoutInflater inflater, ViewGroup container);\n\tView getView();\n}\n```\n\n\n正如你所见，Vu定义了一个通用的初始化例程，我可以通过它来实现一个容器视图，它也有一个方法来获得一个View的实例，每一个presenter将会和它自己的Vu关联，这个presenter将会继承这个接口（直接或者间接的去继承一个来自Vu的接口）\n\n### 2. 创建一个presenter基类 (Activity) \n\n有了Vu接口，我们可以通过构建一系列的class来操纵很多不同的view组件，这些class 使用Vu接口来初始化View组件，并通过继承的方式给子类以操纵view组件的方法，以此来达到将ui 逻辑剥离出activity的目的。在下面的代码中，你可以看到，我覆写了activity的onCreate 、 onCreateView、onDestroy 、 onDestroyView，通过对这些方法的覆写，就可以对Vu的实例化和销毁进行精确的控制（vu.init()就是实例化一个view组件）。onBindVu() 和onDestoryVu()是控制view生命周期的两个方法。通过对actiivty中相关方法的覆写达到控制组件的生命周期的目的（具体看下面的代码，你就明白了）， 这样做的好处就是无论是activity 还是 fragment， 其用与控制view组件创建和销毁的语句是一样的（尽量避免定义多余的函数）。这样的话，二者之间的切换也会减少一定的阻力（也许你今天的需求是用fragment实现的，但是第二天发现使用fragment会有一个惊天bug，译者本人就遇到过）。 \n\n```java\npublic abstract class BasePresenterActivity extends Activity {\n\n protected V vu;\n\n @Override\n protected final void onCreate(Bundle savedInstanceState) {\n super.onCreate(savedInstanceState);\n try {\n vu = getVuClass().newInstance();\n vu.init(getLayoutInflater(), null);\n setContentView(vu.getView());\n onBindVu();\n } catch (InstantiationException e) {\n e.printStackTrace();\n } catch (IllegalAccessException e) {\n e.printStackTrace();\n }\n }\n\n @Override\n protected final void onDestroy() {\n onDestroyVu();\n vu = null;\n super.onDestroy();\n }\n\n protected abstract Class getVuClass();\n\n protected void onBindVu(){};\n\n protected void onDestroyVu() {};\n\n}\n```\n\n### 3. 创建一个基本的presenter(Fragment)\n\n```java\npublic abstract class BasePresenterFragment extends Fragment {\n\n protected V vu;\n\n @Override\n public void onCreate(Bundle savedInstanceState) {\n super.onCreate(savedInstanceState);\n }\n\n @Override\n public final View onCreateView(LayoutInflater inflater, ViewGroup container, Bundle savedInstanceState) {\n View view = null;\n try {\n vu = getVuClass().newInstance();\n vu.init(inflater, container);\n onBindVu();\n view = vu.getView();\n } catch (java.lang.InstantiationException e) {\n e.printStackTrace();\n } catch (IllegalAccessException e) {\n e.printStackTrace();\n }\n return view;\n }\n\n @Override\n public final void onDestroyView() {\n onDestroyVu();\n vu = null;\n super.onDestroyView();\n }\n\n protected void onDestroyVu() {};\n\n protected void onBindVu(){};\n\n protected abstract Class getVuClass();\n\n}\n\n```\n\n\n### 4. 一个简单的例子\n如前文所述，我们已经确定了一个框架，现在就来写一个简单的例子来进一步的说明. 为了避免篇幅过长，我就写一个“hello world”的例子。首先要有一个实现Vu接口的类： \n\n```java\npublic class HelloVu implements Vu {\n\nView view;\nTextView helloView;\n\n@Override\npublic void init(LayoutInflater inflater, ViewGroup container) {\n view = inflater.inflate(R.layout.hello, container, false);\n helloView = (TextView) view.findViewById(R.id.hello);\n}\n\n@Override\npublic View getView() {\n return view;\n}\n\npublic void setHelloMessage(String msg){\n helloView.setText(msg);\n}\n\n}\n```\n下一步，创建一个presenter来操作这个TextView\n```\npublic class HelloActivity extends BasePresenterActivity {\n@Override\nprotected void onBindVu() {\n vu.setHelloMessage(\"Hello World!\");\n}\n\n@Override\nprotected Class getVuClass() {\n return HelloVu.class;\n}\n\n}\n```\n\nOK,这样就大功告成了！！是不是很简便！\n\n### 等等...耦合警告!\n\n你可能注意到我的HelloVu类直接实现了Vu接口，我的Presenter的getVuClass方法直接引用了实现类。传统的MVP模式中，Presenter是要通过接口与他们的View解耦合的。因此，你也可以这么做。避免直接实现Vu接口，我们可以创建一个扩展了Vu的IHelloView接口，然后使用这个接口作为Presenter的泛型类型。这样Presenter看起来应该是如下这样的 : \n\n```java\npublic class HelloActivity extends BasePresenterActivity {\n\n @Override\n protected void onBindVu() {\n vu.setHelloMessage(\"Hello World!\");\n }\n\n @Override\n protected Class getVuClass() {\n return HelloVuImpl.class;\n }\n}\n```\n\n在我使用强大的模拟工具过程中，我个人并没有看到在一个接口下面实现Vu所带来的好处。但是对于我来说一个好的方面是，有没有Vu接口它都能够工作，唯一的需求就是最终你会实现Vu。\n\n## 5. 如何进行测试\n通过以上几步，我们可以发现，去除了UI逻辑之后，Activity变得非常简洁。并且，相关的测试\n也变的非常异常的简单。请看如下的代码：\n\n```java\npublic class HelloActivityTest {\n HelloActivity activity;\n HelloVu vu;\n\n @Before\n public void setup() throws Exception {\n activity = new HelloActivity();\n vu = Mockito.mock(HelloVu.class);\n activity.vu = vu;\n }\n\n @Test\n public void testOnBindVu(){\n activity.onBindVu();\n verify(vu).setHelloMessage(\"Hello World!\");\n }\n }\n```\n\n以上代码是一段标准的jnuit单元测试的代码，不需要在android设备中部署运行，只需要在编译环境中即可测试。大幅度的提高了测试效率。但是，在测试某些方法的时候，你必须要使用android设备，例如当你想测试activity生命周期中的resume()方法。在缺乏设备环境的时候，super.resume()会报错。为了解决这个问题，可以借鉴一些工具，例如Robolectric、还有android gradle 1.1 插件中内置的testOptions { unitTests.returnDefaultValues = true }。此外，你仍然可以将这些生命周期也抽离出来。例如如下:\n\n```java\n@Override\nprotected final void onResume() {\n super.onResume();\n afterResume();\n}\n\nprotected void afterResume(){}\n```\n\n\n现在，你可以在没有android设备的情况下，快速的测试了！ \n\n## 意外收获：使用adapter作为presenter\n将Activity作为presente已经足够狡猾了吧？使用adapter作为presenter，你想过没有？\n好吧，请看如下的代码：\n\n```java\npublic abstract class BasePresenterAdapter extends BaseAdapter {\nprotected V vu;\n\n@Override\npublic final View getView(int position, View convertView, ViewGroup parent) {\n if(convertView == null) {\n LayoutInflater inflater = (LayoutInflater) parent.getContext().getSystemService(Context.LAYOUT_INFLATER_SERVICE);\n try {\n vu = (V) getVuClass().newInstance();\n vu.init(inflater, parent);\n convertView = vu.getView();\n convertView.setTag(vu);\n } catch (InstantiationException e) {\n e.printStackTrace();\n } catch (IllegalAccessException e) {\n e.printStackTrace();\n }\n } else {\n vu = (V) convertView.getTag();\n }\n if(convertView!=null) {\n onBindListItemVu(position);\n }\n return convertView;\n}\n\nprotected abstract void onBindListItemVu(int position);\n\nprotected abstract Class getVuClass();\n}\n```\n\n如上代码，使用adapter作为presenter其实和activity或者fragement几乎是一样的，只有一点明显的区别就是，我把onBingVu替换成了onBindListItemVu（接受int参数）,其实我是借鉴了[ViewHolder模式](http://developer.android.com/training/improving-layouts/smooth-scrolling.html)。\n\n## 总结和一个demo\n我在这篇文章里介绍了我自己的一个实现MVP的方法。我非常期待其他android开发者对我的这套方法的反馈。我切实的想知道我的方法是否可行？我已经把这套思路用在一个框架的开发上，并且即将公布，与此同时，我在github上面有一个demo项目，感兴趣的人可以去看一下https://github.com/wongcain/MVP-Simple-Demo\n\n" }, { "path": "androidweekly/一种更清晰的Android架构/readme.md", "content": "一种更清晰的Android架构\n---\n\n>\n* 原文链接 : [Architecting Android…The clean way?](http://fernandocejas.com/2014/09/03/architecting-android-the-clean-way/)\n* 译者 : [Mr.Simple & Sophie.Ping](https://www.github.com/bboyfeiyu)\n\r过去几个月以来，通过在Tuenti网站上与@pedro_g_s和@flipper83（安卓开发两位大牛）进行友好讨论之后，我决定写这篇关于架构安卓应用的文章。 \n\r我写这篇文章的目的是想把我在过去几个月体悟到的小方法以及在调查和应用中学到的有用的东西分享给大家。\r\r## 入门指南\r大家都知道要写一款精品软件是有难度且很复杂的：不仅要满足特定要求，而且软件还必须具有稳健性，可维护、可测试性强，并且能够灵活适应各种发展与变化。这时候，“清晰架构”就应运而生了，这一架构在开发任何软件应用的时候用起来非常顺手。\r\r这个思路很简单：简洁架构 意味着产品系统中遵循一系列的习惯原则：\n\r\n* 框架独立性\n* 可测试\n* UI独立性\n* 数据库独立性\n* 任何外部代理模块的独立性 \n\r![arch](https://camo.githubusercontent.com/dd69e725f30c30031dea279adc5a9d09ea3432f2/687474703a2f2f6665726e616e646f63656a61732e636f6d2f77702d636f6e74656e742f75706c6f6164732f323031342f30392f636c65616e5f617263686974656374757265312e706e67)\r\r我们并不要求一定要用四环结构（如图所示），这只是一个示例图解，但是要考虑的是依赖项规则：源码依赖项只能向内指向，内环里的所有项不能了解外环所发生的东西。 \n\r以下是更好地理解和熟悉本方法的一些相关词汇： \r\r* Entities：是指一款应用的业务对象\r* Use cases：是指结合数据流和实体中的用例，也称为Interactor\r* Interface Adapters： 这一组适配器，是负责以最合理的格式转换用例（use cases）和实体（entities）之间的数据，表现层（Presenters ）和控制层（Controllers ），就属于这一块的。\n* Frameworks and Drivers: 这里是所有具体的实现了：比如：UI，工具类，基础框架，等等。\r\r想要更具体，更生动丰富的解释，可以参考[这篇文章](http://blog.8thlight.com/uncle-bob/2012/08/13/the-clean-architecture.html)或者[这个视频](https://vimeo.com/43612849)。\n\r\r## 场景\r我会设置一个简单的场景来开始：创建一个简单的小app，app中显示从云端获取的一个朋友或用户列表。当点击其中任何一个时，会打开一个新的窗口，显示该用户的详细信息。这里我放了一段视频，大家看看[这个视频 (需翻墙)](http://fernandocejas.com/2014/09/03/architecting-android-the-clean-way/)大概就可以对我所描述的东西了解个大概了。 \n\r\r## Android应用架构\r这一对象遵循关注分离原则，也就是通过业务规则让内环操作对外环事物一无所知，这样一来，在测试时它们就不会依赖任何的外部元素了。 \r要达到这个目的，我的建议就是把一个项目分成三个层次，每个层次拥有自己的目的并且各自独立于堆放运作。\r值得一提的是，每一层次使用其自有的数据模型以达到独立性的目的（大家可以看到，在代码中需要一个数据映射器来完成数据转换。如果你不想把你的模型和整个应用交叉使用，这是你要付出的代价）。 \n\r\r以下是图解，大家感受下： \n\r![schema](http://fernandocejas.com/wp-content/uploads/2014/09/clean_architecture_android.png)\n\r> \r注：我并没有使用任何的外部库（除了用于json数据句法分析的gson和用于测试的junit, mockito, robolectric和espresso以外）。原因是它可以使这个示例更清晰。总之，在存储磁盘数据时，记得加上ORM、依赖注入框架或者你熟悉的任何工具或库，这些都会带来很大帮助。（记住：重复制造轮子可不是明智的选择）\n\r## 表现层 (Presentation Layer)\n\r表现层在此，表现的是与视图和动画相关的逻辑。这里仅用了一个Model View Presenter（下文简称MVP），但是大家也可以用MVC或MVVM等模式。这里我不再赘述细节，但是需要强调的是，这里的fragment和activity都是View,其内部除了UI逻辑以外没有其他逻辑，这也是所有渲染的东西发生的地方。\r本层次的Presenter由多个interactor（用例）组成，Presenter在 android UI 线程以外的新线程里工作，并通过回调将要渲染到View上的数据传递回来。\r![mvp](http://fernandocejas.com/wp-content/uploads/2014/09/clean_architecture_mvp.png) \n \r如果你需要一个使用MVP和MVVM的[Effective Android UI](https://github.com/pedrovgs/EffectiveAndroidUI/)典型案例，可以参考我朋友Pedro Gómez的文章。\r\r## 领域层 (Domain Layer)\n\r这里的业务规则是指所有在本层发生的逻辑。对于Android项目来说，大家还可以看到所有的interactor（用例）实施。这一层是纯粹的java模块，没有任何的Android依赖性。当涉及到业务对象时，所有的外部组件都使用接口。 \n\r![domain](http://fernandocejas.com/wp-content/uploads/2014/09/clean_architecture_domain.png) \n \r## 数据层 (Data Layer)\r应用所需的所有数据都来自这一层中的UserRepository实现（接口在领域层）。这一实现采用了[Repository Pattern](http://martinfowler.com/eaaCatalog/repository.html)，主要策略是通过一个工厂根据一定的条件选取不同的数据来源。\r比如，通过ID获取一个用户时，如果这个用户在缓存中已经存在，则硬盘缓存数据源会被选中，否则会通过向云端发起请求获取数据，然后存储到硬盘缓存。\r这一切背后的原理是由于原始数据对于客户端是透明的，客户端并不关心数据是来源于内存、硬盘还是云端，它需要关心的是数据可以正确地获取到。\r\r![data](http://fernandocejas.com/wp-content/uploads/2014/09/clean_architecture_data.png) \n\r>\r注：在代码方面，出于学习目的，我通过文件系统和Android preference实现了一个简单、原始的硬盘缓存。请记住，如果已经存在了能够完成这些工作的库，就不要重复制造轮子。\r\r## 错误处理\r这是一个长期待解决的讨论话题，如果大家能够分享各自的解决方案，那真真是极好的。\r我的策略是使用回调，这样的话，如果数据仓库发生了变化，回调有两个方法：onResponse()和onError(). onError方法将异常信息封装到一个ErrorBundle对象中: 这种方法的难点在于这其中会存在一环扣一环的回调链，错误会沿着这条回调链到达展示层。因此会牺牲一点代码的可读性。另外，如果出现错误，我本来可以通过事件总线系统抛出事件，但是这种实现方式类似于使用C语言的goto语法。在我看来，当你订阅多个事件时，如果不能很好的控制，你可能会被弄得晕头转向。\r\r\r## 测试\r关于测试方面，我根据不同的层来选择不同的方法: \n\r*\t展示层 ( Presentation Layer) : 使用android instrumentation和 espresso进行集成和功能测试\r*\t领域层 ( Domain Layer) : 使用JUnit和Mockito进行单元测试；\r*\t数据层 ( Data Layer) : 使用Robolectric （ 因为依赖于Android SDK中的类 ）进行集成测试和单元测试。\r\r## 代码展示\r我猜你现在在想，扯了那么久的淡，代码究竟在哪里呢？ 好吧，这就是你可以找到上述解决方案的[github链接](https://github.com/android10/Android-CleanArchitecture)。还要提一点，在文件夹结构方面，不同的层是通过以下不同的模块反应的: \n\r*\tpresentation: 展示层的Android模块\r*\tdomain: 一个没有android依赖的java模块\r*\tdata: 一个数据获取来源的android模块。\r*\tdata-test: 数据层测试，由于使用Robolectric 存在一些限制，所以我得再独立的java模块中使用。\r\r## 结论\r正如 Bob大叔 所说：“Architecture is About Intent, not Frameworks” ，我非常同意这个说法，当然了，有很多不同的方法做不同的事情（不同的实现方法），我很确定，你每天（像我一样）会面临很多挑战，但是遵循这些方法，可以确保你的应用会： \n\r*\t易维护 Easy to maintain\r*\t易测试 Easy to tes.\r* 高内聚 Very cohesive.\r*\t低耦合 Decoupled. \t\r\r最后，我强烈推荐你去实践一下，并且分享你的经验。也许你会找到更好的解决方案：我们都知道，不断提升自己是一件件非常好的事。我希望这篇文章对你有所帮助，欢迎拍砖。\r\r## 参考资料\r
    \n
  1. Source code: https://github.com/android10/Android-CleanArchitecture
    2. \n
  2. The clean architecture by Uncle Bob
    3. \n
  3. Architecture is about Intent, not Frameworks
    4. \n
  4. Model View Presenter
    5. \n
  5. Repository Pattern by Martin Fowler
    6. \n
  6. Android Design Patterns Presentation
    7. \n
\r\r" }, { "path": "androidweekly/使用Robolectric的参数化测试/readme.md", "content": "使用Robolectric的参数化测试\n---\n\n>\n* 原文标题 : Parameterized testing with Robolectric\n* 原文链接 : [Parameterized testing with Robolectric](http://www.jayway.com/2015/03/19/parameterized-testing-with-robolectric/)\n* 译者 : [Lollypo](https://github.com/Lollypo) \n* 校对者: [Chaos](https://github.com/chaossss) \n* 状态 : 校对完成\n\n在目前的项目中我们使用Robolectric为Android应用程序编写单元测试,它一直都干的不错。最近我需要编写一个测试用例,通过每次使用不同的测试数据，将同一个操作执行若干次，并由此断言：正确的动作能否发生是由数据决定的。\n\nJUnit对于这个情况提供了一个易于使用的选项，它叫做参数化测试-先定义测试数据，,然后使用参数化测试运行器来执行测试。这将创建一个该测试类的实例把测试数据中的每个元素传递到构造函数的参数中。\n\n事实证明，Robolectric有一个完全相同的`ParameterizedRobolectricTestRunner`(稍微调整以适应Robolectric)，而且它对于我的测试：验证应用程序从外部服务提供者接收到不同的错误代码的行为，做的非常好\n\n```java\n@RunWith(ParameterizedRobolectricTestRunner.class)\npublic class ContactServiceTest {\n \n @ParameterizedRobolectricTestRunner.Parameters(name = \"ErrorCode = {0}\")\n public static Collection data() {\n return Arrays.asList(new Object[][]{\n {105, 105_ERROR_MSG},\n {113, 113_ERROR_MSG},\n {114, 114_ERROR_MSG},\n {134, 134_ERROR_MSG},\n {137, 137_ERROR_MSG},\n {999, DEFAULT_ERROR_MSG} // Bogus错误代码\n });\n }\n \n private int errorCode;\n private String expectedErrorMsg;\n \n public ContactServiceTest(int errorCode, String errorMsg) {\n this.errorCode = errorCode;\n this.expectedErrorMsg = errorMsg;\n }\n \n @Test\n public void when_known_error_code_is_received_from_service_correct_error_msg_is_displayed_to_user() {\n // HTTP响应从服务包含定义的错误代码\n Robolectric.addPendingHttpResponse(HttpStatus.SC_OK, buildFakeServiceResponse(errorCode)); \n // 联系服务\n mService.contactService();\n // 使用awaitility等到错误消息显示给用户\n\t\t// 然后断言该错误代码与期望一致\n await().until(getDisplayedErrorMsg(), is(expectedErrorMsg));\n }\n```\n\n该测试用例将被执行6次，一旦遍历测试数据的每个元素，就会将打印的错误消息与特定错误代码定义的错误消息相比较。当创建测试报告时，每一个测试运行都将视为其自身的测试用例。\n\n添加了`name`参数到Parameters注解上将会整理测试结果。作为测试运行结果显示,测试用例的名称将会像下面这种情况下\n\n```java\nwhen_known_error_code_is_received_from_service_correct_error_msg_is_displayed_to_user[ErrorCode = 105]\nwhen_known_error_code_is_received_from_service_correct_error_msg_is_displayed_to_user[ErrorCode = 113]\nwhen_known_error_code_is_received_from_service_correct_error_msg_is_displayed_to_user[ErrorCode = 114]\n...\n```\n\n如需深入理解请查阅[JUnit Theories](https://github.com/junit-team/junit/wiki/Theories)以及[junit-quickcheck](https://github.com/pholser/junit-quickcheck)，一个好的生成测试数据的方法是在JUnit中自动生成（Robolectric也差不多），而不是由你自己定义。" }, { "path": "androidweekly/使用RxJava.Observable取代AsyncTask和AsyncTaskLoader/readme.md", "content": "使用RxJava.Observable取代AsyncTask和AsyncTaskLoader\n---\n\n>\n* 原文链接 : [Replace AsyncTask and AsyncTaskLoader with rx.Observable – RxJava Android Patterns](http://stablekernel.com/blog/replace-asynctask-asynctaskloader-rx-observable-rxjava-android-patterns/)\n* 译者 : [ZhaoKaiQiang](https://github.com/ZhaoKaiQiang) \n* 校对者: [chaossss](https://github.com/chaossss) \n* 状态 : 校对完成\n\n\n在网上有很多关于RxJava入门指南的帖子，其中一些是基于Android环境的。但是，我想到目前为止，很多人只是喜欢他们所看到的这些，当要解决在他们的Android项目中出现的具体问题时，他们并不知道如何或者是为什么要使用RxJava。在这一系列的文章中，我想要探索在我工作过的一些依赖于RxJava架构的Android项目中的模式。\n\n在文章的开始，我想要处理一些Android开发者在使用RxJava的时候，很容易遇到的状况。从这个角度，我将提供更高级和更合适的解决方案。在这一系列的文章中，我希望可以听到其他开发者在使用RxJava的过程中解决类似的问题，或许他们和我发现的一样呢。\n\n#问题一：后台任务\nAndroid开发者首先遇到的挑战就是如何有效的在后台线程中工作，然后在UI线程中更新UI。这经常是因为需要从web service中获取数据。对于已经有相关经验的你可能会说：“这有什么挑战性？你只需要启动一个AsyncTask，然后所有的工作它就都给你做了。”如果你是这样想的，那么你有一个机会去改善这种状况。这是因为你已经习惯了这种复杂的方式并且忘记这本应该是很简洁的，或者是说你没有处理所有应该处理的边界情况。让我们来谈谈这个。\n\n##默认的解决方案：AsyncTask\nAsyncTask是在Android里面默认的处理工具，开发者可以做里面一些长时间的处理工作，而不会阻塞用户界面。(注意：最近，AsyncTaskLoader用来处理一些更加具体的数据加载任务，我们以后会再谈谈这个)\n\n表面上，这似乎很简单，你定义一些代码在后台线程中运行，然后定义一些代码运行在UI线程中，在后台任务处理完之后，它在UI线程会处理从后台任务传递过来的执行结果。\n\n```java\n\tprivate class CallWebServiceTask extends AsyncTask {\n \n\t protected Result doInBackground(String... someData) {\n\t Result result = webService.doSomething(someData);\n\t return result;\n\t }\n \n\t protected void onPostExecute(Result result) {\n\t if (result.isSuccess() {\n\t resultText.setText(\"It worked!\");\n\t }\n\t }\n\t}\n``` \n\n使用AsyncTask的最大的问题是在细节的处理上，让我们谈谈这个问题。\n\n###错误处理\n这种简单用法的第一个问题就是：“如果出现了错误怎么办？”不幸的是，暂时没有非常好的解决方案。所以很多的开发者最终要继承AsyncTask，然后在doInBackground()中包裹一个try/catch，返回一个，然后根据发生的情况，分发到新定义的例如onSuccess()或者是onError()中。(我也曾经见过仅捕获异常的引用，然后在 onPostExcecute()中进行检查的写法) \n\n这最终是有点帮助的，但是你必须为你的每个项目写上额外的代码，随着时间的推移，这些自定义的代码在开发者之间和项目之间，可能不会保持很好的一致性和可预见性。\n\n###Activity和Fragment的生命周期\n另外一个你必须面对的问题是：“当AsyncTask正在运行的时候，如果我退出Activity或者是旋转设备的话会发生什么？”嗯，如果你只是发送一些数据，之后就不再关心发送结果，那可能是没有问题的，但是如果你需要根据Task的返回结果更新UI呢？如果你不做一些事情阻止的话，那么当你试图去调用Activity或者是view的话，你将得到一个空指针异常导致程序崩溃，因为他们现在是不可见或者是null的。\n\n同样，在这个问题上AsyncTask没有做很多工作去帮助你。作为一个开发者，你需要确保保持一个Task的引用，并且要么当Activity正在被销毁的时候取消Task，要么当你试图在onPostExecute()里面更新UI的时候，确保Activity是在一个可达状态。当你只想明确的做一些工作，并且让项目容易维护的时候，这将会继续提高维护项目的难度。\n\n###旋转时的缓存(或是其他情况)\n当你的用户还是待在当前Activity，仅仅是旋转屏幕会发生什么？在这种情况下，取消Task没有任何意义，因为在旋转之后，你最终还是需要重新启动Task。或者是你不想重启Task，因为状况在一些地方以非幕等的方式发生了突变(because it mutates some state somewhere in a non-idempotent way),但是你确实想要得到结果，因为这样你就可以更新UI来反映这种情况。\n\n如果你专门的做一个只读的加载操作，你可以使用AsyncTaskLoader去解决这个问题。但是对于标准的Android方式来说，它还是很沉重，因为缺少错误处理，在Activity中没有缓存，还有很多独有的其他怪癖。\n\n###组合的多个Web Server调用\n现在，假如说我们已经想办法把上面的问题都解决了，但是我们现在需要做一些连续的网络请求，每一个请求都需要基于前一个请求的结果。或者是，我们想做一些并发的网络请求，然后把结果合并在一起发送到UI线程，但是，再次抱歉，AsyncTask在这里帮不到你。\n\n一旦你开始做这样的事情，随着更多的复杂线程模型的增长，之前的问题会导致处理这样的事情非常的痛苦和苍白无力。如果想要这些线程一起运行，要么你就让它们单独运行，然后回调，要么让它们在一个后台线程中同步运行，最后复制组成不同。(To chain calls together, you either keep them separate and end up in callback hell, or run them synchronously together in one background task end up duplicating work to compose them differently in other situations.)\n\n如果要并行运行，你必须创建一个自定义的executor然后传递给AsyncTaskTask，因为默认的AsyncTask不支持并行。并且为了协调并行线程，你需要使用像是CountDownLatchs, Threads, Executors 和 Futures去降低更复杂的同步模式。\n\n###可测试性\n抛开这些不说，如果你喜欢测试你的代码，AsyncTask并不能给你带来什么帮助。如果我们不做额外的工作，测试AsyncTask非常困难，它很脆弱并且难以维持。这是一篇有关如何成功测试AsyncTask的[帖子](http://www.making-software.com/2012/10/31/testable-android-asynctask/)。\n\n##更好的解决方案：RxJava’s Observable\n\n幸运的是，一旦我们决定使用RxJava依赖库的时候，我们讨论的这些问题就都迎刃而解了。下面我们看看它能为我们做什么。\n\n下面我们将会使用Observables写一个请求代码来替代上面的AsyncTask方式。(如果你使用Retrofit，那么你应该很容易使用，其次它还支持Observable 返回值，并且它工作在一个后台的线程池，无需你额外的工作)\n\n```java\n\twebService.doSomething(someData)\n .observeOn(AndroidSchedulers.mainThread())\n .subscribe(\n result -> resultText.setText(\"It worked!\")),\n e -> handleError(e)\n );\n```\n\n###错误处理\n你可能会注意到，没有做额外的工作，我们已经处理了AsyncTask不会处理的成功和错误的情况，并且我们写了很少的代码。你看到的额外的组件是我们想要Observer 在UI主线程中处理的结果。这样可以让我们前进一点点。并且如果你的webService对象不想在后台线程中运行，你也可以在这里通过使用.subscribeOn(...) 声明。(注意：这些例子是使用Java 8的lambda语法，使用[Retrolambda](https://github.com/orfjackal/retrolambda)就可以在Android项目中进行使用了，但在我看来，这样做的回报是高于风险的，和写这篇文章相比，我们更喜欢在我们的项目中使用。)\n\n###Activity和Fragment的生命周期\n现在，我们想在这里利用RxAndroid解决上面提到的生命周期的问题，我们不需要指定mainThread() scheduler(顺便说一句，你只需要导入RxAndroid)。就像下面这样\n\n```java\n\tAppObservable.bindFragment(this, webService.doSomething(someData))\n .subscribe(\n result -> resultText.setText(\"It worked!\")),\n e -> handleError(e)\n );\n```\n\n我通常的做法是在应用的Base Fragment里面创建一个帮助方法来简化这一点，你可以参考我维护的一个[Base RxFragment](https://github.com/rosshambrick/standardlib/blob/master/src/main/java/com/rosshambrick/standardlib/RxFragment.java) 获得一些指导。\n\n```java\n\tbind(webService.doSomething(someData))\n .subscribe(\n result -> resultText.setText(\"It worked!\")),\n e -> handleError(e)\n );\n```\n\n如果我们的Activity或者是Fragment不再是可见状态，那么AppObservable.bindFragment()可以在调用链中插入一个垫片，来阻止onNext()运行。如果当Task试图运行的时候，Activity、Fragment是不可达状态，subscription 将会取消订阅并且停止运行，所以不会存在空指针的风险，程序也不会崩溃。一个需要注意的是，当我们离开Activity和Fragment时，我们会暂时或者是永久的泄露，这取决于问题中的Observable 的行为。所以在bind()方法中，我也会调用LifeCycleObservable机制，当Fragment销毁的时候自动取消。这样做的好处是一劳永逸。\n\n所以，这解决了首要的两个问题，但是下面这一个才是RxJava大发神威的地方。\n\n###组合的多个Web Server调用\n在这里我不会详细的说明，因为这是一个[复杂的问题](http://reactivex.io/documentation/observable.html)，但是通过使用Observables，你可以用非常简单和易于理解的方式完成复杂的事情。这里是一个链式Web Service调用的例子，这些请求互相依赖，在线程池中运行第二批并行调用，然后在将结果返回给Observer之前，对数据进行合并和排序。为了更好的测量，我甚至在里面放置了一个过滤器。所有的业务逻辑都在下面这短短五行代码里面...\n\n```java\n\tpublic Observable> getWeatherForLargeUsCapitals() {\n return cityDirectory.getUsCapitals() \n .flatMap(cityList -> Observable.from(cityList))\n .filter(city -> city.getPopulation() > 500,000)\n .flatMap(city -> weatherService.getCurrentWeather(city)) //each runs in parallel\n .toSortedList((cw1,cw2) -> cw1.getCityName().compare(cw2.getCityName()));\n\t}\n```\n\n###旋转时的缓存(或是其他情况)\n既然这是一个加载的数据，那么我们可能需要将数据进行缓存，这样当我们旋转设备的时候，就不会触发再次调用全部web service的事件。一种实现的方式是保留Fragment，并且保存一个对Observable 的缓存的引用，就像下面这样：\n\n```java\n @Override\n public void onCreate(Bundle savedInstanceState) {\n super.onCreate(savedInstanceState);\n\n setRetainInstance(true);\n weatherObservable = weatherManager.getWeatherForLargeUsCapitals().cache();\n }\n\n public void onViewCreated(...) {\n super.onViewCreated(...)\n bind(weatherObservable).subscribe(this);\n }\n```\n\n在旋转之时,正在运行当中的Subscription(代表了事件源和订阅者之间的关系)会被缓存到一个实例,在旋转之后，这个实例就会立即发送一些和旋转之前已经发送过的事件相同的事件，从而避免了再去重复请求网络服务。\n\n如果你想要避免缓存的Fragment(或者是由于它是一个子Fragment,你不能缓存它)，此时我们可以通过putting the same cache instance one layer down inside a service singleton,或者使用一个无论何时被订阅,都会重新发出最后的事件AsyncSubject实现缓存,或者使用可以在整个应用中获得最后的值以及由改变引起的新值的BehaviorSubject这些来完成缓存(以上这些我将会在我不久后的一篇文章里面更详细的讲明,那篇文章我将使用一种更接近事件总线的observables)。\n\n```java\n WeatherListFragment.java \n\t\n\tpublic void onViewCreated() {\n super.onViewCreated()\n bind(weatherManager.getWeatherForLargeUsCapitals()).subscribe(this);\n\t}\n\n WeatherManager.java\n\n\tpublic Observable> getWeatherForLargeUsCapitals() {\n if (weatherSubject == null) {\n weatherSubject = AsyncSubject.create();\n\n cityDirectory.getUsCapitals() \n .flatMap(cityList -> Observable.from(cityList))\n .filter(city -> city.getPopulation() > 500,000)\n .flatMap(city -> weatherService.getCurrentWeather(city))\n .toSortedList((cw1,cw2) -> cw1.getCityName().compare(cw2.getCityName()))\n .subscribe(weatherSubject);\n }\n return weatherSubject;\n\t}\n```\n\n因为“缓存”是由Manager单独管理的，它不会与Fragment/Activity的周期绑定，并且会保持与Activity/Fragment的解耦。如果你想以一种和处理保存的fragment的生命周期事件相同的手段来强制刷新这个缓存实例的话，你可以这样做：\n\n```java\n\tpublic void onCreate() {\n super.onCreate()\n if (savedInstanceState == null) {\n weatherManager.invalidate(); //invalidate cache on fresh start\n }\n\t}\n```\n\n这件事情的伟大之处在于，它不像是Loaders，我们可以很灵活的缓存这些结果,他们来自我们选择的Activity和Services中。只需要去掉oncreate()中的invalidate()调用，并让你的Manager对象决定何时发出新的气象数据就可以了。可能是一个Timer，或者是用户定位改变，或者是其他任何时刻，这真的没关系。你现在可以控制什么时候如何去更新缓存和重新加载。并且当你的缓存策略发生改变的时候，Fragment和你的Manager对象之间的接口不需要进行改变。它只不过是一个 List的Observer。\n\n###可测试性\n测试是我们想要实现干净、简单的最后一个挑战。(我们可以不用模拟真实的网络服务来进行测试。做法很简单，下面通过一个接口注入这些依赖,这个接口你可能已经在用了。)\n\n幸运的是，Observables给我们一个简单的方式来将一个异步方法变成同步，你要做的就是使用toblocking()方法。我们看一个测试例子。\n\n```java\n\tList results = getWeatherForLargeUsCapitals().toBlocking().first();\n\tassertEquals(12, results.size());\n```\n\n就像这样，我们没有必要去使用Futures或者是CountDownLatchs让做一些脆弱的操作，比如线程睡眠或者是让我们的测试变得很复杂，我们的测试现在是简单、干净、可维护的。\n\n##结论\n更新：我已经创建了一对简单的项目来演示[AsyncTask风格](https://github.com/rosshambrick/AsyncExamples)和[AsyncTaskLoader](https://github.com/rosshambrick/rain-or-shine)风格。\n\nRxJava，你值得拥有。我们使用rx.Observable来替换AsyncTask和AsyncTaskLoader可实现更加强大和清晰的代码。使用RxJava Observables很快乐，而且我期待能够呈现更多的Android问题的解决方案。\n" }, { "path": "androidweekly/使用buildSrc Gradle项目和Codemodel生成java代码/readme.md", "content": "#How to generate Java sources using buildSrc Gradle project and Codemodel\n#使用buildSrc Gradle项目和Codemodel生成java代码\n\r\n[Android](http://www.thedroidsonroids.com/category/blog/android/) • 1 September 2015\n\n> * 原文链接 : [How to generate Java sources using buildSrc Gradle project and Codemodel](http://www.thedroidsonroids.com/blog/android/how-to-generate-java-sources-using-buildsrc-gradle-project/)\n> * 原文作者 : [Karol](http://www.thedroidsonroids.com/blog/)\n> * 译文出自 : [开发技术前线 www.devtf.cn。未经允许，不得转载!](http://www.devtf.cn/)\r> * 译者 : [shenyansycn](https://github.com/shenyansycn)\r> * 校对者 : \n> * 状态 : 校对中\r\n\r\n##Introduction\r\n\n假设现在你现在需要在Android应用中嵌入和解析外部数据，你会怎么做？在本文中我们将在应用中获取[互联网顶级域名(TLD)的列表](https://en.wikipedia.org/wiki/List_of_Internet_top-level_domains)。你可以在[ICANN TLD报告](http://stats.research.icann.org/dns/tld_report/)报告中看到一共有一千多种顶级域名，时不时有新域名的加入，也有旧的域名被废弃。\n\n由于Android中管理TLDs的[API](https://developer.android.com/reference/android/util/Patterns.html#TOP_LEVEL_DOMAIN_STR)很快就过时了，不赞成使用。哪里能获得最新的TLD的列表呢？幸好这里有一个INAN维护的机器识别源:[IANA - Root Zone DataBase](https://data.iana.org/TLD/tlds-alpha-by-domain.txt).好了，我们已经获得了一个源，那如何在应用中嵌入呢？这里有一些方法，例如，我们可以下载文本文件到**assets**或者**res/raw**目录，运行时再解析。但这里有一个更有效的方法－应用编译前解析数据和运行时使用已经处理好的数据。我们可以使用所提供的方法叫**getTldList()**,它返回最新的TLDS。就像Android的编译工具在每次编译时自动刷新**R**类一样。\n\n##生成的代码长什么样？\r\n\n例子中的数据是一个字符串的列表，所以它可以被表示为**List****<****String****>**。域是独一无二的，它永远不能被编辑并且[List](http://developer.android.com/reference/java/util/List.html)接口提供稍微多一点的内容，比如索引。我们用一个方法创建了一个实用性的类，就像下边这样：\n\n```\r\npublic final class TldList {\r\n \tprivate static final List TLD_LIST = Collections.unmodifiableList(Arrays.asList());\r\n /**\r\n * javadoc here\r\n */\r\n public static List getTldList() { \r\n return TLD_LIST; \r\n }\r\n private TldList() {}\r\n}\n```\r\n \r\n##How to generate Java code automatically?\n##如何自动生成Java代码\n\n生成Java代码需要下载源文件并重写到Java源文件中。后者可以打印java语法元素到文件中。但更好的方法是使用专用库。在此情况下你不必担心大括号，换行符和其他语法元素只需要关注逻辑。在这个例子中使用的生成java代码的库是[Codemodel](https://codemodel.java.net/)。使用Codemodel生成代码是简单的。我们用Groovy编写Gradle本身和大部分的插件。\n\n这里有生成好的代码：\r\n\r\n```\r\npublic class TldListGenerator {\r\n\r\n private static final URL IANA_TLDS_URL = \r\n new URL('https://data.iana.org/TLD/tlds-alpha-by-domain.txt')\r\n\r\n /**\r\n * Generates pl.droidsonroids.domainnameutils.TldList \r\n * and places it into outputDir.\r\n * @param outputDir directory where generated sources will be written to\r\n * @param useSavedVersion if true then saved TLD data will be used instead of downloading it \r\n * from IANA's website\r\n */\r\n public static void generateTldListClass(final File outputDir, final boolean useSavedVersion) {\r\n def javadocConfig = new ConfigSlurper()\r\n .parse(TldListGenerator.class.getResource('javadoc.properties'))\r\n def sourceUrl = useSavedVersion ?\r\n TldListGenerator.class.getResource('tlds-alpha-by-domain.txt')\r\n : IANA_TLDS_URL\r\n\r\n def codeModel = new JCodeModel()\r\n\r\n def fqcn = TldListGenerator.class.getPackage().getName() + '.TldList'\r\n def tldListClass = codeModel._class(PUBLIC | FINAL, fqcn, ClassType.CLASS)\r\n def classJavadoc = tldListClass.javadoc()\r\n classJavadoc.append(javadocConfig.getProperty('classJavadoc'))\r\n\r\n def listStringType = codeModel.ref(List.class).narrow(codeModel.ref(String.class))\r\n def asListInvocation = codeModel.directClass(Arrays.class.getName()).staticInvoke('asList')\r\n\r\n sourceUrl.eachLine {\r\n if (!it.startsWith('#')) {\r\n asListInvocation.arg(it.toLowerCase(Locale.ENGLISH))\r\n } else {\r\n classJavadoc.append('\\n
').append(it.replaceFirst('#\\\\s+', ''))\r\n }\r\n return\r\n }\r\n\r\n def constant = codeModel\r\n .directClass(Collections.class.getName())\r\n .staticInvoke('unmodifiableList')\r\n .arg(asListInvocation)\r\n def field = tldListClass.field(PRIVATE | STATIC | FINAL, listStringType, 'TLD_LIST', constant)\r\n def method = tldListClass.method(PUBLIC | STATIC, listStringType, 'getTldList')\r\n\r\n method.javadoc()\r\n .append(javadocConfig.getProperty('methodJavadoc'))\r\n .addReturn()\r\n .append(javadocConfig.getProperty('methodReturnJavadoc'))\r\n method.body()._return(field)\r\n tldListClass.constructor(PRIVATE)\r\n\r\n if (!outputDir.isDirectory() && !outputDir.mkdirs()) {\r\n throw new IOException('Could not create directory: ' + outputDir)\r\n }\r\n codeModel.build(outputDir)\r\n }\r\n}\n```\n\n让我们解释下关键代码部分。在开始的部分我们使用[ConfigSlurper](http://docs.groovy-lang.org/latest/html/gapi/groovy/util/ConfigSlurper.html)从属性中加载java文档。属性是一对key-value，和代码位于不同文件中，并没有被混淆在一起，所有的java文档都在一个地方就像好Android的String资源。Codemodel API就像我们平时写代码一样调用方法即可。\n\n读取输入使用[ResourceGroovyMethods#eachLine()](http://docs.groovy-lang.org/latest/html/api/org/codehaus/groovy/runtime/ResourceGroovyMethods.html#eachLine)方法，从URL中读取每一行内容就好像闭包（代码片段用大括号包围）。特别的变量**it**是一个String内容，是每一行的内容。刚开始的行是注释，所以我们可以写入到java文档中。其他的行包含TLDs，所以我们转换为小写字母写入代码中。所有的行被处理过后，源会被自动关闭。像java中的try-catch-finally或try-with-resources声明。\n\n小写TLDs的操作设置为英语环境也是很重要的。如果没有则使用host提供的默认设置。例如：如果设置为土耳其或者阿塞拜疆，非ASII字符小写i会被当作一个小写的ASCII字符I，我们生成的一些TLDs就会无效。更多信息可以查看[Internationalizing Turkish](http://www.i18nguy.com/unicode/turkish-i18n.html).最终，我们创建了输出的目录结构并保存了生成的代码。\n\n怎么处理错误，如果没有网络连接或者数据没有被下载会发生什么？如，你看到的没有**cactch**声明也无**throws**处理。在Groovy里我们是不需要的，所有的异常都是未被检查的被处理过。如果我们的代码抛出了异常，它仅仅引起Gradle编译失败，会在Android Studio的消息窗口和控制台中显示。\r\n\n##哪里存放生成的代码\n\nGradle给我们提供了几个方式保存生成的代码，例如：\n\n1.直接嵌入到我们App项目的**build.gradle**文件中\n\n2.分开的文件。例如：**generator.gradle**和在**build.gradle**文件中使用**apply from: 'generator.gradle'**\n\n3.[buildSrc project](https://docs.gradle.org/current/userguide/organizing_build_logic.html#sec:build_sources)\n\n4.[standalone project](https://docs.gradle.org/current/userguide/custom_plugins.html#N16FA7)\n\n头两个选项没有一点灵活性。例如：我们生成的代码不能很简单的测试，（特别是第一个）生成的代码与编译配置选项容易混淆让人难以读懂。剩余两项的关键不同是在应用中如何配置。独立的项目在当很多项目被配置使用、需要一个仓库或至少拷贝一个JAR文件时是有用处的。在这个例子中我们将在一个单独的项目中使用我们生成好的代码并且我们将它放在**buildSrc**项目中\r\n\n##**buildSrc** project是什么？\n\nGradle特别处理过的名字为**buildSrc**的目录在项目的根目录时。子项目**buildSrc**（和Android Studio或IntelliJ的子module）被自动创建（不需要在**settings.gradle**中声明）。甚至项目的**build.gradle**都不是必须的因为默认的已经被隐式实现。在Gradle文档中查看[Organizing Build Logic](https://docs.gradle.org/current/userguide/organizing_build_logic.html#sec:build_sources)更多信息。这个项目被加入到了编译脚本的classpath中，所以它的内容可以在build.gradle中用同样的方式使用作为classpath的依赖。例如：**classpath com.android.tools.build:gradle:1.2.3'**。**buildSrc**项目一样也有单元测试和资源。可以被任一项目的Gradle执行。\r\n\n##如何使用生成的代码？\n\n我们需要调用我们的**generateTldListClass()**方法。我们能创建一个完整的Gradle插件，但对于这个简单的目的，我们在App项目中的**build.gradle**文件中添加一个自定义的任务。例子实现如下：\r\n\r\n```\r\nimport pl.droidsonroids.domainnameutils.TldListGenerator\r\n\r\napply plugin: 'com.android.application'\r\n\r\ndef generatedSrcDir = new File(buildDir, \"generated/tld/src/main/java/\")\r\n\r\ntask generateTldList << {\r\n TldListGenerator.generateTldListClass(generatedSrcDir, true)\r\n}\r\n\r\npreBuild.dependsOn generateTldList\r\n\r\nandroid {\r\n sourceSets {\r\n main {\r\n java {\r\n srcDirs += generatedSrcDir\r\n }\r\n }\r\n }\r\n\r\n}\r\n```\n\n让我们分析这个编译脚本。Gradle编译时产生的文件默认会被放在项目根目录下的**build**目录。在**build.gradle**中会被作为**buildDir**被检索到。如此，我们构建了输出目录。\n\n我们也可以创建自定义任务叫**generateTldList**.注意**<<**是一个定义为行为的快捷方式。关于任务的更多信息看[Gradle tasks documentation](https://docs.gradle.org/current/userguide/more_about_tasks.html)。在Android Gradle插件里我们继续添加我们的任务作为**preBuild**任务的一个依赖，当每一个项目编译刚开始时被执行。最终我们把输出目录加入到了main source中，在app源码中可以被引入。\r\n\n##如何使用生成的代码\r\n\n我们可以像使用其他类一样使用我们生成的类。下边的例子展示如何创建一个包含TLDS的简单Spinner：\n\r\n```\r\nfinal Spinner spinner = (Spinner) findViewById(R.id.spinner_tld);\r\nspinner.setAdapter(new ArrayAdapter<>(this, android.R.layout.simple_dropdown_item_1line, TldList.getTldList()));\n```\r\n \r\n##Sample project\n##例子\n\n生成代码的例子和简单的Android项目可以在Github上看到：[koral–/buildsrc-sample](https://github.com/koral--/buildsrc-sample)。Android Studio 1.3中会提示**Class 'TldListGenerator' already exists in 'pl.droidsonroids.domainnameutils'**是但是它并不会影响项目的构建。运行App看起来像下边这样\n\n![Screenshot](https://cloud.githubusercontent.com/assets/3340954/9006569/24f8743a-3789-11e5-9ccf-b36bce782894.png)\r\n\r\n##References\n##引用\r\n\r\n* [IANA — Root Zone Database](https://data.iana.org/TLD/tlds-alpha-by-domain.txt)\r\n* [Codemodel](https://codemodel.java.net/)\n* [Internationalizing Turkish](http://www.i18nguy.com/unicode/turkish-i18n.html)\n* [Organizing Gradle Build Logic](https://docs.gradle.org/current/userguide/organizing_build_logic.html#sec:build_sources)\n* [Writing Custom Gradle Task Classes](https://docs.gradle.org/current/userguide/custom_tasks.html)\n* [More about Gradle tasks](https://docs.gradle.org/current/userguide/more_about_tasks.html)\n* [Sample project](https://github.com/koral--/buildsrc-sample)" }, { "path": "androidweekly/功能测试框架 espresso/readme.md", "content": "功能测试框架 espresso\n---\n\n>\n* 原文链接 : [the-hitchhikers-guide-to-android-testing-part-2-espresso](http://wiebe-elsinga.com/blog/the-hitchhikers-guide-to-android-testing-part-2-espresso/)\n* 译者 : [Lollypo](https://github.com/Lollypo) \n* 校对者: [kang](https://github.com/tiiime)\n* 状态 : 校对完成\n\n![VtFd68Pr19fYk.](http://7xi8kj.com1.z0.glb.clouddn.com/VtFd68Pr19fYk.gif)\n\n正如[Ali Derbane](https://plus.google.com/+AliDerbane)和我写的第一篇关于Android的功能测试的文章中提到的，有许多的框架供你使用.\n在这个旅程的第二部分,我将讲解[Espresso](https://code.google.com/p/android-test-kit/)这个功能测试框架.\n\n\n### 简介\n\nEspresso 是在2013年的 GTAC 上首次提出，目的是让开发人员能够快速地写出简洁，美观，可靠的 Android UI 测试。\n\nEspresso有以下几个通用组件:\n\n- “Espresso”类提供的“onView”和“onData”方法,仅可用于特定接口上测试最优数.\n- `ViewMatchers` 包含一个实现了`Matcher `接口的对象集合. 使用该类你可以收集或是检查View元素.例如,通过文本 “7” 获取一个View元素(Button).\n- `ViewActions` 包含了一组`viewAction`对象，储存了将要在View上执行的动作. 这些动作被传递给`ViewInteraction.perform`方法,也许包含更多的动作. For 例如, 点击一下View元素(Button).\n- `ViewAssertions` 包含`ViewAssertion`集合，用于对Views进行检查.\n\n举个例子说明一下，这些测试组件看起来就像下面这样:\n\n```java\nEspresso.onView(ViewMatchers.withText(\"7\")).perform(ViewActions.click());\nEspresso.onView(withId(R.id.result)).check(ViewAssertions.matches(ViewMatchers.withText(\"42\")));\n ```\n\n好消息，去年谷歌推出了集成Espresso的[Testing Support Library](https://developer.android.com/tools/support-library/index.html).因此，让我们通过实现Espresso开始吧.\n\n> 为了方便解释, 我们要编写一些测试用例来测试[Android calculator application](https://github.com/welsinga/sample_espresso/app)这个App. 先来实现一个测试“6”x“7”等于“42”是否正确的普通测试场景。\n\n\n\n### 定义test runner\n\n 使用Espresso我们首先需要定义这些测试用例。Espresso使用新的名为AndroidJUnitRunner的测试用例。该测试用例基于“InstrumentationTestRunner”和“GoogleInstrumentationTestRunner”,运行JUnit3和JUnit4来测试你的Android应用程序。\n\n首先将依赖项添加到你的`build.gradle`文件中, 这里假设你已经安装好了[Testing Support Library](https://developer.android.com/tools/support-library/index.html).\n\n ```gradle\n dependencies {\n androidTestCompile 'com.android.support.test:testing-support-lib:0.1'\n}\n```\n\n然后添加测试用例到你的`build.gradleandroid.defaultConfig`配置中 \n\n```gradle\ndefaultConfig {\n ...\n testInstrumentationRunner \"android.support.test.runner.AndroidJUnitRunner\"\n}\n```\n\n\n\n### 编写测试\n\n你可能已经想到了，测试类必须在`src\\androidTest\\com.example.package.tests`中.包com.example.package是在AndroidManifest文件中指定的属性.\n\n每一个测试类还必须继承抽象类`ActivityInstrumentationTestCase2`并且使用默认测试的 Activity 作为泛型.\n\n它还需要通过`super()`方法传递给父类.要使被测试的Activity被测试框架调用，只需要在setup方法中同步调用`getActivity()`方法.\n\n```java\npublic class FunctionalInstrumentationTest extends ActivityInstrumentationTestCase2 {\n\n public FunctionalInstrumentationTest() {\n super(ActivityToTest.class);\n }\n\n @Override\n protected void setUp() throws Exception {\n super.setUp();\n getActivity();\n }\n}\n```\n\n正如前面提到的,我们想要检查“6”x“7”是否等于“42”.\n\n```java\npublic void testAnswer_to_the_Ultimate_Question_of_Life_the_Universe_and_Everything() {\n onView(withText(\"7\")).perform(click());\n onView(withText(\"×\")).perform(click());\n onView(withText(\"6\")).perform(click());\n onView(withText(\"=\")).perform(click());\n\n onView(withId(R.id.resText)).check(matches(withText(\"42\")));\n }\n```\n\n你可能已经注意到,这个示例是使用静态导入.这样做完全是为了使代码更易于阅读.\n\n其他你可能会用到的操作:\n\n- `pressBack()`; to simulate the use of the “back” button,\n- `isDisplayed()`; to check if an element is being shown and\n- `scrollTo()`; to scroll to an element.\n- `pressBack()`; 模拟后退按钮\n- `isDisplayed()`; jian检查某个元素是否显示\n- `scrollTo()`; 滚动到另外一个元素\n\n\n### 运行测试\n\n现在我们做做有趣的,运行测试.这可以通过`gradle clean assembleDebug connectedAndroidTest`从命令行运行,或者使用Android Studio:\n\n1. 打开Run菜单 | Edit Configurations\n2. 添加一个新的Android Tests configuration\n3. 选择你需要测试的Module\n4. 定义我们的测试用例: `android.support.test.runner.AndroidJUnitRunner`\n\n![10OjZwNlstPj9e](http://7xi8kj.com1.z0.glb.clouddn.com/10OjZwNlstPj9e.gif)\n\n现在你对于Espresso有一些了解了。如果需要深入，可以浏览以下链接:\n\n- [Espresso website](https://code.google.com/p/android-test-kit/)\n- [Github repo corresponding to this article](https://github.com/welsinga/sample_espresso)\n- [General Espresso Github samples by Google](https://github.com/googlesamples/android-testing)\n" }, { "path": "androidweekly/在Android 5.0中使用JobScheduler/readme.md", "content": "在Android 5.0中使用JobScheduler\n---\n\n> * 原文链接 : [using-the-jobscheduler-api-on-android-lollipop](http://code.tutsplus.com/tutorials/using-the-jobscheduler-api-on-android-lollipop--cms-23562)\n> * 译者 : [Mr.Simple](https://github.com/bboyfeiyu)\n> * 校对者 : [Mr.Simple](https://github.com/bboyfeiyu)\n\n在这篇文章中，你会学习到在Android 5.0中如何使用JobScheduler API。JobScheduler API允许开发者在符合某些条件时创建执行在后台的任务。\n\n## 介绍\n在Android开发中，会存在这么些场景 : 你需要在稍后的某个时间点或者当满足某个特定的条件时执行一个任务，例如当设备接通电源适配器或者连接到WIFI。幸运的是在API 21 ( Android 5.0，即Lollipop )中，google提供了一个叫做JobScheduler API的新组件来处理这样的场景。\n\n当一系列预置的条件被满足时，JobScheduler API为你的应用执行一个操作。与AlarmManager不同的是这个执行时间是不确定的。除此之外，JobScheduler API允许同时执行多个任务。这允许你的应用执行某些指定的任务时不需要考虑时机控制引起的电池消耗。\n\n这篇文章中，你会学到关于JobScheduler API更多的东西以及在你的应用中用于运行一个简单的后台任务的JobService，这篇文章中所展示的代码你都可以在[github](https://github.com/tutsplus/Android-JobSchedulerAPI)中找到。\n\n## 1. 创建Job Service\n\n首先，你需要创建一个API最低为21的Android项目，因为JobScheduler是最近的版本才加入Android的，在写这篇文章的时候，它还没有兼容库支持。（译者注：截止目前已知一个兼容库 [JobSchedulerCompat](https://github.com/evant/JobSchedulerCompat)）\n\n假定你使用的是Android Studio,当你点击了创建项目的完成按钮之后，你会得到一个\"hello world\"的应用骨架。你要做的第一步就是创建一个新的java类。为了简单起见，让我们创建一个继承自JobService且名字为JobSchedulerService的类，这个类必须实现两个方法，分别是`onStartJob(JobParameters params) `和 `onStopJob(JobParameters params)`；\n\n```java\npublic class JobSchedulerService extends JobService {\n \n @Override\n public boolean onStartJob(JobParameters params) {\n \n return false;\n }\n \n @Override\n public boolean onStopJob(JobParameters params) {\n \n return false;\n }\n}\n```\n\n当任务开始时会执行`onStartJob(JobParameters params)`方法，因为这是系统用来触发已经被执行的任务。正如你所看到的，这个方法返回一个boolean值。如果返回值是false,系统假设这个方法返回时任务已经执行完毕。如果返回值是true,那么系统假定这个任务正要被执行，执行任务的重担就落在了你的肩上。当任务执行完毕时你需要调用`jobFinished(JobParameters params, boolean needsRescheduled)`来通知系统。\n\n当系统接收到一个取消请求时，系统会调用`onStopJob(JobParameters params)`方法取消正在等待执行的任务。很重要的一点是如果`onStartJob(JobParameters params)`返回false,那么系统假定在接收到一个取消请求时已经没有正在运行的任务。换句话说，`onStopJob(JobParameters params)`在这种情况下不会被调用。\n\n需要注意的是这个job service运行在你的主线程，这意味着你需要使用子线程，handler, 或者一个异步任务来运行耗时的操作以防止阻塞主线程。因为多线程技术已经超出了我们这篇文章的范围，让我们简单实现一个Handler来执行我们在JobSchedulerService定义的任务吧。\n\n```java\nprivate Handler mJobHandler = new Handler( new Handler.Callback() {\n \n @Override\n public boolean handleMessage( Message msg ) {\n Toast.makeText( getApplicationContext(), \n \"JobService task running\", Toast.LENGTH_SHORT )\n .show();\n jobFinished( (JobParameters) msg.obj, false );\n return true;\n }\n \n} );\n```\n\n在Handler中，你需要实现`handleMessage(Message msg)`方法来处理你的任务逻辑。在这个例子中，我们尽量保证例子简单，因此我们只在`handleMessage(Message msg)`中显示了一个Toast，这里就是你要写你的任务逻辑( 耗时操作 )的地方，比如同步数据等。\n\n当任务执行完毕之后，你需要调用`jobFinished(JobParameters params, boolean needsRescheduled)`来让系统知道这个任务已经结束，系统可以将下一个任务添加到队列中。如果你没有调用`jobFinished(JobParameters params, boolean needsRescheduled)`，你的任务只会执行一次，而应用中的其他任务就不会被执行。\n\n`jobFinished(JobParameters params, boolean needsRescheduled) `的两个参数中的params参数是从JobService的`onStartJob(JobParameters params)`的params传递过来的，needsRescheduled参数是让系统知道这个任务是否应该在最初的条件下被重复执行。这个boolean值很有用，因为它指明了你如何处理由于其他原因导致任务执行失败的情况，例如一个失败的网络请求调用。\n\n创建了Handler实例之后，你就可以实现`onStartJob(JobParameters params)` 和`onStopJob(JobParameters params)`方法来控制你的任务了。你可能已经注意到在下面的代码片段中`onStartJob(JobParameters params)`返回了true。这是因为你要通过Handler实例来控制你的操作，这意味着Handler的handleMessage方法的执行时间可能比`onStartJob(JobParameters params)`更长。返回true,你会让系统知道你会手动地调用`jobFinished(JobParameters params, boolean needsRescheduled)`方法。\n\n```java\n@Override\npublic boolean onStartJob(JobParameters params) {\n mJobHandler.sendMessage( Message.obtain( mJobHandler, 1, params ) );\n return true;\n}\n \n@Override\npublic boolean onStopJob(JobParameters params) {\n mJobHandler.removeMessages( 1 );\n return false;\n}\n```\n一旦你在Java部分做了上述工作之后，你需要到AndroidManifest.xml中添加一个service节点让你的应用拥有绑定和使用这个JobService的权限。\n\n```\n\n```\n \n## 2. 创建一个JobScheduler对象\n随着JobSchedulerService构建完毕，我们可以开始研究你的应用如何与JobScheduler API进行交互了。第一件要做的事就是你需要创建一个JobScheduler对象，在实例代码的MainActivity中我们通过`getSystemService( Context.JOB_SCHEDULER_SERVICE )`初始化了一个叫做mJobScheduler的JobScheduler对象。\n\n```java\nmJobScheduler = (JobScheduler) \n getSystemService( Context.JOB_SCHEDULER_SERVICE );\n``` \n当你想创建定时任务时，你可以使用`JobInfo.Builder`来构建一个JobInfo对象，然后传递给你的Service。JobInfo.Builder接收两个参数，第一个参数是你要运行的任务的标识符，第二个是这个Service组件的类名。\n\n```java\nJobInfo.Builder builder = new JobInfo.Builder( 1,\n new ComponentName( getPackageName(), \n JobSchedulerService.class.getName() ) );\n```\n \n\n这个builder允许你设置很多不同的选项来控制任务的执行。下面的代码片段就是展示了如何设置以使得你的任务可以每隔三秒运行一次。\n\n```java\nbuilder.setPeriodic( 3000 );\n```\n \n其他设置方法 : \n\n* setMinimumLatency(long minLatencyMillis): 这个函数能让你设置任务的延迟执行时间(单位是毫秒),这个函数与`setPeriodic(long time)`方法不兼容，如果这两个方法同时调用了就会引起异常；\n* setOverrideDeadline(long maxExecutionDelayMillis): \n这个方法让你可以设置任务最晚的延迟时间。如果到了规定的时间时其他条件还未满足，你的任务也会被启动。与`setMinimumLatency(long time)`一样，这个方法也会与`setPeriodic(long time)`不兼容，同时调用这两个方法会引发异常。\n* setPersisted(boolean isPersisted): \n这个方法告诉系统当你的设备重启之后你的任务是否还要继续执行。\n* setRequiredNetworkType(int networkType): \n这个方法让你这个任务只有在满足指定的网络条件时才会被执行。默认条件是JobInfo.NETWORK_TYPE_NONE，这意味着不管是否有网络这个任务都会被执行。另外两个可选类型，一种是JobInfo.NETWORK_TYPE_ANY，它表明需要任意一种网络才使得任务可以执行。另一种是JobInfo.NETWORK_TYPE_UNMETERED，它表示设备不是蜂窝网络( 比如在WIFI连接时 )时任务才会被执行。\n* setRequiresCharging(boolean requiresCharging): \n这个方法告诉你的应用，只有当设备在充电时这个任务才会被执行。\n* setRequiresDeviceIdle(boolean requiresDeviceIdle): \n这个方法告诉你的任务只有当用户没有在使用该设备且有一段时间没有使用时才会启动该任务。\n\n需要注意的是`setRequiredNetworkType(int networkType)`, `setRequiresCharging(boolean requireCharging)` 以及 `setRequiresDeviceIdle(boolean requireIdle)`这几个方法可能会使得你的任务无法执行，除非调用`setOverrideDeadline(long time)`设置了最大延迟时间，使得你的任务在未满足条件的情况下也会被执行。一旦你预置的条件被设置，你就可以构建一个JobInfo对象，然后通过如下所示的代码将它发送到你的JobScheduler中。\n\n```java\nif( mJobScheduler.schedule( builder.build() ) <= 0 ) {\n //If something goes wrong\n}\n```\n\n你可能注意到了，这个schedule方法会返回一个整型。如果schedule方法失败了，它会返回一个小于0的错误码。否则它会返回我们在JobInfo.Builder中定义的标识id。\n\n如果你的应用想停止某个任务，你可以调用JobScheduler对象的`cancel(int jobId)`来实现；如果你想取消所有的任务，你可以调用JobScheduler对象的`cancelAll()`来实现。\n\n```java\nmJobScheduler.cancelAll();\n```\n到了这里，你现在应该已经知道如何在你的应用中使用JobScheduler API来执行批量任务和后台操作了。\n\n## 结论\n这篇文章中，你学会了怎么实现一个使用Handler对象来运行后台任务的JobService子类，你也学会了如何使用JobInfo.Builder来设置JobService。掌握了这些之后，你可以在减少资源消耗的同时提升应用的效率。\n" }, { "path": "androidweekly/在Android调试模式中使用Stetho/README.md", "content": "#Stetho for Android debug builds only\n# 在Android调试模式中使用Stetho\n------\n\n - 原文链接:[在Android调试模式中使用Stetho][11]\n - 译者:[BillionWang](https://github.com/BillionWang)\n - 校对者:[chaossss](https://github.com/chaossss)\n - 状态:完成\n \n最近FaceBook发布了一个叫做[Stetho][2]的工具.这个工具是一个谷歌浏览器的开发者工具扩展 ，它可以用来检测你的应用。我发现这东西挺好用的，因为它还提供了访问应用中SQLite数据库的接口。很明显，这种类型的工具只应该在应用的调试模式中使用。接下来我们来看看怎么用这个工具。\n\n\n#添加依赖\n为了保证只在调试模式中使用Stetho，你可以添加一个调试编译依赖，而不是平时常用的普通依赖类型。\n\n depencencies {\n // your other dependencies here...\n debugCompile 'com.facebook.stetho:stetho:1.0.0'\n }\n\n#在调试模式中初始化Stetho\n\n现在我们在调试中使用Stetho。你会怎么做?当然使用牛逼闪闪的Android Gradle构建系统啦。创建一个源文件夹，目录结构为 src/debug/java。这个目录中的代码仅仅是用于调试模式。这个目录结构和src/main/java很像，因为构建模式就是用于应用程序的调试的。(这句话再想想)。然后添加一个[Stetho][5]主页上描述的 [Application][6]。\n\n import com.facebook.stetho.Stetho;\n \n public class MyDebugApplication extends MyApplication {\n @Override\n public void onCreate() {\n super.onCreate();\n Stetho.initialize(\n Stetho.newInitializerBuilder(this)\n .enableDumpapp(Stetho.defaultDumperPluginsProvider(this))\n .enableWebKitInspector(Stetho.defaultInspectorModulesProvider(this))\n .build());\n }\n }\n看清楚这个类是怎样继承一个已经有的MyApplication.类的。这样写的确很方便，因为你的应用里可能已经有一个application来进行其他的初始化了。如果你还没有一个application。你从android.app.Application.继承一个就行了。\n\n#激活我的调试应用\n\n\n最后一步，我们要做的工具是确保当前的应用的调试版本使用的是MyDebugApplication类。在这里我们用Gradle来验证。在src/debug文件夹中添加一个AndroidManifest.xml\n\n\n \n \n \n \n \n\n这个AndroidManifest.xml会合并到src/main中的主AndroidManifest.xml文件里，并且会替换标签中的android:name属性。这是因为我们特别添加上了tools:replace=\"android:name\"属性。真屌。\n\n\n现在当你启动程序的调试模式，[Stetho][8]就会被激活。如果你切换到发布版本，Stetho绝对不会被激活，也看不到它的任何痕迹。如果想要不丢人，程序员要保证软件没有BUG。\n\n\n#总结\n用Android Gradle构建系统，可以很容易的给你的应用添加更多的调试功能。这门手艺不仅可以用在[Stetho][10]上，还可以用于那些你希望仅仅在调试模式中添加的类库或者工具。\n\n\n [1]: https://github.com/facebook/stetho\n [2]: https://github.com/facebook/stetho\n [3]: http://developer.android.com/reference/android/app/Application.html\n [4]: https://github.com/facebook/stetho\n [5]: https://github.com/facebook/stetho\n [6]: http://developer.android.com/reference/android/app/Application.html\n [7]: https://github.com/facebook/stetho\n [8]: https://github.com/facebook/stetho\n [9]: https://github.com/facebook/stetho\n [10]: https://github.com/facebook/stetho\n [11]:http://littlerobots.nl/blog/stetho-for-android-debug-builds-only/\n" }, { "path": "androidweekly/安卓字体渲染器/readme.md", "content": "安卓字体渲染器\n---\n\n* 原文：[android font renderer](https://medium.com/@romainguy/androids-font-renderer-c368bbde87d9)\n* 译者：[7heaven](http://github.com/7heaven)\n* 校对者：\n* 状态：翻译完成\n\n\n\n任何一个有几年的客户端应用开发经验的开发者都会知道文本渲染有多复杂。至少我在2010年开始写libhwui(基于OpenGL的安卓2D绘制API)之前是这么认为的。在开始写libhwui后，我意识到如果试图用GPU来渲染文本会使文本渲染变得更复杂。\n\n##Text and Android\n\n##文本与安卓\n\n安卓的硬件加速字体渲染最开始是由Renderscript团队的一位同事编写的，后来经过了多位工程师的修改和优化，其中就包括我以及我的朋友Chet Haase。你可以很容易的找到很多关于如何用OpenGL渲染文本的教程。但是，大部分的这些文章都把重点放在游戏开发以及如何绕过一些复杂的问题上。\n\n下面的内容并非如小说般的通俗易懂,但我认为它能很容易地给开发者一个如何实现完整的基于GPU的文字渲染系统的总览。文章中同时也描述了几个容易实现的文本渲染的优化。\n\n通常用OpenGL渲染文本的方法是计算一张包含所有需要的字形的纹理集合。这通常是在离线状态下用一个非常复杂的打包算法来最大化的减小纹理集合的资源浪费。创建这样一个纹理集合需要预先知道哪些文本--包括字体、字号以及其他属性等--然后应用就可以在运行时使用这些字形。\n\n在安卓上用预先渲染的纹理显然不是一个可行的解决方案。UI组件无法预先得知哪些文本需要被渲染；部分应用甚至会在运行时加载自定义字体。这是个主要的约束，但是这仅仅是其中一个：\n\n* 必须在运行时建立字体缓存\n\n* 必须能处理数量巨大的字体\n\n* 必须能处理数量巨大的字形\n\n* 必须最大化地减小纹理浪费\n\n* 渲染速度必须够快\n\n* 在高端和低端机型上必须效果一致\n\n* 在任何驱动/GPU组合上都必须完美运行\n\n##实现字体渲染\n\n在我们研究底层OpenGL文字渲染是如何实现之前，我们先来看看应用中直接调用的上层接口。这些接口对理解libhwui如何工作是非常重要的。\n\n###文本接口\n\n应用中用来排版和绘制文本的主要API有4个：\n\n* android.widget.TextView，一个处理排版和渲染的控件\n\n* android.text.*，创建风格化文本和文本布局的类集合\n\n* android.graphics.Paint，文本测量\n\n* android.graphics.Canvas，文本渲染\n\nTextView以及android.text都是以Paint和Canvas为基础的顶层实现。在安卓3.0之前Paint和Canvas都是直接由[Skia](https://code.google.com/p/skia/)(软件渲染库)实现的顶层API，Skia提供一个抽象库叫[Freetype](http://www.freetype.org/),一个流行的开源字体光栅化器。\n\n>安卓软件文本渲染\n>![text rendering](http://img.my.csdn.net/uploads/201503/31/1427770402_6442.png)\n\n安卓4.4以后整个过程变得有点复杂。Paint和Canvas用一个叫TextLayoutCache的内部JNI接口来实现复杂的文本排版布局(CTL)。这个接口依赖于[Harfbuzz](http://www.freedesktop.org/wiki/Software/HarfBuzz/),这是一个开源的文字shaping引擎。TextLayoutCache接受字体和UTF-16编码的字符串输入，并输出一个包含了x，y坐标的字形标示列表。\n\nTextLayoutCache是处理非拉丁文字，包括阿拉伯文、希伯来文、泰文等的关键。这边我不详细解释关于TextLayoutCache和Harfbuzz是如何工作的。但是如果你想在你的应用中更好的支持非拉丁文字，我强烈建议你学习CTL(复杂文本排版布局)的相关知识。这个问题极少在讨论用OpenGL渲染文本的教程中提到。绘制文本会比单纯地从左到右一个接一个地摆放字形更复杂。部分语言，例如阿拉伯语，是从右到左排列的。泰文甚至需要把字形从上到下 或者从下到上排列。\n\n> Android hardware accelerated text rendering\n\n>安卓硬件加速文字渲染\n>![harware text rendering](http://img.my.csdn.net/uploads/201503/31/1427770402_8107.png)\n\n所有这些意味着当你调用Canvas.drawText()，不管是直接还是间接调用。OpenGL渲染器都不会接收到你发送的参数，而只是接收到一个字形标示以及x/y坐标的数组。\n\n###光栅化和缓存\n\n所有字体渲染的调用都要有字体的配合。字体用来缓存多个独立的字形。字形储存在一个缓存纹理上(一个缓存纹理可以包含不同字体的字形)。缓存纹理是用来存放多个缓存的重要对象：一个空的块列表、一个像素缓存、OpenGL纹理和顶点缓存(the mesh)。\n\n>缓存结构\n>![cache arch](http://img.my.csdn.net/uploads/201503/31/1427770403_5202.png)\n\n用来储存所有这些对象的数据结构很简单：\n\n* 字体储存在字体渲染器的一个LRU缓存中\n\n* 字形存放在每一个字体的映射集中(the key is the glyph identifier)\n\n* 缓存纹理用一个块链表来追踪剩余空间\n\n* 像素缓存为uint8 或者 uint32_t的数组(alpha以及RGB缓存)\n\n* mesh是一个包含x/y坐标和u/v坐标的顶点缓存\n\n* 纹理是一个GLunit句柄\n\n字体渲染器初始化的时候会创建两种类型的缓存纹理：alpha和 RGBA。Alpha纹理用来储存普通的字形；字体本身不包含颜色信息，所以我们只需要储存抗锯齿相关的信息。RGBA缓存用来储存emoji表情。\n\n字体渲染器会为每种类型的纹理创建多个针对不同尺寸的CacheTexture实例。缓存的尺寸在不同设备上不一样，下面是几个默认的尺寸(缓存的数量是硬编码的)：\n\n* 1024x512 alpha缓存\n* 2048x256 alpha缓存\n* 2048x256 alpha缓存\n* 2048x512 alpha缓存\n* 1024x512 RGBA缓存\n* 2048x256 RGBA缓存\n\nCacheTexture实例创建后，它下面的缓存并不会自动分配。字体渲染器会根据需要来分配，1024x512alpha缓存作为一个例外每次都会分配。\n\n字形会在纹理中被打包成多个列。当渲染器遇到一个没有缓存的字形时，它会要求上面列表中对应类型的CacheTexture缓存该字形。\n\n这时候上面提到的块列表就登场了。这个列表包含了给定缓存纹理的已分配空间加上可用空间。如果一个已存在的列可以容纳下某个字形，那么这个字形就会被添加到这个列的已占用空间的底部。\n\n如果所有的列都被占用，它便会在左边的剩余空间中创建一个新列。由于部分字体是等宽字体，渲染器会把每一个字形的宽度四舍五入到4的倍数(默认情况下)。打包并不是最优解，但是它提供了一个快速实现方法。\n\n所有储存在纹理中的字形都由一个空的一像素的边包围。这是为了避免在双线性过滤时需要对字体纹理进行人工干预处理。\n\n这边需要了解的一个重点是当文本在渲染的时候做了缩放变换，这些变换会被交给Skia/Freetype。这表示这些字形是以变换后的形态储存在缓存纹理中。这在提高渲染质量的同时造成性能损耗。幸运的是，文本很少做动画缩放，即使做了动画缩放也只影响到少部分的字形。我做了大量的测试也没有出现性能造成比较大影响的情况。\n\n粗体、斜体、文本x轴缩放(这边不是用canvas的变换矩阵来处理)、样式和线宽等属性也会影响字形的光栅化和储存。\n\n###光栅化代替方案\n\n有另外一种用GPU处理文本的方法。字形可以直接用顶点向量的方式渲染，但是这样开销非常大。我也稍微研究了一下有向距离场，但是简单的实现方式会导致精确度的问题(curves tend to become \"wobbly\").\n\n建议看一下[Glyphy](https://code.google.com/p/glyphy/)，这是一个由Harfbuzz的作者写的开源库，扩展了有向距离场技术并解决了精度的问题。我有一段时间没关注这个项目了，上次看的时候着色器开销在安卓上还是禁止的。\n\n###预缓存\n\n缓存字形是理所当然的，但是预缓存会更好一点。由于libhwui是一个延迟渲染器(和Skia的即时模式相反)，所有即将被绘制到屏幕上的字形在帧开始时都是预知的。在显示列表操作的排序过程中(批处理和合并)，字体渲染器会被要求尽可能多的预先缓存字形。\n\n这样做的主要优势是完全或者 最大化的避免纹理在两帧之前的上传数量。纹理上传是一个开销极大的操作，会导致CPU或者GPU的延迟。更严重的是，在部分GPU架构上帧间修改纹理会导致内存紧张。\n\nImaginationTech公司的PowerVR SGX 系列GPU用了一个很有意思的延迟tiling架构，但是会强制驱动保留一份帧间修改的纹理的备份。字体纹理是非常大的，如果不注意纹理上传问题很容易导致内存溢出。\n\nGoogle Play上的一款应用就出现了这个问题。这款应用是一个简单的计算器，包含多个有数学符号和数字的按钮。字体渲染器在第一帧渲染的时候内存溢出了。因为按钮是按顺序绘制的。每一个按钮的绘制都会触发纹理上传。以及对整个字体缓存的拷贝。系统没有足够的内存来维持这么多的缓存拷贝。\n\n###清理缓存\n\n缓存字形的纹理非常大，它们在部分情况下会被系统回收来把空间让给其他应用。\n\n当用户让应用进入后台的时候，系统会发送一条要求释放尽可能多内存的信息给应用。最显而易见的方式就是销毁最大得缓存纹理。在安卓系统上，所有除了第一个创建的缓存纹理（默认是1024x512）都被视为大型纹理。\n\n当所有缓存都没有任何剩余空间得时候，纹理也会被清理掉。字体渲染器用LRU来追踪字体，但不对它做任何操作。如果需要的话，可以选择清理相对使用较少的纹理，这样更加智能化。现在还没有证据证明这是必须的，但是这是一个潜在的优化策略。\n\n###批处理和合并\n\n安卓4.3引入了[批处理和合并](https://www.youtube.com/watch?v=vQZFaec9NpA)绘制操作，彻底降低了OpenGL驱动的指令问题数量，是一个很重要的优化策略。\n\n为了实现合并，字体渲染器在多个绘制请求上对文本几何结构进行缓存。每一个缓存纹理用于一个2048 quad的客户端数组(1 quad = 一个字形),他们共享一个索引缓存（在GPU中储存为一个VBO）。当libhwui内部发起一个绘制请求时，字体渲染器会为每一个字形获取一个mesh并把x/y坐标和u/v坐标写进去。mesh在批处理的最后或者在quad缓存满得时候被发送给GPU(由延迟显示列表系统中所描述)。有可能在渲染一个字符串的时候会有多个mesh，每个缓存纹理一个。\n\n这个优化策略容易实现，并且对性能提升有很大帮助。由于字体渲染器使用多个缓存纹理，导致字符串中的大部分字形一部分在一个纹理中，一部分在另一个纹理中。如果没有批处理/合并优化策略，每次字体渲染器需要切换不同缓存纹理的时候都会发起一个绘制请求给GPU。\n\n我用来测试字体渲染器的一个应用上就出现了这个问题。这个应用用不同的样式和尺寸渲染一个\"Hello world\"字符串。\"o\"字被储存在和其他字符不同的纹理中。这会导致字体渲染器先绘制\"hell\", 然后是\"o\",\"w\",\"o\", 最后是\"rld\"。一共五次绘制请求以及5次纹理绑定，但实际上只需要两个纹理。使用优化后，渲染器会先绘制\"hell w rld\"然后再同时绘制两个\"o\"。\n\n###优化纹理上传\n\n我之前提到字体渲染器在上传缓存纹理的时候会追踪每个纹理的dirty rectangle来尽可能地上传最少量的数据。但是这种方式有两个限制。\n\n首先，OpenGL ES 2.0不允许上传长方形的任意一个部分。glTexSubImage2D允许你指定纹理内部的长方形的x/y和宽高but it assumes that the stride of the data in main memory is the width of that rectangle.可以通过创建一个新的合适大小的CPU缓存来绕过这个问题，但是这就需要预先知道长方形的大小。\n\n一个妥协的办法是上传包含这个长方形的最小带宽的像素(smallest band of pixels)。由于带宽总是和纹理本身一样宽所以我们还是会浪费掉部分带宽，但是这总好过上传整个纹理。\n\n第二个问题是纹理上传是同步的。这会导致CPU长时间的停顿（多至一毫秒，取决于纹理大小、驱动和CPU）。这在预缓存正常工作的情况下并不是大问题，但是在使用大量文本的应用或者使用大量字形的语言(例如中文)的时候用户会感受到停顿。\n\nOpenGL ES 3.0提供了这两个问题的解决方案。用一个叫GL_UNPACK_ROW_LENGTH的像素储存新属性可以上传一个长方形的一部分。这个属性指定了幅度或者主内存中的原始数据。但请注意：这个属性会对当前的OpenGL上下文的全局状态造成影响。\n\n通过使用像素缓存对象或者PBO可以避免CPU停顿。类似于OpenGL中的其他缓存对象，PBO reside in the GPU but can be mapped in main memory.PBO有很多有趣的属性，但是其中最让我们关注的事它允许异步上传纹理。整个操作过程变成：\n\n```\nglMapBufferRange->把字形写入缓存->glUnmapBuffer->glPixlStorei(GL_UNPACK_ROW_LENGTH)->glTexSubImage2D\n```\n\n对glTexSubImage2D的调用现在会立刻返回而不会阻断渲染器。字体渲染器会同时把整个缓存映射到主内存中。虽然这不太可能导致性能问题，但是最好处理方式还是只映射更新缓存纹理所必须的那一部分。\n\n这两个OpenGL ES 3.0的优化策略[已经在安卓4.4中实现](https://plus.google.com/+RomainGuy/posts/9QSTyVCSoz3)\n\n###投影\n\n文本通常在渲染的时候会带上阴影。这是一个开销较大的操作。由于相邻的字形的阴影模糊会互相影响，字体渲染器无法预先对字形进行模糊化。实现模糊的方法很多，但为了减小每帧间的混合操作和纹理取样，投影会以纹理的形式储存并延续到多个帧。\n\n由于应用很容易让GPU超负荷，我们决定把模糊化交给CPU处理。最简单和高效的处理方法是使用RenderScript的C++ 接口。只需要几行代码and takes advantage of all the available cores.唯一需要注意的是初始化Renderscript的时候要指定RS_INIT_LOW_LATENCY标示来把操作交给CPU执行。\n\n###未来的优化策略？\n\n在我离开安卓团队前有一个优化策略我希望能够实现。文本预缓存，异步以及部分纹理更新都是相当重要的优化方式，但是字形的光栅化依然是一个开销极大的操作。在systrace里很容易看出来。(勾选gfx标签并找到precacheText事件)。\n\n一个简单的优化方法是在后台使用worker线程来执行字形光栅化。这种技巧在不渲染成OpenGL几何体的复杂路径光栅化上已经得到应用。\n\n文本渲染的批处理和合并也有潜在的提升空间。用来绘制文本的部分的颜色是以整体的形式发送给碎片着色器的。这降低了发送给GPU的顶点数据但是同时也导致了副作用，会产生不必要得批处理指令：一个批处理只能包含单色的文本。如果以顶点的属性方式储存会减少发送给GPU的批处理指令。\n\n###源码\n\n如果你需要深入研究字体渲染器的实现可以访问libhwui的[github地址](https://github.com/android/platform_frameworks_base/tree/master/libs/hwui)。大部分操作都在[FontRenderer.cpp](https://github.com/android/platform_frameworks_base/blob/master/libs/hwui/FontRenderer.cpp)中，所以你可以选择从这个类开始看。和它相关的类在[font/](https://github.com/android/platform_frameworks_base/tree/master/libs/hwui/font)的子文件夹中。[PixelBuffer.cpp](https://github.com/android/platform_frameworks_base/blob/master/libs/hwui/PixelBuffer.cpp)也非常有帮助。这是一个由CPU缓存(uint8_t数组)或者GPU缓存(PBO)支持的像素缓存的抽象类。\n\n你会发现源代码中有一些配置属性。这些属性在安卓的[性能调节](http://source.android.com/devices/tuning.html)文档中有描述。\n\n###题外话\n\n这篇文章仅仅是对安卓字体渲染器的简单介绍。还有很多实现的细节被我略过或者会出现在我其他的文章中。有问题请尽管提出。\n" }, { "path": "androidweekly/安卓的模糊视图/readme.md", "content": "安卓的模糊视图\n---\n\n>\n* 原文链接 : [A Blurring View for Android](http://developers.500px.com/2015/03/17/a-blurring-view-for-android.html)\n* 作者 : [Jun Luo](https://500px.com/junluo)\n* 译者 : [lvtea0105](https://github.com/lvtea0105) \n* 校对者: [bboyfeiyu](https://github.com/bboyfeiyu) \n* 校对者: [chaossss](https://github.com/chaossss) \n* 状态 : 校对完成\n\n\n\n\n模糊效果可以生动地表现出内容的层次感，当使用者关注重点内容，即便在模糊表面之下发生视差效果或者动态改变，也能够保持当前背景。 \n\n在IOS设备中，我们首先构造一个UIVisualEffectView,之后添加 visualEffectView 到view层，在view中可以进行动态的模糊。\n\n```java\nUIVisualEffect *blurEffect = [UIBlurEffect effectWithStyle:UIBlurEffectStyleLight];\n\nUIVisualEffectView *visualEffectView = [[UIVisualEffectView alloc] initWithEffect:blurEffect];\n```\n\n## 安卓中的表现形式\n\n我们在雅虎天气APP中确实看到了很好的模糊效果实例，但是根据 [Nicholas Pomepuy 的博客帖子](http://nicolaspomepuy.fr/blur-effect-for-android-design/)，然而，这个 App 是通过缓存一张预渲染的背景图片来实现图片虚化的。\n\n虽然这种方法非常有效，但是确实不符合我们的需求，在 [500px](https://500px.com/) 的APP中，图像通常是获得焦点的内容，而不仅仅是提供背景，这说明图像的变化很大且迅速，即便他们是在模糊层之下。在我们的[安卓APP](https://play.google.com/store/apps/details?id=com.fivehundredpx.viewer) 中即是一个恰当的例子：当用户滑动至下一页时，整排图片会以相反方向淡出，为了组成所需的模糊效果，适当地管理多个预渲染图是困难的。\n\n![](http://developers.500px.com/images/2015-03-17-500px-android-tour-blurring.png)\n\n## 一种绘制模糊视图的方法 ##\n\n我们需要的效果是，实时地模糊其下的视图，最终需要给界面的是模糊视图的一个 blurred view 引用。\n\n```java\nblurringView.setBlurredView(blurredView);\n```\n\n之后当blurred view 改变时，不管是因为内容改变（比如呈现新的图片）、view的变换还是处在动画过程，我们都要刷新 blurring view。\n\n```java\nblurringView.invalidate();\n```\n\n为了实现 blurring view, 我们需要继承 view类并重写 onDraw()方法来渲染模糊效果。\n\n```java\nprotected void onDraw(Canvas canvas) {\n super.onDraw(canvas);\n\n // Use the blurred view’s draw() method to draw on a private canvas.\n mBlurredView.draw(mBlurringCanvas);\n\n // Blur the bitmap backing the private canvas into mBlurredBitmap\n blur();\n\n // Draw mBlurredBitmap with transformations on the blurring view’s main canvas.\n canvas.save();\n canvas.translate(mBlurredView.getX() - getX(), mBlurredView.getY() - getY());\n canvas.scale(DOWNSAMPLE_FACTOR, DOWNSAMPLE_FACTOR);\n canvas.drawBitmap(mBlurredBitmap, 0, 0, null);\n canvas.restore();\n}\n```\n\n这里的关键点在于，当模糊视图重绘时，它使用blurred view 的draw()方法，模糊视图保持blurred view的引用，它绘制一个私有的，以bitmap作为背景的画布。\n\n```java\nmBlurredView.draw(mBlurringCanvas);\n```\n\n这种使用另一个视图的 draw（）方法，也适用于建立放大或者个性的UI界面，在其中，放大区域的内容是扩大的，而不是模糊的。\n\n根据 [Nicholas Pomepuy 讨论](http://nicolaspomepuy.fr/blur-effect-for-android-design/) 的想法，我们使用子采样和 [渲染脚本](http://developer.android.com/guide/topics/renderscript/compute.html) 进行快速绘制，当初始化blurring view的私有画布mBlurringCanvas 后，子采样就已经完成了。\n\n```java\nint scaledWidth = mBlurredView.getWidth() / DOWNSAMPLE_FACTOR;\nint scaledHeight = mBlurredView.getHeight() / DOWNSAMPLE_FACTOR;\n\nmBitmapToBlur = Bitmap.createBitmap(scaledWidth, scaledHeight, Bitmap.Config.ARGB_8888);\nmBlurringCanvas = new Canvas(mBitmapToBlur);\n```\n\n通过mBlurringCanvas的 建立与恰当的渲染脚本初始化，重绘时的blur()方法如下：\n\n```java\nmBlurInput.copyFrom(mBitmapToBlur);\nmBlurScript.setInput(mBlurInput);\nmBlurScript.forEach(mBlurOutput);\nmBlurOutput.copyTo(mBlurredBitmap);\n```\n\n此时 mBlurredBitmap 已准备好，剩下的就是使用适当的变换和缩放，在blurring view自己的画布上重绘视图。\n\n## 实现细节\n\n完整实现blurring view 时，我们需要注意几个技术点：\n\n一：我们发现缩放因子8，模糊半径15 很好地满足我们的目标，但满足你需求的参数可能是不同的。\n\n二：在模糊的bitmap边缘会遇到一些渲染脚本效果，我们将缩放的宽度和高度进行了圆角化，直到最近的4的倍数。\n\n```java\n// The rounding-off here is for suppressing RenderScript artifacts at the edge.\nscaledWidth = scaledWidth - (scaledWidth % 4) + 4;\nscaledHeight = scaledHeight - (scaledHeight % 4) + 4;\n```\n\n三：为了保证更好的表现效果，我们新建两个bitmap对象——mBitmapToBlur 和 mBlurredBitmap ，\nmBitmapToBlur 位于私有画布mBlurringCanvas 之下， mBlurredBitmap 仅当blurred view的大小变化时才重新建立他们；\n同样地当blurred view的大小改变时，我们才创建渲染脚本对象mBlurInput 和 mBlurOutput。\n\n四：我们以with PorterDuff.Mode.OVERLAY 模式绘制一个白色半透明的层，它处在被模糊的的图片上层。用来处理设计需求中的淡化。\n\n最后，因为RenderScript（渲染脚本）至少在API 17 上才可用，我们需要降低旧版本的安卓，糟糕的是，[Nicholas Pomepuy帖子](http://nicolaspomepuy.fr/blur-effect-for-android-design/) 中提到的Java bitmap的模糊方法，当恰当地预渲染缓存副本时，对于实时渲染不够迅速，我们所做的是使用一个半透明的view作为回调。(更新于2015年3月23日：通过使用 [RenderScript 库](http://android-developers.blogspot.ca/2013/09/renderscript-in-android-support-library.html)，我的解决方法能在更低版本的 API 中运行。下面提及的库和 Demo 都更新了，非常感谢 GitHub 上的小伙伴 [panzerdev](https://github.com/panzerdev) 告诉我这一点）\n\n## 优点和缺点\n\n我们喜欢这个view的绘制方法，因为它可以实时模糊并且容易使用，使得blurred view 的内容，也在blurring view 和blurred view中间保证了灵活性，最重要的是，它满足了我们的需求\n\n这个方法确实使得blurring view 与适当协同变换的 blurred view 保持了私有联系，相关地，模糊视图必须不能是blurred view的子类，否则会因为互相调用造成堆栈溢出。简单有效处理此限制的方法是要保证模糊视图与blurred view 在同级，并且Z轴次序上 blurred view 在blurring view 之前。\n\n另一点需要注意的限制是，由于与 矢量图形和文本 有关，我们默认的bitmap削减采样表现效果不是很好。\n\n## 库文件和示例\n\n你可以在我们的安卓 [APP](https://play.google.com/store/apps/details?id=com.fivehundredpx.viewer) 上看到解决方法，我们也把开源的库文件连同一个示例分享到了 [github](https://github.com/500px/500px-android-blur)，它能够展示内容变换、动画和视图变换。\n\n![](https://github.com/500px/500px-android-blur/raw/master/blurdemo.gif)\n\n有关这个效果在 [HackNews](https://news.ycombinator.com/item?id=9219097) 中的讨论" }, { "path": "androidweekly/欢迎来到Android多进程时代/readme.md", "content": "欢迎来到Android多进程时代\n---\n\n>\n* 原文标题 : Going multiprocess on Android\n* 原文链接 : [Going multiprocess on Android](https://medium.com/@rotxed/going-multiprocess-on-android-52975ed8863c)\n* 译者 : [Lollypo](https://github.com/Lollypo) \n* 校对者: [Mr.Simple](https://github.com/bboyfeiyu) \n* 状态 : 完成\n\n###That moment when one Dalvik alone is no longer enough.\n\n\n生活在内存限制中\n---\n\n有很多方面使得Android成为一个独特的移动平台操作系统，但有时候却让人觉得难以融入，特别是从开发人员的角度看。\n\n例如,把内存限制。iOS应用程序提供几乎没有限制的内存预算(200 MB不是什么大不了的事),Android有严重的局限性,从最近设备的24/32/48 MB以及旧设备极小的16 MB便可以看出。\n\nRAM预算就是一切你的应用运行时所能获得的全部了，这意味着，它必须满足加载类、线程、服务、资源和你的应用程序想要显示的内容。想象一个通过网格视图展示优美图片的照片浏览应用,或一个需要在后台播放的音乐播放器:这太恐怖了\n\n> 那时候你的体会应该是这样的\n\n![Life’s a bitch, sometimes.](http://7xi8kj.com1.z0.glb.clouddn.com/img01.gif)\n\n要理解为什么Android提出了这些限制以及提供了什么解决方案来应对他们,我们需要知道一点点在这背后之后发生了些什么。\n\n理解Android进程\n---\n\n你应该已经知道了,安卓系统是基于Linux的。因此,每个应用程序都运行在其本身的进程(拥有一个独一无二的PID)中:这允许应用运行在一个相互隔离的环境中,不能被其他应用程序/进程干扰。通常来说,当你想启动一个应用程序,Android创建一个进程(从Zygote中fork出来的),并创建一个主线程，然后开始运行Main Activity。\n\n你可能不知道的是,你可以指定应用程序的一些组件运行在不同的进程中，而不是那个被用于启动应用程序的。先来看一下这个Nice的属性:\n
\n```xml\nandroid:process\n```\n
\n\n该进程属性可用于activities、services、content providers和broadcast receivers 和指定的进程中应该执行的特定组件。\n\n在这个例子中,我指定MusicService必须执行在一个单独的“music”的进程:\n```xml\n\n \n \n \n \n \n\n```\n\n它有什么意义呢?\n\n在这个简短的介绍中，我提到了每一个Android应用程序在运行的时候都有一个不能超出的内存预算值。更精确的说，这限制了它只能在单个基础的进程上运行。换句话说，应用程序的每一个进程都将会有一个专门的内存预算(更不用说其中止时也有更酷的不同的规则)\n\n让我们看看这种方法将是一件好事还是坏事。(剧透:两者都是)\n\n使用多进程有啥好处\n---\n\n正如我刚才提到的,一个独立的进程可以充分利用自己的RAM预算,使其主进程拥有更多的空间处理资源。\n\n此外，操作系统对待运行在不同组件中的进程是不一样的。这意味着，当系统运行在低可用内存的条件时，并不是所有的进程都会被杀死。想象一下：你的音乐播放器正在后台运行，音乐突然播放，系统需要释放一些内存(因为facebook,这就是原因)。由于播放音乐的服务跑在另一个进程中，一种极为可能的情况就是操作系统将会先杀死你的主进程(那个运行着你的UI的)，而留下那个在另一个进程播放音乐的。\n\n最后一点对于用户来说看起来似乎很不错！因为你的程序的每一个进程都有自身的在应用程序管理器上的屏幕显示RAM用度。其中有一个或多个将出现在“缓存”部分(这意味着它们是不活跃的)。\n\n> 正如你所看到的,Spotify在后台播放一些音乐。有一个活跃的带有服务的进程 [上图]，而另一个进程(持有UI的)是缓存状态的，因为不再可见/不活动的[下图]。\n\n![](http://7xi8kj.com1.z0.glb.clouddn.com/img02.png)\n![](http://7xi8kj.com1.z0.glb.clouddn.com/img03.png)\n\n\n使用多进程时的那些坑 \n---\n\n不幸的是,坑有很多。事实上,你要学习拥有多个进程不是一下子就能完成的事\n\n首先,进程是被设计成独立的(如安全特性),这意味着每一个进程将有自己的Dalvik VM实例。反过来,这意味着你不能通过这些实例共享数据,至少不是传统意义上的。例如,静态字段在每个进程都有自己的值,而不是你倾向于相信的只有一个值。并且这延伸到应用程序每一个的状态。\n\n这是否意味着两个独立的进程之间互相交流是不可能的吗?不,实际上是可能的,有几种方法可以做到。最值得注意的是,Intent可以跨进程“旅行”,Handlers和Messengers也可以。。你也可以依靠AIDL(Android接口定义语言)和Binder,和你通常声明一个bound service茶不错(但你可以做更多的事!)。\n\n我需要使用多进程吗\n---\n\n当然,这取决于你需要查看到的迹象。如果你的用户正在经历越来越频繁OutOfMemory错误或者他们抱怨你的应用程序是极其消耗RAM,你可能需要考虑使用一个或多个独立的进程。\n\n音乐播放器的例子是第二个进程能使你的App做的更好的其中最常见的一个场景，当然，还有更多。\n例如,你的应用程序是一个客户端云存储服务：委托同步服务组件专用的进程似乎是完全合理的，所以即使UI会被系统杀死，服务仍然可以运行并且保持文件更新。\n\n> 类似的情况会发生在你第一次真正意识到进程隔离的意思时\n\n![This happens when you first realize what “isolation between processes” really means.](http://7xi8kj.com1.z0.glb.clouddn.com/img04.gif)\n\n如果你认为你需要它,那么我建议你先玩一个小试验台应用:只有通过实际体验过使用多个进程的优势和其内在的复杂性，你才能够决定你是否真的需要它,如果是这样,什么是最好的处理它的方式而不至于把我们逼疯。\n\n结语\n---\n\n我知道我仅仅触及到这个问题的表面，我只是想给你一些实用的建议，而不是告诉你在操作系统层调控进程的全部理论与工作机制。\n\n还是那句话，如果你对此感兴趣并愿意深入其中，那就留言让我知道！同时，不要忘记文档是你最好的朋友[[1]](http://developer.android.com/guide/components/processes-and-threads.html#Processes) [[2]](https://developer.android.com/training/articles/memory.html) [[3]](https://developer.android.com/tools/debugging/debugging-memory.html)" }, { "path": "androidweekly/深入了解Android Graphics Pipeline-part-1/readme.md", "content": "深入了解Android Graphics Pipeline-part-1\n---\n\n* 原文链接 : [Android Graphics Pipeline: From Button to Framebuffer (Part 1)](https://blog.inovex.de/android-graphics-pipeline-from-button-to-framebuffer-part-1/)\n* 作者 : [mgarbe](https://blog.inovex.de/author/mgarbe/)\n* 译者 : [dupengwei](https://github.com/dupengwei) \n* 校对者: [chaossss](https://github.com/chaossss) \n* 状态 : 完成 \n\n\n\n在这个小型博文系列中我们想给有兴趣研究 Android Graphics Pipeline 内部结构的开发者带来一些启发。在此主题上，Google自己也发布了一些见解和文档，如由Chet Haase 和 Romain Guy主持的Google I/O 2012演讲[For Butter or Worse](https://www.youtube.com/watch?v=Q8m9sHdyXnE) (如果没看过就去看看吧!) 和文章 [Graphics architecture](http://source.android.com/devices/graphics/architecture.html) 。虽然这些资料肯定能帮助我们从宏观上理解一个简单的view是如何显示在屏幕上，但是当我们尝试去理解背后的源代码时，这些对我们的帮助并不大。本系列博文将带你走进Android Graphics Pipeline这个有趣的世界。\n\n请注意，本小型系列博文中会涉及大量的源代码和序列图！它值得一读，就算你对Android Graphics Pipeline一点兴趣也没有，你也可以学到很多（或者你至少看看这些漂亮的图片）。所以给自己一杯咖啡，读吧！\n\n## 引言\n\n为了充分理解view显示到屏幕的过程，我们采用一个小Demo来描述Android Graphics Pipeline的每个主要阶段，由Android Java API (SDK)开始，然后是本地C++代码，最后看原始的OpenGL绘图操作。\n\n\n![one-button-layout-cropped](http://img.my.csdn.net/uploads/201504/09/1428538541_6558.png)\n\n这个 Demo 非常值得我们研究，因为这个不起眼的 App 的代码就能充分覆盖整个 Android Graphics 的内部结构，所以，它实际上是一个相当好的例子。\n\n这个activity由一个简单 RelativeLayout，一个带应用图标和标题 ActionBar 和一个读作“Hello world!”的简单 Button 组成。\n\n![one-button-viewhierarchy](http://img.my.csdn.net/uploads/201504/09/1428538541_8737.png)\n\n但从上图你也可以看到，我们这个简单的 Demo 的视图层实际上是相当复杂。\n\n在Android 视图层内部，相对布局（RelativeLayout）由一个简单的颜色渐变背景组成。更复杂的， Actionbar 由一个渐变的背景结合一个bitmap，**One Button** 文本元素和应用图标（也是一个bitmap）组成。9-Patch用作按钮的背景，文本 **Hello World!** 画在它的最上层。屏幕顶部的导航栏和底部的状态栏不属于 App 的 Activity 部分，它们由系统服务`SystemUI`进行渲染。\n\n## Pipeline概述\n\n如果有看过Google I/O演讲**For Butter or Worse**，你肯定认识下面的幻灯片，因为它它显示了完整的 Android Graphics Pipeline 结构。\n\n![pipeline](http://img.my.csdn.net/uploads/201504/09/1428538607_4861.png)\n\n上图就是在 Google 在 Google I/O 2012 大会中提供的完整的 Android Graphics Pipeline 结构。\n\nSurface Flinger负责创建图形缓冲区并将其合成到主显示器，虽然这对应安卓系统非常重要，但是在此不作赘述。\n\n相反，我们将注意力放在其他组件上，因为这些组件的主要任务就是将view显示到屏幕上。\n\n![interesting_bits](http://img.my.csdn.net/uploads/201504/09/1428538541_4202.png)\n\n## Display Lists\n\n可能你已经知道，Android 使用一个叫做 DisplayLists 的概念去渲染所有的view。对于不知道的人来说，display list是一个绘图命令序列集合，需要执行这些命令去渲染指定的view。display lists是Android Graphics Pipeline达到高性能的重要元素。\n\n\n![display-lists](http://img.my.csdn.net/uploads/201504/09/1428538540_9146.png)\n\n每个视图层的 view 都有其对应的 display list，每个开发者都知道 `onDraw()` 方法，这个 display list 就是由 view 的 `onDraw()` 方法生成的。为了将视图层画到屏幕上，只有 display lists 需要被评估并执行。假如某个单一 view 失效（因用户输入、动画或转换），受影响的 display lists 将会重建和重绘。这就避免Android在每个frame层调用相当耗费资源的 `onDraw()`。\n\nDisplay lists can also be nested, meaning that a display list can issue a command to draw a childrens display list. This is important in order to be able to reproduce view hierarchies with display lists. After all, even our simple app has multiple nested views.\n\nDisplay lists 也可以被嵌套，这意味着一个Display list也可以发出一个命令绘制一个子display list。这对复制视图层的display lists来说非常重要。毕竟，即使是最简单的 App 也会具有多个嵌套视图。\n\n这些命令的语句的可以直接映射到OpenGL命令，如翻译和设置剪辑矩阵，或更复杂的命令如`DrawText` 和 `DrawPatch`，但这些复杂命令需要相应的OpenGL命令集，不然我们也无法使用。\n\n`An example of a display list for a button.`\n\n`一个按钮的display list示例`\n\n```java\nSave 3\nDrawPatch\nSave 3\nClipRect 20.00, 4.00, 99.00, 44.00, 1\nTranslate 20.00, 12.00\nDrawText 9, 18, 9, 0.00, 19.00, 0x17e898\nRestore\nRestoreToCount 0\n```\n\n在上面的示例中，你可以清楚地看到 display list 为绘制一个简单的按钮进行了什么操作。第一个操作是保存当前翻译矩阵到栈中，使得它随后可以被恢复。然后又画了9-Patch按钮，接下来是另外一个保存命令，这是必要的，因为对于要绘制的文本来说，只有绘制文本的区域才会创建裁剪矩阵。手机绘图处理器将此矩形区域当做一个线索以便在后续阶段对绘图调用进一步优化。然后将绘画圆点转换到文本位置，并绘制文本。最后，最初的转换矩阵和状态从堆中还原，裁剪矩阵也被重置。\n\n在这篇文章的底部可以看到示例用的的display lists的完整日志。\n\n## 深入代码\n\n带着这些新获取的知识，我们准备深入研究代码。\n\n### 根视图（Root View）\n\n每个Android activity在视图层的最顶层都有一个隐式根视图（Root View），包含一个子view。这个子view是程序员在应用中定义的第一个真正的view。根视图负责调度和执行多种操作，如绘图，使view无效等等。\n\n类似的，每个view都有一个parent的引用。视图层内部的第一个view将根视图作为parent。虽然View类作为每个可视化的元素或组件的基类，但是它并不支持任何子类。然而，其派生类ViewGroup支持多子类，并作为一个容器基类，它已经被标准布局（RelativeLayout 等等)所采用。\n\n如果一个view局部重绘，那么该view会调用根视图的invalidateChildInParent()方法。根视图跟踪所有重绘的区域，并在choreographer调度一个新的遍历，choreographer会在下一个VSync事件执行。\n\n![view-invalidate](http://img.my.csdn.net/uploads/201504/09/1428538608_9350.png)\n\nViewRoot: InvalidateChildInParent(…)\n\n```java\npublic ViewParent invalidateChildInParent(int[] location, Rect dirty) {\n // Add the new dirty rect to the current one\n mDirty.union(dirty.left, dirty.top, \n dirty.right, dirty.bottom);\n // Already scheduled?\n if (!mWillDrawSoon) {\n scheduleTraversals();\n }\n return null;\n}\n```\n\n## 创建Display Lists\n\nAs previously mentioned, each view is responsible to generate its own display list. When a VSync event is fired and the choreographer called performTraversals on the root view, the HardwareRenderer is asked to draw the view, which in turn will ask the view to generate its display list.\n\n正如刚刚提到的，每个view负责生产自己的display list。当一个VSync事件被触发，choreographer调用根视图的`performTraversals`方法，根视图要求`HardwareRenderer`绘制view，`HardwareRenderer`反过来要求view生成自己的display list。\n\n![perform-traversals1](http://img.my.csdn.net/uploads/201504/09/1428538542_9748.png)\n\n在Android framework层中，View是其中一个比较大的类，当前代码量将近20000行。这并不令人惊奇，因为它是每个小组件和应用的构建块。它处理键盘、轨迹球、触摸事件,以及滚动,滚动条,布局和测量,还有很多很多。\n\n![view-getdisplaylist](http://img.my.csdn.net/uploads/201504/09/1428538608_4788.png)\n\n`View.getDisplayList(…)`方法被Hardware Renderer调用时将会创建一个内部的display list，这个内部display list将会在view生命周期的剩余部分被使用。然后这个内部display list被要求提供一个足够大的画布来容纳这个view。并提供一个GLES20RecordingCanvas，所有view和它的children将会在上面绘图，然后传递给`draw(…)`方法。这个画布有点特殊，因为它不执行绘图命令，而是保存命令到display list。这意味着小组件和每个view能使用正常的绘图API，甚至无须关注display list内部的命令\n\n`View: getDisplayList(…)`\n```java\nprivate DisplayList getDisplayList(DisplayList displayList, \n boolean isLayer) {\n HardwareCanvas canvas = displayList.start(width, height);\n if (!isLayer && layerType != LAYER_TYPE_NONE) {\n // Layers don't get drawn via a display list\n } else {\n draw(canvas);\n }\n return displayList;\n}\n```\n\n在`draw(…)`方法中，view将执行`onDraw()`方法的代码，渲染自己到画布上。如果这个view有任何children，children各自调用`draw()`方法。这些children可以是任何东西，可以是一个正常的按钮，也可以是一个布局或view group，这些children包含另外的children，都将被绘制。\n\n![view-draw](http://img.my.csdn.net/uploads/201504/09/1428538608_8013.png)\n\n## 寄语\n\n伴随着display list的产生，part 1结束了。如果你对这系列博文有兴趣的话，请关注 part 2,届时我们会知道 display lists 将如何被呈现在屏幕上!\n\n## 下载\n\nThe full Bachelor’s Thesis on which this article is based is available for download.\n\n本文参考的所有学士论文可供[下载](http://mathias-garbe.de/files/introduction-android-graphics.pdf)\n\n\n\n\n\n" }, { "path": "androidweekly/深入了解Android Graphics Pipeline-part-2/readme.md", "content": "深入了解Android Graphics Pipeline-part-2\n---\n\n>\n* 原文链接 : [Android Graphics Pipeline: From Button to Framebuffer (Part 2)](https://blog.inovex.de/android-graphics-pipeline-from-button-to-framebuffer-part-2/)\n* 作者 : [Mathias Garbe](https://blog.inovex.de/author/mgarbe/)\n* 译者 : [chaossss](https://github.com/chaossss) \n* 校对者: [Mr.Simple](https://github.com/bboyfeiyu) \n* 状态 : 完成 \n\n\n\n\n在上一篇博文中，我们图文结合介绍了 Android 怎么把 onDraw() 方法的 Java 代码转换为 Native 层的 C/C++ 代码。而今天，我们会承接上一篇博文讲的内容，继续探索 Android 在 Native 层是如何通过 C/C++ 代码绘制屏幕上的各种元素（控件、动画等）。在开始讲解之前，我需要提前提醒大家：要深入到 Native 层中研究 C/C++ 代码对 Java 代码的实现，意味着我们从此刻开始要忘掉 Java 安逸的垃圾回收机制，并忍受 C/C++ 代码带来的各种令人蛋疼的内存管理问题。不过大家不必惶恐，我会尽可能简单地讲解今天的内容，而且只会展示与我们今天的内容有关的有趣代码。\n\n## 绘制元素 ##\n\n在 Android 4.3 之前，UI 的绘制流程和将 UI 元素添加到相应 View 层级的顺序相同，并将它们添加到 display list 中。但这里存在一个很严重的问题，这样的渲染流程会不断进入 GPU 最糟糕的使用场景，原因在于：这样的绘制流程会导致在绘制不同的控件时，需要不断地切换状态。举例来说吧，我们现在要绘制两个 Button，那么 GPU 就需要先绘制第一个 Button 的背景和文字，绘制完成后再对第二个 Button 做同样的操作，渲染流程结束后，至少进行了三次的状态改变。\n\n## 重新设计绘制流程 ##\n\n所以为了最小化状态切换带来的 GPU 开销，Android 基于 UI 元素的类型和状态重新设计了相应的绘制流程。不过在接着讲解之前我们要暂时放下“界面中只有一个 Button ”的例子，并随便找一个 Activity 先进行相关知识的介绍。\n\n![](https://blog.inovex.de/wp-content/uploads/2015/03/merging-layout-anot-300x215.png)\n\n> 示例 Activity 包含了许多重叠的元素，我们这样做的目的是：通过使用极端的例子模拟各种可能出现的情况，解释为什么绘制时会产生这些问题，以及对应的解决策略。\n\n如你所见，简单地根据 UI 的元素类型重新设计绘制流程在大多数情况下都不能满足我们的需求，原因在于：无论是先绘制所有文字，再绘制图片；还是先绘制图片，再绘制文字，都不能获得我们我们真正想要的 UI，因为总有一些该显示的 UI 元素会因为绘制顺序被挡住，我相信任何一个有品位的 UI 设计师都不会接受这样的客户端。\n\n为了能正确地渲染示例 Activity 的 UI，UI 中的文字元素 A 和 B 必须先被绘制，然后绘制图片元素 C，最后是文字元素 D。由于 A 和 B 是同类型的元素，所以我们可以同时进行 A 和 B的绘制，但 C 和 D 只能按照顺序绘制，不然又会产生 UI 元素的覆盖问题。\n\n为了更好地优化 UI 每一个 View 层级的绘制流程，在重新设计了绘制顺序后，就要将类似的绘制操作合并。合并在 DeferredDisplayList 中执行，给这个函数取这个名字是因为绘制操作没有按序执行，而是在所有操作的分析，重排序，合并完成前，不断地延迟其绘制动作，直到分析，重排序，合并完成才按序绘制。\n\n由于每一个 display list 的绘制操作只能用于绘制它自身，如果一个操作支持把相同类型的元素的多个操作合并，那这个操作必须能被用于绘制多个具有相同类型的不同页面。但你需要注意的是，这不意味每一个操作都能进行合并，在新的设计里还留有许多只能重排序的操作。\n\n![](https://blog.inovex.de/wp-content/uploads/2015/03/canvas-drawdisplaylist-1024x594.png)\n\nOpenGLRenderer 是 Skia 2D 图像绘制 API 的一个接口，与常见的接口不同，它不需要利用 CPU 进行硬件加速，而是用 OpenGL 完成了所有硬件加速的工作。虽然有很多办法能完成这样的工作，但是 OpenGLRenderer 是第一个用 C++ 实现的本地类。OpenGLRenderer 在 Android 3.0 中被提出，设计它主要是让它和 GLES20Canvas 协作，绘制我们想要的界面元素。有趣的是，在界面绘制的操作中，只有它们是以协作的形式进行的。\n\n为了把多个操作合并到一个绘制操作中，每一个操作都通过调用 addDrawOp() 方法被添加到 deferred display list 中。同时，绘制操作还需要提供 batchId，因为绘制操作必须知道这个类型的操作能否被合并，此外，绘制操作还需要通过调用 DrawOp.onDefer(...) 方法提供 mergeId,以指明哪些操作已经被合并.\n\n一般 batchId 包含了一个简单的枚举，主要是为 9-Patch 图片元素提供 OpBatch_Patch，并为普通的文字元素提供 OpBatch_Text。mergeId 的值由 DrawOpitself 决定，用于判断两个具有相同的 DrawOp 类型的操作能否被合并。对 9-Patch 图片元素来说，mergeId 用于指向图片资源文件，对文字元素来说，则是对应的文字颜色。来自同一个资源文件夹的资源文件可能会被合并到同一个 batch 中，帮助我们大量地节约绘制流程带来时间开销。\n\n有关一个操作的所有信息都被归并到一个简单的结构中，代码如下：\n\n```java\n\tstruct DeferInfo {\n\t // Type of operation (TextView, Button, etc.)\n\t\t// batchId 注明被操作的 UI 元素的类型（如 TextView，Button等……）\n\t int batchId;\n\t \n\t // State of operation (Text size, font, color, etc.)\n\t // mergeId 注明被操作的 UI 元素的状态（如 文字大小，字体，文字颜色等……）\n\t mergeid_t mergeId;\n\t \n\t // Indicates if operation is mergable\n\t // 标记操作是否可被合并\n\t bool mergeable;\n\t};\n```\n\n当一个绘制操作的 batchId 和 mergeId 被确定，如果它还没有被合并，就会被添加到 batch 队列的尾部。如果没有可用的 batch，我们就会创建一个新的 batch。不过一般情况下，这些绘制操作都是可以合并的。为了知道每一个最近合并的 batch 的去向，我们会通过一个简化的算法调用 MergeBatches 的实例 hashmap，用 batchId 构建键值对保存相应的 batch。对每一个 batch 使用 hashmap 能避免使用 mergeId 导致的冲突。\n\n```java\n\tvector batches;\n\tHashmap mergingBatches[BatchTypeCount];\n\t \n\tvoid DeferredDisplayList::addDrawOp(DrawOp op):\n\t DeferInfo info;\n\t /* DrawOp fills DeferInfo with its mergeId and batchId */\n\t /* DrawOp 方法用 mergeId 和 batchId 填充 DeferInfo */\n\t op.onDefer(info);\n\t \n\t if(/* op is not mergeable */):\n\t /* Add Op to last added Batch with same batchId, if first\n\t op then create a new Batch */\n\t /* 将 Op 添加到最后被添加入元素的 Batch 中，但这个 Batch 必须与 Op 具有相同 batchId，此外，如果 op 是 Batch 中的第一个元素，那么需要新建一个 Batch */\n\n\t return; \n\t \n\t DrawBatch batch = NULL;\n\t if(batches.isEmpty() == false):\n\t batch = mergingBatches[info.batchId].get(info.mergeId);\n\t if(batch != NULL && /* Op can merge with batch */):\n\t batch.add(op);\n\t mergingBatches[info.batchId].put(info.mergeId, batch);\n\t return;\n\t \n\t /* Op can not merge with batch due to different states,\n\t flags or bounds */\n\t /* 如果 Op 与 Batch 具有不同的状态，标记，和边界，那么 Op 将无法被合并到 Batch 中 */\n\n\t int newBatchIndex = batches.size();\n\t for(overBatch in batches.reverse()):\n\t if (overBatch == batch):\n\t /* No intersection as we found our own batch */\n\t /* Batch 之间应该没有交集 */\n\n\t break;\n\t \n\t if(overBatch.batchId == info.batchId):\n\t /* Save position of similar batches to insert \n\t after (reordering) */\n\t /* 在重排序后保存 batchId 相同的 batch 中对应的位置，便于后面插入元素 */\n\n\t newBatchIndex == iterationIndex;\n\t \n\t if(overBatch.intersects(localBounds)):\n\t /* We can not merge due to intersection */\n\t /* 如果 Batch 间产生了交集，我们不能进行合并 */\n\n\t batch = NULL\n\t break;\n\t \n\t if(batch == NULL):\n\t /* Create new Batch and add to mergingBatches */\n\t /* 如果 batch 为空，则创建一个新的 batch，并将它添加到 mergingBatches 中 */\n\n\t batch = new DrawBatch(...);\n\t mergingBatches[deferInfo.batchId].put(info.mergeId, batch);\n\t batches.insertAt(newBatchIndex, batch);\n\t batch.add(op);\n```\n\n如果当前操作能够与其他具有相同 mergeId 和 batchId 的操作合并，那么这个操作和下一个可以合并的操作都会被添加到现有的 batch 中。但如果它因为状态不一致、绘制标记或边界限制无法被合并，算法就需要将它插入到一个新的 batch 中。为了实现这样的需求，我们则需要获得 batch 队列中所有 batch 对应的 postion。理想情况下，它能在当前绘制操作中找到一个和它状态相同的 batch。不过需要注意的是，在这个绘制操作中为它找到合适的位置的过程中，也必须保证它和其他 batch 没有交集。因此，batch 列表都以逆序寻找一个合适的位置，并确认对应的位置与其他元素没有交集。如果出现了交集，那么对应操作则不能被合并，并需要在这个位置创建一个新的 DrawBatch，并将其插入 Mergebatchedhaspmap。新的 batch 会被添加到 batch 队列的相应位置中。无论发生什么，改操作都会被加入到当前的 batch 中，区别在于：是在新的 batch 还是已存在的 batch 中。\n\n具体的实现会比我们的简化讲解更复杂（虽然我们这里讲的也很难懂……）。但其中优化的方法值得我们学习：算法通过移除堵塞的绘制操作尽可能地避免重绘，同时通过对为合并的操作进行重排序，从而避免 GPU 状态改变带来的开销。\n\n## 绘制界面 ##\n\n在重排序和合并后，新的 deferred display list 终于可以被绘制到屏幕上了。\n\n![](https://blog.inovex.de/wp-content/uploads/2015/03/ddl-flush.png)\n\n在 OpenGLRenderers::drawDisplayList(…) 方法里，deferred display list 其实就是一个填满了操作的新建普通显示列表，填充完成后延迟显示页面将绘制它自身。\n\n**OpenGLRenderer: drawDisplayList(…)**\n\n```java\n\tstatus_t OpenGLRenderer::drawDisplayList(\n\t DisplayList* displayList, Rect& dirty,\n\t int32_t replayFlags) {\n\t // All the usual checks and setup operations \n\t // (quickReject, setupDraw, etc.)\n\t // will be performed by the display list itself\n\t // 所有的常规检查与创建操作（例如 quickReject, setupDraw 等等）都会由 display list 完成\n\n\t if (displayList && displayList->isRenderable()) {\n\t DeferredDisplayList deferredList(*(mSnapshot->clipRect));\n\t DeferStateStruct deferStruct(\n\t deferredList, *this, replayFlags);\n\t displayList->defer(deferStruct, 0);\n\t return deferredList.flush(*this, dirty);\n\t }\n\t return DrawGlInfo::kStatusDone;\n\t}\n```\n\nmultiDraw(…) 方法会在列表中的第一个操作中被调用，而其他的操作都被视作参数。被调用的操作负责立刻绘制所有被提供的操作，并调用 OpenGLRenderer 执行绘制其自身的操作。\n\n## 显示列表中的操作 ##\n\n每一个绘制操作都会在拥有对应显示操作列表的 Canvas 里被执行，所有显示操作列表必须实现重载了绘制操作的 replay() 方法。这些绘制操作调用 OpenGLRenderer 去绘制他们，当我们创建一个操作时需要提供一个 renderer 的引用。除此以外，我们还需要实现 onDefer() 方法，并返回操作的 drawId 和 mergeId。为合并的 batch 会设置相应的绘制 id 为 kOpBatch_None。可合并的操作必须实现用于立刻绘制所有已合并的操作的 multiDraw() 方法。\n\n例如，绘制 9-Patch 的操作包含了下列 multiDraw(…) 实现：\n\n**DrawPatchOp::multiDraw(…)**\n\n```java\n\tvirtual status_t multiDraw(OpenGLRenderer& renderer, Rect& dirty,\n\t const Vector& ops, const Rect& bounds) {\n\t \n\t // Merge all 9-Patche vertices and texture coordinates \n\t // into one big vector\n\t // 将所有 9-Patche 图片的顶点坐标和纹理坐标合并到一个矢量中\n\n\t Vector vertices;\n\t for (unsigned int i = 0; i < ops.size(); i++) {\n\t DrawPatchOp* patchOp = (DrawPatchOp*) ops[i].op;\n\t const Patch* opMesh = patchOp->getMesh(renderer);\n\t TextureVertex* opVertices = opMesh->vertices;\n\t for (uint32_t j = 0; j < opMesh->verticesCount; \n\t j++, opVertices++) {\n\t vertices.add(TextureVertex(opVertices->position[0], \n\t opVertices->position[1],\n\t opVertices->texture[0], \n\t opVertices->texture[1]));\n\t }\n\t }\n\t \n\t // Tell the renderer to draw multipe textured polygons\n\t // 让渲染器绘制具有多种纹理的多边形\n\t return renderer.drawPatches(mBitmap, getAtlasEntry(),\n\t &vertices[0], getPaint(renderer));\n\t}\n```\n\n9-Patch 图片的 batchId 总是常量 kOpBatch_Patch，而 mergeId 则是指向图片的指针，因此，所有使用了相同图片的 9-Patch 对象都能够被合并为一个。此外，这种特性对我们使用资源文件里的图片非常有帮助，因为现在 Android 框架层所有经常被使用的 9-Patch 图片都可以根据其相同的纹理合并到同一个地方存储、使用。\n\n## 纹理贴图集 ##\n\nAndroid 的起始进程 Zygote 总会预加载一些与所有进程共享的资源文件，这些资源文件夹包含了频繁被使用的那些 9-Batch 图片和 Android 控件使用的图片。但在 Android 4.4 之前，每一个进程在 GPU 内存中都拥有这些资源文件的独立拷贝。从 Android 4.4 开始，这些频繁被使用的资源文件则被打包到一个纹理贴图集，随后传输到 GPU 内存中，并共享于所有进程之中。在这些操作完成之后才有可能对标准 Android 框架中的 9-Patch 和 Drawable资源文件进行合并。\n\n![](https://blog.inovex.de/wp-content/uploads/2015/03/atlas.png)\n\n> 系统产生的纹理贴图集是为了减少切换纹理带来的 GPU 负荷。\n\n刚刚那张图展示了 Nexus 7 在 Android 4.4 系统下生成的纹理贴图集，图集中包含了所有频繁被使用的 Android 框架层图像资源，如果你看得仔细，你会发现 9-Patch 文件没有突出布局和间距区域的边界，而原始的资源文件在系统启动之初则进行了解析，不过它们之后也不会被用于绘制，所以我们也不用在意。\n\n在 Android 进行系统更新后，系统第一次进行引导时（或者每一次进行引导时）， AssetAtlasService 都会重新生成纹理贴图集，并在之后的每一次重新启动过程中再次使用它，直到 Android 更新的内容被应用于系统中。\n\n为了生成纹理贴图集，service 组件会强行搜查各种图集配置，想尽千方百计找到那个能穿上水晶鞋的贴图集配置，那么什么样的贴图集配置是最好的呢？答案是：纹理资源最丰富，且纹理尺寸最小。原因在于：我们所获得的配置信息，会被写入到 /data/system/framework_atlas.config 中，此外，无论元素是否允许旋转，是否添加了间距，配置信息中都包含了我们选择的算法和尺寸大小。完成上述操作后，配置信息就会在之后的每一次重新启动过程中被应用，生成纹理贴图集。之后，系统会分配一个 RGBA8888 的图形缓存区，通过使用 Skiabitmap 将 资源纹理贴图集和所有资源文件绘制到这个缓存区中。经过上述繁复的操作后，资源纹理贴图集将在 AssetAtlasService 组件整个生命周期中有效，只有在系统自身被关闭时才会被释放。\n\n为了真正把所有资源文件打包到一个图集中，AssetAtlasService 会从打包空白纹理开始。在将第一个资源文件放入之后，剩下的空间将会被切分成两个矩形区域。然后利用我们在配置信息中选择的算法，可以将这两个区域分别作为水平方向和垂直方向的视图处理区域。而空白纹理之后的纹理资源文件将会被添加到足以存放它的第一个区域中。而这个区域会再次被切分成两个区域，把下一个资源文件添加到相应区域后再次切分，循环往复。可能有人会问了，这样难道不会因为迭代操作使得时间开销很大吗？不用担心，AssetAtlasService 同时使用多个线程并行操作，使得时间开销被大大减少。\n\n当一个新的 App 被创建，它的硬件渲染器需要 AssetAtlasService 为它提供相应的纹理贴图，并且当渲染器每一次需要绘制 bitmap 或者 9-Patch 图片，它都会先检查它的贴图集。\n\n## 字体的缓存与绘制 ##\n\n为了合并包含文字的 View 的绘制操作，一个简单的方法就是缓存字体。但与纹理贴图集的操作方法相反，字体集是每一个 App 或字体独有的。但由于字体的颜色会被应用到 shader 中，因此 Android 不会将文字颜色添加到字体集中。\n\n![](https://blog.inovex.de/wp-content/uploads/2015/03/font-300x167.png)\n\n> 左边：字体集由字体渲染器生成；右边：用 CPU 生成的几何体渲染字符\n\n就算你只是瞥一眼字体集，你都会注意到只有一部分字符被绘制，如果你看得认真一些，你会注意到只有被使用的字符才会被绘制出来（没有重复的字符）！如果你看到这里在想 Android 支持多少种语言，抑或是支持多少种字符，那只缓存被使用的字符确实是最优解。又因为 Actionbar 和 Button 使用着相同的字体，那么它们俩使用的所有字符都能被合并到一种纹理中。\n\n为了将相应的文字绘制到视图中，渲染器需要在一块拥有边界的纹理区域中生成一个几何体。几何体由 CPU 生成后通过 OpenGL 的 glDrawElements() 命令绘制，如果设备支持 OpenGL ES 3.0,字体渲染器会异步更新字体的纹理缓存，并将其上传到框架的入口，即 GPU 仍接近处于闲置状态时，进行这样的操作能够为每一个框架的加载节省下宝贵的时间。为了实现异步上传，纹理缓存会被实现为 OpenGL 的像素缓存对象。\n\n## OpenGL ##\n\n在博文的前言阶段我曾许下承诺：我会结合部分原生的 OpenGL 绘制命令讲解博文中的知识。那么现在，就是我兑现诺言的时刻了。从此刻开始，我会用 OpenGL 的绘制 log 讲解之前的简单示例 Activity（只有一个 Button 的那个例子！）\n\n```shell\n\tglUniformMatrix4fv(location = 2, count = 1, transpose = false, value = [1.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 1.0])\n\t\n\tglBindBuffer(target = GL_ARRAY_BUFFER, buffer = 0)\n\t\n\tglGenBuffers(n = 1, buffers = [3])\n\t\n\tglBindBuffer(target = GL_ELEMENT_ARRAY_BUFFER, buffer = 3)\n\t\n\tglBufferData(target = GL_ELEMENT_ARRAY_BUFFER, size = 24576, data = [ 24576 bytes ], usage = GL_STATIC_DRAW)\n\t\n\tglVertexAttribPointer(indx = 0, size = 2, type = GL_FLOAT, normalized = false, stride = 16, ptr = 0xbefdcf18)\n\t\n\tglVertexAttribPointer(indx = 1, size = 2, type = GL_FLOAT, normalized = false, stride = 16, ptr = 0xbefdcf20)\n\t\n\tglVertexAttribPointerData(indx = 0, size = 2, type = GL_FLOAT, normalized = false, stride = 16, ptr = 0x??, minIndex = 0, maxIndex = 48)\n\t\n\tglVertexAttribPointerData(indx = 1, size = 2, type = GL_FLOAT, normalized = false, stride = 16, ptr = 0x??, minIndex = 0, maxIndex = 48)\n\t\n\tglDrawElements(mode = GL_MAP_INVALIDATE_RANGE_BIT, count = 72, type = GL_UNSIGNED_SHORT, indices = 0x0)\n\t\n\tglBindBuffer(target = GL_ARRAY_BUFFER, buffer = 2)\n\t\n\tglBufferSubData(target = GL_ARRAY_BUFFER, offset = 768, size = 576, data = [ 576 bytes ])\n\t\n\tglDisable(cap = GL_BLEND)\n\t\n\tglUniformMatrix4fv(location = 2, count = 1, transpose = false, value = [1.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 33.0, 0.0, 1.0])\n\t\n\tglVertexAttribPointer(indx = 0, size = 2, type = GL_FLOAT, normalized = false, stride = 16, ptr = 0x300)\n\t\n\tglVertexAttribPointer(indx = 1, size = 2, type = GL_FLOAT, normalized = false, stride = 16, ptr = 0x308)\n\t\n\tglDrawElements(mode = GL_MAP_INVALIDATE_RANGE_BIT, count = 54, type = GL_UNSIGNED_SHORT, indices = 0x0)\n\t\n\teglSwapBuffers()\n```\n\n你可以在博文的结尾看到完整的绘制 log\n\n## 结论 ##\n\n两篇超简单的博文看下来，Android 如何在 display list 中通过一系列的命令对 View 层的操作进行重排序和合并，如何在底层中执行这些命令，我相信没人会不懂了吧！（有人懂才怪呢 XD～）\n\n结合两篇博文的知识储备，我们重新回去分析之前的示例 App：App 中 View 的整个渲染流程其实只有5步：\n\n![](https://blog.inovex.de/wp-content/uploads/2015/03/one-button-all-1024x180.png)\n\n1. 布局绘制其背景图片，也就是我们的线性布局。\n\n2. ActionBar 和 Button 的 9-Patch 图片文件均被绘制，这两个操作被合并到一个 batch 中，因为它俩的 9-Patch 被用在相同的纹理区域中。\n\n3. 为 Actionbar 绘制一个线性布局。\n\n4. 同时绘制 Button 和 ActionBar 中的文字，因为这两个 View 使用了相同的字体，使得字体渲染器能够使用相同的字体纹理，因此能合并两个文字绘制操作。\n\n5. 应用图标绘制完成。\n\n就像你看到的，我们深入解析了绘制 View 层的操作是如何在底层与 OpenGL 命令一一对应的，这个系列的博文也算是得到了一个完美的收尾了。\n\n## Download ##\n\n文章中引用的论文可以下载，[链接在此](http://mathias-garbe.de/files/introduction-android-graphics.pdf)\n\n## 完整 Log ##\n\n**Display List**\n\nShell\n\n```shell\n\tStart display list (0x5ea4f008, PhoneWindow.DecorView, render=1)\n\t Save 3\n\t ClipRect 0.00, 0.00, 720.00, 1184.00\n\t SetupShader, shader 0x5ea5af08\n\t Draw Rect 0.00 0.00 720.00 1184.00\n\t ResetShader\n\t Draw Display List 0x5ea64d30, flags 0x244053\n\t Start display list (0x5ea64d30, ActionBarOverlayLayout, render=1)\n\t Save 3\n\t ClipRect 0.00, 0.00, 720.00, 1184.00\n\t Draw Display List 0x5ea5ad78, flags 0x24053\n\t Start display list (0x5ea5ad78, FrameLayout, render=1)\n\t Save 3\n\t Translate (left, top) 0, 146\n\t ClipRect 0.00, 0.00, 720.00, 1038.00\n\t Draw Display List 0x5ea59bf8, flags 0x224053\n\t Start display list (0x5ea59bf8, RelativeLayout, render=1)\n\t Save 3\n\t ClipRect 0.00, 0.00, 720.00, 1038.00\n\t Save flags 3\n\t ClipRect 32.00 32.00 688.00 1006.00\n\t Draw Display List 0x5cfee368, flags 0x224073\n\t Start display list (0x5cfee368, Button, render=1)\n\t Save 3\n\t Translate (left, top) 32, 32\n\t ClipRect 0.00, 0.00, 243.00, 96.00\n\t Draw patch 0.00 0.00 243.00 96.00\n\t Save flags 3\n\t ClipRect 24.00 0.00 219.00 80.00\n\t Translate by 24.000000 23.000000\n\t Draw Text of count 12, bytes 24\n\t Restore to count 1\n\t Done (0x5cfee368, Button)\n\t Restore to count 1\n\t Done (0x5ea59bf8, RelativeLayout)\n\t Done (0x5ea5ad78, FrameLayout)\n\t Draw Display List 0x5ea64ac8, flags 0x24053\n\t Start display list (0x5ea64ac8, ActionBarContainer, render=1)\n\t Save 3\n\t Translate (left, top) 0, 50\n\t ClipRect 0.00, 0.00, 720.00, 96.00\n\t Draw patch 0.00 0.00 720.00 96.00\n\t Draw Display List 0x5ea64910, flags 0x224053\n\t Start display list (0x5ea64910, ActionBarView, render=1)\n\t Save 3\n\t ClipRect 0.00, 0.00, 720.00, 96.00\n\t Draw Display List 0x5ea63790, flags 0x224053\n\t Start display list (0x5ea63790, LinearLayout, render=1)\n\t Save 3\n\t Translate (left, top) 17, 0\n\t ClipRect 0.00, 0.00, 265.00, 96.00\n\t Draw Display List 0x5ea5fe80, flags 0x224053\n\t Start display list (0x5ea5fe80, \n\t ActionBarView.HomeView, render=1)\n\t Save 3\n\t ClipRect 0.00, 0.00, 80.00, 96.00\n\t Draw Display List 0x5ea5ed00, flags 0x224053\n\t Start display list (0x5ea5ed00, ImageView, render=1)\n\t Save 3\n\t Translate (left, top) 8, 16\n\t ClipRect 0.00, 0.00, 64.00, 64.00\n\t Save flags 3\n\t ConcatMatrix \n\t [0.67 0.00 0.00] [0.00 0.67 0.00] [0.00 0.00 1.00]\n\t Draw bitmap 0x5d33ae70 at 0.000000 0.000000\n\t Restore to count 1\n\t Done (0x5ea5ed00, ImageView)\n\t Done (0x5ea5fe80, ActionBarView.HomeView)\n\t Draw Display List 0x5ea63618, flags 0x224053\n\t Start display list (0x5ea63618, LinearLayout, render=1)\n\t Save 3\n\t Translate (left, top) 80, 23\n\t ClipRect 0.00, 0.00, 185.00, 49.00\n\t Save flags 3\n\t ClipRect 0.00 0.00 169.00 49.00\n\t Draw Display List 0x5ea634a0, flags 0x224073\n\t Start display list (0x5ea634a0, TextView, render=1)\n\t Save 3\n\t ClipRect 0.00, 0.00, 169.00, 49.00\n\t Save flags 3\n\t ClipRect 0.00 0.00 169.00 49.00\n\t Draw Text of count 9, bytes 18\n\t Restore to count 1\n\t Done (0x5ea634a0, TextView)\n\t Restore to count 1\n\t Done (0x5ea63618, LinearLayout)\n\t Done (0x5ea63790, LinearLayout)\n\t Done (0x5ea64910, ActionBarView)\n\t Done (0x5ea64ac8, ActionBarContainer)\n\t Draw patch 0.00 146.00 720.00 178.00\n\t Done (0x5ea64d30, ActionBarOverlayLayout)\n\tDone (0x5ea4f008, PhoneWindow.DecorView)\n```\n\n**OpenGL**\n\n```shell\n\teglCreateContext(version = 1, context = 0)\n\t\n\teglMakeCurrent(context = 0)\n\t\n\tglGetIntegerv(pname = GL_MAX_TEXTURE_SIZE, params = [2048])\n\t\n\tglGetIntegerv(pname = GL_MAX_TEXTURE_SIZE, params = [2048])\n\t\n\tglGetString(name = GL_VERSION) = OpenGL ES 2.0 14.01003\n\t\n\tglGetIntegerv(pname = GL_MAX_TEXTURE_SIZE, params = [2048])\n\t\n\tglGenBuffers(n = 1, buffers = [1])\n\t\n\tglBindBuffer(target = GL_ARRAY_BUFFER, buffer = 1)\n\t\n\tglBufferData(target = GL_ARRAY_BUFFER, size = 64, data = [64 bytes], \n\t usage = GL_STATIC_DRAW)\n\t\n\tglDisable(cap = GL_SCISSOR_TEST)\n\t\n\tglActiveTexture(texture = GL_TEXTURE0)\n\t\n\tglGenBuffers(n = 1, buffers = [2])\n\t\n\tglBindBuffer(target = GL_ARRAY_BUFFER, buffer = 2)\n\t\n\tglBufferData(target = GL_ARRAY_BUFFER, size = 131072, data = 0x0, \n\t usage = GL_DYNAMIC_DRAW)\n\t\n\tglGetIntegerv(pname = GL_MAX_COMBINED_TEXTURE_IMAGE_UNITS,\n\t params = [16])\n\t\n\tglGetIntegerv(pname = GL_MAX_TEXTURE_SIZE, params = [2048])\n\t\n\tglGenTextures(n = 1, textures = [1])\n\t\n\tglBindTexture(target = GL_TEXTURE_2D, texture = 1)\n\t\n\tglEGLImageTargetTexture2DOES(target = GL_TEXTURE_2D, \n\t image = 2138532008)\n\t\n\tglGetError(void) = (GLenum) GL_NO_ERROR\n\t\n\tglDisable(cap = GL_DITHER)\n\t\n\tglClearColor(red = 0,000000, green = 0,000000, blue = 0,000000, \n\t alpha = 0,000000)\n\t\n\tglEnableVertexAttribArray(index = 0)\n\t\n\tglDisable(cap = GL_BLEND)\n\t\n\tglGenTextures(n = 1, textures = [2])\n\t\n\tglBindTexture(target = GL_TEXTURE_2D, texture = 2)\n\t\n\tglPixelStorei(pname = GL_UNPACK_ALIGNMENT, param = 1)\n\t\n\tglTexImage2D(target = GL_TEXTURE_2D, level = 0, \n\t internalformat = GL_ALPHA, width = 1024, height = 512, \n\t border = 0, format = GL_ALPHA, type = GL_UNSIGNED_BYTE, \n\t pixels = [])\n\t\n\tglTexParameteri(target = GL_TEXTURE_2D, pname = GL_TEXTURE_MIN_FILTER, \n\t param = 9728)\n\t\n\tglTexParameteri(target = GL_TEXTURE_2D, pname = GL_TEXTURE_MAG_FILTER, param = 9728)\n\t\n\tglTexParameteri(target = GL_TEXTURE_2D, pname = GL_TEXTURE_WRAP_S, param = 33071)\n\t\n\tglTexParameteri(target = GL_TEXTURE_2D, pname = GL_TEXTURE_WRAP_T, param = 33071)\n\tglViewport(x = 0, y = 0, width = 800, height = 1205)\n\t\n\tglPixelStorei(pname = GL_UNPACK_ALIGNMENT, param = 1)\n\t\n\tglTexSubImage2D(target = GL_TEXTURE_2D, level = 0, xoffset = 0, yoffset = 0, width = 1024, height = 80, format = GL_ALPHA, type = GL_UNSIGNED_BYTE, pixels = 0x697b7008)\n\t\n\tglInsertEventMarkerEXT(length = 0, marker = Flush)\n\t\n\tglBindBuffer(target = GL_ARRAY_BUFFER, buffer = 0)\n\t\n\tglBindTexture(target = GL_TEXTURE_2D, texture = 1)\n\t\n\tglTexParameteri(target = GL_TEXTURE_2D, pname = GL_TEXTURE_WRAP_S, param = 33071)\n\t\n\tglTexParameteri(target = GL_TEXTURE_2D, pname = GL_TEXTURE_WRAP_T, param = 33071)\n\t\n\tglTexParameteri(target = GL_TEXTURE_2D, pname = GL_TEXTURE_MIN_FILTER, param = 9729)\n\t\n\tglTexParameteri(target = GL_TEXTURE_2D, pname = GL_TEXTURE_MAG_FILTER, param = 9729)\n\t\n\tglCreateShader(type = GL_VERTEX_SHADER) = (GLuint) 1\n\t\n\tglShaderSource(shader = 1, count = 1, string = attribute vec4 position;\n\t\n\tattribute vec2 texCoords;\n\t\n\tuniform mat4 projection;\n\t\n\tuniform mat4 transform;\n\t\n\tvarying vec2 outTexCoords;\n\t \n\tvoid main(void) {\n\t outTexCoords = texCoords;\n\t gl_Position = projection * transform * position;\n\t}\n\t \n\t, length = [0])\n\tglCompileShader(shader = 1)\n\t\n\tglGetShaderiv(shader = 1, pname = GL_COMPILE_STATUS, params = [1])\n\t\n\tglCreateShader(type = GL_FRAGMENT_SHADER) = (GLuint) 2\n\t\n\tglShaderSource(shader = 2, count = 1, string = precision mediump float;\n\t \n\tvarying vec2 outTexCoords;\n\tuniform sampler2D baseSampler;\n\t \n\tvoid main(void) {\n\t gl_FragColor = texture2D(baseSampler, outTexCoords);\n\t}\n\t \n\t, length = [0])\n\tglCompileShader(shader = 2)\n\t\n\tglGetShaderiv(shader = 2, pname = GL_COMPILE_STATUS, params = [1])\n\t\n\tglCreateProgram(void) = (GLuint) 3\n\t\n\tglAttachShader(program = 3, shader = 1)\n\t\n\tglAttachShader(program = 3, shader = 2)\n\t\n\tglBindAttribLocation(program = 3, index = 0, name = position)\n\t\n\tglBindAttribLocation(program = 3, index = 1, name = texCoords)\n\t\n\tglGetProgramiv(program = 3, pname = GL_ACTIVE_ATTRIBUTES, params = [2])\n\t\n\tglGetProgramiv(program = 3, pname = GL_ACTIVE_ATTRIBUTE_MAX_LENGTH, params = [10])\n\t\n\tglGetActiveAttrib(program = 3, index = 0, bufsize = 10, length = [0], size = [1], type = [GL_FLOAT_VEC4], name = position)\n\t\n\tglGetActiveAttrib(program = 3, index = 1, bufsize = 10, length = [0], size = [1], type = [GL_FLOAT_VEC2], name = texCoords)\n\t\n\tglGetProgramiv(program = 3, pname = GL_ACTIVE_UNIFORMS, params = [3])\n\t\n\tglGetProgramiv(program = 3, pname = GL_ACTIVE_UNIFORM_MAX_LENGTH, params = [12])\n\t\n\tglGetActiveUniform(program = 3, index = 0, bufsize = 12, length = [0], size = [1], type = [GL_FLOAT_MAT4], name = projection)\n\t\n\tglGetActiveUniform(program = 3, index = 1, bufsize = 12, length = [0], size = [1], type = [GL_FLOAT_MAT4], name = transform)\n\t\n\tglGetActiveUniform(program = 3, index = 2, bufsize = 12, length = [0], size = [1], type = [GL_SAMPLER_2D], name = baseSampler)\n\t\n\tglLinkProgram(program = 3)\n\t\n\tglGetProgramiv(program = 3, pname = GL_LINK_STATUS, params = [1])\n\t\n\tglGetUniformLocation(program = 3, name = transform) = (GLint) 2\n\t\n\tglGetUniformLocation(program = 3, name = projection) = (GLint) 1\n\t\n\tglUseProgram(program = 3)\n\t\n\tglGetUniformLocation(program = 3, name = baseSampler) = (GLint) 0\n\t\n\tglUniform1i(location = 0, x = 0)\n\t\n\tglUniformMatrix4fv(location = 1, count = 1, transpose = false, value = [0.0025, 0.0, 0.0, 0.0, 0.0, -0.001659751, 0.0, 0.0, 0.0, 0.0, -1.0, 0.0, -1.0, 1.0, -0.0, 1.0])\n\t\n\tglUniformMatrix4fv(location = 2, count = 1, transpose = false, value = [800.0, 0.0, 0.0, 0.0, 0.0, 1205.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 1.0])\n\tglEnableVertexAttribArray(index = 1)\n\t\n\tglVertexAttribPointer(indx = 0, size = 2, type = GL_FLOAT, normalized = false, stride = 16, ptr = 0x681e7af4)\n\t\n\tglVertexAttribPointer(indx = 1, size = 2, type = GL_FLOAT, normalized = false, stride = 16, ptr = 0x681e7afc)\n\t\n\tglVertexAttribPointerData(indx = 0, size = 2, type = GL_FLOAT, normalized = false, stride = 16, ptr = 0x??, minIndex = 0, maxIndex = 4)\n\t\n\tglVertexAttribPointerData(indx = 1, size = 2, type = GL_FLOAT, normalized = false, stride = 16, ptr = 0x??, minIndex = 0, maxIndex = 4)\n\t\n\tglDrawArrays(mode = GL_TRIANGLE_STRIP, first = 0, count = 4)\n\t\n\tglBindBuffer(target = GL_ARRAY_BUFFER, buffer = 2)\n\t\n\tglBufferSubData(target = GL_ARRAY_BUFFER, offset = 0, size = 576, data = [ 576 bytes ])\n\t\n\tglBufferSubData(target = GL_ARRAY_BUFFER, offset = 576, size = 192, data = [ 192 bytes ])\n\t\n\tglEnable(cap = GL_BLEND)\n\t\n\tglBlendFunc(sfactor = GL_SYNC_FLUSH_COMMANDS_BIT, dfactor = GL_ONE_MINUS_SRC_ALPHA)\n\t\n\tglUniformMatrix4fv(location = 2, count = 1, transpose = false, value = [1.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 1.0])\n\t\n\tglBindBuffer(target = GL_ARRAY_BUFFER, buffer = 0)\n\t\n\tglGenBuffers(n = 1, buffers = [3])\n\t\n\tglBindBuffer(target = GL_ELEMENT_ARRAY_BUFFER, buffer = 3)\n\t\n\tglBufferData(target = GL_ELEMENT_ARRAY_BUFFER, size = 24576, data = [ 24576 bytes ], usage = GL_STATIC_DRAW)\n\t\n\tglVertexAttribPointer(indx = 0, size = 2, type = GL_FLOAT, normalized = false, stride = 16, ptr = 0xbefdcf18)\n\t\n\tglVertexAttribPointer(indx = 1, size = 2, type = GL_FLOAT, normalized = false, stride = 16, ptr = 0xbefdcf20)\n\t\n\tglVertexAttribPointerData(indx = 0, size = 2, type = GL_FLOAT, normalized = false, stride = 16, ptr = 0x??, minIndex = 0, maxIndex = 48)\n\t\n\tglVertexAttribPointerData(indx = 1, size = 2, type = GL_FLOAT, normalized = false, stride = 16, ptr = 0x??, minIndex = 0, maxIndex = 48)\n\t\n\tglDrawElements(mode = GL_MAP_INVALIDATE_RANGE_BIT, count = 72, type = GL_UNSIGNED_SHORT, indices = 0x0)\n\t\n\tglBindBuffer(target = GL_ARRAY_BUFFER, buffer = 2)\n\t\n\tglBufferSubData(target = GL_ARRAY_BUFFER, offset = 768, size = 576, data = [ 576 bytes ])\n\t\n\tglDisable(cap = GL_BLEND)\n\t\n\tglUniformMatrix4fv(location = 2, count = 1, transpose = false, value = [1.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 33.0, 0.0, 1.0])\n\t\n\tglVertexAttribPointer(indx = 0, size = 2, type = GL_FLOAT, normalized = false, stride = 16, ptr = 0x300)\n\t\n\tglVertexAttribPointer(indx = 1, size = 2, type = GL_FLOAT, normalized = false, stride = 16, ptr = 0x308)\n\t\n\tglDrawElements(mode = GL_MAP_INVALIDATE_RANGE_BIT, count = 54, type = GL_UNSIGNED_SHORT, indices = 0x0)\n\t\n\tglEnable(cap = GL_BLEND)\n\t\n\tglUniformMatrix4fv(location = 2, count = 1, transpose = false, value = [1.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 1.0])\n\t\n\tglBindBuffer(target = GL_ARRAY_BUFFER, buffer = 0)\n\t\n\tglBindTexture(target = GL_TEXTURE_2D, texture = 2)\n\t\n\tglVertexAttribPointer(indx = 0, size = 2, type = GL_FLOAT, normalized = false, stride = 16, ptr = 0x696bd008)\n\t\n\tglVertexAttribPointer(indx = 1, size = 2, type = GL_FLOAT, normalized = false, stride = 16, ptr = 0x696bd010)\n\t\n\tglVertexAttribPointerData(indx = 0, size = 2, type = GL_FLOAT, normalized = false, stride = 16, ptr = 0x??, minIndex = 0, maxIndex = 80)\n\t\n\tglVertexAttribPointerData(indx = 1, size = 2, type = GL_FLOAT, normalized = false, stride = 16, ptr = 0x??, minIndex = 0, maxIndex = 80)\n\t\n\tglDrawElements(mode = GL_MAP_INVALIDATE_RANGE_BIT, count = 120, type = GL_UNSIGNED_SHORT, indices = 0x0)\n\t\n\tglGenTextures(n = 1, textures = [3])\n\t\n\tglBindTexture(target = GL_TEXTURE_2D, texture = 3)\n\t\n\tglPixelStorei(pname = GL_UNPACK_ALIGNMENT, param = 4)\n\t\n\tglTexImage2D(target = GL_TEXTURE_2D, level = 0, internalformat = GL_RGBA, width = 64, height = 64, border = 0, format = GL_RGBA, type = GL_UNSIGNED_BYTE, pixels = 0x420cd930)\n\t\n\tglTexParameteri(target = GL_TEXTURE_2D, pname = GL_TEXTURE_MIN_FILTER, param = 9728)\n\t\n\tglTexParameteri(target = GL_TEXTURE_2D, pname = GL_TEXTURE_MAG_FILTER, param = 9728)\n\t\n\tglTexParameteri(target = GL_TEXTURE_2D, pname = GL_TEXTURE_WRAP_S, param = 33071)\n\t\n\tglTexParameteri(target = GL_TEXTURE_2D, pname = GL_TEXTURE_WRAP_T, param = 33071)\n\t\n\tglUniformMatrix4fv(location = 2, count = 1, transpose = false, value = [64.0, 0.0, 0.0, 0.0, 0.0, 64.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 16.0, 38.0, 0.0, 1.0])\n\tglBindBuffer(target = GL_ARRAY_BUFFER, buffer = 1)\n\t\n\tglVertexAttribPointer(indx = 0, size = 2, type = GL_FLOAT, normalized = false, stride = 16, ptr = 0x0)\n\t\n\tglVertexAttribPointer(indx = 1, size = 2, type = GL_FLOAT, normalized = false, stride = 16, ptr = 0x8)\n\t\n\tglBindBuffer(target = GL_ELEMENT_ARRAY_BUFFER, buffer = 0)\n\t\n\tglDrawArrays(mode = GL_TRIANGLE_STRIP, first = 0, count = 4)\n\t\n\tglGetError(void) = (GLenum) GL_NO_ERROR\n\t\n\teglSwapBuffers()\n```\n\n\n\n" }, { "path": "androidweekly/深入了解Bundle和Map/readme.md", "content": "深入了解Bundle和Map\n---\n\n>\n* 原文链接 : [The mysterious case of the Bundle and the Map](https://medium.com/the-wtf-files/the-mysterious-case-of-the-bundle-and-the-map-7b15279a794e)\n* 译者 : [yinna317](https://github.com/yinna317) \n* 校对者: [chaossss](https://github.com/chaossss) \n* 状态 : 翻译完成\n\n##前言\n\n因为往Bundle对象中放入Map实际上没有表面上看起来那么容易。\n\n这篇博客是在Eugenio @workingkills Marletti的帮助下完成的。\n\n**警告**：这是一篇篇幅较长的博客\n\n\n##案例：往Bundle对象放入特殊的Map\n\n假设有这样一个案例：你需要将一个要传递的map附加到Intent对象。这个案例虽然不常见，但是，这种情况也是很有可能发生。\n \n \n如果你在Intent对象中附加的是一个Map最常见的接口实现类HashMap，而不是包含附加信息的自定义类，你是幸运的，你可以用以下方法将map附加到Intent对象:\n\n```java\n intent.putExtra(\"map\",myHashMap);\n```\n\n在你接收的Activity里，你可以用以下方法毫无问题地取出之前在Intent中附加的Map:\n\n```java\n HashMap map = (HashMap) getIntent().getSerializableExtra(\"map\");\n```\n \n\n但是，如果你在Intent对象附加另一种类型的Map，比如：一个TreeMap（或者其他的自定义Map接口实现类），你在Intent中取出之前附加的TreeMap时，你用如下方法：\n\n```java\n TreeMap map = (TreeMap) getIntent().getSerializableExtra(\"map\");`\n```\n \n然后就会出现一个类转换异常:\n```java\n java.lang.ClassCastException: java.util.HashMap cannot be cast to java.util.TreeMap`\n```\n\n因为编译器认为你的Map(TreeMap)正试图转换成一个HashMap\n\n\n稍后我会详细地为大家讲解我为什么用 getSerializableExtra() 这个方法来取出附加到Intent中的Map。现在我可以先给大家一个通俗易懂的解释：因为所有默认的 Map 接口实现类都是Serializable,并且 putExtra()/getExtra() 方法接受的参数几乎都是“键-值”对，而其中值的类型非常广泛，Serializable就是其中之一，因此我们能够使用 getSerializableExtra() 来取得我们传递的Map。\n\n\n在我们进行下一步之前，让我们去了解调用putExtra()/get*Extra()时涉及到的一些类或方法。\n\n**提示**：文章很长，如果你只是想要一个解决方案的话，请跳到文章的最后面解决方案那里。\n\n\n##Parcels:\n\n大家都知道（也许少部分人不知道），在Android 系统中所有进程间通信是基于Binder机制。但是，希望大家明白的是允许数据在进程间传递是基于Parcel。\n\nParcel是Android进程间通信中， 高效的专用序列化机制。\n\n与 Serializable 相反，Parcels 决不应该被用于储存任何类型的持久性数据，因为 Parcels 并不是为“操作可更新数据”（可更新数据指的是，具有持久性的数据会由于它的长留存时间会不断更新它的值）提供的，Parcels 更多的是传递 “短暂的一次性数据”，所以，不管什么时候使用Bundle，你在底层处理的都是Parcel。比如附加数据到Intent对象，在Fragment中设参数，等等。\n\n\nParcels 能处理很多类型，包括：本地类型，字符串类型，数组类型，Map类型，sparse arrays类型，以及parcelables和serializables对象。\n除非你必须使用Serializable,一般情况下推荐使用Parcelables读写数据到Parcel.\n\n\n相较于Serializable，Parcelable的优势更多地体现在性能上，因为Parcelable在内存开销方面更小，而这个理由足以让我们在大多数情况下毫不犹豫地选择Parcelable而不是Serializable。\n\n\n##深入底层分析\n\n让我们来了解下是什么原因使我们得到了ClassCastException异常。\n从我们的代码中可以看到，我们对Intent中putExtras()的调用实际上是传入了一个String值和一个Serializable的对象，而不是传入一个Map值。因为Map接口实现类都是Serializable的，而不是Parcelable的。\n\n\n###第一步：找到第一个突破口\n\n让我们来看看在Intent.putExtra(String, Serializable)方法中做了什么。\n\n>Intent.java\n\n```java\npublic Intent putExtra(String name, Serializable value) {\n // ...\n mExtras.putSerializable(name, value);\n return this;\n }\n}\n``` \n\n\n在这里，mExtras是个Bundle，Intent指令所有附加信息到bundle，从而调用了Bundle的putSerializable()方法，让我们来看看在Bundle中的putSerializable()方法中做了什么：\n\n>Bundle.java\n\n```java\n@Override\n public void putSerializable(String key, Serializable value) {\n super.putSerializable(key, value);\n }\n``` \n\n从上面代码我们可以看出，Bundle中的putSerializable()方法中只是对父类的实现，调用了父类BaseBundle中的putSerializable（）方法。\n\n>BaseBundle.java\n\n```java\n void putSerializable(String key, Serializable value) {\n unparcel();\n mMap.put(key, value);\n }\n``` \n\n首先，让我们忽略其中的unparcel()这个方法。我们注意到mMap是一个ArrayMap类型的。这告诉我们，到了这步，我们往mMap中设入的是一个Object类型的。也就是说，不管我们之前是什么类型，在父类BaseBundle这里都转成了Obeject类型。\n\n####这里开始出现问题了\n![](https://d262ilb51hltx0.cloudfront.net/max/800/1*GokSVk3wQIhGoCQtVIwNTA.gif)\n\n\n###第二步：分析写入 map\n\n有趣的是当把Bundle中的值写入到一个Parcel中时，如果此时我们去检查我们附加值的类型，我们发现仍然能得到正确的类型。\n\n```java\n \tIntent intent = new Intent(this, ReceiverActivity.class);\n intent.putExtra(\"map\", treeMap);\n Serializable map = intent.getSerializableExtra(\"map\");\n Log.i(\"MAP TYPE\", map.getClass().getSimpleName());\n``` \n \n\n\n如我们所料，这里打印出来的是TreeMap类型的。因此，在Bundle中写成一个Parcel，与再次读这期间一定发生了类型转换。\n\n\n如果我们观察下是怎样写入Parcel的，我们看到，实际上是调BaseBundle中的writeToParcelInner()方法。\n\n>BaseBundle.java\n\n```java\n \tvoid writeToParcelInner(Parcel parcel, int flags) {\n if (mParcelledData != null) {\n // ...\n } else {\n // ...\n int startPos = parcel.dataPosition();\n parcel.writeArrayMapInternal(mMap);\n int endPos = parcel.dataPosition();\n // ...\n }\n}\n``` \n\n\n跳过所有不相干的代码，我们看到在Parcel的writeArrayMapInternal()方法中做了大量的事（mMap 是一个 ArrayMap类型）\n\n>Parcel.java\n\n```java\n /* package */ void writeArrayMapInternal(\n \tArrayMap val) {\n \t// ...\n \tint startPos;\n \tfor (int i=0; iParcel.java\n\n```java\n public final void writeValue(Object v) {\n\t if (v == null) {\n\t \twriteInt(VAL_NULL);\n\t } else if (v instanceof String) {\n\t\t writeInt(VAL_STRING);\n\t\t writeString((String) v);\n\t } else if (v instanceof Integer) {\n\t\t writeInt(VAL_INTEGER);\n\t\t writeInt((Integer) v);\n\t } else if (v instanceof Map) {\n\t\t writeInt(VAL_MAP);\n\t\t writeMap((Map) v);\n\t } else if (/* you get the idea, this goes on and on */) {\n\t \t// ...\n\t } else {\n\t \tClass clazz = v.getClass();\n\t \tif (clazz.isArray() &&\n\t \tclazz.getComponentType() == Object.class) {\n\t // Only pure Object[] are written here, Other arrays of non-primitive types are\n\t // handled by serialization as this does not record the component type.\n\t \twriteInt(VAL_OBJECTARRAY);\n\t \t writeArray((Object[]) v);\n\t } else if (v instanceof Serializable) {\n\t // Must be last\n\t writeInt(VAL_SERIALIZABLE);\n\t writeSerializable((Serializable) v);\n\t } else {\n\t throw new RuntimeException(\"Parcel: unable to marshal value \"+ v);\n\t }\n\t }\n\t }\n``` \n\n虽然TreeMap是以Serializable的类型传入到 bundle，但是在Parcel中writeValue(）方法执行的是map这个分支的代码---“v instanceof Map”，（“v instanceof Map”在“v instanceOf Serializable”之前）\n\n####到了这里，问题更明显了。\n\n![](https://d262ilb51hltx0.cloudfront.net/max/800/1*zA893bdM9QmLYPlRe7estg.gif)\n\n\n现在我想，他们是不是对 Map 进行了一些非常规的处理，使得 Map 将无可避免地被转换为 HashMap 类型。\n\n###第四步：分析将Map写入到Parcel中\n\nParcel中的writeMap()方法并没有做什么事，只是将我们传入的Map值强转成Map类型，调用writeMapInternal（）方法。\n\n>Parcel.java\n\n```java\n public final void writeMap(Map val) {\n \twriteMapInternal((Map) val);\n }\n``` \n \nJavaDoc文档对这个方法的解释非常清楚：即Map必须是String类型的。\n\n尽管我们可能传入一个key值不为String的Map,类型擦除也使我们不会获得运行时错误。(这是完全非法的)\n\n事实上，看一下Parcel中的writeMapInternal()方法，这更打击我们。\n\n>Parcel.java\n\n```java\n /* package */ void writeMapInternal(Map val) {\n // ...\n Set> entries = val.entrySet();\n writeInt(entries.size());\n for (Map.Entry e : entries) {\n \twriteValue(e.getKey());\n \twriteValue(e.getValue());\n }\n }\n``` \n\n类型擦除使所有的这些代码都不会出现运行时错误。\n\n实际上，在我们遍历Map调用writeValue()方法时，依赖的是原先的类型检查。从我们之前分析writeValue() 这个方法能看出，writeValue(）能处理非String类型的key值。\n\n\n也许这里的文档和代码在某些地方有些不一致（还没有同步）。\n但是，如果你在一个Bundle里对TreeMap进行设值和取值，将不会出现问题。\n当然也还是会出现TreeMap转换成HashMap的异常。\n\n\n####黑洞启示录：\n\n![](https://d262ilb51hltx0.cloudfront.net/max/600/1*sOK3EennxwiAPNzz5s0C4Q.gif)\n\n\n在这里已经非常清楚了，当Map写入到一个Parcel时，Map丢失了它们的类型，所以当我们再次读时是没办法来复原原来的信息。\n\n\n\n###第五步：分析读Map\n\n让我们来看看Parcel中readValue()这个方法，这个方法和writeValue()相对应。\n\n>Parcel.java\n\n```java\n public final Object readValue(ClassLoader loader) {\n int type = readInt();\n \n switch (type) {\n \tcase VAL_NULL:\n \treturn null;\n \n \tcase VAL_STRING:\n \treturn readString();\n \n \tcase VAL_INTEGER:\n \treturn readInt();\n \n \tcase VAL_MAP:\n \treturn readHashMap(loader);\n \n // ...\n }\n }\n``` \n\n>parcel处理写入数据的方式是：\n\n1. 写入一个int来定义数据类型（一个VAL_*的常量）。\n\n2. 存储数据本身（包括其他一些元数据，比如String这种没有固定大小的类型的数据长度）。\n\n3. 递归调用非原始数据类型。\n\n\n这里我们可以看到，readValue()方法中，首先读取一个int的数据，这个int数据是在writeValue（）中将TreeMap设成的VAL_MAP的常量，然后去匹配后面的分支,调用readHashMap()方法来取回数据。\n\n>Parcel.java\n\n```java\n public final HashMap readHashMap(ClassLoader loader)\n {\n int N = readInt();\n if (N < 0) {\n return null;\n }\n HashMap m = new HashMap(N);\n readMapInternal(m, N, loader);\n return m;\n }\n``` \n\nreadMapInternal()这个方法只是将我们从Parcel中读取的map重新进行打包。\n\n这就是为什么我们总是从Bundle中获得一个HashMap，同样的，如果你创建了一个实现了Parcelable自定义类型Map,得到的也是一个HashMap。\n\n很难说本身设计如此，还是是一个疏忽。\n这确实是一个极端例子，因为在一个Intent中传一个Map是比较少见的，你也只有很小的理由来传Serializable而不是Parcelable的。\n但是文档上没有写，这让我觉得应该是个疏忽，而不是本身设计如此。\n\n\n##解决方案：\n\n好了，分析底层代码我们已经弄明白了我们的问题，现在我们定位到问题的关键位置。\n我们需要明白的是在writeValue()方法中，我们的TreeMap不应该进入“v instanceOf Map”这个分支。\n\n\n当我和 Eugenio谈话时，我想到的第一个想法是将map包裹成一个Serializable的容器，这个想法是丑陋的但是有效的。\nEugenio迅速写了个通用的wrapper类解决了这个问题。\n\n>MapWrapper.java\n\n```java\n public class MapWrapper implements Serializable {\n \n private final T map;\n\n public MapWrapper(T map) {\n this.map = map;\n }\n\n public T getMap() {\n return map; public static Intent\n putMapExtra(Intent intent, String name, T map) {\n\n return intent.putExtra(name, new MapWrapper<>(map));\n }\n\n public static T\n getMapExtra(Intent intent, String name)\n throws ClassCastException {\n\n Serializable s = intent.getSerializableExtra(name);\n return s == null ? null : ((MapWrapper)s).getMap();\n }\n}\n }\n``` \n\n\n##另一个可行的解决方案：\n\n另一个解决方法是，在你将Map附加到Intent前，将Map转成byte array的。然后调用getByteArrayExtra()方法。但是这种方法你必须处理序列化与反序列化的问题。\n\n如果你想要其他的解决方案，你可以依据Eugenio提供的代码要点来写一个。\n\n##当你不能掌控Intent上面的代码时：\n\n也许，有这样或那样的原因，对于Bundle中的代码你无法掌控，比如可能在第三方的library中。\n\n这种情况，要想到，\nMap接口实现类有一个构造器方法，可以将map作为参数传入，比如 new TreeMap(Map)，你可以把从Bundle中取回的HashMap，用构造器的方式转成你想要的类型。\n\n不过，要记得的是，这种用构造器的方式，map中的附加属性将会丢失，只有键值对被保存了下来。\n\n##总结：\n\n在Android开发中，你可能会被一些表面的事所欺骗，特别是一些小的，似乎是无关紧要的事。\n\n当事情没有像我们期盼中那样发生时，不要死盯着JavaDoc文档，因为JavaDoc可能过时了，JavaDoc的作者也不知道你的特殊需求。这个时候去看看源码，答案可能在AOSP代码里。\n\nAOSP代码是我们的巨大财富，这在移动开发领域几乎是独一无二的，因为我们能够准确的知道在底层都做了些什么。\n\n\n当你知道了底层代码执行了什么，你也就能够成为一个更好的开发人员。\n\n记住：凡事要嘛就是成功，要嘛就是失败\n\n![](https://d262ilb51hltx0.cloudfront.net/max/800/0*40IPQ7jhknFGYKNR.)\n\n\n##最后：\n\n感谢[chaossss](https://github.com/chaossss) 帮我校对文章\n\n初次翻译，Android也是刚接触，翻译不好的地方，请大家多多指教。\n\n\n\n\n\n" }, { "path": "androidweekly/符合Material Design的抽屉导航效果/readme.md", "content": "###符合Material Design的抽屉导航效果：\n---\n>\n* 原文链接 : [Navigation Drawer styling according to Material Design](https://medium.com/@sotti/navigation-drawer-styling-according-material-design-5306190da08f)\n* 译者 : [wly2014](https://github.com/wly2014)\n* 校对者: [chaossss](https://github.com/chaossss)\n* 状态 : 校对完成\n\n![](https://d262ilb51hltx0.cloudfront.net/max/720/1*hLe32r_m-fWUQrnJCalKkQ.png)\n\n####前言：\n现在看来，抽屉式导航[已经成为主流导航模式之一](http://goo.gl/w4FVWS)。尽管广受[批评](https://medium.com/@villainschorus/your-problem-goes-beyond-hamburgers-e0aae6a1576)，但我还是很喜欢该样式，因此我决定在我写的几个app上添加这个控件。这篇文章想通过介绍我觉得抽屉式导航有趣的地方，帮助阅读本文的 Android 开发者们学习到一些知识，同时从其他人的评论中学习到更多的东西。\n\n这是三篇文章中的第二篇。欢迎查看第一篇和第三篇：\n\n * [Material Design下的抽屉导航的大小](https://medium.com/@sotti/navigation-drawer-styling-under-material-design-f0767882e692)\n\t* Material Design下的抽屉效果的行为（敬请期待）\n\n你可以从下面查看Material Design指南上关于抽屉导航的部分：\n\n\t* [Navigation Drawer pattern](http://www.google.com/design/spec/patterns/navigation-drawer.html)\n\t* [Material Design metrics and keylines](http://www.google.com/design/spec/layout/metrics-keylines.html#)\n\t* [Toolbar metrics](http://www.google.com/design/spec/layout/structure.html#structure-toolbars)\n\n### 开始：\n\n抽屉式导航一直以来都是被争论的热点话题。当 Material Design 规范刚发布的时候，抽屉式导航就在规范中处在一个尴尬的位置，使得开发者们很[困惑](http://goo.gl/q3dnCI)到底要不要使用抽屉式导航，甚至在 Material Design 规范下的[开发指南出来以后](https://plus.google.com/+SebastianoPoggi/posts/6MFgMeRLrrg)，有关如何在 Android 开发中对待抽屉式导航都没有一个清晰的答案。\n\n现在，虽然这儿已有一些漂亮的[库](https://plus.google.com/+MikePenz/posts/Erwn9mDZszr)，甚至有一些Google的[源码](https://github.com/google/iosched)能拿来看看... 但是，你之所以还来到这里，可能是因为你[热衷于编程](http://i3.kym-cdn.com/photos/images/facebook/000/234/765/b7e.jpg)。\n\n在这篇文章里，我将会谈论如何使用抽屉的样式，但是并不会完全涉及 Material Design 指南上的所有样式，只是捡一些我认为需要强调的东西。\n\n准备好了吗？\n\n### 位置\n在过去，抽屉式导航栏 和 ActionBar 处于同一个 View 层级\n\n![](https://d262ilb51hltx0.cloudfront.net/max/800/1*Vh9mKyCUMDCFMFjM8ZEG9Q.png)\n\n随着这种设计模式的发展，其中相互矛盾的地方也开始浮出水面……在 Material Design 中很清晰地指出：处于不同 View 层级的两个页面，是不能共存于同一个父布局中的同一个 View 层级的。有关这个问题引发了[许多讨论](https://plus.google.com/+RomanNurik/posts/3G8zYvN5oRC)，但[更重要的是](http://goo.gl/SHrQmd)， [Google 并没有给出好的解释](http://goo.gl/FghQhb)，不过最后抽屉式导航还是得到了一个被认可的定义：\n\n左抽屉式导航打开后，导航栏的高度应该和屏幕一致，但要低于状态栏。此外，其他任何在抽屉层以下的内容都应该被阴影覆盖，但这些内容又是可见的。\n\n> 左侧的导航抽屉横跨屏幕的高度并覆盖下方的状态栏。抽屉下的东西将会变暗。但仍是可见的。\n\n![](https://d262ilb51hltx0.cloudfront.net/max/1267/1*Gg34WwPMo1ylOX7KLPaY0w.png)\n\n注意图中右边的抽屉略有不同。\n\n注：我假设你使用的是[AppCompat ](https://chris.banes.me/2014/10/17/appcompat-v21/) [toolbar](https://developer.android.com/reference/android/widget/Toolbar.html)\n\n既然toolbar是View 层级的另一个view，不妨就就将toolbar置于抽屉的layout之下，跟其他的view一样。\n\n如果你在Google应用上看到如下的东西也不用担心：\n\n![](https://d262ilb51hltx0.cloudfront.net/max/700/1*ncHm2VDOAU4GRN5Act_P5A.png)\n\nGoogle+ Photos可能是最后一个使用抽屉，却没有覆盖ActionBar/Toolbar的Google应用，但是我想他应该很快就会被改过来。\n\n### 旋转标题图标\n\n你还记得当抽屉打开时那个ActionBar/Toolbar中的漂亮的图标动画吗？这个动画在Holo主题下并不是很好看，在 Matarial Design 下却很漂亮。\n\n![](https://d262ilb51hltx0.cloudfront.net/max/768/1*QfXDV7tpaGwEqil_l6Pe8Q.gif)\n\n我觉得当它第一次出现在Google Play Store时，很多的开发者和设计师都会很喜欢它。\n\n仅在那数周之后，抽屉式导航上就[开始出现该动画](https://lh6.googleusercontent.com/-9oPeSA7FUkI/VOs530mLbLI/AAAAAAABapc/ekQNTZPXyoE/w499-h281-no/tumblr_inline_nk2y80nOF91rllljr.gif)。那时它显得很特别，因为在Google Material Design videos 和 promo features上都出现了它的身影。\n\n![](https://d262ilb51hltx0.cloudfront.net/max/800/1*XI72aAgZON-g0F_Teo6kiA.jpeg)\n\n我记得很多人在第一次遵循 Matarial Design 规范开发时，就是使用这个汉堡/箭头图标动画。Google第一次实现这个抽屉式导航栏的时候，并不是把它放在 ToolBar 的上面，因此你可以看到这个精美的动画。但是 Material Design 指南发布后，出现了一个很奇怪的现象，很多的Google应用都在做与 Material Design 指南背道而驰的事情。即使是现在我写这篇博文的时候，大部分的应用还是在遵循着 Material Desgin 指南，但我还是希望抽屉式导航栏都能在 Toolbar 上面。\n\n在我看来，Material Design发布的已经有点晚了。因为图标动画已出现在发布了的SDK中并且在默认情况下被使用了。\n\n由于某些原因，即使要求把抽屉导航栏布局到其他的view之上，但大多数的google应用还是会有这样的动画(注：在写下这篇文章的时候，Gmail和Inbox已经停用了)，即使你很难发现它（但如果你仔细看的话，在缓慢的移动抽屉式导航时，还是可以看到动画的）。让我很不爽的是：一旦你看到了，又会每次都忍不住去看，得不偿失。因此，我也决定关掉这种动画效果。\n\n第一眼看来，DrawerArrowStyle的参数很容易懂：\n\n[< item name=\"spineBars\"> true < /item>](https://developer.android.com/reference/android/support/v7/mediarouter/R.attr.html#spinBars)\n\n[Android Developers中定义如下：](https://developer.android.com/reference/android/support/v7/appcompat/R.attr.html#spinBars)\n\n> 在移动抽屉导航栏的过程中，无论图标是否应该旋转，都要设定一个布尔值：要么是 true，要么是false.\n\n但问题是，这并不能起到作用。如果你设置为false，bars就会以一种奇怪的方式旋转。\n\n我发现的解决的方式是：覆写onDrawerSlide方法。见下面链接的Gist。\n\n> 既然这个图标动画的可视性较差，那就没有必要再保留它了。如果你不注意看，你就看不到它，但当你注意看并看到的时候，又不知道是怎么回事。\n\n### 资料图片\n\n这张个人头像是圆形的，我们有很多方法能让图片变成圆形，但我每次需要实现这个需求想起的都是 [Romain Guy](https://plus.google.com/+RomainGuy/about) 的[方法](http://www.curious-creature.com/2012/12/11/android-recipe-1-image-with-rounded-corners/comment-page-1/)。所以这次我还是使用了 Romain Guy 的 CircleImageView，毕竟“信RM，无BUG”。有人可能会提到 Google IO 大会上被使用的那个[ App](https://github.com/google/iosched/blob/master/android/src/main/java/com/google/samples/apps/iosched/ui/widget/BezelImageView.java)，我还没去了解过它的具体实现，可能值得我们看一看吧。\n\n在Google Paly Movies与Google Paly Books上，这个图片有一个白色的边框。而其他的Google app上却没有。Google+和Hangouts的资料图片在toolbar上，不过却有白边框。\n\n![](https://d262ilb51hltx0.cloudfront.net/max/800/1*58WoVNOl-JIRyp1o3_f9JQ.jpeg)\n\n![](https://d262ilb51hltx0.cloudfront.net/max/800/1*v5KQiG7MNlpFdCjSk0WHqQ.jpeg)\n\n注意：[查看资料图片大小](https://medium.com/@sotti/navigation-drawer-styling-under-material-design-f0767882e692)\n\n> 资料图片是圆形的，通常没有边框。建议你通过Romain Guy推出的库来获得圆形。\n\n### 封面图片\n\n封面图片（不同于资料图片），是账号/头像部分的背景（就是抽屉式导航的上部，通常你可以在此切换账号，查看昵称，email和你的资料图片）。\n\n这块的文字是白色的，并且要确保能看的见，你可以应用一个前景或者半透明的黑色来覆盖封面图片。我试了一下，发现40-50% 的黑色是最好的。要注意的是，不要既弄得图片不可见，又弄得文字没法读。\n\n我是在FrameLayout中加一个前景。但我不知道这是不是最好的方法，欢迎大家交流。我并没有实现在账号切换的功能，而且这整个layout/section都是可点击的，有touch反馈，或者是Lollipop中的ripple，或者两者。当然你也可以使用[centerCrop ](https://developer.android.com/reference/android/widget/ImageView.ScaleType.html)scaleType 让它更漂亮。\n\n![](https://d262ilb51hltx0.cloudfront.net/max/800/1*JnT0ei6pp-M7Fn0ZZxl-yg.jpeg)\n\n仔细看一下这个图片，你会发现其实它在状态栏下也是可见的。当我写下这行字的时候，Google apps正在应用这种效果。Gmail，Inbox，Keep，Playe Story和Hangouts已经实现了，而其他的也准备实现它。当然，这只是Lollipop及以上的版本中才会有的效果。\n\n![](https://d262ilb51hltx0.cloudfront.net/max/800/1*0K95PBc-Ym1quF4S4-svlw.png)\n\n![](https://d262ilb51hltx0.cloudfront.net/max/800/1*eYUlXFl-nKp54CbhSqHy5Q.png)\n\n即使是现在，在Play Store 上的Google IO 的有些应用的抽屉式导航也是完全错的，但他们在改良代码，并且准备下一个版本了（不过好像有段时间了... 可能会在今年几个月后的Google IO 大会之前更新）\n\n比较神奇的是[Google ScrimInsets layout](http://goo.gl/07TJnm)。拷贝，粘贴，然后自己试着修修改改就OK了。我觉得Google的人员应该比我做的更好。深入的阅读一下gist上的代码，了解一下关于 themes/styles 的更多的详细内容，能让你有更好地表现。\n\n让我有点疑惑就是ScrimInsets layout能不能应用到Lollipop以下的版本中。我知道在Kit Kat中是可行的，但是Google并没这样做。可以肯定的是“挤满”状态栏和/或导航栏在Lollipop下的版本中并不存在，这可能是背后的一个原因。\n\n注意：[查看封面照片的大小](https://medium.com/@sotti/navigation-drawer-styling-under-material-design-f0767882e692)\n\n> 只有在Lollipop中，抽屉导航会出现在状态栏之下。在Lollipop之下的版本中，挤满状态或导航栏并不是什么事情，这可能是其中的原因。\n\n### 可选中行的背景，图标和文字\n\n![](https://d262ilb51hltx0.cloudfront.net/max/800/1*l38m8vKyELP23Fgo0VIYLg.png)\n\n当要更改抽屉中的主要行的样式的时候，对每行的每个元素，我们都要处理其中的三个子元素（背景，图标，文本）和3个不同的状态（默认，选中，点击）。但每一个开发者都需要明白：开发 App 不需要完全遵循[规范](http://www.google.com/design/spec/patterns/navigation-drawer.html) ，但是了解规范又是必不可少的，大家可以看看 Google 的 App 和其他的一些好看的apps是怎样体现 Material Desgin 所包含的思想的，把你从这些 App 里总结出来的东西应用到你的 App 中。\n\nOkay，现在来看一下Google apps 都有哪些特征。在下面的图片中，第一行是默认的状态，第二行是选中的状态，第三行是点击的状态。\n\n![](https://d262ilb51hltx0.cloudfront.net/max/800/1*cbbbhJcPwsrL6XuF_7B-BA.jpeg)\n\n![](https://d262ilb51hltx0.cloudfront.net/max/800/1*S7YeU9ekl1_nC03isgeVBw.jpeg)\n\n![](https://d262ilb51hltx0.cloudfront.net/max/800/1*guYsqqXCcQikqMNMVTL1_g.jpeg)\n\n![](https://d262ilb51hltx0.cloudfront.net/max/800/1*fTlbwdydeGKNznbliR2J-g.jpeg)\n\n![](https://d262ilb51hltx0.cloudfront.net/max/800/1*rzdSKrX4NgQqwPOeNReuTw.jpeg)\n\n![](https://d262ilb51hltx0.cloudfront.net/max/800/1*ubYKjE5BgQUnuf8vXBjucA.jpeg)\n\n![](https://d262ilb51hltx0.cloudfront.net/max/800/1*W0l0rAj_f08DcYiBKhnpYQ.jpeg)\n\n![](https://d262ilb51hltx0.cloudfront.net/max/800/1*WMsmw3UZ6kzBGaMCHPWgHA.jpeg)\n\n![](https://d262ilb51hltx0.cloudfront.net/max/800/1*ZsjyMCtqBLG4iq7_ypaLUA.jpeg)\n\n![](https://d262ilb51hltx0.cloudfront.net/max/800/1*Mn1OyDGujUgv3hXi-bBggw.jpeg)\n\n![](https://d262ilb51hltx0.cloudfront.net/max/800/1*BV3ByPvh4Elbq2MKPrE-Bg.jpeg)\n\n虽然上面的图片看起来很相似，但其实它们是不一样的。总结一下就是：\n\n![](https://d262ilb51hltx0.cloudfront.net/max/800/1*BXfi8inb3rWh0gRCve5uCg.jpeg)\n\n![](https://d262ilb51hltx0.cloudfront.net/max/800/1*0_cj6ynaM0rDvBmQG0WJFw.png)\n\n> Google apps看起来十分的连贯，但是当你注意下细节时就会发现，此时抽屉式导航的选中行有超过10多种的样式。\n\n* 拇指规则：\n\n在自己不断地尝试并参考了设计指南与Google apps后，这是我提出的一些想法：\n\n![](https://d262ilb51hltx0.cloudfront.net/max/800/1*zU5_BF4hNM3ESUqqOyn7Dw.png)\n\n![](https://d262ilb51hltx0.cloudfront.net/max/800/1*X2iLimaiz8NgrdDtbcinFg.jpeg)\n\n### 如何实现\n\n尽管我想知道，但是没人告诉我他是怎么来实现的，所以我自己就这么做了。\n\n首先，使用两个drawable作为背景。一个放在res/drawable-v21里，为Lollipop及以上的版本使用；另一个在res/drawable中，目标是更低的版本。因为ripple在5.0以下的版本中并不存在。\n\n> 仅在Lollipop及以上的版本中使用ripple。Ripples并不支持5.0以下的版本。\n\n每当你点击一行的时候，ripple就会出现，不管它选中与否。因此，你在res/drawable-v21中的是有一组包含ripple的items的selector。这是因为我们希望对于选中和未选中的行，在被点击时都能显示相同的ripple，但是未选中的背景是白色，而选中的item的背景是grey_200。\n\n另外在res/drawable中，你需要的是一个不包含ripple的selector。\n\n### 图标\n\n在最近的几个月里，我尝试让同一图标呈现出不同的颜色来。 因此，我就把所有的图标都先弄成白色，然后在用想要的颜色进行[着色](https://developer.android.com/reference/android/widget/ImageView.html#attr_android:tint)。这样做的优点是，你不必每次创建一个新的图标。[你可以先从Google上得到不同大小和颜色的这些图标](https://github.com/google/material-design-icons)，再用不同的颜色进行二次加工，看看那种效果最好。另外你要是使用不同颜色的同一图标的话，要记得保存成相同的大小。如果你需要根据状态（点击，选中...）来改变它的颜色的话，可以设置一个[color state list resource](https://developer.android.com/guide/topics/resources/color-list-resource.html)。\n\n我实现的方式是在一个[自定义的ImageView](https://github.com/Sottti/MaterialDesignNavDrawer/blob/master/app/src/main/java/com/demo/materialdesignnavdrawer/customViews/TintOnStateImageView.java)中编写的，因为color state list在Kit Kat及其一下的版本中并不可用（android:tint中可以使用color，但是不能用color state）。\n\n看一下下面链接中的gist中我是如何做的。如果你发现了更好的方式，或错误，请反馈给我。\n\n### Header和footer的表现\n\n![](https://d262ilb51hltx0.cloudfront.net/max/800/1*COQpEPm-a2DLqdifPANmzw.png)\n\n头部（aka account section）中有些是不可滑动的，而有些是可滑动的。以我看来，如果可以的话，最好设计成不可滑动的。这样的话，抽屉式导航看起来更美观，连贯，易用。\n\n底部（aka setting and support）可以是可滑动的，也可以不是。如果你看一下Google Apps，就会发现有些是不可滑动的，而有些是在可滑动的scroll的底部。如果你有需求是不能放在抽屉的底部的话，那就放在能滑动的列表的后面。\n\n![](https://d262ilb51hltx0.cloudfront.net/max/800/1*8HEdHs9YQq35OKtsCmAwLQ.png)\n\n![](https://d262ilb51hltx0.cloudfront.net/max/800/1*JW5RFt4JfEahP9tqH3-bPg.png)\n\n再次强调一下，在我看来，不可滑动是最好的方式，但是也可以有例外。比如，当头部不可滑动时，有些条目就被固定了，因此在抽屉里就有了可滚动的区域了。但是如果可滚动的空间太小，那么看起来就很糟糕了（只有一行或两行），要想得到更多的空间，那么一个好的办法就是将footer 解除固定。\n\n> 头部和底部理应被固定住，除非抽屉需要更多的空间以表现更出色。\n\n由于抽屉选项，路径，结构...的不同，因此这里其实并没有什么拇指法则。\n\n### 资源\n-[Google Official Material Design icons](https://github.com/google/material-design-icons)\n-[Material Design Color Definitions](http://www.google.com/design/spec/style/color.html)\n\n### 代码\n\n-[Github项目地址](https://github.com/Sottti/MaterialDesignNavDrawer)\n\n### 总结\n这是关于如何更改抽屉式导航的样式，你仍需要花费很多时间来想清楚你想做成什么样，而这要比做到花费的时间要长的多。\n\n如果你想要了解更改抽屉式导航的样式，请看看另两篇文章。\n\n欢迎评论，反馈... \n\nHava fun！\n" }, { "path": "androidweekly/让你的Android应用能使用多种主题-Part-1/readme.md", "content": "在你的Android App中支持多主题\n---\n\n>\n* 原文链接 : [Supporting multiple themes in your Android app (Part 1)](http://www.hidroh.com/2015/02/16/support-multiple-themes-android-app/)\n* 译者 : [chaossss](https://github.com/chaossss) \n* 校对者: [Mr.Simple](https://github.com/bboyfeiyu) \n* 状态 : 完成\n\n\n![](images/multiple-theme-dark.png)\n![](images/multiple-theme-light.png)\n\n我最近一直在忙着整我的黑客资讯App——Materialistic，今天难得有空，就让我来给大家分享一下我在Materialistic里使用的一个有趣的功能吧。\n\n纵观现在的主流阅读类App，用户最常见的需求就是能够基于自己的阅读习惯选择明亮/灰暗两种风格的主题。为了用户的使用体验，我当然要为Materialistic添加这样的功能啦，要不然没人用我会很伤心的！而且很幸运的是，在Android里支持多种主题的切换并不麻烦（如果你的代码没有问题的话），实现这个功能蛮顺利的。所以今天我打算通过这篇博客给大家介绍我在Materialistic里面为了支持多种主题切换所使用的方法。\n\n准备工作：\n\n1. 你最少要有两个由Android 基本的light/dark主题衍生而来的主题。如果你使用了最新的appcompat-v7包，所对应的就是Theme.AppCompat.Light 或 Theme.AppCompat.Light.DarkActionBar（明亮风格），和Theme.AppCompat（灰暗风格）主题\n\n1. 你需要为你的主题设置颜色。你可以在 [Google design spec](http://www.google.com/design/spec/style/color.html#color-color-palette \" Google design spec website\") 里面看到有关颜色搭配的指导\n\n1. （可选项）为每一个主题的选项菜单图标加上颜色。取决于你的实现方式，染色过程可以是自动的，也可以是手动的，不过自动化的过程不就意味着你可以把一套图标应用于一种主题嘛，其他的调整只要改改颜色就可以了；但就Materialistic的实际需求来考虑，我还是为一个主题预留了多套不同的图标来避免麻烦……\n\n我今天就以明亮风格的主题来开始讲解吧：\n\n## values/styles.xml ##\n\n```xml\n \n```\n\n## values/colors.xml ##\n\n```xml\n \n #FF9800\n #F57C00\n #FFE0B2\n \n #FF5252\n \n #FFFFFF\n #9E9E9E\n \n #DE000000\n #9E9E9E\n```\n\n## AndroidManifest.xml ##\n\n```xml\n \n ...\n \n```\n\ntheme 中涉及的各种属性的含义可以在[Android Developers blog](http://android-developers.blogspot.sg/2014/10/appcompat-v21-material-design-for-pre.html \"Android Developers blog\") 里面找到解释\n\n## 贴心小提示 ##\n\n> 虽然Android里面style的属性/值非常全面，我们想要实现的效果style基本上都包含了有，但是Android文档有关这些主题属性的解释特别少，尤其是对appcompat的解释。所以我们还是建议你写一个小Demo去测试style里面的属性/值应该怎么使用、能实现什么样的效果，然后再根据我们的需求去考虑使用哪些属性/值来实现我们想要的效果。\n\n根据Android的Material Design规范，选项菜单图标的颜色应该和action bar上面的文字颜色保持一致，在我这是通过 android:textColorPrimary 来实现的，也就是使用#FFFFFF，基于这样的规范，我们需要为action bar提供一套白色的选项菜单图标。\n\n## 贴心小提示 ##\n\n> Google 有在 [material-design-icons - Github](https://github.com/google/material-design-icons \"Github\") 上提供一些开源的Material Design图标哦。\n\n## menu/my_menu.xml ##\n\n```xml\n \n \t\n \t\n \t\n \n```\n\n为了使颜色一致，并且能让我们的Views和Texts能够在多个主题下被使用，最好的解决办法就是把颜色变成资源的引用，例如：android:textColor=\"@color/textColorPrimary；又或者是通过设置style来改变，例如：在textEmptyStyle.xml文件下，我们只使用被选中的颜色\n\n## values/styles.xml ##\n\n```xml\n \n```\n\n我相信通过今天在上面所介绍的这些内容已经足够让我们实现一个符合Material Design的明亮风格的主题了，下一篇博文我将会给大家介绍如何实现一个符合Material Design的灰暗风格的主题，以及如何在运行App的过程中切换主题。希望大家继续关注我的博客哦。\n" }, { "path": "androidweekly/让你的Android应用能使用多种主题-Part-2/readme.md", "content": "让你的Android应用能使用多种主题 ( Part 2 )\n---\n\n>\n* 原文链接 : [Supporting multiple themes in your Android app (Part 2)](http://www.hidroh.com/2015/02/25/support-multiple-themes-android-app-part-2/)\n* 译者 : [chaossss](https://github.com/chaossss) \n* 校对者: [Mr.Simple](https://github.com/bboyfeiyu) \n* 状态 : 完成\n\n在 [上一篇博文](http://www.hidroh.com/2015/02/16/support-multiple-themes-android-app/) 中，我们创建了一个明亮风格的主题，并且为实现使用多种主题作了一些前期的准备，而今天呢，我打算在这篇博文中接着上一篇博文继续为大家讲解，而我今天要讲的内容大概是以下三个部分：使 Android 应用能够使用多种主题，创建一个灰暗风格的主题，以及允许 Android 应用在运行时自由地切换不同的主题。\n\n在理想的情况下，如果我们把主题的设置看作是一项配置，那么我们应该能够在类似 \"theme-qualifier\" 的目录下指定我们想要的特定主题，例如：values-dark 就是我们想要的灰暗风格主题；而values-light 则是明亮风格的主题。但很遗憾，在这篇博文所要讲述的实现方法里，这种方法并没有成为实现方式之一。\n\n那么我们要怎么为不同的主题指定相应的资源文件呢？如果我们有了解过 appcompat 是怎么使用资源文件的话，对 Android 系统是如何管理和使用资源文件会有一个粗略的认识。毫无疑问，[Materialistic](https://play.google.com/store/apps/details?id=io.github.hidroh.materialistic) 中使用的方法就是类似于 Android 系统使用的方法。\n\n\n## 主题设置 ##\n\n**values/styles.xml**\n\n```xml\n \n \n \n``` \n\n**values/color.xml**\n\n```xml\n \n ...\n \n ...\n ...\n ...\n\n```\n\n\n在上面的操作中我们创建了一个名叫 AppTheme.Dark 的灰暗风格主题，此外，为了保持 style 和 color 的一致性，我们的 AppTheme.Dark 主题衍生于 appcompat 的 Theme.AppCompat 主题（一个 Android 自带的灰暗风格主题）。然而，由于我们的两个主题（明亮风格和灰暗风格）衍生于不同的基础主题，因此这两个主题之间并不能够进行属性的共享（在JAVA中，类只能进行单继承）。\n\n这两个主题理应有一些恰当的属性值，能同时用于设置基本的 Android 和 appcompat的主题属性，例如：在灰暗风格中，android:textColorPrimary 应该被设置为明亮的，而在明亮风格中，android:textColorPrimary则应该是灰暗的。按照常用的命名习惯，我们在这里将用相反的后缀来区分可替代的主题颜色。\n\n## 温馨小提示 \n\n> 在某些情况下，一种颜色能同时在明亮风格和灰暗风格的主题中被使用，这当然是喜闻乐见的情况，但是在大部分主题中这并不能够实现。所以我希望你在设计主题的过程中，通过在 AndroidManifest.xml 中短暂地切换你应用里正在使用的可替代主题，以此确定你的主题是否需要添加其他的 colors/style 文件来满足你的主题设计需求。\n\n\n## 特定的主题资源文件 \n\n到了现在，我相信我们都能很轻松地为我们的 App 设计出美如画的灰暗风格主题，但这里还存在一些小麻烦，例如：用于美化 action bar 菜单选项的 drawables 资源文件。灰暗风格的 action bar 需要用明亮的颜色修饰它的菜单选项，反之亦然。为了让 Android 能够在不同的App主题下区分不同的 drawables 资源文件，我们创建了能够指定正确资源文件的 [自定义属性](http://developer.android.com/training/custom-views/create-view.html#customattr) 引用，并且在不同的主题下提供了不同的 drawable 引用，将其值赋给特定的自定义属性。（温婉如妻，appcompat 库贴心地为我们准备了类似 colorPrimary 的自定义属性值）\n\n**values/attrs.xml** \n\n```xml\n\n \n \n ...\n```\n\n**values/styles.xml** \n\n```xml\n\n \n \n \n```\n\n**menu/my_menu.xml** \n\n```xml\n \n \t\n \t\t\n \t\t\n \n```\n\n根据你实际的主题设计需要，类似的实现也能被用于为大多数自定义属性指定相应的资源值。但这个方法存在一个问题：根据实际的需要从 drawable 资源文件中解析相应的属性值，并应用于主题的方法在API 21之前的版本似乎都不可行。举例来说明这个问题吧：如果你有一个 layer-list 中包含了各种你所需要的 color 的 drawable 资源文件，在API 21之前的版本中，这些 color 的值都应该是固定的，而不是能够在App运行过程中不断变化的。这个问题在 Google I/O 2014 大会上有被提出，并要求给出相应的解决办法。（详情参见 [Click Me!](https://github.com/google/iosched/commit/dd7ed72a7eb2d223203db079bd99d31c6ef3061e)）。\n\n此外，为了避免在不同的主题中重复使用相同的资源文件，我们可以利用 drawable 的 tint 属性解决这个需求。虽然这个属性可以在API 21之后的版本中使用。但 [Dan Lew](http://blog.danlew.net/2014/08/18/fast-android-asset-theming-with-colorfilter/) 在他的博客中为我们介绍了怎么在所有的 API 版本中使用 tint 属性。但就个人偏好来说，如果可以的话，我会更倾向于选择不受 View 逻辑影响的 Java 实现，所以我选择为每一个主题提供不同的 drawable 资源文件。\n\n## 动态主题切换 \n\n现在我们已经有两个可以使用的主题了，接下来我们需要做的就是让用户能够在使用 App 时能够自如地根据他们的个人偏好切换不同的主题。要实现这个功能，我们可以通过使用 SharedPreferences 来实现，通过改变 pref_dark_theme 的值去存储当前被选择的主题并决定我们的 App 将要被切换成什么主题。但从实际情况来考虑，主题切换后，App 所有 Activity 的 View 在被创建之前都应该被改变，所以我们只需要在 onCreate()方法中实现我们的逻辑。\n\n**BaseActivity.java** \n\n```java\n public abstract class BaseActivity extends ActionBarActivity {\n \t\t @Override\n \t protected void onCreate(Bundle savedInstanceState) {\n \t\t\t if (PreferenceManager.getDefaultSharedPreferences(this)\n \t\t\t\t .getBoolean(\"pref_dark_theme\"), false)) {\n \t\t setTheme(R.style.AppTheme_Dark);\n \t\t}\n \tsuper.onCreate(savedInstanceState);\n \t}\n }\n```\n\n在这里，因为我们的 App 已经使用了默认的明亮风格主题，所以我们只需要检查默认的引用是否被重载，是否被用于重载灰暗风格的主题。为了默认的引用能够被所有 Activity共享，其中的逻辑已经在 \"base\" Activity中被写好了。\n\n值得注意的是，这个方法只能被用于改变没有处在 [back stack](http://developer.android.com/guide/components/tasks-and-back-stack.html) 中的 Acitivity 的主题。而那些已经在 back stack 中的 Activity，仍然会显示为之前的主题，因为当我们结束当前 Activity，返回到上一个 Activity，只会触发 onResume() 方法，而不是我们期望的 onCreate()方法。因此，考虑到实际的产品功能设计需求，我们当然要解决这些“过时”的 Activity 了，我在这里为大家提供了两种解决办法，都挺简单的：一方面，我们可以清空我们的 back stack；另一方面，一旦 preference 被改变，我们就在 back stack 中按照顺序让所有 Acitivty 出栈后重新加载，将所有 Activity 的主题改变后再重新入栈。在这里为了简便，我们选择的实现方法是：当主题被改变，我们就简单地清空 back stack，然后重启当前的 Activity。\n\n## SettingsFragment.java ##\n\n```java\n public class SettingsFragment extends PreferenceFragment {\n \t\t...\n \n \t@Override\n \t\tpublic void onActivityCreated(Bundle savedInstanceState) {\n \t\tsuper.onActivityCreated(savedInstanceState);\n\n \t\tmListener = new SharedPreferences.OnSharedPreferenceChangeListener() {\n \t\t@Override\n \t\tpublic void onSharedPreferenceChanged(SharedPreferences sharedPreferences, String key) {\n \t\t\tif (!key.equals(\"pref_dark_theme\")) {\n \t\t\t\treturn;\n \t\t\t}\n \n \t\tgetActivity().finish();\n\n \t\tfinal Intent intent = getActivity().getIntent();\n \t\tintent.setFlags(Intent.FLAG_ACTIVITY_NEW_TASK | IntentCompat.FLAG_ACTIVITY_CLEAR_TASK);\n \t\tgetActivity().startActivity(intent);\n \t\t}\n \t};\n }\n \n ...\n```\n\n虽然结束得有些突然，但我们今天的讲解就到此结束啦。现在我们的 App 拥有了两个这么优雅的主题，就算是挑剔的文艺小清新也不会嫌弃我们的 App 很 low 了吧！如果你想要了解整个 Materialistic 的具体实现，或者是这个功能的源码，可以来我的 [GitHub](https://github.com/hidroh/materialistic) 上获取哦～" }, { "path": "androidweekly/那些年我们错过的响应式编程/readme.md", "content": "## 那些年我们错过的响应式编程\n---\n\n>\n* 原文链接 : [The introduction to Reactive Programming you've been missing](https://gist.github.com/staltz/868e7e9bc2a7b8c1f754)\n* 作者 : [@andrestaltz](https://twitter.com/andrestaltz)\n* 译者 : [yaoqinwei](https://github.com/yaoqinwei) \n* 校对者: [bboyfeiyu](https://github.com/bboyfeiyu)、[chaossss](https://github.com/chaossss)\n* 状态 : 完成\n\n\n\n\n相信你们在学习响应式编程这个新技术的时候都会充满了好奇，特别是它的一些变体，例如：Rx系列、Bacon.js、RAC等等……\n\n在缺乏优秀资料的前提下，响应式编程的学习过程将满是荆棘。起初，我试图寻找一些教程，却只找到少量的实践指南，而且它们讲的都非常浅显，从来没人接受围绕响应式编程建立一个完整知识体系的挑战。此外，官方文档通常也不能很好地帮助你理解某些函数，因为它们通常看起来很绕，不信请看这里：\n\n> **Rx.Observable.prototype.flatMapLatest(selector, [thisArg])**\n\n> 根据元素下标，将可观察序列中每个元素一一映射到一个新的可观察序列当中，然后...%…………%&￥#@@……&**(晕了)\n\n天呐，这简直太绕了！\n\n我读过两本相关的书，一本只是在给你描绘响应式编程的伟大景象，而另一本却只是深入到如何使用响应式库而已。我在不断的构建项目过程中把响应式编程了解的透彻了一些，最后以这种艰难的方式学完了响应式编程。在我工作公司的一个实际项目中我会用到它，当我遇到问题时，还可以得到同事的支持。\n\n学习过程中最难的部分是**如何以响应式的方式来思考**，更多的意味着要摒弃那些老旧的命令式和状态式的典型编程习惯，并且强迫自己的大脑以不同的范式来运作。我还没有在网络上找到任何一个教程是从这个层面来剖析的，我觉得这个世界非常值得拥有一个优秀的实践教程来教你**如何以响应式编程的方式来思考**，方便引导你开始学习响应式编程。然后看各种库文档才可以给你更多的指引。希望这篇文章能够帮助你快速地进入**响应式编程**的世界。\n\n## \"什是响应式编程?\"\n\n网络上有一大堆糟糕的解释和定义，如[Wikipedia](https://en.wikipedia.org/wiki/Reactive_programming)上通常都是些非常笼统和理论性的解释，而[Stackoverflow](http://stackoverflow.com/questions/1028250/what-is-functional-reactive-programming)上的一些规范的回答显然也不适合新手来参考，[Reactive Manifesto](http://www.reactivemanifesto.org/)看起来也只像是拿给你的PM或者老板看的东西，微软的[Rx术语](https://rx.codeplex.com/)\"Rx = Observables + LINQ + Schedulers\" 也显得太过沉重，而且充满了太多微软式的东西，反而给我们带来更多疑惑。相对于你使用的MV*框架以及你钟爱的编程语言，\"Reactive\"和\"Propagation of change\"这样的术语并没有传达任何有意义的概念。当然，我的view框架能够从model做出反应，我的改变当然也会传播，如果没有这些，我的界面根本就没有东西可渲染。\n\n所以，不要再扯这些废话了。\n\n#### 响应式编程就是与异步数据流交互的编程范式\n\n一方面，这已经不是什么新事物了。事件总线(Event Buses)或一些典型的点击事件本质上就是一个异步事件流(asynchronous event stream)，这样你就可以观察它的变化并使其做出一些反应(do some side effects)。响应式是这样的一个思路：除了点击和悬停(hover)的事件，你还可以给其他任何事物创建数据流。数据流无处不在，任何东西都可以成为一个数据流，例如变量、用户输入、属性、缓存、数据结构等等。举个栗子，你可以把你的微博订阅功能想象成跟点击事件一样的数据流，你可以监听这样的数据流，并做出相应的反应。\n\n**最重要的是，你会拥有一些令人惊艳的函数去结合、创建和过滤任何一组数据流。** 这就是\"函数式编程\"的魔力所在。一个**数据流**可以作为另一个**数据流**的输入，甚至多个**数据流**也可以作为另一个**数据流**的输入。你可以_合并_两个**数据流**，也可以_过滤_一个数据流得到另一个只包含你感兴趣的事件的**数据流**，还可以_映射_一个**数据流**的值到一个新的**数据流**里。\n\n**数据流**是整个响应式编程体系中的核心，要想学习响应式编程，当然要先走进数据流一探究竟了。那现在就让我们先从熟悉的\"点击一个按钮\"的**事件流**开始\n\n![Click event stream](http://img.my.csdn.net/uploads/201504/13/1428914359_2150.png)\n\n一个**数据流**是一个**按时间排序的即将发生的事件(Ongoing events ordered in time)**的序列。如上图，它可以发出3种不同的事件(上一句已经把它们叫做事件)：一个某种类型的**值事件**，一个**错误事件**和一个**完成事件**。当一个**完成事件**发生时，在某些情况下，我们可能会做这样的操作：关闭包含那个按钮的窗口或者视图组件。\n\n我们只能**异步**捕捉被发出的事件，使得我们可以在发出一个**值事件**时执行一个函数，发出**错误事件**时执行一个函数，发出**完成事件**时执行另一个函数。有时候你可以忽略后两个事件，只需聚焦于如何定义和设计在发出**值事件**时要执行的函数，监听这个**事件流**的过程叫做**订阅**，我们定义的函数叫做**观察者**，而事件流就可以叫做被观察的**主题**(或者叫被观察者)。你应该察觉到了，对的，它就是[**观察者模式**](https://en.wikipedia.org/wiki/Observer_pattern)。\n\n上面的示意图我们也可以用ASCII码的形式重新画一遍，请注意，下面的部分教程中我们会继续使用这幅图：\n```\n--a---b-c---d---X---|->\n\na, b, c, d 是值事件\nX 是错误事件\n| 是完成事件\n---> 是时间线(轴)\n```\n\n现在你对响应式编程事件流应该非常熟悉了，为了不让你感到无聊，让我们来做一些新的尝试吧：我们将创建一个由原始点击事件流演变而来的一种新的点击事件流。\n\n首先，让我们来创建一个记录按钮点击次数的事件流。在常用的响应式库中，每个事件流都会附有一些函数，例如 `map`, `filter`, `scan`等，当你调用这其中的一个方法时，比如`clickStream.map(f)`，它会返回基于点击事件流的一个**新事件流**。它不会对原来的点击事件流做任何的修改。这种特性叫做**不可变性(immutability)**，而且它可以和响应式事件流搭配在一起使用，就像豆浆和油条一样完美的搭配。这样我们可以用链式函数的方式来调用，例如：`clickStream.map(f).scan(g)`:\n\n```\n clickStream: ---c----c--c----c------c-->\n vvvvv map(c becomes 1) vvvv\n ---1----1--1----1------1-->\n vvvvvvvvv scan(+) vvvvvvvvv\ncounterStream: ---1----2--3----4------5-->\n```\n\n`map(f)`函数会根据你提供的`f`函数把原事件流中每一个返回值分别映射到新的事件流中。在上图的例子中，我们把每一次点击事件都映射成数字1，`scan(g)`函数则把之前映射的值聚集起来，然后根据`x = g(accumulated, current)`算法来作相应的处理，而本例的`g`函数其实就是简单的加法函数。然后，当一个点击事件发生时，`counterStream`函数则上报当前点击事件总数。\n\n为了展示响应式编程真正的魅力，我们假设你有一个\"双击\"事件流，为了让它更有趣，我们假设这个事件流同时处理\"三次点击\"或者\"多次点击\"事件，然后深吸一口气想想如何用传统的命令式和状态式的方式来处理，我敢打赌，这么做会相当的讨厌，其中还要涉及到一些变量来保存状态，并且还得做一些时间间隔的调整。\n\n而用响应式编程的方式处理会非常的简洁，实际上，逻辑处理部分只需要[四行代码](http://jsfiddle.net/staltz/4gGgs/27/)。但是，当前阶段让我们现忽略代码的部分，无论你是新手还是专家，看着图表思考来理解和建立事件流将是一个非常棒的方法。\n\n![多次点击事件流](http://img.my.csdn.net/uploads/201504/13/1428914360_6429.png)\n\n图中，灰色盒子表示将上面的事件流转换下面的事件流的**函数**过程，首先根据250毫秒的间隔时间(event silence, 译者注：无事件发生的时间段，上一个事件发生到下一个事件发生的间隔时间)把点击事件流一段一隔开，再将每一段的一个或多个点击事件添加到列表中(这就是这个函数：`buffer(stream.throttle(250ms))`所做的事情，当前我们先不要急着去理解细节，我们只需专注响应式的部分先)。现在我们得到的是多个含有事件流的列表，然后我们使用了`map()`中的函数来算出每一个列表长度的整数数值映射到下一个事件流当中。最后我们使用了过滤`filter(x >= 2)` 函数忽略掉了小于`1` 的整数。就这样，我们用了3步操作生成了我们想要的事件流，接下来，我们就可以订阅(\"监听\")这个事件并作出我们想要的操作了。\n\n我希望你能感受到这个示例的优雅之处。当然了，这个示例也只是响应式编程魔力的冰山一角而已，你同样可以将这3步操作应用到不同种类的事件流中去，例如，一串API响应的事件流。另一方面，你还有非常多的函数可以使用。\n\n## \"我为什么要采用响应式编程？\"\n\n响应式编程可以加深你代码抽象的程度，让你可以更专注于定义与事件相互依赖的业务逻辑，而不是把大量精力放在实现细节上，同时，使用响应式编程还能让你的代码变得更加简洁。\n\n特别对于现在流行的webapps和mobile apps，它们的 UI 事件与数据频繁地产生交互，在开发这些应用时使用响应式编程的优点将更加明显。十年前，web页面的交互是通过提交一个很长的表单数据到后端，然后再做一些简单的前端渲染操作。而现在的Apps则演变的更具有实时性：仅仅修改一个单独的表单域就能自动的触发保存到后端的代码，就像某个用户对一些内容点了赞，就能够实时反映到其他已连接的用户一样，等等。\n\n当今的Apps都含有丰富的实时事件来保证一个高效的用户体验，我们就需要采用一个合适的工具来处理，那么响应式编程就正好是我们想要的答案。\n\n## 以响应式编程方式思考的例子\n\n让我们深入到一些真实的例子，一个能够一步一步教你如何以响应式编程的方式思考的例子，没有虚构的示例，没有一知半解的概念。在这个教程的末尾我们将产生一些真实的函数代码，并能够知晓每一步为什么那样做的原因(知其然，知其所以然)。\n\n我选了**JavaScript**和**[RxJS](https://github.com/Reactive-Extensions/RxJS)**来作为本教程的编程语言，原因是：JavaScript是目前最多人熟悉的语言，而[Rx系列的库](http://www.reactivex.io)对于很多语言和平台的运用是非常广泛的，例如([.NET](https://rx.codeplex.com/), [Java](https://github.com/Netflix/RxJava), [Scala](https://github.com/Netflix/RxJava/tree/master/language-adaptors/rxjava-scala), [Clojure](https://github.com/Netflix/RxJava/tree/master/language-adaptors/rxjava-clojure), [JavaScript](https://github.com/Reactive-Extensions/RxJS), [Ruby](https://github.com/Reactive-Extensions/Rx.rb), [Python](https://github.com/Reactive-Extensions/RxPy), [C++](https://github.com/Reactive-Extensions/RxCpp), [Objective-C/Cocoa](https://github.com/ReactiveCocoa/ReactiveCocoa), [Groovy](https://github.com/Netflix/RxJava/tree/master/language-adaptors/rxjava-groovy)等等。所以，无论你用的是什么语言、库、工具，你都能从下面这个教程中学到东西(从中受益)。\n\n## 实现一个推荐关注(Who to follow)的功能\n\n在Twitter里有一个UI元素向你推荐你可以关注的用户，如下图：\n\n![Twitter Who to follow suggestions box](http://img.my.csdn.net/uploads/201504/13/1428914371_1788.png)\n\n我们将聚焦于模仿它的主要功能，它们是：\n\n* 开始阶段，从API加载推荐关注的用户账户数据，然后显示三个推荐用户\n* 点击刷新，加载另外三个推荐用户到当前的三行中显示\n* 点击每一行的推荐用户上的'x'按钮，清楚当前被点击的用户，并显示新的一个用户到当前行\n* 每一行显示一个用户的头像并且在点击之后可以链接到他们的主页。\n\n我们可以先不管其他的功能和按钮，因为它们是次要的。因为Twitter最近关闭了未经授权的公共API调用，我们将用[Github获取用户的API](https://developer.github.com/v3/users/#get-all-users)代替，并且以此来构建我们的UI。\n\n如果你想先看一下最终效果，这里有完成后的[代码](http://jsfiddle.net/staltz/8jFJH/48/)。\n\n## Request和Response\n\n**在Rx中是怎么处理这个问题呢？**，在开始之前，我们要明白，(几乎)_一切都可以成为一个事件流_，这就是Rx的准则(mantra)。让我们从最简单的功能开始：\"开始阶段，从API加载推荐关注的用户账户数据，然后显示三个推荐用户\"。其实这个功能没什么特殊的，简单的步骤分为： (1)发出一个请求，(2)获取响应数据，(3)渲染响应数据。ok，让我们把请求作为一个事件流，一开始你可能会觉得这样做有些夸张，但别急，我们也得从最基本的开始，不是吗？\n\n开始时我们只需做一次请求，如果我们把它作为一个数据流的话，它只能成为一个仅仅返回一个值的事件流而已。一会儿我们还会有很多请求要做，但当前，只有一个。\n\n```\n--a------|->\n\na就是字符串：'https://api.github.com/users'\n```\n\n这是一个我们要请求的URL事件流。每当发生一个请求时，它将告诉我们两件事：**什么时候**和**做了什么事**(when and what)。**什么时候**请求被执行，什么时候事件就被发出。而**做了什么**就是请求了什么，也就是请求的URL字符串。\n\n在Rx中，创建返回一个值的事件流是非常简单的。其实事件流在Rx里的术语是叫\"被观察者\"，也就是说它是可以被观察的，但是我发现这名字比较傻，所以我更喜欢把它叫做_事件流_。\n\n```javascript\nvar requestStream = Rx.Observable.just('https://api.github.com/users');\n```\n\n但现在，这只是一个字符串的事件流而已，并没有做其他操作，所以我们需要在发出这个值的时候做一些我们要做的操作，可以通过[订阅(subscribing)](https://github.com/Reactive-Extensions/RxJS/blob/master/doc/api/core/observable.md#rxobservableprototypesubscribeobserver--onnext-onerror-oncompleted)这个事件来实现。\n\n```javascript\nrequestStream.subscribe(function(requestUrl) {\n // execute the request\n jQuery.getJSON(requestUrl, function(responseData) {\n // ...\n });\n}\n```\n\n注意到我们这里使用的是JQuery的AJAX回调方法(我们假设你[已经很了解JQuery和AJAX了](http://devdocs.io/jquery/jquery.getjson))来的处理这个异步的请求操作。但是，请稍等一下，Rx就是用来处理**异步数据流**的，难道它就不能处理来自请求(request)在未来某个时间响应(response)的数据流吗？好吧，理论上是可以的，让我们尝试一下。\n\n```javascript\nrequestStream.subscribe(function(requestUrl) {\n // execute the request\n var responseStream = Rx.Observable.create(function (observer) {\n jQuery.getJSON(requestUrl)\n .done(function(response) { observer.onNext(response); })\n .fail(function(jqXHR, status, error) { observer.onError(error); })\n .always(function() { observer.onCompleted(); });\n });\n \n responseStream.subscribe(function(response) {\n // do something with the response\n });\n}\n```\n\n[`Rx.Observable.create()`](https://github.com/Reactive-Extensions/RxJS/blob/master/doc/api/core/observable.md#rxobservablecreatesubscribe)操作就是在创建自己定制的事件流，且对于数据事件(`onNext()`)和错误事件(`onError()`)都会显示的通知该事件每一个观察者(或订阅者)。我们做的只是小小的封装一下jQuery Ajax Promise而已。**等等，这是否意味者jQuery Ajax Promise本质上就是一个被观察者呢(Observable)？**\n\n![Amazed](http://img.my.csdn.net/uploads/201504/13/1428914359_8403.gif)\n\n是的。\n\nPromise++就是被观察者(Observable)，在Rx里你可以使用这样的操作：`var stream = Rx.Observable.fromPromise(promise)`，就可以很轻松的将Promise转换成一个被观察者(Observable)，非常简单的操作就能让我们现在就开始使用它。不同的是，这些被观察者都不能兼容[Promises/A+](http://promises-aplus.github.io/promises-spec/)，但理论上并不冲突。一个Promise就是一个只有一个返回值的简单的被观察者，而Rx就远超于Promise，它允许多个值返回。\n\n这样更好，这样更突出被观察者至少比Promise强大，所以如果你相信Promise宣传的东西，那么也请留意一下响应式编程能胜任些什么。\n\n现在回到示例当中，你应该能快速发现，我们在`subscribe()`方法的内部再次调用了`subscribe()`方法，这有点类似于回调地狱(callback hell)，而且`responseStream`的创建也是依赖于`requestStream`的。在之前我们说过，在Rx里，有很多很简单的机制来从其他事件流的转化并创建出一些新的事件流，那么，我们也应该这样做试试。\n\n现在你需要了解的一个最基本的函数是[`map(f)`](https://github.com/Reactive-Extensions/RxJS/blob/master/doc/api/core/observable.md#rxobservableprototypemapselector-thisarg)，它可以从事件流A中取出每一个值，并对每一个值执行`f()`函数，然后将产生的新值填充到事件流B。如果将它应用到我们的请求和响应事件流当中，那我们就可以将请求的URL映射到一个响应Promises上了(伪装成数据流)。\n\n```javascript\nvar responseMetastream = requestStream\n .map(function(requestUrl) {\n return Rx.Observable.fromPromise(jQuery.getJSON(requestUrl));\n });\n```\n\n然后，我们创造了一个叫做\"_metastream_\"的怪兽：一个装载了事件流的事件流。先别惊慌，metastream就是每一个发出的值都是另一个事件流的事件流，你看把它想象成一个[指针(pointers)]((https://en.wikipedia.org/wiki/Pointer_(computer_programming))数组：每一个单独发出的值就是一个_指针_，它指向另一个事件流。在我们的示例里，每一个请求URL都映射到一个指向包含响应数据的promise数据流。\n\n![Response metastream](http://img.my.csdn.net/uploads/201504/13/1428914360_7454.png)\n\n一个响应的metastream，看起来确实让人容易困惑，看样子对我们一点帮助也没有。我们只想要一个简单的响应数据流，每一个发出的值是一个简单的JSON对象就行，而不是一个'Promise' 的JSON对象。ok，让我们来见识一下另一个函数：[Flatmap](https://github.com/Reactive-Extensions/RxJS/blob/master/doc/api/core/observable.md#rxobservableprototypeflatmapselector-resultselector)，它是`map()`函数的另一个版本，它比metastream更扁平。一切在\"主躯干\"事件流发出的事件都将在\"分支\"事件流中发出。Flatmap并不是metastreams的修复版，metastreams也不是一个bug。它俩在Rx中都是处理异步响应事件的好工具、好帮手。\n\n```javascript\nvar responseStream = requestStream\n .flatMap(function(requestUrl) {\n return Rx.Observable.fromPromise(jQuery.getJSON(requestUrl));\n });\n```\n\n![Response stream](http://img.my.csdn.net/uploads/201504/13/1428914371_2167.png)\n\n很赞，因为我们的响应事件流是根据请求事件流定义的，**如果**我们以后有更多事件发生在请求事件流的话，我们也将会在相应的响应事件流收到响应事件，就如所期待的那样：\n\n```\nrequestStream: --a-----b--c------------|->\nresponseStream: -----A--------B-----C---|->\n\n(小写的是请求事件流, 大写的是响应事件流)\n```\n\n现在，我们终于有响应的事件流了，并且可以用我们收到的数据来渲染了：\n\n```javascript\nresponseStream.subscribe(function(response) {\n // render `response` to the DOM however you wish\n});\n```\n\n让我们把所有代码合起来，看一下：\n\n```javascript\nvar requestStream = Rx.Observable.just('https://api.github.com/users');\n\nvar responseStream = requestStream\n .flatMap(function(requestUrl) {\n return Rx.Observable.fromPromise(jQuery.getJSON(requestUrl));\n });\n\nresponseStream.subscribe(function(response) {\n // render `response` to the DOM however you wish\n});\n```\n\n## 刷新按钮\n\n我还没提到本次响应的JSON数据是含有100个用户数据的list，这个API只允许指定页面偏移量(page offset)，而不能指定每页大小(page size)，我们只用到了3个用户数据而浪费了其他97个，现在可以先忽略这个问题，稍后我们将学习如何缓存响应的数据。\n\n每当刷新按钮被点击，请求事件流就会发出一个新的URL值，这样我们就可以获取新的响应数据。这里我们需要两个东西：点击刷新按钮的事件流(准则：一切都能作为事件流)，我们需要将点击刷新按钮的事件流作为请求事件流的依赖(即点击刷新事件流会引起请求事件流)。幸运的是，RxJS已经有了可以从事件监听者转换成被观察者的方法了。\n\n```javascript\nvar refreshButton = document.querySelector('.refresh');\nvar refreshClickStream = Rx.Observable.fromEvent(refreshButton, 'click');\n```\n\n因为刷新按钮点击事件不会携带将要请求的API的URL，我们需要将每次的点击映射到一个实际的URL上，现在我们将请求事件流转换成了一个点击事件流，并将每次的点击映射成一个随机的页面偏移量(offset)参数来组成API的URL。\n\n```javascript\nvar requestStream = refreshClickStream\n .map(function() {\n var randomOffset = Math.floor(Math.random()*500);\n return 'https://api.github.com/users?since=' + randomOffset;\n });\n```\n\n因为我比较笨而且也没有使用自动化测试，所以我刚把之前做好的一个功能搞烂了。这样，请求在一开始的时候就不会执行，而只有在点击事件发生时才会执行。我们需要的是两种情况都要执行：刚开始打开网页和点击刷新按钮都会执行的请求。\n\n我们知道如何为每一种情况做一个单独的事件流：\n\n```javascript\nvar requestOnRefreshStream = refreshClickStream\n .map(function() {\n var randomOffset = Math.floor(Math.random()*500);\n return 'https://api.github.com/users?since=' + randomOffset;\n });\n \nvar startupRequestStream = Rx.Observable.just('https://api.github.com/users');\n```\n\n但是我们是否可以将这两个合并成一个呢？没错，是可以的，我们可以使用[`merge()`](https://github.com/Reactive-Extensions/RxJS/blob/master/doc/api/core/observable.md#rxobservableprototypemergemaxconcurrent--other)方法来实现。下图可以解释`merge()`函数的用处：\n\n```\nstream A: ---a--------e-----o----->\nstream B: -----B---C-----D-------->\n vvvvvvvvv merge vvvvvvvvv\n ---a-B---C--e--D--o----->\n```\n\n现在做起来应该很简单：\n\n```javascript\nvar requestOnRefreshStream = refreshClickStream\n .map(function() {\n var randomOffset = Math.floor(Math.random()*500);\n return 'https://api.github.com/users?since=' + randomOffset;\n });\n \nvar startupRequestStream = Rx.Observable.just('https://api.github.com/users');\n\nvar requestStream = Rx.Observable.merge(\n requestOnRefreshStream, startupRequestStream\n);\n```\n\n还有一个更干净的写法，省去了中间事件流变量：\n\n```javascript\nvar requestStream = refreshClickStream\n .map(function() {\n var randomOffset = Math.floor(Math.random()*500);\n return 'https://api.github.com/users?since=' + randomOffset;\n })\n .merge(Rx.Observable.just('https://api.github.com/users'));\n```\n\n甚至可以更简短，更具有可读性：\n```javascript\nvar requestStream = refreshClickStream\n .map(function() {\n var randomOffset = Math.floor(Math.random()*500);\n return 'https://api.github.com/users?since=' + randomOffset;\n })\n .startWith('https://api.github.com/users');\n```\n\n[`startWith()`](https://github.com/Reactive-Extensions/RxJS/blob/master/doc/api/core/observable.md#rxobservableprototypestartwithscheduler-args)函数做的事和你预期的完全一样。无论你的输入事件流是怎样的，使用`startWith(x)`函数处理过后输出的事件流一定是一个`x` 开头的结果。但是我没有总是[重复代码( DRY)](https://en.wikipedia.org/wiki/Don't_repeat_yourself)，我只是在重复API的URL字符串，改进的方法是将 `startWith()`函数挪到`refreshClickStream`那里，这样就可以在启动时，模拟一个刷新按钮的点击事件了。\n\n```javascript\nvar requestStream = refreshClickStream.startWith('startup click')\n .map(function() {\n var randomOffset = Math.floor(Math.random()*500);\n return 'https://api.github.com/users?since=' + randomOffset;\n });\n```\n\n不错，如果你倒回到\"搞烂了的自动测试\"的地方，然后再对比这两个地方，你会发现我仅仅是加了一个`startWith()`函数而已。\n\n## 用事件流将3个推荐的用户数据模型化\n\n直到现在，在响应事件流(responseStream)的订阅(`subscribe()`)函数发生的渲染步骤里，我们只是稍微提及了一下_推荐关注_的UI。现在有了刷新按钮，我们就会出现一个问题：当你点击了刷新按钮，当前的三个推荐关注用户没有被清楚，而只要响应的数据达到后我们就拿到了新的推荐关注的用户数据，为了让UI看起来更漂亮，我们需要在点击刷新按钮的事件发生的时候清楚当前的三个推荐关注的用户。\n\n```javascript\nrefreshClickStream.subscribe(function() {\n // clear the 3 suggestion DOM elements \n});\n```\n\n不，老兄，还没那么快。我们又出现了新的问题，因为我们现在有两个订阅者在影响着推荐关注的UI DOM元素(另一个是 `responseStream.subscribe()`)，这看起来并不符合[关注分离(Separation of concerns)](https://en.wikipedia.org/wiki/Separation_of_concerns)原则，还记得响应式编程的原则么？\n\n![Mantra](http://i.imgur.com/AIimQ8C.jpg)\n\n现在，让我们把推荐关注的用户数据模型化成事件流形式，每个被发出的值是一个包含了推荐关注用户数据的JSON对象。我们将把这三个用户数据分开处理，下面是推荐关注的1号用户数据的事件流：\n\n```javascript\nvar suggestion1Stream = responseStream\n .map(function(listUsers) {\n // get one random user from the list\n return listUsers[Math.floor(Math.random()*listUsers.length)];\n });\n```\n\n其他的，如推荐关注的2号用户数据的事件流`suggestion2Stream`和推荐关注的3号用户数据的事件流`suggestion3Stream` 都可以方便的从`suggestion1Stream` 复制粘贴就好。这里并不是**重复代码**，只是为让我们的示例更加简单，而且我认为这是一个思考如何避免**重复代码**的好案例。\n\nInstead of having the rendering happen in responseStream's subscribe(), we do that here:\n\n```javascript\nsuggestion1Stream.subscribe(function(suggestion) {\n // render the 1st suggestion to the DOM\n});\n```\n\n我们不在responseStream的subscribe()中处理渲染了，我们这样处理：\n\n```javascript\nsuggestion1Stream.subscribe(function(suggestion) {\n // render the 1st suggestion to the DOM\n});\n```\n\n回到\"当刷新时，清楚掉当前的推荐关注的用户\"，我们可以很简单的把刷新点击映射为没有推荐数据(`null` suggestion data)，并且在`suggestion1Stream`中包含进来，如下：\n\n```javascript\nvar suggestion1Stream = responseStream\n .map(function(listUsers) {\n // get one random user from the list\n return listUsers[Math.floor(Math.random()*listUsers.length)];\n })\n .merge(\n refreshClickStream.map(function(){ return null; })\n );\n```\n\n当渲染时，我们将 `null`解释为\"没有数据\"，然后把UI元素隐藏起来。\n\n```javascript\nsuggestion1Stream.subscribe(function(suggestion) {\n if (suggestion === null) {\n // hide the first suggestion DOM element\n }\n else {\n // show the first suggestion DOM element\n // and render the data\n }\n});\n```\n\n现在我们大概的示意图如下：\n\n```\nrefreshClickStream: ----------o--------o---->\n requestStream: -r--------r--------r---->\n responseStream: ----R---------R------R--> \n suggestion1Stream: ----s-----N---s----N-s-->\n suggestion2Stream: ----q-----N---q----N-q-->\n suggestion3Stream: ----t-----N---t----N-t-->\n```\n\n`N`代表`null`\n\n作为一种补充，我们可以在一开始的时候就渲染空的推荐内容。这通过把startWith(null)添加到推荐关注的事件流就可以了：\n\n```javascript\nvar suggestion1Stream = responseStream\n .map(function(listUsers) {\n // get one random user from the list\n return listUsers[Math.floor(Math.random()*listUsers.length)];\n })\n .merge(\n refreshClickStream.map(function(){ return null; })\n )\n .startWith(null);\n```\n\n结果是这样的：\n\n```\nrefreshClickStream: ----------o---------o---->\n requestStream: -r--------r---------r---->\n responseStream: ----R----------R------R--> \n suggestion1Stream: -N--s-----N----s----N-s-->\n suggestion2Stream: -N--q-----N----q----N-q-->\n suggestion3Stream: -N--t-----N----t----N-t-->\n```\n\n## 推荐关注的关闭和使用已缓存的响应数据(responses)\n\n只剩这一个功能没有实现了，每个推荐关注的用户UI会有一个'x'按钮来关闭自己，然后在当前的用户数据UI中加载另一个推荐关注的用户。最初的想法是：点击任何关闭按钮时都需要发起一个新的请求：\n\n```javascript\nvar close1Button = document.querySelector('.close1');\nvar close1ClickStream = Rx.Observable.fromEvent(close1Button, 'click');\n// and the same for close2Button and close3Button\n\nvar requestStream = refreshClickStream.startWith('startup click')\n .merge(close1ClickStream) // we added this\n .map(function() {\n var randomOffset = Math.floor(Math.random()*500);\n return 'https://api.github.com/users?since=' + randomOffset;\n });\n```\n\n这样没什么效果，这样会关闭和重新加载_全部_的推荐关注用户，而不仅仅是处理我们点击的那一个。这里有几种方式来解决这个问题，并且让它变得有趣，我们将重用之前的请求数据来解决这个问题。这个API响应的每页数据大小是100个用户数据，而我们只使用了其中三个，所以还有一大堆未使用的数据可以拿来用，不用去请求更多数据了。\n\nok，再来，我们继续用事件流的方式来思考。当'close1'点击事件发生时，我们想要使用_最近发出的_响应数据，并执行`responseStream`函数来从响应列表里随机的抽出一个用户数据来，就像下面这样：\n\n```\n requestStream: --r--------------->\n responseStream: ------R----------->\nclose1ClickStream: ------------c----->\nsuggestion1Stream: ------s-----s----->\n```\n\n在Rx中一个组合函数叫做[`combineLatest`](https://github.com/Reactive-Extensions/RxJS/blob/master/doc/api/core/observable.md#rxobservableprototypecombinelatestargs-resultselector)，应该是我们需要的。这个函数会把数据流A和数据流B作为输入，并且无论哪一个数据流发出一个值了，`combineLatest` 函数就会将从两个数据流最近发出的值`a`和`b`作为`f`函数的输入，计算后返回一个输出值(`c = f(x,y)`)，下面的图表会让这个函数的过程看起来会更加清晰：\n\n```\nstream A: --a-----------e--------i-------->\nstream B: -----b----c--------d-------q---->\n vvvvvvvv combineLatest(f) vvvvvvv\n ----AB---AC--EC---ED--ID--IQ---->\n\nf是转换成大写的函数\n```\n\n这样，我们就可以把`combineLatest()`函数用在`close1ClickStream`和 `responseStream`上了，只要关闭按钮被点击，我们就可以获得最近的响应数据，并在`suggestion1Stream`上产生出一个新值。另一方面，`combineLatest()`函数也是相对的：每当在`responseStream`上发出一个新的响应，它将会结合一次新的`点击关闭按钮事件`来产生一个新的推荐关注的用户数据，这非常有趣，因为它可以给我们的`suggestion1Stream`简化代码：\n\n```javascript\nvar suggestion1Stream = close1ClickStream\n .combineLatest(responseStream, \n function(click, listUsers) {\n return listUsers[Math.floor(Math.random()*listUsers.length)];\n }\n )\n .merge(\n refreshClickStream.map(function(){ return null; })\n )\n .startWith(null);\n```\n\n现在，我们的拼图还缺一小块地方。`combineLatest()`函数使用了最近的两个数据源，但是如果某一个数据源还没有发出任何东西，`combineLatest()`函数就不能在输出流上产生一个数据事件。如果你看了上面的ASCII图表(文章中第一个图表)，你会明白当第一个数据流发出一个值`a`时并没有任何的输出，只有当第二个数据流发出一个值`b`的时候才会产生一个输出值。\n\n这里有很多种方法来解决这个问题，我们使用最简单的一种，也就是在启动的时候模拟'close 1'的点击事件：\n\n```javascript\nvar suggestion1Stream = close1ClickStream.startWith('startup click') // we added this\n .combineLatest(responseStream, \n function(click, listUsers) {l\n return listUsers[Math.floor(Math.random()*listUsers.length)];\n }\n )\n .merge(\n refreshClickStream.map(function(){ return null; })\n )\n .startWith(null);\n```\n\n## 封装起来\n\n我们完成了，下面是封装好的完整示例代码：\n\n```javascript\nvar refreshButton = document.querySelector('.refresh');\nvar refreshClickStream = Rx.Observable.fromEvent(refreshButton, 'click');\n\nvar closeButton1 = document.querySelector('.close1');\nvar close1ClickStream = Rx.Observable.fromEvent(closeButton1, 'click');\n// and the same logic for close2 and close3\n\nvar requestStream = refreshClickStream.startWith('startup click')\n .map(function() {\n var randomOffset = Math.floor(Math.random()*500);\n return 'https://api.github.com/users?since=' + randomOffset;\n });\n\nvar responseStream = requestStream\n .flatMap(function (requestUrl) {\n return Rx.Observable.fromPromise($.ajax({url: requestUrl}));\n });\n\nvar suggestion1Stream = close1ClickStream.startWith('startup click')\n .combineLatest(responseStream, \n function(click, listUsers) {\n return listUsers[Math.floor(Math.random()*listUsers.length)];\n }\n )\n .merge(\n refreshClickStream.map(function(){ return null; })\n )\n .startWith(null);\n// and the same logic for suggestion2Stream and suggestion3Stream\n\nsuggestion1Stream.subscribe(function(suggestion) {\n if (suggestion === null) {\n // hide the first suggestion DOM element\n }\n else {\n // show the first suggestion DOM element\n // and render the data\n }\n});\n```\n\n**你可以在[这里](http://jsfiddle.net/staltz/8jFJH/48/)看到可演示的示例工程**\n\n以上的代码片段虽小但做到很多事：它适当的使用关注分离(separation of concerns)原则的实现了对多个事件流的管理，甚至做到了响应数据的缓存。这种函数式的风格使得代码看起来更像是声明式编程而非命令式编程：我们并不是在给一组指令去执行，只是定义了事件流之间关系来**告诉它这是什么**。例如，我们用Rx来告诉计算机_`suggestion1Stream`**是**'close 1'事件结合从最新的响应数据中拿到的一个用户数据的数据流，除此之外，当刷新事件发生时和程序启动时，它就是`null`_。\n\n留意一下代码中并未出现例如`if`, `for`, `while`等流程控制语句，或者像JavaScript那样典型的基于回调(callback-based)的流程控制。如果可以的话(稍候会给你留一些实现细节来作为练习)，你甚至可以在`subscribe()`上使用 `filter()`函数来摆脱`if`和`else`。在Rx里，我们有例如： `map`, `filter`, `scan`, `merge`, `combineLatest`, `startWith`等数据流的函数，还有很多函数可以用来控制**事件驱动编程(event-driven program)**的流程。这些函数的集合可以让你使用更少的代码实现更强大的功能。\n\n## 接下来\n\n如果你认为Rx将会成为你首选的响应式编程库，接下来就需要花一些时间来熟悉[一大批的函数](https://github.com/Reactive-Extensions/RxJS/blob/master/doc/api/core/observable.md)用来变形、联合和创建被观察者。如果你想在事件流的图表当中熟悉这些函数，那就来看一下这个：[RxJava's very useful documentation with marble diagrams](https://github.com/Netflix/RxJava/wiki/Creating-Observables)。请记住，无论何时你遇到问题，可以画一下这些图，思考一下，看一看这一大串函数，然后继续思考。以我个人经验，这样效果很有效。\n\n一旦你开始使用了Rx编程，请记住，理解[Cold vs Hot Observables](https://github.com/Reactive-Extensions/RxJS/blob/master/doc/gettingstarted/creating.md#cold-vs-hot-observables)的概念是非常必要的，如果你忽视了这一点，它就会反弹回来并残忍的反咬你一口。我这里已经警告你了，学习函数式编程可以提高你的技能，熟悉一些常见问题，例如Rx会带来的副作用\n\n但是响应式编程库并不仅仅是Rx，还有相对容易理解的，没有Rx那些怪癖的[Bacon.js](http://baconjs.github.io/)。[Elm Language](http://elm-lang.org/)则以它自己的方式支持响应式编程：它是一门会编译成Javascript + HTML + CSS的响应式编程语言，并有一个[time travelling debugger](http://debug.elm-lang.org/)功能，很棒吧。\n\n而Rx对于像前端和App这样需要处理大量的编程效果是非常棒的。但是它不只是可以用在客户端，还可以用在后端或者接近数据库的地方。事实上，[RxJava就是Netflix服务端API用来处理并行的组件](http://techblog.netflix.com/2013/02/rxjava-netflix-api.html)。Rx并不是局限于某种应用程序或者编程语言的框架，它真的是你编写任何事件驱动程序，可以遵循的一个非常棒的编程范式。\n\n如果这篇教程对你有帮助, [那么就请来转发一下吧(tweet it forward)](https://twitter.com/intent/tweet?original_referer=https%3A%2F%2Fgist.github.com%2Fstaltz%2F868e7e9bc2a7b8c1f754%2F&text=The%20introduction%20to%20Reactive%20Programming%20you%27ve%20been%20missing&tw_p=tweetbutton&url=https%3A%2F%2Fgist.github.com%2Fstaltz%2F868e7e9bc2a7b8c1f754&via=andrestaltz).\n" }, { "path": "authorization.md", "content": "# 作者授权列表\nAndroid开发技术前线翻译的文章都尽可能的找到原作者的联系方式，然后获得文章作者的翻译授权，原文也将保留原文链接和作者名。下面是目前已获得授权的作者列表。\n\n| 作者 | 博客地址 | 授权状态 | 联系人 |备注 |\n|-------|---------|-----------|-----------|--------|\n| Romain Guy | http://www.curious-creature.com/ | 已授权 | Mr.Simple | email |\n| Mark Allison | https://blog.stylingandroid.com/ | 已授权 | Mr.Simple| 需要遵循Creative Commons [Attribution-NonCommercial-ShareAlike 4.0 International](http://creativecommons.org/licenses/by-nc-sa/4.0/) 协议 |\n| Mark Richards | http://www.wmrichards.com/ | 沟通中 | Mr.Simple| 翻译的是《软件架构模式》免费电子书，需要跟O‘Reilly的编辑沟通 |\n| Hannes Dorfmann | http://hannesdorfmann.com/ | 沟通中 | Mr.Simple| g+沟通中 |\n| Ravi Tamada | http://www.androidhive.info/ | 沟通中 | Mr.Simple| g+沟通中 |\n| nuunei | http://inthecheesefactory.com/blog | 沟通中 | Mr.Simple| 博客留言沟通中 |\n| inovex | [http://blog.inovex.de](http://blog.inovex.de) | 沟通中 | Mr.Simple| facebook留言沟通中 |\n| Alex Lockwood | [http://www.androiddesignpatterns.com/](http://www.androiddesignpatterns.com/) | 已授权 | Mr.Simple| google+ |\n| Robert Martin (Bob大叔) | [Clean Coder](https://sites.google.com/site/unclebobconsultingllc/) 和 [http://blog.8thlight.com/](http://blog.8thlight.com/) | 沟通中 | Mr.Simple| 沟通中 |\n| Zaitsev Serge | [Zaitsev Serge](http://zserge.com/blog.html) | 已授权 | Mr.Simple| 沟通中 |\n| flavien Laurent | [flavien Laurent](http://flavienlaurent.com/) | 已授权 | Mr.Simple| 沟通中 |\n\n" }, { "path": "git简单使用教程.md", "content": "#git简单教程 (适用于参与开发技术前线)\n\n## 1、git的安装与配置\n[Git详解之一：Git起步](http://blog.jobbole.com/25775/)\n\n## 2、参与开发技术前线的项目\n\n1. 首先到[iOS-tech-frontier](https://github.com/bboyfeiyu/iOS-tech-frontier),将该仓库fork(右上角)到你的个人账户下，因此你首先需要注册一个github账户；\n2. 用命令行进入到你的某个目录下，然后输入如下命令 : `git clone https://github.com/这里替换为你的用户名/iOS-tech-frontier`将你fork的那份克隆下来；\n3. 进入到iOS-tech-frontier目录中，在对应期数的文件夹中(例如,issue-2代表第二期)创建你的文章文件，例如:swift编程指南.md，注意文件名不要有空格；\n4. 按照规范翻译文章，并且保留原文，每段英文下面跟一段译文；\n5. 完成翻译之后，通过如下命令提交你的工作。首先提交到本地,`git add .`,然后`git commit -m \"我翻译了xxx\"`,最好通过`git push origin master`将你的翻译内容提交到github上；\n6. 等待提交结束之后，你的提交也只是提交到了你个人的项目中，此时你需要向主仓库发一个pull request (简称 pr ) 请求，可参考[Fork + Pull模式](http://www.worldhello.net/gotgithub/04-work-with-others/010-fork-and-pull.html)；\n7. 发布pr之后管理员会安排人员进行文章校对，有问题的地方校对人员会在pr下进行评论，翻译人员确认问题之后修改问题即可；\n8. 校对并且修改完之后翻译人员更新pr，管理员确认没有问题之后会合并该pr，整个翻译流程就此结束啦！\n\n如果在这个过程中有冲突，翻译人员需要先解决冲突，可以参考[Git下的冲突解决](http://www.cnblogs.com/sinojelly/archive/2011/08/07/2130172.html)。\n\n## 3、更详细的资料\n\n[git - 简易指南](http://www.bootcss.com/p/git-guide/)\n[pro git中文版](http://pan.baidu.com/s/1o6Hsets)" }, { "path": "issue-10/Android如何直播RTMP流.md", "content": "Android 如何直播RTMP流\n===\n> * 原文链接 : [How To Stream RTMP live in Android](http://www.truiton.com/2015/03/stream-rtmp-live-android/)\n* 原文作者 : [Mohit Gupt](google.com/+MohitGupt)\n* [译文出自 : 开发技术前线 www.devtf.cn](http://www.devtf.cn)\n* 译者 : [ayyb1988](https://github.com/ayyb1988) \n* 校对者: [chaossss](https://github.com/chaossss) \n* 状态 : 完成\n\n![rtmp](http://www.truiton.com/wp-content/uploads/2015/03/Android-RTMP-Player.png)\n\n在android上，视频/音频流直播是极少有人关注的一部分。每当我们讨论流媒体，RTMP[(Real Time Messaging Protocol)](http://en.wikipedia.org/wiki/Real_Time_Messaging_Protocol)是不可或缺的。RTMP是一个基本的视频/音频直播流协议，但是不幸的是Android标准的[VideoView](http://developer.android.com/reference/android/widget/VideoView.html)不支持RTMP的播放。因此，如果想在android上播放RTMP直播流，你必须使用支持RTMP协议的库。在本教程中我们将讨论如何通过使用安卓的 [Vitamio]（https://www.vitamio.org/en/） 库播放由 RTMP 协议传输的流媒体。\n\n##Android Vitamio 库\nVitamio是一个android和ios上基于[FFmpeg](https://www.ffmpeg.org/)的开源项目。Vitamio为我们提供了一个清洁、简单、全面、真实的硬件加速解码器和渲染器API，Vitamio是一个支持多种音视频格式 如 FLV, TS/TP, WMV, DivX, Xvid等多种标准格式的非常强大的库。所不同的是，它也支持类似.mkv和.srt嵌入和外挂字幕播放。但是它带有一个许可证，因此在使用它之前请先获得[认证](https://www.vitamio.org/en/License/)。在这个android RTMP例子中，我们不仅讨论RTMP直播流，而且也会讨论m3u8流（HLS），RTSP流和 MMS (Microsoft Media Stream)。首先让在我们的项目中引用Vitamio库。\n\n####在Android Studio中引用Vitamio库的步骤如下：\n1. 下载Vitamio bundle [https://github.com/yixia/VitamioBundle](https://github.com/yixia/VitamioBundle)\n2. 解压并且在Android Studio上File->Import Module\n3. 指定到VitamioBundle路径，选择vitamio文件夹 点击完成\n4. 在build.gradle(Module: app)依赖部分添加依赖项目(‘:vitamio’)\n5. 打开build.gradle (Module: vitamio) - 改变最小sdk版本为7\n6. 不要忘记在manifest.xml中添加internet权限\n7. 完成！\n\n####Android RTMP流\n在讲述如何使用之前，让我们先了解下RTMP。Real Time Messaging Protocol (RTMP)是一个Adobe Systems所拥有的一个协议。该协议是Adobe公司拥有的开发音视频流的flash player。后来该协议的部分被公开，供公众使用。更多请查看[这里](http://en.wikipedia.org/wiki/Real_Time_Messaging_Protocol).这个协议大多用于IPTV和实时视频点播流，但它也用于其他领域。\n\n在android上，标准的VideoView不支持RTMP播放。但WebView可以播放RTMP流。这解决了播放RTMP流的问题，但是我认为web apps 不能提供一个很好的界面和体验。因此这这个android RTMP例子中我们将运用第三方库-Vitamio 直播RTMP流的流媒体。在工程中引用Vitamio之后，请在你的layout文件添加Vitamio的VideoView：\n\nactivity_main.xml\n\n```xml\n\t\n\t\n\t\n\t \n\t\n\t\n```\n\n另外请编写你的activity如下：\n\nMainActivity.java\n\n```java\n\tpackage com.truiton.rtmpplayer;\n\t \n\timport android.net.Uri;\n\timport android.os.Bundle;\n\timport android.support.v7.app.ActionBarActivity;\n\t \n\timport java.util.HashMap;\n\t \n\timport io.vov.vitamio.LibsChecker;\n\timport io.vov.vitamio.MediaPlayer;\n\timport io.vov.vitamio.widget.MediaController;\n\timport io.vov.vitamio.widget.VideoView;\n\t \n\t \n\tpublic class MainActivity extends ActionBarActivity {\n\t private static final String TAG = \"MainActivity\";\n\t private String path;\n\t //private HashMap options;\n\t private VideoView mVideoView;\n\t \n\t @Override\n\t protected void onCreate(Bundle savedInstanceState) {\n\t super.onCreate(savedInstanceState);\n\t if (!LibsChecker.checkVitamioLibs(this))\n\t return;\n\t setContentView(R.layout.activity_main);\n\t mVideoView = (VideoView) findViewById(R.id.vitamio_videoView);\n\t path = \"rtmp://rrbalancer.broadcast.tneg.de:1935/pw/ruk/ruk\";\n\t /*options = new HashMap<>();\n\t options.put(\"rtmp_playpath\", \"\");\n\t options.put(\"rtmp_swfurl\", \"\");\n\t options.put(\"rtmp_live\", \"1\");\n\t options.put(\"rtmp_pageurl\", \"\");*/\n\t mVideoView.setVideoPath(path);\n\t //mVideoView.setVideoURI(Uri.parse(path), options);\n\t mVideoView.setMediaController(new MediaController(this));\n\t mVideoView.requestFocus();\n\t \n\t mVideoView.setOnPreparedListener(new MediaPlayer.OnPreparedListener() {\n\t @Override\n\t public void onPrepared(MediaPlayer mediaPlayer) {\n\t mediaPlayer.setPlaybackSpeed(1.0f);\n\t }\n\t });\n\t }\n\t}\n```\n\n虽然上面代码很清晰明了，但需要指出的是请修改你播放RTMP流的路径。在android上，有时可能使用带报头路径来播放RTMP流。幸运的是，Vitamio RTMP播放器也支持这种方式。因此，所有类型的RTMP流可以使用Vitamio库。上面的例子会是这个样子：\n![Rtmpplayer](http://www.truiton.com/wp-content/uploads/2015/03/Android-RTMP-Stream-Live.png)\n\n####Android RTSP流媒体\n实时流协议(RTSP)通过多媒体服务器传输内容，例如YouTube使用RTSP流发布内容。关于RTSP流比较容易的部分是，它可以通过android标准的VideoView来完成，想了解更多，请参考我的[VideoView例子](http://www.truiton.com/2013/08/android-videoview-example-with-youtube-playback/)。\n\n但是如果你使用Vitamio库，可以更好的播放RTSP流。事实上Vitamio也支持RTSP流的回播。和上面过程是一样的，包括Vitamio的VideoView在布局文件，并使用路径变量指定的RTSP url\n\n```java\n\tmVideoView = (VideoView) findViewById(R.id.vitamio_videoView);\n\tpath = \"rtsp://wowzaec2demo.streamlock.net/vod/mp4:BigBuckBunny_115k.mov\";\n\tmVideoView.setVideoPath(path);\n\tmVideoView.setMediaController(new MediaController(this));\n\tmVideoView.requestFocus();\n\t\n\tmVideoView.setOnPreparedListener(new MediaPlayer.OnPreparedListener() {\n\t @Override\n\t public void onPrepared(MediaPlayer mediaPlayer) {\n\t mediaPlayer.setPlaybackSpeed(1.0f);\n\t }\n\t});\n```\n\n####Android m3u8 流媒体\n“如何在android上播放m3u8视频”是android开发者最常见的问题之一。通过Http 协议进行视频流直播最简单的办法就是使用标准的 VideoView. 但只能在android3.0以上的设备上播放m3u8流。因为在Android 3.0引入HTTP/ HTTPS直播和HTTP/ HTTPS渐进式流媒体协议，在android3.1完全支持HTTPS。\n\n如果你希望在早期的版本上实现支持android m3u8流的HTTP实时流媒体 (HLS)。应该考虑使用Vitamio库，这个库支持在android API7以上播放m3u8。使用方式，同样的在布局文件中使用Vitamio的VideoView，并指定的HTTP实时流媒体URL。\n\n```java\n\tmVideoView = (VideoView) findViewById(R.id.vitamio_videoView);\n\tpath = \"http://93.184.221.133/00573D/236/236-0.m3u8\";\n\tmVideoView.setVideoPath(path);\n\tmVideoView.setMediaController(new MediaController(this));\n\tmVideoView.requestFocus();\n\t\n\tmVideoView.setOnPreparedListener(new MediaPlayer.OnPreparedListener() {\n\t @Override\n\t public void onPrepared(MediaPlayer mediaPlayer) {\n\t mediaPlayer.setPlaybackSpeed(1.0f);\n\t }\n\t});\n```\n\nPlaying m3u8 stream on Android with Vitamio would look something like this:\n在androi上使用Vitamio播放m3u8流效果如下：\n![m3u8](http://www.truiton.com/wp-content/uploads/2015/03/Android-m3u8-Streaming.png)\n\n####Android MMS 流\n\nVitamio库是一个强大的库，还支持Microsoft媒体服务器（MMS）流中的播放。 MMS是网络流媒体协议，主要用于网络广播和电台直播。使用Vitamio用于在anroid的MMS流和其他协议没有什么不同。所有你需要做的只是更换路径变量指向一个MMS url：\n\n```java\n\tmVideoView = (VideoView) findViewById(R.id.vitamio_videoView);\n\tpath = \"mms://beotelmedia.beotel.net/studiob\";\n\tmVideoView.setVideoPath(path);\n\tmVideoView.setMediaController(new MediaController(this));\n\tmVideoView.requestFocus();\n\t\n\tmVideoView.setOnPreparedListener(new MediaPlayer.OnPreparedListener() {\n\t @Override\n\t public void onPrepared(MediaPlayer mediaPlayer) {\n\t mediaPlayer.setPlaybackSpeed(1.0f);\n\t }\n\t});\n```\n\n##结论\n通过上面的讨论，可以确定地说，Vitamio是一个强大的多平台库（ios and android）。通过使用Vitamio库 能播放多种类型的视频格式和协议如RTMP, RTSP, HTTP Live, and HTTP渐进式流协议。另外一个很好的功能是，vitamio支持字幕和多音轨的播放。Vitamio的唯一的缺点是，它不是完全的开源。您可能需要购买许可证来使用它。希望这会有所帮助。通过Facebook, Google+ and Twitter来联系我们获取更多更新。\n\n" }, { "path": "issue-10/Android进行单元测试难在哪-part2.md", "content": "Android 进行单元测试难在哪-part2\n---\n\n> * 原文链接 : [Why Android Unit Testing is so hard](http://philosophicalhacker.com/2015/04/24/why-android-unit-testing-is-so-hard-pt-2/)\n* 原文作者 : [Matthew Dupree](http://philosophicalhacker.com/)\n* [译文出自 : 开发技术前线 www.devtf.cn](http://www.devtf.cn)\n* 译者 : [chaossss](https://github.com/chaossss) \n* 校对者: [tiiime](https://github.com/tiiime) \n* 状态 : 完成\n\n\n在上一篇博文中，我用干货告诉大家：即使是 Google 大牛写出来的代码也无法进行测试。确切地说，我真正告诉大家的是：根本没办法在 SessionDetailActivity 的 onStop() 方法里进行单元测试，而且详细地解释了个中因果：由于无法改变预测试状态，我们无法在 onStop() 方法里完成断言；在 onStop() 方法中进行测试时，获得测试后状态也是无法完成的。在上篇博文的结尾处，我跟大家说：正是 Android SDK 的某些特性，以及 Google 官方推荐的代码模板使得单元测试处于如此尴尬的境地，而且我承诺会在这篇博文中详尽地解释各种因由，那现在就让我来兑现我的诺言吧。\n\n在我开始论述之前，我再说一次：正是标准的 Android 应用架构使测试 Android 应用变得如此困难，这句话是本系列博文的核心论点。这篇博文的意义在于：我们尝试提出理由证明重构 Android 应用的必要性，使得这些 Android 应用不需要明确地依赖于 Android SDK，与此同时，我们也尝试着提出一种健壮的应用架构，以增强 Android 应用的测试性，你会在这篇博文里了解到相关的概述。因此，我接下来将尝试去证明这篇博文的核心论点。\n\n众所周知，开发 Android 应用有一种标准的架构，在示例代码和开源代码里很常见到应用的业务逻辑被放在 Android 应用的组件类，Activity，Service，Fragment 里执行。而我接下来就要遵循这种架构进行开发。而这篇博文要论述的就是：如果我们遵循这种标准架构进行开发，极有可能写下无法测试的代码，我在上一篇博文里也论证了这样的问题并不是偶然，正是标准的 Android 应用架构让测试变得支离破碎，单元测试几乎不能进行。\n\n## 传统的 Android 应用架构让单元测试变得不可能\n\n为了开始论证为什么标准开发架构让应用组件变得无法测试，大家不妨和我一起简要地复习下上篇博文的一些结论。单元测试包含三个步骤：准备，测试，断言。为了完成准备步骤，需要改变测试代码的预测试状态，此外，为了完成单元测试的断言步骤，我们需要获得程序的测试后状态。\n\n复习了这些知识点后，可以开始进入正题了哈。在某些情况下，依赖注入是实现能够改变预测试状态代码的唯一办法，而且这些代码的测试后状态也是可访问的。我写了一个与 Android 完全无关的示例：\n\n```java\n\tpublic class MathNerd {\n\t \n\t private final mCalcCache;\n\t \n\t private final mCalculator;\n\t \n\t public MathNerd(CalculationCache calcCache, Calculator calculator) {\n\t mCalcCache = calcCache;\n\t mCalculator = calculator;\n\t }\n\t \n\t \n\t public void doIntenseCalculation(Calculation calculation, IntenseCalculationCompletedListener listener) {\n\t \n\t if (!mCalcCache.contains(calculation)) {\n\t \n\t mCalculator.doIntenseCalculationInBackground(listener);\n\t \n\t } else {\n\t \n\t Answer answer = mCalcCache.getAnswerFor(calculation);\n\t listener.onCalculationCompleted(answer);\n\t }\n\t }\n\t}\n```\n\n如上所示，依赖注入确实是对 doIntenseCalculation() 进行单元测试的唯一办法，因为 doIntenseCalculation() 方法根本没有返回值。除此以外，MathNerd 类里也没有判断测试后状态有效性的属性。但通过依赖注入，我们可以通过 mCalcCache 获得单元测试中的测试后状态。\n\n```java\n\tpublic void testCacheUpdate() {\n\t \n\t //Arrange\n\t CalculationCache calcCache = new CalculationCache();\n\t \n\t Calculator calculator = new Calculator();\n\t \n\t MathNerd mathNerd = new MathNerd(calcCache, calculator);\n\t \n\t Calculation calcualation = new Calculation(\"e^2000\");\n\t \n\t //Act\n\t mathNerd.doIntenseCalculationInBackground(calculation, null);\n\t \n\t //some smelly Thread.sleep() code...\n\t \n\t //Assert\n\t calcCache.contains(calculation);\n\t}\n```\n\n如果我们这样做，很遗憾，恐怕是没办法为 MathNerd 类实现一个测试单元了。我们将会实现一个整合测试，用于检查 MathNerd 实际行为以及类是否根据 doIntenseCalculationInBackground() 方法处理后的值更新 CalcCache。\n\n此外，依赖注入实际上也是验证测试单元测试后状态的唯一办法。我们通过注入验证方法在正确的位置被调用：\n\n```java\n\tpublic void testCacheUpdate() {\n\t \n\t //Arrange\n\t CalculationCache calcCache = mock(CalculationCache.class);\n\t \n\t when(calcCache.contains()).thenReturn(false);\n\t \n\t Calculator calculator = mock(Calculator.class);\n\t \n\t MathNerd mathNerd = new MathNerd(calcCache, calculator);\n\t \n\t Calculation calculation = new Calculation(\"e^2000\");\n\t \n\t //Act\n\t mathNerd.doIntenseCalculationInBackground(calculation, null);\n\t \n\t //Assert should use calculator to perform calcluation because cache was empty\n\t verify(calculator).doIntenseCalculationInBackground(any());\n\t}\n```\n\n在 Android 应用的相关类中进行单元测试涉及的许多测试实例都需要一个东西：依赖注入。但问题来了：核心 Android 类持有我们无法注入的依赖。例如我上次提到的通过 SessionDetailActivity 启动的 SessionCalendarService 就是一个很好的例子：\n\n```java\n\t@Override\n\tprotected void onHandleIntent(Intent intent) {\n\t \n\t final String action = intent.getAction();\n\t Log.d(TAG, \"Received intent: \" + action);\n\t \n\t final ContentResolver resolver = getContentResolver();\n\t \n\t boolean isAddEvent = false;\n\t \n\t if (ACTION_ADD_SESSION_CALENDAR.equals(action)) {\n\t isAddEvent = true;\n\t \n\t } else if (ACTION_REMOVE_SESSION_CALENDAR.equals(action)) {\n\t isAddEvent = false;\n\t \n\t } else if (ACTION_UPDATE_ALL_SESSIONS_CALENDAR.equals(action) &&\n\t PrefUtils.shouldSyncCalendar(this)) {\n\t try {\n\t getContentResolver().applyBatch(CalendarContract.AUTHORITY,\n\t processAllSessionsCalendar(resolver, getCalendarId(intent)));\n\t sendBroadcast(new Intent(\n\t SessionCalendarService.ACTION_UPDATE_ALL_SESSIONS_CALENDAR_COMPLETED));\n\t } catch (RemoteException e) {\n\t LOGE(TAG, \"Error adding all sessions to Google Calendar\", e);\n\t } catch (OperationApplicationException e) {\n\t LOGE(TAG, \"Error adding all sessions to Google Calendar\", e);\n\t }\n\t \n\t } else if (ACTION_CLEAR_ALL_SESSIONS_CALENDAR.equals(action)) {\n\t try {\n\t getContentResolver().applyBatch(CalendarContract.AUTHORITY,\n\t processClearAllSessions(resolver, getCalendarId(intent)));\n\t } catch (RemoteException e) {\n\t LOGE(TAG, \"Error clearing all sessions from Google Calendar\", e);\n\t } catch (OperationApplicationException e) {\n\t LOGE(TAG, \"Error clearing all sessions from Google Calendar\", e);\n\t }\n\t \n\t } else {\n\t return;\n\t }\n\t \n\t //...\n\t}\n```\n\nSessionCalendarService 的依赖是 ContentResolver，而且 ContentResolver 就是一个无法注入的依赖，所以如果我们并没有办法在 onHandleIntent() 方法里进行注入。而 onHandleIntent() 方法没有返回值，SessionCalendarService 类里也没有能让我们检查测试后状态的可访问的属性。为了验证测试后状态，我们可以通过查询 ContentProvider 检查请求数据是否被插入，但我们不会这样的方式为 SessionCalendarService 实现测试单元。相反，我们用的方法是实现一个整合测试，同时测试 SessionCalendarService 以及受 ContentProvider 操控的日历会议数据。\n\n所以如果你把业务逻辑放在 Android 类里，而这个类的依赖又无法被注入，那这部分代码铁定没办法进行单元测试了。类似的无法被注入的依赖还有呢，例如：Activity 和 Fragment 的 FragmentManager。因此，至今为止 Google 官方一直鼓励我们使用的标准 Android 应用架构模式，教导我们在开发应用的时候要把业务逻辑放在应用的组件类里，信誓旦旦地说这是为我们好，而我们今天才知道真相竟然是：正是这样的架构让我们写下无法测试的代码。\n\n## 标准开发模式让单元测试变得困难重重\n\n某些情况下，标准的开发模式使代码的单元测试变得十分困难。如果我们回到上一篇博文提到的 SessionDetailActivity 里的 onStop() 方法，可以看到：\n\n```java\n\t@Override\n\tpublic void onStop() {\n\t super.onStop();\n\t if (mInitStarred != mStarred) {\n\t if (UIUtils.getCurrentTime(this) < mSessionStart) {\n\t // Update Calendar event through the Calendar API on Android 4.0 or new versions.\n\t Intent intent = null;\n\t if (mStarred) {\n\t // Set up intent to add session to Calendar, if it doesn't exist already.\n\t intent = new Intent(SessionCalendarService.ACTION_ADD_SESSION_CALENDAR,\n\t mSessionUri);\n\t intent.putExtra(SessionCalendarService.EXTRA_SESSION_START,\n\t mSessionStart);\n\t intent.putExtra(SessionCalendarService.EXTRA_SESSION_END,\n\t mSessionEnd);\n\t intent.putExtra(SessionCalendarService.EXTRA_SESSION_ROOM, mRoomName);\n\t intent.putExtra(SessionCalendarService.EXTRA_SESSION_TITLE, mTitleString);\n\t } else {\n\t // Set up intent to remove session from Calendar, if exists.\n\t intent = new Intent(SessionCalendarService.ACTION_REMOVE_SESSION_CALENDAR,\n\t mSessionUri);\n\t intent.putExtra(SessionCalendarService.EXTRA_SESSION_START,\n\t mSessionStart);\n\t intent.putExtra(SessionCalendarService.EXTRA_SESSION_END,\n\t mSessionEnd);\n\t intent.putExtra(SessionCalendarService.EXTRA_SESSION_TITLE, mTitleString);\n\t }\n\t intent.setClass(this, SessionCalendarService.class);\n\t startService(intent);\n\t \n\t if (mStarred) {\n\t setupNotification();\n\t }\n\t }\n\t }\n\t}\n```\n\n就像你看到的那样，onStop() 方法里压根没有能让我们知道 SessionCalendarService 是否通过正确的参数启动的可访问属性，此外，onStop() 方法是一个受保护的方法，使其返回值是无法修改的。因此，我们访问测试后状态的唯一办法就是检查注入到 onStop() 方法内的注入的状态。\n\n这样一来，我们就会注意到 onStop() 方法中用于启动 SessionCalendarService 的代码并不属于某一个类。换句话说，onStop() 方法中注入的依赖根本不存在用于检查 SessionCalendarService 是否在正确的情况下通过正确的参数启动的测试单元测试后状态的属性。为了提出能让 onStop() 方法变为可测试的的第三种办法，那我们需要一些这样的东西：\n\n```\n\t@Override\n\tpublic void onStop() {\n\t super.onStop();\n\t if (mInitStarred != mStarred) {\n\t if (UIUtils.getCurrentTime(this) < mSessionStart) {\n\t // Update Calendar event through the Calendar API on Android 4.0 or new versions.\n\t Intent intent = null;\n\t if (mStarred) {\n\t \n\t // Service launcher sets up intent to add session to Calendar\n\t mServiceLauncher.launchSessionCalendarService(SessionCalendarService.ACTION_ADD_SESSION_CALENDAR, mSessionUri, \n\t mSessionStart, mSessionEnd, mRoomName, mTitleString);\n\t \n\t } else {\n\t \n\t // Set up intent to remove session from Calendar, if exists.\n\t mServiceLauncher.launchSessionCalendarService(SessionCalendarService.ACTION_REMOVE_SESSION_CALENDAR, mSessionUri,\n\t mSessionStart, mSessionEnd, mTitleString);\n\t }\n\t \n\t if (mStarred) {\n\t setupNotification();\n\t }\n\t }\n\t }\n\t}\n```\n\n虽然这不是重构 onStop() 方法最简洁的方式，但如果我们按照标准开发方法把业务逻辑写在 Activity 里，并让写下的代码可以进行单元测试，类似的处理就变得必要了。现在不妨想想这种重构方式有多么违反常理：我们没有简单地调用 startService() 方法（startService() 是 Context 的一个方法，我们甚至可以说调用的是 SessionDetailActivity 的方法），而是通过依赖于 Context 的 ServiceLauncher 对象去启动该服务。SesionDetailActivity 作为 Context 的子类也将使用一个持有 Context 的对象去启动 SessionCalendarService。\n\n不幸的是，即使我们像上面说的那样重构了 onStop() 方法，我们仍然不能保证能为 onStop() 方法实现测试单元。问题在于：ServiceLauncher 没有被注入，使得我们不能对 ServiceLauncher 进行注入，使我们能验证在测试过程中调用了正确的方法。\n\n要对 ServiceLauncher进行注入，除了刚刚提到的以外，还会因为 ServiceLauncher 自身依赖于 Context 变得复杂，因为 Context 是一个非打包对象。因此，你并不能简单地通过将其传入用于启动 SessionDetailActivity 的 Intent 注入 ServiceLauncher。所以为了注入 ServiceLauncher，你需要开动你的小脑筋，或者使用类似于 Dagger¹ 的注入库。现在你应该也会发现，为了让我们的代码可以进行单元测试，我们确实需要完成许多复杂、繁琐的工作，而且，正如我即将在下篇博文中的论述，就算我们为了进行依赖注入而使用 Dagger 这样的库，在 Activity 内进行单元测试仍然是令人备受煎熬的。\n\n为了让 onStop() 方法能进行单元测试，标准开发方式强迫我们使用反常理的重构方法，并要求我们在“根据以 Intent 为基础的依赖注入机制想出更好的重构方法”或“使用第三方的依赖注入库”。而标准开发方式为写下可测试代码带来的困难，就像在鼓励我们写下无法进行测试的代码，正是这种困难让我认为：标准开发方式阻碍我们写下可测试代码。\n\n## 结论\n\n在整个系列博文中，我一直在提出这样的观点：通过反思为什么在 Android 中进行单元测试如此困难，将帮助我们发现重构应用架构的各种好处，使我们的应用不必明确地依赖于 Android SDK。这篇博文论述到这里，我相信大家有足够理由相信完全摆脱 Android SDK 或许是个好提议了。\n\n我刚刚把业务逻辑放在应用的组件类中，并向大家证明了对其进行单元测试有多么困难，甚至我们可以说对其进行单元测试这是不可能的。在下一篇博文中，我将建议大家将业务逻辑委托给使用了正确的依赖注入姿势的类。如果我们觉得定义这些类很麻烦的话，退而求其次，也能让这些类的依赖成为与 Android 无关的接口。与增强程序测试性的第一步相比，这一步是至关重要的，而完成第二步使我们无需 Android 特有的测试工具（例如：Roboletric，Instrumented Tests）就能写下更高效的测试单元。\n\n**注**\n\n1. 毫无疑问，你在传入 ServiceLauncher 时应该使他变为一个序列化对象。但这并不是一个特别健壮的解决办法，因为只有在你不在乎序列化带来的性能影响时才能使用这个办法。\n" }, { "path": "issue-10/Kotlin-for-Android-(IV)：自定义视图和Android的扩展.md", "content": "Kotlin for Android (IV)：自定义视图和Android的扩展\n---\n\n> * 原文链接 : [Kotlin for Android (IV): Custom Views and Android Extensions](http://antonioleiva.com/kotlin-android-custom-views/)\n* 原文作者 : [Antonio Leiva](http://antonioleiva.com)\n* [译文出自 : 开发技术前线 www.devtf.cn](http://www.devtf.cn)\n* 译者 : [sundroid](https://github.com/sundroid) \n* 校对者: [Mr.Simple](https://github.com/bboyfeiyu) \n* 状态 : 已校对\n\n\n在了解[extension functions and default values](http://antonioleiva.com/kotlin-android-extension-functions/)\n可以为我们做什么后，你可能想知道接下来将会发生什么。\n在[first article about Kotlin](http://antonioleiva.com/kotlin-for-android-introduction/)\n我们讨论过，Kotlin使得我们的开发变的更加简单，并且接下来我将更加深入的阐述这一观点。\n\n自定义View\n---\n\nKotlin的以往版本（一直到M10）是不支持去创建自定义view的。原因是我们在使用Kotlin时，每一个类只有一个构造函数。这通常是足够的，因为我们使用可选参数来使构造函数足以满足我们的需求。下面就是这样的一个例子：\n\n``` Java\nclass MyClass(param: Int, optParam1: String = \"\", optParam2: Int = 1) \n{
\n
 init {\n
 // Initialization code\n
 }
\n}\n```\n\n有一个独特的构造函数，我们现在有四种方法来创建这个类：\n\n\n``` Java\nval myClass1 = MyClass(1)\nval myClass2 = MyClass(1, \"hello\")\nval myClass3 = MyClass(param = 1, optParam2 = 4)\nval myClass4 = MyClass(1, \"hello\", 4)\n```\n\n\n正如你所见，我们通过可选参数达到了我们想要的多构造函数的目的。但是这导致了一个问题就是如果我们尝试通过继承系统的View来创建一个Android自定义View。自定义View需要重写不止一个父类的构造函数才能够正常运行，并且Kotlin没有提供这样的方法。幸运的是，从Kotlin M11版本发布后就支持声明多个构造函数，就像我们在Java下一样。这是一个ImageView保存平方率的例子：\n\n``` Java\nclass SquareImageView : ImageView {\n \n public constructor(context: Context) : super(context) {\n }\n \n public constructor(context: Context, attrs: AttributeSet) : super(context, attrs) {\n }\n \n public constructor(context: Context, attrs: AttributeSet, defStyleAttr: Int) : super(context, attrs, defStyleAttr) {\n }\n \n override fun onMeasure(widthMeasureSpec: Int, heightMeasureSpec: Int) {\n super.onMeasure(widthMeasureSpec, heightMeasureSpec)\n val width = getMeasuredWidth()\n setMeasuredDimension(width, width)\n }\n}\n```\n\n非常简单，它可能不太详细，但是至少我们现在有一个方法。\n\nKotlin Android 扩展组件\n---\n\n通过Kotlin M11，我们还提供了一个新的插件，这个插件将会帮助我们这个android开发者们用一种更加简单的方法去访问xml下定义的view，当你们使用这个方法时你们将会记得Butterknife，但是这个将会更加简单的去使用它。\n\nKotlin Android 扩展组件是一个基本的控件绑定，它将会让你在代码中通过id来使用你在xml中定义的view，它将会在不使用任何注解或者findViewById的方法自动创建这些属性。\n\n使用这个扩展组件，你需要安装一个新的插件，这个插件叫做Kotlin Android Extensions 并且添加通过buildscript来添加这个地址（在项目的build.gradle=中）\n\n\n\n``` Java\nbuildscript {
\n …\n
 dependencies {\n …
\n classpath \"org.jetbrains.kotlin:kotlin-android-extensions:$kotlin_version\"\n }\n
}\n```\n\n设想你有一个一个布局，叫main.xml：\n\n``` Java\n\n \n

 

\n \n\n```\n\n\n如果你想在你的activity中使用这个view，你唯一需要做得就是导入这个Kotlin Android Extensions提供的属性：\n\n``` Java\nimport kotlinx.android.synthetic..*\n```\n\n在我们的例子中，它将是主要的：\n\n\n``` Java\nimport kotlinx.android.synthetic.main.*\n```\n\n现在你可以通过id使用你的view了：\n\n``` Java\noverride fun onCreate(savedInstanceState: Bundle?) {
\n super.onCreate(savedInstanceState)\n setContentView(R.id.main)
\n frameLayout.setVisibility(View.VISIBLE)\n
 welcomeText.setText(\"I´m a welcome text!!\")
\n}\n```\n\n\n总结\n---\n\n通过这两个新功能，我们Kotlin 团队真正感兴趣的是让android开发者们可以生活的更加轻松。他们也发布了一个叫做Anko的库，让我们通过Kotlin创建布局。我们有使用其主要功能，但是你在处理View时可以使用它去简化你的代码，我有一些Kotlin项目的例子已经提交到github，你可以看看这些例子或者其他相关资料。\n\n下一个文章将会介绍使用lambda表达式和他们怎样才能帮助我们简化代码。非常有趣，对我来说，Kotlin和java 1.7比较起来将会变的非常有力。\n" }, { "path": "issue-10/readme.md", "content": "# 开发技术前线 第10期\n\n| 文章名称 | 译者 | \n|---------|--------|\n| [Android如何直播RTMP流](Android如何直播RTMP流.md) | [ayyb1988](https://github.com/ayyb1988) |\n| [Android 进行单元测试难在哪-part2](Android进行单元测试难在哪-part2.md) | [chaossss](https://github.com/chaossss)|\n| [Kotlin-for-Android-(IV)：自定义视图和Android的扩展](Kotlin-for-Android-(IV)：自定义视图和Android的扩展.md) | [sundroid](https://github.com/sundroid) |\n| [使用Facebook-SDK为安卓应用添加Like按钮](使用Facebook-SDK为安卓应用添加Like按钮.md) | [objectlife](https://github.com/objectlife)|\n| [将基于Dagger-1开发的项目迁移到Dagger-2中](将基于Dagger-1开发的项目迁移到Dagger-2中.md) | [chaossss](https://github.com/chaossss) |\n" }, { "path": "issue-10/使用Facebook-SDK为安卓应用添加Like按钮.md", "content": "使用Facebook SDK为安卓应用添加Like按钮\n\n> * 原文链接 : [How to add a Native Facebook Like Button to your Android app using Facebook SDK for Android v4](http://inthecheesefactory.com/blog/how-to-add-facebook-like-button-in-android-app/en)\n* 原文作者 : [nuuneoi](http://inthecheesefactory.com/blog)\n* [译文出自 : 开发技术前线 www.devtf.cn](http://www.devtf.cn)\n* 译者 : [objectlife](https://github.com/objectlife) \n* 校对者: [tiiime](https://github.com/tiiime)\n* 状态 : 完成 \n\n\nLike按钮是为你的网站增加流量最重要策略之一。不要惊讶为什么Facebook会引入这个Like按钮，`LikeView`,开发者可以随意将Like按钮添加到他们的Android/iOS中。\n\n![](http://inthecheesefactory.com/uploads/source/facebooklike/likes.png)\n\n虽然它听起非常简单，尤如我们在做网站的其它内容一样，但是答案是否定的。如果我们只是在应用的layout中添LikeView,它也会起作用但是在功能上会有限制，比如Like的数目和Like的状态不会显示。如果不安装Facebook app那是不行的。\n\n在深挖Facebook SDK's的源代码之后，我发现**LikeView被设计成只有安装Facebook app之后才能完全展现所有功能**。。。据我所知(AFAIK)也没有其它的文档提到这一问题。\n\n在试验了几次之后，最后我终于找到可以展现LikeView所有功能的方法，并且实践起来很容易。让我一步一步的介绍。\n\n##创建一个Facebook应用\n\n正如我上面所提到的，如果想让LikeView展现所有的功能是需要连接Facebook app的。所以我们第一步是创建一个Facebook app。\n\n我们打开[https://developers.facebook.com/apps](https://developers.facebook.com/apps)页面之后添加新应用。\n\n![](http://inthecheesefactory.com/uploads/source/facebooklike/addnewapp.png)\n\n输入你的应用的名字点击Create New Facebook App ID\n\n![](http://inthecheesefactory.com/uploads/source/facebooklike/newapp2.jpg)\n\n选择一个类别点击Create App ID\n\n![](http://inthecheesefactory.com/uploads/source/facebooklike/categoryselection.jpg)\n\n接下来你会跳转到Facebook App的设置页面，滚动到页面底部并且输入你应用的相关信息，**Package Name**和**Default Activity Class Name**点击**Next**\n\n![](http://inthecheesefactory.com/uploads/source/facebooklike/classes.jpg)\n\n接下来有一点小复杂，为了让你的应用无论是在开发环境还是生产环境下都能完美使用Facebook App，需要分别填写Debug Key Hash and Release Key Hash。\n\n![](http://inthecheesefactory.com/uploads/source/facebooklike/keyhashesbefore.jpg)\n\n有两种方式可以生成key hashes：命令或者代码。\n\n###方法1 - 命令行\n\n假设你使用**Mac**或者**Linux**并且已经安装了`keytool`(jdk自带)和`openssl`.你可以使用下面命令\n\n```\nkeytool -exportcert -alias androiddebugkey -keystore ~/.android/debug.keystore | openssl sha1 -binary | openssl base64\n```\n\nWindows下:\n\n```\nkeytool -exportcert -alias androiddebugkey -keystore %HOMEPATH%\\.android\\debug.keystore | openssl sha1 -binary | openssl base64\n```\n\n下面的命令是是用生成发布签名的Key Hash，这样上线的应用也可以使用Facebook app。\n\n```\nkeytool --exportcert -alias ENTER_ALIAS_HERE -keystore PATH_TO_KEYSTORE.keystore | openssl sha1 -binary | openssl base64\n```\n\n###方法2 - 通过JAVA代码\n\n假设你还没有并且你也不想安装keytool和openssl，你也可以通过下面JAVA代码来生成。**不要忘记修改成你的包名**.\n\n```\ntry {\n PackageInfo info = getPackageManager().getPackageInfo(\n \"com.inthecheesefactory.lab.facebooklike\",\n PackageManager.GET_SIGNATURES);\n for (Signature signature : info.signatures) {\n MessageDigest md = MessageDigest.getInstance(\"SHA\");\n md.update(signature.toByteArray());\n Log.d(\"KeyHash:\", Base64.encodeToString(md.digest(), Base64.DEFAULT));\n }\n } catch (PackageManager.NameNotFoundException e) {\n\n } catch (NoSuchAlgorithmException e) {\n\n } \n```\n\n为了生成开发环境下的Key Hash，你可以在IDE中简单运行一下应用从打印的Logcat中复制出生成的key hash，把生成key hash分别填进**Development Key Hashes** 和 **Release Key Hash**。\n\n为了生成正式环境下的Key Hash，你需要为你的应用打包签名，将打包签名的应用安装到设备或者模拟器上打开，将生成的Key Hash填到Release Key Hash处。\n\n> 注意，用于正式打包的Key Hash值可以稍后补上，最重要的是你现在先把开发环境下的Key Hash值填写到Development Key Hashes and Release Key Hash中\n\n![](http://inthecheesefactory.com/uploads/source/facebooklike/keyhashes2.jpg)\n\n点击**Next**并滚到页面到底端，点击**Skip to Developer Dashboard**进入到你刚刚创建的应用面板中。\n\n![](http://inthecheesefactory.com/uploads/source/facebooklike/skiptodashboard.jpg)\n\n将**App ID**复制下来一会要用，到此为止一个Facebook App已经创建完成。\n\n##项目中设置Facebook SDK\n\n在客户端导入该库\n\n```\ndependencies {\n compile 'com.facebook.android:facebook-android-sdk:4.0.1'\n}\n```\n\n将Application ID添加到value/strings中：\n\n```\n你的Application ID\n```\n\n将下面的代码粘到`AndroidManifest.xml`的``之前，**一定要修改下面FacebookContentProvider后面的值为你的Application ID**。\n\n```\n \n \n \n\n \n``` \n\n\nINTERNET permission is needed for LikeView. Don't forget to add this line inside `AndroidManifest.xml` before ``.\n\n添加访问网络权限\n\n```\n\n```\n\n在自定义的Application中作Facebook SDK的初使化工作\n\n```\npublic class MainApplication extends Application {\n\n @Override\n public void onCreate() {\n super.onCreate();\n\n FacebookSdk.sdkInitialize(getApplicationContext());\n }\n}\n```\n\n检查一下自定义Application是否在`AndroidManifest.xml`注册。\n\n```\n\n```\n\n至此，已经完成了Facebook SDK的设置。\n\n## 使用LikeView\n\n在部局文件中使用\n\n```\n\n```\n\n代码初使化\n\n```\nLikeView likeView = (LikeView) findViewById(R.id.likeView);\nlikeView.setLikeViewStyle(LikeView.Style.STANDARD); \nlikeView.setAuxiliaryViewPosition(LikeView.AuxiliaryViewPosition.INLINE);\n```\n\n通过**setObjectIdAndType**方法设置LikeView的url。\n\n```\nlikeView.setObjectIdAndType(\n \"http://inthecheesefactory.com/blog/understand-android-activity-launchmode/en\",\n LikeView.ObjectType.OPEN_GRAPH)\n```\n\n添加成功后如图所示\n![](http://inthecheesefactory.com/uploads/source/facebooklike/exp0.jpg)\n\n虽然效果出来了，但是效果还不完美，目前有两个比较大的问题：\n\n**问题1：如果不点击Like按钮，就不会看到Like的数目和状态。**\n\n**问题2：没有安装Facebook应用的设备是不能使用的。**\n\n![](http://inthecheesefactory.com/uploads/source/facebooklike/exp1.jpg)\n\n在上面已经描述过其中的原由了，只有和Facebook连接成功才能完美的使用LikeView。与在网站中使用不同的一点就是不需要登录。(作者:我很好奇Facebook为什么会这样设计)\n\n![](http://inthecheesefactory.com/uploads/source/facebooklike/onweb.png)\n\n看来得变通一下才行，要显示LikeView需要登录Facebook，可以用和LikeView相同外观的登录按钮代替。\n\n这并不复杂。在LikeView的父部局RelativeLayout中使用LinearLayout创建一个登录按钮\n\n```\n\n\n \n \n\n \n\n \n\n \n\n \n\n\n```\n\n然后在代码中使用Facebook SDK提供的**LoginManager, CallbackManager** 和 **AccessToken** 类来完成登录的逻辑。\n\n```\npublic class MainActivity extends Activity {\n \n LinearLayout btnLoginToLike;\n LikeView likeView;\n CallbackManager callbackManager;\n\n \n @Override\n protected void onCreate(Bundle savedInstanceState) {\n super.onCreate(savedInstanceState);\n setContentView(R.layout.activity_main);\n\n initInstances();\n initCallbackManager();\n refreshButtonsState();\n }\n\n private void initInstances() {\n btnLoginToLike = (LinearLayout) findViewById(R.id.btnLoginToLike);\n likeView = (LikeView) findViewById(R.id.likeView);\n likeView.setLikeViewStyle(LikeView.Style.STANDARD);\n likeView.setAuxiliaryViewPosition(LikeView.AuxiliaryViewPosition.INLINE);\n\n btnLoginToLike.setOnClickListener(new OnClickListener() {\n @Override\n public void onClick(View v) {\n LoginManager.getInstance().logInWithReadPermissions(MainActivity.this, Arrays.asList(\"public_profile\"));\n }\n });\n }\n\n private void initCallbackManager() {\n callbackManager = CallbackManager.Factory.create();\n LoginManager.getInstance().registerCallback(callbackManager, new FacebookCallback() {\n @Override\n public void onSuccess(LoginResult loginResult) {\n refreshButtonsState();\n }\n\n @Override\n public void onCancel() {\n\n }\n\n @Override\n public void onError(FacebookException e) {\n\n }\n });\n }\n\n private void refreshButtonsState() {\n if (!isLoggedIn()) {\n btnLoginToLike.setVisibility(View.VISIBLE);\n likeView.setVisibility(View.GONE);\n } else {\n btnLoginToLike.setVisibility(View.GONE);\n likeView.setVisibility(View.VISIBLE);\n }\n }\n\n public boolean isLoggedIn() {\n return AccessToken.getCurrentAccessToken() != null;\n }\n\n @Override\n protected void onActivityResult(int requestCode, int resultCode, Intent data) {\n super.onActivityResult(requestCode, resultCode, data);\n // Handle Facebook Login Result\n callbackManager.onActivityResult(requestCode, resultCode, data);\n }\n}\n```\n\nOK。让我们看一下结果。\n\n###结果\n\n如果程序无法连接到Facebook app,我们的登录按钮将会代替LikeView显示。\n\n![](http://inthecheesefactory.com/uploads/source/facebooklike/btnLogin2.png)\n\n一旦点击登录按钮，跳转到用户登录\n\n![](http://inthecheesefactory.com/uploads/source/facebooklike/loginprocess.png)\n\n用户登录之后，登录按钮将会被隐藏同时显示LikeView，届时你将会看到Like的数目和状态也会像网站中的一样完美的显示出来。如果url改变了，那些数目和状态也会相应的刷新。\n\n![](http://inthecheesefactory.com/uploads/source/facebooklike/loggedin.png)\n\n如果用户点击Like,也会影响到网站中使用的Like.\n\n![](http://inthecheesefactory.com/uploads/source/facebooklike/liked.png)\n\n这种方法可以让没有安装Facebook应用的设备使用Facebook SDK.意味着在Chrome和ARC Welder 也可以使用\n\n![](http://inthecheesefactory.com/uploads/source/facebooklike/arcwelder.jpg)\n\n##已知bug\n\n虽然它接近完美但是仍然有一些bug。如果在网站中点击了Like，应用中的Like状态不会改变。除了等Facebook修复这个bug我们无能为力。\n\n##FBLikeAndroid Library\n\n为了让它更加容易使用，我特意制作了一个library。**FBLikeAndroid 就是当成功连接到Facebook应用时，登录按钮自动改变原生Like按钮的library**\n\n![](http://inthecheesefactory.com/uploads/source/facebooklike/fblikeandroid.png)\n\n使用它的时候你只需按照上面的步骤创建一个Facebook应用，然后添加依赖到你项目`build.gradle`中。**注意：此依赖已经包括了Facebook SDK，你不需要再添加额外依赖**\n\n```\ndependencies {\n compile 'com.inthecheesefactory.thecheeselibrary:fb-like:0.9.3'\n}\n```\n\n像如下方式使用该组件\n\n```\n\n```\n\nFBLikeView中LikeView使用了标准外观，你不需要再重新设置，除非你想改变它的style.如果想访问LikeView你可以使用`getLikeView()`方法。下面的代码是为LikeView设置url\n\n```\nFBLikeView fbLikeView = (FBLikeView) rootView.findViewById(R.id.fbLikeView);\nfbLikeView.getLikeView().setObjectIdAndType(\n \"http://inthecheesefactory.com/blog/understand-android-activity-launchmode/en\",\n LikeView.ObjectType.OPEN_GRAPH);\n```\n\n最后一步，你需要在每一个Activity的`onActivityResult`中调用`FBLikeView.onActivityResult`方法进行Facebook登录\n\n```\n@Override\n protected void onActivityResult(int requestCode, int resultCode, Intent data) {\n super.onActivityResult(requestCode, resultCode, data);\n FBLikeView.onActivityResult(requestCode, resultCode, data);\n }\n```\n\n就这样。是不是很简单。\n\n如果你想与Facebook取消连接。使用下面代码就可以了。按钮会自动改变其状态。\n\n```\nFBLikeView.logout();\n```\n\nFBLikeAndroid Library的源码[https://github.com/nuuneoi/FBLikeAndroid](https://github.com/nuuneoi/FBLikeAndroid)有空的时候可以看一下。\n\n\n##Submit for public use\n\n现在LikeView只在当前Facebook的账号下可以使用。为了让每一个人可以使用LikeView，你需要向Facebook提交申请。下面是申请步骤：\n\n1）进入你的Facebook应用的详情页。输入描述、隐私政策URL并上传你希望使用的应用图标。\n\n![](http://inthecheesefactory.com/uploads/source/facebooklike/appdetails.jpg)\n\n2)进入Status & Review页面点击Start a Submission\n\n![](http://inthecheesefactory.com/uploads/source/facebooklike/submission1.png)\n\n3)选择Native Like Button项并点击Add 1 Item\n\n![](http://inthecheesefactory.com/uploads/source/facebooklike/submission2.png)\n\n4)点击Add Notes在弹窗中输入一些介绍信息，根据我的经验，提供一些应用截图的链接比输入文字的效果更好。\n\n![](http://inthecheesefactory.com/uploads/source/facebooklike/AddNotes.jpg)\n\n上传APK文件，并上传你应用的截图(最少4张)勾选**I have tested that my application loads on all of the above platforms**,并点击**Submit for Review**。\n\n![](http://inthecheesefactory.com/uploads/source/facebooklike/submission3.jpg)\n\n6)在**Settings**页面输入联系Email\n\n![](http://inthecheesefactory.com/uploads/source/facebooklike/submission4.jpg)\n\n7)最后一步是为了让每个人都可以使用创建的Facebook应用，在**Status & Review**页面将按钮状态切换为**On**\n\n![](http://inthecheesefactory.com/uploads/source/facebooklike/submission5.jpg)\n\n出去旅个游，钓个鱼什么的等个一两天就会有结果了。平均来说，大概需要提交2-3次才能通过，所以在发布你应用的前一个星期就需要开始申请。\n\n当申请通过之后**Status & Review**页面是这样的\n\n![](http://inthecheesefactory.com/uploads/source/facebooklike/submissionpassed.png)\n\n一旦状态变成如图中那样，那么每个人都可以使用你的LikeView了\n\n希望这篇文章对你有用，不要忘了给文章点赞哦。=)\n\n\n" }, { "path": "issue-10/将基于Dagger-1开发的项目迁移到Dagger-2中.md", "content": "将基于Dagger-1开发的项目迁移到Dagger-2中\n---\n\n> * 原文链接 : [Dagger 1 to 2 migration process](http://frogermcs.github.io/dagger-1-to-2-migration/)\n* 原文作者 : [Miroslaw Stanek](https://about.me/froger_mcs)\n* [译文出自 : 开发技术前线 www.devtf.cn](http://www.devtf.cn)\n* 译者 : [chaossss](https://github.com/chaossss) \n* 校对者: [tiiime](https://github.com/tiiime)\n* 状态 : 完成\n\n我相信每一个 Android 开发者都听说过依赖注入框架，事实上几乎所有 Android 官方会议都讨论过软件设计模式。虽然我是依赖注入的脑残粉，但我不得不承认也有人不喜欢依赖注入，主要原因如下：\n\n- **依赖注入框架很慢** - 好吧，在使用 [RoboGuice](https://github.com/roboguice/roboguice) 的时代里，整个依赖图表会在运行时被创建和验证，使依赖注入框架确实会存在这样的问题。但现在，[Dagger](https://github.com/square/dagger) 让这一切发生了改变。在 Dagger 1 框架中，大量的工作（图表验证）在编译时被完成，而且对象创建也不需要通过反射机制完成（值得一提的是：最近发布的 Roboguice 3 也在编译时完成了大量的工作）。虽然 Dagger 1 框架的效率还是不如工程师亲自写的代码，但在大部分 App 里这都是可以接受的。\n\n- **依赖注入框架需要大量的模板** - 可以说它是对的，也可以说不是。确实，我们需要为提供依赖的类和注入添加额外的代码，但正因为我们完成了这样的工作，使我们不必在每次需要使用它们的时候通过构造器处理它们。我不否认依赖注入框架会在影响小型 App 的性能，但随着 App 内部结构变得复杂，依赖注入的好处会越来越明显。\n\n- 其他缺点就是较差的溯源性，已生成代码的可读性差等等……\n\n但我已经说了：我是依赖注入框架的脑残粉，刚刚提到的种种缺点并不会让我放弃在项目中使用它。直到最近我使用 Dagger 1 都没产生什么问题，但当我们决定完全重写 [Azimo](https://azimo.com/) （我的新项目），并将它运行在依赖注入框架时，Dagger 1 中存在的一些问题渐渐显现。这些问题到底是什么呢？且听我娓娓道来。\n\n不过好消息是，Dagger 2 虽然还没有发布正式版，但 Dagger 2 已经有一个稳定，特征完备的版本了。\n\n## Dagger 2\n\n说实话，我并没有太深入地了解 Dagger 2 的实现细节，我只是稍微看了看官网的一些说明 [Dagger 2 website](http://google.github.io/dagger/) 和 Jake Wharton 的随笔-[The Future of Dependency Injection with Dagger 2](https://www.parleys.com/talk/5471cdd1e4b065ebcfa1d557/)。\n\n毕竟对我来说最重要的是，Dagger 2 几乎自动地帮我解决了 Dagger 1 中大量的长耗时任务。\n\n## 对项目使用 Proguard\n\n我不得不承认，Azimo 应用的方法数已经超过了 65536 个了（[Android Dex's 64k 限制](http://ingramchen.io/blog/2014/09/prevention-of-android-dex-64k-method-size-limit.html)）。刚开始开发 Azimo 的时候我们使用的是 [MultiDex solution](https://developer.android.com/tools/building/multidex.html)，但随着应用的迭代我们发现 MultiDex solution 存在一些缺陷，因此我们必须考虑使用 Proguard。为什么我们必须要作出这样的决定呢？\n\n> 译者注：ProGuard是一个压缩、优化和混淆Java字节码文件的免费的工具，它可以删除无用的类、字段、方法和属性。可以删除没用的注释，最大限度地优化字节码文件。它还可以使用简短的无意义的名称来重命名已经存在的类、字段、方法和属性。常常用于Android开发用于混淆最终的项目，增加项目被反编译的难度。\n\n仅有在 MultiDexApplication 类的 onCreate() 方法中调用的 MultiDex.install(this) 在使用 Android 4.4 系统的 Nexus 7 设备中花费大约 4000ms 的时间（Lollipop 对 MultDex 的支持是基于内核的，所以在相同的设备中只需要1ms）。此外，应用的构建时间戏剧性地不降反增（即使我们只修改了一行代码，每一个 Gradel assembleDebug 仍需要2分钟左右的时间）。为什么耗时这么长？简单来说：每一次我们修改代码决定将哪些代码放到第一个 .dex 文件中以及哪些代码能够移动到其他 .dex 文件时，MultiDex 插件都需要扫描资源文件。\n\n所以我们决定使用 Proguard，然后就爆炸了……因为在 Proguard 规范下没有用来处理 Dagger 自动生成代码的简单办法。所以我们得使用 [Squad leader](https://bitbucket.org/littlerobots/squadleader) 的 @Keep 注解来简化这个问题，但我们还是需要花费一定的时间更新代码，并将这条规范在注释中标注。\n\nDagger 2 回应：Proguard 中不存在 Dagger 2 所需要的单一原则。一切都是自然而然发生的。因为 Dagger 2 产生完全可溯源的代码，而且不需要使用反射 - 这对 Proguard 的友好度简直爆表。\n\n## 其他事项\n\n现在还有一些不是非常重要（但又有用）的事项让我们确信将基于 Dagger 1 框架开发的代码转移到 Dagger 2 中：\n\n- Dagger 1 自动生成的代码非常难度，虽然 Dagger 1 他爹值得信赖，但了解 Dagger 1 在底层到底留下了什么对我们也有好处。由于这些代码并不是完全可溯源的，那就意味着我们不能用 IDE 中类似 “find usages” 的功能。\n\nDagger 2 生成了和程序员亲手实现的依赖注入代码几乎一样的整个栈。使代码具有完全可溯源性，便于我们更好地理解代码的运行机制。\n\n- 或许 Dagger 2 的拓展性变差了些许，但 Dagger 2 的 API 比 Dagger 1 清晰易用得多。我们的团队仍然在发展，在我们重写应用的时候，理解整个应用的架构过程必须尽可能快， Bug 要尽可能地少是很重要的。幸亏 Dagger 2 的学习曲线并不陡峭，这为我们节省了学习成本。\n\n- 依赖图的构建时间。或许现在它对我们来说不是什么大问题 - 因为在 Nexus 7（Android 4.4 系统）构造应用的依赖图大概需要 80ms 的时间。但使用了 Dagger 2，只需要 40ms 依赖图就构建完成了。\n\n# 将基于 Dagger 1 开发的项目迁移到 Dagger 2 中\n\nAntonio Leiva 曾在几个月前写了有关如何在 Android 基于 MVP 模式开发的项目中使用依赖注入的系列博文([post 1](http://antonioleiva.com/dependency-injection-android-dagger-part-1/), [post 2](http://antonioleiva.com/dependency-injection-android-dagger-part-2/), [post 3](http://antonioleiva.com/dependency-injection-android-dagger-part-3/))。我觉得这个项目挺好的，于是将它下了下来，并让它的依赖注入框架更新为 Dagger 2。\n\n## 依赖图\n\n为了更好地理解 Dagger 1 是如何在范例中运行的，我用 DaggerExample 项目创建了依赖图：\n\n![](http://frogermcs.github.io/images/12/dagger1-graph.jpg)\n\n现在我们来看看在相同的项目中使用 Dagger 2 创建的依赖图：\n\n![](http://frogermcs.github.io/images/12/dagger2-graph.jpg)\n\n你能看到其中的相似之处吗？\n\nDagger 1 和 Dagger 2 两者中最值得一提的区别就是 Compontents。简单来说，它们把调用者可能请求的所有类型都枚举出来了。但组件接口只声明它为调用者提供了某些东西，以及这些东西由 Module 提供，所以 Module 仍然负责创建对象。组件只是依赖图的公有 API。\n\n# 迁移过程\n\n## 创建依赖\n\n首先，为了添加新的依赖，我们要更新 build.gradle 文件。当我在写这篇博文的时候，只有一个快照版本是可用的。这也是我们必须添加 Sonatype snapshot 库的原因：\n\n**build.gradle:**\n\n```java\n\tbuildscript {\n\t repositories {\n\t mavenCentral()\n\t maven { url \"https://oss.sonatype.org/content/repositories/snapshots/\" }\n\t }\n\t dependencies {\n\t classpath 'com.android.tools.build:gradle:1.1.3'\n\t classpath 'com.neenbedankt.gradle.plugins:android-apt:1.4'\n\t }\n\t}\n\t \n\tallprojects {\n\t repositories {\n\t mavenCentral()\n\t maven { url \"https://oss.sonatype.org/content/repositories/snapshots/\" }\n\t }\n\t}\n```\n\nAndroid-ADT 插件与注解处理器协作，并仅在注解处理器为依赖时允许配置编译时间而不把 artifact 添加到最后的 APK 中。当然了，它还为自动生成的代码生成了相应的原路径，在 Android Studio 中它们都是可见的并且可溯源的。\n\nDagger 的 app/build.gradle 文件和 Android-ADT 中的信息应该大致如下：\n\n```java\n\tapply plugin: 'com.android.application'\n\tapply plugin: 'com.neenbedankt.android-apt'\n\t \n\tandroid {\n\t compileSdkVersion 22\n\t buildToolsVersion \"22.0.1\"\n\t \n\t defaultConfig {\n\t minSdkVersion 14\n\t targetSdkVersion 22\n\t versionCode 1\n\t versionName \"1.0\"\n\t }\n\t \n\t compileOptions {\n\t sourceCompatibility JavaVersion.VERSION_1_7\n\t targetCompatibility JavaVersion.VERSION_1_7\n\t }\n\t buildTypes {\n\t release {\n\t minifyEnabled false\n\t proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.txt'\n\t }\n\t }\n\t}\n\t \n\tdependencies {\n\t compile fileTree(dir: 'libs', include: ['*.jar'])\n\t compile 'com.google.dagger:dagger:2.0-SNAPSHOT'\n\t apt 'com.google.dagger:dagger-compiler:2.0-SNAPSHOT'\n\t provided 'org.glassfish:javax.annotation:10.0-b28'\n\t}\n```\n\n## Modules\n\n接下来这一步可以说是迁移过程中最简单的一步了。Module 将尽可能变得简单，它们只需要为将要提供的对象添加 @Module（不需要任何额外的参数） 和 @Provides 注解。\n\n这是 AppModule 类：\n\n**Dagger 1:**\n\n```java\n\t@Module(\n\t injects = {\n\t App.class\n\t },\n\t includes = {\n\t DomainModule.class,\n\t InteractorsModule.class\n\t }\n\t)\n\tpublic class AppModule {\n\t \n\t private App app;\n\t \n\t public AppModule(App app) {\n\t this.app = app;\n\t }\n\t \n\t @Provides public Application provideApplication() {\n\t return app;\n\t }\n\t}\n```\n\n**Dagger 2:**\n\n```java\n\t@Module\n\tpublic class AppModule {\n\t \n\t private App app;\n\t \n\t public AppModule(App app) {\n\t this.app = app;\n\t }\n\t \n\t @Provides public Application provideApplication() {\n\t return app;\n\t }\n\t}\n```\n\n两者的区别在哪里？区别在于：注入参数被移动到组件内，就像使用 include。所有 Module 参数都该尽快过时/移除。\n\n##组件\n\n就像我刚刚说的，Dagger 2 中还添加了一些新的特性。简单来说把，就是依赖图的一些公有 API。大家不妨再回去看看刚刚 Dagger 2 的依赖图，这是每一个 @Componentclass 的实现：\n\n**AppComponent:**\n\n```java\n\t@Singleton\n\t@Component(\n\t modules = {\n\t AppModule.class,\n\t DomainModule.class,\n\t InteractorsModule.class\n\t }\n\t)\n\tpublic interface AppComponent {\n\t void inject(App app);\n\t \n\t AnalyticsManager getAnalyticsManager();\n\t LoginInteractor getLoginInteractor();\n\t FindItemsInteractor getFindItemsInteractor();\n\t}\n```\n\n**LoginComponent:**\n\n```java\n\t@ActivityScope\n\t@Component(\n\t dependencies = AppComponent.class,\n\t modules = LoginModule.class\n\t)\n\tpublic interface LoginComponent {\n\t void inject(LoginActivity activity);\n\t \n\t LoginPresenter getLoginPresenter();\n\t}\n```\n\n**MainComponent:**\n\n```java\n\t@ActivityScope\n\t@Component(\n\t dependencies = AppComponent.class,\n\t modules = MainModule.class\n\t)\n\tpublic interface MainComponent {\n\t void inject(MainActivity activity);\n\t \n\t MainPresenter getLoginPresenter();\n\t}\n```\n\n大家可以看到我使用了 @AcivityScope 注解。简单来说，它是本地子图中 @Singleton 注解的代替品。在 Dagger 1 里，假如我们有一个 LoginPresenter 类的单例对象，虽然这个对象确实是一个单例，但某种程度上它总像一个本地单例 - 因为它只存活于图的作用域中（示例代码中，该单例会在 onDestory() 方法中被设置为 null)。\n\n@ActivityScope is used just for semantic clarity and it’s defined in our code:\n\n@ActivtiyScope 只用于语境清晰的环境中，它在代码中的定义如下：\n\n```java\n\t@Scope\n\t@Retention(RetentionPolicy.RUNTIME)\n\tpublic @interface ActivityScope {\n\t}\n```\n\n## 对象图\n\nDagger 2 中不再有对象图，因为对象图被组件取代了。确切来说，Dagger 2 框架将自动生成以 DaggerComponent_ 为前缀的代码。这就意味着我们现在必须处理生成代码（但只在这里处理）。\n\n我们必须记住：DaggerComponent_ 类只有在所有代码有效的情况下被生成，所以在你解决所有 Error 之前你不会看到它。\n\n那它具体长什么样呢？\n\n```java\n\tpublic class App extends Application {\n\t \n\t private AppComponent component;\n\t \n\t @Inject\n\t AnalyticsManager analyticsManager;\n\t \n\t @Override\n\t public void onCreate() {\n\t super.onCreate();\n\t setupGraph();\n\t analyticsManager.registerAppEnter();\n\t }\n\t \n\t private void setupGraph() {\n\t component = Dagger_AppComponent.builder()\n\t .appModule(new AppModule(this))\n\t .build();\n\t component.inject(this);\n\t }\n\t \n\t public AppComponent component() {\n\t return component;\n\t }\n\t \n\t public static App get(Context context) {\n\t return (App) context.getApplicationContext();\n\t }\n\t}\n```\n\n我们的图将通过16-18行代码生成，取代了 Dagger 1 的 ObjectGraph.create(getModules()) 代码。\n\n第19行代码将 App 对象注入到途中（而且此时类中所有 @Inject 注解都是可信的）\n\n这是一个本地图（MainActivity）的范例：\n\n```java\n\tprotected void setupComponent(AppComponent appComponent) {\n\t Dagger_MainComponent.builder()\n\t .appComponent(appComponent)\n\t .mainModule(new MainModule(this))\n\t .build()\n\t .inject(this);\n\t}\n```\n\nMainComponent 依赖于 AppComponent，使我们必须准确地提供这个对象。如果 Module 没有默认的构造器，你必须提供（就像 MainModule)。\n\n那么迁移工作到这里就算完成了。提交完整的迁移过程的 [pull request](https://github.com/antoniolg/DaggerExample/pull/5) 能防止我们遗漏某些东西。大家必须记住：这篇文章没有讲解更多复杂的解决办法，以及 Dagger 2 的所有特性和功能。下面是一些能帮你更好地理解 Dagger 2 和依赖注入框架运行机制的链接：\n\n[The Future of Dependency Injection with Dagger 2](https://www.parleys.com/talk/5471cdd1e4b065ebcfa1d557/)\n[Dagger 2 doc by Gregory Kick](https://docs.google.com/document/d/1fwg-NsMKYtYxeEWe82rISIHjNrtdqonfiHgp8-PQ7m8/edit)\n[Dagger 2 official website](http://google.github.io/dagger/)\n\n那这篇博文就到此为止啦，感谢你能耐心看完这篇文章，我希望能更深入地挖掘 Dagger 2 的技术细节，我相信大家很快会看到我的新博文的！😃\n\n## 源码\n\n[Github](https://github.com/frogermcs/DaggerExample) 上面有整个项目的源码。" }, { "path": "issue-11/Android-Espresso测试框架介绍.md", "content": "Android Espresso 测试框架介绍\n---\n\n> * 原文链接 : [Introduction to Android Espresso](https://androidresearch.wordpress.com/2015/04/04/an-introduction-to-espresso/)\n* 原文作者 : [Veaceslav Grec](https://androidresearch.wordpress.com/author/androidresearch/)\n* [译文出自 : 开发技术前线 www.devtf.cn](http://www.devtf.cn)\n* 译者 : [zhengxiaopeng](https://github.com/zhengxiaopeng) \n* 校对者: [chaossss](https://github.com/chaossss) \n* 状态 : 完成\n\n\n\nEspresso 是一个提供了简单 API 的用于 android app UI 测试的测试框架。最新的 2.0 版本发布后已经可以在 Android Support Repository 中下载了，那么在项目中集成它就方便多了。\n\n但在我们看 Espresso 的 API 之前，让我们来细看下它与其它测试框架的不同：\n\n- 你首先会注意到的是，他写出来的代码很像英文，可想而知它是很容易学习的\n- API 相当的小，当然也会对扩展开放的\n- Espresso 的测试跑起来那是相当的快（没有等待、睡眠）\n- Gradle 和 Android Studio 的支持\n\n\n## 在你的项目中添加 Espresso\n\n1、首先保证你的 Android Support Repository 已经成功安装\n![Android Support Repository](https://androidresearch.files.wordpress.com/2015/03/sdk-manager1.png?w=550&h=303)\n\n2、在你程序的 build.gradle 文件中添加依赖\n\n``` Gradle\ndependencies {\n androidTestCompile 'com.android.support.test:testing-support-lib:0.1'\n androidTestCompile 'com.android.support.test.espresso:espresso-core:2.0'\n}\n```\n\n3、最后，在默认配置中指定 test instrumentation runner\n\n``` Gradle\nandroid {\n \n defaultConfig {\n // ....\n testInstrumentationRunner \"android.support.test.runner.AndroidJUnitRunner\"\n }\n}\n```\n\n这些基本上就是在你的项目中集成 Espresso 测试框架了（给你的项目一杯浓咖啡提提神~）！\n\n\n## Espresso 的主要组件\n\nEspresso 由 3 个主要的组件构成。\n\n这些组件是：\n\n- ViewMatchers - 在当前的 view 层级中定位一个 view\n- ViewActions - 跟你的 view 交互\n- ViewAssertions - 给你的 view 设置断言\n\n更简单的可以用下面的短语来表述它们：\n\n- ViewMatchers – “ `找` 某些东西“\n- ViewActions – “ `做` 某些事情“\n- ViewAssertions – “ `检查` 某些东西“\n\n举个例子，当你需要 `检查` 某些东西（像在屏幕中显示一些文字），你就会知道你需要一个 ViewAssertions 来做这些工作。\n\nBelow is an example of a test in Espresso, and where the main components find their place.\n\n下面是使用 Espresso 的例子，你会看到那些主要的组件将会在哪里出现使用。\n\n![main components](https://androidresearch.files.wordpress.com/2015/03/espesso_main_components.png)\n\n\n## 一个使用 onView() 的简单测试\n\n假设我们有一个 app，需要用户输入它的名字。\n\n输入名字之后，用户按下了“下一步”按钮然后就会跳转到另一个显示问候信息的 activity。\n\n![scenario](https://androidresearch.files.wordpress.com/2015/03/simple_test_onview.png?w=595)\n\n如果我们按这个方案来写一个测试的话，它看上去将会这样：\n\n``` Java\n// locate the view with id \"user_name\" and type the text \"John\"\nonView(withId(R.id.user_name)).perform(typeText(\"John\"));\n \n// locate the view with id \"next\" and click on it\nonView(withId(R.id.next)).perform(click());\n \n// locate the view with id \"greeting_message\" and check its text is equal with \"Hello John!\"\nonView(withId(R.id.greeting_message)).check(matches(withText(\"Hello John!\")));\n\n```\n\n注意到我们并没有特别指定与其交互的 view 的信息（eg： EditText、Button），我们只是简单的说明了我们要找一个指定 id 的 view。\n\n同样，当点击“下一步”按钮时然后检测文本时，我们也没有写代码来告诉 Espresso 我们有跳转到其它的 activity。\n\n现在，如果要跑起这个测试用例，我们需要把这写代码写到一个类中，然后对于在 Gradle 中这个类应该保存的位置：yourApp`/src/androidTest/java`。\n\n这个就是测试类的样子和它的主要特征：\n\n![SimpleNameTest](https://androidresearch.files.wordpress.com/2015/03/class.png)\n\n## 一个使用 onData 的简单测试\n\n每当你有一个 ListView、GridView、Spinner 或者其它基于 Adapter 的view时，你都必须使用 `onData()` 来把 item 和 list 的数据联系起来。\n\n**onData()** 是给你的 adapter 提供数据的。这是什么意思呢，接下来你就会知道了。\n\n在一个假想的程序中我们需要在一个 **Spinner** 中选择一个国家，一旦选定，这个国家的名字就会在 Spinner 的旁边显示出来。\n\n![Registration](https://androidresearch.files.wordpress.com/2015/03/ondata_simple.png?w=595)\n\n下面的测试就是检查显示出的国家是否与我们选择的相符合，代码长这样：\n\n``` Java\n// locate the view with id \"country_spinner\" and click on it\nonView(withId(R.id.country_spinner)).perform(click());\n \n// match an item that is a String and is equal with whatever value the COUNTRY constant is initialized, then click on it.\nonData(allOf(is(instanceOf(String.class)), is(COUNTRY))).perform(click());\n \n// locate the view with id \"selected_country\" and check its text is equal with COUNTRY\nonView(withId(R.id.selected_country)).check(matches(withText(\"selected: \" + COUNTRY)));\n```\n\n上文中你看到的这个 Spinner 的适配数据是一个字符串的简单数组，所以对于我们要找的 item 来说我们也要指定 String 的数据类型。如果不是一个 String 而是一些自定义的对象呢，我们应该指定这些自定义的对象。\n\n思考下下面这个显示一个 books 的 list 集合数据的例子：\n\n![AdapterView](https://androidresearch.files.wordpress.com/2015/03/books-adapter1.png?w=595&h=388)\n\n把 item 的数据改为 Book 后，来看看查询:\n\n``` Java\nonData(allOf(is(instanceOf(Book.class)), withBookTitle(BOOK_TITLE))).perform(click());\n```\n\n\n## 数据交互\n\nEspresso 有一些很有用的方法可以用来处理数据间的交互。\n\n**atPosition()** - 在下述的这些情况中会很有用，与相应元素交互的对象是不相关的，或 items 的顺序是特定的所以你知道每个 item 在哪个位置。\n\n``` Java\nonData(...).atPosition(2).perform(click());\n```\n\n**inRoot()** - 在没有默认窗口的情况下使用 inRoot()。这个场景可以应用在测试需自动完成时。这个 list 出现在自动输入填写完成的 view 是属于应用窗口之上的窗口视图。\n\n这种情况下你必须指定你要查找的数据，而这数据并不在主程序窗口中。\n\n``` Java\nonView(withText(\"AutoCompleteText\"))\n .inRoot(withDecorView(not(is(getActivity().getWindow().getDecorView()))))\n .check(matches(isDisplayed()));\n```\n\n**onChildView()** - 这个数据交互可以进一步地精取出在一个 list 中的指定的（item） view。\n\n你有一个集合列表，每一行的 item 上都有一个删除按钮。你想点击指定 item 上的删除按钮：\n\n``` Java\nonData(withBookTitle(\"My Book\"))\n .onChildView(withId(R.id.book_delete)).perform(click());\n```\n\n**inAdapterView()** - 可以选择指定一个 adapter view 去操作，默认情况下 Espresso 可以操作任何 adapter view。\n\n你可能会发现这个在处理 `ViewPagers` 和 `Fragments` 时很有用，或者，你想要与当前显示的 AdapterView 交互时，你的 activity 中有多个 adapter view 时。\n\n``` Java\nonData(withBookTitle(\"My Book\"))\n .inAdapterView(allOf(isAssignableFrom(AdapterView.class), isDisplayed()))\n .perform(click());\n```\n\n\n## Espresso 和 RecyclerView\n\n[RecyclerView](https://developer.android.com/reference/android/support/v7/widget/RecyclerView.html) 是一个像 ListView、GridVIew 那样呈现数据集合的 UI 组件，实际上它的目的是要替换掉这两个组件。从测试的角度上来看我们感兴趣的有是 RecyclerView 不是一个 AdapterView，这意味着你不能使用 onData() 去跟你的 list items 交互。\n\nFortunately, there is a class called RecyclerViewActions that exposes a small API to operate on a RecyclerView. RecyclerViewActions is part of a separate lib called espresso-contrib, that also should be added to build.gradle:\n\n幸运的是，有一个叫 [RecyclerViewActions](https://developer.android.com/reference/android/support/test/espresso/contrib/RecyclerViewActions.html) 的类提供了简单的 API 给我们操作 RecyclerView。RecyclerViewActions 是 **espresso-contrib**库的一部分，这个库的依赖可以在 build.gradle 中添加：\n\n``` Gradle\ndependencies {\n // ...\n \n androidTestCompile('com.android.support.test.espresso:espresso-contrib:2.0');\n}\n```\n\n因为你的项目已经包括 recyclerview 依赖, 所以不妨也加上支持库的，一些依赖关系可能出现的冲突。在这种情况下可以在 espresso-contrib 中 exclude 他们：\n\n``` Java\ndependencies {\n // ...\n \n androidTestCompile('com.android.support.test.espresso:espresso-contrib:2.0') {\n exclude group: 'com.android.support', module: 'appcompat'\n exclude group: 'com.android.support', module: 'support-v4'\n exclude module: 'recyclerview-v7'\n }\n}\n```\n\n下面就是示例怎么（在RecyclerView）点击指定位置的 item：\n\n``` Java\nonView(withId(R.id.recyclerView))\n .perform(RecyclerViewActions.actionOnItemAtPosition(0, click()));\n```\n\n或者怎么点击指定 item 上的 view：\n\n``` Java\nonView(withId(R.id.recyclerView))\n .perform(RecyclerViewActions.actionOnItem(\n hasDescendant(withText(BOOK_TITLE)), click()));\n```\n\n更多 Espresso 的例子请戳：[https://github.com/vgrec/EspressoExamples](https://github.com/vgrec/EspressoExamples)" }, { "path": "issue-11/Android进行单元测试难在哪-part3.md", "content": "Android 进行单元测试难在哪-part3\n---\n\n> * 原文链接 : [HOW TO MAKE OUR ANDROID APPS UNIT TESTABLE (PT. 1)](http://philosophicalhacker.com/2015/05/01/how-to-make-our-android-apps-unit-testable-pt-1/)\n* 原文作者 : [Matthew Dupree](http://philosophicalhacker.com/)\n* [译文出自 : 开发技术前线 www.devtf.cn](http://www.devtf.cn)\n* 译者 : [chaossss](https://github.com/chaossss) \n* 校对者: [tiiime](https://github.com/tiiime) \n* 状态 : 完成 \n\n\n在 Android 应用中进行单元测试很困难，有时候甚至是不可能的。在[之前的两篇博文](https://github.com/bboyfeiyu/android-tech-frontier/blob/master/issue-9/Android%20%E8%BF%9B%E8%A1%8C%E5%8D%95%E5%85%83%E6%B5%8B%E8%AF%95%E9%9A%BE%E5%9C%A8%E5%93%AA-part1.md)中，我已经向大家解释了在 Android 中进行单元测试如此困难的原因。而[上一篇博文](https://github.com/bboyfeiyu/android-tech-frontier/blob/master/issue-10/Android%E8%BF%9B%E8%A1%8C%E5%8D%95%E5%85%83%E6%B5%8B%E8%AF%95%E9%9A%BE%E5%9C%A8%E5%93%AA-part2.md)我们通过分析得到的结论是：正是 Google 官方所提倡的应用架构方式使得在 Android 中进行单元测试变成一场灾难。因为在官方提倡的架构方式中，Google 似乎希望我们将业务逻辑都放在应用的组件类中（例如：Activity，Fragment，Service，等等……）。而这种开发方式也是我们一直以来使用的开发模板。\n\n在这篇博文中，我列举出几种架构 Android 应用的方法，使用这些方法进行开发能让单元测试变得轻松些。但正如我在[序](https://github.com/bboyfeiyu/android-tech-frontier/blob/master/issue-8/Android%20%E8%BF%9B%E8%A1%8C%E5%8D%95%E5%85%83%E6%B5%8B%E8%AF%95%E9%9A%BE%E5%9C%A8%E5%93%AA-%E5%BA%8F.md)中所说，我最推崇的办法始终是[ Square 在他们的应用中抛弃 Fragment ](https://corner.squareup.com/2014/10/advocating-against-android-fragments.html)所用的通用方法。因为这个方法是由 Square 中的 Android 开发工程师想出来的，所以我会在接下来的博文中将这个办法叫作“Square 大法”。\n\nSquare 大法的核心思想是：把应用组件类中的业务逻辑全部移除（例如：Activity，Fragment，Service，等等……），并且把业务逻辑转移到业务对象，而这些业务对象都是被依赖注入的纯 Java 对象，以及与 Android 无关的接口在此的 Android 特定实现。如果我们在开发应用的时候使用 Square 大法，那进行单元测试就简单多了。在这篇博文中，我会解释 Square 大法是如何帮助我们重构 UI 无关的应用组件（例如我们在之前的博文中讨论的 SessionCalendarService），并让对它进行单元测试变得容易许多。\n\n## 用 Square 大法重构 UI 无关的应用组件\n\n用 Square 大法重构类似于 Service，ContentProvider，BroadcastReceiver这样的 UI 无关的应用组件相对来说比较容易。我再说一次我们要做的事情吧：把在这些类中的业务逻辑移除，并把它们放到业务对象中。\n\n由于“业务逻辑”是很容易有歧义的词语，我来解释下我使用“业务逻辑”这个词时，它所代表的含义吧。当我提到“业务逻辑”，它的含义和维基百科上的解释是一致的：程序中根据现实世界中的规则用于决定数据将如何被创建，展示，储存和修改的那部分代码。那么现在我们就可以就“业务逻辑”这个词的含义达成共识了，那就来看看 Square 大法到底是啥吧。\n\n我们先来看看怎么用 Square 大法实现我在之前的博文中介绍的 SessionCalendarService 吧，具体代码如下：\n\n```java\n/**\n * Background {@link android.app.Service} that adds or removes session Calendar events through\n * the {@link CalendarContract} API available in Android 4.0 or above.\n */\npublic class SessionCalendarService extends IntentService {\n private static final String TAG = makeLogTag(SessionCalendarService.class);\n \n //...\n \n public SessionCalendarService() {\n super(TAG);\n }\n \n @Override\n protected void onHandleIntent(Intent intent) {\n final String action = intent.getAction();\n Log.d(TAG, \"Received intent: \" + action);\n \n final ContentResolver resolver = getContentResolver();\n \n boolean isAddEvent = false;\n \n if (ACTION_ADD_SESSION_CALENDAR.equals(action)) {\n isAddEvent = true;\n \n } else if (ACTION_REMOVE_SESSION_CALENDAR.equals(action)) {\n isAddEvent = false;\n \n } else if (ACTION_UPDATE_ALL_SESSIONS_CALENDAR.equals(action) &&\n PrefUtils.shouldSyncCalendar(this)) {\n try {\n getContentResolver().applyBatch(CalendarContract.AUTHORITY,\n processAllSessionsCalendar(resolver, getCalendarId(intent)));\n sendBroadcast(new Intent(\n SessionCalendarService.ACTION_UPDATE_ALL_SESSIONS_CALENDAR_COMPLETED));\n } catch (RemoteException e) {\n LOGE(TAG, \"Error adding all sessions to Google Calendar\", e);\n } catch (OperationApplicationException e) {\n LOGE(TAG, \"Error adding all sessions to Google Calendar\", e);\n }\n \n } else if (ACTION_CLEAR_ALL_SESSIONS_CALENDAR.equals(action)) {\n try {\n getContentResolver().applyBatch(CalendarContract.AUTHORITY,\n processClearAllSessions(resolver, getCalendarId(intent)));\n } catch (RemoteException e) {\n LOGE(TAG, \"Error clearing all sessions from Google Calendar\", e);\n } catch (OperationApplicationException e) {\n LOGE(TAG, \"Error clearing all sessions from Google Calendar\", e);\n }\n \n } else {\n return;\n }\n \n final Uri uri = intent.getData();\n final Bundle extras = intent.getExtras();\n if (uri == null || extras == null || !PrefUtils.shouldSyncCalendar(this)) {\n return;\n }\n \n try {\n resolver.applyBatch(CalendarContract.AUTHORITY,\n processSessionCalendar(resolver, getCalendarId(intent), isAddEvent, uri,\n extras.getLong(EXTRA_SESSION_START),\n extras.getLong(EXTRA_SESSION_END),\n extras.getString(EXTRA_SESSION_TITLE),\n extras.getString(EXTRA_SESSION_ROOM)));\n } catch (RemoteException e) {\n LOGE(TAG, \"Error adding session to Google Calendar\", e);\n } catch (OperationApplicationException e) {\n LOGE(TAG, \"Error adding session to Google Calendar\", e);\n }\n }\n \n //...\n}\n```\n\n如你所见，SessionCalendarService 调用了将要在后面定义的 helper 方法。一旦我们将这些 helper 方法和类的字段声明也考虑进来，Service 类的代码就有400多行。要 hold 住这么庞大的类内发生的业务逻辑可不是什么简单的活，而且就像我们在上一篇博文中看到的那样，要在 SessionCalendarService 中进行单元测试简直是天方夜谭。\n\n那现在来看看用 Square 大法实现它代码会是怎样的。我再强调一次：Square 大法需要我们将 Android 类内的业务逻辑迁移到一个业务对象中。在这里，SessionCalendarService 所对应的业务对象则是 SessionCalendarUpdater，具体代码如下：\n\n```java\npublic class SessionCalendarUpdater {\n \n //...\n \n private SessionCalendarDatabase mSessionCalendarDatabase;\n private SessionCalendarUserPreferences mSessionCalendarUserPreferences;\n \n public SessionCalendarUpdater(SessionCalendarDatabase sessionCalendarDatabase,\n SessionCalendarUserPreferences sessionCalendarUserPreferences) {\n \n mSessionCalendarDatabase = sessionCalendarDatabase;\n mSessionCalendarUserPreferences = sessionCalendarUserPreferences;\n }\n \n public void updateCalendar(CalendarUpdateRequest calendarUpdateRequest) {\n \n boolean isAddEvent = false;\n \n String action = calendarUpdateRequest.getAction();\n \n long calendarId = calendarUpdateRequest.getCalendarId();\n \n if (ACTION_ADD_SESSION_CALENDAR.equals(action)) {\n isAddEvent = true;\n \n } else if (ACTION_REMOVE_SESSION_CALENDAR.equals(action)) {\n isAddEvent = false;\n \n } else if (ACTION_UPDATE_ALL_SESSIONS_CALENDAR.equals(action)\n && mSessionCalendarUserPreferences.shouldSyncCalendar()) {\n \n try {\n \n mSessionCalendarDatabase.updateAllSessions(calendarId);\n \n } catch (RemoteException | OperationApplicationException e) {\n \n LOGE(TAG, \"Error adding all sessions to Google Calendar\", e);\n }\n \n } else if (ACTION_CLEAR_ALL_SESSIONS_CALENDAR.equals(action)) {\n \n try {\n \n mSessionCalendarDatabase.clearAllSessions(calendarId);\n \n } catch (RemoteException | OperationApplicationException e) {\n \n LOGE(TAG, \"Error clearing all sessions from Google Calendar\", e);\n }\n \n } else {\n return;\n }\n \n \n if (!shouldUpdateCalendarSession(calendarUpdateRequest, mSessionCalendarUserPreferences)) {\n return;\n }\n \n try {\n \n CalendarSession calendarSessionToUpdate = calendarUpdateRequest.getCalendarSessionToUpdate();\n \n if (isAddEvent) {\n \n mSessionCalendarDatabase.addCalendarSession(calendarId, calendarSessionToUpdate);\n } else {\n \n mSessionCalendarDatabase.removeCalendarSession(calendarId, calendarSessionToUpdate);\n }\n \n } catch (RemoteException | OperationApplicationException e) {\n LOGE(TAG, \"Error adding session to Google Calendar\", e);\n }\n }\n \n private boolean shouldUpdateCalendarSession(CalendarUpdateRequest calendarUpdateRequest, \n SessionCalendarUserPreferences sessionCalendarUserPreferences) {\n \n return calendarUpdateRequest.getCalendarSessionToUpdate() == null || !sessionCalendarUserPreferences.shouldSyncCalendar();\n }\n}\n```\n\n我想要强调其中的一些要点：首先，需要注意，我们完全不需要用到任何新的关键字，因为业务对象的依赖都被注入了，它根本不会使用新的关键字，而这正是让类可单元测试的关键。其次，你会注意到类没有确切地依赖于 Android SDK，因为业务对象的依赖都是 Android 无关接口的 Android 特定实现，因此它不需要依赖于 Android SDK。\n\n那么这些依赖是怎么添加到　SessionCalendarUpdater　类中的呢？是通过　SessionCalendarService　类注入进去的：\n\n```java\n/**\n * Background {@link android.app.Service} that adds or removes session Calendar events through\n * the {@link CalendarContract} API available in Android 4.0 or above.\n */\npublic class SessionCalendarService extends IntentService {\n private static final String TAG = makeLogTag(SessionCalendarService.class);\n \n public SessionCalendarService() {\n super(TAG);\n }\n \n @Override\n protected void onHandleIntent(Intent intent) {\n final String action = intent.getAction();\n Log.d(TAG, \"Received intent: \" + action);\n \n final ContentResolver resolver = getContentResolver();\n \n Broadcaster broadcaster = new AndroidBroadcaster(this);\n \n SessionCalendarDatabase sessionCalendarDatabase = new AndroidSessionCalendarDatabase(resolver,\n broadcaster);\n \n SharedPreferences defaultSharedPreferences = PreferenceManager.getDefaultSharedPreferences(this);\n \n SessionCalendarUserPreferences sessionCalendarUserPreferences = new AndroidSessionCalendarUserPreferences(defaultSharedPreferences);\n \n SessionCalendarUpdater sessionCalendarUpdater\n = new SessionCalendarUpdater(sessionCalendarDatabase,\n sessionCalendarUserPreferences);\n \n AccountNameRepository accountNameRepository = new AndroidAccountNameRepository(intent, this);\n \n String accountName = accountNameRepository.getAccountName();\n \n long calendarId = sessionCalendarDatabase.getCalendarId(accountName);\n CalendarSession calendarSessionToUpdate = CalendarSession.fromIntent(intent);\n \n CalendarUpdateRequest calendarUpdateRequest = new CalendarUpdateRequest(action, calendarId, calendarSessionToUpdate);\n \n sessionCalendarUpdater.updateCalendar(calendarUpdateRequest);\n }\n}\n```\n\n值得注意的是，修改后的 SessionCalendarService 到处都是新的关键字，但这些关键字在类中并不会引起什么问题。如果我们花几秒时间略读一下要点就会明白这一点：SessionCalendarService 类中已经没有任何业务逻辑，因此 SessionCalendarService 类不再需要进行单元测试。只要我们确定在 SessionCalendarService 调用的是 SessionCalendarUpdater 类中的 updateCalendar() 方法，在 SessionCalendarService 唯一可能出现的就是编译时错误。我们完全不需要为此实现测试单元，因为这是编译器的工作，与我们无关。\n\n由于我在前两篇博文中提到的相关原因，将我们的 Service 类拆分成这样会使对业务逻辑进行单元测试变得非常简单，例如我们对 SessionCalendarUpdater 类进行单元测试的代码可以写成下面的样子：\n\n```java\npublic class SessionCalendarUpdaterTests extends TestCase {\n \n public void testShouldClearAllSessions() throws RemoteException, OperationApplicationException {\n \n SessionCalendarDatabase sessionCalendarDatabase = mock(SessionCalendarDatabase.class);\n \n SessionCalendarUserPreferences sessionCalendarUserPreferences = mock(SessionCalendarUserPreferences.class);\n \n \n SessionCalendarUpdater sessionCalendarUpdater = new SessionCalendarUpdater(sessionCalendarDatabase,\n sessionCalendarUserPreferences);\n \n CalendarUpdateRequest calendarUpdateRequest = new CalendarUpdateRequest(SessionCalendarUpdater.ACTION_CLEAR_ALL_SESSIONS_CALENDAR,\n 0,\n null);\n \n sessionCalendarUpdater.updateCalendar(calendarUpdateRequest);\n \n verify(sessionCalendarDatabase).clearAllSessions(0);\n }\n}\n```\n\n## 结论\n\n为了能够进行单元测试，我认为修改后的代码变得更易读和更易维护了。可以肯定的是，我们还有许多办法能让代码变得更好，但在让代码能够进行单元测试的过程中，我想让修改后的代码尽可能与修改前风格相似，所以我没有进行其他修改。在下一篇博文中，我将会教大家如何使用 Square 大法重构应用的 UI 组件（例如：Fragment 和 Activity）。\n" }, { "path": "issue-11/Code Review最佳实践.md", "content": "Code Review最佳实践\n====\n> * 原文链接 : [Code Review Best Practices](http://kevinlondon.com/2015/05/05/code-review-best-practices.html)\n* 原文作者 : [Kevin London](http://kevinlondon.com/about/)\n* [译文出自 : 开发技术前线 www.devtf.cn](http://www.devtf.cn)\n* 译者 : [ayyb1988](https://github.com/ayyb1988) \n* 校对者: [chaossss](https://github.com/chaossss) \n* 状态 : 完成\n\n\n在Wiredrive上，我们做了很多的Code Review。在此之前我从来没有做过，这对于我来说是一个全新的体验，下面来总结一下在Code Review中做的事情以及说说谈论Code Review的最好方式。\n\n简单的说，Code Review是开发者之间讨论修改代码来解决问题的过程。很多文章谈论了Code Review的诸多好处，包括知识共享，代码的质量，开发者的成长，却很少讨论审查什么、如何审查。\n\n###审查的内容\n\n####体系结构和代码设计\n\n* [单一职责原则：](http://en.wikipedia.org/wiki/Single_responsibility_principle)一个类有且只能一个职责。我通常使用这个原则去衡量，如果我们必须使用“和”来描述一个方法做的事情，这可能在抽象层上出了问题。\n\n* [开闭原则](http://en.wikipedia.org/wiki/Open/closed_principle)如果是面向对象的语言，对象对可扩展开放、对修改关闭。如果我们需要添加另外的内容会怎样？\n\n* 代码复用：根据[\"三振法\"](http://c2.com/cgi/wiki?ThreeStrikesAndYouRefactor),如果代码被复制一次，虽然如喜欢这种方式，但通常没什么问题。但如果再一次被复制，就应该通过提取公共的部分来重构它。\n\n* [换位考虑](http://robertheaton.com/2014/06/20/code-review-without-your-eyes/)，如果换位考虑，这行代码是否有问题？用这种模式是否可以发现代码中的问题。\n\n* 用更好的代码： 如果在一块混乱的代码做修改，添加几行代码也许更容易，但我建议更进一步，用比原来更好的代码。\n\n* 潜在的bugs：是否会引起的其他错误？循环是否以我们期望的方式终止？\n\n* 错误处理：错误确定被优雅的修改？会导致其他错误？如果这样，修改是否有用？\n\n* 效率： 如果代码中包含算法，这种算法是否是高效？ 例如，在字典中使用迭代，遍历一个期望的值，这是一种低效的方式。\n\n\n####代码风格\n* 方法名： 在计算机科学中，命名是一个难题。一个函数被命名为==get_message_queue_name==，但做的却是完全不同的事情，比如从输入内容中清除html，那么这是一个不准确的命名，并且可能会误导。\n\n* 值名：对于数据结构，==foo== or ==bar== 可能是无用的名字。相比==exception==， ==e==同样是无用的。如果需要(根据语言)尽可能详细，在重新查看代码时，那些见名知意的命名是更容易理解的。\n\n* 函数长度： 对于一个函数的长度，我的经验值是小于20行，如果一个函数在50行以上，最好把它分成更小的函数块。\n\n\n* 类的长度：我认为类的长度应该小于300行，最好在100内。把较长的类分离成独立的类，这样更容易理解类的功能。\n\n* 文件的长度： 对于Python，一个文件最多1000行代码。任何高于此的文件应该把它分离成更小更内聚,看一下是否违背的“单一职责” 原则。\n* 文档：对于复杂的函数来说，参数个数可能较多，在文档中需要指出每个参数的用处，除了那些显而易见的。\n\n* 注释代码： 移除任何注释代码行。\n* 函数参数个数：不要太多， 一般不要超过3个。。\n* 可读性： 代码是否容易理解？在查看代码时要不断的停下来分析它？\n\n####测试\n* 测试的范围：我喜欢测试新功能。测试是否全面？是否涵盖了故障的情况【比如：网络，信号等，译者注】？是否容易使用？是否稳定？大多的测试？性能的快慢？\n* 合乎规范的测试：当复查测试时，确保我们用适当的方式。换句话说，当我们在一个较低水平测试却要求期望的功能？Gary Bernhardt建议95％的单元测试，5％的集成测试。特别是在Django项目中，在较高的测试水平上，很容易发现意外bug，创建一个详细的测试用例，认真仔细也是很重要的。\n\n####审查代码\n在提交代码之前，我经常用git添加改变的文件/文件夹,然后通过git diff 来查看做了哪些修改。通常，我会关注如下几点：\n* 是否有注释？\n* 变量名是否见名知意？\n* ...等上面提到的\n\n和著名的橡皮鸭调试法（Rubber Duck Debugging）一样，每次提交前整体把自己的代码过一遍非常有帮助，尤其是看看有没有犯低级错误。\n\n\n####如何进行Code Review\n当Code Review时，会遇到不少问题，我也学会了如何处理，下面是一些方法：\n\n* 提问： 这个函数是如何生效的？如果需求变更，应该做什么改变？怎么更容易维护？\n* 表扬/奖励良好的做法：Code Review重要的一点是奖励开发者的成长和努力。得到别人的肯定是一件很不错的事情，我尽可能多的给人积极的评论。\n* 当面讨论代替评论。 大部分情况下小组内的同事是坐在一起的，当面的 code review是非常有效的。\n* 说明理由 ：是否还有跟好的方式，证明为什么这样做是好的。\n\n####心态上\n* 作为一个Developer , 不仅要Deliver working code, 还要Deliver maintable code.\n* 必要时进行重构，随着项目的迭代，在计划新增功能的同时，开发要主动计划重构的工作项。\n* 开放的心态，虚心接受大家的Review Comments。\n\n####参考\n一些关于clean code的书籍，如下：\n* [Clean Code](http://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882)\n* [Refactoring](http://www.amazon.com/Refactoring-Improving-Design-Existing-Code/dp/0201485672)\n* [All the Small Things by Sandi Metz](https://www.youtube.com/watch?v=8bZh5LMaSmE&index=1&list=LLlt4ZSW8NUcXLWiB3NMnK_w)\n* [How to Design a Good API and Why it Matters](https://www.youtube.com/watch?v=aAb7hSCtvGw&list=LLlt4ZSW8NUcXLWiB3NMnK_w&index=48)\n* [Discussion on Hacker News](https://news.ycombinator.com/item?id=9517892)\n\n##译者注\n#####一. 参考了 http://jimhuang.cn/?p=59\n\n#####二. 国内阿里的[陈皓](http://coolshell.cn/articles/author/haoel)写的关于codereview的文章，也很有见底，推荐大家看看\n######1.[Code Review中的几个提示](http://coolshell.cn/articles/1302.html)\n* 先Review设计实现思路，然后Review设计模式，接着Review成形的骨干代码，最后Review完成的代码，如果程序复杂的话，需要拆成几个单元或模块分别Review\n* Code Review不要太正式，而且要短\n* 学会享受Code Reivew\n\n######2.[从Code Review 谈如何做技术](http://coolshell.cn/articles/11432.html/comment-page-1#comments)\n\n#####三. Code Review 工具\n[Review Board](https://github.com/reviewboard/reviewboard)\n\n#####四.\n在Code Review时，要在 **意识** **方法** **心态** **习惯** 这几个方面上下功夫，坚持code review，相信我们会在各方面有很大的提升。\n" }, { "path": "issue-11/readme.md", "content": "# 开发技术前线 第10期\n\n| 文章名称 | 译者 | \n|---------|--------|\n| [Android-Espresso测试框架介绍](Android-Espresso测试框架介绍.md) | [zhengxiaopeng](https://github.com/zhengxiaopeng) |\n| [Android 进行单元测试难在哪-part3](Android进行单元测试难在哪-part3.md) | [chaossss](https://github.com/chaossss)|\n| [Code Review最佳实践](Code Review最佳实践.md) | [ayyb1988](https://github.com/ayyb1988) |\n| [听FaceBook工程师讲Custom-ViewGroups](听FaceBook工程师讲Custom-ViewGroups.md) | [objectlife](https://github.com/objectlife)|\n| [详解Dagger2](详解Dagger2.md) | [xianjiajun](https://github.com/xianjiajun) |\n" }, { "path": "issue-11/听FaceBook工程师讲Custom-ViewGroups.md", "content": "#听FackBook工程师讲*Custom ViewGroups*\n\n---\n\n> * 原文链接 : [Custom ViewGroups](https://sriramramani.wordpress.com/2015/05/06/custom-viewgroups/)\n* 原文作者 : [Sriram Ramani](https://sriramramani.wordpress.com/)\n* [译文出自 : 开发技术前线 www.devtf.cn](http://www.devtf.cn)\n* 译者 : [objectlife](https://github.com/objectlife) \n* 校对者: [xianjiajun](https://github.com/xianjiajun) \n* 状态 : 完成 \n\nAndroid提供了几个ViewGroups如LinearLayout, RelativeLayout, FrameLayout来固定child Views的位置。在这些普通的ViewGroups中有多种使用选择。\n例如：LinearLayout几乎支持HTML Flexbox的所有特性(除了包装)。在view之间你可以选择是否显示分割线(dividers),并且基于最大的child测量所有的children。RelativeLayout是一种限制性的解决方案。这些layouts都已经足够好了，但是当你的UI非常复杂的时候它们还能很好的解决么？\n\n![](https://sriramramani.files.wordpress.com/2015/05/custom-view-group.png?w=1594&h=204)\n\n>ViewGroup with a ProfilePhoto, Title, Subtitle and Menu button.\n\n上面的这种布局在Facebook app中是非常常见的。有头像、其它的view垂直摆在它的右侧、还有一个可选操作的view在最右边。这个布局可以通过使用LinearLayout嵌套或者一个RelativeLayout这样的普通ViewGroup实现。我们看一下当分别使用这两种布局的情况下在measure时会发生什么。\n\n使用LinearLayout完成布局的示例\n\n```java\n\n \n \n \n \n \n \n \n \n \n \n \n \n \n\n```\n在Nexus 5设备上measure发生时的情况如下\n\n```\n> LinearLayout [horizontal] [w: 1080 exactly, h: 1557 exactly ]\n > ProfilePhoto [w: 120 exactly, h: 120 exactly ]\n > LinearLayout [vertical] [w: 0 unspecified, h: 0 unspecified]\n > Title [w: 0 unspecified, h: 0 unspecified]\n > Subtitle [w: 0 unspecified, h: 0 unspecified]\n > Title [w: 222 exactly, h: 57 exactly ]\n > Subtitle [w: 222 exactly, h: 57 exactly ]\n > Menu [w: 60 exactly, h: 60 exactly ]\n > LinearLayout [vertical] [w: 900 exactly, h: 1557 at_most ]\n > Title [w: 900 exactly, h: 1557 at_most ]\n > Subtitle [w: 900 exactly, h: 1500 at_most ] \n```\n\n\nProfilePhoto和Menu只被测量了一次，因为它们有明确的宽高值。垂直的LinearLayout被测量了两次。第一次的时候，父LinearLayout要求以UNSPECIFIED spec的方式来测量。导致了垂直的LinearLayout也以这种方式测量它的子view.此时它在它们返回值的基础上以EXACTLY spec的方式测量它的子view，但是它还没有结束。一旦在测量ProfilePhoto和Menu之后，父布局知道可用于垂直的LinearLayout的尺寸大小。以AT_MOST height对Title 和 Subtitle测量之后导致了第二次传值。显然，每一个TextView (Title and Subtitle)被测量3次。第二次传值创建或者废弃Layouts，这些操作是昂贵的。如果想ViewGroup发挥更好的性能，首要的工作就是免去对TextViews的测量传值工作。\n\n\n使用RelativeLayout效果会不会好一些?\n\n```java\n\n \n \n \n \n \n \n \n \n \n\n```\n\n测量情况如下：\n\n```\n> RelativeLayout [w: 1080 exactly, h: 1557 exactly]\n > Menu [w: 60 exactly, h: 1557 at_most]\n > ProfilePhoto [w: 120 exactly, h: 1557 at_most]\n > Title [w: 900 exactly, h: 1557 at_most]\n > Subtitle [w: 900 exactly, h: 1557 at_most]\n > Title [w: 900 exactly, h: 1557 at_most]\n > Subtitle [w: 900 exactly, h: 1500 at_most]\n > Menu [w: 60 exactly, h: 60 exactly]\n > ProfilePhoto [w: 120 exactly, h: 120 exactly]\n```\n\n\n正如先前提到的，RelativeLayout是通过solving constraints(分解约束。译者认为就是一层一层的测量)进行测量，上面的布局中ProfilePhoto和Menu没有依赖其它的参照物(siblings)，因此它们先被测量(with an AT_MOST height).这时Title(2个约束)和Subtitle(3个约束)才会被测量。此时所有view明确了自己想要的尺寸大小。RelativeLayout使用这些信息第二次传值给Title, Subtitle, Menu和ProfilePhoto。再重复一遍，每个view被测量了两次，因此这种方案稍佳。如果你和上面的LinearLayout例子相比较一下，最后用于测量所有leaf Views所使用的MeasureSpec是相同的-因此最后的输出结果是一样的。\n\n\n怎么样才能免去对子view的测量传值呢？自定义一个ViewGroup是不是会有帮助？让我们分析一下这个布局。Title 和 Subtitle 总是在ProfilePhoto的左侧在Menu按钮的右侧。如果我们手工解决这个问题，需要计算出ProfilePhoto和Menu按钮的尺寸，并且使用剩下的尺寸再来计算Title 和 Subtitle。这时对每个view只进行一次测量传值。我们叫这种布局为ProfilePhotoLayout。\n\n\n```java\npublic class ProfilePhotoLayout extends ViewGroup {\n \n private ProfilePhoto mProfilePhoto;\n private Menu mMenu;\n private Title mTitle;\n private Subtitle mSubtitle;\n \n @Override\n protected void onMeasure(int widthMeasureSpec, int heightMeasureSpec) {\n // 1. Setup initial constraints.\n int widthConstraints = getPaddingLeft() + getPaddingRight();\n int heightContraints = getPaddingTop() + getPaddingBottom();\n int width = 0;\n int height = 0;\n \n // 2. Measure the ProfilePhoto\n measureChildWithMargins(\n mProfilePhoto,\n widthMeasureSpec,\n widthConstraints,\n heightMeasureSpec,\n heightConstraints);\n \n // 3. Update the contraints.\n widthConstraints += mProfilePhoto.getMeasuredWidth();\n width += mProfilePhoto.getMeasuredWidth();\n height = Math.max(mProfilePhoto.getMeasuredHeight(), height);\n \n // 4. Measure the Menu.\n measureChildWithMargins(\n mMenu,\n widthMeasureSpec,\n widthConstraints,\n heightMeasureSpec,\n heightConstraints);\n \n // 5. Update the constraints.\n widthConstraints += mMenu.getMeasuredWidth();\n width += mMenu.getMeasuredWidth();\n height = Math.max(mMenu.getMeasuredHeight(), height);\n \n // 6. Prepare the vertical MeasureSpec.\n int verticalWidthMeasureSpec = MeasureSpec.makeMeasureSpec(\n MeasureSpec.getSize(widthMeasureSpec) - widthConstraints,\n MeasureSpec.getMode(widthMeasureSpec));\n \n int verticalHeightMeasureSpec = MeasureSpec.makeMeasureSpec(\n MeasureSpec.getSize(heightMeasureSpec) - heightConstraints,\n MeasureSpec.getMode(heightMeasureSpec));\n \n // 7. Measure the Title.\n measureChildWithMargins(\n mTitle,\n verticalWidthMeasureSpec,\n 0,\n verticalHeightMeasureSpec,\n 0);\n \n // 8. Measure the Subtitle.\n measureChildWithMargins(\n mSubtitle,\n verticalWidthMeasureSpec,\n 0,\n verticalHeightMeasureSpec,\n mTitle.getMeasuredHeight());\n \n // 9. Update the sizes.\n width += Math.max(mTitle.getMeasuredWidth(), mSubtitle.getMeasuredWidth());\n height = Math.max(mTitle.getMeasuredHeight() + mSubtitle.getMeasuredHeight(), height);\n \n // 10. Set the dimension for this ViewGroup.\n setMeasuredDimension(\n resolveSize(width, widthMeasureSpec),\n resolveSize(height, heightMeasureSpec));\n }\n \n @Override\n protected void measureChildWithMargins(\n View child,\n int parentWidthMeasureSpec,\n int widthUsed,\n int parentHeightMeasureSpec,\n int heightUsed) {\n MarginLayoutParams lp = (MarginLayoutParams) child.getLayoutParams();\n \n int childWidthMeasureSpec = getChildMeasureSpec(\n parentWidthMeasureSpec,\n widthUsed + lp.leftMargin + lp.rightMargin,\n lp.width);\n \n int childHeightMeasureSpec = getChildMeasureSpec(\n parentHeightMeasureSpec,\n heightUsed + lp.topMargin + lp.bottomMargin,\n lp.height);\n \n child.measure(childWidthMeasureSpec, childHeightMeasureSpec);\n }\n}\n```\n\n我们来分析一下代码。我们从已知的约束条件开始 — 所有边的内边距，另外还需要考虑的约束是使用固定值的控件的高和宽。Android提供了一个帮助方法-measureChildWithMargins()用于测量ViewGroup内的子view.然而它总是添加padding作为约束条件的一部分。因此我们复写这个方法自己来管理这些约束条件。从测量ProfilePhoto开始，测量完成后更新一下constraints。对menu按钮的测量亦是如此。\n现在还剩下Title和Subtitle的宽度没有测量。Android还提供了另外一个帮助方法-makeMeasureSpec()，用于构造MeasureSpec,传入相应的size和mode返回一个MeasureSpec。接下来我们传入Title 和 Subtitle可用的width 和 height及相应的MeasureSpecs来测量Title 和 Subtitle。最后更新一下ViewGroup的尺寸。在这一步可以明确每个view都只被测量一次。\n\n\n```\n> ProfilePhotoLayout [w: 1080 exactly, h: 1557 exactly]\n > ProfilePhoto [w: 120 exactly, h: 120 exactly]\n > Menu [w: 60 exactly, h: 60 exactly]\n > Title [w: 900 exactly, h: 1557 at_most]\n > Subtitle [w: 900 exactly, h: 1500 at_most]\n```\n\n\n性能上是不是提升了？Facebook app中你看见的大多数布局都使用了这种布局，并且经证明确实提高了性能。我把没有提到的onLayout()方法留给读者作为练习。\n\n\n你喜欢解决这种Android UI 工程问题么? Facebook在这方面缺少专业的人才。\n\n[点击申请](https://www.facebook.com/careers/department?req=a0I1200000G49VNEAZ&dept=engineering&q=UI%20Engineer)\n\n" }, { "path": "issue-11/详解Dagger2.md", "content": "Dagger2\n---\n\n> * ԭ : [Tasting Dagger 2 on Android](http://fernandocejas.com/2015/04/11/tasting-dagger-2-on-android/)\n* ԭ : [Fernando Cejas](http://fernandocejas.com/)\n* [ij : ǰ www.devtf.cn](http://www.devtf.cn)\n* : [xianjiajun](https://github.com/xianjiajun) \n* У: [chaossss](https://github.com/chaossss) \n* ״̬ : \n\n##Ϊʲôʹע\nҪ֪ںܳһʱﶼÿƷתԭ涨ӦóȡڳʱͼĽͨĶ󽻻ʵĶ̡̬ʹע뼼߷λʱ󶨡\n\nʹעԴºô\n\n* עö֮⡣\n* ΪһϵĵطʼԵע󷽷ʱֻҪ޸ĶʵַôĴ⡣\n* ע뵽һУǿעЩģʵ֣ʹòԸӼ򵥡\n\nԿܹʵķΧһdz顣ҵĹ۵㣬appежЭ߶Ӧ֪йʵڵκ飬ЩӦǵעܹġ\n\n![p1](http://fernandocejas.com/wp-content/uploads/2015/04/dependency_inversion1.png)\n\n#ʲôJSR-330\nΪ̶ȵߴĸԡԺάԣjavaעΪעеʹöһע⣨ͽӿڣ׼Dagger1Dagger2Guiceǻױ׼ȶԺͱ׼ע뷽\n\n#Dagger1\n汾ƪµص㣬ֻǼԵ˵һ¡Dagger1˺ܶĹף˵AndroidеעܡSquare˾ܵGuiceġ\n\nص㣺\n\n* ע㣺ͨinjected\n* ְ󶨷ͨprovided\n* modulesʵijֹܵİ󶨼\n* ͼ ʵһΧmodules\n\nDagger1ڱʱʵа󶨣Ҳõ˷ơ䲻ʵģͼĹɡDaggerеʱȥǷһжʹõʱḶһЩۣżЧ͵ѡ\n\n#Dagger2\nDagger2Dagger1ķ֧ɹȸ蹫˾ֿĿǰİ汾2.0Dagger2ܵ[AutoValueĿ](https://github.com/google/auto)\nտʼDagger2Ļ˼ǣɺдĴϴﵽеIJṩĴ붼дӡ\n\nǽDagger21Ƚϣںܶ෽涼dzƣҲкҪ£\n\n* Ҳûʹ÷䣺ͼ֤úԤöڱʱִС\n* ׵ԺͿɸ٣ȫصṩʹĶջ\n* õܣȸ13%Ĵ\n* ʹDzͬԼдĴһ\n\nȻЩܰص㶼ҪһۣǾȱԣ磺Dagger2û÷ûж̬ơ\n\n#о\nҪ˽Dagger2ͱҪ֪עĻеÿһ\n\n* @Inject: ͨҪĵطʹע⡣仰˵DaggerֶҪע롣Daggerͻṹһʵǵ\n\n* @Module: ModulesķרṩǶһ࣬@Moduleע⣬Daggerڹʵʱ򣬾֪ȥҵҪmodulesһҪΪһ𣨱˵ǵappпжһmodules\n\n* @Provide: modulesУǶķע⣬ԴDaggerҪṩЩ\n\n* @Component: ComponentsӸ˵һעҲ˵@Inject@ModuleҪþ֡Componentsṩж˵͵ʵ磺DZ@ComponentעһӿȻге@Modulesɸȱʧκһ鶼ڱʱ򱨴еͨmodules֪ķΧ\n\n* @Scope: ScopesǷdzãDagger2ͨԶע޶ע򡣺ʾһӣһdzǿص㣬Ϊǰ˵һûҪÿȥ˽ιǵʵscopeУԶ@PerActivityעһ࣬ʱͺactivityһ˵ǿԶзΧ(@PerFragment, @PerUser, ȵ)\n\n* Qualifier: ͲԼһʱǾͿʹעʾ磺AndroidУǻҪͬ͵contextǾͿԶqualifierע⡰@ForApplication͡@ForActivityעһcontextʱǾͿԸDaggerҪ͵context\n\n#ϻϴ\nǰѾ˺ܶˣԽǿʹDagger2ȻҪǵbuild.gradleļã\n```java\napply plugin: 'com.neenbedankt.android-apt'\n \nbuildscript {\n repositories {\n jcenter()\n }\n dependencies {\n classpath 'com.neenbedankt.gradle.plugins:android-apt:1.4'\n }\n}\n \nandroid {\n ...\n}\n \ndependencies {\n apt 'com.google.dagger:dagger-compiler:2.0'\n compile 'com.google.dagger:dagger:2.0'\n \n ...\n}\n```\n\nʾ˱п⣬бزٵaptûdaggerܲرAndroid studioС\n\n#\nǰдһƪAndroidʵbobܹ£ǿҽȥһ£֮㽫иõ⡣ԹǰķУṩʱ򣬻⣬£ע\n```java\n @Override void initializePresenter() {\n // All this dependency initialization could have been avoided by using a\n // dependency injection framework. But in this case this is used this way for\n // LEARNING EXAMPLE PURPOSE.\n ThreadExecutor threadExecutor = JobExecutor.getInstance();\n PostExecutionThread postExecutionThread = UIThread.getInstance();\n\n JsonSerializer userCacheSerializer = new JsonSerializer();\n UserCache userCache = UserCacheImpl.getInstance(getActivity(), userCacheSerializer,\n FileManager.getInstance(), threadExecutor);\n UserDataStoreFactory userDataStoreFactory =\n new UserDataStoreFactory(this.getContext(), userCache);\n UserEntityDataMapper userEntityDataMapper = new UserEntityDataMapper();\n UserRepository userRepository = UserDataRepository.getInstance(userDataStoreFactory,\n userEntityDataMapper);\n\n GetUserDetailsUseCase getUserDetailsUseCase = new GetUserDetailsUseCaseImpl(userRepository,\n threadExecutor, postExecutionThread);\n UserModelDataMapper userModelDataMapper = new UserModelDataMapper();\n\n this.userDetailsPresenter =\n new UserDetailsPresenter(this, getUserDetailsUseCase, userModelDataMapper);\n }\n```\n\nԿİ취ʹעܡҪô룺಻漰Ĵṩ\nǸôأȻʹDagger2ȿṹͼ\n![pic2](http://fernandocejas.com/wp-content/uploads/2015/04/composed_dagger_graph1.png)\n\nǻֽͼ͸ֻд롣\n\nApplication Component: ڸApplicationһע뵽AndroidApplicationBaseActivityС\n\n```java\n@Singleton // Constraints this component to one-per-application or unscoped bindings.\n@Component(modules = ApplicationModule.class)\npublic interface ApplicationComponent {\n void inject(BaseActivity baseActivity);\n\n //Exposed to sub-graphs.\n Context context();\n ThreadExecutor threadExecutor();\n PostExecutionThread postExecutionThread();\n UserRepository userRepository();\n}\n```\n\nΪʹ@Singletonע⣬ʹ䱣֤ΨһԡҲΪʲôҪcontextԱ¶ȥDaggercomponentsҪʣ㲻modulesͱ¶ôֻʾʹǡУҰЩԪر¶ͼɾʱͻᱨ\n\nApplication Module: moduleṩӦõдĶҲΪʲô@ProvideעķҪ@Singleton޶\n\n```java\n@Module\npublic class ApplicationModule {\n private final AndroidApplication application;\n\n public ApplicationModule(AndroidApplication application) {\n this.application = application;\n }\n\n @Provides @Singleton Context provideApplicationContext() {\n return this.application;\n }\n\n @Provides @Singleton Navigator provideNavigator() {\n return new Navigator();\n }\n\n @Provides @Singleton ThreadExecutor provideThreadExecutor(JobExecutor jobExecutor) {\n return jobExecutor;\n }\n\n @Provides @Singleton PostExecutionThread providePostExecutionThread(UIThread uiThread) {\n return uiThread;\n }\n\n @Provides @Singleton UserCache provideUserCache(UserCacheImpl userCache) {\n return userCache;\n }\n\n @Provides @Singleton UserRepository provideUserRepository(UserDataRepository userDataRepository) {\n return userDataRepository;\n }\n}\n```\n\nActivity Component: ڸActivityһ\n\n```java\n@PerActivity\n@Component(dependencies = ApplicationComponent.class, modules = ActivityModule.class)\npublic interface ActivityComponent {\n //Exposed to sub-graphs.\n Activity activity();\n}\n```\n\n@PerActivityһԶķΧע⣬󱻼¼ȷУȻЩӦѭactivityڡһܺõϰҽǶһ£ºô\n\n* ע󵽹췽Ҫactivity\n* һper-activityϵĵʹá\n* ֻactivityʹʹȫֵĶͼ\n\n´룺\n```java\n@Scope\n@Retention(RUNTIME)\npublic @interface PerActivity {}\n```\n\nActivity Module: ڶͼУmoduleactivity¶ࡣfragmentʹactivitycontext\n\n```java\n@Module\npublic class ActivityModule {\n private final Activity activity;\n\n public ActivityModule(Activity activity) {\n this.activity = activity;\n }\n\n @Provides @PerActivity Activity activity() {\n return this.activity;\n }\n}\n```\nUser Component: ̳ActivityComponent@PerActivityע⡣ͨעûصfragmentʹáΪActivityModuleactivity¶ͼˣκҪһactivitycontextʱDaggerṩע룬ûҪmodulesжˡ\n\n```java\n@PerActivity\n@Component(dependencies = ApplicationComponent.class, modules = {ActivityModule.class, UserModule.class})\npublic interface UserComponent extends ActivityComponent {\n void inject(UserListFragment userListFragment);\n void inject(UserDetailsFragment userDetailsFragment);\n}\n```\nUser Module: ṩûصʵǵӣṩû\n\n```java\n@Module\npublic class UserModule {\n @Provides @PerActivity GetUserListUseCase provideGetUserListUseCase(GetUserListUseCaseImpl getUserListUseCase) {\n return getUserListUseCase;\n }\n\n @Provides @PerActivity GetUserDetailsUseCase provideGetUserDetailsUseCase(GetUserDetailsUseCaseImpl getUserDetailsUseCase) {\n return getUserDetailsUseCase;\n }\n}\n```\n#ϵһ\nѾʵעͼҸע룿Ҫ֪Daggerһѡע\n\n 1. 췽ע룺Ĺ췽ǰע@Inject\n 2. Աע룺ijԱ˽Уǰע@Inject\n 3. ע룺ںǰע@Inject\n\n˳DaggerʹõģΪеĹУܻһЩֵǿָ룬Ҳζڶ󴴽ʱܻûгʼɡAndroidactivityfragmentʹóԱעᾭΪûǵĹ췽ʹá\n\nصǵУһBaseActivityעһԱУעһNavigator࣬Ӧиࡣ\n\n```java\npublic abstract class BaseActivity extends Activity {\n\n @Inject Navigator navigator;\n\n @Override\n protected void onCreate(Bundle savedInstanceState) {\n super.onCreate(savedInstanceState);\n this.getApplicationComponent().inject(this);\n }\n\n protected ApplicationComponent getApplicationComponent() {\n return ((AndroidApplication)getApplication()).getApplicationComponent();\n }\n\n protected ActivityModule getActivityModule() {\n return new ActivityModule(this);\n }\n}\n```\n\nNavigatordzԱעģApplicationModule@ProvideעʾṩġdzʼcomponentȻinject()עԱͨActivityonCreate()еgetApplicationComponent()ЩgetApplicationComponent()Ϊ˸ԣҪΪ˻ȡʵApplicationComponent\n\nFragmentpresenterҲͬ飬Ļȡһ㲻һΪʹõper-activityΧ޶componentע뵽UserDetailsFragmentеUserComponentʵפUserDetailsActivityеġ\n\n```java\nprivate UserComponent userComponent;\n```\nDZactivityonCreate()ķʽʼ\n```java\nprivate void initializeInjector() {\n this.userComponent = DaggerUserComponent.builder()\n .applicationComponent(getApplicationComponent())\n .activityModule(getActivityModule())\n .build();\n}\n```\nDaggerᴦǵע⣬ΪcomponentsʵֲϡDaggerǰ׺ΪһϵcomponentڹʱDZеĴȥcomponentsmodulesǵcomponentѾ׼ˣΪ˿fragmentдһȡ\n\n```java\n@Override public UserComponent getComponent() {\n return userComponent;\n}\n```\nڿgetȡcomponentȻinject()FragmentΪȥ˰UserDetailsFragment\n\n```java\n@Override public void onActivityCreated(Bundle savedInstanceState) {\n super.onActivityCreated(savedInstanceState);\n this.getComponent.inject(this);\n}\n```\n[Ҫ鿴ӣȥҵgithub](https://github.com/android10/Android-CleanArchitecture).һЩطع˵ģҿԸһҪ˼루Թٷӣǣ\n\n```java\npublic interface HasComponent {\n C getComponent();\n}\n```\nˣͻˣfragmentԻȡʹcomponentactivity\n```java\n@SuppressWarnings(\"unchecked\")\nprotected C getComponent(Class componentType) {\n return componentType.cast(((HasComponent)getActivity()).getComponent());\n}\n```\nʹǿתͻ˲ܻȡõcomponentٺܿͻʧܡκ뷨ܹõؽ⣬ҡ\n#Dagger2ɵĴ\n˽DaggerҪ֮ڲ졣Ϊ˾˵ǻNavigator࣬δעġǿһǵDaggerApplicationComponent\n```java\n@Generated(\"dagger.internal.codegen.ComponentProcessor\")\npublic final class DaggerApplicationComponent implements ApplicationComponent {\n private Provider provideNavigatorProvider;\n private MembersInjector baseActivityMembersInjector;\n\n private DaggerApplicationComponent(Builder builder) { \n assert builder != null;\n initialize(builder);\n }\n\n public static Builder builder() { \n return new Builder();\n }\n\n private void initialize(final Builder builder) { \n this.provideNavigatorProvider = ScopedProvider.create(ApplicationModule_ProvideNavigatorFactory.create(builder.applicationModule));\n this.baseActivityMembersInjector = BaseActivity_MembersInjector.create((MembersInjector) MembersInjectors.noOp(), provideNavigatorProvider);\n }\n\n @Override\n public void inject(BaseActivity baseActivity) { \n baseActivityMembersInjector.injectMembers(baseActivity);\n }\n\n public static final class Builder {\n private ApplicationModule applicationModule;\n \n private Builder() { \n }\n \n public ApplicationComponent build() { \n if (applicationModule == null) {\n throw new IllegalStateException(\"applicationModule must be set\");\n }\n return new DaggerApplicationComponent(this);\n }\n \n public Builder applicationModule(ApplicationModule applicationModule) { \n if (applicationModule == null) {\n throw new NullPointerException(\"applicationModule\");\n }\n this.applicationModule = applicationModule;\n return this;\n }\n }\n}\n```\nصҪע⡣һҪע뵽activityУԻõһעȳԱעDaggerɵBaseActivity_MembersInjector\n```java\n@Generated(\"dagger.internal.codegen.ComponentProcessor\")\npublic final class BaseActivity_MembersInjector implements MembersInjector {\n private final MembersInjector supertypeInjector;\n private final Provider navigatorProvider;\n\n public BaseActivity_MembersInjector(MembersInjector supertypeInjector, Provider navigatorProvider) { \n assert supertypeInjector != null;\n this.supertypeInjector = supertypeInjector;\n assert navigatorProvider != null;\n this.navigatorProvider = navigatorProvider;\n }\n\n @Override\n public void injectMembers(BaseActivity instance) { \n if (instance == null) {\n throw new NullPointerException(\"Cannot inject members into a null reference\");\n }\n supertypeInjector.injectMembers(instance);\n instance.navigator = navigatorProvider.get();\n }\n\n public static MembersInjector create(MembersInjector supertypeInjector, Provider navigatorProvider) { \n return new BaseActivity_MembersInjector(supertypeInjector, navigatorProvider);\n }\n}\n```\nעһ㶼ΪactivityעԱṩֻҪһinject()ͿԻȡҪֶκ\n\nڶص㣺ǵDaggerApplicationComponent࣬һProviderһṩʵĽӿڣDZScopedProviderģԼ¼ʵķΧ\n\nDaggerΪǵNavigatorһApplicationModule_ProvideNavigatorFactoryĹԴᵽķΧȻõΧڵʵ\n\n```java\n@Generated(\"dagger.internal.codegen.ComponentProcessor\")\npublic final class ApplicationModule_ProvideNavigatorFactory implements Factory {\n private final ApplicationModule module;\n\n public ApplicationModule_ProvideNavigatorFactory(ApplicationModule module) { \n assert module != null;\n this.module = module;\n }\n\n @Override\n public Navigator get() { \n Navigator provided = module.provideNavigator();\n if (provided == null) {\n throw new NullPointerException(\"Cannot return null from a non-@Nullable @Provides method\");\n }\n return provided;\n }\n\n public static Factory create(ApplicationModule module) { \n return new ApplicationModule_ProvideNavigatorFactory(module);\n }\n}\n```\n\ndz򵥣ǵApplicationModule@ProvideNavigatorࡣ\n\n֮Ĵ뿴óģҷdz⣬ڵԡ໹кܶȥ̽ǿͨȥDagger󶨵ġ\n![pic3](http://fernandocejas.com/wp-content/uploads/2015/04/debugging_dagger.png)\n\n#Դ:\n: https://github.com/android10/Android-CleanArchitecture\n#:\n[Architecting AndroidThe clean way?](http://fernandocejas.com/2014/09/03/architecting-android-the-clean-way/)\n[Dagger 2, A New Type of Dependency Injection.](https://www.youtube.com/watch?v=oK_XtfXPkqw)\n[Dependency Injection with Dagger 2.](https://speakerdeck.com/jakewharton/dependency-injection-with-dagger-2-devoxx-2014)\n[Dagger 2 has Components.](https://publicobject.com/2014/11/15/dagger-2-has-components/)\n[Dagger 2 Official Documentation.](http://google.github.io/dagger/)" }, { "path": "issue-12/Android上MVP的介绍.md", "content": "MVP在Android平台上的应用\n---\n\n> * 原文链接 : [Introduction to Model-View-Presenter on Android](http://konmik.github.io/introduction-to-model-view-presenter-on-android.html)\n* 原文作者 : [konmik](http://konmik.github.io/)\n* 译文出自 : [ 其他 http://konmik.github.io/introduction-to-model-view-presenter-on-android.html](http://konmik.github.io/introduction-to-model-view-presenter-on-android.html)\n* 译者 : [MiJack](https://github.com/MiJack) \n* 校对者: [MiJack](https://github.com/MiJack) \n* 状态 : 校对完成\n\n=======\n\n\n\n#Android平台上MVP的介绍\n\n\n\n这篇文章向你介绍Android平台上的MVP模式，从一个简浅的例子开始实践之路。文章也会介绍一个一个库让你在Android平台上轻松的实现MVP\n\n\n\n##简单吗？我怎么才能从中受益？\n\n\n###什么是MVP？\n\n\n\n\n- **View**层主要是用于展示数据并对用户行为做出反馈。在Android平台上，他可以对应为Activity, Fragment,View或者对话框。\n- **Model**是数据访问层，往往是数据库接口或者服务器的API。\n- **Presenter**层可以想View层提供来自数据访问层的数据，除此以外，他也会处理一些后台事务。\n\n\n在Android平台上，MVP可以将后台事务从Activity/View/Fragment中分离出来，让它们独立于大部分生命周期事件。这样，一个应用将会变得简单， 整个应用可靠性可以提高10倍，应用的代码将会变短, 代码的可维护性提高，开发者也为此感到高兴。\n\n\n###Android为什么需要MVP\n\n\n####理由1：尽量简单\n\n如果你还有读过这篇文章，请阅读它：[Kiss原则](https://people.apache.org/~fhanik/kiss.html)（Keep It Stupid Simple）\n\n\n- 大部分的安卓应用只使用View-Model结构\n- 程序员现在更多的是和复杂的View打交道而不是解决业务逻辑。\n\n\n当你在应用中只使用Model-View时，到最后，你会发现“所有的事物都被连接到一起”。\n![](http://konmik.github.io/images/mvp_everything_is_connected_with_everything.png)\n\n\n如果这张图看上去还不是很复杂，那么请你想象一下以下情况：每一个View在任意一个时刻都有可能出现或者消失。不要忘记View的保存和恢复，在临时的view上挂载一个后台任务。\n\n“所有的事物都被连接到一起”的替代品是一个万能对象(god object)。\n\n![](http://konmik.github.io/images/mvp_a_god_object.png)\n\n\ngod object是十分复杂的，他的每一个部分都不能重复利用，无法轻易的测试、或者调试和重构。\n\n###With MVP\n\n###使用MVP\n\n![](http://konmik.github.io/images/mvp_mvp.png)\n\n\n\n复杂的任务被分成细小的任务，并且很容易解决。越小的东西，bug越少，越容易debug，更好测试。在MVP模式下的View层将会变得简单，所以即便是他请求数据的时候也不需要回调函数。View逻辑变成十分直接。\n\n\n理由2：后台任务\n\n\n当你编写一个Actviity、Fragment、自定义View的时候，你会把所有的和后台任务相关的方法写在一个静态类或者外部类中。这样，你的Task不再和Activity联系在一起，这既不会导致内存泄露，也不依赖于Activity的重建。\n\n\n这里有若干种方法处理后台任务，但是它们的可靠性都不及MVP。\n\n\n###为什么它是可行的？\n\n\n这里有一张表格，用于展示在configuration改变、Activity 重启、Out-Of-Memory时，不同的应用部分会发生什么？\n\n \n| | 情景 1 | 情景 2 | 情景 3|\n|:-------------:|:-------------:|:-------------:|:-------------:|\n||配置改变| Activity 重启| 进程重启|\n |对话框 | 重置 | 重置 | 重置|\n|Activity, View, Fragment | 保存/恢复 | 保存/恢复 | 保存/恢复|\n| Fragment with setRetainInstance(true) |无变化 | 保存/恢复 | 保存/恢复|\n| Static variables and threads | 无变化 | 无变化 | 重置|\n\n\n\n情景 1: 当用户切换屏幕、更改语言设置或者链接外部的模拟器时，往往意味着设置改变。 相关更多请阅读[这里](http://developer.android.com/reference/android/R.attr.html#configChanges)。\n\n情景 2:Activity的重启发生在当用户在开发者选项中选中了“Don't keep activities”（“中文下为 不保留活动”）的复选框，然后另一个Activity在最顶上的时候。\n\n情景 3: 进程的重启发生在应用运行在后台，但是这个时候内存不够的情况下。\n\n\n\n###总结\n\n\n现在你可以发现，一个setRetainInstance(true)的Fragment也不奏效，我们还是希望这样的Fragment在所有的情景下为保存/恢复的状态模式，所以为简化问题，我们暂不考虑上述情况的Fragment。[Occam's razor](http://en.wikipedia.org/wiki/Occam's_razor)\n\n\n\n| |配置改变, Activity重启 | 进程重启|\n|:-------------:|:-------------:|:-------------:|\n |Activity, View, Fragment, DialogFragment | 保存/恢复 |保存/恢复 |\n|Static variables and threads | 无变化 | 重置|\n\n\n\n现在，看上去更舒服了，我们只需要写两段代码为了恢复应用：\n\n* 保存/恢复 for Activity, View, Fragment, DialogFragment;\n\n* 重启后台请求由于进程重启\n\n\n第一个部分,用Android的API可以实现。第二个部分，就是Presenter的作用了。Presenter只会记住有哪些请求需要执行，当进程在执行过程中重启时，Presenter将会再次执行它们。\n\n\n#####一个简单的例子(no MVP)\n\n这个例子用于从远程服务器加载数据并呈现，当发生异常时，会通过Toast提示。\n\n我推荐使用[RxJava](https://github.com/ReactiveX/RxJava)构建Presenter，因为这个库更容易控制数据流。\n\n我想对创造如此简单的API的伙计说声谢谢，我把它用于[The Internet Chuck Norris Database](http://www.icndb.com/)\n\n无MVP的[例子00](https://github.com/konmik/MVPExamples/tree/master/example00)：\n\n```java\n\npublic class MainActivity extends Activity {\n public static final String DEFAULT_NAME = \"Chuck Norris\";\n\n private ArrayAdapter adapter;\n private Subscription subscription;\n\n @Override\n public void onCreate(Bundle savedInstanceState) {\n super.onCreate(savedInstanceState);\n setContentView(R.layout.activity_main);\n ListView listView = (ListView)findViewById(R.id.listView);\n listView.setAdapter(adapter = new ArrayAdapter<>(this, R.layout.item));\n requestItems(DEFAULT_NAME);\n }\n\n @Override\n protected void onDestroy() {\n super.onDestroy();\n unsubscribe();\n }\n\n public void requestItems(String name) {\n unsubscribe();\n subscription = App.getServerAPI()\n .getItems(name.split(\"\\\\s+\")[0], name.split(\"\\\\s+\")[1])\n .delay(1, TimeUnit.SECONDS)\n .observeOn(AndroidSchedulers.mainThread())\n .subscribe(new Action1() {\n @Override\n public void call(ServerAPI.Response response) {\n onItemsNext(response.items);\n }\n }, new Action1() {\n @Override\n public void call(Throwable error) {\n onItemsError(error);\n }\n });\n }\n\n public void onItemsNext(ServerAPI.Item[] items) {\n adapter.clear();\n adapter.addAll(items);\n }\n\n public void onItemsError(Throwable throwable) {\n Toast.makeText(this, throwable.getMessage(), Toast.LENGTH_LONG).show();\n }\n\n private void unsubscribe() {\n if (subscription != null) {\n subscription.unsubscribe();\n subscription = null;\n }\n }\n}\n\n```\n\n有经验的开发者会注意到这个例子有以下不妥：\n\n\n当用户翻转屏幕时候会开始请求，应用发起了过多的请求，将会是屏幕在切换的时候呈现空白的界面。\n\n当用户频繁的切换屏幕，这将会造成内存泄露，请求运行时，每一个回调将会持有MainActivity的引用，让其保存在内存中。因此引起的OOM和应用反应迟缓，会引发应用的Crash。\n\n\nMVP模式下的[例子 01](https://github.com/konmik/MVPExamples/tree/master/example01)\n\n```java\npublic class MainPresenter {\n\n public static final String DEFAULT_NAME = \"Chuck Norris\";\n\n private ServerAPI.Item[] items;\n private Throwable error;\n\n private MainActivity view;\n\n public MainPresenter() {\n App.getServerAPI()\n .getItems(DEFAULT_NAME.split(\"\\\\s+\")[0], DEFAULT_NAME.split(\"\\\\s+\")[1])\n .delay(1, TimeUnit.SECONDS)\n .observeOn(AndroidSchedulers.mainThread())\n .subscribe(new Action1() {\n @Override\n public void call(ServerAPI.Response response) {\n items = response.items;\n publish();\n }\n }, new Action1() {\n @Override\n public void call(Throwable throwable) {\n error = throwable;\n publish();\n }\n });\n }\n\n public void onTakeView(MainActivity view) {\n this.view = view;\n publish();\n }\n\n private void publish() {\n if (view != null) {\n if (items != null)\n view.onItemsNext(items);\n else if (error != null)\n view.onItemsError(error);\n }\n }\n}\n\n```\n\n从严格意义上来说，MainPresenter有三个事件处理线程： *onNext*, *onError*, *onTakeView*。他们在`publish()`方法中被回调，*onNext* 或 *onError*的值将会在由onTakeView方法传入的View实例,也就是MainActivity中来发布。 \t \n\n\n```java\npublic class MainActivity extends Activity {\n\n private ArrayAdapter adapter;\n\n private static MainPresenter presenter;\n\n @Override\n public void onCreate(Bundle savedInstanceState) {\n super.onCreate(savedInstanceState);\n setContentView(R.layout.activity_main);\n\n ListView listView = (ListView)findViewById(R.id.listView);\n listView.setAdapter(adapter = new ArrayAdapter<>(this, R.layout.item));\n\n if (presenter == null)\n presenter = new MainPresenter();\n presenter.onTakeView(this);\n }\n\n @Override\n protected void onDestroy() {\n super.onDestroy();\n presenter.onTakeView(null);\n if (isFinishing())\n presenter = null;\n }\n\n public void onItemsNext(ServerAPI.Item[] items) {\n adapter.clear();\n adapter.addAll(items);\n }\n\n public void onItemsError(Throwable throwable) {\n Toast.makeText(this, throwable.getMessage(), Toast.LENGTH_LONG).show();\n }\n}\n```\n\nMainActivty构建了MainPresenter，将其维持在onCreate/onDestroy周期外，MainActivity持有MainPresenter的静态引用，所以每一个进程由于OOM重启时，MainActivity可以确认Presenter是否仍然存在，必要时创建。\n\n当然，确认和使用静态变量可能是代码变得臃肿，稍后我们会告诉你如何好看些：。:)\n\n####重要思路：\n\n* 示例程序不会在每次切换屏幕的时候都开始一个新的请求\n* 当进程重启时，示例程序将会重新加载数据。\n* 当MainActivity销毁时，MainPresenter不会持有MainActivity的引用，因此不会在切换屏幕的时候发生内存泄漏，而且没必要去unsubscribe请求。\n\n###[Nucleus](https://github.com/konmik/nucleus)\n\nNucleus是我从[Mortar](https://github.com/square/mortar)和 Keep It Stupid Simple 这篇文章得到的灵感而建立的库。\n\n它有以下特征：\n\n* 它支持在View/Fragment/Activity的Bundle中保存/恢复Presenter的状态，一个Presenter可以保存它的请求参数到bundles中，以便之后重启它们\n \n* 只需要一行代码，它就可以直接将请求结果和错误反馈给View，所以你不需要写`!= null`之类的非空判断语句。\n \n* 它允许一个view实例可以持有多个Presenter。不过你不能在用[Dagger](http://square.github.io/dagger/)实例化的presenter中这样使用(传统方法).\n\n* 它可以用一行代码快速的将View和Presenter绑定。\n\n* 它提供一些现成的基类，例如: `NucleusView`, `NucleusFragment`, `NucleusSupportFragment`, `NucleusActivity`. 你可以将他们的代码拷贝出来改造出一个自己的类以利用Nucleus的presenter。\n\n* 支持在进程重启后，自动重新发起请求，在`onDestroy`方法中，自动的退订RxJava的订阅。\n\n* 最后，它简洁明了，每一个开发者都会理解，以上这些只用了180行代码来驱动Presenter这个类,加上230行RxJava的依赖。\n\n\n使用了[Nucleus](https://github.com/konmik/nucleus) 的[例 02](https://github.com/konmik/MVPExamples/tree/master/example02)\n\n```java\npublic class MainPresenter extends RxPresenter {\n\n public static final String DEFAULT_NAME = \"Chuck Norris\";\n\n @Override\n protected void onCreate(Bundle savedState) {\n super.onCreate(savedState);\n\n App.getServerAPI()\n .getItems(DEFAULT_NAME.split(\"\\\\s+\")[0], DEFAULT_NAME.split(\"\\\\s+\")[1])\n .delay(1, TimeUnit.SECONDS)\n .observeOn(AndroidSchedulers.mainThread())\n .compose(this.deliverLatestCache())\n .subscribe(new Action1() {\n @Override\n public void call(ServerAPI.Response response) {\n getView().onItemsNext(response.items);\n }\n }, new Action1() {\n @Override\n public void call(Throwable throwable) {\n getView().onItemsError(throwable);\n }\n });\n }\n}\n\n@RequiresPresenter(MainPresenter.class)\npublic class MainActivity extends NucleusActivity {\n\n private ArrayAdapter adapter;\n\n @Override\n public void onCreate(Bundle savedInstanceState) {\n super.onCreate(savedInstanceState);\n setContentView(R.layout.activity_main);\n\n ListView listView = (ListView)findViewById(R.id.listView);\n listView.setAdapter(adapter = new ArrayAdapter<>(this, R.layout.item));\n }\n\n public void onItemsNext(ServerAPI.Item[] items) {\n adapter.clear();\n adapter.addAll(items);\n }\n\n public void onItemsError(Throwable throwable) {\n Toast.makeText(this, throwable.getMessage(), Toast.LENGTH_LONG).show();\n }\n}\n```\n\n正如你看到的，跟上一个代码相比，这个例子十分简洁。Nucleus 可以构造/销毁/保存 Presenter, 绑定/解绑 View ，并且自动向已经绑定的view发送请求的结果。\n\n`MainPresenter`的代码比较短，因为它使用`deliverLatestCache（）`的操作，延迟了由一个数据源发出所有的数据和错误，直到View可用。它还把数据缓存在内存中，以便它可以在Configuration change时可以被重用。\n\n`MainActivity`的代码比较短，因为主Presenter的创作由`NucleusActivity`管理。当你需要绑定一个Presenter的时候，只需要添加注解`@RequiresPresenter（MainPresenter.class）`。\n\n警告！注释！在Android中，如果你使用注解，这是最好检查以下这么做会不会降低性能。以我使用的'Galaxy S`（2010年设备）为例，处理此批注耗时不超过0.3毫秒。只在实例化view的时候才会发生，因此注解在这里对性能的影响可以忽略。\n\n\n####更多例子\n\n\n一个扩展的例子,带有请求参数的Presenter：[Nucleus Example](https://github.com/konmik/nucleus/tree/master/nucleus-example)。\n\n\n带有单元测试的例子： [Nucleus Example With Tests](https://github.com/konmik/nucleus/tree/master/nucleus-example-with-tests)\n\n####`deliverLatestCache()` 方法\n\n这个RxPresenter的工具方法有三个变种：\n\n* `deliver()` will just delay all onNext, onError and onComplete emissions until a View becomes available. Use it for cases when you're doing a one-time request, like logging in to a web service. [Javadoc](http://konmik.github.io/nucleus/nucleus/presenter/Presenter.html#onCreate(android.os.Bundle))\n\n* `deliver()`只是推迟onNext、onError、onComplete的调用，直到视图有效。使用它，你只需要一次请求，就像发起登陆web服务一样。[Javadoc](http://konmik.github.io/nucleus/nucleus/presenter/Presenter.html#onCreate(android.os.Bundle))\n\n* `deliverLatest（）`当有新的的onNext值，将会舍弃原有的值，如果你有可更新的数据源，这将让你去除那些不需要的数据。[Javadoc](http://konmik.github.io/nucleus/nucleus/presenter/RxPresenter.html#deliverLatest)\n\n* `deliverLatestCache（）`，和`deliverLatest（）`一样，但除了它会在内存中保存最新的结果外，当View的另一个实例可用（例如：在配置更改的时候）时，还是会触发一次。如果你不想组织请求在你的View中的保存/恢复事务（比方说，结果太大或者不能很容易地保存在Bundle中），这个方法可以让用户体验更好。[Javadoc](http://konmik.github.io/nucleus/nucleus/presenter/RxPresenter.html#deliverLatestCache)\n\n####Presenter的生命周期\n\n相比Android组件，Presenter的生命周期更加简短。\n\n* `void onCreate(Bundle savedState)` - 每一个Presenter构造时 . [Javadoc](http://konmik.github.io/nucleus/nucleus/presenter/Presenter.html#onCreate(android.os.Bundle))\n\n* `void onDestroy()` - 用户离开View时调用 . [Javadoc](http://konmik.github.io/nucleus/nucleus/presenter/Presenter.html#onDestroy())\n\n* `void onSave(Bundle state)` - 在View的`onSaveInstanceState`方法中调用，用于持有Presenter的状态. [Javadoc](http://konmik.github.io/nucleus/nucleus/presenter/Presenter.html#onSave(android.os.Bundle))\n\n* `void onTakeView(ViewType view)` - 在Activity或者Fragment的`onResume()`方法中或者`android.view.View#onAttachedToWindow()`调用. [Javadoc](http://konmik.github.io/nucleus/nucleus/presenter/Presenter.html#onTakeView(ViewType))\n\n* `void onTakeView(ViewType view)` - 在Activity或者Fragment的`onResume()`方法中或者`android.view.View#onAttachedToWindow()`调用. [Javadoc](http://konmik.github.io/nucleus/nucleus/presenter/Presenter.html#onTakeView(ViewType))\n\n* `void onDropView()` - 在Activity或者Fragment的`onPause()`方法中或者`android.view.View#onDetachedFromWindow()`调用. [Javadoc](http://konmik.github.io/nucleus/nucleus/presenter/Presenter.html#onDropView)\n\n####View的回收与View栈\n\n通常来说,你的view（比如fragment或者自定义的view）在用户的交互过程中挂载与解挂（attached and detached）都是随机发生的。 这倒是不让presenter在view每次解挂（detached）的时候都销毁的一个启发。你可以在任何时候挂载与解挂view，但是presenter可以在这些行为中幸存下来，继续后台的工作。\n\n\n\n这里还存在着一个关于View回收的问题：一个Fragment在Configuration change或者从stack中弹出的情况下，不知道自身有没有解挂（detached）。\n\n默认只在Activity处于finish时，才在调用View的`onDetachedFromWindow()`/`onDestroy()` 销毁Presenter。\n\n所以，当你在常规的Activity生命周期内，销毁View，你需要给给View一个销毁Presenter的信号。在这里，公有方法`NucleusLayout.destroyPresenter()` and `NucleusFragment.destroyPresenter()`就派上用场了。\n\n例如，在我的项目中，下面的是我如何进行FragmentManager的`pop()`操作:\n\n```java\n fragment = fragmentManager.findFragmentById(R.id.fragmentStackContainer);\n fragmentManager.popBackStackImmediate();\n if (fragment instanceof NucleusFragment)\n ((NucleusFragment)fragment).destroyPresenter();\n```\n\n在进行*replace*Fragment栈和对处于底部的Fragment进行*push*操作时，你可能需要进行相同的操作。\n\n在View从Activity解挂（detached）时，您可能会选择摧毁Presenter来避免问题的发生，但是，这将意味着当View解挂（detached）时，后台任务无法继续进行。\n\n所以这一节的 \"view recycling\"完全留你你自己考虑，也许有一天我会找到更好的解决办法，如果你有一个办法，请告诉我。\n\n####最佳实践\n\n\n在Presenter中保存你的请求参数。\n\n规则很简单：Presenter的主要作用是管理请求。所以，View不应该自己处理或者重启请求。从View中，我们可以看见，后台事务不会消失，总是会返回结果或者错误，*而不是通过回调的方式*。\n\n\n\n```java\n\npublic class MainPresenter extends RxPresenter {\n\n private String name = DEFAULT_NAME;\n\n @Override\n protected void onCreate(Bundle savedState) {\n super.onCreate(savedState);\n if (savedState != null)\n name = savedState.getString(NAME_KEY);\n ...\n\n @Override\n protected void onSave(@NonNull Bundle state) {\n super.onSave(state);\n state.putString(NAME_KEY, name);\n }\n}\n```\n\n我推荐使用一个很棒的库[Icepick](https://github.com/frankiesardo/icepick)。在不使用运行时注解的前提下，它可以减少代码量，并简化应用程序逻辑 - 所有的事都在编译过程中已经处理好了。这个库和[ButterKnife](http://jakewharton.github.io/butterknife)搭配是个不错的选择。\n\n \n```java\npublic class MainPresenter extends RxPresenter {\n\n @Icicle String name = DEFAULT_NAME;\n\n @Override\n protected void onCreate(Bundle savedState) {\n super.onCreate(savedState);\n Icepick.restoreInstanceState(this, savedState);\n ...\n }\n @Override\n protected void onSave(@NonNull Bundle state) {\n super.onSave(state);\n Icepick.saveInstanceState(this, state);\n }\n}\n \n```\n\n如果你有不止一对请求参数，这个库在不使用运行时注解的前提下。您可以创建`BasePresenter`并把*Icepick*到该类中，所有的子类将会自动保存标有`@Icicle`这一注解的变量，而你将不再需要去实现`OnSave`。这也适用于保存Activity，Fragment，View的状态。\n\n\n####在主线程中调用`onTakeView`进行即时查询[Javadoc](http://konmik.github.io/nucleus/nucleus/presenter/Presenter.html#onTakeView(ViewType))\n\n\n有时候，你要进行少量的数据查询，如从数据库中读取少量的数据。虽然你可以很容易地用Nucleus创建一个可重启的请求，你不必到处使用这个强大的工具。如果你在fragment创建的时候初始化一个后台请求，即使只有几毫秒，用户也会看到一会儿的空白屏。因此，为了使代码更短，用户体验更好，可以使用主线程。\n\n\n#### 不要让Presenter控制你的View\n\n这不是很好的工作方式 - 由于这种不自然的方式，应用程序逻辑变得太复杂。\n\n自然的方式是操作流由用户发起，通过View，Presenter和Model，最后流向数据。毕竟，用户将使用应用,用户是控制应用程序的源头。因此，控制应该从用户开始而不是一些应用的内部结构。\n\n\n从view，到presenter到model是很直接的形式，很容易书写这样的代码。你将得到以下序列： __user -> view -> presenter -> model -> data__ 。但是，当控制流变成这样时: __user -> view -> presenter -> view -> presenter -> model -> data__，它只是违反KISS原则.\n\n\n\nFragments？不好意思它是违背了这种自然操作流程的。它们太复杂。这里是一个非常好讲诉Fragment的文章：[抨击Android的Fragment](http://corner.squareup.com/2014/10/advocating-against-android-fragments.html)。fragment的替代者[Flow](https://github.com/square/flow) 并没有简化多少东西。\n\n####MVC\n\n如果你对MVC（模型-View-控制器）-不要去使用。模型-View-控制器和MVP完全不同，不能解决接口开发者面对的问题。\n\n####What is MVC?\n\n####什么是MVC?\n\n\n\n\n\n* **Model**代表着应用程序的内部状态。它可以负责存储，当然也可以不考虑。\n\n* **View**是唯一的与MVP相同的部分 - 它用于将模型呈现在屏幕上，应用程序的一部分。\n\n* **Controller**表示输入装置，如键盘，鼠标或操纵杆。\n\n\nMVC在过去以键盘为驱动的应用中（比如游戏），是比较好的模式。没有窗口和图形用户界面的交互——应用接受输入(Controller),维持状态（Model），产生输出（View）。同样，数据和控制的关系是这样的。**controller -> model -> view**。这种模式是在Android绝对无用。\n\n\n\n这里有一些关于MVC的困惑。人们（Web开发人员）觉得他们使用MVC，而实际上，他们使用的MVP。许多Android开发者认为Controller是用于控制View的，所以他们试图在创建View时，从视图（View）中提取视图逻辑，交由专门的控制器控制。我个人是没有看出这种架构的好处。\n\n\n#### 在数据复杂的项目中使用固定的数据结构\n\n\n\n在这方面，[AutoValue](https://github.com/google/auto/tree/master/value)是十分好的库，在它的描述中，你会发现一大堆好处，我建议你阅读它。Android平台上还有一个接口：[AutoParcel](https://github.com/frankiesardo/auto-parcel)。其主要原因是，你可以四处传递，而不用关心是否在程序的某个地方被修改了。而且他们也是线程安全的。\n\n\n\n\n###总结\n\n\n试试MVP吧，然后告诉你的朋友。:)\n" }, { "path": "issue-12/Android自动截屏工具.md", "content": "Android 自动截屏工具\n---\n\n> * 原文链接 : [Automating Android Screenshots](https://medium.com/@swanhtet1992/automating-android-screenshots-5b7574c0621d)\n* 原文作者 : [Swan Htet Aung](https://medium.com/@swanhtet1992)\n* [译文出自 : 开发技术前线 www.devtf.cn](http://www.devtf.cn)\n* 译者 : [sundroid](https://github.com/sundroid) \n* 校对者: [yinna317](https://github.com/yinna317 ) \n* 状态 : 完成\n\n随着mac版本AndroidTool的发布，获取android应用截屏变得非常简单。与此同时，感谢开发商！这对于我们开发者来说真是太好了！\n\n对于简单应用来说，AndroidTool是足够满足截屏的功能需求了，然而，我需要在在我正在开发的一款app上完成一个完全自动化的截图过程，并且将截图发布到应用市场。我认为这将不简单，所以，我尽量避免复杂的实现过程，而是想办法如何更好的结合AndroidTool来完成这个功能。\n\n然而当我昨天阅读了[Enrique López Mañas yesterday](https://medium.com/@enriquelopezmanas)的[Automating Android development](https://medium.com/google-developer-experts/automating-android-development-6daca3a98396)文章，我意识到，他在博客中讨论的话题我已经完成了4/5。唯一我还没有做的就是测试。我不喜欢测试，然而，那篇文章激励着我去尝试写测试代码。。 所以，我今天早上尝试了一下。经过几个小时编写测试代码，我意外的找到了自动化截图的解决方案。\n\n在这片文章中，我将会谈论关于如何通过ui 测试来完成自动截图和提交这些截图到应用商店。\n\n##UI Automator查看器\n\n‘uiautomatorviewer’是一个非常强大的工具来查看views，当发现极好的布局时，我通常会使用‘uiautomatorviewer’来查看，如果你运行这个工具将会获得下图所示。\n\n![](https://d262ilb51hltx0.cloudfront.net/max/2000/1*2GVDSxydFfqY4WvXBBVQ1Q.png)\n\n通过这个工具你可以看到UI对象，在这里，我可以检测TextView的id，这个技巧在稍后会变得非常有用。。\n\n![](https://d262ilb51hltx0.cloudfront.net/max/2000/1*9yNBO3PwetoOv7EWEChsag.png)\n\n##UI Automator\n\nGoogle在[Android Testing Support Library](https://developer.android.com/tools/testing-support-library/index.html)里面同时也提供了一个叫做‘UI Automator’ 的库，它允许开发者自动化获取用户交互过程。\n\n使用UI Automator时，你需要在你的项目中添加依赖，具体配置信息需要填写在`build.gradle`里面。\n\n正如[文档](https://developer.android.com/training/testing/ui-testing/uiautomator-testing.html#run)中所说。你需要指定[AndroidJUnitRunner](https://developer.android.com/reference/android/support/test/runner/AndroidJUnitRunner.html)作为你默认的测试工具。\n\nUI Automator 里面频繁使用的类有：UiDevice, UiSelector, UiObject, and UiScrollable.\n\n我们将会在androidTestScreenshot文件夹下创建一个简单的测试类，并且这个类继承InstrumentationTestCase。\n\n这个过程很直接：\n\n首先，监听设备点击“Home”键时，执行UiDevice 的方法pressHome()。在每一个测试里面，我们做这样重复性的工作：\n\n从最开始的地方打开app。我个人发现一个简答的方法去获取截屏。你可以使用UiDevice的pressBack()方法为其他测试。\n\n获取想要的UI交互可以使用UiSelector, UiScrollable, and UiObject。\n\n使用SystemClock.sleep方法，为异步任务的执行腾出一些时间（异步任务的执行可能在截屏之后），以此来避免发生截屏获取的为空异常和UiObject not found异常。\n\n最后我们截屏并且将获取的截屏保存在指定的位置。\n\n到目前为止，你可能已经了解了如何使用uiautomatorviewer来帮助我们获取许多我们想要的UI元素，然而，我使用UiSelector().resourceId，因为我们可以通过我们在layout里面使用的id来完成截屏，这样不是更加简单了吗？你也可以有其他选择，比如使用 className, text, etc… 来完成这一过程。\n\n##Product Flavor\n\n我不知道为什么UiAutomator下的minSdkVersion是18，因为我需要minSdk至少是14，我需要使用这个额外的方法。如果这里有任何其他方法可以避免我自己去实现截屏的，请让我知道。\n\nAndroid使用androidTest来实现主要的测试工作，也为了实现不同产品的写测试需要，我们需要写我们的测试在androidTestFlavorName文件夹。这就是为什么我们在androidTestScreenshot路径下创建SimpleUiTest 类的原因。\n\n万事具备，现在，运行`gradle connectedAndroidTestScreenshotDebug`。在这个测试完成后你将会获得屏幕截图。\n\n" }, { "path": "issue-12/Android进行单元测试难在哪-part4.md", "content": "Android 进行单元测试难在哪-part4\n---\n\n> * 原文链接 : [HOW TO MAKE OUR ANDROID APPS UNIT TESTABLE (PT. 2)](http://philosophicalhacker.com/2015/05/08/how-to-make-our-android-apps-unit-testable-pt-2/)\n* 原文作者 : [Matthew Dupree](http://philosophicalhacker.com/)\n* [译文出自 : 开发技术前线 www.devtf.cn](http://www.devtf.cn)\n* 译者 : [chaossss](https://github.com/chaossss) \n* 校对者: [Mr.Simple](https://github.com/bboyfeiyu) \n* 状态 : 完成\n\n\n在**[上一篇博文](https://github.com/bboyfeiyu/android-tech-frontier/blob/master/issue-11/Android%E8%BF%9B%E8%A1%8C%E5%8D%95%E5%85%83%E6%B5%8B%E8%AF%95%E9%9A%BE%E5%9C%A8%E5%93%AA-part3.md)**中，我给大家介绍了新的应用架构方式 - Square 大法，就像我之前说的，Square 大法是 Square 用于使 Fragment 内的业务逻辑能够进行单元测试的通用方法，我还给大家展示了如何使用 Square 大法重构 Google 的 IOSched 应用的 SessionCalendarService 类，使得对 SessionCalendarService 类内的业务逻辑进行单元测试由几乎不可能变为可行。而在今天的这篇博文中，我会和大家一起继续探索 Square 大法，让我们对应用的 UI 组件进行单元测试成为可能，也让测试变得容易。\n\n## 这篇博文有“依赖”\n\n将 Sqaure 大法应用到 App 的 UI 组件中（例如 Activity 和 Fragment） 比起将它应用到无 UI 的应用中要复杂一些，造成这种情况的根源正好与我们重构代码的核心方法相关联，解决了这些额外的复杂性问题，我们也就能够改变对 UI 组件进行单元测试时需要使用的预测试状态，以及修改测试后状态。如果你听到“预测试状态”和“测试后状态”后感觉一头雾水，或者觉得有一点点印象却不记得具体是什么意思的话，最好复习复习我之前写的`[Android 进行单元测试难在哪-part1](https://github.com/bboyfeiyu/android-tech-frontier/blob/master/issue-9/Android%20%E8%BF%9B%E8%A1%8C%E5%8D%95%E5%85%83%E6%B5%8B%E8%AF%95%E9%9A%BE%E5%9C%A8%E5%93%AA-part1.md)`。如果你清楚地理解这两个概念的话，确保你知道 SessionDetailActivity 干了啥。为了学习该如何将 Square 大法应用到应用的 UI 组件类中，我们将重构 SessionDetailActivity 类的代码，使我们能够对类中的 onStop() 方法中的业务逻辑进行单元测试。\n\n开始之前我在唠叨几句吧，如果你有了解过 MVP 模式的话对你理解用 Square 大法重构应用 UI 组件大有裨益，不过呢，由于 Square 已经写了一篇非常精彩的[博文](https://corner.squareup.com/2014/10/advocating-against-android-fragments.html)介绍 MVP 模式了，我就不再给大家介绍啦，有兴趣的话看 Square 写的博文就好了。如果你在学习 MVP 模式的时候觉得很难理解与 View 相关的操作，不妨看看我之前写的一篇[博文](http://philosophicalhacker.com/2015/04/05/dont-call-it-mvp/)，这篇博文能帮你区分进行 Android 开发时我们使用的 View 和 MVP 模式中的“View”。除此以外，我在这篇博文中将 Presenter 用于更新应用界面显示的对象称为 “ViewTranslator” 而不是 “View”。\n\n## 用 Square 大法重构应用 UI 组件类\n\n虽然用 Square 大法重构应用的 UI 组件可能会更复杂些，但我们的重构策略始终没有发生变化：抽取出应用组件类中的业务逻辑（例如 Activity，Fragment，Service），并将业务逻辑放到我之前说的被进行了依赖注入的“业务对象”中，也就是与 Android 无关接口的 Android 特定实现。\n\n下面是重构后的 onStop() 方法：\n\n```java\n@Override\npublic void onStop() {\n super.onStop();\n if (mInitStarred != mStarred) {\n if (UIUtils.getCurrentTime(this) < mSessionStart) {\n // Update Calendar event through the Calendar API on Android 4.0 or new versions.\n Intent intent = null;\n if (mStarred) {\n // Set up intent to add session to Calendar, if it doesn't exist already.\n intent = new Intent(SessionCalendarService.ACTION_ADD_SESSION_CALENDAR,\n mSessionUri);\n intent.putExtra(SessionCalendarService.EXTRA_SESSION_START,\n mSessionStart);\n intent.putExtra(SessionCalendarService.EXTRA_SESSION_END,\n mSessionEnd);\n intent.putExtra(SessionCalendarService.EXTRA_SESSION_ROOM, mRoomName);\n intent.putExtra(SessionCalendarService.EXTRA_SESSION_TITLE, mTitleString);\n } else {\n // Set up intent to remove session from Calendar, if exists.\n intent = new Intent(SessionCalendarService.ACTION_REMOVE_SESSION_CALENDAR,\n mSessionUri);\n intent.putExtra(SessionCalendarService.EXTRA_SESSION_START,\n mSessionStart);\n intent.putExtra(SessionCalendarService.EXTRA_SESSION_END,\n mSessionEnd);\n intent.putExtra(SessionCalendarService.EXTRA_SESSION_TITLE, mTitleString);\n }\n intent.setClass(this, SessionCalendarService.class);\n startService(intent);\n \n if (mStarred) {\n setupNotification();\n }\n }\n }\n}\n```\n\n正如我之前提到的，这段代码存在一个问题：代码并没有通过被注入到 SessionDetailActivity 的依赖中的方法启动 SessionCalendarService。那我们现在就用 Square 大法来解决这个问题。首先，我们将业务逻辑抽取出来，并放入业务对象中，Square 的工程师们为这个在 Activity（或 Fragment，或其他……）中使用的业务对象起了一个名字 —— “Presenter”。\n\nPresenter 负责用 Model 中的数据更新 View，为了使单元测试在 Presenter 中是可行的，这就意味着 Model 和 View 都必须是注入到 Presenter 中的依赖。也正是这三个对象的组合使用构成了我们所说的 MVP 架构模式。\n\n下面就是 SessionDetailPresenter 中与 onStop() 方法等价的实现啦：\n\n```java\npublic class SessionDetailViewPresenter implements RepositoryManagerCallbacks {\n \n public SessionDetailViewPresenter(SessionDetailView sessionDetailView,\n RepositoryManager loaderManager,\n ServiceStarter serviceStarter,\n long calendarId\n ) {\n \n mSessionDetailView = sessionDetailView;\n mLoaderManager = loaderManager;\n mServiceStarter = serviceStarter;\n mCalendarId = calendarId;\n }\n \n //...\n \n public void onViewTranslatorStopped() {\n \n if (mInitStarred != mStarred) {\n \n if (System.currentTimeMillis() < mSessionStart) {\n \n CalendarSession calendarSession = new CalendarSession(mSessionUri, mSessionStart, mSessionEnd, mTitleString, mRoomName);\n \n if (mStarred) {\n \n mServiceStarter.startAddCalendarSessionService(mCalendarId, calendarSession);\n \n } else {\n \n mServiceStarter.startRemoveCalendarSessionService(mCalendarId, calendarSession);\n }\n }\n \n if (mStarred) {\n \n setupSessionNotification();\n }\n }\n }\n \n //...\n}\n```\n\n完成这个类的关键在于：SessionDetailPresenter 的依赖通过它的构造器传递，因为这些依赖都被注入了，所以我们现在可以修改 SessionDetailPresenter 类中 onViewTranslatorStopped() 方法的测试单元的测试后状态。\n\n```java\npackage com.google.samples.apps.iosched.test;\n \nimport com.google.samples.apps.iosched.service.CalendarSession;\nimport com.google.samples.apps.iosched.ui.RepositoryManager;\nimport com.google.samples.apps.iosched.ui.ServiceStarter;\nimport com.google.samples.apps.iosched.ui.sessiondetail.SessionDetailViewPresenter;\nimport com.google.samples.apps.iosched.ui.sessiondetail.SessionDetailViewTranslator;\n \nimport junit.framework.TestCase;\n \nimport static org.mockito.Matchers.any;\nimport static org.mockito.Matchers.anyLong;\nimport static org.mockito.Mockito.mock;\nimport static org.mockito.Mockito.verify;\n \n/**\n * Created by MattDupree on 5/8/15.\n */\npublic class SessionDetailPresnterTests extends TestCase {\n \n \n public void testShouldLaunchAddSessionService() {\n \n //Arrange\n SessionDetailViewTranslator sessionDetailViewTranslator = mock(SessionDetailViewTranslator.class);\n \n RepositoryManager repositoryManager = mock(RepositoryManager.class);\n \n ServiceStarter serviceStarter = mock(ServiceStarter.class);\n \n long calendarId = 0;\n \n SessionDetailViewPresenter sessionDetailViewPresenter = new SessionDetailViewPresenter(sessionDetailViewTranslator,\n repositoryManager,\n serviceStarter,\n calendarId);\n sessionDetailViewPresenter.onViewCreated(null);\n \n //Act\n sessionDetailViewPresenter.onViewStopped();\n \n //Assert\n verify(serviceStarter).startAddCalendarSessionService(anyLong(), any(CalendarSession.class));\n \n }\n \n}\n```\n\n虽然我们现在可以修改测试单元的测试后状态了，但这还不够，因为这个测试单元无法完成测试。为什么呢？我们不妨一起看看 onViewTranslatorStopped() 方法：\n\n```java\npublic void onViewTranslatorStopped() {\n \n if (mInitStarred != mStarred) {\n \n if (System.currentTimeMillis() < mSessionStart) {\n \n CalendarSession calendarSession = new CalendarSession(mSessionUri, mSessionStart, mSessionEnd, mTitleString, mRoomName);\n \n if (mStarred) {\n \n mServiceStarter.startAddCalendarSessionService(mCalendarId, calendarSession);\n \n } else {\n \n mServiceStarter.startRemoveCalendarSessionService(mCalendarId, calendarSession);\n }\n }\n \n if (mStarred) {\n \n setupSessionNotification();\n }\n }\n}\n```\n\nonViewTranslatorStopped() 方法的代码被包裹在一个判断模块中，只有在“starred button”的状态与其初始化状态相异时才会执行判断模块中的代码。mInitStarred 将会在 Loader 回调中被初始化，IOSched 应用检索数据库以判断用户选中的 I/O 大会是否已经被添加到日历中，并在用户返回到 SessionDetailActivity 后通过消息更新 UI。但在上面这段业务逻辑的测试单元中，mInitStarred 和 mStarred 都将有一个初始值 `false`，使得判断模块内的代码永远不会被执行。\n\n即使我们能执行判断模块内的代码，我们还是不能获得进行单元测试所需要的一切，因为启动 SessionCalendarService 的代码在另一个用于确保在 System.currentTimeMillis() 的返回值小于 mSessionStart 时才执行相关代码的判断模块中。既然我们不能修改 mSessionStart 的值，也就不能保证启动 SessionCalendarService 的代码会被运行。\n\n这些问题都是我思考如何在 Android 中进行单元测试时想到的普遍问题的极端例子：我们常常缺乏对测试单元预测试状态的控制力。然而，由于我们将 SessionRepositoryManager 注入到 SessionDetailPresenter 中，我们现在可以判断 mSessionStart 和 mInitStarred 的值了，因为 SessionRepositoryManager 是一个 Android 无关的接口¹:\n\n```java\npackage com.google.samples.apps.iosched.ui;\n \nimport android.os.Bundle;\n \nimport com.google.samples.apps.iosched.io.model.Session;\n \n/**\n * \n * Created by MattDupree on 5/6/15.\n */\npublic interface SessionRepositoryManager {\n \n void initRepository(int id, Bundle bundle, SessionRepositoryManagerCallbacks repositoryManagerCallbacks);\n \n \n interface SessionRepositoryManagerCallbacks {\n \n void onLoadFinished(Session session);\n }\n}\n```\n\n然而，当我们创建 SessionDetailPresenter，我们注入了包含 LoaderManager 的 Android 无关接口 `SessionRepositoryManager` 的实现。\n\n```java\npublic class SessionDetailActivity extends Activity implements SessionDetailViewTranslator {\n \n @Override\n public void onCreate(Bundle savedInstanceState)\n \n //...\n \n ServiceStarter serviceStarter = new AndroidServiceStarter(this);\n \n SessionRepositoryManager repositoryManager = new AndroidSessionRepositoryManager(getLoaderManager());\n \n mSessionDetailViewPresenter = new SessionDetailViewPresenter(this, repositoryManager, \n serviceStarter, calendarId);\n mSessionDetailViewPresenter.onViewCreated(savedInstanceState);\n \n //...\n }\n \n}\n```\n\n因为 SessionRepositoryManager 只是一个接口，所以我们能轻松地定义 MockRepositoryManager 帮助我们完成单元测试：\n\n```java\npackage com.google.samples.apps.iosched.ui.sessiondetail;\n \nimport android.os.Bundle;\n \nimport com.google.samples.apps.iosched.io.model.Session;\n \n/**\n * Created by MattDupree on 5/8/15.\n */\npublic class MockSessionRepositoryManager implements SessionRepositoryManager{\n \n \n private Session mSession;\n \n public MockSessionRepositoryManager(Session session) {\n \n mSession = session;\n }\n \n \n @Override\n public void initRepository(int id, Bundle bundle,\n SessionRepositoryManagerCallbacks repositoryManagerCallbacks) {\n \n repositoryManagerCallbacks.onLoadFinished(mSession);\n }\n}\n```\n\n不知道大家有没有注意到：当有操作通过向构造器传递一个 Session 对象调用 initRepository() 方法时，我们能够指定 MockSessionRepositoryManager 的返回值。SessionDetailPresenter 中类似 mSessionStart 这样的值能在 Session 的模板对象中通过 startTimeStamp 实例初始化。这样一来，我们就能掌控这些值了，也就是说，我们现在几乎拥有了在对 onViewTranslatorStopped() 方法进行单元测试时，准备阶段所需要的一切。\n\n```java\npublic void testShouldLaunchAddSessionService() {\n \n //Arrange\n SessionDetailViewTranslator sessionDetailViewTranslator = mock(SessionDetailViewTranslator.class);\n \n Session session = new Session();\n session.startTimestamp = \"1431081943\";\n \n SessionRepositoryManager repositoryManager = new MockSessionRepositoryManager(session);\n \n ServiceStarter serviceStarter = mock(ServiceStarter.class);\n \n long calendarId = 0;\n \n SessionDetailViewPresenter sessionDetailViewPresenter = new SessionDetailViewPresenter(sessionDetailViewTranslator,\n repositoryManager,\n serviceStarter,\n calendarId);\n sessionDetailViewPresenter.onViewCreated(null);\n \n //Act\n sessionDetailViewPresenter.onViewStopped();\n \n //Assert\n verify(serviceStarter).startAddCalendarSessionService(anyLong(), any(CalendarSession.class));\n \n}\n```\n\n我之所以说“几乎”，是因为 onViewTranslatorStopped() 方法中还有一个地方不能通过上面的代码处理。在 onViewTranslatorStopped() 方法的最下面有一个只有在 mStarred 的值为 true 时才会运行的代码块。这段代码会启动一个 Service 提醒用户参与并且/或者排列他们添加到日历中的 IO 大会：\n\n```java\npublic class SessionDetailViewPresenter implements RepositoryManagerCallbacks {\n \n public SessionDetailViewPresenter(SessionDetailView sessionDetailView,\n RepositoryManager loaderManager,\n ServiceStarter serviceStarter,\n long calendarId\n ) {\n \n mSessionDetailView = sessionDetailView;\n mLoaderManager = loaderManager;\n mServiceStarter = serviceStarter;\n mCalendarId = calendarId;\n }\n \n //...\n \n public void onViewTranslatorStopped() {\n \n if (mInitStarred != mStarred) {\n \n if (System.currentTimeMillis() < mSessionStart) {\n \n CalendarSession calendarSession = new CalendarSession(mSessionUri, mSessionStart, mSessionEnd, mTitleString, mRoomName);\n \n if (mStarred) {\n \n mServiceStarter.startAddCalendarSessionService(mCalendarId, calendarSession);\n \n } else {\n \n mServiceStarter.startRemoveCalendarSessionService(mCalendarId, calendarSession);\n }\n }\n \n if (mStarred) {\n \n setupSessionNotification();\n }\n }\n }\n \n //...\n}\n```\n\n为了让这段代码运行，我们需要确保 mStarred 的值为 true。我们能通过调用 SessionDetailPresenter 的 onSessionStarred() 方法完成这项工作，因为 onSessionStarred() 方法就是在用户点击 star button 时 SessionDetailViewTranslator（如果你觉得这些命名让你觉得晕乎乎的，你可以把它当作 SessionDetailView）调用的方法。\n\n```java\npublic void onToggleSessionStarred() {\n \n mStarred = !mStarred;\n}\n```\n\n```java\npublic void testShouldLaunchAddSessionService() {\n \n //Arrange\n SessionDetailViewTranslator sessionDetailViewTranslator = mock(SessionDetailViewTranslator.class);\n \n Session session = new Session();\n session.startTimestamp = \"1431081943\";\n \n SessionRepositoryManager repositoryManager = new MockSessionRepositoryManager(session);\n \n ServiceStarter serviceStarter = mock(ServiceStarter.class);\n \n long calendarId = 0;\n \n SessionDetailViewPresenter sessionDetailViewPresenter = new SessionDetailViewPresenter(sessionDetailViewTranslator,\n repositoryManager,\n serviceStarter,\n calendarId);\n sessionDetailViewPresenter.onViewCreated(null);\n //****** We call onToggleSessionStarred() to make sure that mStarrred is true\n sessionDetailViewPresenter.onToggleSessionStarred();\n //******\n \n //Act\n sessionDetailViewPresenter.onViewStopped();\n \n //Assert\n verify(serviceStarter).startAddCalendarSessionService(anyLong(), any(CalendarSession.class));\n \n}\n```\n\n把上面提到的所有工作万仇后，我们终于能够在 onViewTranslatorStopped() 方法中进行单元测试了。\n\n##结论\n\n你可能觉得我们为单元测试的准备阶段进行了大量的工作，我不得不承认你的感觉是对的。最后，我提一点个人想法：我认为 SessionDetailActivity 类中的代码实在是太多了，都有1000多行……正是这个原因，使得为其实现测试单元变得如此艰难。此外，因为这篇博文的目的只是展示 Square 大法的核心用法，所以我并不打算讨论优化单元测试的方案。²\n\nSquare 大法是告别传统 Android 开发架构的里程碑，因为我们确实发现了遵循传统架构进行开发的种种缺陷。为此，我将在下一篇博文中指出 Square 大法潜在的问题，并提出可能的解决办法。此外，本系列的最后一篇博文也会告诉大家 Square 大法的种种优点，而且我所说的优点可不是只有增强应用的可测试性哦。\n\n##注：\n\n1. 严格来说这个接口并不是 Android 无关的，因为它的核心方法使用 Bundle 作为参数，但我不确定这会不会带来什么问题，毕竟 Bundle 非常普通，并不会是什么我们想要测试的东西。退一万步说，即使要对它进行测试也没啥麻烦。\n\n2. 在 Droidcon Montreal 中，Richa Khandelwal 在 Coursa 上开了一节课建议我们使用[更简洁、更易于测试的架构进行开发](https://speakerdeck.com/richk/clean-android-architecture)，这或许也能让实现单元测试变得简单些。" }, { "path": "issue-12/MVP框架Mosby架构详解.md", "content": "# Ted Mosby - 软件架构\n\n* 作者：Hannes Dorfmann\n* 原文链接 : [http://hannesdorfmann.com/android/mosby/]\n(http://hannesdorfmann.com/android/mosby/)\n* 文章出自 : [Android开发技术前线](https://github.com/bboyfeiyu/android-tech-frontier)\n* 译者 : [Mr.Simple](https://github.com/bboyfeiyu)\n\n我给这篇关于Android库的博客起的名字灵感来源于《老爸老妈浪漫史》中的建筑设计师Ted Mosby。这个Mosby库可以帮助大家在Android上通过Model-View-Presenter模式做出一个完善稳健、可重复使用的软件，还可以借助ViewState轻松实现屏幕翻转。\n\n## Model-View-Presenter (MVP)\n\n**MVP**模式是一个把view从低层模型分离出来的一种现代模式。**MVP**由model–view–controller (MVC)软件模式衍生而来，常用于构建UI\n\n* **MVP**中的**M**（model）代表的是将会显示在view（UI）中的数据。\n* **MVP**中的**V**（view）是显示数据（model）并且将用户指令（events）传送到presenter以便作用于那些数据的一个接口。View通常含有Presenter的引用。\n* **MVP**中的**P**（presenter）扮演的是“中间人”的作用（就如MVC中的controller），且presenter同时引用view和model。值得注意的是，“Model”这个词并不正确。严格意义上来说，它指的应该是检索或控制一个Model的业务逻辑层。举个例子，比如你的数据库里面包含了User，而你的View想要显示一个User列表，那么Presenter会引用数据库中的业务逻辑层（比如DAO）从而查询到一个User列表。如图1-1.\n ![](http://hannesdorfmann.com/images/mosby/mvp-overview.png)\n\n从数据库中查询或显示User列表的具体流程如图1-2：\n![](http://hannesdorfmann.com/images/mosby/mvp-workflow.png)\n\n以上工作流程图应该能够说明问题了。但是，还有以下几点值得注意的地方：\n\n* **Presenter**不是一个**OnClickListener**。**View**主要是负责处理用户输入并调用presenter相应的方法。那么问题来了，为什么不把**Presenter** 直接做成一个**OnClickListener**，从而把“转发流程”给省略掉呢？大家想想，如果这样做的话，首先，**presenter**需要知道view的内部构件。举个例子，如果一个View有两个按钮，且这个view在这两个按钮上都把**Presenter** 注册成**OnClickListener**的话，那么发生点击事件时Presenter （在不知道view中按钮引用等内部构件的情况下）怎么能够区分出是哪一个按钮被点击了呢？Model，View和Presenter三者应解耦。其次，如果让Presenter 执行OnClickListener，Presenter就被绑定到了Android平台上。理论上来说**presenter**和业务逻辑层都是纯旧式的能够与桌面应用或其他任何java应用共享的java代码。\n\n* 大家在第1步和第2步中可以看到，**View** 只执行**Presenter** 指示的操作：用户点击“load user button”（第1步）后，view并没有直接显示加载动画，而是在第2步presenter明确告诉其显示加载动画后才显示的。这一Model-View-Presenter的变体称之为MVP 被动视图。这个view可以说是要多笨有多笨。这时我们需要让presenter以一种更抽象的方式来控制view。比如，presenter在调用 **view.showLoading()** 时并不控制view的诸如动画等具体事项。所以presenter不应调用**view.startAnimation()** 等方法。\n\n* 通过执行**MVP**被动视图，并发性以及多线程更容易处理。大家可以看到，第3步中数据库查询异步运行，并且**presenter作为Listener/Observer**，在数据准备显示时presenter收到通知。\n\n##**Android**上的**MVP**\n\n目前为止一切顺利。但是大家怎么样把MVP运用到自己的Android 应用上呢？第一个问题在于，我们要把MVP模式运用到什么地方？Activity上、Fragment上、还是像RelativeLayout这类的ViewGroup上？我们来看看Android平板上的Gmail应用，如图1-3：\n\n![](http://hannesdorfmann.com/images/mosby/mvp-gmail.png)\n\n在我看来，上图屏幕中有四个可以使用MVP的地方。我所说的“可以使用MVP的地方”是指屏幕上显示的、在逻辑上属于一个整体的UI元素。因此这些地方也可以称为是可以运用MVP的一个单独的UI单元。如图 1-4.\n\n![](http://hannesdorfmann.com/images/mosby/mvp-gmail-candidates.png)\n\n看起来MVP似乎很适合运用到Activity，特别是Fragment上。通常Fragment只负责显示单一的如ListView之类的内容，就像依靠**MailProvider** 来获取一系列**Mails**的**InboxPresenter** 控制下的 **InboxView**一样。但是，**MVP**不仅仅限于Fragment或Activity，它还可以运用到SearchView中显示的ViewGroup中。在我的大多数app里面我都在Fragment运用MVP模式。但是大家可以自行决定把MVP运用到什么地方，前提是view是独立的，这样这样presenter才能在不与其他Presenter冲突的情况下控制View。\n\n##我们为什么要实现**MVP**？\n\n我们如何在不使用MVP模式时显示Email列表到Fragment? 通常，我们需要获取并且合并本地SQL数据库和从IMAP邮件服务器获取的邮件列表，然后将邮件列表绑定到收件箱view中。那么，此时fragment的代码又会是怎么样的呢？我们需要运行两个**AsyncTasks** 并实现一个“等待机制”（等到两个任务将两者的加载数据合并到一个单独的mail列表）。我们还需要注意的是在加载时要显示加载动画（ProgressBar），之后用ListView替代。我们需要把所有的代码放到Fragment中吗？要是加载过程中出现错误怎么办？屏幕翻转怎么办？谁来负责撤销**AsyncTasks** ？这一系列的问题都可以通过MVP得到解决。让我们跟那些带有上千行大杂烩代码的activity和fragment说拜拜吧\n\n但是，在我们深入研究如何将MVP运用到Android中之前，我们需要弄清楚的一个问题是：Activity或Fragment究竟是一个View还是一个Presenter。Activity或Fragment似乎既是**View**也是**Presenter**，因为它们都有 **onCreate()** 或**onDestroy()**之类的生命周期回调功能，并且它们负责从一个UI控件到另一个UI 控件的转换（比如在加载时显示ProgressBar，然后显示带有数据的ListView）等View操作。大家可能会觉得这里的Activity或Fragment就是一个Controller，我猜可能也是这么一个初衷。但是在经历了几年的Android应用开发之后，我得出这么一个结论：我们应该把Activity或Fragment看作是一个不太智能的View，而不是把它们看作一个Presenter。后文我会给出原因。\n\n综上，我想给大家介绍一个在Android平台上开发基于MVP的应用的一个 **Mosby**库。\n**Mosby**\n\n大家可以在[Github](https://github.com/sockeqwe/mosby)和Maven Central上找到Mosby库。Mosby分为几个子模块，大家可以根据自己的需要选取组件。我们来回顾一下最重要的一个模块。\n\n##核心模块 ( Core Module)\n\n《老爸老妈浪漫史》中的建筑设计师Ted Mosby想建造一栋摩天大楼。而建造这样一栋宏伟的建筑必须打好坚实的地基。这对Android应用的开发来说是也是一样的道理。基本上，**Core Module** 分为两种类型：**MosbyActivity** 和**MosbyFragment**。这两者是所有其他activity或fragment子类的基类（相当于建筑的地基）。两者都使用我们大家所熟知的APT **（Annotation Processing Tool）**来减少一些样板式代码。**MosbyActivity** 和**MosbyFragment** 使用Butterknife进行view的注入，使用Icepick 将实例状态保存和存储到Bundle中，使用FragmentArgs注入Fragment参数。我们不需要再调用Butterknife.inject(this)等插入方法。这类代码已经包含在了MosbyActivity 和 MosbyFragment中。它是即时可用的。我们需要做的就是使用子类中相应的注解。核心模块与MVP没有关联，它只是写一个大型软件的基础。\n\n##MVP模块( MVP Module )\n\nMosby库中的MVP模块使用泛型来确保类型安全。所有view的基类是**MvpView**。从根本上说这只是一个空的interface 。Presenter的基类是**MvpPresenter**：\n\n```\npublic interface MvpView{}\n\npublic interface MvpPresenter{\n\tpublic void attachView(V view);\n\tpublic void detachView(boolean retainInstance);\n}\n```\n上文提到，我们把**Activity**和**Fragment**看做View。因此Mosby库的MVP模块提供了 属于**MvpViews** 的**MvpActivity**和**MvpFragment**作为**Activity**和**Fragment**的基类。\n\n```\npublic abstract class MvpActivity

extends MosbyActivity implements MvpView{\n\n\tprotected P presenter;\n\t@Override protected void onCreate(Bundle savedInstanceState){\n\t\tsuper.onCreate(savedInstanceState);\n\t\tpresenter = createPresenter();\n\t\tpresenter.attachView(this);\n\t\tsuper.onDestroy();\n\t\tpresenter.detachView(false);\n\t}\n\n\tprotected abstract PcreatePresenter();\n}\n\npublic abstract class MvpFragment

MosbyFragment implements MvpView{\n\tprotected Ppresenter;\n\n\t@Override public void onViewCreated(View view,@Nullable Bundle savedInstanceState){\n\t\tsuper.onViewCreated(view,savedInstanceState);\n\t\t// Create the presenter if needed\n\t\tif(presenter == null){\n\t\t\tpresenter = createPresenter();\n\t\t}\n\t\tpresenter.attachView(this);\n\t}\n\n\t@Override public void onDestroyView(){\n\t\tsuper.onDestroyView();\n\t\tpresenter.detachView(getRetainInstance());\n\t}\n\t\n\tprotected abstract PcreatePresenter();\n\t}\n}\n\n@Override protected void onDestroy(){\n\n```\n\n这一理念主要是一个**MvpView** (也就是Fragment or Activity)会关联一个MvpPresenter，并且管理**MbpPresenter**的声明周期。大家从上面的代码片段可以看到，Mosby使用Activity和Fragement生命周期来实现这一目的。通常presenter是绑定在该生命周期上的。所以初始化或者清理一些东西等操作（例如撤销异步运行任务）应该在 **presenter.onAttach()**和 presenter.onDetach()上进行。我们稍后会谈到presenter如何使用setRetainInstanceState(true) “避开”Fragment中的生命周期。我相信大家也注意到了， MvpPresenter是一个interface 。MVP模块提供一个 **MvpBasePresenter**，这个**MvpBasePresenter**只持有View（是一个Fragment或Activity）的弱引用，从而避免内存泄露。因此，当**presenter**想要调用view方法时，我们需要查看**isViewAttached()** 并使用**getView()**来获取引用，以检查view是否连接到了presenter。\n\n##Loading-Content-Error (LCE)\n\n通常Fragment会一直重复做某一件事。它在后台加载数据，同时显示加载view（即ProgressBar），并在屏幕上显示加载的数据，或者当加载失败时显示view错误。如今，下拉刷新支持很容易实现，因为SwipeRefreshLayout是Android支持库的组成部分。为了避免重复执行这一工作流，Mosby库的**MVP**模块提供了**MvpLceView**。\n\n```\npublic interface MvpLceView extends MvpView{\n\t/**\n\t * 显示一个加载中的视图\n\t * loading view 必须有个id 为 R.id.loadingView的View\n\t * @param pullToRefresh 如果是true,那么表示下拉刷新被触发了\n\t */\n\tpublic void showLoading(boolean pullToRefresh);\n\t/**\n\t * 显示 content view.\n\t * >{\n}\n```\n\n为什么要为View定义接口呢？\n1.因为定义了这个接口之后我们可以更改view的实现。我们可以简单地把代码从一个继承自 Activity的实现转移到继承自 Fragment的实现。\n\n2.模块性：我们可以移动独立的库项目中的整个业务逻辑层、Presenter以及View 接口，然后把这个包含了Presenter的库应用到各类app当中。下图中左侧是使用了嵌入在ViewPager中的Activity的**kicker app**，以及使用嵌入在ViewPager中的Fragment的**meinVerein app**，如图1-5。 两者采用的是同一个定义了View接口和Presenter且测试了单元的库。\n\n![](http://hannesdorfmann.com/images/mosby/mvp-reuse.png)\n\n由于我们可以通过执行view接口来模拟view，所以我们可以很容易地编写单元测试。还有一个更简单的方法就是在presenter中引入java接口并使用模拟presenter对象来编写单元测试。\n还有一个良性副作用就是，定义了view接口之后，我们不用直接从presenter再回调activity/fragment方法。我们这样区分开来是因为在执行presenter时我们在IDE自动完成上看到的方法只是关于view接口的方法。就我个人体会来说，我觉得这个方法非常有用，特别是团队一起工作的时候。需要注意的是，除了定义一个CountriesView接口之外，我们还可以采用**MvpLceView>** 。但是，定义一个专门的接口可以提高代码可读性，并且将来可以灵活地定义更多其他的与View相关的方法。\n\nNext we define our views xml layout file with the required ids:\n\n下一步我们需要按照指定的id来定义view xml 布局文件.\n\n```xml\n\n\n\t\n\t\n\n\t\n\t\n\n\t\n\n\t\n\n\n\t\n\t\n\n\n```\n\nCountriesPresenter控制CountriesView并运行CountriesAsyncLoader。\n\n```java\npublic class CountriesPresenter extends MvpBasePresenter{\n\n\t@Override \n\tpublic void loadCountries(final boolean pullToRefresh){\n\t\tgetView().showLoading(pullToRefresh);\n\t\t\n\t\tCountriesAsyncLoader countriesLoader = new CountriesAsyncLoader(\n\t\tnew CountriesAsyncLoader.CountriesLoaderListener(){\n\n\t\t@Override public void onSuccess(List countries){\n\n\t\t\tif(isViewAttached()){\n\t\t\t\tgetView().setData(countries);\n\t\t\t\tgetView().showContent();\n\t\t\t}\n\t\t}\n\n\t\t@Override public void onError(Exception e){\n\n\t\t\tif(isViewAttached()){\n\t\t\t\tgetView().showError(e,pullToRefresh);\n\t\t\t}\n\t\t}\n\t});\n\n\t\tcountriesLoader.execute();\n\t}\n}\n```\n\n实现**CountriesView**接口 的**CountriesFragment** 如下所示：\n\n```java\npublic class CountriesFragment\n extends MvpLceFragment,CountriesView,CountriesPresenter>\n implements CountriesView,SwipeRefreshLayout.OnRefreshListener{\n\n\t@InjectView(R.id.recyclerView)RecyclerViewrecyclerView;\n\tCountriesAdapteradapter;\n\n\t@Override public void onViewCreated(View view,@Nullable Bundle savedInstance){\n\tsuper.onViewCreated(view,savedInstance);\n\n\t\t// Setup contentView == SwipeRefreshView\n\t\tcontentView.setOnRefreshListener(this);\n\n\t// Setup recycler view\n\t\tadapter = new CountriesAdapter(getActivity());\n\t\trecyclerView.setLayoutManager(new LinearLayoutManager(getActivity()));\n\t\trecyclerView.setAdapter(adapter);\n\t\tloadData(false);\n\t}\n\n\tpublic void loadData(boolean pullToRefresh){\n\t\tpresenter.loadCountries(pullToRefresh);\n\t}\n\n\t@Override protected CountriesPresenter createPresenter(){\n\t\treturn new SimpleCountriesPresenter();\n\t}\n\n\t// Just a shorthand that will be called in onCreateView()\n\t@Override protected int getLayoutRes(){\n\t\treturn R.layout.countries_list;\n\t}\n\n\t@Override public void setData(List data){\n\t\tadapter.setCountries(data);\n\t\tadapter.notifyDataSetChanged();\n\t}\n\n\t@Override public void onRefresh(){\n\t\tloadData(true);\n\t}\n}\n```\n\n代码数量也并不是很多嘛，对吧？这是因为基类已经执行了从加载view到content view或error view的转换。我们可能第一眼看到那一列**MvpLceFragment**类属参数会觉得灰心。但是我要解释一下：第一种类属参数代表的是content view的类型；第二种是指以fragment显示的Model；第三种是View接口;最后一种是Presenter的类型。总结起来就是：**MvpLceFragment**。\n\n大家可能还注意到的一个点就是 **getLayoutRes()**，它是**MosbyFragment**引入的用于解析xml view布局的速记法。\n\n```java\n@Override public View onCreateView(LayoutInflater inflater,ViewGroup container,Bundle savedInstanceState){\n\tReturn inflater.inflate(getLayoutRes(),container,false);\n}\n```\n\n因此，我们不用重写**onCreateView()**，只需重写**getLayoutRes()**。一般来说，onCreateView()只能创建view而**onViewCreated()**需要被重写，以便为RecyclerView初始化Adapter等项。因此，千万不要忘记调用super.OnViewCreated()；\n\n##ViewState模块\n\n看到这里大家应该大概了解了如何运用Mosby库。Mosby中的ViewState模块能帮助我们在Android开发中解决一些棘手的难题：处理屏幕旋转。\n\n问：如果把正在运行country这个例子的app并显示了一列country的设备从横屏旋转到竖屏，会出现什么情况？\n\n\n答：大家到这个视频链接[https://youtu.be/9iSBGEIZmUw](https://youtu.be/9iSBGEIZmUw)中看看，结果是一个新的 CountriesFragment会被实例化，app开始显示ProgressBar（并重新加载country列表）而不再在RecyclerView中显示country列表（屏幕旋转前的状态）\n\nMosby引入了**ViewState**来解决这个问题。原理就是，我们跟踪presenter从关联的View中调用的方法。比如，**presenter**调用的是view.showContent()，一旦showContent()被调用，view就会意识到其状态变更为**“showing content”**，从而view把这一信息存储到一个ViewState。如果view在方向改变过程中遭到破坏，那么ViewState 就会被存储到**Activity.onSaveInstanceState(Bundle) 或 Fragment.onSaveInstanceState(Bundle)中，并在Activity.onCreate(Bundle) 或Fragment.onActivityCreated(Bundle)**中修复。\n\n由于不是每种数据都能存储在Bundle中，所以不同的数据类型采用不同的ViewState 实现：数据类型**ArrayList**采用**ArrayListLceViewState**；数据类型Parcelable 采用**Parcelable DataLceViewState**；数据类型**Serializeable**采用**SerializeableLceViewState**。如果使用的是一个可保持( Retaining )的Fragment，那么 ViewState在屏幕旋转时不会被破坏，所以也就不需要存储到Bundle中。因此，它可以存储任何类型的数据。在这种情况下，我们需要使用**RetainingFragmentLceViewState**。存储一个ViewState比较容易。由于我们的架构比较整洁，我们的View又有接口，ViewState 可以向presenter一样通过调用同样的接口方法来修复相关联的view。举个例子，MvpLceView一般有3种状态，即：显示**showContent()，showLoading()和showError()**，所以ViewState本身会调用相应的方法来修复view的状态。\n\n\n那只是一些内部构件。如果大家想编写自定义的ViewState，了解以上内容就够了。ViewStates的使用非常简单。事实上，要把MvpLceFragment 迁移到MvpLceViewStateFragment ，我们只需要另外执行**createViewState()** 和 **getData()**。下面我们就在CountriesFragment中实践一下吧：\n\n```java\npublic class CountriesFragment\n extends MvpLceViewStateFragment,CountriesView,CountriesPresenter>\n implements CountriesView,SwipeRefreshLayout.OnRefreshListener{\n\n\t@InjectView(R.id.recyclerView)RecyclerView recyclerView;\n\tCountriesAdapter adapter;\n\n\t@Override public LceViewState,CountriesView> createViewState(){\n\t\treturn new RetainingFragmentLceViewState,CountriesView>(this);\n\t}\n\n\t@Override public List getData(){\n\t\treturn adapter == null? null : adapter.getCountries();\n\t}\n\n\t// The code below is the same as before\n\n\t@Override public void onViewCreated(Viewview,@Nullable Bundle savedInstance){\n\tsuper.onViewCreated(view,savedInstance);\n\n\t// Setup contentView == SwipeRefreshView\n\tcontentView.setOnRefreshListener(this);\n\n\t// Setup recycler view\n\t\tadapter = new CountriesAdapter(getActivity());\n\t\trecyclerView.setLayoutManager(new LinearLayoutManager(getActivity()));\n\t\trecyclerView.setAdapter(adapter);\n\t\tloadData(false);\n\t}\n\n\n\tpublic void loadData(boolean pullToRefresh){\n\t\tpresenter.loadCountries(pullToRefresh);\n\t}\n\n\t@Override protected CountriesPresenter createPresenter(){\n\t\treturn new SimpleCountriesPresenter();\n\t}\n\n\t// Just a shorthand that will be called in onCreateView()\n\t@Override protected int getLayoutRes(){\n\t\treturn R.layout.countries_list;\n\t}\n\n\t@Override public void setData(List data){\n\t\tadapter.setCountries(data);\n\t\tadapter.notifyDataSetChanged();\n\t}\n\n\t@Override public void onRefresh(){\n\t\tloadData(true);\n\t}\n}\n```\n\n以上就是全部过程啦。我们不必更改presenter或其他代码。[这里](https://youtu.be/9iSBGEIZmUw ) 是一个关于我们的获得ViewState支持的CountriesFragment的视频。在这个视频中我们可以看到，view在方位转变之后仍然处于同样的“状态”，即，view横屏显示country列表，随后横屏显示country列表。View能横屏显示下拉刷新指示，变更为竖屏时也能显示。\n\n##自定义ViewState\n\nViewState确实是一个强大且灵活的概念。看到这里我相信大家都了解了LCE (Loading-Content-Error) ViewState的易用性。下面我们就一起来编写自己的View和ViewState吧。我们的View只显示两类不同的数据对象：A和B。结果应该像这个视频 [https://youtu.be/9iSBGEIZmUw](https://youtu.be/9iSBGEIZmUw ) 中演示的这样：\n\n大家心里肯定觉得，这也不怎么样啊！别介啊，我只是想演示一下创建自己的ViewState是一件多么容易的事。\n\nView 接口和数据对象（model）如下所示：\n\n```java\npublic class A implements Parcelable {\n\tString name;\n\n\tpublic A(String name){\n\t\tthis.name=name;\n\t}\n\n\tpublic String getName(){\n\t\treturn name;\n\t}\n}\n\npublic class B implements Parcelable {\n\tString foo;\n\n\tpublic B(String foo){\n\t\tthis.foo=foo;\n\t}\n\n\tpublic String getFoo(){\n\t\treturn foo;\n\t}\n}\n\npublic interface MyCustomView extends MvpView{\n\n\tpublic void showA(A a);\n\n\tpublic void showB(B b);\n}\n```\n\n在这个简单的例子中我们没有加入业务逻辑层。因为我们假设在实际的app中如果有业务逻辑层的话会使整个生成A或B的操作变得复杂。**Presenter**如下所示：\n\n```java\npublic class MyCustomPresenter extends MvpBasePresenter{\n\tRandom random = new Random();\n\n\tpublic void doA(){\n\n\t\tA a = new A(\"My name is A \"+random.nextInt(10));\n\n\t\tif(isViewAttached()){\n\t\t\tgetView().showA(a);\n\t\t}\n\t}\n\n\tpublic void doB(){\n\t\tB b = new B(\"I am B \"+random.nextInt(10));\n\n\t\tif(isViewAttached()){\n\t\t\tgetView().showB(b);\n\t\t}\n\t}\n}\n\n```\n\n\n我们定义了实现了MyCustomView接口的**MyCustomActivity**。\n\n```java\npublic class MyCustomActivity extends MvpViewStateActivity\n implements MyCustomView{\n\n\t@InjectView(R.id.textViewA) TextViewaView;\n\t@InjectView(R.id.textViewB) TextViewbView;\n\n\t@Override protected void onCreate(Bundle savedInstanceState){\n\t\tsuper.onCreate(savedInstanceState);\n\t\tsetContentView(R.layout.my_custom_view);\n\t}\n\n\t@Override public RestoreableViewState createViewState(){\n\t\treturn new MyCustomViewState();// Our ViewState implementation\n\t}\n\n\t// Will be called when no view state exist yet,\n\t// which is the case the first time MyCustomActivity starts\n\t@Override public void onNew ViewStateInstance(){\n\t\tpresenter.doA();\n\t}\n\n\t@Override protected MyCustomPresenter createPresenter(){\n\t\treturn new MyCustomPresenter();\n\t}\n\n\t@Override public void showA(A a){\n\t\tMyCustomViewState vs = ((MyCustomViewState)viewState);\n\t\tvs.setShowingA(true);\n\t\tvs.setData(a);\n\t\taView.setText(a.getName());\n\t\taView.setVisibility(View.VISIBLE);\n\t\tbView.setVisibility(View.GONE);\n\t}\n\n\t@Override public void showB(B b){\n\t\tMyCustomViewState vs=((MyCustomViewState)viewState);\n\t\tvs.setShowingA(false);\n\t\tvs.setData(b);\n\t\tbView.setText(b.getFoo());\n\t\taView.setVisibility(View.GONE);\n\t\tbView.setVisibility(View.VISIBLE);\n\t}\n\n\t@OnClick(R.id.loadA)public void onLoadAClicked(){\n\t\tpresenter.doA();\n\t}\n\n\t@OnClick(R.id.loadB)public void onLoadBClicked(){\n\t\tpresenter.doB();\n\t}\n}\n```\n\n由于我们没有LCE(Loading-Content-Error)，所以不把 **MvpLceActivity**作为基类。我们采用的是最普遍的支持 ViewState的**MvpViewStateActivity**作为基类。基本上我们的View只显示aView 或 bView。\n\n在**onNew ViewStateInstance()**中，我们需要明确在第一个Activity运行时需要做什么，因为先前并不存在ViewState 例子用于修复。在showA(A a) 和 showB(B b)中，我们需要将显示A 或 B的信息存储到ViewState。到这一步，我们就差不多完成了，现在只差MyCustomViewState执行这一步啦：\n\n```java\nublic class MyCustomViewState implements RestoreableViewState{\n\n\tprivate final String KEY_STATE=\"MyCustomViewState-flag\";\n\tprivate final String KEY_DATA=\"MyCustomViewState-data\";\n\n\tpublic boolean showingA=true;// if false, then show B\n\tpublic Parcelable data;// Can be A or B\n\n\t@Override public void saveInstanceState(Bundle out){\n\t\tout.putBoolean (KEY_STATE,showingA);\n\t\tout.putParcelable (KEY_DATA,data);\n\t}\n\n\t@Override public boolean restoreInstanceState(Bundle in){\n\t\tif(in==null){\n\t\t return false;\n\t\t}\n\n\t\tshowingA = in.getBoolean (KEY_STATE,true);\n\t\tdata = in.getParcelable (KEY_DATA);\n\t\treturn true;\n\t}\n\n\t@Override public void apply(MyCustomView view,boolean retained){\n\n\t\tif(showingA){\n\t\t\tview.showA((A)data);\n\t\t}else{\n\t\t\tview.showB((B)data);\n\t\t}\n\t}\n\n\t/**\n\t * @param a true if showing a, false if showing b\n\t */\n\tpublic void setShowingA(boolean a){\n\t\tthis.showingA=a;\n\t}\n\n\tpublic void setData(Parcelable data){\n\t\tthis.data=data;\n\t}\n}\n```\n\n大家可以看到，我们需要把**ViewState**保存到从**Activity.onSaveInstanceState()**调用的 **saveInstanceState()**中，并且在从Activity.onCreate()调用的**restoreInstanceState()**中修复viewstate的数据。apply()方法将会从Activity中调用以修复view state。我们像presenter一样通过调用同样的View interface 方法showA() 或 showB()来实现这一操作。\n\n大家可以看到，我们需要把ViewState保存到从**Activity.onSaveInstanceState()**调用的 **saveInstanceState()**中，并且在从Activity.onCreate()调用的**restoreInstanceState()**中修复viewstate的数据。apply()方法将会从Activity中调用以修复view state。我们像presenter一样通过调用同样的View interface 方法showA() 或 showB()来实现这一操作。\n\n这个外部的**ViewState**把view state修复的复杂性和职责从Activity代码中剥离，并入到这个单独的类中。而编写**ViewState**类的单元测试要比Activity类的单元测试容易得多。\n\n##怎样处理后台线程？\n通常，**Presenter**会管理后台线程。Presenter如何处理后台线程取决于它所关联的Activity或者Fragment ，具体分为两种情况：\n\n* 可保持的Fragment : 如果你调用了Fragment的setRetainInstanceState(true)那么这个Fragment在屏幕旋转时就不会被销毁。只有该Fragment的GUI会被销毁，并且在屏幕旋转时重新调用onCreateView创建视图。这就是说当屏幕旋转时Fragment所有的成员成员变量和Presenter不会发生变化。在这个示例中，我们将新的视图关联到Presenter中。因此，Presenter不需要去掉任何正在运行中的后台任务，因为Presenter已经关联了新的视图。例如:\n\n1.竖屏情况下启动应用\n2.实例化Fragment时会调用onCreate()、onCreateView()、createPresenter(), 然后通过调用presenter的attachView()函数将View关联到Presenter中。\n3. 下一步我们旋转手机屏幕，从竖屏切换到横屏；\n4. 此时onDestroyView() 会调用，而onDestroyView() 又会调用presenter的detachView(true)函数。我们注意到detachView有个参数为true,这是告诉presenter这个Fragment是可持有的Fragment（否则这个参数应该为false）。通过这个参数，presenter就知道它不需要取消正在运行的后台任务；\n5. 应用现在是横屏状态了，在旋转时onCreateView方法会被调用，但是createPresenter()函数不会被调用，因为我们会对presenter 进行不为空的判断，当presenter为空时才调用createPresenter()函数。而Fragment的setRetainInstanceState(true)会保持这个presenter对象，因此presenter此时不会被重新创建；\n6. 在调用了presenter的attachView()之后新创建的View会被重新关联到presenter中。\n7. ViewState会被恢复，但是没有后台任务会被取消，因此也没有后台任务需要重新启动。\n\n\n* Activity和不保持的Fragment :在这个示例中工作流非常的简单。所有的东西都会被销毁，包括presenter。因此presenter对象应该取消所有正在运行的任务。例如 :\n我们采用非保持fragment在竖屏情况下启动app。\n\n8.我们采用非保持fragment在竖屏情况下启动app。\n9.Fragment被实例化之后，调用onCreate()， onCreateView()，和createPresenter()，然后通过调用**presenter.attachView()**将**view（fragment）**附着到presenter。\n10.下一步我们旋转设备屏幕，从竖屏切换到横屏。\n11.此时onDestroyView() 会调用，而**onDestroyView()** 又会调用**presenter**的**detachView(true)**函数。**Presenter**取消后台任务。\n12. **onSaveInstanceState(Bundle)**被调用， **ViewState**被保存到Bundle中。\n13. **App**现在出于横屏状态。新的Fragment被实例化并调用onCreate()，onCreateView()和 **createPresenter()**来创建一个新的presenter例子，通过调用**presenter.attachView()**将新的view附着到新的presenter\n14. **ViewState**会从**Bundle**中恢复，且view的状态也会被恢复。如果ViewState是showLoading，那么**presenter**会重新启动后台线程来加载数据。\n15. 以下是获得ViewState支持的Activity的生命周期图解，如图1-6：\n![](http://hannesdorfmann.com/images/mosby/mvp-activity-lifecycle.png)\n\n以下是获得ViewState支持的Fragment的生命周期图解， 如图 1-7：\n![](http://hannesdorfmann.com/images/mosby/mvp-fragment-lifecycle.png)\n\n##Retrofit模块\n\nMosby提供了 **LceRetrofitPresenter** 和 **LceCallback**。为获得LCE方法showLoading(), showContent() 和 showError()支持的Retrofit编写presenter ，几行代码就能搞定。\n\n```java\npublic class MembersPresenter extends LceRetrofitPresenter>{\n\n\tprivate GithubApigithubApi;\n\n\tpublic MembersPresenter(GithubApi githubApi){\n\t\tthis.githubApi=githubApi;\n\t}\n\n\tpublic void loadSquareMembers(boolean pullToRefresh){\n\t\tgithubApi.getMembers(\"square\",new LceCallback(pullToRefresh));\n\t}\n}\n```\n\n##Dagger模块\n 想在不依靠注入式的情况下写应用？Ted Mosby告诉你，这是行不通滴！Dagger是java依赖注入式框架最常用的方法，也是Android开发者们的心头好。Mosby支持Dagger1。Mosby通过一个叫做getObjectGraph()的方法提供Injector界面。通常，我们的应用模块非常广泛。要想轻松分享这一模块，我们需要把android.app.Application归入子类，使其执行Injector。之后所有的Activity和Fragment都可以通过调用getObjectGraph()来存取ObjectGraph，因为**DaggerActivity and DaggerFragment**也都是Injector。我们也可以通过重写Activity 或 Fragment中的 getObjcetGraph() ，从而调用plus(Module)以增加模块。我个人已经用到Dagger2了，它与Mosby也兼容。大家可以在Github上找到关于Dagger1 和 Dagger2的示例。点此这个链接[https://db.tt/3fVqVdAz](https://db.tt/3fVqVdAz )Dagger1示例 apk；点此这个链接[https://db.tt/z85y4fSY]( https://db.tt/z85y4fSY )Dagger2 示例 apk。\n\n##Rx模块\n **Observables**赞爆了！现在稍微潮一点的小伙儿们都用RxJava了好吗！你猜结果怎么着？RxJava确实是太酷了！所以，Mosby给大家提供一个本质上是Subscriber的MvpLceRxPresenter，它能帮我们自动处理**onNext()， onCompleted() 和 onError()并回调相应的LCE方法，比如showLoading(), shwoContent() **和 showError()。它还将 RxAndroid 附带到observerOn() Android主要 UI 线程。你可能觉得，要是用了RxJava的话就不再需要Model View Presenter了。呃，那只是你的一家之言。在我看来，把View和Model清晰地区分开来非常重要。而且我也认为其中的某些好用的功能在没有MVP的情况下不容易执行。最后，大家要是还想回到过去那个Activity和Fragment包含了上千条又臭又长的代码行时代，那么我祝你在面条式代码的地狱里过得愉快。好了，废话不多说，我介绍的方法不属于面条式代码是因为Observerables引入了一个结构齐整的工作流，把Activity或Fragment做成一个BLOB的想法已经近在咫尺了。\n \n##测试模块\n大家可能注意到这里存在着一个测试模块。这个模块用于Mosby库的内部测试。但是，它也可以为我们自己的app所用。它使用Robolectric为我们的LCE Presenter， Activities 和 Fragments提供单元测试模板。它的基本功能是查看测试中的Presenter是否正确工作：通过观察presenter时候调用showLoading()，\n**showContent()** 和 **showError()**。我们还可以验证setData()中的数据。所以我们可以为Presenter和底层编写类似黑匣子的测试。Mosby的测试模块也提供了测试MvpLceFragment 或 **MvpLceActivity**的可能性。它相当于一种“精简版”的UI 测试。这些测试通过查看xml布局是否包含R.id.loadingView， R.id.contentView 和R.id.errorView之类的指定id、loadingView是否可视，在加载view时，是否是错误的view可视、content view能否处理由setData()提交的已加载数据等方面来检验Fragment或Activity是否正常工作，是否遇到crashing。它和Espresso类的UI测试并不相同。我觉得没有必要为LCE View单独写一个UI 测试。\n\n以下是Ted Mosby库的一些测试小建议：\n1. 编写传统的单元测试来测试业务逻辑层和model。\n2. 使用**MvpLcePresenterTest**来测试presenter。\n3.使用**MvpLceFragmentTest** 和 **MvpLceActivityTest**来测试MvpLceFragment 和 Activity。\n4.如果有必要，可以使用Espresso来编写UI测试。\n\n测试模块尚未完成。大家可以看到这个模块是测试版，因为Robolectric 3.0还没完成，而且Android gradle plugin也没用完全支持传统的单元测试。android gradle plugin \n\n1.2应该会好得多。Robolectric 和 androids gradle plugin可以用了之后我会再写一篇关于Mosby，Dagger，Retrofit和RxJava单元测试的博客。\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n" }, { "path": "issue-12/readme.md", "content": "# 2015.5.31 ( 第十二期 )\n| 文章名称 | 译者 | \n|---------|--------|\n| [自动化Android开发](自动化Android开发.md) | [tmc9031](https://github.com/tmc9031) |\n| [Android进行单元测试难在哪-part4](Android进行单元测试难在哪-part4.md) | [chaossss](https://github.com/chaossss)|\n| [当复仇者联盟遇上Dragger2、RxJava和Retrofit的巧妙结合](当复仇者联盟遇上Dragger2、RxJava和Retrofit的巧妙结合.md) | [Rocko](https://github.com/Rocko) |\n| [Ted Mosby - 软件架构](MVP框架Mosby架构详解.md) | [Mr.Simple](https://github.com/bboyfeiyu)|\n| [Android自动截屏工具](Android自动截屏工具.md) | [sundroid](https://github.com/sundroid) |\n| [Android上MVP的介绍](Android上MVP的介绍.md) | [MiJack](https://github.com/MiJack) |\n" }, { "path": "issue-12/当复仇者联盟遇上Dragger2、RxJava和Retrofit的巧妙结合.md", "content": "当复仇者联盟遇上Dragger2、RxJava和Retrofit的巧妙结合\n---\n\n> * 原文链接 : [When the Avengers meet Dagger2, RxJava and Retrofit in a clean way](http://saulmm.github.io/when-Thor-and-Hulk-meet-dagger2-rxjava-1/)\n* 原文作者 : [Saúl M](http://saulmm.github.io/)\n* [译文出自 : 开发技术前线 www.devtf.cn](http://www.devtf.cn)\n* 译者 : [zhengxiaopeng](https://github.com/zhengxiaopeng) \n* 校对者: [chaossss](https://github.com/chaossss) \n* 状态 : 完成\n\n\n\n最近，许多文章、框架和 android 社区中的讨论都出现关于测试和软件架构方面的内容，就像上次 [Droidcon Spain](http://es.droidcon.com/2015/speakers/) 上所说的，我们专注于做出健壮的程序而不是去开发特性功能。这些现象也意味着 Android 框架和当前 Android 社区的日渐成熟。\n\n如果你是一名 Android 开发者，而到现在你还没听过 [Dagger 2](http://google.github.io/dagger/)、[RxJava](https://github.com/ReactiveX/RxJava)、[Retrofit](http://square.github.io/retrofit/) 这些名词的话你就错过了一些东西了，这个（文章）系列将会把一些关注点放在怎么用一种 [清晰架构](http://blog.8thlight.com/uncle-bob/2012/08/13/the-clean-architecture.html) 去综合使用这些框架。\n\n我刚开始的想法是仅仅写一篇文章的，但是看到这些框架中有大量的内容所以我最终决定写一个最少 3 篇的系列文章。\n\n一如既往，所有的代码都放在了 [Github](https://github.com/saulmm/Avengers)，所有的建议、错误提交和评论都欢迎，我可能没那么多时间去回答所有问题，先说声抱歉 ：）\n\n![Avengers](http://androcode.es/wp-content/uploads/2015/05/avengers_list-e1431571424213.png)\n\n\n## 依赖注入与 Dagger 2\n\n弄懂这个框架的工作机制花费了一些时间，所以我将会根据我所学习到的内容用更加清晰的方式写出来。\n\n[Dagger 2](http://google.github.io/dagger/)是基于 [依赖注入](http://en.wikipedia.org/wiki/Dependency_injection) 模式的。\n\n看下下面的代码片段：\n\n``` Java\n // Thor is awesome. He has a hammer!\n public class Thor extends Avenger {\n private final AvengerWeapon myAmazingHammer;\n\n public Thor (AvengerWeapon anAmazingHammer) {\n myAmazingHammer = anAmazingHammer;\n }\n\n public void doAmazingThorWork () {\n myAmazingHammer.hitSomeone();\n }\n }\n```\n\n雷神（Thor）需要一个 `复仇者武器（AvengerWeapon）` 才能正确工作，依赖注入的基本思想是，如果雷神不是通过构造器创建他自己的 `复仇者武器` 而是在内部自己创建了出来那么他就不能得到很多的优势。如果雷神自己创建出雷锤将会增加耦合度。\n\n`复仇者武器（AvengerWeapon）` 可以是一个接口，根据我们的逻辑可以有不同的实现和注入方式。\n\n在 Android 中，因为框架已经设计好了，我们并不总是能访问构造器，`Activity` 和 `Fragment` 就是这样的例子。\n\n这些依赖注入器框架像 [http://google.github.io/dagger/](http://google.github.io/dagger/)、[Dagger](http://square.github.io/dagger/) 、[Guice](https://github.com/google/guice) 可以给我们带来便利。\n\n使用 [Dagger 2](http://google.github.io/dagger/) 我们可以把之前的代码改写成这样：\n\n``` Java\n// Thor is awesome. He has a hammer!\n public class Thor extends Avenger {\n @Inject AvengerWeapon myAmazingHammer;\n\n public void doAmazingThorWork () {\n myAmazingHammer.hitSomeone();\n }\n }\n```\n\n我们没有直接访问雷神的构造方法，注入器使用了几个指令去创建了雷神的雷锤\n\n``` Java\n public class ThorHammer extends AvengerWeapon () {\n\n @Inject public AvengerWeapon() {\n\n initGodHammer();\n }\n }\n```\n\n`@Inject` 注解用于告诉 Dagger 2 构造器有用于创建雷神的雷锤。\n\n## Dagger 2\n\n[Dagger 2](http://google.github.io/dagger/) 由 Google 开发和维护，是 [Square](https://corner.squareup.com/) 的 [Dagger](http://square.github.io/dagger/) 项目的分支。\n\n首先必须配置注解处理器，`android-apt` 插件就是负责这个角色，允许使用注解处理器而不将其插入到最后的 .apk 中。处理器还配置由该处理器所产生的源代码。\n\n`build.gradle` （项目的根目录中）\n\n``` Gradle\ndependencies {\n ...\n classpath 'com.neenbedankt.gradle.plugins:android-apt:1.4'\n }\n```\n\n`build.gradle` （你的 android module 中）\n\n``` Gradle\napply plugin: 'com.neenbedankt.android-apt'\n\n dependencies {\n ...\n apt 'com.google.dagger:dagger-compiler:2.0'\n }\n\n```\n\n\n## 组件（Components）、模块（modules）和复仇者\n\n模块负责提供依赖，组件负责注入它们（依赖）。\n\n这是一个例子：\n\n``` Java\n@Module\npublic class AppModule {\n private final AvengersApplication mAvengersApplication;\n\n public AppModule(AvengersApplication avengersApplication) {\n this.mAvengersApplication = avengersApplication;\n }\n\n @Provides @Singleton \n AvengersApplication provideAvengersAppContext () { \n return mAvengersApplication; \n }\n\n @Provides @Singleton \n Repository provideDataRepository (RestRepository restRepository) { \n return restRepository; \n }\n}\n```\n\n这个就是主模块，我们感兴趣的是它的依赖存在于程序的生命周期中，一个通用的上下文和一个取回信息的仓库。\n\n很简单，对吧？\n\n我们在 Dagger 2 中所说的 `@Provides` 注解，如果有需要则必须会创建其依赖。因此如果我们没有给一个特别的依赖指定一个提供者（provider），Dagger 2 将会去寻找有 `@Inject` 注解的构造方法。\n\n组件使用模块去完成依赖注入，看看这个模块的组件：\n\n``` Java\n@Singleton @Component(modules = AppModule.class)\npublic interface AppComponent {\n\n AvengersApplication app();\n Repository dataRepository();\n}\n```\n\n这个模块并不由任何的 activity 或者 fragment 去调用，而是通过更复杂的模块，以提供这些需要得到的依赖\n\n``` Java\nAvengersApplication app();\nRepository dataRepository();\n```\n\n组件必须暴露它们的依赖给图（该模块提供的依赖关系），也即是这个模块提供的依赖关系必须对其它组件是可见的，其它的组件有把当前这个组件作为依赖，如果这些依赖关系是不可见的，Dagger 2 将不会注入这些要求的依赖。\n\n下面是我们的依赖关系树：\n\n![tree of dependencies](http://androcode.es/wp-content/uploads/2015/05/Dagger-graph.png)\n\n``` Java\n@Module\npublic class AvengersModule {\n\n @Provides @Activity\n List provideAvengers() {\n\n List avengers = new ArrayList<>(6);\n\n avengers.add(new Character(\n \"Iron Man\", R.drawable.thumb_iron_man, 1009368));\n\n avengers.add(new Character(\n \"Thor\", R.drawable.thumb_thor, 1009664));\n\n avengers.add(new Character(\n \"Captain America\", R.drawable.thumb_cap,1009220));\n\n avengers.add(new Character(\n \"Black Widow\", R.drawable.thumb_nat, 1009189));\n\n avengers.add(new Character(\n \"Hawkeye\", R.drawable.thumb_hawkeye, 1009338));\n\n avengers.add(new Character(\n \"Hulk\", R.drawable.thumb_hulk, 1009351));\n\n return avengers;\n }\n}\n```\n\n这个模块将会用于一个特别的 activity 的依赖注入，实际上就是负责绘画的复仇者名单：\n\n``` Java\n@Activity \n@Component(\n dependencies = AppComponent.class, \n modules = {\n AvengersModule.class, \n ActivityModule.class\n }\n)\npublic interface AvengersComponent extends ActivityComponent {\n\n void inject (AvengersListActivity activity);\n List avengers();\n}\n```\n\n再次，我们暴露出我们的依赖：`List` 给其它的组件，在这种情况下出现了一个新方法：`void inject (AvengersListActivity activity)` 。**在此方法被调用时**，这些依赖关系将可被消耗，将会被注入给 `AvengerListActivity` 。\n\n\n## 结合所有\n\n我们的类 `AvengersApplication`，将负责提供应用到其他组件的组件，注意，仅仅提供组件而不会用于注入依赖。\n\n再次提醒的是 [Dagger 2](http://google.github.io/dagger/) 是在编译时生成必要的元素，如果你没有构建项目你是找不到 `DaggerAppComponent` 类的。\n\nDagger 2 从你的组件中生成的类的格式：`Dagger$${YourComponent}.` 。\n\n`AvengersApplication.java`\n``` Java\npublic class AvengersApplication extends Application {\n\n private AppComponent mAppComponent;\n\n @Override\n public void onCreate() {\n\n super.onCreate();\n initializeInjector();\n }\n\n private void initializeInjector() {\n\n mAppComponent = DaggerAppComponent.builder()\n .appModule(new AppModule(this))\n .build();\n }\n\n public AppComponent getAppComponent() {\n\n return mAppComponent;\n }\n}\n```\n\n`AvengersListActivity.java`\n``` Java\npublic class AvengersListActivity extends Activity \n implements AvengersView {\n\n @InjectView(R.id.activity_avengers_recycler) \n RecyclerView mAvengersRecycler;\n\n @InjectView(R.id.activity_avengers_toolbar) \n Toolbar mAvengersToolbar;\n\n @Inject \n AvengersListPresenter mAvengersListPresenter;\n\n @Override\n protected void onCreate(Bundle savedInstanceState) {\n\n super.onCreate(savedInstanceState);\n setContentView(R.layout.activity_avengers_list);\n ButterKnife.inject(this);\n\n initializeToolbar();\n initializeRecyclerView();\n initializeDependencyInjector();\n initializePresenter();\n }\n\n private void initializeDependencyInjector() {\n\n AvengersApplication avengersApplication = \n (AvengersApplication) getApplication();\n\n DaggerAvengersComponent.builder()\n .avengersModule(new AvengersModule())\n .activityModule(new ActivityModule(this))\n .appComponent(avengersApplication.getAppComponent())\n .build().inject(this);\n }\n```\n\n当 `initializeDependencyInjector()` 中执行到 `.inject(this)` 中时 [Dagger 2](http://google.github.io/dagger/) 就会开始工作并提供必要的依赖关系，请记住 [Dagger 2](http://google.github.io/dagger/) 在注入时是严格执行的，我要说的意思是组件必须是 **完全相同** 的组件类，此组件类负责调用 `inject()` 方法。\n\n`AvengersComponent.java`\n``` Java\n...\npublic interface AvengersComponent extends ActivityComponent {\n\n void inject (AvengersListActivity activity);\n List avengers();\n}\n```\n\n否则，依赖关系将不会被解决。在如下情况，presenter 与由 Dagger 2 提供的复仇者一起初始化：\n\n``` Java\npublic class AvengersListPresenter implements Presenter, RecyclerClickListener {\n\n private final List mAvengersList;\n private final Context mContext;\n private AvengersView mAvengersView;\n private Intent mIntent;\n\n @Inject public AvengersListPresenter (List avengers, Context context) {\n\n mAvengersList = avengers;\n mContext = context;\n }\n```\n\n[Dagger 2](http://google.github.io/dagger/) 将会解决这个 presenter，因为其有 `@Inject` 注解。该构造方法的参数由 Dagger 2 解决，因为它知道怎么去构建它，这得益于这个模块中的 `@Provides` 方法。\n\n\n## 总结\n\n像 [Dagger 2](http://google.github.io/dagger/) 这样，使用好了依赖注入器，其力量是无可争辩的，想象下根据该框架提供的 API 级别你可以有不同的策略，其可能性是无止境的。\n\n## 资源\n\n- **Chiu-Ki Chan** - [Dagger 2 + Espresso + Mockito](http://blog.sqisland.com/2015/04/dagger-2-espresso-2-mockito.html)\n\n- **Fernando Cejas** - [Tasting Dagger 2 on Android](http://fernandocejas.com/2015/04/11/tasting-dagger-2-on-android/)\n\n- **Google Developers** - [Dagger 2, A new type of dependency injection](https://www.youtube.com/watch?v=oK_XtfXPkqw)\n\n- **Mike Gouline** - [Dagger 2, Even sharper, less square](http://blog.gouline.net/2015/05/04/dagger-2-even-sharper-less-square/)\n" }, { "path": "issue-12/自动化Android开发.md", "content": "自动化 Android 开发\n---\n\n> * 原文链接：[Automating Android development](https://medium.com/google-developer-experts/automating-android-development-6daca3a98396)\n> * 原文作者：[Enrique López Mañas](https://medium.com/google-developer-experts/automating-android-development-6daca3a98396)\n> * 译者：[tmc9031](https://github.com/tmc9031)\n> * 校对者：[Mr.Simple](https://github.com/bboyfeiyu)\n> * 状态：完成\n\n\n\n我最近已经在 [DroidCon Spain](http://es.droidcon.com/2015/) 和 [DroidCon Italy](http://it.droidcon.com/2015/) 讨论过关于如何自动化传统的Android工作流。\n令我惊讶的是，仍然还有很多组织缺少执行持续集成（CI）的策略。这是一个巨大的灾难！\n我决定用文字表达我的思想，就是如何高效的实现持续集成（CI）。\n\n作为一个软件攻城狮，你的目标应该是尽可能多的自动化许多工作流程。\n计算机比人更高效，它们不需要吃饭睡觉，它们的任务表现没有错误，并且它们使你的生活更轻松。\n请记住：*做的越多是为了了做的更少*\n\n持续集成（CI）尽管是一个包含许多不同要点的综合领域，并且你需要把它们整合在一起。\n比如，你需要讨论 Jira，你需要关心测试和分支，你需要脚本和构建。\n\n这里有一大块我想在这个帖子中介绍的。他们的每一点都值得展开介绍，但这不是这篇文章的目的。其目的是展示给你每个基础知识，以及如何组合他们。\n\n1. 定义一个分支策略。\n2. 使用敏捷方法\n3. Gradle和构建脚本\n4. 测试\n5. 使用CI服务器。\n\n\n### 分支策略\n\n\n分支是重要的。当你正在构建一个新的产品，你想建立一个协议如何工作。\n人们怎么应该提交自己的特性？我们如何发布？我们如何保证不正在破坏什么东西？\n要回答这些问题，你需要采用分支策略。\n\n我正在使用一个经过轻微修改的由 [Vincent Driessen](http://nvie.com/posts/a-successful-git-branching-model/) 提出的分支策略。\n让我们考虑我们应用程序的三种状态：**alpha**, **beta** 和 **release**.\n\n* **Alpha** 的状态是你的系统正在开发。\n* **Beta** 当你测试的功能已被批准和合并。\n* **Release** 是当系统可交付的状态。\n\n> (一些人喜欢叫 alpha 为 “develop” ，并且 beta 为 “stage”. 我认为希腊字母表的字母总是更cool的).\n\n下面的图片是一个项目的第一个状态。你有一个初始的提交到了master分支。\n\n![image](https://d262ilb51hltx0.cloudfront.net/max/800/1*CWNjrbmm5jQ0uvp-L53EYg.png)\n\n我们的系统才刚刚开始。只有第一个提交在master分支，其他分支还是空的。\n追着工作时间的进行。你需要从初始状态进入到develop过程。这将是你的1.0.1版本。\n\n![image](https://d262ilb51hltx0.cloudfront.net/max/800/1*JLekFIGh6ciEvj52w3hddA.png)\n\n> 在这个点上，alpha的确与master相同\n\n现在，你会在功能特性上开始工作。对于每一个特性，你会创建一个分支。\n使用正确的命名是很重要的，有几种方法可以做到这一点。如果您使用的是一个问题跟踪系统像 [Jira](https://www.atlassian.com/software/jira)，你可能会用一个与功能相关联的标签名（比如 FEATURE-123）。\n当我提交特性时，我会包括分支名在提交信息里，并添加一个完整的描述。\n\n *[FEATURE-123] Created a new screen that performs an action.*\n\n![image](https://d262ilb51hltx0.cloudfront.net/max/800/1*wKF9mdhTLC8MFdy02WJ1EQ.png)\n\n注意，在每个分支的项目里都有自己的版本号。您可以使用 [git tags](http://git-scm.com/book/en/v2/Git-Basics-Tagging) 来执行版本号的控制\n\n当一个功能已经完成，一个 pull request 就开放了，所以你的组织的其他成员就可以批准它。这是为了确保你提供高质量软件的一个关键部分。在 [Sixt](http://www.sixt.de/mobileapps/)，另一成员被分配到你的代码审查，这个人会通读你全部的代码。\n我们保证我们的代码是符合我们的[coding conventions](https://speakerdeck.com/kikoso/android-coding-guidelines)和我们对过程中严格的要求，典型的如在XML文件中有一个额外的空格。我们评论的命名（“函数名我不清楚”），检查我们的设计是完美的（“你的文本视图的颜色 \\#DCDCDC 但设计是 \\#DEDEDE”）有一个功能测试去检查该特性是覆盖了在问题跟踪里编写的验收标准的。\n我们甚至进行一些哲学讨论，比如关于null和void或empty变量的意义。这听起来令人讨厌，但它是有趣的。如果是充满热情的做了这一切，到时候你就知道你的代码达到了产品需要的提交质量。\n\n\n### 敏捷和迭代\n\n\n你可能会在执行[SCRUM](http://en.wikipedia.org/wiki/Scrum_%28software_development%29), [Kanban](http://en.wikipedia.org/wiki/Kanban_%28development%29)或另外的敏捷方法。通常你会进行在几个星期的冲刺工作。我们认为是一个好主意，把冲刺分到两周：第一周是用来开发特性，而第二周将稳定在第一阶段创造的特性。在第二个冲刺中，我们将修复发现的漏洞，实现完美的布局或提高重构我们的代码。这项工作是在 **beta/stage** 分支完成的。\n如下图所示\n\n![image](https://d262ilb51hltx0.cloudfront.net/max/800/1*7lynNxY8iQpFHCee_Rkjjg.png)\n\n> 这些黄点属于bug修复和稳定性阶段\n\n如果你遵循我们的约定，敏捷结束时你将会有一个可交付的成果。这将是一个准备发表在谷歌商店的可交付文件。此时此刻，我们的应用程序的最后版本已经合并到了master。\n另一个非常重要的课题是如何创建一个热修复补丁。我们的模型试图通过使用代码检查和修复bug和产品稳定的第二周来阻止他们发生，但错误确实已经发生。这是发生在生产时，这种模式要求错误直接被修正在 **master** 分支。\n\n![image](https://d262ilb51hltx0.cloudfront.net/max/800/1*sdL8HDfMgoNuhnLKu7Soew.png)\n\n你有没有意识到这个模型的标志？是的，就是那！该热修复补丁是不存在在我们的 **alpha/beta** 的分支。经过修复和稳定期后（第二周），我们的 **alpha** 分支是旧状态，错误仍然是存在的。我们需要立即合并到各分支来保证正确，从而确保每一个修复是存在所有的分支的。\n\n![image](https://d262ilb51hltx0.cloudfront.net/max/800/1*Rijzdkk4SA4T9T3koBAXCg.png)\n\n很难理解？可能是读起来比实施来的难。\n如果你没有一个分支策略，只是试图使用这个模型来开发一个特性。你会发现很容易工作，而且你甚至会开始定制！\n\n\n### Gradle 和脚本化\n\n\n现在您已经阅读分支模型，我们准备继续讨论接下来的步骤。Gradle是一个工具,将帮助我们自动完成很多事情。你可能熟悉Gradle(或其它家族成员,Maven和Ant)。Gradle是一个项目的自动化工具，当我们正在建设我们的应用程序时，可以使用执行功能和定义属性。它介绍了一种基于Groovy的领域语言，它能做到的基本上只受限于我们的想象力。\n\n我以前写的一个 [post](http://codetalk.de/?p=112) 和一些技巧来使用工具。他们中的一些将非常有用，包括对于你的应用，但之后也有一些我已经应用的，我想在这里介绍。\n\n#### 构建配置（BuildConfig）的力量\n\n当我们编译Android应用程序时，*BuildConfig* 是一个自动生成的文件。这个文件，默认情况下，看起来如下：\n\n![image](https://d262ilb51hltx0.cloudfront.net/max/800/1*wkoXjbSYaYymUhZrO8-jRw.png)\n\nBuildConfig 包含一个字段，叫 **DEBUG**，指示应用程序是否已经编译在调试模式。这个文件是高度可定制的，当我们工作在不同的构造类型时，这是非常便利的。\n\n应用程序通常使用服务工具追踪其行为 [Google Analytics](http://www.google.com/analytics/ce/mws/), [Crashlytics](https://try.crashlytics.com/) 或其他平台。当我们正在开发应用时，我们可能不想影响这些指标（想象一个用户界面的测试，自动发布的每一天，跟踪您的登录屏幕？）。我们也会根据我们的构建有不同的域名（例如development.domain.com, staging.domain.com…），我们要使用自动的。但我们怎么可以做的干净利落？容易！在Gradle的buildTypes域，我们可以添加任何我们希望的新域。这些域将通过*BuildConfig* 在以后可用（这意味着，我们可以使用 BuildType.FIELD 来读取它们）。\n\n![image](https://d262ilb51hltx0.cloudfront.net/max/800/1*Z_YYrTPF7FTShHAt5tqW3g.png)\n\n在 [this post](http://codetalk.de/?p=112) 我展示了如何使用不同的图标和如何改变包的名称。利用这个我们可以安装我们应用程序的不同版本。这能够非常方便的同时看到我们的 beta, alpha 和 release 版本。\n\n\n### 保持测试\n\n\n测试本身，和整个过程都有它自己的中间环节。当我们谈论测试就是我们在谈论模拟的组件，关于UI测试和集成测试，关于仪器，和所有对于Android可用的不同框架。\n\n测试是非常重要的，因为它可以防止开发者破坏现有的东西。没有测试，当我们开发一个新的功能B时，我们可以很容易地干扰一个旧的特性A。当一个新的特征被提交，是很难手动测试整个系统的，但自动的做这些就更容易控制一个系统的稳定性。\n\n这里有了许多不同的测试可以在移动设备上实施：只是列举几个，我们可以考虑，集成测试，功能测试，性能测试和用户界面测试。每一种都有不同的功能，它们一般是定期触发以确保新功能没有破坏或干扰系统。\n\n为了展示一个基本的例子，如何将测试在 Jenkins 集成（以及他们如何实现生成出错时停止的功能）\n我们将看到一个做UI测试的小例子 [Espresso](https://code.google.com/p/android-test-kit/wiki/Espresso) 每次都是在 Jenkins 构建测试我们的Android应用程序。\n\n\n### 一个应用程序的示例\n\n\n我创建了一个小示例应用程序并上传到 [GitHub](https://github.com/kikoso/Android-Testing-Espresso)，所以你可以来这里看看。也有一些分支使用命名约定和 pull requests，直到现在你可以看到审查的一切解释。该应用程序是相当基本的：它有一个TextView屏幕。还有三个已在文件执行的UI测试单元\n[MainActivityInstrumentationTest](https://github.com/kikoso/Android-Testing-Espresso/blob/master/src/androidTest/java/com/dropsport/espressoreadyproject/tests/MainActivityInstrumentationTest.java):\n\n1. 检查在屏幕上存在一个TextView。\n2. 检查TextView包含文本“Hello World!”\n3. 检查TextView包含文本“What a label!”\n\n最后的两个试验是互斥的（这意味着，无论是一个或另一个是成功的，但不能两者同时成立）。我们通过以下命令对应用进行测试：\n\n ./gradlew clean connectedCheck.\n\n如果你检出了代码，你可以自己试试注释功能 *testFalseLabel*。这将使测试失败。\n\n\n### 把一切都集成在 Jenkins\n\n\n现在，我们已经检查了一些事情，让我们看看他们如何适配 Jenkins。如果你没有安装它，你可以从网站下载 [last version](https://jenkins-ci.org/)。\n\n我们没有提到一些东西，但这里也有分支策略。\n有许多不同的方法，它们都具有各自的优点和缺点：\n\n1. 你可以在分支构建前触发测试。\n2. 你可以晚上或每日构建，不要阻止构建，但如果失败仍然要发出通知。\n\n在本教程中我选择了第一种方法，也是为了显示 Jenkins 的一大特征：jobs 之间的依赖关系。让我们创造三个 jobs：**Job Beta**, **Job Alpha** and **Job Tests**。\n\n1. **Job Alpha** 将构建 alpha 分支 (通过 ./gradlew clean assembleAlpha)\n2. **Job Beta** 将做同样的工作在 beta 分支上（通过 ./gradlew clean assemblebeta）。这是每一次有分支合并到 beta 分支上就会执行的\n3. **Job Tests** 每次有分支合并到 alpha 分支时都将触发。如果它成功了，它会引发 **Job Alpha**。\n\n![image](https://d262ilb51hltx0.cloudfront.net/max/800/1*OPzV-aZLBGxdPYWPIip8Bg.png)\n\nJenkins 是一个基于大量的插件的平台。许多公司正在为他们的产品不断地发布插件，他们将集成在 Jenkins，我们可以很容易地与其他平台连接。\n让我们看看在 Jenkins 的一些选项\n\n#### 依赖\n\n使用依赖 Jenkins 可以互连项目。也许我们要连接测试 jobs 和基于试验结果来控制启动。或许我们在实际构建应用之前，部分逻辑首先存在需要编译的lib库里。\n\n#### 通知\n\nJenkins 可以通知一个人或一个工作组或构建错误。通知一般是电子邮件，但也有插件可以通过IM系统发送消息，如 [Skype](https://wiki.jenkins-ci.org/display/JENKINS/Skype+Plugin) 或者 [SMS](https://wiki.jenkins-ci.org/display/JENKINS/SMS+Notification)（最新版当你有重要的测试失败时可以很方便的通知）。\n\n#### 交付\n\n你可能知道，在这一点上 [HockeyApp](http://hockeyapp.net/) 或另一个 [delivery platforms](http://alternativeto.net/software/hockeyapp/)。他们基本上可以存储二进制文件，创建组，并当应用程序被上传时通知他们。想象看测试者自动在他/她的设备上接收每次他们被创造的文件，和产品所有者被通知有新的beta版的情景。这里有一个Jenkins 插件 [HockeyApp plugin](https://wiki.jenkins-ci.org/display/JENKINS/HockeyApp+Plugin) 能够上传二进制文件到 Hockey（甚至通知成员，或作为你最近提交的 release notes 使用）。\n\n![image](https://d262ilb51hltx0.cloudfront.net/max/800/1*P6-P4hBkKfAG7Ls0bzXeEQ.png)\n\n我还是喜欢保持手动发布产品的步骤，这可能是由于在出版过程中不经过人工控制的一种担心。但是，确实有一个 [plugin](https://wiki.jenkins-ci.org/display/JENKINS/Google+Play+Android+Publisher+Plugin) 用来直接发步到 Google Play。\n\n\n### 结论\n\n\n在 *building*, *testing*, *delivering* 和 *publishing* 实现自动化，主要是在一个团队工作中选择正确的决策。当这个决定是明确的，我们才可以继续去技术上实现。\n\n有一件事情是肯定的：错误会由于以往人们的行动而大幅度减少，并结合强大的测试覆盖率，我们的软件质量将大大提高。这里我借用同事的座右铭 [Cyril Mottier](https://developers.google.com/experts/people/cyril-mottier)：\n\n> 致精而大\n\n这是你职业生涯中的一个重要时刻！当你想在工作中保证 **质量** 而努力，而不是 **数量** 的多少。我了解这件事，第一步是尽你所能的实现自动化。事实上，我可以用以前的口号改述为另一句话，我将在我的日常生活里：\n\n> 自动化的更多，所以你被动化的更少\n\n祝：快乐编程！\n\n![image](https://d262ilb51hltx0.cloudfront.net/fit/c/63/63/1*AV6Ju95BJPkkIXg1x8Ni1w.jpeg \"Enrique López Mañas\")\n" }, { "path": "issue-13/Android进行单元测试难在哪-终.md", "content": "Android 进行单元测试难在哪-终\n---\n\n> * 原文链接 : [WHAT I’VE LEARNED FROM TRYING TO MAKE AN ANDROID APP UNIT TESTABLE](http://www.philosophicalhacker.com/2015/05/22/what-ive-learned-from-trying-to-make-an-android-app-unit-testable/)\n* 原文作者 : [Matthew Dupree](http://philosophicalhacker.com/)\n* [译文出自 : 开发技术前线 www.devtf.cn](http://www.devtf.cn)\n* 译者 : [chaossss](https://github.com/chaossss) \n* 校对者: [Mr.Simple](https://github.com/bboyfeiyu) \n* 状态 : 完成\n\n\n\n\n在前面的博文中，我给大家介绍并展示了要怎么使用 Square 大法架构 Android 应用，事实上，Square 开发新的 Android 应用架构本意只是增强应用的可测试性。正如我在[Android 进行单元测试难在哪-序](https://github.com/bboyfeiyu/android-tech-frontier/blob/master/issue-8/Android%20%E8%BF%9B%E8%A1%8C%E5%8D%95%E5%85%83%E6%B5%8B%E8%AF%95%E9%9A%BE%E5%9C%A8%E5%93%AA-%E5%BA%8F.md)中所说，要在 Android 中进行单元测试在大多数情况下都很费时，尝试一些奇技淫巧或者第三方库情况可能会好一些。为了实现高效且不依赖第三方库的测试单元，Square 大法应运而生。\n\n此外，我们在[ Android 进行单元测试难在哪-part1](https://github.com/bboyfeiyu/android-tech-frontier/blob/master/issue-9/Android%E8%BF%9B%E8%A1%8C%E5%8D%95%E5%85%83%E6%B5%8B%E8%AF%95%E9%9A%BE%E5%9C%A8%E5%93%AA-part1.md)和[ Android 进行单元测试难在哪-part3](https://github.com/bboyfeiyu/android-tech-frontier/blob/master/issue-11/Android%E8%BF%9B%E8%A1%8C%E5%8D%95%E5%85%83%E6%B5%8B%E8%AF%95%E9%9A%BE%E5%9C%A8%E5%93%AA-part3.md)两篇博文就这个问题进行了研究，最后成功地通过 Square 大法为 Android 应用实现了测试单元，这篇文章则是对 Square 大法进行评估，我将从下面三个方面进行：\n\n1. 为 Android 应用实现高效的测试单元并不需要移除所有对 Android SDK 的编译时依赖。（事实上这样做有些不切实际。）\n\n2. 加入我们重新设计 Square 大法，使 Square 大法的使用不需要移除所有对 Android SDK 的编译时依赖，尝试将 Square 大法运营到项目中唯一会发生的问题是：实现一大堆模板代码。幸运的是，许多诸如此类的模板代码都可以通过 Android Studio 自动生成。\n\n3. 依赖注入确实是让 Square 大法成为应用可测试性治病良方的好办法。\n\n##移除所有对 Android SDK 的编译时依赖既不必要也不切合实际\n\n完成这个系列博文的最初愿望就是通过让 Android 应用栈变成下图那样，增强应用的可测试性：\n\n![](http://i2.wp.com/www.philosophicalhacker.com/wp-content/uploads/2015/04/androidstack-02.png?resize=279%2C172)\n\n接下来我将告诉大家，这个想法一直误导着我们。要使应用的可测试性增强，我们还需要利用依赖注入的其它特性，而不仅仅是用它将业务逻辑代码和 Android SDK 解耦。最初的原因是对象的 Android 依赖可以通过类似 Mockito 的东西模拟出来，而且如果我们无法单独通过 Mocktio 完全控制测试单元的预测试状态的话，我们还可以用具有 mock 实现的接口代替这些 Android 依赖。而这也正是我们在[ Android 进行单元测试难在哪-part4](https://github.com/bboyfeiyu/android-tech-frontier/blob/master/issue-12/Android%E8%BF%9B%E8%A1%8C%E5%8D%95%E5%85%83%E6%B5%8B%E8%AF%95%E9%9A%BE%E5%9C%A8%E5%93%AA-part4.md)中重构 SessionRepositoryManager 的办法。\n\n移除依赖不仅是不必要的，将它完全与 Android SDK 解耦也是不切实际的，问题在于：当你尝试完成这个目标时，不妨回顾你已经完成的工作，你会很明显地感觉这是不必要的，所以我只打算在此简要地陈述个中因由。\n\n要移除移除应用中所有对 Android SDK 的编译时依赖可能会导致下面的问题：\n\n1. 应用必须为此定义许多方法和类。\n\n2. 添加的接口和已有的 Android 接口几乎一样。\n\n3. 由于有些情况下，对象需要被注入；有些情况下，对象不需要被注入，带有依赖的类构造器会因此变得很臃肿。\n\n虽然 Square 大法存在一些问题，但这并不影响我在之前的博文中有关 Square 的讲解，Square 的这些特性依旧是实用，值得尝试的。由于 Android SDK 供予我们使用的应用组件类都没有被依赖注入，我们要在 Android 应用中进行单元测试确实很困难，但有了 Square 大法后，只要我们将业务逻辑交给被依赖注入的纯 Java 对象，就能轻易地对 Android 应用进行单元测试。尽管 Square 大法减小了移除 Android SDK 依赖的需求，但 Square 大法仍然是增强应用可测试性的屠龙宝刀。但我个人还是希望对 Square 大法进行优化，使得 Square 大法能无视这个需求，换句话说，我希望能够找到一种不需要我们移除所有对 Android SDK 依赖的架构方法，\n\n##乏味的模板代码是阻碍应用变得可测试的绊脚石\n\n如果我们对 Square 大法进行优化，使其不再要求我们移除对 Android SDK的依赖，Square 大法看起来真的是天下第一的神功了。委以业务逻辑的纯 Java 对象将被应用组件类引用，使它们能够访问所有组件类内的属性和回调。因此，将业务逻辑转移到进行了依赖注入的纯 Java 对象，不应该将那些拥有履行自身职责的数据的对象排除在外。\n\n如果这是正确的，那么唯一阻止我们使用 Square 大法的就是实现乏味的模板代码。幸运的是，Android Studio 为我们提供了过渡到 Square 大法的重构选项——the Extract Delegate option。利用这个选项，可以自动地将类的方法和实例变量转移到一个委托类中，并让原始类通过调用委托类处理逻辑，而不用依赖类自身的方法。\n\n这个[视频](www.youtube.com/embed/N0F7w4wEnQ8)向我们展示了如何利用 `the Extract Delegate option` 完成重构 SessionDetailActivity 的 onStop() 并使之能够进行单元测试必要的操作。我曾在之前的博文中给大家解释过进行这样的重构为什么是必要的，很显然，手动操作无法涵盖所有情况，而且你需要为此不断重复实现代码语句块中分离 Activity View 和数据的方法，这样重复而又没有意义的工作无异于浪费生命，因此这个选项真的非常实用。\n\n##依赖注入是 Square 大法的精髓\n\n[Android 进行单元测试难在哪-part3](https://github.com/bboyfeiyu/android-tech-frontier/blob/master/issue-11/Android%E8%BF%9B%E8%A1%8C%E5%8D%95%E5%85%83%E6%B5%8B%E8%AF%95%E9%9A%BE%E5%9C%A8%E5%93%AA-part3.md)的秘密在于：**依赖注入**。\n\n— Chris Arriola (@arriolachris) [May 15, 2015](https://twitter.com/arriolachris/status/599232312492982273)\n\nSquare 大法之所以能解决 Android 的单元测试问题，是因为它允许我们对持有业务逻辑的类进行真正的依赖注入，我之所以强调 Square 允许我们进行的是**真正的**依赖注入，是因为依赖注入这个概念在 Dagger 库中也被提到过，然而，Dagger 并不能真正简化 Android 应用进行单元测试的代码。\n\n这是因为 Dagger 就像它介绍的那样，确实是一个 Service 定位库，正是如此，Dagger 强迫我们实现一个模块，使之为我们想要进行单元测试的对象提供 mock 依赖。为了能利用这些模块，我们还要确保由这些 mock 提供者模块构建的对象图与我们尝试进行单元测试的对象使用的对象图相同。\n\n而正是这样的操作使得 Dagger 的依赖注入不如 Square 大法中真正的依赖注入那样简便，解释为什么 Dagger 不能简化对 Android 应用进行单元测试的过程完全可以写一篇博文，所以现在，我唯一能做的就是先指出这个问题，如果我们理解[ Martin Fowler 对依赖注入的定义](http://martinfowler.com/articles/injection.html#InversionOfControl)（这篇博文确实值得一读，因为他创建了一个新的术语），就会发现 Dagger 确实只是一个 Service 定位库，而且 Google 官方有关测试的博客也有[一篇博文](http://martinfowler.com/articles/injection.html#InversionOfControl)对此作出解释。\n\n##结论\n\n如果想让 Android 应用可以进行单元测试，那就用 Square 大法吧，当然了，如果有其他解决办法的话我也会支持的。在这里友情提示一下哈：我只是列出我了解的几种办法，我可没有说 Square 大法天下第一无人可敌，事实上增强应用可测试性应该还会有其他办法的。\n\n这篇博文的发布也预示着这系列博文走向终结啦，我非常感谢每一个关注本系列博文的 Android 开发者的支持，感谢每一个人对我的鼓励、转发以及大家在社交媒体上对我的褒奖，我感恩这一切。这些积极的反馈使我认识到讨论和思考对 Android 应用进行测试的重要性，正是完成这个系列博文给我带来的启示使我决定：我要在未来花费更多的时间在博客中研究 Android 测试方面的知识。我会在每个周五更新博客，希望能学习更多有关测试的知识，和大家一起进步。" }, { "path": "issue-13/Square：从今天开始抛弃Fragment吧！.md", "content": "Square：从今天开始抛弃Fragment吧！\n---\n\n> * 原文链接 : [Advocating Against Android Fragments](https://corner.squareup.com/2014/10/advocating-against-android-fragments.html)\n* 原文作者 : [Pierre-Yves Ricau](http://twitter.com/Piwai)\n* [译文出自 : 开发技术前线 www.devtf.cn](http://www.devtf.cn)\n* 译者 : [chaossss](https://github.com/chaossss) \n* 校对者: [Belial](www.belial.me)\n* 状态 : 完成\n\n最近我在 Droidcon Paris 上进行了[一个技术相关的演讲](http://fr.droidcon.com/2014/agenda/detail?title=D%C3%A9fragmentez+vos+apps+avec+Mortar+%21)，我在这次演讲中给大家展示了 Square 使用 Fragment 进行开发时遇到的种种问题，以及其他 Android 开发者是怎么避免在项目中使用 Fragment 的。\n\n在 2011 年那会，由于下面的原因我们决定使用 Fragment：\n\n- 在那会，虽然我们很想让应用能在平板设备上被使用，但我们确实没能为平板提供平台支持。而 Fragment 能帮助我们完成这项愿望，建立响应式 UI 界面。\n\n- Fragment 是视图控制器，它们能够将一大块耦合严重的业务逻辑模块解耦，并使得解耦后的业务逻辑能够被测试。\n\n- Fragment 的 API 能够进行回退栈管理（例如，它能反射某个 Activity 内 Activity 栈的具体操作）\n\n- 因为 Fragment 处于视图层的顶层，而为 View 设置动画并不麻烦，使得 Fragment 为设置页面切换的过渡效果提供了更好的支持。\n\n- Google 建议我们使用 Fragment，而我们作为开发者都想让自己的代码符合标准。\n\n在 2011年之后，我们在为 Square 进行开发的过程中发现了比使用 Fragment 更好的方法。\n\n#关于 Fragment 你不知道的事\n\n##The lolcycle\n\n在 Android 中，Context 就像一个[上帝对象](http://en.wikipedia.org/wiki/God_object)，因为在 Context 类中涵盖了太多 Android 系统的信息和相关的操作，使得 Context 在 Android 系统中相当于一个全知全能的上帝，而 Activity 就是为 Context 添加了生命周期的子类。不过让上帝具有生命周期还是有些讽刺的。虽然 Fragment 不是上帝对象，但 Fragment 为了能够完成 Activity 中能完成的各种操作，使 Fragment 自身的生命周期变得异常复杂。\n\nSteve Pomeroy 做了一张[ Fragment 的完整生命周期图](https://github.com/xxv/android-lifecycle)，我相信任谁看到这张图都不会好受：\n\n![](https://corner.squareup.com/images/no-fragments/lifecycle.png)\n\n这张图由 Steve Pomeroy 完成，图中移除了 Activity 的生命周期，分享这张图需要获得 [CC BY-SA 4.0](https://creativecommons.org/licenses/by-sa/4.0/) 许可。\n\n整个 Fragment 的生命周期让你很头疼要怎样使用这些回调方法，它们是同步调用的呢，还是只是一次性全部调用呢，还是其它情况……？\n\n##难于调试\n\n当你的应用出现 Bug，你得用调试工具一步一步地执行代码才能知道到底发生了什么，虽说一般情况下这样做 Bug 都能解决，但如果你在调试的时候发现 Bug 和 FragmentManagerImpl 类存在某种联系，那么我可要好好恭喜你即将中大奖了！\n\n因为要跟踪 FragmentManagerImpl 类内代码的执行顺序，并进行调试是很困难的，这也使得修复应用中相关的 Bug 也变得异常困难：\n\n```java\nswitch (f.mState) {\n case Fragment.INITIALIZING:\n if (f.mSavedFragmentState != null) {\n f.mSavedViewState = f.mSavedFragmentState.getSparseParcelableArray(\n FragmentManagerImpl.VIEW_STATE_TAG);\n f.mTarget = getFragment(f.mSavedFragmentState,\n FragmentManagerImpl.TARGET_STATE_TAG);\n if (f.mTarget != null) {\n f.mTargetRequestCode = f.mSavedFragmentState.getInt(\n FragmentManagerImpl.TARGET_REQUEST_CODE_STATE_TAG, 0);\n }\n f.mUserVisibleHint = f.mSavedFragmentState.getBoolean(\n FragmentManagerImpl.USER_VISIBLE_HINT_TAG, true);\n if (!f.mUserVisibleHint) {\n f.mDeferStart = true;\n if (newState > Fragment.STOPPED) {\n newState = Fragment.STOPPED;\n }\n }\n }\n// ...\n}\n```\n\n如果你曾经需要解决应用旋转后产生一个与旋转前 UI 相同（方向发生变化）的独立的 Fragment 的需求，我想你应该懂我在说什么。（别给我提嵌套使用的 Fragment！）\n\n我想下面这张图很好地诠释了这类代码给程序员带来的伤害（由于版权问题我得放出这张图的出处哈：[this cartoon](http://www.osnews.com/story/19266/WTFs_m)）：\n\n![](https://corner.squareup.com/images/no-fragments/code-quality.png)\n\n在多年的深度分析中我得出结论：操蛋程度/调试耗费的时间 = 2^m，m 为 Fragment 的个数。\n\n##Fragment 是视图控制器？想太多\n\n因为 Fragment 需要创建、绑定和配置 View，它们包含了许多与 View 关联的结点，这就意味着 View 类代码中的业务逻辑并没有真正地被解耦，正是这个原因使得我们要为 Fragment 实现测试单元将会变得很困难。\n\n##Fragment transactions\n\nFragment 的 transaction 允许你执行一系列的 Fragment 操作，但不幸的是，提交 transaction 是异步操作，并且在 UI 线程的 Handler 队列的队尾被提交。这会在接收多个点击事件或配置发生改变时让你的 App 处在未知的状态。\n\n```java\nclass BackStackRecord extends FragmentTransaction {\n int commitInternal(boolean allowStateLoss) {\n if (mCommitted)\n throw new IllegalStateException(\"commit already called\");\n mCommitted = true;\n if (mAddToBackStack) {\n mIndex = mManager.allocBackStackIndex(this);\n } else {\n mIndex = -1;\n }\n mManager.enqueueAction(this, allowStateLoss);\n return mIndex;\n }\n}\n```\n\n##创建 Fragment 可能带来的问题\n\nFragment 的实例能够通过 Fragment Manager 创建，例如下面的代码看起来没有什么问题：\n\n```java\nDialogFragment dialogFragment = new DialogFragment() {\n @Override public Dialog onCreateDialog(Bundle savedInstanceState) { ... }\n};\ndialogFragment.show(fragmentManager, tag);\n```\n\n然而，当我们需要存储 Activity 实例的状态时，Fragment Manager 可能会通过反射机制重新创建该 Fragment 的实例，又因为这是一个匿名内部类，该类有一个隐藏的构造器的参数正是外部类的引用，如果大家有看过[这篇博文](http://blog.csdn.net/u012403246/article/details/45666369)的话就会知道，拥有外部引用可能会带来内存泄漏的问题。\n\n```java\nandroid.support.v4.app.Fragment$InstantiationException:\n Unable to instantiate fragment com.squareup.MyActivity$1:\n make sure class name exists, is public, and has an empty\n constructor that is public\n```\n\n##Fragment 教给我们的思想\n\n尽管 Fragment 有着上面提到的缺点，但也是 Fragment 教给我们许多代码架构的思想：\n\n- 独立的 Activity 接口：实际上我们并不需要为每一个页面创建一个 Activity，我们大可以将应用切分成许多解耦的视图组件，按照我们的实际需求把它们组装成我们想要的界面。这样做也能简化生命周期和动画设置，因为我们还能将视图组件切分为 view 组件和控制器组件。\n\n- 回退栈不是 Activity 的特有概念，也就意味着你能在 Activity 内部实现回退栈。\n\n- 不需要添加新的 API，我们需要的只是 Activity，View 和 LayoutInflater。\n\n#响应式 UI：Fragment VS Custom View\n\n##Fragment\n\n我们不妨先来看看一个 Fragment 的[范例](http://developer.android.com/shareables/training/FragmentBasics.zip)，界面中显示了一个 list。\n\nHeadlinesFragment 就是显示 List 的简单 Fragment：\n\n```java\npublic class HeadlinesFragment extends ListFragment {\n OnHeadlineSelectedListener mCallback;\n\n public interface OnHeadlineSelectedListener {\n void onArticleSelected(int position);\n }\n\n @Override\n public void onCreate(Bundle savedInstanceState) {\n super.onCreate(savedInstanceState);\n setListAdapter(\n new ArrayAdapter(getActivity(),\n R.layout.fragment_list,\n Ipsum.Headlines));\n }\n\n @Override\n public void onAttach(Activity activity) {\n super.onAttach(activity);\n mCallback = (OnHeadlineSelectedListener) activity;\n }\n\n @Override\n public void onListItemClick(ListView l, View v, int position, long id) {\n mCallback.onArticleSelected(position);\n getListView().setItemChecked(position, true);\n }\n}\n```\n\n现在有趣的事情来了：ListFragmentActivity 必须控制 list 是否处于同一个页面中。\n\n```java\npublic class ListFragmentActivity extends Activity\n implements HeadlinesFragment.OnHeadlineSelectedListener {\n @Override\n public void onCreate(Bundle savedInstanceState) {\n super.onCreate(savedInstanceState);\n setContentView(R.layout.news_articles);\n if (findViewById(R.id.fragment_container) != null) {\n if (savedInstanceState != null) {\n return;\n }\n HeadlinesFragment firstFragment = new HeadlinesFragment();\n firstFragment.setArguments(getIntent().getExtras());\n getFragmentManager()\n .beginTransaction()\n .add(R.id.fragment_container, firstFragment)\n .commit();\n }\n }\n public void onArticleSelected(int position) {\n ArticleFragment articleFrag =\n (ArticleFragment) getFragmentManager()\n .findFragmentById(R.id.article_fragment);\n if (articleFrag != null) {\n articleFrag.updateArticleView(position);\n } else {\n ArticleFragment newFragment = new ArticleFragment();\n Bundle args = new Bundle();\n args.putInt(ArticleFragment.ARG_POSITION, position);\n newFragment.setArguments(args);\n getFragmentManager()\n .beginTransaction()\n .replace(R.id.fragment_container, newFragment)\n .addToBackStack(null)\n .commit();\n }\n }\n}\n```\n\n##自定义 View\n\n我们不妨重新实现一个简化版的只使用了 View 的代码\n\n首先，我们会引入一个叫作“容器”的概念，“容器”的作用是帮助我们展示一项内容并处理后退操作\n\n```java\npublic interface Container {\n void showItem(String item);\n\n boolean onBackPressed();\n}\n```\n\nAcitivity 将假设始终存在容器，并且几乎不会将业务交给容器处理。\n\n```java\npublic class MainActivity extends Activity {\n private Container container;\n\n @Override protected void onCreate(Bundle savedInstanceState) {\n super.onCreate(savedInstanceState);\n setContentView(R.layout.main_activity);\n container = (Container) findViewById(R.id.container);\n }\n\n public Container getContainer() {\n return container;\n }\n\n @Override public void onBackPressed() {\n boolean handled = container.onBackPressed();\n if (!handled) {\n finish();\n }\n }\n}\n```\n\n要显示的 List 也只是个平凡的 List。\n\n```java\npublic class ItemListView extends ListView {\n public ItemListView(Context context, AttributeSet attrs) {\n super(context, attrs);\n }\n\n @Override protected void onFinishInflate() {\n super.onFinishInflate();\n final MyListAdapter adapter = new MyListAdapter();\n setAdapter(adapter);\n setOnItemClickListener(new OnItemClickListener() {\n @Override public void onItemClick(AdapterView parent, View view,\n int position, long id) {\n String item = adapter.getItem(position);\n MainActivity activity = (MainActivity) getContext();\n Container container = activity.getContainer();\n container.showItem(item);\n }\n });\n }\n}\n```\n\n这样做的好处是：能够基于资源文件夹在不同的 XML 布局文件\n\n`res/layout/main_activity.xml`\n\n```xml\n\n \n\n```\n\n`res/layout-land/main_activity.xml`\n\n```xml\n\n \n \n\n```\n\n下面是这些容器类的简单实现：\n\n```java\npublic class DualPaneContainer extends LinearLayout implements Container {\n private MyDetailView detailView;\n\n public DualPaneContainer(Context context, AttributeSet attrs) {\n super(context, attrs);\n }\n\n @Override protected void onFinishInflate() {\n super.onFinishInflate();\n detailView = (MyDetailView) getChildAt(1);\n }\n\n public boolean onBackPressed() {\n return false;\n }\n\n @Override public void showItem(String item) {\n detailView.setItem(item);\n }\n}\n```\n\n```java\npublic class SinglePaneContainer extends FrameLayout implements Container {\n private ItemListView listView;\n\n public SinglePaneContainer(Context context, AttributeSet attrs) {\n super(context, attrs);\n }\n\n @Override protected void onFinishInflate() {\n super.onFinishInflate();\n listView = (ItemListView) getChildAt(0);\n }\n\n public boolean onBackPressed() {\n if (!listViewAttached()) {\n removeViewAt(0);\n addView(listView);\n return true;\n }\n return false;\n }\n\n @Override public void showItem(String item) {\n if (listViewAttached()) {\n removeViewAt(0);\n View.inflate(getContext(), R.layout.detail, this);\n }\n MyDetailView detailView = (MyDetailView) getChildAt(0);\n detailView.setItem(item);\n }\n\n private boolean listViewAttached() {\n return listView.getParent() != null;\n }\n}\n```\n\n不难想象：将容器类抽象，并用这种的方式开发 App，不但不需要 Fragment，还能架构出容易理解的代码。\n\n##View 和 Presenter\n\n自定义 View 在应用中非常有用，但我们希望将业务逻辑从 View 中剥离，转交给特定的控制器处理，也就是接下来我们所说的 Presenter，引入 Presenter 能提高代码的可读性和可测试性。如果你不信的话，不妨看看重构后的 MyDetailView：\n\n```java\npublic class MyDetailView extends LinearLayout {\n TextView textView;\n DetailPresenter presenter;\n\n public MyDetailView(Context context, AttributeSet attrs) {\n super(context, attrs);\n presenter = new DetailPresenter();\n }\n\n @Override protected void onFinishInflate() {\n super.onFinishInflate();\n presenter.setView(this);\n textView = (TextView) findViewById(R.id.text);\n findViewById(R.id.button).setOnClickListener(new OnClickListener() {\n @Override public void onClick(View v) {\n presenter.buttonClicked();\n }\n });\n }\n\n public void setItem(String item) {\n textView.setText(item);\n }\n}\n```\n\n我们来看看 Square 注册界面中编辑账户的页面吧！\n\n![](https://corner.squareup.com/images/no-fragments/edit-discounts.png)\n\nPresenter 将在更高层级中操控 View：\n\n```java\nclass EditDiscountPresenter {\n // ...\n public void saveDiscount() {\n EditDiscountView view = getView();\n String name = view.getName();\n if (isBlank(name)) {\n view.showNameRequiredWarning();\n return;\n }\n if (isNewDiscount()) {\n createNewDiscountAsync(name, view.getAmount(), view.isPercentage());\n } else {\n updateNewDiscountAsync(discountId, name, view.getAmount(),\n view.isPercentage());\n }\n close();\n }\n}\n```\n\n大家可以看到，为这个 Presenter 实现测试单元犹如一缕春风拂面来，甚是舒心爽快呐～\n\n```java\n@Test public void cannot_save_discount_with_empty_name() {\n startEditingLoadedPercentageDiscount();\n when(view.getName()).thenReturn(\"\");\n presenter.saveDiscount();\n verify(view).showNameRequiredWarning();\n assertThat(isSavingInBackground()).isFalse();\n}\n```\n\n##回退栈管理\n\n通过异步处理来管理回退栈实在是牛刀杀鸡，大材小用了……我们只需要用一个超轻量级库——Flow，就可以达到目的。有关 Flow 的介绍 Ray Ryan 已经写过博客了，我就不在此赘述啦。\n\n##我把 UI 相关的代码全都写在 Fragment 里了咋办呀，在线等，急！！！\n\n别理你的 Fragment，你就一点一点地把 View 相关的代码移到自定义 View 里，然后把涉及到的业务逻辑交给能够与 View 进行交互的 Presenter，然后你就会发现 Fragment 沦为空壳，只有一些初始化自定义 View 和连接 View 和 Presenter 的操作：\n\n```java\npublic class DetailFragment extends Fragment {\n @Override public View onCreateView(LayoutInflater inflater,\n ViewGroup container, Bundle savedInstanceState) {\n return inflater.inflate(R.layout.my_detail_view, container, false);\n }\n}\n```\n\n事实上到了这一步你已经可以抛弃 Fragment 了。\n\n抛弃 Fragment 确实得花很大的功夫，但我们已经做到了，感谢[ Dimitris Koutsogiorgas ](https://twitter.com/dnkoutso)和[ Ray Ryan ](https://twitter.com/rjrjr)的伟大贡献！\n\n##Dagger 和 Mortar 是什么？\n\nDagger & Mortar 与 Fragment 成正交关系，换句话说，两者间各自的变化不会影响对方，使用 Dagger & Mortar 既可以用 Fragment，也可以不用 Fragment。\n\n[Dagger](http://square.github.io/dagger/) 能帮你将应用模块化为一张由解耦组件构成的图，它考虑了所有类间的连接关系并简化了抽取依赖的操作，并实现一个与此相关的单例对象。\n\n[Mortar](https://github.com/square/mortar) 在 Dagger 的顶层进行操作，主要优势有如下两点：\n\n- Mortar 为被注入组件提供简单的生命周期回调，使你能实现不会因旋转被销毁的单例 Presenter，不过需要注意的是，Mortar 将当前界面元素的状态储存在 Bundle 中，使数据不会随进程的结束而被清除。\n\n- Mortar 为你管理 Dagger 的子图，并帮你将它们与 Activity 的生命周期关联在一起，这种功能让你能有效地实现“域”：当一个 View 被添加进来，它的 Presenter 和依赖都会作为子图被创建；当 View 被移除，你能轻易地销毁“域”，并让垃圾回收机制去完成它的工作。\n\n##结论\n\n我们曾为 Fragment 的诞生满心欢喜，幻想着 Fragment 能为我们带来种种便利，然而这一切不过是场虚空大梦，我们最后发现骑着白马的 Fragment 既不是王子也不是唐僧，只不过是人品爆发捡了只白马的乞丐罢了：\n\n- 我们遇到的大多数难以解决的 Bug 都与 Fragment 的生命周期有关。\n\n- 我们只需要 View 创建响应式 UI，实现回退栈以及屏幕事件的处理，不用 Fragment 也能满足实际开发的需求。" }, { "path": "issue-13/readme.md", "content": "# 2015.6.5 ( 第十三期 )\n| 文章名称 | 译者 | \n|---------|--------|\n| [Square：从今天开始抛弃Fragment吧！](Square：从今天开始抛弃Fragment吧！.md) | [chaossss](https://github.com/chaossss) |\n| [Android进行单元测试难在哪-终](Android进行单元测试难在哪-终.md) | [chaossss](https://github.com/chaossss)|\n| [优化android-studio编译效率的方法](优化android-studio编译效率的方法.md) | [FTExplore](https://github.com/FTExplore) |\n| [创建 RecyclerView LayoutManager – Part 2](创建-RecyclerView-LayoutManager-Part-2.md) | [tiiime](https://github.com/tiiime)|\n| [创建-RecyclerView-LayoutManager-Part-3](创建-RecyclerView-LayoutManager-Part-3.md) | [tiiime](https://github.com/tiiime) |\n| [创建-RecyclerView-LayoutManager-Redux](创建-RecyclerView-LayoutManager-Redux.md) | [Mr.Simple](https://github.com/bboyfeiyu) |\n" }, { "path": "issue-13/优化android-studio编译效率的方法.md", "content": "优化android studio编译效率的方法\n---\n\n> * 原文链接 : [Boosting the performance for Gradle in your Android projects](https://medium.com/@erikhellman/boosting-the-performance-for-gradle-in-your-android-projects-6d5f9e4580b6)\n* 原文作者 : [Erik Hellman](https://medium.com/@erikhellman)\n* [译文出自 : 开发技术前线 www.devtf.cn](http://www.devtf.cn)\n* 译者 : [FTExplore](https://github.com/FTExplore) \n\n## 引言\n\n如果你之前用eclipse开发过Android app的化,转到android studio的第一反应也许就是:\"编译速度有点慢\". 表现的最明显的一点就是,当我使用eclipse开发的时候,选中了auto building.这个时候\n我更改了几个字符,eclipse会速度非常快的编译出一个新的apk. 而android studio使用gradle编译,每次编译,即便是更改的代码量很少,也会按照预先设置的task的顺序,依次走完编译的各项流程.所以\n这点就让人很痛苦. 然而问题总还是要被解决的,作者曾经亲眼看到过使用android studio仅仅用了2.5秒就编译完毕(在代码更改很少的情况下). 现在把如何优化gradle编译速度的方法记录在此,希望可以\n帮助到广大的同行们.\n\n## 准备工作\n\ngradle现在最新的版本是2.4, 相比较之前的版本, 在编译效率上面有了一个非常大的提高,为了确保你的android项目使用的是最新版的gradle版本,有两种方法可以使用,下面依次进行介绍\n\n### 1、在build.gradle中进行设置\n\n在你的项目gradle文件内(不是app里面的gradle文件), 添加一个task, 代码如下:\n\n```java\ntask wrapper(type: Wrapper) {\n gradleVersion = '2.4'\n}\n```\n\n然后打开terminal, 输入./gradlew wrapper, 然后gradle就会自动去下载2.4版本,这也是官方推荐的手动设置gradle的方法(http://gradle.org/docs/current/userguide/gradle_wrapper.html)\n\n### 2、使用android studio对gradle版本进行设置\n\n这种方法需要你去手动去gradle官网下载一个zip包,解压缩后,打开android studio 设置界面的Project Structure. 然后手动添加你解压缩后的gradle的磁盘路径即可,可以参考如下的图片\n\n![image](http://img.blog.csdn.net/20150604104904903)\n\n有一点需要注意的是,这种设置方法仅适用于在你的项目中使用gradle wrapper进行编译打包的操作(就是android studio默认需要的东东).如果你想使用gradle做其他的事情,请出门左转,去gradle官网(http://gradle.org)\n\n## 守护进程,并行编译\n\n通过以上步骤,我们设置好了android studio使用最新的gradle版本,下一步就是正式开启优化之路了. 我们需要将gradle作为守护进程一直在后台运行,这样当我们需要编译的时候,gradle就会立即跑过来然后\n吭哧吭哧的开始干活.除了设置gradle一直开启之外,当你的工作空间存在多个project的时候,还需要设置gradle对这些projects并行编译,而不是单线的依次进行编译操作.\n\n说了那么多, 那么怎么设置守护进程和并行编译呢?其实非常简单,gradle本身已经有了相关的配置选项,在你电脑的GRADLE_HOME这个环境变量所指的那个文件夹内,有一个`.gradle/gradle.properties`文件.\n在这个文件里,放入下面两句话就OK了:\n\n```\norg.gradle.daemon=true\norg.gradle.parallel=true\n```\n\n有一个地方需要注意的是,android studio 本身在编译的时候,已经是使用守护进程中的gradle了,那么这里加上了org.gradle.daemon=true就是保证了你在使用命令行编译apk的时候也是使用的守护进程.\n\n你也可以将上述的配置文件放到你project中的根目录下,以绝对确保在任何情况下,这个project都会使用守护进程进行编译.不过有些特殊的情况下也许你应该注意守护进程的使用,具体的细节参考http://gradle.org/docs/current/userguide/gradle_daemon.html#when_should_i_not_use_the_gradle_daemon\n\n在使用并行编译的时候必须要注意的就是,你的各个project之间不要有依赖关系,否则的话,很可能因为你的Project A 依赖Project B, 而Project B还没有编译出来的时候,gradle就开始编译Project A 了.最终\n导致编译失败.具体可以参考http://gradle.org/docs/current/userguide/multi_project_builds.html#sec:decoupled_projects。\n \n还有一些额外的gradle设置也许会引起你的兴趣,例如你想增加堆内存的空间,或者指定使用哪个jvm虚拟机等等(代码如下) \n\norg.gradle.jvmargs=-Xmx768m \norg.gradle.java.home=/path/to/jvm\n\n如果你想详细的了解gradle的配置,请猛戳http://gradle.org/docs/current/userguide/userguide_single.html#sec:gradle_configuration_properties\n\n## 一个实验性的功能\n\n最后一个要介绍的是incremental dexing, 这个功能目前还在试验阶段,android studio默认是关闭的, 作者个人是非常推荐的,程序员就是爱折腾啊.\n\n开启incremental dexing也是非常简单的,就是在app级别的buid.gradle文件中加入下面的代码:\n\n```\ndexOptions {\n incremental true\n}\n```\n\n感性您的阅读,希望这边文章可以对您有所帮助. 如果您有好的建议或者意见请联系我\n\n" }, { "path": "issue-13/创建-RecyclerView-LayoutManager-Part-2.md", "content": "创建 RecyclerView LayoutManager – Part 2\n---\n\n> * 原文链接 : [Building a RecyclerView LayoutManager – Part 2][part2]\n> * 原文作者 : [Dave Smith][author]\n* [译文出自 : 开发技术前线 www.devtf.cn](http://www.devtf.cn)\n* 译者 : [tiiime](https://github.com/tiiime) \n* 校对者:[chaossss](https://github.com/chaossss) \n* 状态 : 完成 \n\n\n# 创建 a RecyclerView LayoutManager – Part 2\n\n>本文是这个系列中的 Part 2，这里是 [Part 1][part1] 和 [Part 3][part3] 的链接。\n\n上次我们讲了创建一个 RecyclerView LayoutManager 的核心步骤。接下来，\n我们会介绍如何给普通基于适配器的 View 加入一些附加特性。\n\n>友情提醒：示例中的代码在这里 [Github][sample-github]\n\n---\n\n#Item Decorations 支持\n\nRecyclerView 有一个很好的特性 `RecyclerView.ItemDecoration`，它可以给\n子视图添加自定义样式，还可以在不修改子视图布局参数的情况下插入\n布局属性(margins)。后者就是 LayoutManager 必须提供的约束子视图布局方式。\n\n---\n\n\n>[RecyclerPlayground ][sample-github] 里有几个 decorator 用来介绍它们的实现方式。\n\nLayoutManager 中提供了一些辅助方法操作 decorations ，不需要我们自己实现：\n\n- 用`getDecoratedLeft()`代替`child.getLeft()`获取子视图的 left 边缘。\n- 用`getDecoratedTop()`代替`getTop()`获取子视图的 top 边缘。\n- 用`getDecoratedRight()`代替`getRight()`获取子视图的 right 边缘。\n- 用`getDecoratedBottom()`代替`getBottom()`获取子视图的 bottom 边缘。\n- 使用 `measureChild() ` 或 `measureChildWithMargins()` 代替`child.measure()` \n\t测量来自 Recycler 的新视图。\n- 使用`layoutDecorated() `代替 `child.layout()` 布局来自 Recycler 的新视图。\n- 使用 `getDecoratedMeasuredWidth() `或 `getDecoratedMeasuredHeight()`\n\t代替 `child.getMeasuredWidth()`或` child.getMeasuredHeight()`获取\n\t子视图的测量数据。\n\n只要你使用了正确的方法去获取视图的属性和测量数据，RecyclerView 会自己搞定细节部分的处理。\n\n---\n\n#数据集改变\n\n当使用 `notifyDataSetChanged()`触发 `RecyclerView.Adapter` 的更新操作时，\nLayoutManager 负责更新布局中的视图。这时，`onLayoutChildren()`会被再次调用。\n实现这个功能需要我们调整代码，判断出当前状态是生成一个新的视图 还是 adapter \n更新期间的视图改变。下面是`FixedGridLayoutManager`中的填充方法的完整实现：\n\n```java\n@Override\npublic void onLayoutChildren(RecyclerView.Recycler recycler, RecyclerView.State state) {\n //We have nothing to show for an empty data set but clear any existing views\n if (getItemCount() == 0) {\n detachAndScrapAttachedViews(recycler);\n return;\n }\n\n //...on empty layout, update child size measurements\n if (getChildCount() == 0) {\n //Scrap measure one child\n View scrap = recycler.getViewForPosition(0);\n addView(scrap);\n measureChildWithMargins(scrap, 0, 0);\n\n /*\n * We make some assumptions in this code based on every child\n * view being the same size (i.e. a uniform grid). This allows\n * us to compute the following values up front because they\n * won't change.\n */\n mDecoratedChildWidth = getDecoratedMeasuredWidth(scrap);\n mDecoratedChildHeight = getDecoratedMeasuredHeight(scrap);\n\n detachAndScrapView(scrap, recycler);\n }\n\n updateWindowSizing();\n\n int childLeft;\n int childTop;\n if (getChildCount() == 0) { //First or empty layout\n /*\n * Reset the visible and scroll positions\n */\n mFirstVisiblePosition = 0;\n childLeft = childTop = 0;\n } else if (getVisibleChildCount() > getItemCount()) {\n //Data set is too small to scroll fully, just reset position\n mFirstVisiblePosition = 0;\n childLeft = childTop = 0;\n } else { //Adapter data set changes\n /*\n * Keep the existing initial position, and save off\n * the current scrolled offset.\n */\n final View topChild = getChildAt(0);\n if (mForceClearOffsets) {\n childLeft = childTop = 0;\n mForceClearOffsets = false;\n } else {\n childLeft = getDecoratedLeft(topChild);\n childTop = getDecoratedTop(topChild);\n }\n\n /*\n * Adjust the visible position if out of bounds in the\n * new layout. This occurs when the new item count in an adapter\n * is much smaller than it was before, and you are scrolled to\n * a location where no items would exist.\n */\n int lastVisiblePosition = positionOfIndex(getVisibleChildCount() - 1);\n if (lastVisiblePosition >= getItemCount()) {\n lastVisiblePosition = (getItemCount() - 1);\n int lastColumn = mVisibleColumnCount - 1;\n int lastRow = mVisibleRowCount - 1;\n\n //Adjust to align the last position in the bottom-right\n mFirstVisiblePosition = Math.max(\n lastVisiblePosition - lastColumn - (lastRow * getTotalColumnCount()), 0);\n\n childLeft = getHorizontalSpace() - (mDecoratedChildWidth * mVisibleColumnCount);\n childTop = getVerticalSpace() - (mDecoratedChildHeight * mVisibleRowCount);\n\n //Correct cases where shifting to the bottom-right overscrolls the top-left\n // This happens on data sets too small to scroll in a direction.\n if (getFirstVisibleRow() == 0) {\n childTop = Math.min(childTop, 0);\n }\n if (getFirstVisibleColumn() == 0) {\n childLeft = Math.min(childLeft, 0);\n }\n }\n }\n\n //Clear all attached views into the recycle bin\n detachAndScrapAttachedViews(recycler);\n\n //Fill the grid for the initial layout of views\n fillGrid(DIRECTION_NONE, childLeft, childTop, recycler);\n}\n```\n\n---\n\n我们根据有没有已经被 attach 的子视图来判断当前是一个新的布局还是一个更新操作。\n如果是更新，我们根据第一个可见视图的 position（通过监测视图左上角是哪个子视图）\n和当前 x/y 滑动的位移这些信息去执行新的 `fillGrid()`，同时保证左上角的 item 位置不变。\n\n---\n\n下面是一些需要特殊处理得情况：\n\n- 当新的数据集很小，不足以滑动时，布局会将左上角重置为 position 是 0 的item。\n- 如果新的数据集很小，保持当前位置会使滚动超出边界。\n\t我们就应该调整第一个 item 的位置，以便和右下角对齐。\n\t\n---\n\n###onAdapterChanged()\n\n这个方法提供了另一个重置布局的场所，设置新的 adapter 会触发这个事件\n(在这，`setAdapter`会被再次调用)。\n这个阶段你可以安全的返回一个与之前 adapter 完全不同的视图。所以，\n示例中我们移除了所有当前视图(并没有回收它们)。\n\n```java\n@Override\npublic void onAdapterChanged(RecyclerView.Adapter oldAdapter, RecyclerView.Adapter newAdapter) {\n //Completely scrap the existing layout\n removeAllViews();\n}\n```\n\n移除视图会触发一个新的布局过程，当 `onLayoutChildren()` 被再次调用时，\n我们的代码会执行创建新视图的布局过程，因为现在没有 attched 的子视图。\n\n---\n\n#Scroll to Position\n另一个重要的特性就是给 LayoutManager 添加滚动到特定位置的功能。\n可以带有有动画效果，也可以没有，下面是对应的两个回调方法。\n\n###scrollToPosition()\n\n当 layout 应该立即将所给位置设为第一个可见 item 时，调用 RecyclerView 的 `scrollToPosition()`。\n在一个 vertical list 里，item 应该放在顶部；horizontal list 中，通常放在左边。在我们的\n网格布局中，被选中的 item 应该放在视图的左上角。\n\n```java\n@Override\npublic void scrollToPosition(int position) {\n if (position >= getItemCount()) {\n Log.e(TAG, \"Cannot scroll to \"+position+\", item count is \"+getItemCount());\n return;\n }\n\n //Ignore current scroll offset, snap to top-left\n mForceClearOffsets = true;\n //Set requested position as first visible\n mFirstVisiblePosition = position;\n //Trigger a new view layout\n requestLayout();\n}\n```\n\n因为有一个良好的 `onLayoutChildren()` 实现，这里就可以简单的更新目标位置并触发一个\n新的 fill 操作。\n\n---\n\n###smoothScrollToPosition()\n\n在带有动画的情况下，我们需要使用一些稍微不同的方法。\n在这方法里我们需要创建一个 `RecyclerView.SmoothScroller`实例，\n然后在方法返回前请求`startSmoothScroll()`启动动画。\n\n`RecyclerView.SmoothScroller` 是提供 API 的抽象类，含有四个方法：\n\n---\n\n- `onStart()`：当滑动动画开始时被触发。\n- `onStop()`：当滑动动画停止时被触发。\n- `onSeekTargetStep()`：当 scroller 搜索目标 view 时被重复调用，这个方法负责读取提供的 \n\tdx/dy ，然后更新应该在这两个方向移动的距离。\n\t- 这个方法有一个`RecyclerView.SmoothScroller.Action`实例做参数。\n\t\t通过向 action 的 `update()`方法传递新的 dx, dy, duration 和 `Interpolator` ，\n\t\t告诉 view 在下一个阶段应该执行怎样的动画。\n\t- **NOTE：** 如果动画耗时过长，框架会对你发出警告，\n\t\t\t应该调整动画的步骤，尽量和框架标准的动画耗时相同。\n- `onTargetFound()`：只在目标视图被 attach 后调用一次。\t这是将目标视图要通过动画移动到准确位置最后的场所。\n\t- 在内部，当 view 被 attach 时使用 LayoutManager 的 `findViewByPosition()` 方法\n\t\t查找对象。如果你的 LayoutManager 可以有效匹配 view 和 position ，\n\t\t可以覆写这个方法来优化性能。默认提供的实现是通过每次遍历所有子视图查找。\n\n---\n\n你可以自己实现一个 scroller 达到你想要的效果。不过这里我们只使用系统提供的\n`LinearSmoothScroller` 就好了。只需实现一个方法`computeScrollVectorForPosition()`，\n然后告诉 scroller 初始方向还有从当前位置滚动到目标位置的大概距离。\n\n---\n```java\n@Override\npublic void smoothScrollToPosition(RecyclerView recyclerView, RecyclerView.State state, final int position) {\n if (position >= getItemCount()) {\n Log.e(TAG, \"Cannot scroll to \"+position+\", item count is \"+getItemCount());\n return;\n }\n\n /*\n * LinearSmoothScroller's default behavior is to scroll the contents until\n * the child is fully visible. It will snap to the top-left or bottom-right\n * of the parent depending on whether the direction of travel was positive\n * or negative.\n */\n LinearSmoothScroller scroller = new LinearSmoothScroller(recyclerView.getContext()) {\n /*\n * LinearSmoothScroller, at a minimum, just need to know the vector\n * (x/y distance) to travel in order to get from the current positioning\n * to the target.\n */\n @Override\n public PointF computeScrollVectorForPosition(int targetPosition) {\n final int rowOffset = getGlobalRowOfPosition(targetPosition)\n - getGlobalRowOfPosition(mFirstVisiblePosition);\n final int columnOffset = getGlobalColumnOfPosition(targetPosition)\n - getGlobalColumnOfPosition(mFirstVisiblePosition);\n\n return new PointF(columnOffset * mDecoratedChildWidth, rowOffset * mDecoratedChildHeight);\n }\n };\n scroller.setTargetPosition(position);\n startSmoothScroll(scroller);\n}\n```\n\n---\n\n在这个实现中，和现有 ListView 的行为相似，无论是 RecyclerView 的哪个方向滚动，\n当视图完全可见时滚动就会停止。\n\n\n\n---\n\n#接下来？\n\n我们现在已经有些起色了！事实上还有很多可以实现的功能。在[下篇文章][part3]中，我们会介绍\n如何给你的 LayoutManager 提供数据集改变时的动画效果。\n\n\n---\n\n[part1]:../issue-9/创建-RecyclerView-LayoutManager-Part-1.md\n[author]:http://wiresareobsolete.com/\n[part2]:http://wiresareobsolete.com/2014/09/recyclerview-layoutmanager-2/\n[part3]:./创建-RecyclerView-LayoutManager-Part-3.md\n[sample-github]:https://github.com/devunwired/recyclerview-playground\n" }, { "path": "issue-13/创建-RecyclerView-LayoutManager-Part-3.md", "content": "创建 RecyclerView LayoutManager – Part 3\n---\n\n> * 原文链接 : [Building a RecyclerView LayoutManager – Part 3][part3]\n> * 原文作者 : [Dave Smith][author]\n* [译文出自 : 开发技术前线 www.devtf.cn](http://www.devtf.cn)\n* 译者 : [tiiime](https://github.com/tiiime) \n* 校对者:[chaossss](https://github.com/chaossss) \n* 状态 : 完成 \n\n\n# Building a RecyclerView LayoutManager – Part 3\n\n\n>本文是这个系列中的 Part 3，这里是 [Part 1][part1] 和 [Part 2][part2] 的链接。\n\n在[之前的文章][part2]里，我们讨论了怎样对数据集改变和定量滚动\n提供正确的支持。接下来我们会介绍怎样给 LayoutManager 添加\n合适的动画效果。\n\n>友情提醒：示例中的代码在这里 [Github][sample-github]\n\n---\n\n#The Problem With Free\n\n上次我们说到了 `notifyDataSetChanged()` ，但是使用这个方法\n不会有数据改变的动画效果(1)。\nRecyclerView 提供了新的 API 让我们可以通知 adapter \n做出带有动画效果的改变。它们是：\n\n- `notifyItemInserted()` 和 `notifyItemRangeInserted()`：\n\t在给定位置/范围插入新item(s)。\n- `notifyItemChanged()` 和 `notifyItemRangeChanged()`：\n\t使给定 位置/范围 的 item(s) 无效，数据集并没有结构上的改变。\n- `notifyItemRemoved()` 和 `notifyItemRangeRemoved()`：\n\t移除给定 位置/范围 的 item(s)。\n- `notifyItemMoved()`：\n\t将数据集中的一个 item 重定位到一个新的位置。\n\n\n使用这些方法你的 LayoutManager 会得到一个很简单的默认 item 动画。\n这些动画是根据当前每一个 view 在改变后是否还存在于 layout 之中生成的。\n新的 view 渐入，被移除的 view 淡出，其他 view 移动到新的位置。\n下面是我们 grid layout 示例的动画效果：\n\n![img][animate-01]\n \n不过这里有个问题，一些没有被移除的 item 也淡出了。\n这是因为它们在父控件 RecyclerView 的边界中不再可见。\n我们想要这些 view 朝着用户期望的方向滑去，但是框架只知道\n我们的代码在数据改变后没有显示出这些 item。此外，\n新加入的 view 是淡入进来的，让他们从预定位置滑入界面会更好。\n\n我们要给 LayoutManager 加点东西才能实现这些。\n\n---\n\n#Predictive Item Animations\n\n下面的图片展示了我们期望的移除 item 动画效果：\n![img][animate-02]\n左侧一列 items 滑到右侧填补空白部分的动画很引人注意。\n和这个差不多，你可以脑补出在这个位置添加一个 item 时的动画效果。\n\n在第一篇文章里曾提到的，`onLayoutChildren()` 通常只会\n在父控件 `RecyclerView` 初始化布局 或者 数据集的大小(比如 item 的数量)改变时调用一次。\nPredictive Item Animations \n这个特性允许我们给 view (基于数据改变产生)的过渡动画\n提供更多有用的信息。想要使用这个特性，就要告诉\n框架我们的 `LayoutManager` 提供了这个附加数据：\n\n```java\n@Override\npublic boolean supportsPredictiveItemAnimations() {\n return true;\n}\n```\n\n有了这个改动，`onLayoutChildren() `会在每次数据集改变后被调用两次，\n一次是\"预布局\"(pre-layout)阶段，一次是真实布局(real layout)。\n\n---\n\n#在 pre-layout 阶段该做些什么\n\n在`onLayoutChildren()`的 pre-layout 阶段，\n你应该运行你的布局逻辑设置动画的**初始状态**。\n这需要你在动画执行前布局所有 当前可见的 view **和** 在动画后会可见的 view\n(被称为 **APPEARING** view)。Appearing views 应该被布局在\n屏幕之外，用户期望它进入的位置。框架会捕获他们的位置，\n籍此创建更合适的动画效果。\n\n>我们可以使用 `RecyclerView.State.isPreLayout()` 来检测当前处于哪一阶段\n\n在 `FixedGridLayoutManager` 示例中，我们根据数据集的改变\n使用 pre-layout 决定哪些 view 被移除。被移除的 view \n在 pre-layout 的 Recycler 中仍然会被返回，所以你不用担心\n会出现空白位置。如果你想要判断视图是否会被移除，\n可以使用`LayoutParams.isViewRemoved()` 这个方法 。\n我们的示例统计了被移除 view 的数量，让我们\n对有多少空间会被 appearing views 填充有一个大概的印象。\n\n---\n\n```java\n@Override\npublic void onLayoutChildren(RecyclerView.Recycler recycler, RecyclerView.State state) {\n …\n\n SparseIntArray removedCache = null;\n /*\n * During pre-layout, we need to take note of any views that are\n * being removed in order to handle predictive animations\n */\n if (state.isPreLayout()) {\n removedCache = new SparseIntArray(getChildCount());\n for (int i=0; i < getChildCount(); i++) {\n final View view = getChildAt(i);\n LayoutParams lp = (LayoutParams) view.getLayoutParams();\n\n if (lp.isItemRemoved()) {\n //Track these view removals as visible\n removedCache.put(lp.getViewPosition(), REMOVE_VISIBLE);\n }\n }\n …\n }\n\n …\n\n //Fill the grid for the initial layout of views\n fillGrid(DIRECTION_NONE, childLeft, childTop, recycler, state.isPreLayout(), removedCache);\n\n …\n}\n```\n\n>Tip：在 pre-layout 期间，RecyclerView 会尝试用 view\n>在 adapter 中的位置匹配它们的\"原位置\"(数据改变前的位置)。\n>如果你想通过 position 请求一个 view，并且希望这个位置\n>是这个视图初始化时的位置。就不要在 pre-layout 和\n>real-layout 期间改变它们。\n\n示例代码中最后的变动是对`fillGrid()`进行修改，在这里给 N \n个 appearing views 布局，N 是被移除的可见视图个数。\n这些 view 永远是从右侧进入的，所以他们被安排在最后一列\n可见 view 的后面。\n\n```java\nprivate void fillGrid(int direction, int emptyLeft, int emptyTop, RecyclerView.Recycler recycler,\n boolean preLayout, SparseIntArray removedPositions) {\n …\n\n for (int i = 0; i < getVisibleChildCount(); i++) {\n int nextPosition = positionOfIndex(i);\n\n …\n\n if (i % mVisibleColumnCount == (mVisibleColumnCount - 1)) {\n leftOffset = startLeftOffset;\n topOffset += mDecoratedChildHeight;\n\n //During pre-layout, on each column end, apply any additional appearing views\n if (preLayout) {\n layoutAppearingViews(recycler, view, nextPosition, removedPositions.size(), …);\n }\n } else {\n leftOffset += mDecoratedChildWidth;\n }\n }\n\n …\n}\n\nprivate void layoutAppearingViews(RecyclerView.Recycler recycler, View referenceView,\n int referencePosition, int extraCount, int offset) {\n //Nothing to do...\n if (extraCount < 1) return;\n\n for (int extra = 1; extra <= extraCount; extra++) {\n //Grab the next position after the reference\n final int extraPosition = referencePosition + extra;\n if (extraPosition < 0 || extraPosition >= getItemCount()) {\n //Can't do anything with this\n continue;\n }\n\n /*\n * Obtain additional position views that we expect to appear\n * as part of the animation.\n */\n View appearing = recycler.getViewForPosition(extraPosition);\n addView(appearing);\n\n //Find layout delta from reference position\n final int newRow = getGlobalRowOfPosition(extraPosition + offset);\n final int rowDelta = newRow - getGlobalRowOfPosition(referencePosition + offset);\n final int newCol = getGlobalColumnOfPosition(extraPosition + offset);\n final int colDelta = newCol - getGlobalColumnOfPosition(referencePosition + offset);\n\n layoutTempChildView(appearing, rowDelta, colDelta, referenceView);\n }\n}\n```\n\n在 `layoutAppearingViews()`这个方法里，每一个 appearing view\n被布局到它的\"全局\"位置(就是它在这个网格中占据的行/列)。\n虽然位置在屏幕之外，但是为框架创建滑入 view 动画的起始点提供了\n必要的数据。\n\n\n---\n\n#Changes for the “Real” Layout\n\n[part1][part1]中我们已经讨论过布局期间的基本工作，\n然而要想为我们的动画提供支持还要做一些修改。\n其中之一就是判断有没有 disappearing views。在我们的示例中\n是通过运行一个普通的布局过程，然后检查 Recycler\n的 scrap heap 之中有没有剩下的 view。\n\n\n>注意：我们之所以能以这种方式使用 scrap heap 是因为\n>在每一次布局过程开始前，布局逻辑总是调用了\n>`detachAndScrapAttachedViews()`这个方法。\n>前面说过，这是布局中你需要遵循的最佳实践。\n\n---\nViews still in scrap that aren’t considered removed are \ndisappearing views. We need to lay these views out in \ntheir off-screen positions so the animation system \ncan slide them out of view (instead of just fading them out).\n\n仍在 scrap 中没有被移除的视图就是 disappearing views。\n我们需要把它们放置到屏幕之外的位置，以便动画系统\n将它们滑出视图(用来取代淡出动画)。\n\n---\n\n```java\n@Override\npublic void onLayoutChildren(RecyclerView.Recycler recycler, RecyclerView.State state) {\n …\n\n if (!state.isPreLayout() && !recycler.getScrapList().isEmpty()) {\n final List scrapList = recycler.getScrapList();\n final HashSet disappearingViews = new HashSet(scrapList.size());\n\n for (RecyclerView.ViewHolder holder : scrapList) {\n final View child = holder.itemView;\n final LayoutParams lp = (LayoutParams) child.getLayoutParams();\n if (!lp.isItemRemoved()) {\n disappearingViews.add(child);\n }\n }\n\n for (View child : disappearingViews) {\n layoutDisappearingView(child);\n }\n }\n}\n\nprivate void layoutDisappearingView(View disappearingChild) {\n /*\n * LayoutManager has a special method for attaching views that\n * will only be around long enough to animate.\n */\n addDisappearingView(disappearingChild);\n\n //Adjust each disappearing view to its proper place\n final LayoutParams lp = (LayoutParams) disappearingChild.getLayoutParams();\n\n final int newRow = getGlobalRowOfPosition(lp.getViewPosition());\n final int rowDelta = newRow - lp.row;\n final int newCol = getGlobalColumnOfPosition(lp.getViewPosition());\n final int colDelta = newCol - lp.column;\n\n layoutTempChildView(disappearingChild, rowDelta, colDelta, disappearingChild);\n}\n```\n\n---\n\n>小心：布局视图(然后将它们加入container)把它们从 scrap 列表中移除。\n>在开始变化前，小心处理你需要从 scrap 中获取的视图，否则你可能会\n>在这个集合上出现并发修改的问题结束运行。\n\n\n和之前处理 appearing views 的代码差不多，`layoutDisappearingView()`\n将所有剩余 view 放在与之对应的\"全局\"位置作为最终布局位置。\n给框架提供必要信息创建出适当方向的滑出动画。\n\n下面的图片可以帮你理解`FixedGridLayoutManager`之中的过程：\n\n- 黑框是 `RecyclerView` 的可视边界。\n- Red View：数据集中被移除的 item。\n- Green View (Appearing View)：开始时没有，在 pre-layout 过程中被布局到屏幕外的item。\n- Purple Views (Disappearing views)：pre-layout 时期放置在他们的原始位置 ，\n\treal-layout 时期被布局到屏幕之外的位置。\n\n![img][animate-03]\n\n---\n\n\n#响应屏幕外的变动\n你或许注意到在上一节中我们可以判断可视 views 的移除操作。\n如果变化出现在可视边界之外会怎样？这取决于你的布局结构，\n像这样的变化可能需要你调整布局来达到更好的动画效果。\n\nAdapter 会将这个变化 post 给你的 LayoutManager。你可以覆写\n`onItemsRemoved()`, `onItemsMoved()`, `onItemsAdded()` 或者\n`onItemsChanged()` 响应 item 的这些事件，无论 item \n在当前布局中是否可见。\n\n如果被移除的范围在可视边界之外， 调用 pre-layout 之前会调用\n`onItemRemoved()`。我们可以利用它收集和这个变化有关的数据，为\n这个事件可能触发的 appearing view 改变提供更好的支持。\n\n示例中，我们像之前一样收集被移除的 view，但是将它们标记成不同的类型。\n\n---\n\n```java\n@Override\npublic void onItemsRemoved(RecyclerView recyclerView, int positionStart, int itemCount) {\n mFirstChangedPosition = positionStart;\n mChangedPositionCount = itemCount;\n}\n\n@Override\npublic void onLayoutChildren(RecyclerView.Recycler recycler, RecyclerView.State state) {\n …\n\n SparseIntArray removedCache = null;\n /*\n * During pre-layout, we need to take note of any views that are\n * being removed in order to handle predictive animations\n */\n if (state.isPreLayout()) {\n …\n\n //Track view removals that happened out of bounds (i.e. off-screen)\n if (removedCache.size() == 0 && mChangedPositionCount > 0) {\n for (int i = mFirstChangedPosition; i < (mFirstChangedPosition + mChangedPositionCount); i++) {\n removedCache.put(i, REMOVE_INVISIBLE);\n }\n }\n }\n\n …\n\n //Fill the grid for the initial layout of views\n fillGrid(DIRECTION_NONE, childLeft, childTop, recycler, state.isPreLayout(), removedCache);\n\n …\n}\n```\n\n---\n\n>TIP：如果被移除的 item 是可见的，这个方法在 pre-layout \n>之后还会被调用。这也就是为什么\n>当被移除的可见 views 出现时我们仍要从它们获取数据。\n\n所有步骤就位，现在我们可以启动这个应用啦。可以看到左边消失的items\n移到对应行的后面。右边新出现的 items 滑动进入现有的界面。\n现在，新的动画中只有被移除的 item 是淡出的了。\n\n![img][animate-04]\n\n---\n\n#未完待续...\n\n我说过...这应该是这系列中的最后一篇。不过，在编写 `FixedGridLayoutManager`\n动画效果的过程中又出现了些有趣的问题，并不是所有自定义的实现。\n所以在下一篇文章里(这次真的是最后一篇了)，我会解决这些问题。\n\n特别感谢 [Yiğit Boyar][thanks]提供技术支持，帮助完成这篇文章。\n\n---\n\n1. 如果你的 adapter 使用了固定的 IDs ，可以提供足够的数据推测哪些 view 被 移除/添加/等等\n\t框架就会尝试 给它添加动画\t↩\n\n---\n\n\n[part1]:../issue-9/创建-RecyclerView-LayoutManager-Part-1.md\n[author]:http://wiresareobsolete.com/\n[part2]:./创建-RecyclerView-LayoutManager-Part-2.md\n[part3]:http://wiresareobsolete.com/2015/02/recyclerview-layoutmanager-3/\n[sample-github]:https://github.com/devunwired/recyclerview-playground\n[animate-01]:http://i.embed.ly/1/display/resize?url=http%3A%2F%2Fwiresareobsolete.com%2Fwp-content%2Fuploads%2F2015%2F02%2FDefaultRecyclerAnimationsSmall.gif&grow=true&key=92b31102528511e1a2ec4040d3dc5c07\n[animate-02]:http://i.embed.ly/1/display/resize?url=http%3A%2F%2Fwiresareobsolete.com%2Fwp-content%2Fuploads%2F2015%2F02%2FRecycleConceptSmall.gif&grow=true&key=92b31102528511e1a2ec4040d3dc5c07&height=400\n[animate-03]:http://i.embed.ly/1/display/resize?url=http%3A%2F%2Fwiresareobsolete.com%2Fwp-content%2Fuploads%2F2015%2F02%2FRecycleRemove.gif&grow=true&key=92b31102528511e1a2ec4040d3dc5c07&height=400\n[animate-04]:http://i.embed.ly/1/display/resize?url=http%3A%2F%2Fwiresareobsolete.com%2Fwp-content%2Fuploads%2F2015%2F02%2FPredictiveRecyclerAnimationsSmall.gif&grow=true&key=92b31102528511e1a2ec4040d3dc5c07\n[thanks]:https://plus.google.com/111851968937104436377/posts\n" }, { "path": "issue-13/创建-RecyclerView-LayoutManager-Redux.md", "content": "创建-RecyclerView-LayoutManager-Redux\n---\n\n> * 原文链接 : [Building A RecyclerView LayoutManager – Redux](http://wiresareobsolete.com/2015/02/recyclerview-layoutmanager-redux/)\n* 原文作者 : [Dave Smith](http://wiresareobsolete.com/)\n* [译文出自 : 开发技术前线 www.devtf.cn](http://www.devtf.cn)\n* 译者 : [Mr.Simple](https://github.com/bboyfeiyu) \n* 校对者: [chaossss](https://github.com/chaossss) \n* 状态 : 完成 \n\n\n\n这篇文章是RecyclerView系列文章的结尾篇。前三部分的链接在这里 : \n\n* [第一部分](../issue-9/创建-RecyclerView-LayoutManager-Part-1.md)\n* [第二部分](./创建-RecyclerView-LayoutManager-Part-2.md)\n* [第三部分](./创建-RecyclerView-LayoutManager-Part-3.md)\n\n当我在写这个系列的最后一篇文章，也就是关于predictIve animation的讨论时，我突然想到几个很有意思的点，并且很有讨论价值。这个系列文章以调查RecyclerView是否能够以简单的方式满足竖向、横向滚动的布局需求以及开发者要定制一个LayoutManager的难度有多大开始。这篇文章中我选择了一个基本的网格布局作为自定义layoutManager的示例。\n\n下面这幅图展示了运用这个自定义LayoutManager到RecyclerView的滚动效果。 \n\n![](http://i.embed.ly/1/display/resize?url=http%3A%2F%2Fwiresareobsolete.com%2Fwp-content%2Fuploads%2F2015%2F02%2FGridWindow.gif&grow=true&key=92b31102528511e1a2ec4040d3dc5c07&height=400)\n\n## 打破常规设计\n\n无论你打算如何组织Adapter的位置（从左到右，上到下等等）,内容视图的视角都是显示部分不连贯数据集的区域。更确切地说，在第一个和最后一个可视位置之间的Adapter区域的数据项也会在可视区域view的外面。 \n\n这是一个很重要的点，因为它与在单轴上滚动的布局大相径庭（从而导致与当前框架下提供的默认布局背道而驰）。这些标准小工具显示，数据集是在一个连接块范围内--从第一个到最后一个可视位置之间不间断。\n\nRecyclerView LayoutManager API会假定有一个可见的数据集合，RecyclerView LayoutManager只会显示数据集合中某个范围内可见的数据项，然后产生一个像上述所展示的网格布局一样的布局效果，这稍微有那么点挑战。在predictive animation里没有什么比这部分更加明显了。为了便于扩展，我感觉在这里指出这些毛病是非常必要的。\n\n\n## 假设1 ： 从不可见区域移除一个数据项不会影响当前可见的View\n\n当你考虑到一个Adapter移除一个数据项时LinearLayoutManager或者GridLayoutManager会做何反应时，这两个LayoutManager实际上都处理得非常好。如果被移除的数据项是可见的，一个可用的区域将会空置出来，此时就需要一个周边的View进行填充。这意味着周边显示的View必须被布局到这个位置以填补缺口。然而，并没有一个示例表明当一个移除操作执行时会发送一个隐藏视图的操作，唯一被隐藏的视图是那些被显式移除的。如果被移除的View在可见区域之外，那么对于可见区域的布局不会产生影响。在这个情况之下，你不会看到任何动画，它可能做出的修改是数据项被移到其他位置。\n\n从上述的情况看，这与文章开头我们提到的一样，LayoutManager显示的是一个不连续的数据项。然而，这一可视区域的不连续本质使得数据项在屏幕外从可视区域内移除！换种说法，它们的位置处于第一个和最后一个位置之间，但是目前数据项view并不在布局中。这导致的结果就是，屏幕外发生的数据项移除可以并且会影响我们在布局动画处理时view的生成和消失。\n\n在有机会对view的生成进行布局时，预布局是RecyclerView动画的关键阶段。RecyclerView通过其初始位置值将view返回，据此我们可以将内容布局在其初始状态。但是，当view移除与可视区域不相交时。RecyclerView就会通过其最终位置值将view返回。这样一来，在没有附加记账的情况下处理view的生成就变得困难得多。不过话说回来，难是难，也还是可以做到。\n\n在上一篇文章中我们看到的FixedGridLayoutManager，我们不仅要解析可视view，还要听从onItemsRemoved()的回调来找到移除点，并妥当处理所有生成的view案例。RecyclerView确保我们在需要时，该回调会在预布局之前出现（屏幕外案例），但相反情况下会在预布局之后出现。RecyclerView这么做是为了避免这些事件与你的布局产生冲突--其时间点对我们来说只是一个美丽的意外。\n\n我们还需要追踪的一个事实就是，可视移除会以一种我们意料之中的方式偏移view的位置，而屏幕外移除则不会。这也是为什么移除会被冠以不同类型的原因。上一篇文章忽略的一点表明，在屏幕外进行移除时，我们会对view生成逻辑提供一个手动偏移。。。所以当移除可视时，位置之间会相互匹配。\n\n```java\nprivate void fillGrid(int direction, int emptyLeft, int emptyTop, RecyclerView.Recycler recycler,\n boolean preLayout, SparseIntArray removedPositions) {\n …\n\n for (int i = 0; i < getVisibleChildCount(); i++) {\n int nextPosition = positionOfIndex(i);\n\n /*\n * When a removal happens out of bounds, the pre-layout positions of items\n * after the removal are shifted to their final positions ahead of schedule.\n * We have to track off-screen removals and shift those positions back\n * so we can properly lay out all current (and appearing) views in their\n * initial locations.\n */\n int offsetPositionDelta = 0;\n if (preLayout) {\n int offsetPosition = nextPosition;\n\n for (int offset = 0; offset < removedPositions.size(); offset++) {\n //Look for off-screen removals that are less-than this\n if (removedPositions.valueAt(offset) == REMOVE_INVISIBLE\n && removedPositions.keyAt(offset) < nextPosition) {\n //Offset position to match\n offsetPosition--;\n }\n }\n offsetPositionDelta = nextPosition - offsetPosition;\n nextPosition = offsetPosition;\n }\n\n if (nextPosition < 0 || nextPosition >= getItemCount()) {\n //Item space beyond the data set, don't attempt to add a view\n continue;\n }\n\n …\n\n if (i % mVisibleColumnCount == (mVisibleColumnCount - 1)) {\n leftOffset = startLeftOffset;\n topOffset += mDecoratedChildHeight;\n\n //During pre-layout, on each column end, apply any additional appearing views\n if (preLayout) {\n layoutAppearingViews(recycler, view, nextPosition, removedPositions.size(), offsetPositionDelta);\n }\n } else {\n leftOffset += mDecoratedChildWidth;\n }\n }\n\n …\n}\n```\n\n之后offsetPositionDelta值会作为我们在预布局中使用到的行/列位置的全局偏移被传递到layoutAppearingViews()。如果不是出于附加记账要求，这一偏移完全可以不必存在。\n\n## 假设#2：添加新的数据项只会导致同级view的消失，而不是生成。\n\n添加了新的数据项之后，反面为真。如果在添加时数据项为可视，那么标准布局管理器会在屏幕外推开不可视的view以便腾出空间。之前没有出现过关于这种行为会同时触发一个或多个同级view滑向可视子类位置的案例。移除也是同样的道理，在可视区域外添加数据项并不会影响可视view，所以通常来说动画也不会起作用。\n\n对于FixedGridLayoutManager或其他任何非连贯区域的布局，在可视区域内还是可视区域外进行添加并没有多大差别。两种情况中我们都需要管理可能出现的view生成和消失。而我们在移除中使用的方案在这里则不可行，因为onItemsAdded()总是在预布局之后被调用。。。这一次我们就没那么幸运地再一次能够碰到美丽的意外了。\n\n缺少了那次回调，关于添加数据项，我们实际上在预布局时就没有多少可做的了。这样一来就变成了布局额外的view以备不时之需，而不布局一定量的额外view就会损害性能这两种情况之间的妥协。FixedGridLayoutManager在添加数据项时不支持预测view生成。\n\n## 一切才刚刚开始\n\nRecyclerView APIs是一个新生事物，现有案例中还有非常多的地方需要改进的。同时，它也非常复杂，想要做对并不容易。表面上看起来RecyclerView要求大家付出的努力，背后可能大家要花10倍的精力才能实现。而且这些类型越到后面可能月蛋疼。希望正在尝试这种做法的各位同仁可以视本文为一个预警，不要盲目浪费时间，但同时我们也期待这这个框架的日渐成熟。\n\n\n" }, { "path": "issue-14/Android-Design-Support-Library.md", "content": "Android Design Support Library\n---\n\n> * 原文链接 : [Android Design Support Library](http://android-developers.blogspot.jp/2015/05/android-design-support-library.html)\n* 原文作者 : [Android Developers Blog](http://developer.android.com/index.html)\n* [译文出自 : 开发技术前线 www.devtf.cn](http://www.devtf.cn)\n* 译者 : [MiJack](https://github.com/MiJack) \n* 状态 : 校对完成\n\nAndroid 5.0是有史以来最重要的Android 版本之一，这其中有很大部分要归功于Material design的引入，这种新的设计语言让整个Android的用户体验焕然一新。我们的详细专题是帮助你开始采用Material Design。但是我们也知道，这种设计对于开发者，尤其是那些在意向后兼容的开发者来说是一种挑战。在Android Design Support Library的帮助下，我们为所有的开发者，所有2.1以上的设备，带来了一些重要的Material design控件。你可以在这里面找到Navigation Drawer View，输入控件的悬浮标签，Floating Action Button，Snackbar，Tab以及将这些控件结合在一起的手势滚动框架。\n\n[YouTube的介绍](https://youtu.be/32i7ot0y78U)\n\n###Navigation View\n\n[Navigation drawer](http://www.google.com/design/spec/patterns/navigation-drawer.html?utm_campaign=io15&utm_source=dac&utm_medium=blog)是app识别度与内部导航的关键，保持这里设计上的一致性对app的可用性至关重要，尤其是对于第一次使用的用户。 NavigationView 通过提供抽屉导航所需的框架让实现更简单，同时它还能够直接通过菜单资源文件直接生成导航元素。\n\n![](http://3.bp.blogspot.com/-WmBBQQEJIKM/VWikAyy08sI/AAAAAAAABvc/1R36Txk83UI/s400/drawer.png)\n\n把NavigationView作为DrawerLayout的内容视图来使用，布局如下：\n\n```\n\n\n \n\n \n\n```\n\n你会注意到 NavigationView 的两个属性：app:headerLayout - 控制头部的布局， app:menu - 导航菜单的资源文件（也可以在运行时配置）。NavigationView处理好了和状态栏的关系，可以确保NavigationView在API21+设备上正确的和状态栏交互。\n\n最简单的抽屉菜单往往是几个可点击的菜单的集合：\n\n```\n\n \n \n\n```\n\n被点击过的item会高亮显示在抽屉菜单中，让用户知道当前是哪个菜单被选中。\n你也可以在menu中使用subheader来为菜单分组：\n\n```\n\n

\n \n \n \n\n```\n\n你可以通过设置一个OnNavigationItemSelectedListener，使用其setNavigationItemSelectedListener()来获得元素被选中的回调事件。它为你提供可以点击的[MenuItem](http://developer.android.com/reference/android/view/MenuItem.html?utm_campaign=io15&utm_source=dac&utm_medium=blog)，让你可以处理选择事件，改变复选框状态，加载新内容，关闭导航菜单，以及其他任何你想做的操作。\n\n\n###Floating labels for editing text\n\n即便是十分简单的EditText，在Material Design 中也有提升的空间。在EditText中，当你填入第一个字符后，hint就消失了。现在将它换成[TextInputLayout](http://developer.android.com/reference/android/support/design/widget/TextInputLayout.html?utm_campaign=io15&utm_source=dac&utm_medium=blog)，提示信息会变成一个显示在EditText之上的floating label，这样用户就始终知道他们现在输入的是什么。\n\n![](http://4.bp.blogspot.com/-BUKc5AwzS4A/VWihVlHr9cI/AAAAAAAABvI/rslBAoaHwzA/s1600/textinputlayout.png)\n\n除此以外，还可以通过setError()设置当用户输入不合法时的Error提示；\n\n###Floating Action Button\n\n\n[Floating action button](http://www.google.com/design/spec/components/buttons-floating-action-button.html?utm_campaign=io15&utm_source=dac&utm_medium=blog)是一个负责显示界面基本操作的圆形按钮。Design library中的[FloatingActionButton](http://developer.android.com/reference/android/support/design/widget/FloatingActionButton.html?utm_campaign=io15&utm_source=dac&utm_medium=blog) 实现了一个默认颜色为主题中colorAccent的悬浮操作按钮。\n\n![](http://2.bp.blogspot.com/-tdrgNYnQZyw/VWiOcfSRoYI/AAAAAAAABuU/6LsOxJFE4hE/s1600/image03.png)\n\n\n除了一般大小的悬浮操作按钮，它还支持mini size（fabSize=”mini”）。FloatingActionButton继承自ImageView，你可以使用android:src或者ImageView的任意方法，比如[setImageDrawable()](http://developer.android.com/reference/android/widget/ImageView.html?utm_campaign=io15&utm_source=dac&utm_medium=blog#setImageDrawable(android.graphics.drawable.Drawable)来设置FloatingActionButton里面的图标。\n\n###Snackbar\n\n\n如果你需要一个轻量级、可以快速作出反馈的控件，可以试试[SnackBar](http://www.google.com/design/spec/components/snackbars-toasts.html?utm_campaign=io15&utm_source=dac&utm_medium=blog)。[Snackbar](http://www.google.com/design/spec/components/snackbars-toasts.html?utm_campaign=io15&utm_source=dac&utm_medium=blog)显示在屏幕的底部,包含了文字信息与一个可选的操作按钮。在指定时间结束之后自动消失。另外，用户还可以滑动删除它们。\n\n\n[example video](http://material-design.storage.googleapis.com/publish/material_v_3/material_ext_publish/0B6Okdz75tqQsLVVnZlF4UEtKRU0/components_snackbar_specs_fabtablet_002.webm)\n\n\nSnackbar，可以通过滑动或者点击进行交互，可以看作是比Toast更强大的快速反馈机制，你会发现他们的API非常相似。\n\n```\nSnackbar\n .make(parentLayout, R.string.snackbar_text, Snackbar.LENGTH_LONG)\n .setAction(R.string.snackbar_action, myOnClickListener)\n .show(); // Don’t forget to show!\n```\n\n你应该注意到了make()方法中把一个View作为第一个参数，Snackbar试图找到一个合适的父亲以确保自己是被放置于底部。\n\n###Tabs\n\n通过选项卡的方式切换[View](http://www.google.com/design/spec/components/tabs.html)并不是Material design中才有的新概念，它们和[顶层导航模式](http://www.google.com/design/spec/patterns/app-structure.html?utm_campaign=io15&utm_source=dac&utm_medium=blog#app-structure-top-level-navigation-strategies)或者组织app中不同分组内容（比如，不同风格的音乐）是同一个概念。\n\n![](http://1.bp.blogspot.com/-liraQhLEn60/VWihbiaXaJI/AAAAAAAABvQ/nKi1_xcx6yk/s320/tabs.png)\n\nDesign library的[TabLayout](http://developer.android.com/reference/android/support/design/widget/TabLayout.html?utm_campaign=io15&utm_source=dac&utm_medium=blog) 既实现了固定的选项卡（View的宽度平均分配），也实现了可滚动的选项卡（View宽度不固定同时可以横向滚动）,也可以通过编写代码添加Tab。\n```\n\nTabLayout tabLayout = ...;\ntabLayout.addTab(tabLayout.newTab().setText(\"Tab 1\"));\n```\n\n如果，你使用[ViewPager](http://developer.android.com/reference/android/support/v4/view/ViewPager.html?utm_campaign=io15&utm_source=dac&utm_medium=blog)在tab之间横向切换，你可以直接从[PagerAdapter](http://developer.android.com/reference/android/support/v4/view/PagerAdapter.html?utm_campaign=io15&utm_source=dac&utm_medium=blog)的[getPageTitle()](http://developer.android.com/reference/android/support/v4/view/PagerAdapter.html?utm_campaign=io15&utm_source=dac&utm_medium=blog#getPageTitle(int))中创建选项卡，然后使用setupWithViewPager()将两者联系在一起。它可以使tab的选中事件能更新ViewPager,同时ViewPager的页面改变能更新tab的选中状态。\n\n\n\n###CoordinatorLayout, 动作和滚动\n\n\n独特的视觉效果只是Material design小小的一部分：运动也是设计好一款Material designed应用的重要组成部分。而在Material design中，包括[触摸Ripple](http://www.google.com/design/spec/animation/responsive-interaction.html?utm_campaign=io15&utm_source=dac&utm_medium=blog#responsive-interaction-surface-reaction)和[有意义的转场](http://www.google.com/design/spec/animation/meaningful-transitions.html?utm_campaign=io15&utm_source=dac&utm_medium=blog)，Design library引入[CoordinatorLayout](http://developer.android.com/reference/android/support/design/widget/CoordinatorLayout.html?utm_campaign=io15&utm_source=dac&utm_medium=blog0)，一个从另一层面去控制子view之间触摸事件的布局，Design library中的很多控件都利用了它。\n\n\n###CoordinatorLayout和Floating Action Buttons\n\n\n一个很好的例子就是当你将FloatingActionButton作为一个子View添加进CoordinatorLayout并且将CoordinatorLayout传递给 Snackbar.make()，在3.0及其以上的设备上，Snackbar不会显示在悬浮按钮的上面，而是FloatingActionButton利用CoordinatorLayout提供的回调方法，在Snackbar以动画效果进入的时候自动向上移动让出位置，并且在Snackbar动画地消失的时候回到原来的位置，不需要额外的代码。\n\n\n[example video](http://material-design.storage.googleapis.com/publish/material_v_3/material_ext_publish/0B6Okdz75tqQsLWFucDNlYWEyeW8/components_snackbar_usage_fabdo_002.webm)\n\n\nCoordinatorLayout还提供了layout_anchor和layout_anchorGravity属性一起配合使用，可以用于放置floating view，比如FloatingActionButton与其他View的相对位置\n\n\n###CoordinatorLayout 和app bar\n\n\n另一个比较重要的场合是CoordinatorLayout结合app bar (或者action bar)和 [滚动处理](http://www.google.com/design/spec/patterns/scrolling-techniques.html?utm_campaign=io15&utm_source=dac&utm_medium=blog). 你可能在你的布局里已经使用了[Toolbar](https://developer.android.com/reference/android/support/v7/widget/Toolbar.html?utm_campaign=io15&utm_source=dac&utm_medium=blog), 能让你自定义外观，将应用中最显眼的部分和其他部分整合到一起. Design library采用了进一步的解决方案:使用[AppBarLayout](http://developer.android.com/reference/android/support/design/widget/AppBarLayout.html?utm_campaign=io15&utm_source=dac&utm_medium=blog)可以让Toolbar和其他View（例如展示Tab的TabLayout）对滚动事件作出反应，前提是他们在一个标有ScrollingViewBehavior的View中.因此，你可以创建如下的布局：\n```\n \n \n \n \n\n \n \n\n \n \n\n```\n\n\n现在，随着用户滚动RecyclerView，AppBarLayout通过子视图上的scroll flag，处理事件作出反应，控制他们如何进入，如何退出。Flag包括：\n\n\n\n> - scroll: 所有想滚动出屏幕的view都需要设置这个flag- 没有设置这个flag的view将被固定在屏幕顶部。\n- enterAlways: 这个flag让任意向下的滚动都会导致该view变为可见，启用\"快速返回\"模式。\n- enterAlwaysCollapsed: 当你的视图已经设置minHeight属性又使用此标志时，你的视图只会在最小高度处进入，只有当滚动视图到达顶部时才扩大到完整高度。\n- exitUntilCollapsed: 在滚动过程中，只有当视图折叠到最小高度的时候，它才退出屏幕。\n\n\n注意：那些使用Scroll flag的视图必须在其他视图之前声明。这样才能确保所有的视图从顶部撤离，剩下的元素固定在前面（译者注：剩下的元素压在其他元素的上面）。\n\n###折叠 Toolbars\n\n直接向AppBarLayout添加ToolBar，你需要添加enteralwayscollapsed和exituntilcollapsed两个滚动Flag，但是不能在细节上不同的元素对此的反应。为此，您可以使用 [CollapsingToolbarLayout](http://developer.android.com/reference/android/support/design/widget/CollapsingToolbarLayout.html?utm_campaign=io15&utm_source=dac&utm_medium=blog):\n\n```\n\n \n \n \n\n```\n\n\n这个设置使用collapsingtoolbarlayout的layout_collapsemode =\"pin\" 确保在View折叠时，Toolbar本身仍然在屏幕顶部。更好的是，当你同时使用collapsingtoolbarlayout和Toolbar，当布局完全可见时，标题看上去明显变大了；当布局折叠完成后，它恢复到其默认大小。请注意，在这些情况下，你应该调用CollapsingToolbarLayout#settitle() ，而不是调用Toolbar。\n\n\n[example video](http://material-design.storage.googleapis.com/publish/material_v_3/material_ext_publish/0B0NGgBg38lWWcFhaV1hiSlB4aFU/patterns-scrollingtech-scrolling-070801_Flexible_Space_xhdpi_003.webm)\n\n\n\n如果你希望添加压住特定的视图效果，您可以使用app：layout_collapsemode =\"parallax\"（和app：layout_collapseparallaxmultiplier =“0.7”（可选,用于设置视差乘数）实现视差滚动（也就是说ImageView，作为Toolbar的兄弟节点，在collapsingtoolbarlayout中）。在这种情况下，建议在CollapsingToolbarLayout中设置\napp:contentScrim=\"?attr/colorPrimary\"这一属性，这样，当视图折叠的时候，就会有蒙上纱布的渐变效果。\n\n[example video](http://material-design.storage.googleapis.com/publish/material_v_4/material_ext_publish/0B6Okdz75tqQscXNQY3dNdVlYeTQ/patterns-scrolling-techniques_flex_space_image_xhdpi_003.webm)\n\n\n###CoordinatorLayout与自定义控件\n\n\n\n还有一件需要注意的事情，CoordinatorLayout跟FloatingActionButton或AppBarLayout需要一定的配置-它在[Coordinator.Behavior](http://developer.android.com/reference/android/support/design/widget/CoordinatorLayout.Behavior.html?utm_campaign=io15&utm_source=dac&utm_medium=blog)提供了一些API,子视图既可以更好地控制触摸事件也可以通过[onDependentViewChanged()](http://developer.android.com/reference/android/support/design/widget/CoordinatorLayout.Behavior.html?utm_campaign=io15&utm_source=dac&utm_medium=blog#onDependentViewChanged(android.support.design.widget.CoordinatorLayout,%20V,%20android.view.View))给别人提供一个回调方法。\n\n\nViews可以用CoordinatorLayout.DefaultBehavior(YourView.Behavior.class)注解（annotation）声明默认的Behavior,或者在你的布局文件中声明app:layout_behavior=\"com.example.app.YourView$Behavior\" 属性. 这样做，就可以将任何一个View和CoordinatorLayout整合在一起.\n\n###马上使用吧！\n\nDesign library现在就可以使用，请确保已经用SDk Manager更新了Android Support Repository. 然后添加一条dependency，你就可以使用Design library了:\n\n```\n compile 'com.android.support:design:22.2.0'\n```\n\n需要注意的是，Design library 依赖于Support v4和AppCompat Support Libraries,在你添加 Design library时，这些库也会自动的添加到依赖中。同时，这些控件在Android Studio的Layout Editor (可以在CustomView中找到)中是可用的，你可以便捷的预览一些新的控件。\n\nDesign library, AppCompat和所有的Android Support Library 都是开发Android的强有力工具，当你打造一个符合当代风格、好看的应用时，可以使用提供现成的模块，无需从0开始。\n" }, { "path": "issue-14/Android之WebRTC介绍.md", "content": "#Android之WebRTC介绍\n---\n\n> * 原文链接 : [Introduction to WebRTC on Android](https://tech.appear.in/2015/05/25/Introduction-to-WebRTC-on-Android/)\n* 原文作者 : [Dag-Inge Aas](https://disqus.com/home/forums/appearin/)\n* 译文出自 : [appear.in](https://tech.appear.in/)\n* 译者 : [DorisMinmin](https://github.com/DorisMinmin) \n* 校对者: [这里校对者的github用户名](github链接) \n* 状态 ：完成\n\nWebRTC被誉为是web长期开源开发的一个新启元，是近年来web开发的最重要创新。WebRTC允许Web开发者在其web应用中添加视频聊天或者点对点数据传输，不需要复杂的代码或者昂贵的配置。目前支持Chrome、Firefox和Opera，后续会支持更多的浏览器，它有能力达到数十亿的设备。\n\n然而，WebRTC一直被误解为仅适合于浏览器。事实上，WebRTC最重要的一个特征是允许本地和web应用间的互操作，很少有人使用到这个特性。\n\n本文将探讨如何在自己的Android应用中植入WebRTC，使用[WebRTC Initiative](http://www.webrtc.org/)中提供的本地库。这边文章不会讲解如何使用信号机制建立通话，而是重点探讨Android与浏览器中实现的差异性和相似性。下文将讲解Android中实现对应功能的一些接口。如果想要了解WebRTC的基础知识，强烈推荐[Sam Dutton’s Getting started with WebRTC](http://www.html5rocks.com/en/tutorials/webrtc/basics/)。\n\n##项目中添加WebRTC\n*下面的讲解基于Android WebRTC库版本9127.*\n\n首先要做的是在应用中添加WebRTC库。 WebRTC Initiative 提供了[一种简洁的方式来编译](http://www.webrtc.org/native-code/android)，但尽量不要采用那种方式。取而代之，建议使用原始的io编译版本，可以从[maven central repository](https://oss.sonatype.org/content/groups/public/io/pristine/)中获取。\n\n添加WebRTC到工程中，需要在你的依赖中添加如下内容：\n```Gradle\n1 compile 'io.pristine:libjingle:9127@aar'\n```\n同步工程后，WebRTC库就准备就绪。\n\n##权限\n同其他Android应用一样，使用某些 API 需要申请相应权限。WebRTC也不例外。制作的应用不同，或者需要的功能不同，例如音频或者视频，所需要的权限集也是不同的。请确保按需申请！一个好的视频聊天应用权限集如下：\n```xml\n1 \n2 \n3 \n4 \n5 \n6 \n7 \n8 \n9 \n```\n##灯光，摄影，工厂\n\n在浏览器中使用WebRTC时，有一些功能完善、说明详细的API可供使用。 [navigator.getUserMedia](https://developer.mozilla.org/en-US/docs/Web/API/Navigator/getUserMedia) 和 [RTCPeerConnection](https://developer.mozilla.org/en-US/docs/Web/API/RTCPeerConnection) 包含了可能用到的几乎所有功能。结合`\n \n```\n\n## 5) 模型类\n\n首先，我们需要创建一个POJO或模型类。服务器返回的JSON数据不能在Java里直接使用，所以我们需要用模型类来做转换。\n\nURL的结构是这样的：https://api.github.com/users/ + “search term”\n\n举个栗子：https://api.github.com/users/basil2style\n\n我们的JSON返回数据是这样的：\n\n![json object response](http://img.my.csdn.net/uploads/201504/13/1428929583_4905.jpg)\n\n这是一个**JSON Object**，如果你不了解**JSON Array**和**JSON Object**的区别，请看[这里](http://stackoverflow.com/questions/12289844/difference-between-jsonobject-and-jsonarray)。\n\n使用[jsonschema2pojo](http://www.jsonschema2pojo.org/)来创建POJO更加简单，不要每一个JSON数据的POJO转换都用它，有时候会报错。选择源代码类型为**Json**，注解类型是**Gson**,然后点击**preview**。\n\n点击[这里](http://pastebin.com/4xckerN1)(需翻墙)查看`gitmodel.java`源代码。\n\n## 6) gitapi.java\n\n1) 现在我们需要使用接口调用URL.\n\n**`@GET(\"/users/{user}\")`**, 添加这个注解会调用服务器，参数url基于BASE URL，服务调用的参数以'/'开头，其中{user}是从EditText获取的字符串。\n\n**`@Path(\"user\") String user`** 就是我们从EditText获取的字符串。\n\n服务器端响应的数据则会被存储到POJO实例中去。\n\n```java\npublic interface gitapi {\n \n @GET(\"/users/{user}\") // here is the other url part.best way is to start using /\n public void getFeed(@Path(\"user\") String user, Callback response);\n // string user is for passing values from edittext for eg: user=basil2style,google\n \t // response is the response from the server which is now in the POJO\n}\n```\n\n## 7) RestAdapter\n\n现在该主要部分了，你需要设置`Rest Adapter`和`service`类.\n\n1) API就是`Base URL`.\n\n2) 我们需要设置**`Endpoint(API)`**并调用**`buid()`**方法来创建一个**`RestAdapter`**对象。\n\n3) 使用我们的**`gitapi`**来创建一个服务适配器(service for adapter)。\n\n4) 调用函数并获得响应数据，回调接口是用来异步的获取模型实例的，我们的回调接口需要实现成功回调方法(success request)和错误处理方法(error handling)。\n\n5) 我们解析好的json数据的现在就存在于POJO实例中了，你可以每次调用一条。\n\n```java\nString API = \"https://api.github.com\";\n\nRestAdapter restAdapter = new RestAdapter.Builder().setLogLevel(RestAdapter.LogLevel.FULL).setEndpoint(API).build(); \n\ngitapi git = restAdapter.create(gitapi.class);\n\ngit.getFeed(user, new Callback() {\n\t@Override\n\tpublic void success(gitmodel gitmodel, Response response) {\n\t\ttv.setText(\"Github Name :\" + gitmodel.getName() + \n\t\t \"\\nWebsite :\" + gitmodel.getBlog() + \n\t\t \"\\nCompany Name :\" + gitmodel.getCompany());\n\n\t\tpbar.setVisibility(View.INVISIBLE); // disable progressbar\n \t}\n\n \t@Override\n\tpublic void failure(RetrofitError error) {\n \t\ttv.setText(error.getMessage());\n \t\tpbar.setVisibility(View.INVISIBLE); //disable progressbar\n \t}\n });\n```\n\n完整的`MainActivty.java`代码：\n\n```java\npackage com.makeinfo.flowerpi;\n \nimport android.support.v7.app.ActionBarActivity;\nimport android.os.Bundle;\nimport android.view.Menu;\nimport android.view.MenuItem;\nimport android.view.View;\nimport android.widget.Button;\nimport android.widget.EditText;\nimport android.widget.ProgressBar;\nimport android.widget.TextView;\n \nimport com.makeinfo.flowerpi.API.gitapi;\nimport com.makeinfo.flowerpi.model.gitmodel;\n \nimport retrofit.Callback;\nimport retrofit.RestAdapter;\nimport retrofit.RetrofitError;\nimport retrofit.client.Response;\n \n \npublic class MainActivity extends ActionBarActivity {\n \n Button click;\n TextView tv;\n EditText edit_user;\n ProgressBar pbar;\n String API = \"https://api.github.com\";\t// BASE URL\n \n @Override\n protected void onCreate(Bundle savedInstanceState) {\n super.onCreate(savedInstanceState);\n setContentView(R.layout.activity_main);\n \n click = (Button) findViewById(R.id.button);\n tv = (TextView) findViewById(R.id.tv);\n edit_user = (EditText) findViewById(R.id.edit);\n pbar = (ProgressBar) findViewById(R.id.pb);\n pbar.setVisibility(View.INVISIBLE);\n \n click.setOnClickListener(new View.OnClickListener() {\n @Override\n public void onClick(View v) {\n String user = edit_user.getText().toString();\n pbar.setVisibility(View.VISIBLE);\n \n // Retrofit section start from here...\n // create an adapter for retrofit with base url\n RestAdapter restAdapter = new RestAdapter.Builder().setEndpoint(API).build(); \n \n // creating a service for adapter with our GET class \n gitapi git = restAdapter.create(gitapi.class);\t\n \n // Now ,we need to call for response\n // Retrofit using gson for JSON-POJO conversion\n \n git.getFeed(user,new Callback() {\n @Override\n public void success(gitmodel gitmodel, Response response) {\n // we get json object from github server to our POJO or model class\n \n tv.setText(\"Github Name :\" + gitmodel.getName() + \n \"\\nWebsite :\"+gitmodel.getBlog() + \n \"\\nCompany Name :\"+gitmodel.getCompany());\n \n pbar.setVisibility(View.INVISIBLE);\t// disable progressbar\n }\n \n @Override\n public void failure(RetrofitError error) {\n \ttv.setText(error.getMessage());\n pbar.setVisibility(View.INVISIBLE);\t// disable progressbar\n }\n });\n }\n });\n }\n \n \n @Override\n public boolean onCreateOptionsMenu(Menu menu) {\n // Inflate the menu; this adds items to the action bar if it is present.\n getMenuInflater().inflate(R.menu.menu_main, menu);\n return true;\n }\n \n @Override\n public boolean onOptionsItemSelected(MenuItem item) {\n // Handle action bar item clicks here. The action bar will\n // automatically handle clicks on the Home/Up button, so long\n // as you specify a parent activity in AndroidManifest.xml.\n int id = item.getItemId();\n \n //noinspection SimplifiableIfStatement\n if (id == R.id.action_settings) {\n return true;\n }\n \n return super.onOptionsItemSelected(item);\n }\n}\n```\n" }, { "path": "issue-7/readme.md", "content": "# 开发技术前线 第七期 周报\n\n## 一、Android \n### 1.1 技术文章\n| 文章名称 | 译者 | \n|---------|--------|\n| [使用Robolectric和Android生成代码覆盖率报告](https://github.com/bboyfeiyu/android-tech-frontier/tree/master/issue-7/使用Robolectric和Android生成代码覆盖率报告) | [normalme](https://github.com/normalme) | \n| [Retrofit开发指南](https://github.com/bboyfeiyu/android-tech-frontier/tree/master/issue-7/Retrofit开发指南) | [yaoqinwei](https://github.com/yaoqinwei) | \n| [Android测试框架:Dagger2+Espresso2+Mockito](https://github.com/bboyfeiyu/android-tech-frontier/tree/master/issue-7/Android测试框架：Dagger2+Espresso2+Mockito) | [yaoqinwei](https://github.com/yaoqinwei) | \n| [在Activity中使用Thread导致的内存泄漏](https://github.com/bboyfeiyu/android-tech-frontier/tree/master/issue-7/在Activity中使用Thread导致的内存泄漏) | [chaossss](https://github.com/chaossss) | \n| [深入浅出Android 新特性-Transition-Part-3a](https://github.com/bboyfeiyu/android-tech-frontier/tree/master/issue-7/深入浅出Android 新特性-Transition-Part-3a) | [tiiime](https://github.com/tiiime) | \n| [深入浅出Android 新特性-Transition-Part-3b](https://github.com/bboyfeiyu/android-tech-frontier/tree/master/issue-7/深入浅出Android 新特性-Transition-Part-3b) | [tiiime](https://github.com/tiiime) | \n| [Android Lollipop 5.1.1 更新](https://github.com/bboyfeiyu/android-tech-frontier/tree/master/issue-7/Android Lollipop update.md) | [Mr.Simple](https://github.com/bboyfeiyu) \n| [Android Support 库 22.1版](https://github.com/bboyfeiyu/android-tech-frontier/tree/master/issue-7/Android Support 库 22.1版.md) | [Rocko](https://github.com/zhengxiaopeng) | \n\n### 1.2 开源库\n\n* [自定义RecyclerView实现了listview、gridview、 瀑布流等样式](https://github.com/lucasr/twoway-view)\n\n* [一个类似iOS的Segment Control的控件](https://github.com/7heaven/SHSegmentControl)\n\n* [一个ViewIndicator](https://github.com/eccyan/SpinningTabStrip) \n\n\n## 二、iOS \n### 2.1 技术文章\n| 文章标题 | 译者 | \n|----------------------|------------------------|\n| [iOS编程101-如何生成圆形和圆角的图像](https://github.com/bboyfeiyu/iOS-tech-frontier/blob/master/issue-1/iOS编程101-如何生成圆形和圆角的图像.md) | [7heaven](https://github.com/7heaven) | \n| [CocoaPods指南](https://github.com/bboyfeiyu/iOS-tech-frontier/blob/master/issue-1/CocoaPods指南.md) | [Lollypo](https://github.com/Lollypo) | \n| [iOS开发-可滑动的单元格](https://github.com/bboyfeiyu/iOS-tech-frontier/blob/master/issue-1/iOS开发-可滑动的单元格.md) | [Harries Chen](https://github.com/mrchenhao) | \n| [View Debugging in Xcode 6 ](https://github.com/bboyfeiyu/iOS-tech-frontier/blob/master/issue-1/View Debugging in Xcode 6.md) | [Mr.Simple](https://github.com/bboyfeiyu) | \n\n\n\n### 2.2 开源库\n\n* [一个 AutoLayout 下自动计算 UITableViewCell 高度的扩展](https://github.com/forkingdog/UITableView-FDTemplateLayoutCell)\n\n* [下拉刷新组件](https://github.com/CoderMJLee/MJRefresh) \n\n\n\n## 三、每周推荐\n\n* [友盟微社区,一个可以嵌入App中的微博SDK](http://wsq.umeng.com/)\n* [FIR.Im —— 免费的App内测托管平台，支持IOS、Android应用](http://fir.im/)\n\n\n## 四、涨薪机会\n\n| 公司 | 岗位 | 公司福利 | 详细信息 | \n|----|-----------------|----------------|---------------|\n| 友盟 | Android 架构师 | 氛围好，弹性工作时间，福利好，专业团队 | [详细说明](https://github.com/android-cn/android-jobs/blob/master/%E5%8C%97%E4%BA%AC--JD/%E5%8F%8B%E7%9B%9F%20Android.md) | \n\t \n\n\n## 五、段子\n\n1. 初中的时候，一个晚自习，前桌的一个心仪男生突然转身对我说：“10年后我一定会回来娶你。”\n 我一听，脸爆红，跟他玩得比较好，但没想到他会这么说...然后，他接着说，“回来取你狗命! 哈哈。。。”这么多年了，想起就无语." }, { "path": "issue-7/使用Robolectric和Android生成代码覆盖率报告/readme.md", "content": "使用 Robolectric 和 Android 生成代码覆盖率（测试）报告\n---\n\n> * 原文链接 : [Code coverage reports using Robolectric and Android](http://raptordigital.blogspot.com/2014/08/code-coverage-reports-using-robolectric.html)\n* 原文作者 : [Kris Vandermast](http://raptordigital.blogspot.com/)\n* 译文出自 : [开发技术前线 www.devtf.cn](http://www.devtf.cn)\n* 译者 : [normalme](https://github.com/normalme) \n* 校对者: [Mr.Simple](https://github.com/bboyfeiyu) \n* 状态 : 校对中 \n\n#介绍\n\n我写过许多测试驱动开发与陷阱方面的文章。我认为，其中对测试驱动开发中遇到的陷阱的描述让整个介绍更加完整。测试驱动开发或者通常的测试中，最重要的是你清楚代码中哪些部分经过了测试，而哪些部分需要继续测试。\n\n你可以使用[JaCoCo](http://www.eclemma.org/jacoco/)搞定上述的问题，它对Grandle和Robolectric有较好的集成。\n\n# 配置build.gradle\n\n第一步，配置build.gradle。主要代码如下所示。完整代码见[GitHub](https://github.com/kvandermast/my-robolectric-app)。\n\n*build.gradle*\n\n```\n...\n\nandroid {\n ...\n buildTypes {\n debug {\n runProguard false\n proguardFile 'proguard-rules.txt'\n debuggable true\n testCoverageEnabled = true\n\n }\n }\n\n ...\n}\n\n...\n\napply plugin: 'jacoco'\n\njacoco {\n toolVersion = \"0.7.1.201405082137\"\n}\n\ndef coverageSourceDirs = [\n '../app/src/main/java'\n]\n\ntask jacocoTestReport(type:JacocoReport, dependsOn: \"testDebug\") {\n group = \"Reporting\"\n\n description = \"Generate Jacoco coverage reports\"\n\n classDirectories = fileTree(\n dir: '../app/build/intermediates/classes/debug',\n excludes: ['**/R.class',\n '**/R$*.class',\n '**/*$ViewInjector*.*',\n '**/BuildConfig.*',\n '**/Manifest*.*']\n )\n\n additionalSourceDirs = files(coverageSourceDirs)\n sourceDirectories = files(coverageSourceDirs)\n executionData = files('../app/build/jacoco/testDebug.exec')\n\n reports {\n xml.enabled = true\n html.enabled = true\n }\n\n}\n```\n\n（现在）我们来看看其中最重要的配置。\n\n* buildType 声明，开启代码覆盖测试。\n\n```\n\nandroid {\n ...\n buildTypes {\n debug {\n runProguard false\n proguardFile 'proguard-rules.txt'\n debuggable true\n testCoverageEnabled = true\n\n }\n }\n\n ...\n}\n```\n\n* 加入一个 JaCoCo 插件，同时，指定使用最新版 : \n\n```\n\napply plugin: 'jacoco'\n\njacoco {\n toolVersion = \"0.7.1.201405082137\"\n}\n\ndef coverageSourceDirs = [\n '../app/src/main/java'\n]\n```\n\n* 配置 converageSourceDirs，指定一个文件夹，JaCoCo 将对文件夹中的目标进行反射。\n\n* 配置 JaCoCo 插件，指定你需要测试的类（它们已经经过编译）和不需要测试的类（比如 ButterKnife 注入的 *ViewInjector*）。\n\n```\ntask jacocoTestReport(type:JacocoReport, dependsOn: \"testDebug\") {\n group = \"Reporting\"\n\n description = \"Generate Jacoco coverage reports\"\n\n classDirectories = fileTree(\n dir: '../app/build/intermediates/classes/debug',\n excludes: ['**/R.class',\n '**/R$*.class',\n '**/*$ViewInjector*.*',\n '**/BuildConfig.*',\n '**/Manifest*.*']\n )\n\n additionalSourceDirs = files(coverageSourceDirs)\n sourceDirectories = files(coverageSourceDirs)\n executionData = files('../app/build/jacoco/testDebug.exec')\n\n reports {\n xml.enabled = true\n html.enabled = true\n }\n\n}\n```\n\n#执行 gradle 任务\n\n修改 gradle.build 文件后，你必须执行与开发环境同步，以检查加入新插件后 gradle 也工作正常。\n\n在使用 JaCoCo 生成测试报告前，还需要提供 testDebug.exec 文件。（提供文件）最简单的方法是打开命令行，对你的项目上执行如下命令 ： \n`$ ./gradlew clean assemble`\n\n这条命令会清空之前编译生成的class文件，并重新构建。\n\n现在，你就可以使用 JaCoCo 生成测试报告啦，只要执行这条命令：\n`$ ./gradlew jacocoTestReport`\n\n（你会看到）终端将开始执行 grable 构建脚本，其中，最后一项任务是使用 JaCoCo 生成测试报告：\n\n>\n`$ ./gradlew jacocoTestReport\n:app:preBuild \n:app:preDebugBuild \n:app:checkDebugManifest \n:app:preReleaseBuild \n:app:prepareComAndroidSupportSupportV42000Library UP-TO-DATE \n:app:prepareDeKeyboardsurferAndroidWidgetCrouton184Library UP-TO-DATE \n:app:prepareDebugDependencies \n:app:compileDebugAidl UP-TO-DATE \n:app:compileDebugRenderscript UP-TO-DATE \n:app:generateDebugBuildConfig UP-TO-DATE \n:app:generateDebugAssets UP-TO-DATE \n:app:mergeDebugAssets UP-TO-DATE \n:app:generateDebugResValues UP-TO-DATE \n:app:generateDebugResources UP-TO-DATE \n:app:mergeDebugResources UP-TO-DATE \n:app:processDebugManifest UP-TO-DATE \n:app:processDebugResources UP-TO-DATE \n:app:generateDebugSources UP-TO-DATE \n:app:compileDebugJava UP-TO-DATE \n:app:compileTestDebugJava \n:app:processTestDebugResources UP-TO-DATE \n:app:testDebugClasses \n:app:testDebug \n:app:jacocoTestReport \n \nBUILD SUCCESSFUL\n \nTotal time: 29.482 secs\n\n生成的代码覆盖率测试报告保存在 ./build/reports/jacoco/jacocoTestReport 中，结果类似下图：\n![p](http://img.blog.csdn.net/20150421201014450) \n\n#注意事项\n\n* 你的**应用名**\n\n在我的例子中，Android module名是\"app\"。因此包含 `'../app/src/main/java'` 中的代码。如果你的Android module 名和例子中的不同，就请修改gradle文件中路径（所有涉及到 Android module 相关的路径）。比如，如果你的Android module名是FooBar，配置文件中就应修改为 `\"..app/src/main/java\"`。\n\n* **产品类別**\n\n例子中没用指明产品类别，所以构建任务使用`\"testDebug\"`和`\"../app/build/intermediates/classes/debug\"`中的class文件。但是，如果你在应用中指定产品类别（比如. Local），Gradle就找不到\"testDebug\"任务。所以，需要正确的命名，比如，这里你可以用 testLocalDebug 并包含正确的class文件：`'../app/build/intermediated/classes/debug'`。\n\n如果你有任何问题，别犹豫，直接来问我。代码在 [Github](https://github.com/kvandermast/my-robolectric-app) 上已经更新，请 Check Out。\n\n术语： \n\n1. code coverage 代码覆盖率：软件测试中用来表示被测软件中被测试代码占整个软件的比例或程度。" }, { "path": "issue-7/在Activity中使用Thread导致的内存泄漏/readme.md", "content": "在Activity中使用Thread导致的内存泄漏\n---\n\n> * 原文链接 : [Activitys, Threads, & Memory Leaks](http://www.androiddesignpatterns.com/2013/04/activitys-threads-memory-leaks.html)\n* 原文作者 : [AlexLockwood](https://google.com/+AlexLockwood)\n* [译文出自 : 开发技术前线 www.devtf.cn](http://www.devtf.cn)\n* 译者 : [chaossss](https://github.com/chaossss) \n* 校对者: [yinna317](https://github.com/yinna317) \n* 状态 : 完成\n\n\n\n\n> 注：这篇博文涉及的源码可以在 [GitHub](https://github.com/alexjlockwood/leaky-threads) 上面下载哦\n\n做 Android 开发最常遇到的问题就是在 Activity 的生命周期中协调耗时任务，避免执行任务导致不易察觉的内存泄漏。不妨先读一读下面的代码，代码写了一个简单的 Activity，Activity 在启动后就会开启一个线程，并循环执行该线程中的任务\n\n```java\n\n\t/** \n\t * 示例向我们展示了在 Activity 的配置改变时（配置改变会导致其下的 Activity 实例被销\n * 毁）存活。此外，Activity 的 context 也是内存泄漏的一部分，因为每一个线程都被初始\n * 化为匿名内部类，使得每一个线程都持有一个外部 Activity 实例的隐式引用，使得\n * Activity 不会被 Java 的垃圾回收机制回收。\n */ \n\tpublic class MainActivity extends Activity {\n\t\n\t @Override\n\t protected void onCreate(Bundle savedInstanceState) {\n\t super.onCreate(savedInstanceState);\n\t exampleOne();\n\t }\n\t\n\t private void exampleOne() {\n\t new Thread() {\n\t @Override\n\t public void run() {\n\t while (true) {\n\t SystemClock.sleep(1000);\n\t }\n\t }\n\t }.start();\n\t }\n\t}\n```\n\nActivity 配置发生改变会使 Activity 被销毁，并新建一个 Activity，我们总会觉得 Android 系统会将与被销毁的 Activity 相关的一切清理干净，例如回收与 Activity 关联的内存，Activity 执行的线程等等……然而，现实总是很残酷的，刚刚提到的这些东西都不会被回收，并导致内存泄漏，从而显著地影响应用的性能表现。\n\n## Activity 内存泄漏的根源 ##\n\n如果你读过我以前写的一篇有关 Handler 和 内部类的博文，那我接下来要讲的知识你肯定知道。在 Java 中，非静态匿名内部类会持有其外部类的隐式引用，如果你没有考虑过这一点，那么存储该引用会导致 Activity 被保留，而不是被垃圾回收机制回收。Activity 对象持有其 View 层以及相关联的所有资源文件的引用，换句话说，如果你的内存泄漏发生在 Activity 中，那么你将损失大量的内存空间。\n\n而这样的问题在 Activity 配置改变时会更加严重，因为 Activity 的配置改变表示 Android 系统将要销毁当前 Activity 并新建一个 Activity。举例来说吧，在使用应用的时候，你执行了10次横屏/竖屏操作，每一次方向的改变都会执行下面的代码，那么我们会发现（使用[ Eclipse 的内存分析工具](http://www.eclipse.org/mat/)可以看到）每一个 Activity 对象都会因为留有一个隐式引用而被保留在内存中。\n\n![](http://www.androiddesignpatterns.com/assets/images/posts/2013/04/15/activity-leak.png)\n\n每一次配置的改变都会使 Android 系统新建一个 Activity 并把改变前的 Activity 交给垃圾回收机制回收。但因为线程持有旧 Activity 的隐式引用，使该 Activity 没有被垃圾回收机制回收。这样的问题会导致每一个新建的 Activity 都将发生内存泄漏，与 Activity 相关的所有资源文件也不会被回收，其中的内存泄漏有多严重可想而知。\n\n看到这里可能你会很害怕，很惶恐，很无助，那我们该怎么办……莫慌，解决办法非常简单，既然我们已经确定了问题的根源，那么对症下药就可以了：我们把该线程类声明为私有的静态内部类就可以解决这个问题：\n\n```java\n\n\t /**\n * 示例通过将线程类声明为私有的静态内部类避免了 Activity context 的内存泄漏问题，但\n * 在配置发生改变后，线程仍然会执行。原因在于，DVM 虚拟机持有所有运行线程的引用，无论\n * 这些线程是否被回收，都与 Activity 的生命周期无关。运行中的线程只会继续运行，直到\n * Android 系统将整个应用进程杀死\n */ \n\tpublic class MainActivity extends Activity {\n\t\n\t @Override\n\t protected void onCreate(Bundle savedInstanceState) {\n\t super.onCreate(savedInstanceState);\n\t exampleTwo();\n\t }\n\t\n\t private void exampleTwo() {\n\t new MyThread().start();\n\t }\n\t\n\t private static class MyThread extends Thread {\n\t @Override\n\t public void run() {\n\t while (true) {\n\t SystemClock.sleep(1000);\n\t }\n\t }\n\t }\n\t}\n```\n\n通过上面的代码，新线程再也不会持有一个外部 Activity 的隐式引用，而且该 Activity 也会在配置改变后被回收。\n\n## 线程内存泄漏的根源 ##\n\n第二个问题是：对于每个新建 Activity,如果 Activity 中的线程发生发生内存泄漏。在Java中线程是垃圾回收机制的根源，也就是说，在运行系统中DVM虚拟机总会使硬件持有所有运行状态的进程的引用，结果导致处于运行状态的线程将永远不会被回收。因此，你必须为你的后台线程实现销毁逻辑！下面是一种解决办法：\n\n```java\n\n\t/**\n * 除了我们需要实现销毁逻辑以保证线程不会发生内存泄漏，其他代码和示例2相同。在退出当前\n * Activity 前使用 onDestroy() 方法结束你的运行中线程是个不错的选择\n\t */\n\tpublic class MainActivity extends Activity {\n\t private MyThread mThread;\n\t\n\t @Override\n\t protected void onCreate(Bundle savedInstanceState) {\n\t super.onCreate(savedInstanceState);\n\t exampleThree();\n\t }\n\t\n\t private void exampleThree() {\n\t mThread = new MyThread();\n\t mThread.start();\n\t }\n\t\n /**\n\t * 私有的静态内部类不会持有其外部类的引用，使得 Activity 实例不会在配置改变时发生内\n\t * 存泄漏\n */\n\t private static class MyThread extends Thread {\n\t private boolean mRunning = false;\n\t\n\t @Override\n\t public void run() {\n\t mRunning = true;\n\t while (mRunning) {\n\t SystemClock.sleep(1000);\n\t }\n\t }\n\t\n\t public void close() {\n\t mRunning = false;\n\t }\n\t }\n\t\n\t @Override\n\t protected void onDestroy() {\n\t super.onDestroy();\n\t mThread.close();\n\t }\n\t}\n```\n\n通过上面的代码，我们在 onDestroy() 方法中结束了线程，确保不会发生意外的线程的内存泄漏问题。如果你想要在配置改变后保留该线程（而不是每一次在关闭 Activity 后都要新建一个线程），那我建议你使用 Fragment 去完成该耗时任务。你可以翻我以前的博文，一名叫作**“Handling Configuration Changes with Fragments”**应该能满足你的需求，在API demo中也提供了很好理解的例子来为你阐述相关概念。\n\n## 结论 ##\n\nAndroid 开发过程中，在 Activity 的生命周期里协调耗时任务可能会很困难，你一不小心就会导致内存泄漏问题。下面是一些小提示，能帮助你预防内存泄漏问题的发生：\n\n- **尽可能使用静态内部类而不是非静态内部类。**每一个非静态内部类实例都会持有一个外部类的引用，若该引用是 Activity 的引用，那么该 Activity 在被销毁时将无法被回收。如果你的静态内部类需要一个相关 Activity 的引用以确保功能能够正常运行，那么你得确保你在对象中使用的是一个 Activity 的弱引用，否则你的 Activity 将会发生意外的内存泄漏。\n\n- **不要总想着 Java 的垃圾回收机制会帮你解决所有内存回收问题。**就像上面的示例，我们以为垃圾回收机制会帮我们将不需要使用的内存回收，例如：我们需要结束一个 Activity，那么它的实例和相关的线程都该被回收。但现实并不会像我们剧本那样走。Java 线程会一直存活，直到他们都被显式关闭，抑或是其进程被 Android 系统杀死。所以，为你的后台线程实现销毁逻辑是你在使用线程时必须时刻铭记的细节，此外，你在设计销毁逻辑时要根据 Activity 的生命周期去设计，避免出现 Bug。\n\n- **考虑你是否真的需要使用线程。**Android 应用的框架层为我们提供了很多便于开发者执行后台操作的类。例如：我们可以使用 Loader 代替在 Activity 的生命周期中用线程通过注入执行短暂的异步后台查询操作，考虑用 Service 将结构通知给 UI 的 BroadcastReceiver。最后，记住，这篇博文中对线程进行的讨论同样适用于 AsyncTask（因为 AsyncTask 使用 ExecutorService 执行它的任务）。然而，虽说 ExecutorService 只能在短暂操作（文档说最多几秒）中被使用，那么这些方法导致的 Activity 内存泄漏应该永远不会发生。\n\n这篇博文的源码可以在 [GitHub](https://github.com/alexjlockwood/leaky-threads) 中下载，你也可以在 [Google Play](https://play.google.com/store/apps/details?id=com.adp.leaky.threads) 下载 APK 使用。\n\n![](http://www.androiddesignpatterns.com/assets/images/posts/2013/04/15/leaky-threads-screenshot.png)" }, { "path": "issue-7/深入浅出Android新特性-Transition-Part-3a/readme.md", "content": "`深入理解 Shared Element Transition (part 3a)`\n---\n\n>\n* 原文链接 : [Shared Element Transitions In-Depth (part 3a)][source-url]\n* 作者 : [Alex Lockwood](https://plus.google.com/+AlexLockwood)\n* [译文出自 : 开发技术前线 www.devtf.cn](http://www.devtf.cn)\n* 译者 : [tiiime](https://github.com/tiiime)\n* 校对者: [chaossss](https://github.com/chaossss) \n* 状态 : 完成\n\n\n\n##深入理解共享元素 Transition\n\n这篇文章会深度分析共享元素 transitions 和它在 Activity & Fragment Transitions API 中的作用。这篇文章是下面这个系列中的第三篇：\n\n- Part 1: [在 Activity 和 Fragment 中使用 Transition ][part-1]\n- Part 2: [深入理解 Content Transition][part-2]\n- Part 3a: [深入理解共享元素 Transition][part3a]\n- Part 3b: [延迟共享元素的 Transition][part-3b]\n- Part 3c: 共享元素回调实践 (coming soon!)\n- Part 4: Activity & Fragment 过渡动画示例(coming soon!)\n\nPart 3 会分成三个部分: part3a 介绍 共享元素 transitions 的底层操作，part3b 和 part3c \n主要关注 API 的具体实现细节，例如推迟某些 共享元素 transition 的重要性和如何实现\n**SharedElementCallbacks**。\n\n我们首先会总结下在 [part 1][part-1] 中提到的关于 共享元素 transition 的知识点，然后说一说在 Android Lollipop 中是怎样使用它来构建合适的过渡动画。\n\n##什么是 共享元素 Transition ?\n\n共享元素 transition 决定了 共享元素 视图(也叫做主角视图)在\nActivity/Fragment 场景过渡时的动画效果。共享元素 的动画\n在被调用 Activity/Fragment 的 **进入/返回** 共享元素 transition\n(1) 中执行，\n可以通过下面的[Window][window]/[Fragment][fragment] 方法设置：\n\n- **setSharedElementEnterTransition()** - **B** 的 **进入** 共享元素 transition ，执行将 \n\t共享元素视图 从 **A** 中的起始位置移动到它在 **B** 中的最终位置的动画。\n- **setSharedElementReturnTransition()** - **B** 的 **返回** 共享元素 transition ，执行将 \n\t共享元素视图 从 **B** 中起始位置移动到它在 **A** 中的最终位置的动画。\n\n[**Video 3.1**][video-3.1] 展示了在 Google Play Music 中是怎样使用共享元素 transition \n的。这个 transition 包含两个元素：一个 **ImageView**和它的父视图 **CardView**。\nTransition 期间，**CardView** 会扩展到全屏或收缩回原状， \n**ImageView** 能在这两个 Activity 里无缝的衔接。\n\n在 [part1 ][part-1] 里只是简单的介绍了下这个话题，这篇文章将会对 共享元素 transition\n做更深度的分析。例如 共享元素 Transition 在底层是如何实现的？都有哪些类型的 Transition 对象可以使用? Transition 期间 共享元素视图 是在哪里怎样绘制的？接下来的几章里\n我们会逐个解答这些问题。\n\n##深入共享元素 Transitions 底层\n\n之前的文章已经介绍过 Transition 的两个主要任务分别是获取目标视图的 开始&结束 状态和创建这两个状态间视图的过渡动画(Animator)。共享元素 Transition 也一样：\n在创建动画前需要捕获每一个\n共享元素视图的起始和结束状态(就是共享元素在 **调用/被调用** Activity/Fragment\n里的位置，大小和外观)。有了这些信息 共享元素 Transition 就可以确定每一个 共享元素\n视图应该执行的动画。\n\n和 [Content Transitions 的底层][content-transition]相似，框架通过在运行时明确的\n更改每个 共享元素视图 的属性将这个状态信息提供给 共享元素 Transition 。\n更准确地说 Activity **A** 启动 Activity **B** 时将会出现以下事件：(2)\n\n---\n\n1. Activity **A** 调用 **startActivity()** 构造，测量，布局了一个\n\t最初背景色为透明的半透明窗口 Activity **B** 。\n2. 框架将 **B** 中每一个共享元素视图复位到对应的原来在 **A** 中时的位置，接着 **B** 的进入 transition 捕获 **B** 中所有共享元素视图的起始状态。\n3. 框架将 **B** 中每一个共享元素视图复位到对应的在 **B** 的最终位置，接着 **B** 的进入 transition 捕获 B 中所有共享元素视图的结束状态。\n4. **B** 的进入 transition 比较所有共享元素视图的起始和结束状态，根据它们的不同\n\t创建一个 **Animator**。\n5. 框架命令 **A** 隐藏共享元素视图，并运行返回的 **Animator**。**B** 中的\n\t共享元素视图到位之后，**B** 的窗口背景在 **A **上逐渐显示，直到 **B** \n\t完全的显示出来，transition 运行完毕。\n---\n\nContent transitions 是根据每个过渡视图的可见性变化来调节的，**共享元素 transition \n是根据每个共享元素视图的位置，大小和外观的变化来调节的**。从 API 21 开始，框架提供了\n几个自定义共享元素场景切换动画的 **Transition** 实现。\n\n- [ChangeBounds][ChangeBounds] - 捕获共享元素布局边界根据不同构造动画。\n\t**ChangeBounds** 在共享元素 Transition 中经常使用，大多数共享元素在两个\n\tActivity/Fragment 间会有大小 或/和 位置不同。 \n- [ChangeTransform][ChangeTransform ] - 捕获共享元素缩放和角度，\n\t根据不同构建动画(3)。\n- [ChangeClipBounds][ChangeClipBounds] - 捕获共享元素的 [clip bounds][clip-bounds] \n\t(剪辑边界) ，根据不同构建动画。\n- [ChangeImageTransform][ChangeImageTransform] - 捕获共享元素 ImageView 的\n\t变换矩阵( transform matrices) ，根据不同构建动画。结合 **ChangeBounds**，\n\t可以让 ImageView\n\t 无缝的改变大小，形状和 [ ImageView.ScaleType ][ImageView.ScaleType]。 \n- [@android:transition/move][move] - 一个 **TransitionSet** ，同时执行上面四种\n\ttransition 。在 [part 1][part-1] 里提到过，如果没有明确的声明 进入/返回 共享元素 \n\ttransition ，框架会默认运行这个 transition。\n\t\n---\n\n在上面的例子中，我们还可以发现 **共享元素视图实例并没有在 Activities/Fragments 间\n“共享”**。事实上，进入/返回 共享元素 transitions期间，用户看到的绝大多数东西都是在\n**B** 的 content view 中绘制的。框架并没有从 **A** 向 **B** \n传递 共享元素视图实例，\n而是采用了不同的方法实现相同的视觉效果。当 **A** 启动 **B** ，框架收集 **A**\n中共享元素的所有相关信息，并传递给 **B**。接下来 **B** 使用这些信息初始化\n共享元素视图的起始状态(它们在 **A** 中时对应的大小，位置和外观)。Transition \n开始时，B 中除了共享元素视图外的所有东西都被初始化为对用户不可见。Tansition\n的执行过程中，框架将 B 的 Activity 窗口逐渐显示，直到 B \n中共享元素结束动画窗口变为不透明。\n\n---\n\n##使用共享元素 Overlay (4)\n最后，如果想要完全理解共享元素 transition 的运作，我们必须先说说共享元素 overlay。\n可能不是很明显，**共享元素默认是在整个窗口视图层的顶层 [ViewOverlay][ViewOverlay] \n上绘制**。简单介绍下 ，\n**ViewOverlay** 这个类是在 API 18 中为了方便在视图层顶层\n绘制引入的。添加到视图 **ViewOverlay** 之中的Drawable \n和 view (甚至是一个 **ViewGroup** 的子类) ，\n将会被绘制在视图的最上层。这就解释了框架为什么\n默认选择在窗口视图层的 **ViewOverlay** 中绘制共享元素。\n共享元素视图应该是贯穿整个 transition 的焦点；\n如果 transitioning views 意外的绘制在共享元素之上就会\n破坏这个效果(5)。\n\n---\n\n虽然共享元素默认绘制在共享元素的 ViewOverlay 之中，但是\n框架也提供了关闭 overlay 的方法，只要调用\n[Window#setSharedElementsUseOverlay(false) ][setsharedelementuseoverlay] \n就可以了。如果你关闭了 overlay\n，要留意这样做可能会引起的副作用。例如，[Video 3.2][video-3.2]\n 执行了一个简单的共享元素 transition 两次，\n一次开启和一次关闭 共享元素 overlay 。第一次达到了预期想要的结果，\n第二次关闭 overlay 后运行的效果不理想。Transition view 从底部向上移入\n调用 Activity 的 content view 时挡住了部分 共享元素 **ImageView** 。虽然\n可以改变在 View 上绘制视图的顺序或者通过在共享元素 parent 里调用\n **setClipChildren(false)** 这些旁门左道来修复问题，但是与可能带来的维护问题\n 相比真是得不偿失。总之，除非你感觉必须要关掉共享元素 overlay 才能达到你想要的效果，\n 其他情况尽量不要关闭它，这样会保持代码简洁，并且共享元素 transition 效果更引人注目。\n \n##结语\n\n综上所诉，这篇文章讲了三个重点:\n\n1. 共享元素 transition 确定 共享元素视图(主角视图) 从一个 Activity/Fragment 移动到\n\t另一个其间场景过渡的动画。\n2. 共享元素 transition 是根据每一个 共享元素视图 的位置，大小，和外观的变化调节的。\n3. 共享元素默认是绘制在窗口视图的顶层 **ViewOverlay** 上面的。\n\n希望这篇文章对你有所帮助 ～\n\n---\n\n1 Note that the Activity Transition API gives you the ability to also specify exit and reenter shared element transitions using the setSharedElementExitTransition() and setSharedElementReenterTransition() methods, although doing so is usually not necessary. For an example illustrating one possible use case, check out this blog post. For an explanation why exit and reenter shared element transitions are not available for Fragment Transitions, see George Mount's answer and comments in this StackOverflow post. ↩\n\n2 A similar sequence of events occurs during the exit/return/reenter transitions for both Activities and Fragments. ↩\n\n3 One other subtle feature of ChangeTransform is that it can detect and handle changes made to a shared element view's parent during a transition. This comes in handy when, for example, the shared element's parent has an opaque background and is by default selected to be a transitioning view during the scene change. In this case, the ChangeTransform will detect that the shared element's ｀parent is being actively modified by the content transition, pull out the shared element from its parent, and animate the shared element separately. See George Mount's StackOverflow answer for more information. ↩\n\n4 Note that this section only pertains to Activity Transitions. Unlike Activity Transitions, shared elements are not drawn in a ViewOverlay by default during Fragment Transitions. That said, you can achieve a similar effect by applying a ChangeTransform transition, which will have the shared element drawn on top of the hierarchy in a ViewOverlay if it detects that its parent has changed. See this StackOverflow post for more information. ↩\n\n5 Note that one negative side-effect of having shared elements drawn on top of the entire view hierarchy is that this means it will become possible for shared elements to draw on top of the System UI (such as the status bar, navigation bar, and action bar). For more information on how you can prevent this from happening, see this Google+ post. ↩\n\n\n1. Activity Transition API 也提供了\n\t**setSharedElementExitTransition()** 和 **setSharedElementReenterTransition()**\n\t这两个方法来设置 退出/重入 共享元素过渡，虽然通常来说是不必要的。\n\t[这篇文章][thispost]介绍了一个可能会遇到的用例。在这个 [stackoverflow][stackoverflow1]\n\t提问中 George Mount 的回答解释了为什么 退出/重入 共享元素 transition 在\n\tFragment Transitions 中不可用。 ↩\n\n2. Activities 和 Fragments 的 退出/返回/重入 transition 过程中出现事件序列相似 ↩\n3. **ChangeTransform** 还有一个超赞的特性，它可以检测并处理共享元素父视图过渡期间\n\t的改变。当共享元素父视图有一个不透明背景，在场景变换过程中默认被选为\n\ttransitioning view 时，**ChangeTransform** 就有了用武之地。如果它检测出\n\t共享元素父视图已被 content transition 更改，就会将共享元素提取出来，单独执行\n\t共享元素的动画。[StackOverflow answer][stackoverflow2] 这里有 George Mount \n\t的详细说明。\n\t↩\n4. 注意，这部分只与 Activity Transition 有关。和Activity Transition 不同，Fragment Transition\n\t期间共享元素默认不在 **ViewOverlay** 中绘制。尽管如此，你仍可以使用 ChangeTransform \n\ttransition 来达到相似的效果，如果它检测到父视图改变了，就会把共享元素绘制在 \n\t**ViewOverlay** 的顶层。[StackOverflow][stackoverflow3] 这里有更多信息。\n\t ↩\n5. 注意，将共享元素绘制在整个图层最顶层也有一些负面效果。有可能\n\t会将共享元素绘制在 System UI 之上(比如 status bar, navigation bar还有 action bar)。\n\t解决方法看这里 [Google+ post][gplus]。\n\t↩\n\n---\n\n[source-url]:http://www.androiddesignpatterns.com/2015/01/activity-fragment-shared-element-transitions-in-depth-part3a.html\n\n[part-1]:http://www.androiddesignpatterns.com/2014/12/activity-fragment-transitions-in-android-lollipop-part1.html\n[part-2]:http://www.androiddesignpatterns.com/2014/12/activity-fragment-content-transitions-in-depth-part2.html\n[part3a]:http://www.androiddesignpatterns.com/2015/01/activity-fragment-shared-element-transitions-in-depth-part3a.html\n[part-3b]:http://www.androiddesignpatterns.com/2015/03/activity-postponed-shared-element-transitions-part3b.html\n[window]:http://developer.android.com/reference/android/view/Window.html\n[fragment]:http://developer.android.com/reference/android/app/Fragment.html\n[content-transition]:http://www.androiddesignpatterns.com/2014/12/activity-fragment-content-transitions-in-depth-part2.html\n[video-3.1]:http://www.androiddesignpatterns.com/assets/videos/posts/2015/01/12/music-opt.mp4\n[Video-3.2]:http://www.androiddesignpatterns.com/assets/videos/posts/2015/01/12/overlay-opt.mp4\n[ChangeBounds]:https://developer.android.com/reference/android/transition/ChangeBounds.html\n[ChangeTransform ]:https://developer.android.com/reference/android/transition/ChangeTransform.html\n[ChangeClipBounds]:https://developer.android.com/reference/android/transition/ChangeClipBounds.html\n[ChangeImageTransform]:https://developer.android.com/reference/android/transition/ChangeImageTransform.html\n[move]:https://github.com/android/platform_frameworks_base/blob/lollipop-release/core/res/res/transition/move.xml\n[clip-bounds]:https://developer.android.com/reference/android/view/View.html#getClipBounds()\n[ImageView.ScaleType]:https://developer.android.com/reference/android/widget/ImageView.ScaleType.html\n[ViewOverlay]:https://developer.android.com/reference/android/view/ViewOverlay.html\n[setsharedelementuseoverlay]:https://developer.android.com/reference/android/view/Window.html#setSharedElementsUseOverlay(boolean)\n[thispost]:https://halfthought.wordpress.com/2014/12/08/what-are-all-these-dang-transitions/\n[stackoverflow1]:http://stackoverflow.com/questions/27346020/understanding-exit-reenter-shared-element-transitions\n[stackoverflow2]:http://stackoverflow.com/questions/26899779/enter-transition-on-a-fragment-with-a-shared-element-targets-the-shared-element\n[stackoverflow3]:http://stackoverflow.com/questions/27892033/is-there-a-setsharedelementsuseoverlay-method-for-fragment-transitions\n[gplus]:https://plus.google.com/+AlexLockwood/posts/RPtwZ5nNebb\n" }, { "path": "issue-7/深入浅出Android新特性-Transition-Part-3b/readme.md", "content": "延迟共享元素的过渡动画 (part 3b)\n---\n\n>\n* 原文链接 : [Postponed Shared Element Transitions (part 3b)][source-url]\n* 作者 : [Alex Lockwood](https://plus.google.com/+AlexLockwood)\n* [译文出自 : 开发技术前线 www.devtf.cn](http://www.devtf.cn)\n* 译者 : [tiiime](https://github.com/tiiime)\n* 校对者: [chaossss](https://github.com/chaossss) \n* 状态 : 完成\n\n通过讨论 Lollipop Transition API 的一个重要的特性：延迟共享元素的过渡动画，这篇博文将继续我们关于共享元素 Transition 的深度解析。这也是我关于 Transition 这个专栏的第四篇文章。\n\n- Part 1: [在 Activity 和 Fragment 中使用 Transition ][part-1]\n- Part 2: [深入理解 Transition][part-2]\n- Part 3a: [深入理解共享元素的 Transition][part3a]\n- Part 3b: [延迟共享元素的 Transition][part-3b]\n- Part 3c: 共享元素回调实践 (coming soon!)\n- Part 4: Activity & Fragment 过渡动画示例(coming soon!)\n\n我们通过一个常见的问题来解释为什么需要推迟某些共享元素的过渡动画。\n\n##理解问题\n\n通常问题的根源是框架在 Activity 生命周期非常早的时候启动共享元素 Transition 。回想我们的第一篇文章，Transitions 必须捕获目标 View 的起始和结束状态来构建合适的动画。因此，如果框架在共享元素获得它在调用它的 Activity 中所给定的大小和位置前启动共享元素的过渡动画，这个 Transition 将不能正确捕获到共享元素的结束状态值,生成动画也会失败(一个过渡失败的例子[Video 3.3](http://www.androiddesignpatterns.com/assets/videos/posts/2015/03/09/postpone-bug-opt.mp4)).\n\nTransition 开始前，能否计算出正确的共享元素的结束值主要依靠两个因素:\n\n(1) 调用共享元素的 Activity 的布局复杂度以及布局层次结构的深度 \n(2)调用共享元素Activity载入数据消耗的时间\n\n布局越复杂，在屏幕上确定共享元素的大小位置耗时越长。同样，如果调用共享元素的 Activity 依赖一个异步的数据载入，框架仍有可能会在数据载入完成前自动开始共享元素 Transition。下面列出的是你可能遇到的常见问题:\n\n- **存在于 Activity 托管的 Fragment 中的共享元素**。[FragmentTransactions 在 commit 后并不会被立即执行][FragmentTransactions]，它们会被安排到主线程中等待执行。因此，如果共享元素存在的 Fragment 的视图层和FragmentTransaction没有被及时执行，框架有可能在共享元素被正确测量大小和布局到屏幕前启动共享元素 Transition。(1)\n\n- **共享元素是一个高分辨率的图片**。给 **ImageView** 设置一个超过其初始化边界的高分辨率图片，最终可能会导致在这个视图层里出现[额外的布局传递][add-layout-pass]，由此增加在共享元素准备好前就启动 Transition 的几率。流行的异步图片处理库比如 [`Volley`][volley] 和 [`Picasso`][picasso] ，也不能可靠的解决这个问题：框架不能预先了解图片是要被下载，缩放还是在后台线程中从磁盘读取，也不管图片是否处理完毕就启动共享元素 Transition。\n\n- **共享元素依赖于异步的数据加载**如果共享元素所需的数据是通过**AsyncTask**，**AsyncQueryHandler**,**Loader**或者其他类似的东西加载，在它们获得在调用它们的 Activity 的最终数据（大小、位置）前，框架就有可能在主线程中启动 Transition。\n\n现在你可能会想：如果有办法能让暂时延迟 Transition 的使用，直到我们确定了共享元素的确切大小和位置才使用它就好了。幸好 Activity Transitions API(2) 为我们提供了解决方案。\n\n在 Activity 的`onCreate()`中调用[`postponeEnterTransition()`][postponeEnterTransition] 方法来暂时阻止启动共享元素 Transition。之后，你需要在共享元素准备好后调用 [`startPostponedEnterTransition`][startPostponedEnterTransition] 来恢复过渡效果。常见的模式是在一个[`OnPreDrawListener`][onPreDrawListener]中启动延时 Transition，它会在共享元素测量和布局完毕后被调用(3)。\n\n```java\n\n\n@Override\nprotected void onCreate(Bundle savedInstanceState) {\n super.onCreate(savedInstanceState);\n setContentView(R.layout.activity_main);\n\n // Postpone the shared element enter transition.\n postponeEnterTransition();\n\n // TODO: Call the \"scheduleStartPostponedTransition()\" method\n // below when you know for certain that the shared element is\n // ready for the transition to begin.\n}\n\n/**\n * Schedules the shared element transition to be started immediately\n * after the shared element has been measured and laid out within the\n * activity's view hierarchy. Some common places where it might make\n * sense to call this method are:\n *\n * (1) Inside a Fragment's onCreateView() method (if the shared element\n * lives inside a Fragment hosted by the called Activity).\n *\n * (2) Inside a Picasso Callback object (if you need to wait for Picasso to\n * asynchronously load/scale a bitmap before the transition can begin).\n *\n * (3) Inside a LoaderCallback's onLoadFinished() method (if the shared\n * element depends on data queried by a Loader).\n */\nprivate void scheduleStartPostponedTransition(final View sharedElement) {\n sharedElement.getViewTreeObserver().addOnPreDrawListener(\n new ViewTreeObserver.OnPreDrawListener() {\n @Override\n public boolean onPreDraw() {\n sharedElement.getViewTreeObserver().removeOnPreDrawListener(this);\n startPostponedEnterTransition();\n return true;\n }\n });\n}\n```\n\n忽略方法名，这里还有第二种方法可以延迟共享元素的返回 Transition，在调用Activity的[`onActivityReenter()`][onActivityReenter] 方法中延缓返回 Transition(4)\n\n```java\n/**\n * Don't forget to call setResult(Activity.RESULT_OK) in the returning\n * activity or else this method won't be called!\n */\n@Override\npublic void onActivityReenter(int resultCode, Intent data) {\n super.onActivityReenter(resultCode, data);\n\n // Postpone the shared element return transition.\n postponeEnterTransition();\n\n // TODO: Call the \"scheduleStartPostponedTransition()\" method\n // above when you know for certain that the shared element is\n // ready for the transition to begin.\n}\n\n```\n\n尽管添加延时可以让共享元素 Transition 更加流畅准确，但是你也要知道在应用中引入共享元素 Transition 的延迟可能会产生一些负面影响：\n\n- **调用`postponeEnterTransition`后不要忘记调用`startPostponedEnterTransition`**。\n忘记调用`startPostponedEnterTransition`会让你的应用处于死锁状态，用户无法进入下个Activity。\n\n\n- **不要将共享元素 Transition 延迟设置到1s以上**。延迟时间过长会在应用中产生不必要的卡顿，影响用户体验。\n\n\n感谢阅读！希望这篇文章对你有所帮助。\n\n**1**: 当然，许多应用通过调用 [`FragmentManager#executePendingTransactions()`](https://developer.android.com/reference/android/app/FragmentManager.html#executePendingTransactions()) 来避开这个问题，这样会强制立即执行FragmentTransactions而不是异步。\n\n**2**: 注意!`postponeEnterTransition()`和`startPostponedEnterTransition()`只对 Activity Transition起作用，对Fragment无效。详细信息可以在这里找到 [StackOverflow](http://stackoverflow.com/questions/26977303/how-to-postpone-a-fragments-enter-transition-in-android-lollipop) & [Google+](https://plus.google.com/+AlexLockwood/posts/3DxHT42rmmY)\n\n**3**: 小贴士:你可以先调用 [`View#isLayoutRequested()`](http://developer.android.com/reference/android/view/View.html#isLayoutRequested()) 来确认是否需要调用 [`OnPreDrawListener`][OnPreDrawListener]，有必要的话 [`View#isLaidOut()`](http://developer.android.com/reference/android/view/View.html#isLaidOut()) 在一些情况下也能派上用场\n\n\n**4**: 在开发者选项中启用不保留 Activity 选项可以方便调试共享元素返回/重新进入时对应过渡动画的行为，这也可以帮助测试在返回的过渡效果开始之前可能发生最糟糕的情况( Activity 需要重新构造布局加载数据...)\n\n\n[source-url]:http://www.androiddesignpatterns.com/2015/03/activity-postponed-shared-element-transitions-part3b.html\n[FragmentTransactions]:https://developer.android.com/reference/android/app/FragmentTransaction.html#commit()\n[postponeEnterTransition]:https://developer.android.com/reference/android/app/Activity.html#postponeEnterTransition()\n[startPostponedEnterTransition]:https://developer.android.com/reference/android/app/Activity.html#startPostponedEnterTransition()\n[add-layout-pass]:https://github.com/android/platform_frameworks_base/blob/lollipop-release/core/java/android/widget/ImageView.java#L453-L455\n[video]:http://www.androiddesignpatterns.com/assets/videos/posts/2015/03/09/postpone-bug-opt.mp4\n[volley]:https://android.googlesource.com/platform/frameworks/volley\n[picasso]:http://square.github.io/picasso/\n[onPreDrawListener]:http://developer.android.com/reference/android/view/ViewTreeObserver.OnPreDrawListener.html\n[onActivityReenter]:https://developer.android.com/reference/android/app/Activity.html#onActivityReenter(int,%20android.content.Intent)\n\n[part-1]:https://github.com/bboyfeiyu/android-tech-frontier/tree/master/others/%E6%B7%B1%E5%85%A5%E6%B5%85%E5%87%BAAndroid%20%E6%96%B0%E7%89%B9%E6%80%A7-Transition-Part-1\n[part-2]:http://www.androiddesignpatterns.com/2014/12/activity-fragment-content-transitions-in-depth-part2.html\n[part3a]:http://www.androiddesignpatterns.com/2015/01/activity-fragment-shared-element-transitions-in-depth-part3a.html\n[part-3b]:http://www.androiddesignpatterns.com/2015/03/activity-postponed-shared-element-transitions-part3b.html\n" }, { "path": "issue-8/Android 进行单元测试难在哪-序.md", "content": "Android 进行单元测试难在哪-序\n---\n\n> * 原文链接 : [Against Android Unit Tests](http://philosophicalhacker.com/2015/04/10/against-android-unit-tests/)\n* 原文作者 : [Matthew Dupree](http://philosophicalhacker.com/)\n* [译文出自 : 开发技术前线 www.devtf.cn](http://www.devtf.cn)\n* 译者 : [chaossss](https://github.com/chaosssss) \n* 校对者: [Rocko](https://github.com/zhaoxiaopeng) \n* 状态 : 完成 \n\n其实不仅仅只有普通 Android 开发工程师觉得测试 Android 应用很恼火，大牛们也受此困扰已久。例如 Jake Wharton 曾经明确地表示：Android 平台自诞生之初就与应用测试势如水火。Don Felker 和 Kaushik Gopal 也在他们的[博文](http://fragmentedpodcast.com/episodes/1/)里也提出了相同的观点。当然了，他们还提到 Google 的 [IOSched 应用](https://github.com/google/iosched)，根本就没有进行过测试，据说 IOSched 还是 Android 开发环境中应用开发的最优集合体呢。IOSched 没有进行测试让我们这些开发者很困扰：1、Google 所谓的“测试是高效地进行 Android 开发中的关键一环”真的不是来唬小孩的吗；2、还是 Google 官方的工程师觉得测试 Android 应用简直就是浪费时间？不管怎样，如果这个世界上最优秀的 Android 开发工程师都觉得在 Android 中进行测试很麻烦，那我们这些小菜鸡玩不好测试也是理所当然的了。\n\n多年以来，Android 开发者们为克服在 Android 中难于进行测试的问题绞尽脑汁。Roboletric 就是这些工程师的智慧结晶，它能让开发者们在 JVM 虚拟机上进行 Android 测试。而最近又有博文开始声讨 Fragment，[个中翘楚 Square 就表示](https://corner.squareup.com/2014/10/advocating-against-android-fragments.html)：老子再也不用 Fragment 这种垃圾玩意了，我们要把业务逻辑都转换到新开发的 Mortar & Flow （MVP 开发框架）框架里，用纯 Java 对象进行编程，完全不依赖 Android 平台的 API。毫无疑问，这些 Java 对象在标准的 Java 测试工具中进行测试是非常简单的。\n\n我坚信那些和 Square 站在统一战线上的开发团队肯定也在想办法将 UI 从实际的业务逻辑中剥离为纯 Java对象，为提高应用的可测试性不懈努力。换句话说，我觉得我们可以不在 Android 中进行单元测试，也不用实现依赖于 Android SDK 的测试单元。我们应该做的是重构应用，让我们能够为应用中的代码实现纯 Java 的测试单元，无论最终能不能真正地提高 Android 的可测试性和健壮性，我觉得这都值得一试。\n\n我感觉到这个思路会是治本良方，所以我们要做的，就是将下图这样的 Android 的应用架构\n\n![](http://img.my.csdn.net/uploads/201504/26/1430014189_2164.png)\n\n变成下图这样：\n\n![](http://img.my.csdn.net/uploads/201504/26/1430014189_8490.png)\n\n虽然这个方法可能能从根本上解决问题，但它也有很大的风险，尽管如此，我还是坚持认为这个方法值得一试，因为它能拯救万千挣扎在实现 Android 测试单元的开发者们于水火之中，而且不用强迫他们使用第三方的库，毕竟第三库总会让他们滞后于最新的 Android 系统特性。此外，Kent Beck 认为：可测试性好的代码就是架构优秀的代码，如果他的观点是对的，或许我们还能找到架构应用更好的办法。\n\n在接下来的博文里，我将探索“重构 Android 应用以使它们能轻易地通过标准的 Java 工具进行测试”这个方案的可操作性。\n\n在第一、第二篇博文中，我会侧重阐述在 Android 里进行单元测试为什么会带来如此痛苦的体验。我觉得阻碍 Android 测试方法发展的根本原因就在于：Android 系统本身就难于进行测试。缺乏对 Activity 和 Fragment 的合理注入就是让应用难以测试的根本原因，而且认识到这一点是设计可测试强的应用架构的关键。\n\n在第三篇博文中，我会在细节上探讨一个常见的解耦应用代码和 Android SDK的策略。简单来说，这个策略就是：将所有应用的具体行为交给一个 POJO 对象（Plain Ordinary Java Object）完成，这些 POJO 对象都是 Android 无关的接口的 Android 特定实现。\n\n在第四篇博文中，我会指出实现第二篇博文中提出的策略存在的技术难点，并尝试去挖掘可以解决这些难点的方法。在这些难点中，最大的问题在于内存泄漏和繁复的重用代码。\n\n在最后一篇博文中，我会通过展示我提出的架构为 Android 测试性带来的提高让大家觉得进行这样的技术探索是值得花费时间、精力，并且能获得相应回报的。\n" }, { "path": "issue-8/Custom-Drawables.md", "content": "自定义Drawables\n---\n\n>\n* 原文链接 : [Custom Drawables](http://www.ryanharter.com/blog/2015/04/03/custom-drawables/)\n* 原文作者 : [Ryan Harter](http://www.ryanharter.com/)\n* [译文出自 : 开发技术前线 www.devtf.cn](http://www.devtf.cn)\n* 译者 : [SwinZh](https://github.com/SwinZh) \n* 校对者: [Mr.Simple](https://github.com/bboyfeiyu) \n* 状态 : 完成\n\n\n我们都看过关于为什么你应该适当的使[自定义Views](http://www.ryanharter.com/blog/2014/05/14/using-custom-compound-views-in-android/)和如何能帮助你正确的封装你的应用程序代码的帖子。但非视图相关的部分如何转化为我们apps的其他部分的这种思考方式，我们对此并不非常了解。\n\n在我的应用[Fragment](https://play.google.com/store/apps/details?id=com.pixite.fragment&referrer=utm_source%3Dryanharter.com%26utm_medium%3Dpost%26utm_content%3Dcustom_drawables)中,有些地方我使用自定义Drawables来封装我的逻辑，就像你在customView中做的一样。\n\n##用例##\n\n在Fragment中,有一些使用水平滚动条作为一个选择视图的地方。这意味着该中心图标就是“选中”的图标,整个条目就该平滑的平移进去或平移出。为此，一个好的显示转换将非常棒。\n\n![](http://www.ryanharter.com/images/posts/custom-drawables/example.gif)\n\n虽然这并非完全必要，但我觉得它是一个能让这个滑动更加流畅并增加一个触摸的类在app上的效果。我本可以设置多个imageviews并让他们每个独立出来，但这真是使用自定义drawables的好地方~\n\n##自定义Drawables##\n\n在Android里，Drawables和Views实际上非常的相似。他们有相似的方法,例如padding和bounds(layout),并且都有一个可以被重写的draw方法。就我而言，我需要能够在一个选中的图片和一个未选中的图片之间进行转换基础上的一个值。\n\n在我们的例子中，我们简单地创建一个包含其他Drawables(和方向)的Drawable子类.\n\n\n\n```java\npublic class RevealDrawable extends Drawable {\n public RevealDrawable(Drawable unselected, Drawable selected, int orientation) {\n this(null, null);\n\n mUnselectedDrawable = unselected;\n mSelectedDrawable = selected;\n mOrientation = orientation;\n }\n}\n```\n\n接下来，我们需要设定能够与图片选择过程中相关联的值。幸运的是Drawable内置了这种类型的事件，setLevel(int).\n\n一个Drawable的level是介于0和10000的整数，它只是允许Drawable基于一个值去自定义它的view.在我们的例子中，我们可以定义5000作为图片被选择时的状态值，其他没被选中状态值在5000左右两侧。\nAll we need to do now is to override the draw(Canvas canvas) method to draw the appropriate drawable by clipping the canvas based on the current level.\n现在我们要做的就是重写draw(Canvas canvas)方法，通过基于当前的level裁剪画布去绘制相应的图片。\n\n```java\n@Override\npublic void draw(Canvas canvas) {\n\n // If level == 10000 || level == 0, just draw the unselected image\n int level = getLevel();\n if (level == 10000 || level == 0) {\n mRevealState.mUnselectedDrawable.draw(canvas);\n }\n\n // If level == 5000 just draw the selected image\n else if (level == 5000) {\n mRevealState.mSelectedDrawable.draw(canvas);\n }\n\n // Else, draw the transitional version\n else {\n final Rect r = mTmpRect;\n final Rect bounds = getBounds();\n\n { // Draw the unselected portion\n float value = (level / 5000f) - 1f;\n int w = bounds.width();\n if ((mRevealState.mOrientation & HORIZONTAL) != 0) {\n w = (int) (w * Math.abs(value));\n }\n int h = bounds.height();\n if ((mRevealState.mOrientation & VERTICAL) != 0) {\n h = (int) (h * Math.abs(value));\n }\n int gravity = value < 0 ? Gravity.LEFT : Gravity.RIGHT;\n Gravity.apply(gravity, w, h, bounds, r);\n\n if (w > 0 && h > 0) {\n canvas.save();\n canvas.clipRect(r);\n mRevealState.mUnselectedDrawable.draw(canvas);\n canvas.restore();\n }\n }\n\n { // Draw the selected portion\n float value = (level / 5000f) - 1f;\n int w = bounds.width();\n if ((mRevealState.mOrientation & HORIZONTAL) != 0) {\n w -= (int) (w * Math.abs(value));\n }\n int h = bounds.height();\n if ((mRevealState.mOrientation & VERTICAL) != 0) {\n h -= (int) (h * Math.abs(value));\n }\n int gravity = value < 0 ? Gravity.RIGHT : Gravity.LEFT;\n Gravity.apply(gravity, w, h, bounds, r);\n\n if (w > 0 && h > 0) {\n canvas.save();\n canvas.clipRect(r);\n mRevealState.mSelectedDrawable.draw(canvas);\n canvas.restore();\n }\n }\n }\n}\n```\n\n就这样，我们可基于滑动的位置以简单地设置icon的level,结束了~\n\n```java\nfloat offset = getOffestForPosition(recyclerView, position);\nif (Math.abs(offset) <= 1f) {\n holder.image.setImageLevel((int) (offset * 5000) + 5000);\n} else {\n holder.image.setImageLevel(0);\n}\n```\n\n想要看自定义Drawable源码，请在Github上搜索Gist[here](https://gist.github.com/rharter/34051da57f8a6a0991ff)\n\n" }, { "path": "issue-8/Support Libraries v22.1.0.md", "content": "Support Libraries v22.1.0\n---\n\n> * 原文链接 : [Support Libraries v22.1.0](https://chris.banes.me/2015/04/22/support-libraries-v22-1-0/)\n* 原文作者 : [Chris Banes](https://chris.banes.me/)\n* [译文出自 : 开发技术前线 www.devtf.cn](http://www.devtf.cn)\n* 译者 : [tiiime](https://github.com/tiiime)\n* 校对者: [chaossss](https://github.com/chaossss)\n* 状态 : 完成\n\n\n\n#Support Libraries v22.1.0\n22 Apr 2015\n\n好久不见了啊大家～ 你可能听说了我们已经发布 22.1.0 support libraries 的这个消息，\n这可能是目前为止我们对 support library 改动最大的一次更新。 \n\n在我们开讲前，建议先读一下 Ian Lake 的这篇官方 [blog][official-blog]，里面列出了\n这次更新中所有的新特性。\n\n这篇文章我将重点讲解内部运行的方式和原因，尤其是我完成的部分\n(因为我非常清楚了解这些)。\n\n---\n\n## AppCompat\n\n先从 AppCompat 说起吧，我们在这个版本中对它做了很大的更新。首先，它的重构...\n\n---\n\n\n###Refactoring\n\n在之前的版本中进入 AppCompat 唯一的入口 ActionBarActivity 已经被我们抛弃了。\n也就是说你以后只能使用一组 Activity 视图层，再也不能像 PreferenceActivity 那样使用它了。\n\n我们现在提取出了所有内部内容，并将它们暴露给一个单一委托 API ，\n[AppCompatDelegate][AppCompatDelegate] 。AppCompatDelegate 可以从\n任何提供了 [Window.Callback][Window.Callback] 接口的 Android 对象中构造，\n例如 Activity 或 Dialog 的子类。你可以使用它的静态方法\n [create](https://developer.android.com/reference/android/support/v7/app/AppCompatDelegate.html#create(android.app.Activity, android.support.v7.app.AppCompatCallback)) 创建它。\n\n如果你创建了一个委托，你需要在每次调用它提供的接口时回调到它。\n(例如 `onCreate()`)，不过这很简单，可以提取到一个基类中。\n\n最终，你可以给所有 Activity 的子类附加任何你想要的 AppCompat 的功能。\n\n如果你打算使用 AppCompatDelegate ，我强烈建议你有空看一眼 AppCompatActivity \n的源码。这是一个(极端的)例子介绍了怎样整合 AppCompatDelegate。\n\n大部分人不需要这层自定义，可以像原来那样使用 ActionBarActivity \n那样使用 [AppCompatActivity][AppCompatActivity] 这个类就好。\n\n---\n\n###Dialogs\n\n上面刚刚提到了 Dialog ，你应该也想到了我们还加入了什么。在完成重构工作后，\nDialog 很自然就是我们下一步工作对象。实际上从 decor-setup 角度来看，\n Activity 和 Dialog 这里有一些小的不同。\n \n 这意味着我们终于解决了自 v21 以来 AppCompat 最大的需求：\n material styled dialogs (balalalala~)。\n\n我们现在有了新的 [AppCompatDialog][AppCompatDialog] 类，\n你应该在在引用(or 关联) `Theme.AppCompat.Dialog` 时使用它。\n\n最后，AppCompat 现在也有了它自己的 AlertDialog 实现，来方便构建\nmaterial 样式的 AlertDialog。只要使用\n [android.support.v7.app.AlertDialog][AlertDialog] 就好了，它会自己处理细节部分。\n \n有一点要注意，AppCompat 的 AlertDialog 没有实现框架版本所做的一切。\n它只暴露了在这个 ‘material 世界’ 中有价值的部分。( (╯°□°）╯︵ ┻━┻ )\n\n---\n\n###android:theme\n\n在进入这部分前，请先阅读这篇文章 [Theme vs Style][theme-vs-style]，\n了解下将要讲解内容的基础。\n\n在 AppCompat v21 里，我们提供了一个快速方便的方法设置设置 [Toolbar][toolbar]\n的主题，使用 `app:theme`。\n\n在 v22.1.0 里，我们扩充了它的功能，现在你可以给你的 layout 里的任意视图\n设置主题了。只要使用 `android:theme` 这个属性就好了，可以在 \ncompat 和 framework 之间无缝地切换功能。\n\n最好的一点要数它会自动继承父视图的 theme ，并且兼容所有 API v11 以上的设备。\n一个例子:\n\n```xml\n\n\n \n \n\n\n```\n对于运行 API v10 甚至更老的设备来说，你也可以使用 `android:theme` 属性，\n不过它不会继承父视图 theme 。这就意味着你要么重新考虑你的布局，要么\n为每一个子视图都设置上 `android:theme` 属性。(这样做效率真的很低)\n\n如果你感兴趣的话，开启继承父类 theme 的方法在这里\n [LayoutInflater.Factory2][LayoutInflater.Factory2] 。\n \n ---\n \n###Widgets\n\n如果读过了 Ian 的文章，你可能看到了和 控件着色 (tinting widgets)相关的内容\n(这里还有一些新的内容)。\n\n很好，不过关于这点还有一个变化：我们不会再修改 该平台主题的默认\nwidget 样式了。也就是说如果你使用这个 widget 的 AppCompat \n实现(无论显式还是隐式的)，那么你在 v21 版本之前的设备上只能获取到\n material 样式。在实践中你应该不会看到有什么不同，\n 因为我们会自动插入适当的 AppCompat 的实现。\n\n这样我们就解决了已经使用 material 样式但是没有着色的问题。它出现在 \nwidget 的平台实现使用了我们的样式，并且出现在不同的位置之中时，比如\n Preferences 。\n\n反之，你将会看到当前平台默认的样式 (Holo，etc)。\n虽然这样看起来可能有点奇怪，不过这可比看一个空白未着色的 drawable 好多了。\n\n---\n\n###Theme window features\n现在 AppCompat 预测 窗口主题 flag 时会更严格 ，配合框架更密切。\n\n背后的原因是为我们早些时候提到的 dialogs 提供支持。它们大量使用了\nAppCompat 之前并没有重视的 `windowNoTitle ` 标志。\n\n升级到 v22.1.0 以后，你可能已经遇到过下面的异常：\n\n\tIllegalArgumentException: AppCompat does not support the current theme features\n我在这里回答了解决办法：\n[http://stackoverflow.com/q/29790070/474997][stackoverflow]\n\n---\n\n\n## v4\nsupport libraries 的老祖宗 support-v4 还在继续增长，添加了一些新内容。\n\n### ColorUtils\n[ColorUtils][ColorUtils] 已经从 Palette 中移入到 support-v4里。\n它包含了一些非常好的操作颜色的方法。比如，你可以计算在某个背景中，\n最小的文本颜色 alpha 值：\n\n```java\nint backgroundColor = ...;\nint textColor = Color.WHITE;\nfloat minContrastRatio = 4.5f; // We want a minimum contrast ration of 1:4.5\n\nint minAlpha = ColorUtils.calculateMinimumAlpha(\n textColor, backgroundColor, minContrastRatio);\n\nif (minAlpha != -1) {\n // There is an alpha value which has enough contrast, use it!\n return ColorUtils.setAlphaComponent(textColor, minAlpha);\n}\n```\n还有很多方便的方法，比如颜色合成，计算亮度工具等等。更多信息可以\n去看文档。\n\n---\n\n\n### Drawable 着色\nLollipop 中加入的 Drawable 着色的方法非常好用，可以让你动态的处理着色资源。\n在 v21 support library 中 AppCompat 有它自己的实现，现在我们将它移入到\nsupport-v4 的 [DrawableCompat][DrawableCompat] 之中让大家都可以使用它。\n知道它的工作方式很重要。\n\n```java\nDrawable drawable = ...;\n\n// Wrap the drawable so that future tinting calls work\n// on pre-v21 devices. Always use the returned drawable.\ndrawable = DrawableCompat.wrap(drawable);\n\n// We can now set a tint\nDrawableCompat.setTint(drawable, Color.RED);\n// ...or a tint list\nDrawableCompat.setTintList(drawable, myColorStateList);\n// ...and a different tint mode\nDrawableCompat.setTintMode(drawable, PorterDuff.Mode.SRC_OVER);\n```\n需要注意下在调用完 [DrawableCompat.wrap()][DrawableCompat.wrap] 之后，\n它的返回值和你赋值给它的那个并不是同一个东西。你应该使用\n[DrawableCompat.unwrap( )][DrawableCompat.unwrap] 取出原始 Drawable。\n\n在内部，我们将你的 Drawable 包裹在一个特殊的 ‘tint drawable’ (着色 drawable)\n之中，它会根据指定的色彩自动更新 Drawable 的滤色器。 允许我们处理\n[ColorStateList][ColorStateList] 实例。\n\n---\n\n##Palette\nPalette 在这次发布中也获得了一些更新。首先，我们给它加入了新的 \n[Builder][Palette.Builder] 类来帮助获取 Palette 实例。我们发现\nPalette 与日俱增的 ‘把手’ 和 设置 正在将它的 API 变得复杂难懂。\n使用 Builders 可以显著缓解这个问题。\n\n更加重要的是第二个改变，我们在很大程度上提升了 Palettes 的生成速度。\n在生成 Palette 过程中最耗时的要数 色彩量化这一步，它会读取一张图片中的\n所有像素点，并降低颜色深度到一个很小的色彩数 (通常是 16)。\n\n在这次更新中，我们使用了传统的方式优化色彩量化的性能，比如更少的对象分配，\n更合适的数据结构还有降低算法复杂度。成果很显著～\n\n下面是一些测试数据，在一个使用 ART 的设备上性能大概提升 5 到 6 倍，\n如果是使用 Dalvik 的设备，效果还会更加明显。\n\n Device | 22.0\t\t | 22.1.0 \t| Speedup\n ----------|--------| ------|------\nNexus 6\t\t| 55ms \t| 8ms \t |~6x\nNexus 5 \t\t| 55ms \t| 11ms\t |~5x\nNexus One\t| 1200ms\t| 120ms \t |~10x\n\n> 测试结果并不是很科学，只是给出一个近似的值，不过你懂这个意思的啦。\n\nCover photo:[Scaffolding][cover] by Brett Weinstein\n\n---\n\n[official-blog]:http://android-developers.blogspot.com/2015/04/android-support-library-221.html\n[AppCompatDelegate]:https://developer.android.com/reference/android/support/v7/app/AppCompatDelegate.html\n[Window.Callback]:https://developer.android.com/reference/android/view/Window.Callback.html\n[AppCompatDialog]:https://developer.android.com/reference/android/support/v7/app/AppCompatDialog.html\n[AlertDialog]:https://developer.android.com/reference/android/support/v7/app/AlertDialog.html\n[theme-vs-style]:https://chris.banes.me/2014/11/12/theme-vs-style/\n[toolbar]:https://developer.android.com/reference/android/support/v7/widget/Toolbar.html\n[LayoutInflater.Factory2]:https://developer.android.com/reference/android/view/LayoutInflater.Factory2.html\n[stackoverflow]:http://stackoverflow.com/q/29790070/474997\n[ColorUtils]:https://developer.android.com/reference/android/support/v4/graphics/ColorUtils.html\n[DrawableCompat]:https://developer.android.com/reference/android/support/v4/graphics/drawable/DrawableCompat.html\n[DrawableCompat.wrap]:https://developer.android.com/reference/android/support/v4/graphics/drawable/DrawableCompat.html#wrap(android.graphics.drawable.Drawable)\n[DrawableCompat.unwrap]:https://developer.android.com/reference/android/support/v4/graphics/drawable/DrawableCompat.html#unwrap(android.graphics.drawable.Drawable)\n[ColorStateList]:https://developer.android.com/reference/android/content/res/ColorStateList.html\n[cover]:https://flic.kr/p/GbAqX\n[Palette.Builder]:http://developer.android.com/reference/android/support/v7/graphics/Palette.Builder.html\n[AppCompatActivity]:https://developer.android.com/reference/android/support/v7/app/AppCompatActivity.html" }, { "path": "issue-8/如何在Android上响应各种信息通知.md", "content": "如何在Android上响应各种信息通知\n---\n\n> * 原文链接 : [How to respond to any* messaging notification on Android](https://medium.com/@polidea/how-to-respond-to-any-messaging-notification-on-android-7befa483e2d7)\n* 原文作者 : [Michał Tajchert](https://github.com/tajchert/NotificationResponse)\n* [译文出自 : 开发技术前线 www.devtf.cn](http://www.devtf.cn)\n* 译者 : [MrLoong](https://github.com/MrLoong) \n* 校对者: [bboyfeiyu ](https://github.com/bboyfeiyu) \n* 状态 : 完成 \n\n\n\n有没有想过使用你的代码去回应未知的发送者是多么酷的事情？作为一家痴迷于最新技术的公司，我想和大家一起分享我们的一些研究\n\n如果你是Android用户，你可能会喜欢 [Pushbullet](https://www.pushbullet.com/)这个令人敬畏的App，它是一个越过设备同步你所有的消息的App，包括Pc和Mac，自从二月的更新，它允许回应消息给应用程序，例如Facebook Messenger，Hangouts，Telegram 等等 -难道不让人敬畏？可以确定！并没有易于实施的API接口去实现这些，基本上每一个平台都需要我们实现所有客户的连接，但这不是一个好的解决方案。\n\n作为一个喜欢此功能的用户，我们的工程师Michał Tajchert开始专研这个主题后他的好奇心被Reddit上的一个“它是怎么运行的”问题而引发，这个功能一定已经与Android Wear API发生了连接，作者是这样说的。小提示下，Android Wear是提供给智能手表的平台。更具体的讲，我们并不是谈论关于智能手表全新的数据API或消息API，但除了一些已经存在的小通知。由于Android Wear的介绍，我们可以增添一个被叫做\"WearableExtender\"的小物件，增添一些针对智能手表的功能，像活动页，背景，语音输入等\n\n```java\n\tRemoteInput remoteInput = new RemoteInput.Builder(EXTRA_VOICE_REPLY).build();\n\t \n\tNotificationCompat.Action action =\n\t new NotificationCompat.Action.Builder(...)\n\t .addRemoteInput(remoteInput)\n\t .build();\n\t \n\tNotificationCompat.WearableExtender wearableExtender = new NotificationCompat.WearableExtender().addAction(action);\n\t \n\tNotificationCompat.Builder notificationBuilder = new NotificationCompat.Builder(MainActivity.this).extend(wearableExtender);\n```\n\n在上面的代码我们可以看到，我们已经新建RemoteInput(一个收集语音应答的对象),RemoteInput被作为一个Action添加到我们的WearableExtender对象，最终被添加带Notification他自己本身。如果你有一个显示通知并等待用户我文本响应的App(任何类似的App)，这是一个完美的解决方案对你来说。大多流行App都已经实现了。仅有非常少数的App仍然缺乏这点，像Skype 正在计划添加这个功能在接下来的几周。\n\n![我们使用这个技巧的事例应用程序，当用户点击程序按钮，他将回应Messenger conversation](https://d262ilb51hltx0.cloudfront.net/max/800/1*IlV2iOqJ5L9fgK-6_4l-bg.gif)\n\n我们使用这个技巧的事例应用程序，当用户点击程序按钮，他将回应Messenger conversation\n\n##怎样捕获通知?\n\n在Android上还是比较容易实现的，只要实现你自己的service，继承NotificationListenerService并且实现onNotificationPosted() and onNotificationRemoved()方法，这样任何通知的出现或被取消都会被感知。安全访问通知的完成是通过提示屏幕列表中能访问你的通知和能够选中或取消任何的应用程序通知。对于UX来说这并不是一个好的应用，因为它是全屏幕（所以这样的互动应该离开我们的App），一个更好的模式是有一个列表应程序替代询问我们特殊权限的应用程序窗口。\n\n##让我们看看如何可以访问WearableExtender\n\n第一种方式，这样做实际上是由一些用户在网上发布，从pushbulle源提取，随着一些代码的完善使它工作，这是什么样子的：\n\n```java\n\tBundle bundle = statusBarNotification.getNotification().extras;\n\tfor (String key : bundle.keySet()) {\n\t Object value = bundle.get(key);\n\t \n\t if(\"android.wearable.EXTENSIONS\".equals(key)){\n\t Bundle wearBundle = ((Bundle) value);\n\t for (String keyInner : wearBundle.keySet()) {\n\t Object valueInner = wearBundle.get(keyInner);\n\t \n\t if(keyInner != null && valueInner != null){\n\t if(\"actions\".equals(keyInner) && valueInner instanceof ArrayList){\n\t ArrayList actions = new ArrayList<>();\n\t actions.addAll((ArrayList) valueInner);\n\t for(Notification.Action act : actions) {\n\t if (act.getRemoteInputs() != null) {//API > 20 needed\n\t android.app.RemoteInput[] remoteInputs = act.getRemoteInputs();\n\t }\n\t }\n\t }\n\t }\n\t }\n\t }\n\t}\n```\n\n[WearableExtenderGetter](https://gist.github.com/tajchert/5a45deef2de9d667eb81#file-wearableextendergetter) hosted with ❤ by [GitHub](https://github.com/)\n\n在这里刚刚发生了什么？首先，我们从WearableExtender中的参数分布提取出了Bundle通知，然后我们搜索一个能让我们访问所有Android Wear特殊的功能关键值“android.wearable.EXTENSIONS”，例如页面.....我们正在寻找RemoteInput！为了找到它，我们需要遍历所有的功能。这就是实际的工作，但还是代码看起来很丑并且“hackish”。\n\n![](https://d262ilb51hltx0.cloudfront.net/max/1375/1*BieupTbIh3rfs9hxruOvkQ.png)\n\n##我们能比这做的更好吗?\n\n当然！一行代码获得WearableExtender，会是多么的酷？\n\n```java\n\tWearableExtender wearableExtender = new WearableExtender(statusBarNotification.getNotification());\n```\n[WearableExtenderGetter](https://gist.github.com/tajchert/5a45deef2de9d667eb81#file-wearableextendergetter) hosted with ❤ by [GitHub](https://github.com/)\n\n好的，让我们现在直接提取Actions从RemoteInput中。\n\n```java\n\tList< Action> actions = wearableExtender.getActions();\n\tfor(Action act : actions) {\n\t\tif(act != null && act.getRemoteInputs() != null) {\n\t RemoteInput[] remoteInputs = act.getRemoteInputs();\n\t }\n\t}\n```\n[WearableExtenderGetter](https://gist.github.com/tajchert/5a45deef2de9d667eb81#file-wearableextendergetter) hosted with ❤ by [GitHub](https://github.com/)\n\n好的，但是我们还需要做些什么呢？我们需要PendingIntent发送我们的返回结果给应用程序，使它触发通知并且他也将很好的保持Bundle，因为他可能包含一些额外的价值，例如conversationId，让我们去实现它\n\n```java\n\tnotificationWear.pendingIntent = statusBarNotification.getNotification().contentIntent;\n\tnotificationWear.bundle = statusBarNotification.getNotification().extras;\n```\n\n[WearableExtenderGetter](https://gist.github.com/tajchert/5a45deef2de9d667eb81#file-wearableextendergetter) hosted with ❤ by [GitHub](https://github.com/)\n\n现在我们准备返回它！探究一下我们的事例应用程序，加速POC的开发过程，通过的数据以EventBus为媒介转到Activity被保存在Stack，当用户点击“Respond to last”直接就突出最后题目并且伪造响应文本给它\n\n##填充RemoteInput\n\n大概最有趣的部分是怎么能够填补一个对象，通常需要语音输入我们虚假的文字，它并不是很难。\n\n```java\n\tRemoteInput[] remoteInputs = new RemoteInput[notificationWear.remoteInputs.size()];\n\t \n\tIntent localIntent = new Intent();\n\tlocalIntent.addFlags(Intent.FLAG_ACTIVITY_NEW_TASK);\n\tBundle localBundle = notificationWear.bundle;\n\tint i = 0;\n\tfor(RemoteInput remoteIn : notificationWear.remoteInputs){\n\t getDetailsOfNotification(remoteIn);\n\t remoteInputs[i] = remoteIn;\n\t localBundle.putCharSequence(remoteInputs[i].getResultKey(), \"Our answer\");//This work, apart from Hangouts as probably they need additional parameter (notification_tag?)\n\t i++;\n\t}\n\tRemoteInput.addResultsToIntent(remoteInputs, localIntent, localBundle);\n\ttry {\n\t notificationWear.pendingIntent.send(MainActivity.this, 0, localIntent);\n\t} catch (PendingIntent.CanceledException e) {\n\t Log.e(TAG, \"replyToLastNotification error: \" + e.getLocalizedMessage());\n\t}\n```\n\n我们的notificationWear对象是一个暂时存放所有需要数据来响应特殊通知的容器，然后我们把每一个RemoteInput从我们保存的通知中填充到我们所期望的文本，通过使用putCharSequence()方法在Bundle返回。这里的关键是使用getResultKey()在每一个RemoteInput，因为被调用的程序将在返回Bundle答复文本。最后一步我们需要使Intent移植于RemoteInputs对于那些虚假的回应，让我们使用addResultsToIntent(inputs, intent, bundle)这样做。现在我们准备好所有的数据去触发PendingIntent，触发叫做pendingIntent.send(context, code,intent)的方法。这是全部，我们只是回应在Messenger，Telegraph，Line 或是任何其他使用WearableExtender与RemoteInput的应用程序！这种方法仍然缺少Hangouts，可能需要一些额外的参数，我最好的猜测是在其他Tag中的StatusBarNotification如果其他的（工作）应用程序也是空的。\n\n##帅不？\n\n是的，是这样。仔细看一看Pushbullet是他被允许做的非常好的事情。但是在我们的办公室，值得被的关注的是，用户被提示选择应用程序读取通知和使用这个技巧，我们可以应对任何通知。还有，我们不但可以响应也可以缓存需要被触发的数据，例如，一些用在Messenger中以后使用的对话，同时，潜在的，它允许你发送短信在没有正确权限，因为你“just responded to a notification”和偶然有短信应用程序。现在在Android默认文本消息的应用程序不包括WearableExtender，但也许这只是时间问题，而且Hangouts允许你发送短信。\n\n##时刻保持安全\n\n什么是单向的，可以做其他工作的，这就意味着如果你正在开发一个Wear-enabled用用程序，其他的开发人员可能会回复你的通知，后来出现RemoteInput黑客，让我们想想如何保持安全。最简单的方法是生成一些ID对于每个通知并且允许他们只能使用一次，这样任何应用程序使用这个技巧不会发送过多的消息到你的应用程序。另一个方法是在Bundle中不包括一些参数，但是作为一个例子Tag中的Notification比较后接受。 这可能是我们为什么不能让黑客工作在Hangouts。从另一方面来讲，如果你是使用者你应该更加关注那些曾获取“reading notifications”应用程序，因为他现在也允许应用程序与他们互动。如果你想要一个测验或者帮助我们对于Hangouts的工作，这个样品在[Github](https://github.com/tajchert/NotificationResponse)上\n\n\n" }, { "path": "issue-8/开始学习Material Design.md", "content": "开始学习Material Design\n---\n\n> * 原文链接 : [Android Getting Started with Material Design](http://www.androidhive.info/2015/04/android-getting-started-with-material-design/)\n* 原文作者 : [Ravi Tamada](http://www.androidhive.info/)\n* [译文出自 : 开发技术前线 www.devtf.cn](http://www.devtf.cn)\n* 译者 : [xu6148152](https://github.com/xu6148152) \n* 校对者: [chaossss](https://github.com/chaossss) \n* 状态 : 完成\n\n\n\n\n你可能已经听说过Android Lollipop中引入的Material Design.Material Design引入了很多新的东西，如Material 主题, 新的控件, 自定义阴影, 矢量绘制 and 自定义动画.如果你还没用过Material Design，那么本文很适合你。\n\n我们将在本文中学习Material Design开发的基本步骤:编写自定义主题和用RecyclerView实现navigation drawer.\n\n在下面的链接中，你能够学到更多有关Material Design的知识 \n\n[Material Design Specifications](http://www.google.com/design/spec/material-design/introduction.html#) \n\n[Creating Apps with Material Design](http://developer.android.com/training/material/index.html) \n \n[Code](http://download.androidhive.info/download?code=WPSkdrdZprHT0KLCZS3ClafgXBikGqM4r7FnNYdsdUTmlAkK6%2F2mkT0heOlNOq4U82rzqbod%2F14yU2uk5TWY4Zp%2FAYx6oiD7SKI%2FEgtUapzQUqkqcWEXX1bmw%3D%3DvqARiMEKqkqsXGbVf3vVUoffTqQcD2qfqZo)\n\n[Video](http://www.youtube.com/embed/jDXX_wDvarM)\n\n###1.下载AndroidStudio\n\n再往下走之前，先下载Android Studio，并配置好本文之前提到的东西，如果你是首次使用Android Studio，先去看看文档.\n\n###2.Material Design 颜色自定义\n\nMaterial Deisgin提供以下系列自定义Material Deisign 颜色主题的属性，但本文只使用5种基本属性来自定义整体的主题\n\ncolorPrimaryDark - 这是app中最黑的基本色，主要用来做notification bar的背景.\n\ncolorPrimary - 这是app的基本颜色,将用作toolbar的背景色\n\ntextColorPrimary - 文本颜色,用于toolbar的标题\n\nwindowBackground - app默认的背景颜色\n\nnavigationBarColor - 这个颜色定义了navigation bar页脚的背景色. \n\n![](http://cdn2.androidhive.info/wp-content/uploads/2015/04/android-material-design-color-schema.png)\n\n你能选择适合你APP风格的颜色\n\n###3.创建Material Design 主题\n\n1.在as中，创建新项目,选择BlankActivity.\n\n2.打开res->values->strings.xml 添加以下字符值\n\n \n```xml \nstrings.xml\n \n\n Material Design\n Settings\n Search\n Open\n Close\n \n Home\n Friends\n Messages\n \n \n \n @string/nav_item_home\n @string/nav_item_friends\n @string/nav_item_notifications\n \n \n Messages\n Friends\n Home\n \n``` \n\n3.打开res->values->colors 添加以下颜色,如果你没有找到colors.xml文件，那么新建一个.\n \n```xml \ncolors.xml \n\n \n\n #F50057\n #C51162\n #FFFFFF\n #FFFFFF\n #000000\n #FF80AB\n \n \n``` \n4. 打开 dimens.xml文件，加入以下代码\n \n \n```xml \ndimens.xml\n \n\n \n 16dp\n 16dp\n 260dp \n \n \n```\n\n5.打开styles.xml文件加入以下代码，在这里定义的style对于所有的androidbanben都是通用的。 \n \n```xml \nstyles.xml\n\n \n \n \n \n \n \n```\n\n6.在res目录下，创建一个values-v21目录,并styles.xml\n文件夹,这些style仅仅用于Android Lollipop\n\nstyles.xml \n```xml\n\n \n \n \n \n```\n\n7.现在我们已经准备好Material Design style了， 为了使用这主题, 在AndroidManifest.xml文件中修改application theme属性如下：\n \n```xml \nAndroidManifest.xml\n\n\n \n \n \n \n \n \n \n \n \n \n \n \n```\n\n现在如果你运行app，你能看到notification的颜色已经变成我们在style中设置的颜色.\n\n![](http://cdn4.androidhive.info/wp-content/uploads/2015/04/android-material-design-notification-bar.png)\n\n###3.1 添加工具栏 (Action Bar)\n\n添加toolbar很简单,你要做的只是为toolbar另外创建一个layout,然后你想在哪里显示它，就在那个页面布局中include它\n\n8.在layout目录下创建toolbar.xml, 在里面添加android.support.v7.widget.Toolbar，并设置宽高.代码如下： \n\n```xml\t\ntoolbar.xml\n\n\n```\n\n9.打开你的main activiy的布局,添加如下代码: \n\n \n```xml\t\nactivity_main.xml\n\n \n \n \n \n \n \n \n \n```\n![](http://cdn4.androidhive.info/wp-content/uploads/2015/04/android-material-design-toolbar1.png) \n\n现在让我尝试添加toolbard额标题，并启用它的行为。 \n\n10.下载相关图片资源，然后导入到AS当中作为Image Asset.\n\n11.导入Image asset步骤,右键res目录->new->Image Asset 之后显示弹窗，然后找到你已经下载好的图片,选择Action Bar 和 Tab Icons， 给资源命名为ic_search_action. 如下图 \n\n![](http://cdn3.androidhive.info/wp-content/uploads/2015/04/android-studio-importing-image-asset.png) \n\n12.一旦图片导入了，打开menu_main.xml 添加seach menu item,代码如下： \n\n\n```xml\t\nmenu_main.xml \n\n \n \n \n \n \n```\n\n13.打开MainActivity.java做以下修改.\n\nMainActivity从ACtionBarAcitiv继承\n\n调用setSupportActionBar()来启用toolbar\n\n复写onCreateOptionsMenu() 和 onOptionsItemSelected()来启动toolbar菜单子目录的行为。 \n \n```java \nMainActivity.java\n \n private Toolbar mToolbar;\n \n @Override\n protected void onCreate(Bundle savedInstanceState) {\n super.onCreate(savedInstanceState);\n setContentView(R.layout.activity_main);\n \n mToolbar = (Toolbar) findViewById(R.id.toolbar);\n \n setSupportActionBar(mToolbar);\n getSupportActionBar().setDisplayShowHomeEnabled(true);\n }\n \n \n @Override\n public boolean onCreateOptionsMenu(Menu menu) {\n // Inflate the menu; this adds items to the action bar if it is present.\n getMenuInflater().inflate(R.menu.menu_main, menu);\n return true;\n }\n \n @Override\n public boolean onOptionsItemSelected(MenuItem item) {\n // Handle action bar item clicks here. The action bar will\n // automatically handle clicks on the Home/Up button, so long\n // as you specify a parent activity in AndroidManifest.xml.\n int id = item.getItemId();\n \n //noinspection SimplifiableIfStatement\n if (id == R.id.action_settings) {\n return true;\n }\n \n return super.onOptionsItemSelected(item);\n }\n \n```\n \n添加以上代码后，运行APP，你应该能够看到如下图所示的效果 \n\n![](http://cdn1.androidhive.info/wp-content/uploads/2015/04/android-material-design-toolbar-action-items.png?)\n\n###3.2添加Navigation Drawer \n\n添加Natigation Drawer的方式跟lollipop以前一样,但我们使用RecyclerView来实现Menu Items. \n\n14.在java文件下创建三个包，分别命名为activity,adapter,model,把MainActivity移到activity包种，这样整个项目看起来就更有组织性。 \n\n15.在build.gradle中添加以下依赖库 \n\n \n```gradle \nbuild.gradle\ndependencies {\n compile fileTree(dir: 'libs', include: ['*.jar'])\n compile 'com.android.support:appcompat-v7:22.0.0'\n compile 'com.android.support:recyclerview-v7:21.0.+'\n} \n``` \n\n16.在model包下添加NavDrawerItem.java文件作为menuItem,代码如下： \n \n```java \nNavDrawerItem.java\npublic class NavDrawerItem {\n private boolean showNotify;\n private String title;\n \n \n public NavDrawerItem() {\n \n }\n \n public NavDrawerItem(boolean showNotify, String title) {\n this.showNotify = showNotify;\n this.title = title;\n }\n \n public boolean isShowNotify() {\n return showNotify;\n }\n \n public void setShowNotify(boolean showNotify) {\n this.showNotify = showNotify;\n }\n \n public String getTitle() {\n return title;\n }\n \n public void setTitle(String title) {\n this.title = title;\n }\n} \n```\n\n17.添加nav_drawer_row.xml布局文件,代码如下： \n\n```xml \n\n\n \n \n \n \n```\n\n18.下载这个图片,这图片用在导航栏的头部 \n\n![](http://api.androidhive.info/images/ic_profile.pn)\n \n19.创建另一个布局文件fragment_navigation_drawer.xml,如下代码: \n \n```xml \nfragment_navigation_drawer.xml\n\n \n \n \n \n \n \n \n \n \n \n \n \n\n```\n\n20.由于RecyclerView是自定义的，我们需要创建一个Adapter来渲染自定的布局, 因此创建NavigationDrawerAdapter.java文件 \n\n```java \npublic class NavigationDrawerAdapter extends RecyclerView.Adapter {\n List data = Collections.emptyList();\n private LayoutInflater inflater;\n private Context context;\n \n public NavigationDrawerAdapter(Context context, List data) {\n this.context = context;\n inflater = LayoutInflater.from(context);\n this.data = data;\n }\n \n public void delete(int position) {\n data.remove(position);\n notifyItemRemoved(position);\n }\n \n @Override\n public MyViewHolder onCreateViewHolder(ViewGroup parent, int viewType) {\n View view = inflater.inflate(R.layout.nav_drawer_row, parent, false);\n MyViewHolder holder = new MyViewHolder(view);\n return holder;\n }\n \n @Override\n public void onBindViewHolder(MyViewHolder holder, int position) {\n NavDrawerItem current = data.get(position);\n holder.title.setText(current.getTitle());\n }\n \n @Override\n public int getItemCount() {\n return data.size();\n }\n \n class MyViewHolder extends RecyclerView.ViewHolder {\n TextView title;\n \n public MyViewHolder(View itemView) {\n super(itemView);\n title = (TextView) itemView.findViewById(R.id.title);\n }\n }\n\n```\n\n21.在adapter包下创建FragmentDrawer.java，代码如下： \n\n```java \nFragmentDrawer.java \npublic class FragmentDrawer extends Fragment {\n \n private static String TAG = FragmentDrawer.class.getSimpleName();\n \n private RecyclerView recyclerView;\n private ActionBarDrawerToggle mDrawerToggle;\n private DrawerLayout mDrawerLayout;\n private NavigationDrawerAdapter adapter;\n private View containerView;\n private static String[] titles = null;\n private FragmentDrawerListener drawerListener;\n \n public FragmentDrawer() {\n \n }\n \n public void setDrawerListener(FragmentDrawerListener listener) {\n this.drawerListener = listener;\n }\n \n public static List getData() {\n List data = new ArrayList<>();\n \n \n // preparing navigation drawer items\n for (int i = 0; i < titles.length; i++) {\n NavDrawerItem navItem = new NavDrawerItem();\n navItem.setTitle(titles[i]);\n data.add(navItem);\n }\n return data;\n }\n \n @Override\n public void onCreate(Bundle savedInstanceState) {\n super.onCreate(savedInstanceState);\n \n // drawer labels\n titles = getActivity().getResources().getStringArray(R.array.nav_drawer_labels);\n }\n \n @Override\n public View onCreateView(LayoutInflater inflater, ViewGroup container,\n Bundle savedInstanceState) {\n // Inflating view layout\n View layout = inflater.inflate(R.layout.fragment_navigation_drawer, container, false);\n recyclerView = (RecyclerView) layout.findViewById(R.id.drawerList);\n \n adapter = new NavigationDrawerAdapter(getActivity(), getData());\n recyclerView.setAdapter(adapter);\n recyclerView.setLayoutManager(new LinearLayoutManager(getActivity()));\n recyclerView.addOnItemTouchListener(new RecyclerTouchListener(getActivity(), recyclerView, new ClickListener() {\n @Override\n public void onClick(View view, int position) {\n drawerListener.onDrawerItemSelected(view, position);\n mDrawerLayout.closeDrawer(containerView);\n }\n \n @Override\n public void onLongClick(View view, int position) {\n \n }\n }));\n \n return layout;\n }\n \n \n public void setUp(int fragmentId, DrawerLayout drawerLayout, final Toolbar toolbar) {\n containerView = getActivity().findViewById(fragmentId);\n mDrawerLayout = drawerLayout;\n mDrawerToggle = new ActionBarDrawerToggle(getActivity(), drawerLayout, toolbar, R.string.drawer_open, R.string.drawer_close) {\n @Override\n public void onDrawerOpened(View drawerView) {\n super.onDrawerOpened(drawerView);\n getActivity().invalidateOptionsMenu();\n }\n \n @Override\n public void onDrawerClosed(View drawerView) {\n super.onDrawerClosed(drawerView);\n getActivity().invalidateOptionsMenu();\n }\n \n @Override\n public void onDrawerSlide(View drawerView, float slideOffset) {\n super.onDrawerSlide(drawerView, slideOffset);\n toolbar.setAlpha(1 - slideOffset / 2);\n }\n };\n \n mDrawerLayout.setDrawerListener(mDrawerToggle);\n mDrawerLayout.post(new Runnable() {\n @Override\n public void run() {\n mDrawerToggle.syncState();\n }\n });\n \n }\n \n public static interface ClickListener {\n public void onClick(View view, int position);\n \n public void onLongClick(View view, int position);\n }\n \n static class RecyclerTouchListener implements RecyclerView.OnItemTouchListener {\n \n private GestureDetector gestureDetector;\n private ClickListener clickListener;\n \n public RecyclerTouchListener(Context context, final RecyclerView recyclerView, final ClickListener clickListener) {\n this.clickListener = clickListener;\n gestureDetector = new GestureDetector(context, new GestureDetector.SimpleOnGestureListener() {\n @Override\n public boolean onSingleTapUp(MotionEvent e) {\n return true;\n }\n \n @Override\n public void onLongPress(MotionEvent e) {\n View child = recyclerView.findChildViewUnder(e.getX(), e.getY());\n if (child != null && clickListener != null) {\n clickListener.onLongClick(child, recyclerView.getChildPosition(child));\n }\n }\n });\n }\n \n @Override\n public boolean onInterceptTouchEvent(RecyclerView rv, MotionEvent e) {\n \n View child = rv.findChildViewUnder(e.getX(), e.getY());\n if (child != null && clickListener != null && gestureDetector.onTouchEvent(e)) {\n clickListener.onClick(child, rv.getChildPosition(child));\n }\n return false;\n }\n \n @Override\n public void onTouchEvent(RecyclerView rv, MotionEvent e) {\n }\n }\n \n public interface FragmentDrawerListener {\n public void onDrawerItemSelected(View view, int position);\n }\n}\n```\n\n22.最后在activity_main.xml中添加DrawerLayout，如下代码: \n\n```xml \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n```\n \n现在我们已经完成了所有的的布局和jav文件,接下来我们要实现navigation draw而得功能. \n \n23.打开MainActivity,作如下修改:\n\nMainActivity实现FragmentDrawer.FragmentDrawerListener接口，复写onDrawerItemSelected()\n \n创建FragmentDrawer实例，并设置其选择监听事件,如下代码: \n\n```java \npublic class MainActivity extends ActionBarActivity implements FragmentDrawer.FragmentDrawerListener {\n \n private Toolbar mToolbar;\n private FragmentDrawer drawerFragment;\n \n @Override\n protected void onCreate(Bundle savedInstanceState) {\n super.onCreate(savedInstanceState);\n setContentView(R.layout.activity_main);\n \n mToolbar = (Toolbar) findViewById(R.id.toolbar);\n \n setSupportActionBar(mToolbar);\n getSupportActionBar().setDisplayShowHomeEnabled(true);\n \n drawerFragment = (FragmentDrawer)\n getSupportFragmentManager().findFragmentById(R.id.fragment_navigation_drawer);\n drawerFragment.setUp(R.id.fragment_navigation_drawer, (DrawerLayout) findViewById(R.id.drawer_layout), mToolbar);\n drawerFragment.setDrawerListener(this);\n }\n \n \n @Override\n public boolean onCreateOptionsMenu(Menu menu) {\n // Inflate the menu; this adds items to the action bar if it is present.\n getMenuInflater().inflate(R.menu.menu_main, menu);\n return true;\n }\n \n @Override\n public boolean onOptionsItemSelected(MenuItem item) {\n // Handle action bar item clicks here. The action bar will\n // automatically handle clicks on the Home/Up button, so long\n // as you specify a parent activity in AndroidManifest.xml.\n int id = item.getItemId();\n \n //noinspection SimplifiableIfStatement\n if (id == R.id.action_settings) {\n return true;\n }\n \n return super.onOptionsItemSelected(item);\n }\n \n @Override\n public void onDrawerItemSelected(View view, int position) {\n \n }\n}\n\n```\n \n \n现在运行APP能看到以下效果. \n\n![](http://cdn1.androidhive.info/wp-content/uploads/2015/04/androd-material-design-navigation-drawer.png)\n\n###3.3实现Navigation Drawer的选择 \n\n虽然navigation drawer已经能够工作了，但是MENU的子选项无法工作，这是因为我们还没有处理RecyclerView item是的点击监听。 \n \n由于我们有三子菜单(Home,Friends&Mesages), 因此我们需要创建三个独立的Fragment \n\n24.创建fragment_home布局文件,代码如下： \n\n```xml \nfragment_home.xml\n\n \n \n \n \n \n \n\n``` \n\n25.在activity包下，创建HomeFragment.java文件，代码如下: \n \n```java \npublic class HomeFragment extends Fragment {\n \n public HomeFragment() {\n // Required empty public constructor\n }\n \n @Override\n public void onCreate(Bundle savedInstanceState) {\n super.onCreate(savedInstanceState);\n \n }\n \n @Override\n public View onCreateView(LayoutInflater inflater, ViewGroup container,\n Bundle savedInstanceState) {\n View rootView = inflater.inflate(R.layout.fragment_home, container, false);\n \n \n // Inflate the layout for this fragment\n return rootView;\n }\n \n @Override\n public void onAttach(Activity activity) {\n super.onAttach(activity);\n }\n \n @Override\n public void onDetach() {\n super.onDetach();\n }\n}\n``` \n26.创建另外两个FRAGMENT，跟上面一样 \n\n27.做如下修改.代码如下：\n\ndisplayView方法用来显示menu item选中的页面.这个方法被onDrawerItemSelected()调用. \n\n```java \npublic class MainActivity extends ActionBarActivity implements FragmentDrawer.FragmentDrawerListener {\n \n private static String TAG = MainActivity.class.getSimpleName();\n \n private Toolbar mToolbar;\n private FragmentDrawer drawerFragment;\n \n @Override\n protected void onCreate(Bundle savedInstanceState) {\n super.onCreate(savedInstanceState);\n setContentView(R.layout.activity_main);\n \n mToolbar = (Toolbar) findViewById(R.id.toolbar);\n \n setSupportActionBar(mToolbar);\n getSupportActionBar().setDisplayShowHomeEnabled(true);\n \n drawerFragment = (FragmentDrawer)\n getSupportFragmentManager().findFragmentById(R.id.fragment_navigation_drawer);\n drawerFragment.setUp(R.id.fragment_navigation_drawer, (DrawerLayout) findViewById(R.id.drawer_layout), mToolbar);\n drawerFragment.setDrawerListener(this);\n \n // display the first navigation drawer view on app launch\n displayView(0);\n }\n \n \n @Override\n public boolean onCreateOptionsMenu(Menu menu) {\n // Inflate the menu; this adds items to the action bar if it is present.\n getMenuInflater().inflate(R.menu.menu_main, menu);\n return true;\n }\n \n @Override\n public boolean onOptionsItemSelected(MenuItem item) {\n // Handle action bar item clicks here. The action bar will\n // automatically handle clicks on the Home/Up button, so long\n // as you specify a parent activity in AndroidManifest.xml.\n int id = item.getItemId();\n \n //noinspection SimplifiableIfStatement\n if (id == R.id.action_settings) {\n return true;\n }\n \n if(id == R.id.action_search){\n Toast.makeText(getApplicationContext(), \"Search action is selected!\", Toast.LENGTH_SHORT).show();\n return true;\n }\n \n return super.onOptionsItemSelected(item);\n }\n \n @Override\n public void onDrawerItemSelected(View view, int position) {\n displayView(position);\n }\n \n private void displayView(int position) {\n Fragment fragment = null;\n String title = getString(R.string.app_name);\n switch (position) {\n case 0:\n fragment = new HomeFragment();\n title = getString(R.string.title_home);\n break;\n case 1:\n fragment = new FriendsFragment();\n title = getString(R.string.title_friends);\n break;\n case 2:\n fragment = new MessagesFragment();\n title = getString(R.string.title_messages);\n break;\n default:\n break;\n }\n \n if (fragment != null) {\n FragmentManager fragmentManager = getSupportFragmentManager();\n FragmentTransaction fragmentTransaction = fragmentManager.beginTransaction();\n fragmentTransaction.replace(R.id.container_body, fragment);\n fragmentTransaction.commit();\n \n // set the toolbar title\n getSupportActionBar().setTitle(title);\n }\n }\n}\n``` \n\n现在运行app,你能够选择menu的子菜单了。如下效果。\n\n![](http://cdn1.androidhive.info/wp-content/uploads/2015/04/android-material-design-navigation-drawer-1.png)\n\n![](http://cdn1.androidhive.info/wp-content/uploads/2015/04/android-material-design-navigation-drawer-2.png)\n\n![](http://cdn1.androidhive.info/wp-content/uploads/2015/04/android-material-design-navigation-drawer-3.png)\n" }, { "path": "issue-8/检测Android应用的启动与关闭.md", "content": "检测Android应用的启动与关闭\n---\n\n> * 原文链接 : [Determine when App is Opened or Closed](http://engineering.meetme.com/2015/04/android-determine-when-app-is-opened-or-closed/)\n* 原文作者 : [Bill Donahue](http://engineering.meetme.com/author/bdonahue/)\n* [译文出自 : 开发技术前线 www.devtf.cn](www.devtf.cn)\n* 译者 : [xianjiajun](https://github.com/xianjiajun) \n* 校对者: [Mr.Simple](https://github.com/bboyfeiyu) \n* 校对者: [chaossss](https://github.com/chaossss)\n* 状态 : 完成\n\n\n##问题\n当开发安卓程序的时候，我们不免需要去检测应用什么时候在前台运行，用户什么时候离开。不幸的是，没有一个简单的方法可以做到这点。当用户第一次启动的时候去检测还是不难，但如果是重新打开或关闭就不简单了。\n\n这篇文章将会展示一个用来解决上述问题的技巧。\n\n## 入门指南\n应用的activity是否显示在界面是决定应用是打开还是关闭的核心因素。我们先来看一个简单的例子，一个应用只有一个activity并且不支持横屏，这个activity的onstart和onstop方法就决定了这个应用是打开的还是关闭的。\n\n```java\n@Override\nprotected void onStart() {\n super.onStart();\n // The Application has been opened!\n}\n\n@Override\nprotected void onStop() {\n super.onStop();\n // The Application has been closed!\n}\n```\n\n\n但有个问题，一旦我们支持横屏，上面这个方法就失效了。如果我们旋转设备，这个activity会重新创建，onstart方法会第二次执行，导致程序错误的认为应用第二次被打开。\n\n为了处理设备旋转，我们需要添加一个验证步骤。这个验证需要启动一个计时器，用来检测当activity停止后，我们是否能很快看到该程序另一个activity启动。如果不能，则说明用户推出了程序，否则说明用户还在使用程序。\n\n这样的验证同样支持有多个activity的应用。因为从一个activity跳转到另外一个也可以用这个验证方式处理。\n\n所以利用这个技巧，我创建了一个管理activity的类，当activity的可见性发生变化的时候都要报告给这个管理类。这个类为每个activity处理验证步骤，避免意外的验证。我们同样利用了“发布-订阅”（观察者）模式，使得其他相关的类能够收到程序打开或关闭的通知。\n\n##使用这个管理类的三个步骤\n\n###1) 将下面的代码添加到你的代码库\n\n```java\nimport android.app.Activity;\nimport android.os.Handler;\nimport android.os.Looper;\nimport android.os.Message;\nimport android.support.annotation.NonNull;\nimport android.text.format.DateUtils;\n\nimport java.lang.ref.Reference;\nimport java.lang.ref.WeakReference;\nimport java.util.HashSet;\nimport java.util.Set;\n\n/**\n * 这个类用于追踪当前所有启动的Activity，使得我们能判断应用是否在后台运行。\n */\npublic class AppForegroundStateManager {\n private static final String TAG = AppForegroundStateManager.class.getSimpleName();\n private static final int MESSAGE_NOTIFY_LISTENERS = 1;\n public static final long APP_CLOSED_VALIDATION_TIME_IN_MS = 30 * DateUtils.SECOND_IN_MILLIS; // 30 Seconds\n private Reference mForegroundActivity;\n private Set mListeners = new HashSet<>();\n private AppForegroundState mAppForegroundState = AppForegroundState.NOT_IN_FOREGROUND;\n private NotifyListenersHandler mHandler;\n\n // 获得一个线程安全的类实例\n private static class SingletonHolder {\n public static final AppForegroundStateManager INSTANCE = new AppForegroundStateManager();\n }\n\n public static AppForegroundStateManager getInstance() {\n return SingletonHolder.INSTANCE;\n }\n\n private AppForegroundStateManager() {\n // 在主线程创建一个 handler\n mHandler = new NotifyListenersHandler(Looper.getMainLooper());\n }\n\n public enum AppForegroundState {\n IN_FOREGROUND,\n NOT_IN_FOREGROUND\n }\n\n public interface OnAppForegroundStateChangeListener {\n /** 当应用状态发生改变时这个方法被调用（隐藏到后台或显示到前台） */\n public void onAppForegroundStateChange(AppForegroundState newState);\n }\n\n /** 当 Activity 可见时应该调用这个方法 */\n public void onActivityVisible(Activity activity) {\n if (mForegroundActivity != null) mForegroundActivity.clear();\n mForegroundActivity = new WeakReference<>(activity);\n determineAppForegroundState();\n }\n\n /** 当 Activity 不再可见时应该调用这个方法 */\n public void onActivityNotVisible(Activity activity) {\n /*\n * 前台 Activity 可能会被一个新的 Activity 替换。\n * 如果新 Activity 与前台 Activity 匹配，仅仅清除前台 Activity\n */\n if (mForegroundActivity != null) {\n Activity ref = mForegroundActivity.get();\n\n if (activity == ref) {\n // This is the activity that is going away, clear the reference\n mForegroundActivity.clear();\n mForegroundActivity = null;\n }\n }\n\n determineAppForegroundState();\n }\n\n /** 用于判断应用是否处于前台 */\n public Boolean isAppInForeground() {\n return mAppForegroundState == AppForegroundState.IN_FOREGROUND;\n }\n\n /**\n * 用于判断当前状态，更新追踪的目标，并通知所有观察者状态是否发生了改变\n */\n private void determineAppForegroundState() {\n /* 获取当前状态 */\n AppForegroundState oldState = mAppForegroundState;\n\n /* 决定当前状态 */\n final boolean isInForeground = mForegroundActivity != null && mForegroundActivity.get() != null;\n mAppForegroundState = isInForeground ? AppForegroundState.IN_FOREGROUND : AppForegroundState.NOT_IN_FOREGROUND;\n\n /* 如果新的状态与之前的状态不一样，则之前的状态需要通知所有观察者状态发生了改变 */\n if (mAppForegroundState != oldState) {\n validateThenNotifyListeners();\n }\n }\n\n /**\n * 添加一个用于监听前台应用状态的监听器\n *\n * @param listener\n */\n public void addListener(@NonNull OnAppForegroundStateChangeListener listener) {\n mListeners.add(listener);\n }\n\n /**\n * 移除用于监听前台应用状态的监听器\n *\n * @param listener\n */\n public void removeListener(OnAppForegroundStateChangeListener listener) {\n mListeners.remove(listener);\n }\n\n /** 通知所有监听器前台应用状态发生了改变 */\n private void notifyListeners(AppForegroundState newState) {\n android.util.Log.i(TAG, \"Notifying subscribers that app just entered state: \" + newState);\n\n for (OnAppForegroundStateChangeListener listener : mListeners) {\n listener.onAppForegroundStateChange(newState);\n }\n }\n\n /**\n * 这个方法会通知所有观察者：前台应用的状态发生了改变\n *

\n * 我们只在应用进入/离开前台时立刻监听器。当打开/关闭/方向切换这些操作频繁发生时，我们\n * 简要的传递一个一定会被无视的 NOT_IN_FOREGROUND 值。为了实现它，当我们注意到状态发\n * 生改变，一个延迟的消息会被发出。在这个消息被接收之前，我们不会注意前台应用的状态是否\n * 发生了改变。如果在消息被延迟的那段时间内应用的状态发生了改变，那么该通知将会被取消。\n */\n private void validateThenNotifyListeners() {\n // If the app has any pending notifications then throw out the event as the state change has failed validation\n if (mHandler.hasMessages(MESSAGE_NOTIFY_LISTENERS)) {\n android.util.Log.v(TAG, \"Validation Failed: Throwing out app foreground state change notification\");\n mHandler.removeMessages(MESSAGE_NOTIFY_LISTENERS);\n } else {\n if (mAppForegroundState == AppForegroundState.IN_FOREGROUND) {\n // If the app entered the foreground then notify listeners right away; there is no validation time for this\n mHandler.sendEmptyMessage(MESSAGE_NOTIFY_LISTENERS);\n } else {\n // We need to validate that the app entered the background. A delay is used to allow for time when the application went into the\n // background but we do not want to consider the app being backgrounded such as for in app purchasing flow and full screen ads.\n mHandler.sendEmptyMessageDelayed(MESSAGE_NOTIFY_LISTENERS, APP_CLOSED_VALIDATION_TIME_IN_MS);\n }\n }\n }\n\n private class NotifyListenersHandler extends Handler {\n private NotifyListenersHandler(Looper looper) {\n super(looper);\n }\n\n @Override\n public void handleMessage(Message inputMessage) {\n switch (inputMessage.what) {\n // 解码完成\n case MESSAGE_NOTIFY_LISTENERS:\n /* 通知所有观察者状态发生了改变 */\n android.util.Log.v(TAG, \"App just changed foreground state to: \" + mAppForegroundState);\n notifyListeners(mAppForegroundState);\n break;\n default:\n super.handleMessage(inputMessage);\n }\n }\n }\n}\n```\n\n###2) activity必须通知可见性的改变\n所有的activity都要实现下面的方法来通知管理者其可见性的改变，最好添加到你的base activity中。\n\n```java\n@Override\nprotected void onStart() {\n super.onStart();\n AppForegroundStateManager.getInstance().onActivityVisible(this);\n}\n\n@Override\nprotected void onStop() {\n AppForegroundStateManager.getInstance().onActivityNotVisible(this);\n super.onStop();\n}\n```\n\n###3) 订阅前台的变化\n\n订阅你感兴趣的前台的状态变化。application类的onCreate方法是首先需要订阅的，这样才能保证每次应用进入或退出前台的时候能收到通知。\n\n```java\npublic class MyApplication extends Application {\n @Override\n public void onCreate() {\n super.onCreate();\n AppForegroundStateManager.getInstance().addListener(this);\n }\n\n @Override\n public void onAppForegroundStateChange(AppForegroundStateManager.AppForegroundState newState) {\n if (AppForegroundStateManager.AppForegroundState.IN_FOREGROUND == newState) {\n // App just entered the foreground. Do something here!\n } else {\n // App just entered the background. Do something here!\n }\n }\n}\n```\n\n##深入思考\n有一些细节还需要再讨论。你需要做一些改变来适配你的应用。\n\n##验证时间\n计时器应该隔多久检测一次应用是否真正进入后台。在上面的代码中设置为30秒。\n\n在应用运行的时候，第三方程序的activity可能会出现占满屏幕，比如说google的支付应用或者facebook的登录。这些程序必然会导致你的程序进入后台，因为你应用的activity都没有在前台显示。这种情况并不能当作用户离开了程序，因为他们并没有真正地离开。30秒的超时刚好可以解决这个问题。比如说绝大部分的用户都会在30秒之内完成支付操作，这样他们就不会被当作离开应用。\n\n如果这种情况不适合你，那么我建议你将验证时间设置为4秒。对于那些缓慢的设备来说，这段时间已经足够用来在旋转的时候创建一个activity。\n\n##CPU休眠\n还有一个潜在问题，如果用户在退出应用之后马上就锁屏（或者在应用还在运行的时候锁屏），不能保证CPU有足够长的运行时间来完成后台检测任务。为了确保像预期的一样工作，你需要持有唤醒锁防止CPU休眠，直到应用退出事件得到验证。实际上使用唤醒锁使这个看起来并不是什么大问题。\n\n##论应用如何启动\n到目前为止，我们知道了如何检测应用是什么时候被打开或者关闭的，但是我们还不知道应用是如何被打开的。是用户点击了通知，还是他们点击一个链接，又或者是他们只是从应用图标或最近任务点进来的？\n\n##记录启动方式\n首先我们要在某个地方记录应用打开的方式。在这段代码中，我在application类中添加了一个枚举型变量用来记录应用是如何被打开的。这个建立在上一个例子的基础之上，所以我们打印一下日志，来看看应用是什么时候被打开的和如何被打开的。\n\n```java\npublic class MyApplication extends Application {\n public final String TAG = MyApplication.class.getSimpleName();\n\n public enum LaunchMechanism {\n DIRECT,\n NOTIFICATION,\n URL;\n }\n\n private LaunchMechanism mLaunchMechanism = LaunchMechanism.DIRECT;\n\n public void setLaunchMechanism(LaunchMechanism launchMechanism) {\n mLaunchMechanism = launchMechanism;\n }\n\n @Override\n public void onCreate() {\n super.onCreate();\n AppForegroundStateManager.getInstance().addListener(this);\n }\n\n @Override\n public void onAppForegroundStateChange(AppForegroundStateManager.AppForegroundState newState) {\n if (AppForegroundStateManager.AppForegroundState.IN_FOREGROUND.equals(newState)) {\n // 应用刚进入前台\n Log.i(TAG, \"App Just Entered the Foreground with launch mechanism of: \" + mLaunchMechanism);\n } else {\n // 应用刚进入前台，并设置我们的登录模式为当前的默认状态\n mLaunchMechanism = LaunchMechanism.DIRECT;\n }\n }\n}\n```\n\n##设置启动方式\n现在当用户打开应用时，我们就可以打印出启动的方式，但实际上我们还没有设置它的值。所以下一步就是要在用户通过链接或通知打开应用的时候设置启动方式。如果不是上述两个方式，则说明用户是直接打开应用。\n\n##记录链接点击\n为了记录用户通过点击链接打开应用，需要在某个地方拦截这个链接，加入下面这行代码。确保这行代码在activity的onStart()之前调用的。根据你的代码结构，可能需要把代码添加到很多地方或者一个公用的链接拦截器。\n\n```java\ngetApplication().setLaunchMechanism(LaunchMechanism.URL);\n```\n\n##记录通知事件\n记录从通知进入是有诀窍的。手机显示通知，用户点击它，打开一个被绑定了的PendingIntent。这个诀窍就是在给所有的PendingIntent加一个标志，用来说明这个Intent是来自通知的。换句话说，当intent最终打开activity的时候，我们需要能够检测到这个intent来自于通知的。\n\n下面就是一个创建来自通知的PendingIntent，把下面的代码添加到每一个intent。\n\n```java\n\tpublic static final String EXTRA_HANDLING_NOTIFICATION = \"Notification.EXTRA_HANDLING_NOTIFICATION\";\n\t\n\t// 通过 Extra 可以知道 Activity 是否通过推送启动\n\tintent.putExtra(EXTRA_HANDLING_NOTIFICATION, true);\n```\n\n最后我们还需要做的就是检查每个activity的标志（添加到你的base activity）。如果我们检测到这个标志量，那么就知道这个activity是通过通知产生的，我们可以设置启动方式为通知启动。这个步骤必须在onCreat里面完成，这样它才可以在应用显示到前台(打印启动方式)之前设置值。\n\n```java\n@Override\npublic void onCreate(Bundle savedInstanceState) {\n super.onCreate(savedInstanceState);\n\n Intent intent = getIntent();\n if (intent != null && intent.getExtras() != null) {\n // 判断 Activity 是否由用户点击推送启动\n if (intent.getExtras().getBoolean(EXTRA_HANDLING_NOTIFICATION, false)) {\n // 发出“应用通过用户点击推送启动”的通知\n getApplication().setLaunchMechanism(LaunchMechanism.NOTIFICATION);\n }\n }\n}\n```\n\n终于完成了。现在你不仅可以检测应用什么时候启动或关闭的，还可以检测出它是如何启动的。\n\n\n\n" }, { "path": "issue-9/Android 10ms问题：关于Android音频路径延迟的解释.md", "content": "#Android 10ms问题：关于Android音频路径延迟的解释\n---\n\n> * 原文链接 : [Android’s 10 Millisecond Problem: The Android Audio Path Latency Explainer](http://superpowered.com/androidaudiopathlatency/#axzz3XksxvKDY)\n* 作者 : [Gabor (@szantog) and Patrick (@Pv), founders of Superpowered](http://superpowered.com/)\n* 译者 : [objectlife](https://github.com/objectlife) \n* 校对者: \n* 状态 : \n\n\n 许多手机应用都是非常依赖低音频功能的，比如游戏类，合成软件，DAWs(数字音频工作站)，音频交互应用和模拟乐器应用，以及即将到来的模拟现实应用，所有的这些都因为Apple平台(AppStore+IOS devices)都在得以快速发展，在App Store 和 IOS开发者身上产生的巨大收入在Android上**是不存在的**\n \n \n\n **Android 10ms 问题**了解的不多,但如果在android这个关键点上可以**以一种可接受的方式阻止这类应用产生**甚至发布那将是巨大的技术挑战并且将产生巨大的影响。\n \n \n初创公司和开发者不原意开发那些已成功的IOS app(需要10ms音频延迟)的android版本，他们担心音频的处理结果会给他们的口碑带来负面影响以及给品牌和名声带来重重的一击。\n\n\n这样会失去一部分消费者。因为他们还是非常愿意购买一些这样的android应用，有如目前在ios上的收入数据显示一样不能如愿。当有人考虑解释“下一个十亿”消费者将会成为‘mobile-only’人们会感激问题/机会的规模。\n\n\n\n我们要解决这个问题。这篇文章以一种非常容易理解方式说明了谷歌Nexus 9Android 10毫秒问题。\n\n\n\n###Android's 10ms问题和Android 音频路径延迟是如何影响App开发者和Android厂商的\n\n\n\n尽管音乐类应用占IOS App Store总下裁量的3%，但是在收入方面却是位居游戏和社交类之后第三名。它表明那些在App Store/IOS devices提供低延性能的音乐应用收入不成比例。\n\n\n在安卓方面。那是一个悲伤的故事。在play store音乐类应用的收入从没有挤进前5名。\n\n\n绝大多数的android设备都被高声音延迟蹂躏过。阻止开发者开发应用以满足消费者的强烈需求。\n\n\n同样的由于Android 10ms问题，Google和Android的开发者正在无缘于与Apple和IOS开发者共享的数十亿美元。\n\n\n同款移动设备音频的输入和输出都需要某种处理，延迟是不同的。正如音乐家说的一样。我们人类对于这种10ms的延迟是非常舒适的。只要偏高就会影响我们的舒适度。\n\n\n大多数的Android应用有超过100ms的音频输入延迟和超过200ms的来回(音频的输入和输出)延迟。\n为你提供一个快速理解的说法，就像奥斯卡电影Whiplash中鼓手慢了半拍一样。\n\n下面是一些与音频有关系并且正在遭受10ms延迟的蹂躏的应用。\n\n- 音乐乐器，音效类应用：音乐家不能同时一起使用，就像用Android设备的表演家会慢半拍一样。甚至都不能用于练习。\n- DJs不能表演beat-matching。作为他们耳机中的预听信号会和观众听到的信息有差距。应用起来的效果就像来回滚动并且回声也是非常困难的。\n- 游戏类：声音效果，比如爆炸和枪声都会落后几帧。游戏的声音和画面产生分离感，用户体验非常不佳。不能让玩家获得身临其境的体验。\n- 通讯类：比如Skype。如果两个人同时用一部高延迟的Android手机，综合来说声音延迟比网络延迟更严重。换句话说处理音频流比处理网络数据更浪费时间\n- 模拟现实类：当用户转动他的头部时，声音\"跟随\"的慢了，破坏了这种3D音频体验，你可以下载\"Paul McCartney Google Cardboard app\"这个应用试一下。Google正在丧失与Apple共享数十亿美元VR机会。\n\n\n为了教育和通知科技行业的leaders,应用程序开发人员、技术人员、产品经理、高管、记者、企业家、音乐家、玩家和投资者关于 Android 10ms的问题～还没有从中获取益的那些人，我们在Superpowered发表了你正在阅读的这篇问题概述提供了更简单的消化整个安卓音频链和潜在的瓶颈。\n\n我们的目标是在Android 10ms音频延迟的挑战上我们要团结一起。此外，将其转化为促进创新，更好的用户体验，消费者从Google Play受益，Android开发者，Android的OEM厂商和整个Android生态系统的机会。\n\n###音频延迟说明\n\n\n数字音频延迟的计量有两种有用的计量单位\n\n- Millisecond (ms)，大多数的延迟指的是这种。发生在时间上的单位\n- Sample (or frame)：表示在音频流中的一个离散的数字值（数字）。Sampling是软件如何把像声波一样的连续信号转换成samples的序列。Samples是独立的音频通道的数目。对于一个信道信号，一个sample是指一个号码。对于双信道信号的一个sample装置是指两个数字等。\n\n\n我们在最好的情况下计算音频信号流综合延迟\n\n- 音频位于Android的原生层(Android NDK),并且使用Google推荐的低延迟配置。不幸得是大多的应用都没有遵循Google的低延迟推荐\n- Android设备上使用适当的配置并且可以利用\"Fast Mixer\"路径用于输入和输出音频，除了最近的新款Nexus设备，大多数的其它厂家没有配置Android支持Fast Mixer，所以这些设备的延迟明显高于其它的设备，详情请看[ Superpowered’s Mobile Audio Census and Latency Test App](http://superpowered.com/latency)延迟在更多设备上的测试数据\n\n###Android 5.0 Lollipop 音频路径延迟的说明\n\n\n####模拟音频输入\n\n可能有许多不同的模拟元件，比如前置放大器的内置麦克风。这些模拟​​元件可以被认为是“零延迟”，因为在这种情况下，它们的真实延迟通常是幅度低于1毫秒。\n\n延迟:0\n\n---\n\n####模拟到数字转换(ADC)\n\n音频芯片测量在预定的时间间隔输入音频流和每一次测量变换为号码。这个预定义的时间间隔被称为采样率，以Hz测量。对于大多数Android和iOS设备音频芯片而言我们的[Mobile Audio Census and Latency Test App](http://superpowered.com/latency)表明48000赫兹是本地采样率，这意味着该声频数据流进行采样48000次每秒。\n\n因为ADC实现方式通常包含内过采样滤波器，ADC操作中通常是归为1ms延迟。\n\n现在，该音频流已经被数字化，从这点转向现在的数字音频。数字音频几乎从未行进一个接一个，但相反，在组块中被称为“缓冲器”或“周期”。\n\n延迟：1ms\n\n---\n\n####从音频芯片总线传输至音频驱动\n音频芯片有几个任务。它处理ADC和DAC，互相切换或混合多个输入和输出，适用于音量调节等，它也“群体”离散数字音频样本到缓冲区并处理这些缓冲器传送给操作系统。\n\n音频芯片被USB，PCI，火线等这样的总线连接到CPU，每个总线具有其自己的传输延迟，这取决于其内部缓冲器的大小和缓冲计数。在这里延迟为典型的1毫秒（在内部系统总线的音频芯片）至6毫秒（使用传统USB总线设置的USB声卡）。\n\n延迟：1-6 ms\n\n---\n\n####音频驱动（ALSA，OSS等）\n在大多数情况下，音频驱动程序使用音频芯片接收本地采样率48000赫兹的音频传入“总线缓冲区大小”的环形缓冲器。\n\n该环形缓冲器是平滑总线传输的重要组成部分，并且将总线传输缓冲区大小与操作系统音频堆栈的缓冲区大小相“连接”。环形缓冲器在操作系统音频堆栈的缓冲中处理数据，它自然增加了一些延迟时间。\n\nAndr​​oid是基于Linux的，并且大多数Android设备使用最流行的Linux音频驱动系统-ALSA（高级Linux声音架构）。ALSA处理环形缓冲器步骤如下：\n\n- 音频是从“period size”的环形缓冲器消耗。\n- 环形缓冲器的大小是“period size”的倍数。\n\n例如：\n\n- period size= 480samples。\n- Period count= 2。\n- 环形缓冲区的大小为480×2 = 960samples。\n- 音频输入被接收到的一个period（480samples），而音频堆读取/处理的其他period（480samples）。\n- 延迟为1period，480samples。相当于48000赫兹下的10毫秒。\n\n|\n|\n|环形缓冲区（960samples）|\n|period（480samples）period（480samples）|\n\n\n一个常见的​​时期数为2，但有些系统可能偏高...\n\n延迟：one or more periods\n\n---\n\n####Android的音频硬件抽象层（HAL）\n该HAL作为Android的媒体服务器以及Linux音频驱动程序之间的中间人。HAL的实现是由“移植”Android到设备移动设备的制造商提供的。\n\n实现是开放的，厂商可以自由地创建任何类型的HAL代码。使用预定义的结构与媒体服务器通信。媒体服务器装载HAL和要求用于创建具有可选优选参数，如采样速率，缓冲区大小或音频效果的输入输出流。\n\n注意：HAL能否可以根据所述参数执行取决于媒体服务器必须“适应”HAL。\n\n典型的HAL的实现是tinyALSA，它是用来与ALSA音频驱动程序进行通信。一些厂商认为把这块的音频实现代码进行闭源是很重要的。\n\n在分析Android源代码库开源HAL实现的代码后，我们发现一些音频路径的配置问题以及代码的质量严重的的增加了延迟以及不必要的CPU负载 \n\n一个好的HAL实现应该不添加任何的延迟。\n\n延迟：0 or more samples\n\n---\n\n####Audio Flinger\n\n\nAndroid的媒体服务器包括两个服务：\n\n- AudioPolicy服务处理音频会话和权限处理，如使用或者关闭麦克风。这和iOS的“音频会话处理非常相似。\n- AudioFlinger服务处理数字音频流。\n\nAudio Flinger创建RecordThread，其作为一个应用程序和音频驱动器之间的中间人。它的基本任务是：\n\n- 使用Android HAL从环形缓冲区驱动中获取下一个音频输入缓冲区。\n- 如果应用程序请求与原生不同的采样率重新采样。\n- 如果应用要求与原生不同的缓冲区大小执行额外的缓冲。\n\nAudio Flinger有一个“fast mixer”的路径，如果Android配置了这种方式。如果用户应用程序是使用本地（Android NDK）代码，并建立与本地硬件sample rate and period size设置了音频缓冲队列，没有重采样，额外的缓冲或混合（“MixerThread”)会发生在此步骤。\n\nRecordThread是一种“推”的工作方式，没有任何严格的同步到音频驱动程序。它试图使一个“猜测”何时唤醒和运行，但“推”的方法对放弃更加敏感。低延迟系统始终用“拉”的方式，音频驱动程序通过整个音频链“规定”音频I / O。很明显，当Android操作系统在最初构思，设计和开发时，低延迟的音频不是一个优先事项。\n\n延迟：1 period (best case scenario)\n\n---\n\n####Binder\nAndroid主要进程间通信系统的共享内存是用来传输Audio Flinger和用户应用程序之间的音频缓冲区。这是Android系统的心脏，用于Andr​​oid内部的每个地方。\n\n延迟：0\n\n---\n\n####AudioRecord\n\n现在我们处于用户应用程序的进程之中。AudioRecord实现了应用程序音频输入，这是通过OpenSL ES访问客户端库特性的示例\n\n潜伏期：0+samples\n\n---\n\n####用户应用程序\n最后，音频输入到达了目的地那就是用户的应用程序。\n\n因为输入和输出线程是不一样的，一个用户应用程序必须实现线程之间的环形缓冲区。它的大小为2个periods以上（1 for 音频输入 and 1 for 音频输出），但写得不好的应用程序通常比较暴力，用更多的时间来解决CPU瓶颈。\n\n从这一点来说，我们是我们开始回忆一下音频输出。\n\n延迟：超过1period，近2通常（最理想的情况）\n\n---\n\n####AudioTrack\nAudioTrack实现音频输出的用户应用程序的一面。这是通过OpenSL ES访问客户端库的特性。运行一个定期发送下一个音频缓冲区到Audio Flinger的线程。Android 4.4.4之后，AudioTrack不添加延迟的音频路径，因为它可以被设置为只使用一个缓冲区。\n\n延迟：0+ samples\n\n---\n\n####Binder\n\n同音频输入\n\n延迟：0\n\n---\n\n####Audio Flinger\n创建一个PlaybackThread，其工作方式为RecordThread的音频输入反向。\n\n延迟：1周期（最理想的情况）\n\n---\n\n####Android audio HAL \n同音频输入\n\n延迟:0 or more samples\n\n---\n\n####音频驱动（ALSA，OSS等）\n音频输入与输出的工作方式一样并且使用同一个缓冲区\n\n延迟:one or more periods\n\n---\n\n####从音频驱动总线传输到音频芯片\n与音频输入的总线传输类似，延迟范围是典型的从1 ms到6毫秒。\n\n延迟：1-6毫秒\n\n---\n\n####数字到模拟转换器（DAC）\nADC的反向，数字音频被“转换”成模拟这一点上，对于同种原因的ADC，DAC操作中通常是归为1ms延迟。。\n\n延迟：1ms\n\n---\n\n####模拟音频输出\n\nDAC的输出信号是模拟音频，但它需要额外的组件来驱动连接的设备，比如耳机。类似于模拟音频输入，模拟组件可以被认为是“零延迟”。\n\n延迟：0\n\n---\n\n###Android Audio Path Latency Animation\n![Alt text](http://bit.ly/1I9MKxo)\n\n###Android的音频路径延迟案例分析：Google Nexus 9\n\n到目前为止Nexus9在音频延迟测试中表现得最好\n\n最好的结果是35毫秒是使用USB声卡或直接连接耳机连接器的麦克风输入和输出，一个特殊音频适配器禁用内置麦克风阵列降噪/回馈破坏功能，增加了约〜13毫秒的额外延迟。\n\n因此，使用上述相同的模型，我们来分解一下Nexus 9的35毫秒音频延迟：\n\nGoogle Nexus 9的35ms延迟是如何产生的\n\n|COMPONENT |SAMPLES|MS|\n|:--------|--------:|:--:|\n|ADC||1|\n|Bus||1|\n|ALSA audio driver|256|5.3|\n|Audio Flinger|256|5.3|\n|User Application's Ring Buffer|512|10.6|\n|Audio Flinger|256|5.3|\n|ALSA audio driver|256|5.3|\n|Bus||1|\n|DAC||1|\n|||Result: \t35.8|\n\n\n###About Superpowered\n我们的使命是扩大制造商的创造力和生产力的能力-使其更加的真实-深刻塑造他们，生产者生产出来的东西没有超音频技术是不可能的。\n\n为此，我们正在建设的技术，解决音频瓶颈，这将解决Android的10毫秒问题。\n\nSuperpowered Audio SDK for Android and iOS is\n\n- 跨平台：开发人员可以使用或复用相同的代码在Android，iOS和OSX。\n- 速度快：它在移动设备上，为所有应用提供桌面级的加工和专业音频质量的最高性能的音频DSP。减少CPU负载来提高电池寿命和使应用更顺畅。\n- “push” and “pull” audio stacks处理更好即使是离线。\n- 0延迟：Superpowered的特性和处理不添加任何的延迟。使用Superpowered Audio SDK开发的应用程序在Android和IOS的低音频延迟设备上更容易的运行。\n\n我们很乐意听取您的意见。请将你的建议、意见和问题以邮件方式发给我们。\n\n感谢您的阅读。\n\n-Gabor (@szantog) and Patrick (@Pv), founders of Superpowered\n\nPS 请加入有关Android的10毫秒问题伟大的对话和[黑客新闻](https://news.ycombinator.com/item?id=9386994)。\n\n原文链接:[http://superpowered.com/androidaudiopathlatency/#axzz3XksxvKDY](http://superpowered.com/androidaudiopathlatency/#axzz3XksxvKDY)\n" }, { "path": "issue-9/Android进行单元测试难在哪-part1.md", "content": "Android 进行单元测试难在哪-part1\n---\n\n> * 原文链接 : [WHY ANDROID UNIT TESTING IS SO HARD (PT 1)](http://philosophicalhacker.com/2015/04/17/why-android-unit-testing-is-so-hard-pt-1/)\n* 原文作者 : [Matthew Dupree](http://philosophicalhacker.com/)\n* [译文出自 : 开发技术前线 www.devtf.cn](http://www.devtf.cn)\n* 译者 : [chaossss](https://github.com/chaossss) \n* 校对者: [tiiime](https://github.com/tiiime) \n* 状态 : 完成\n\n\n\n正如我在[序](issue-8/Android 进行单元测试难在哪-序.md)中所说，在 Android 中难于进行测试是众多 Android 开发者的共识。上一篇博文发出后，有许多同行回复了我，并对我的观点表示支持：\n\n> — Andy Dyer (@dammitandy) April 13, 2015\n\n> @philosohacker大大发话了！他写了一篇有关如何能更好地测试 Android 应用的博文，[地址戳我](http://t.co/gQCJKIOrSN)\n> — Andy Dyer (@dammitandy) April 13, 2015\n\n> 卧槽，我终于知道在 Android 上测试应用的正确姿势了！感谢：[地址戳我](http://t.co/8gIqfoFVnL)\n\n> 非常赞同“Android SDK 排斥 Android 测试单元”的看法。你应该让你的代码和 SDK 的的联系尽可能地小。\n\n> — Pascal Hartig (@passy) April 12, 2015\n\n所以在 Android 中进行单元测试困难的问题，我提到的这些已经说得足够清楚了。但事实上，问题的根源比这更显而易见。难于进行单元测试的一部分原因是：为了启动 Roboletric 使你的测试单元能够以一种合理的速度运作，你往往需要做许多繁复且没有意义的事。不过在我看来，这并不是关键因素，关键在于：Google 设计的 Android SDK 和 Google 官方提倡的应用架构模式让测试变得困难，在某些情况下，进行测试甚至是不可能的。\n\n这样说可能让人感觉是泛泛而谈，为了证明我的结论，我今天将会用一整个系列的博文来论证我的观点。在接下来的博文里，我会尽可能解释为什么官方鼓励的应用开发方式会使进行单元测试困难，甚至不可能。除此以外，我还会在这些博文里通过重构应用架构探索增强 Android 可测试性的办法，使得应用的代码不需要直接依赖于 Android SDK。通过介绍 Android 怎么让测试变得困难，我会延伸出我想到的重构应用的几个建议，我会在系列博文的第四篇里把它们列出来。\n\n## 一个（看似）简单的测试示例\n\n要分析这个问题，我们不妨先从一个简单的测试范例开始研究。示例里面用的是 Google IOsched 应用的源码，因为我在第一篇博文里就说道：IOsched 就是 Android 开发者的参考模板。\n\nIOsched 应用里有一个有关 IO 大会细节的页面：\n\n![](https://philosophicalhacker.files.wordpress.com/2015/04/screenshot-0646am-apr-17-2015.png?w=169&h=300)\n\n页面里有一个“+”按钮，我们能通过这个按钮将 IO 大会添加日历的对应日期里，如果 IO 大会已经被添加到日历中，“+”按钮则会变成“check”按钮；如果用户再次点击“check”按钮，IO 大会则会从日历中被移除。打开相应的源码我们会发现：这个按钮的状态储存在一个叫作 mStarred 的实例变量里，Activity 会根据按钮的状态启动一个 Service，Service 将在它的 onStop() 方法中将对应的 IO 大会添加到用户的日历中/将对应的 IO 大会从用户的日历中移除。\n\n```java\n@Override\npublic void onStop() {\n super.onStop();\n if (mInitStarred != mStarred) {\n if (UIUtils.getCurrentTime(this) < mSessionStart) {\n // Update Calendar event through the Calendar API on Android 4.0 or new versions.\n Intent intent = null;\n if (mStarred) {\n // Set up intent to add session to Calendar, if it doesn't exist already.\n intent = new Intent(SessionCalendarService.ACTION_ADD_SESSION_CALENDAR,\n mSessionUri);\n intent.putExtra(SessionCalendarService.EXTRA_SESSION_START,\n mSessionStart);\n intent.putExtra(SessionCalendarService.EXTRA_SESSION_END,\n mSessionEnd);\n intent.putExtra(SessionCalendarService.EXTRA_SESSION_ROOM, mRoomName);\n intent.putExtra(SessionCalendarService.EXTRA_SESSION_TITLE, mTitleString);\n } else {\n // Set up intent to remove session from Calendar, if exists.\n intent = new Intent(SessionCalendarService.ACTION_REMOVE_SESSION_CALENDAR,\n mSessionUri);\n intent.putExtra(SessionCalendarService.EXTRA_SESSION_START,\n mSessionStart);\n intent.putExtra(SessionCalendarService.EXTRA_SESSION_END,\n mSessionEnd);\n intent.putExtra(SessionCalendarService.EXTRA_SESSION_TITLE, mTitleString);\n }\n intent.setClass(this, SessionCalendarService.class);\n startService(intent);\n \n if (mStarred) {\n setupNotification();\n }\n }\n }\n}\n```\n\n在这样的代码里写一个测试单元看起来是个明智的选择，但问题就来了：你无法为这样的代码写一个测试单元。你可能就不懂了，为什么不能写啊？别急，为了找到问题所在，我们不妨回到 Android 系统里，并想一想通常情况下，是什么让代码可以被测试。\n\n我们都知道，一个测试单元包含了三个步骤：准备，测试，断言。为了顺利地展示我们测试中的断言步骤，我们需要获得程序在执行测试步骤中的代码后的状态。我们不妨将这个状态称为“测试后状态”。对一个测试单元来说，只有三种办法能获得测试后状态。\n\n第一种办法就是检查测试步骤中执行的方法的返回值，写下这样的测试代码倒不难：\n\n```java\npublic void testSquare() {\n \n MathNerd mathNerd = new MathNerd();\n \n int result = mathNerd.square(2);\n \n assertEquals(result, 4);\n}\n```\n\n第二种办法就是获得被测试对象中那些可访问的属性的引用，并断言你取得的这些属性就是你想要的：\n\n```java\npublic void testSquare() {\n \n MathNerd mathNerd = new MathNerd();\n \n int result = mathNerd.square(2);\n \n assertTrue(mathNerd.didDoMath());\n}\n```\n\n第三种办法是检查对象中被注入的依赖的状态。这些依赖或许是不可访问的，但因为你在测试函数中对它们进行注入，那么你肯定会持有它们的引用\n\n```java\npublic void testSquare() {\n \n Calculator calculator = new Calculator();\n \n TerribleMathStudent terribleMathStudent = new TerribleMathStudent(calculator);\n \n //terribleMathStudent uses calculator to do this\n int result = terribleMathStudent.square(2);\n The IOsched app has a IO session detail screen that looks like this:\n assertTrue(calculator.didDoMath());\n}\n```\n\n那么我们现在已经把能够在一个测试单元中完成断言步骤的方法都列出来了，接下来就该解释为什么刚刚的 Android 代码无法被测试了：答案很简单，我们根本没有办法在 onStop() 方法里完成测试单元的断言步骤——因为 onStop() 方法根本就没有返回值。SessionDetailActivity 里也不存在能帮助我们验证 SessionCalendarService 是否通过正确的命令启动的可访问属性。最后，启动 SessionCalendarService 的代码也不属于注入到 SessionDetailActivity 中的依赖。\n\n你以为这样就完了吗？很不幸，还有比这更糟糕的。在 onStop() 里完成测试单元的准备步骤也是不可能的。为了在测试单元中完成准备步骤，你必须能够改变影响程序测试后状态的所有因素，不妨把它们叫作“预测试状态”。而我们没有任何办法能够在 onStop() 方法里改变预测试状态，所以我们不能对应用进行单元测试。\n\nonStop() 方法里，预测试状态是一个叫作 mInitStarred 的布尔值，你看看写在 onStop() 里的代码估计就懂我的意思了：\n\n```java\n@Override\npublic void onStop() {\n super.onStop();\n if (mInitStarred != mStarred) {\n if (UIUtils.getCurrentTime(this) < mSessionStart) {\n // Update Calendar event through the Calendar API on Android 4.0 or new versions.\n Intent intent = null;\n if (mStarred) {\n // Set up intent to add session to Calendar, if it doesn't exist already.\n intent = new Intent(SessionCalendarService.ACTION_ADD_SESSION_CALENDAR,\n mSessionUri);\n intent.putExtra(SessionCalendarService.EXTRA_SESSION_START,\n mSessionStart);\n intent.putExtra(SessionCalendarService.EXTRA_SESSION_END,\n mSessionEnd);\n intent.putExtra(SessionCalendarService.EXTRA_SESSION_ROOM, mRoomName);\n intent.putExtra(SessionCalendarService.EXTRA_SESSION_TITLE, mTitleString);\n } else {\n // Set up intent to remove session from Calendar, if exists.\n intent = new Intent(SessionCalendarService.ACTION_REMOVE_SESSION_CALENDAR,\n mSessionUri);\n intent.putExtra(SessionCalendarService.EXTRA_SESSION_START,\n mSessionStart);\n intent.putExtra(SessionCalendarService.EXTRA_SESSION_END,\n mSessionEnd);\n intent.putExtra(SessionCalendarService.EXTRA_SESSION_TITLE, mTitleString);\n }\n intent.setClass(this, SessionCalendarService.class);\n startService(intent);\n \n if (mStarred) {\n setupNotification();\n }\n }\n }\n}\n```\n\n这个布尔值会在 ContentProvider 的查询操作完成后通过回调方法被设置：\n\n```java\nprivate void onSessionQueryComplete(Cursor cursor) {\n \n final boolean inMySchedule = cursor.getInt(SessionsQuery.IN_MY_SCHEDULE) != 0;\n \n //...\n \n if (!mIsKeynote) {\n showStarredDeferred(mInitStarred = inMySchedule, false);\n }\n \n //...\n}\n```\n\n让 mInitStarred 在 Loader 回调方法里被初始化的原因是：如果用户向他们的日历添加了在 SessionDetailActivity 中选择的 IO 大会事件，那么用于标识该 IO 大会是否被添加到用户日历中的变量将会被存储到数据库中包含所有 IO 大会的表中。我们都知道，Google 希望我们使用 Loader 去获得数据库中的数据，所以 mInitStarred 在 Loader 回调方法里被初始化。\n\n> 注：但是 Google 自己用 Loader 取数据都非常困难，详见视频：[Click me!](https://www.youtube.com/watch?v=qrPoIF6A9gM)\n\nmInitStarred 用于判断应用是否必须启动 SessinCalendarService 更新用户的日历，添加/移除某个 IO 大会的信息。如果从数据库中查询获得的信息表示用户的日历已经添加了该大会，而且添加按钮已经转换为“check”，我们就不需要进行任何操作。\n\n所以，如果我们要在 onStop() 方法里进行测试，我们想要确定 onStop() 方法是否真正启动了一个根据“+”按钮的状态去更新用户日历的 Service。但很不幸，mInitStarred 是一个在 Loader 回调中被初始化的私有实例变量，如果要在测试单元里改变它的值，一定会非常麻烦。那我们现在不妨再来想想改变测试单元预测试状态的办法。\n\n第一个办法是，改变影响对象预测试状态的公有属性：\n\n> 注：改变测试状态的公有属性显然有很多办法。但如果，我举个例子，预测试状态由被测试对象的依赖决定，那我们当然也可以通过改变对象依赖的公有属性改变被测试对象的预测试状态。\n\n```java\npublic void testSquare() {\n \n TerribleMathStudent terribleMathStudent = new TerribleMathStudent();\n terribleMathStudent.setCalculator(new BrokenCalculator());\n \n //terribleMathStudent uses broken calculator to do this, so this student really sucks\n int result = terribleMathStudent.square(2);\n \n assertNotEquals(result, 4);\n \n //we pity the terrible math student, so we give him a working calculator\n terribleMathStudent.setCalculator(new Calculator());\n \n result = terribleMathStudent.square(2);\n \n assertEquals(result, 4);\n}\n```\n\n第二个办法是改变传入被测试方法的参数：\n\n```java\npublic void testSquare() {\n \n MathNerd mathNerd = new MathNerd();\n \n //Math nerds only use calculators when they need them\n int result = mathNerd.squareBigNumber(new BrokenCalculator(), 54321);\n \n assertNotEquals(result, 2950771041);\n \n result = mathNerd.squareBigNumber(new Calculator(), 54321);\n \n assertEquals(result, 2950771041);\n}\n```\n\n就像改变测试后状态一样，这两个办法都不能解决我们的问题，所以我们根本不可能在 onStop() 方法里面完成测试单元的准备步骤，问题的根源在于：SessionDetailActivity 里根本不存在能用于改变 mInitStarred 的公有属性。除此以外，onStop() 方法也不会把 mInitStarred 当作一个参数，所以我们无法通过改变 onStop() 的参数值来改变预测试状态。\n\n## 结论\n\n经过上面一系列源码的分析，每一个希冀进行单元测试的开发者都站在了悬崖的边缘上：即便是 Google 官方所谓的开发模板应用 - IOsched 中一个看起来非常简单的模块，要进行单元测试都困难重重。如果你曾经为了在 Activity 里为你的业务逻辑添加相应的测试单元绞尽脑汁，我现在可以告诉你为什么会这么蛋疼：大部分情况下，要在 Activity 里添加相应的测试单元只是不能实现而已。某些情况下，因为你没有办法改变被测试对象的预测试状态，使得你无法完成单元测试的准备步骤。在另一些情况下，因为你无法访问相关的测试后状态，使得你无法完成对象的断言步骤。而 SessionDetailActivity 的 onStop() 方法就是完美的示例，因为上面的两种情况在它身上体现地淋漓尽致。\n\nAndroid 里还有许多类似的代码也是无法测试的，这让我不禁怀疑：让我们写下无法测试的代码的罪魁祸首，会不会就是带有 Android 平台特性的应用架构方式。所以在下一篇博文里，我将会深入探索这个假设。\n" }, { "path": "issue-9/NotRxJava懒人专用指南.md", "content": "NotRxJava懒人专用指南\n---\n\n> * 原文链接 : [NotRxJava guide for lazy folks](http://yarikx.github.io/NotRxJava/)\n* 原文作者 : [Yaroslav Heriatovych](http://yarikx.github.io/)\n* [译文出自 : 开发技术前线 www.devtf.cn](http://www.devtf.cn)\n* 译者 : [Rocko](https://github.com/Rocko) \n* 校对者: [Mr.Simple](https://github.com/bboyfeiyu) \n* 状态 : 完成校对\n\n\n\n如果你是一位 Android 开发者，那么这些天你可能已经听到或看到一些关于 RxJava 满天飞的宣传了。RxJava 是一个能让你摆脱编写一些复杂繁琐的代码去处理异步事件的库。一旦开始在你的项目中使用，你会对它爱不释手的。\n\n然而，RxJava 有个缺陷，它需要一个陡峭的学习过程。对于一个从未接触使用过 RxJava 的人来说，是很难一次就领会到它的精髓所在的，对于它的一些使用方法你也可能会很迷惑。在项目中使用它意味着你需要稍微地改变一下你的代码编写思路，另外，这样的学习曲线会使得在项目中因为大规模的使用RxJava而引发一些问题。\n\n当然，关于如何去使用 RxJava 已经有许多的教程和代码范例了。感兴趣的开发者可以访问 RxJava 的官方 [Wiki](https://github.com/ReactiveX/RxJava/wiki)，里面有关于什么是 Observable 以及它和 Iterable、Future 之间关系的很好的解释。Wiki 里有一篇很有用的文章：[How To Use RxJava](https://github.com/ReactiveX/RxJava/wiki/How-To-Use-RxJava)，这篇文章包含怎么去发送事件流并且打印出它们的介绍以及它的样例代码。\n\n但我们要明确的是在还没有学习什么是 Observable 的前提下了解 RxJava 用来解决什么问题以及它是怎么帮助我们组织起异步代码的。\n\n我这篇文章的定位就是 RxJava 官方文档的“前篇”，读完这篇文章能更好地去理解 RxJava 所解决的问题。文章中也有一个小 Demo，就是自己怎么去整理那些凌乱的代码，然后看看我们在没有使用 RxJava 的情况下是怎么去遵循 RxJava 基本原则的。\n\n所以，如果你仍有足够的好奇的话就让我们开始吧！\n\n\n## Cat 应用程序\n\n让我们来创建一个真实世界的例子。我们都知道猫是我们技术发展的引擎，所以就让我们也来创建这么一个用来下载猫图片的典型应用吧。\n\n**任务描述**\n\n> 我们有个 Web API，能根据给定的查询请求搜索到整个互联网上猫的图片。每个图片包含可爱指数的参数（描述图片可爱度的整型值）。我们的任务将会下载到一个猫列表的集合，选择最可爱的那个，然后把它保存到本地。\n\n我们只关心下载、处理和保存猫的数据。\n\n我们开始吧~\n\n\n## 模型和 API\n\n下面是描述“猫”的简单数据结构：\n\n``` Java\npublic class Cat implements Comparable{\n Bitmap image;\n int cuteness;\n\n @Override\n public int compareTo(Cat another) {\n return Integer.compare(cuteness, another.cuteness);\n }\n}\n```\n\n还有我们传统阻塞式风格的 API，它被打包进 cat-sdk.jar 中了：\n\n``` Java\npublic interface Api {\n List queryCats(String query);\n Uri store(Cat cat);\n}\n```\n\n这足够清楚了吗？当然！那就让我们开始编写业务逻辑吧：\n\n``` Java\npublic class CatsHelper {\n\n Api api;\n\n public Uri saveTheCutestCat(String query){\n List cats = api.queryCats(query);\n Cat cutest = findCutest(cats);\n Uri savedUri = api.store(cutest);\n return savedUri;\n }\n\n private Cat findCutest(List cats) {\n return Collections.max(cats);\n }\n}\n```\n\n唉，这样清晰简单的代码帅到让我窒息啊。来理清一下代码的炫酷之处吧。主方法 saveTheCutestCat 只包含了 3 个其它方法，然后花个几分钟来看看代码和思考这些方法。你给方法提供了输入参数然后就能得到结果返回了，在这个方法工作的时候我们需要等待它的完成。\n\n简洁而有用，让我们再看看组合方法的其它优势：\n\n**组合**\n\n正如我们看到的，根据其它 3 个方法而新创建了一个方法（` saveTheCutestCat `），因此我们组合了它们。像乐高积木那样，我们把方法之间连接起来组成了乐高积木（实际上可以在之后组合起来）。组合方法是很简单的，从一个方法得到返回结果然后再把它传递给另外的方法做为输入参数，这不简单吗？\n\n**错误的传递**\n\n另外一个好处就是我们处理错误的方式了。任何一个方法都可能因执行时发生错误而被终止，这个错误能在任何层次上被处理掉，Java 中我们叫它抛出了异常，然后这个错误在 try/catch 代码块中做处理。这里的关键点是我们不需要为组合方法里的每个方法都做异常处理，仅需要对这些组合起来的方法做统一处理，像下面这样：\n\n``` Java\ntry{\n List cats = api.queryCats(query);\n Cat cutest = findCutest(cats);\n Uri savedUri = api.store(cutest);\n return savedUri;\n} catch (Exception e) {\n e.printStackTrace()\n return someDefaultValue;\n}\n```\n\n这个情况下，我们处理了所有执行时的错误，或者说如果我们没有使用 try/catch 代码块我们能够把错误传递到下一个层次上。\n\n\n## 走向异步\n\n要知道我们身在一个对等待很敏感的世界里，我们也知道不可能只有阻塞式的调用。在 Android 中我们也总需要处理异步代码。\n\n拿 Android 的 ` OnClickListener ` 举个例子，当你需要处理一个控件的点击事件时，你必须提供一个监听器（回调）以供在用户点击控件时被调用。这没有理由使用阻塞的方式去接受点击事件的回调，所以对点击来说总是异步的。现在，让我们也使用异步编程吧。\n\n\n**异步的网络调用**\n\n开始想象下使用没有阻塞的 HTTP client（例如[Ion](https://github.com/koush/ion)），还有就是我们的` cats-sdk.jar `已经更新。它的 API 也换成了异步的方式调用。\n\n新 API 的接口：\n\n``` Java\npublic interface Api {\n interface CatsQueryCallback {\n void onCatListReceived(List cats);\n void onError(Exception e);\n }\n\n\n void queryCats(String query, CatsQueryCallback catsQueryCallback);\n\n Uri store(Cat cat);\n}\n```\n\n所以现在我们能异步的获取猫的信息集合列表了，返回正确或错误的结果时都会通过 ` CatsQueryCallback `回调接口。\n\n因为 API 改变了所以我们也不得不改变我们的` CatsHelper `:\n\n``` Java\npublic class CatsHelper {\n\n public interface CutestCatCallback {\n void onCutestCatSaved(Uri uri);\n void onQueryFailed(Exception e);\n }\n\n Api api;\n\n public void saveTheCutestCat(String query, CutestCatCallback cutestCatCallback){\n api.queryCats(query, new Api.CatsQueryCallback() {\n @Override\n public void onCatListReceived(List cats) {\n Cat cutest = findCutest(cats);\n Uri savedUri = api.store(cutest);\n cutestCatCallback.onCutestCatSaved(savedUri);\n }\n\n @Override\n public void onQueryFailed(Exception e) {\n cutestCatCallback.onError(e);\n }\n });\n }\n\n private Cat findCutest(List cats) {\n return Collections.max(cats);\n }\n}\n```\n\n现在我们已经不能使用阻塞的 API 了，我们也不能把我们的客户端上写成阻塞式的调用（实际上是可以的，但需要明确的在线程中使用` synchronized `、` CountdownLatch `、等等，也需要在下层中使用异步处理）。所以我们不能在 ` saveTheCutestCat `方法中直接返回一个值，我们需要对它进行异步回调处理。\n\n让我们再深入一点，如果我们 API 的两个方法调用都是异步的，举个例子，我们正在使用非阻塞IO去写进一个文件。\n\n``` Java\npublic interface Api {\n interface CatsQueryCallback {\n void onCatListReceived(List cats);\n void onQueryFailed(Exception e);\n }\n\n interface StoreCallback{\n void onCatStored(Uri uri);\n void onStoreFailed(Exception e);\n }\n\n\n void queryCats(String query, CatsQueryCallback catsQueryCallback);\n\n void store(Cat cat, StoreCallback storeCallback);\n}\n```\n\n还有我们的 helper：\n\n``` Java\npublic class CatsHelper {\n\n public interface CutestCatCallback {\n void onCutestCatSaved(Uri uri);\n void onError(Exception e);\n }\n\n Api api;\n\n public void saveTheCutestCat(String query, CutestCatCallback cutestCatCallback){\n api.queryCats(query, new Api.CatsQueryCallback() {\n @Override\n public void onCatListReceived(List cats) {\n Cat cutest = findCutest(cats);\n api.store(cutest, new Api.StoreCallback() {\n @Override\n public void onCatStored(Uri uri) {\n cutestCatCallback.onCutestCatSaved(uri);\n }\n\n @Override\n public void onStoreFailed(Exception e) {\n cutestCatCallback.onError(e);\n }\n });\n }\n\n @Override\n public void onQueryFailed(Exception e) {\n cutestCatCallback.onError(e);\n }\n });\n }\n\n private Cat findCutest(List cats) {\n return Collections.max(cats);\n }\n}\n```\n\n现在再来看看代码，跟之前一样优雅吗？明显不是了，这很糟糕！现在它有了更多无关代码和花括号，但是逻辑是一样的。\n\n那么组合在哪呢？他已经不见了！现在你不能像之前那样组合操作了。对于每一个异步操作你都必须创建出回调接口并在代码中插入它们，每一次都需要手动地加入！\n\n错误传递又在哪？又是一个否定！在这样的代码中错误不会自动地传递，我们需要在更深一层上通过自己手动地再让它传递下去（请看` onStoreFailed `和`onQueryFailed `方法）。\n\n我们很难对这样的代码进行阅读和找出潜在的 bugs。\n\n\n**结束了？**\n\n结束了又怎样？我们能拿它来干嘛？我们被困在这个没有组合回调的地狱里了吗？前方高能，请抓紧你的安全带哦，我们将努力的去把这些干掉！\n \n\n## 更美好的世界！\n\n### 泛型回调\n\n可以从我们的回调接口中找到共同的模式：\n\n- 都有一个分发结果的方法（` onCutestCatSaved `,` onCatListReceived `,` onCatStored `）\n\n- 它们中大多数（在我们的例子中是全部）有一个用于错误处理的方法（` onError `,` onQueryFailed `,` onStoreFailed `）\n\n所以我们可以创建一个泛型回调接口去替代原来所有的接口。但是我们不能去改变 API 的调用方法的签名，我们必须创建包装类来间接调用。\n\n所以我们的泛型回调接口看起来是这样的：\n\n``` Java\npublic interface Callback {\n void onResult(T result);\n void onError(Exception e);\n}\n```\n\n然后我们来创建` ApiWrapper `来改变一下调用方法的签名：\n\n``` Java\npublic class ApiWrapper {\n Api api;\n\n public void queryCats(String query, Callback> catsCallback){\n api.queryCats(query, new Api.CatsQueryCallback() {\n @Override\n public void onCatListReceived(List cats) {\n catsCallback.onResult(cats);\n }\n\n @Override\n public void onQueryFailed(Exception e) {\n catsCallback.onError(e);\n }\n });\n }\n\n public void store(Cat cat, Callback uriCallback){\n api.store(cat, new Api.StoreCallback() {\n @Override\n public void onCatStored(Uri uri) {\n uriCallback.onResult(uri);\n }\n\n @Override\n public void onStoreFailed(Exception e) {\n uriCallback.onError(e);\n }\n });\n }\n}\n```\n\n所以这仅仅是对于` Callback `的一些传递 resuts/errors 的调用转发逻辑。\n\n最后我们的` CatsHelper `：\n\n``` Java\npublic class CatsHelper{\n\n ApiWrapper apiWrapper;\n\n public void saveTheCutestCat(String query, Callback cutestCatCallback){\n apiWrapper.queryCats(query, new Callback>() {\n @Override\n public void onResult(List cats) {\n Cat cutest = findCutest(cats);\n apiWrapper.store(cutest, cutestCatCallback);\n }\n\n @Override\n public void onError(Exception e) {\n cutestCatCallback.onError(e);\n }\n });\n }\n\n private Cat findCutest(List cats) {\n return Collections.max(cats);\n }\n}\n```\n\n可以看到比之前的简明了一些。我们可以通过直接传递一个顶级的` cutestCatCallback `回调接口给` apiWrapper.store `来减少回调间的层级调用，此外作为回调方法的签名是一样的。\n\n但是我们可以做的更好！\n\n\n### 你必须把它分开\n\n让我们来看看我们的异步操作（` queryCats `，` queryCats `，还有`saveTheCutestCat`），它们都遵循了相同的模式。调用它们的方法有一些参数（` query `、` cat `）也包括一个回调对象。再次说明：任何异步操作需要携带所需的常规参数和一个回调实例对象。如果我们试图去分开这几个阶段，每个异步操作仅仅将会携带一个参数对象，然后返回一些携带着回调（信息）的临时对象。\n\n我们来应用下这样的模式，看看是否对我们有所帮助。\n\n如果在异步操作中返回一些临时对象，我们需要定义一个出来。这样的一个对象需要包括常见的行为（以回调为单一参数），我们将定义这样的类给所有的异步操作使用，这个类就叫它` AsyncJob `。\n\n> P.S. 称之为` AsyncTask `更合适一点，但是我不希望你混淆了异步操作跟另外一个存在的抽象概念之间的关系（这是不好的一点）。\n\n所以：\n``` Java\npublic abstract class AsyncJob {\n public abstract void start(Callback callback);\n}\n```\n\n非常的简单，` Callback `传进方法后就会开始它的工作任务。\n\n然后更改包装 API 的调用：\n\n``` Java\npublic class ApiWrapper {\n Api api;\n\n public AsyncJob> queryCats(String query) {\n return new AsyncJob>() {\n @Override\n public void start(Callback> catsCallback) {\n api.queryCats(query, new Api.CatsQueryCallback() {\n @Override\n public void onCatListReceived(List cats) {\n catsCallback.onResult(cats);\n }\n\n @Override\n public void onQueryFailed(Exception e) {\n catsCallback.onError(e);\n }\n });\n }\n };\n }\n\n public AsyncJob store(Cat cat) {\n return new AsyncJob() {\n @Override\n public void start(Callback uriCallback) {\n api.store(cat, new Api.StoreCallback() {\n @Override\n public void onCatStored(Uri uri) {\n uriCallback.onResult(uri);\n }\n\n @Override\n public void onStoreFailed(Exception e) {\n uriCallback.onError(e);\n }\n });\n }\n };\n }\n}\n```\n\n目前一切顺利，我们只是部分运用我们的包装过的 API 调用在程序之中。现在我们可以开始使用` AsyncJob `去做我们想要的了，当然也到更改` CatsHelper `的时间了。\n\n``` Java\npublic class CatsHelper {\n\n ApiWrapper apiWrapper;\n\n public AsyncJob saveTheCutestCat(String query) {\n return new AsyncJob() {\n @Override\n public void start(Callback cutestCatCallback) {\n apiWrapper.queryCats(query)\n .start(new Callback>() {\n @Override\n public void onResult(List cats) {\n Cat cutest = findCutest(cats);\n apiWrapper.store(cutest)\n .start(new Callback() {\n @Override\n public void onResult(Uri result) {\n cutestCatCallback.onResult(result);\n }\n\n @Override\n public void onError(Exception e) {\n cutestCatCallback.onError(e);\n }\n });\n }\n\n @Override\n public void onError(Exception e) {\n cutestCatCallback.onError(e);\n }\n });\n }\n };\n }\n\n private Cat findCutest(List cats) {\n return Collections.max(cats);\n }\n}\n```\n\n哇，之前的版本更简单些啊，我们现在的优势是什么？答案就是现在我们可以给客户端返回“组合”操作的` AsyncJob `。所以一个客户端（在 activity 或者 fragment 处）可以用组合起来的工作来操作。\n\n### Breaking things\n\n这是我们的逻辑数据流：\n``` bash\n (async) (sync) (async)\nquery ===========> List -------------> Cat ==========> Uri\n queryCats findCutest store\n```\n\n为了让我们的代码拥有之前的可读性，我们从这个事件流中强行进入到里面的操作里。但有件事需要注意，如果某些操作（方法）是异步的，然后调用它的操作（方法）又是异步的，就比如，查询猫的操作是异步的，然后寻找出最可爱的猫（即使有一个阻塞调用）也是一个异步操作（客户端希望接收的结果）。\n\n所以我们可以使用 AsyncJobs 把我们的方法分解成更小的操作：\n\n``` Java\npublic class CatsHelper {\n\n ApiWrapper apiWrapper;\n\n public AsyncJob saveTheCutestCat(String query) {\n AsyncJob> catsListAsyncJob = apiWrapper.queryCats(query);\n AsyncJob cutestCatAsyncJob = new AsyncJob() {\n @Override\n public void start(Callback callback) {\n catsListAsyncJob.start(new Callback>() {\n @Override\n public void onResult(List result) {\n callback.onResult(findCutest(result));\n }\n\n @Override\n public void onError(Exception e) {\n callback.onError(e);\n }\n });\n }\n };\n\n AsyncJob storedUriAsyncJob = new AsyncJob() {\n @Override\n public void start(Callback cutestCatCallback) {\n cutestCatAsyncJob.start(new Callback() {\n @Override\n public void onResult(Cat cutest) {\n apiWrapper.store(cutest)\n .start(new Callback() {\n @Override\n public void onResult(Uri result) {\n cutestCatCallback.onResult(result);\n }\n\n @Override\n public void onError(Exception e) {\n cutestCatCallback.onError(e);\n }\n });\n }\n\n @Override\n public void onError(Exception e) {\n cutestCatCallback.onError(e);\n }\n });\n }\n };\n return storedUriAsyncJob;\n }\n\n private Cat findCutest(List cats) {\n return Collections.max(cats);\n }\n}\n```\n\n代码量多了许多，但是更加清晰了。低层次嵌套的回调，利于理解的变量名（` catsListAsyncJob `、` cutestCatAsyncJob `、` storedUriAsyncJob `）。\n\n看起来好了许多，但我们要再做一些事情：\n\n### 简单映射\n\n现在看看 ` AsyncJob cutestCatAsyncJob `的部分：\n\n``` Java\nAsyncJob cutestCatAsyncJob = new AsyncJob() {\n @Override\n public void start(Callback callback) {\n catsListAsyncJob.start(new Callback>() {\n @Override\n public void onResult(List result) {\n callback.onResult(findCutest(result));\n }\n\n @Override\n public void onError(Exception e) {\n callback.onError(e);\n }\n });\n }\n };\n```\n\n这 16 行代码只有一行是对我们有用（对于逻辑来说）的操作：\n\n``` Java\nfindCutest(result)\n```\n\n剩下的仅仅是开启另外一个` AsyncJob `和传递结果与错误的样板代码。此外，这些代码并不用于特定的任务，我们可以把其移动到其它地方而不影响编写我们真正需要的业务代码。\n\n我们该怎么写呢？我们必须做下面的两件事情：\n\n- ` AsyncJob `是我们转换的结果\n\n- 转换方法\n\n这又有另外一个问题，因为在 Java 中不能直接传递方法（函数）所以我们需要通过类（和接口）来间接实现这样的功能，然后我们就来定义这个 “方法”：\n\n``` Java\npublic interface Func {\n R call(T t);\n}\n```\n\n相当简单，` Func `接口有两个类型成员，` T `对应于参数类型而` R `对应于返回类型。\n\n当我们从一个` AsyncJob `中装换处结果后我们就需要做一些值之间的映射，这样的方法我们就叫它` map `。定义这个方法实例（Func 类型）最好的地方就在` AsyncJob `类中，所以` AsyncJob `代码里看起来就是这样了：\n\n``` Java\npublic abstract class AsyncJob {\n public abstract void start(Callback callback);\n\n public AsyncJob map(Func func){\n final AsyncJob source = this;\n return new AsyncJob() {\n @Override\n public void start(Callback callback) {\n source.start(new Callback() {\n @Override\n public void onResult(T result) {\n R mapped = func.call(result);\n callback.onResult(mapped);\n }\n\n @Override\n public void onError(Exception e) {\n callback.onError(e);\n }\n });\n }\n };\n }\n}\n```\n\n赞，这时` CatsHelper `就是下面这样了：\n\n``` Java\npublic class CatsHelper {\n\n ApiWrapper apiWrapper;\n\n public AsyncJob saveTheCutestCat(String query) {\n AsyncJob> catsListAsyncJob = apiWrapper.queryCats(query);\n AsyncJob cutestCatAsyncJob = catsListAsyncJob.map(new Func, Cat>() {\n @Override\n public Cat call(List cats) {\n return findCutest(cats);\n }\n });\n\n AsyncJob storedUriAsyncJob = new AsyncJob() {\n @Override\n public void start(Callback cutestCatCallback) {\n cutestCatAsyncJob.start(new Callback() {\n @Override\n public void onResult(Cat cutest) {\n apiWrapper.store(cutest)\n .start(new Callback() {\n @Override\n public void onResult(Uri result) {\n cutestCatCallback.onResult(result);\n }\n\n @Override\n public void onError(Exception e) {\n cutestCatCallback.onError(e);\n }\n });\n }\n\n @Override\n public void onError(Exception e) {\n cutestCatCallback.onError(e);\n }\n });\n }\n };\n return storedUriAsyncJob;\n }\n\n private Cat findCutest(List cats) {\n return Collections.max(cats);\n }\n}\n```\n\n现在好多了，创建` AsyncJob cutestCatAsyncJob `只需要 6 行代码而回调也只有一个层级了。\n\n\n### 高级映射\n\n前面的那些已经很赞了，但是创建` AsyncJob storedUriAsyncJob `的部分还有些不忍直视。能在这里创建映射吗？我们来试试吧：\n\n``` Java\npublic class CatsHelper {\n\n ApiWrapper apiWrapper;\n\n public AsyncJob saveTheCutestCat(String query) {\n AsyncJob> catsListAsyncJob = apiWrapper.queryCats(query);\n AsyncJob cutestCatAsyncJob = catsListAsyncJob.map(new Func, Cat>() {\n @Override\n public Cat call(List cats) {\n return findCutest(cats);\n }\n });\n\n AsyncJob storedUriAsyncJob = cutestCatAsyncJob.map(new Func() {\n @Override\n public Uri call(Cat cat) {\n return apiWrapper.store(cat);\n // ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ will not compile\n // Incompatible types:\n // Required: Uri\n // Found: AsyncJob \n }\n });\n return storedUriAsyncJob;\n }\n\n private Cat findCutest(List cats) {\n return Collections.max(cats);\n }\n}\n```\n\n呃呃。。。并不容易哦，我们来修改下结果的类型变量，试下其它方法：\n\n``` Java\npublic class CatsHelper {\n\n ApiWrapper apiWrapper;\n\n public AsyncJob saveTheCutestCat(String query) {\n AsyncJob> catsListAsyncJob = apiWrapper.queryCats(query);\n AsyncJob cutestCatAsyncJob = catsListAsyncJob.map(new Func, Cat>() {\n @Override\n public Cat call(List cats) {\n return findCutest(cats);\n }\n });\n\n AsyncJob> storedUriAsyncJob = cutestCatAsyncJob.map(new Func>() {\n @Override\n public AsyncJob call(Cat cat) {\n return apiWrapper.store(cat);\n }\n });\n return storedUriAsyncJob;\n //^^^^^^^^^^^^^^^^^^^^^^^ will not compile\n // Incompatible types:\n // Required: AsyncJob\n // Found: AsyncJob>\n }\n\n private Cat findCutest(List cats) {\n return Collections.max(cats);\n }\n}\n```\n\n在目前这点上我们只能有` AsyncJob> `。我们需要往更深处挖吗？我们希望的是，去把`AsyncJob `在一个级别上的两个异步操作扁平化成一个单一的异步操作。\n\n现在我们需要的是得到能使方法返回映射成` R `类型也是` AsyncJob `类型的操作。这个操作应该像` map `，但在最后应该` flatten `我们嵌套的` AsyncJob `。我们叫它为` flatMap `吧，然后就是来实现它：\n\n``` Java\npublic abstract class AsyncJob {\n public abstract void start(Callback callback);\n\n public AsyncJob map(Func func){\n final AsyncJob source = this;\n return new AsyncJob() {\n @Override\n public void start(Callback callback) {\n source.start(new Callback() {\n @Override\n public void onResult(T result) {\n R mapped = func.call(result);\n callback.onResult(mapped);\n }\n\n @Override\n public void onError(Exception e) {\n callback.onError(e);\n }\n });\n }\n };\n }\n\n public AsyncJob flatMap(Func> func){\n final AsyncJob source = this;\n return new AsyncJob() {\n @Override\n public void start(Callback callback) {\n source.start(new Callback() {\n @Override\n public void onResult(T result) {\n AsyncJob mapped = func.call(result);\n mapped.start(new Callback() {\n @Override\n public void onResult(R result) {\n callback.onResult(result);\n }\n\n @Override\n public void onError(Exception e) {\n callback.onError(e);\n }\n });\n }\n\n @Override\n public void onError(Exception e) {\n callback.onError(e);\n }\n });\n }\n };\n }\n}\n```\n\nFlatMap 的粗略实现，但这些东西的实现都在一个地方了，在客户端的业务代码中不会再见到它。接下来我们修复下` CatsHelper `:\n\n``` Java\npublic class CatsHelper {\n\n ApiWrapper apiWrapper;\n\n public AsyncJob saveTheCutestCat(String query) {\n AsyncJob> catsListAsyncJob = apiWrapper.queryCats(query);\n AsyncJob cutestCatAsyncJob = catsListAsyncJob.map(new Func, Cat>() {\n @Override\n public Cat call(List cats) {\n return findCutest(cats);\n }\n });\n\n AsyncJob storedUriAsyncJob = cutestCatAsyncJob.flatMap(new Func>() {\n @Override\n public AsyncJob call(Cat cat) {\n return apiWrapper.store(cat);\n }\n });\n return storedUriAsyncJob;\n }\n\n private Cat findCutest(List cats) {\n return Collections.max(cats);\n }\n}\n```\n\n哈哈！它能用了，读和写也简单了不少。\n\n\n### 最后的要点\n\n再来看看我们编写的代码，眼熟吗？如果我们使用 Java 8 的 lambdas（逻辑是一样的但是看起来更爽一些） 代码会更加地简洁。\n\n``` Java\npublic class CatsHelper {\n\n ApiWrapper apiWrapper;\n\n public AsyncJob saveTheCutestCat(String query) {\n AsyncJob> catsListAsyncJob = apiWrapper.queryCats(query);\n AsyncJob cutestCatAsyncJob = catsListAsyncJob.map(cats -> findCutest(cats));\n AsyncJob storedUriAsyncJob = cutestCatAsyncJob.flatMap(cat -> apiWrapper.store(cat));\n return storedUriAsyncJob;\n }\n\n private Cat findCutest(List cats) {\n return Collections.max(cats);\n }\n}\n```\n\n它看起来会更好吗？我认为这样的代码跟我们第一次阻塞的版本差不多：\n\n``` Java\npublic class CatsHelper {\n\n Api api;\n\n public Uri saveTheCutestCat(String query){\n List cats = api.queryCats(query);\n Cat cutest = findCutest(cats);\n Uri savedUri = api.store(cutest);\n return savedUri;\n }\n\n private Cat findCutest(List cats) {\n return Collections.max(cats);\n }\n}\n```\n\n是的，就是这样，逻辑是相似的！也有可能会复杂些（语义是一样的）。\n我们这样的代码有组合性吗？请大声的说有！我们组合了所有的异步操作然后作为返回结果我们仅需一个组合后的结果对象而已。\n错误传递呢？当然也有！所有的错误都会传递到最后的回调中。\n接下来的最后呢。。。\n\n\n## [RxJava](https://github.com/ReactiveX/RxJava)\n\n嘿，你不需要把那些代码拷到你的项目中，因为我们还是实现地不够完全的，仅仅算是非线程安全的 RxJava 的一小部分而已。\n\n它们之间只有一些差异：\n\n- ` AsyncJob ` 就是实际上的 [Observable](http://reactivex.io/documentation/observable.html)，它不仅可以只分发一个单一的结果也可以是一个序列（可以为空）。\n\n- ` Callback ` 就是 [Observer](http://reactivex.io/documentation/operators/subscribe.html)，除了 Callback 少了` onNext(T t) `方法。Observer 中在` onError(Throwable t) `方法被调用后，会继而调用` onCompleted() `，然后 Observer 会包装好并发送出事件流（因为它能发送一个序列）。\n\n- ` abstract void start(Callback callback) `对应 [Subscription subscribe(final Observer observer)](http://reactivex.io/RxJava/javadoc/rx/Observable.html#subscribe(rx.Observer))，这个方法也返回 [Subscription](http://reactivex.io/RxJava/javadoc/rx/Subscription.html) ，在不需要它时你可以决定取消接收事件流。\n\n- 除了` map `和` flatMap `方法，` Observable `在 Observalbes 之上也有一些[其它](http://reactivex.io/documentation/operators.html)有用的操作。\n\n下面的代码是使用 RxJava 来完成我们前面自己写的代码的功能：\n\n``` Java\npublic class ApiWrapper {\n Api api;\n\n public Observable> queryCats(final String query) {\n return Observable.create(new Observable.OnSubscribe>() {\n @Override\n public void call(final Subscriber> subscriber) {\n api.queryCats(query, new Api.CatsQueryCallback() {\n @Override\n public void onCatListReceived(List cats) {\n subscriber.onNext(cats);\n }\n\n @Override\n public void onQueryFailed(Exception e) {\n subscriber.onError(e);\n }\n });\n }\n });\n }\n\n public Observable store(final Cat cat) {\n return Observable.create(new Observable.OnSubscribe() {\n @Override\n public void call(final Subscriber subscriber) {\n api.store(cat, new Api.StoreCallback() {\n @Override\n public void onCatStored(Uri uri) {\n subscriber.onNext(uri);\n }\n\n @Override\n public void onStoreFailed(Exception e) {\n subscriber.onError(e);\n }\n });\n }\n });\n }\n}\n\npublic class CatsHelper {\n\n ApiWrapper apiWrapper;\n\n public Observable saveTheCutestCat(String query) {\n Observable> catsListObservable = apiWrapper.queryCats(query);\n Observable cutestCatObservable = catsListObservable.map(new Func1, Cat>() {\n @Override\n public Cat call(List cats) {\n return CatsHelper.this.findCutest(cats);\n }\n });\n Observable storedUriObservable = cutestCatObservable.flatMap(new Func1>() {\n @Override\n public Observable call(Cat cat) {\n return apiWrapper.store(cat);\n }\n });\n return storedUriObservable;\n }\n\n private Cat findCutest(List cats) {\n return Collections.max(cats);\n }\n}\n```\n\n你可以看到代码是相同的，除了使用` Observable `来替代` AsyncJob `。\n\n\n### 总结\n\n我们看到，通过简单的转化我们可以把异步操作给抽象出来。这个抽象出来的东西可以被用来操作和组合异步操作就像简单的方法那样。通过这种方法我们可以摆脱嵌套的回调，在处理异步结果时也能手动处理错误的传递。\n\n如果你看到了这里的话建议你放松下，思考下 sync/async 之间的二元关系，然后看看这个很棒的来自[Erik Meijer](http://en.wikipedia.org/wiki/Erik_Meijer_(computer_scientist))的[视频](https://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2014/Keynote-Duality)。\n\n## 一些有用的链接\n- [http://reactivex.io](http://reactivex.io)\n- [https://github.com/ReactiveX/RxJava](https://github.com/ReactiveX/RxJava)\n- [https://github.com/ReactiveX/RxJava/wiki](https://github.com/ReactiveX/RxJava/wiki)\n- [http://queue.acm.org/detail.cfm?id=2169076](http://queue.acm.org/detail.cfm?id=2169076)\n- [https://www.coursera.org/course/reactive](https://www.coursera.org/course/reactive)\n- [http://blog.danlew.net/2014/09/15/grokking-rxjava-part-1](http://blog.danlew.net/2014/09/15/grokking-rxjava-part-1/)\n\n\n## 感谢\n\n感谢我的朋友 Alexander Yakushev 帮忙翻译。\n" }, { "path": "issue-9/readme.md", "content": "# 开发技术前线 第九期\n\n| 文章名称 | 译者 | \n|---------|--------|\n| [Android 10ms问题：关于Android音频路径延迟的解释](Android 10ms问题：关于Android音频路径延迟的解释.md) | [objectlife](https://github.com/objectlife) |\n| [Android进行单元测试难在哪-part1](Android 进行单元测试难在哪-part1.md) | [chaossss](https://github.com/chaossss)|\n| [NotRxJava懒人专用指南](NotRxJava懒人专用指南.md) | [Rocko](https://github.com/Rocko) |\n| [使用Android Studio进行单元测试](使用Android-Studio进行单元测试.md) | [ZhaoKaiQiang](https://github.com/ZhaoKaiQiang)|\n| [通过Jenkins并行完成UI的自动化测试](通过Jenkins并行完成UI的自动化测试.md) | [chaossss](https://github.com/chaossss) |\n| [创建-RecyclerView-LayoutManager-Part-1](创建-RecyclerView-LayoutManager-Part-1.md) | [tiiime](https://github.com/tiiime) |\n" }, { "path": "issue-9/使用Android-Studio进行单元测试.md", "content": "使用Android Studio进行单元测试\n---\n\n> * 原文链接 : [Unit Testing With Android Studio](http://rexstjohn.com/unit-testing-with-android-studio/)\n* 原文作者 : [Rex St John](http://rexstjohn.com/)\n* [译文出自 : 开发技术前线 www.devtf.cn](http://www.devtf.cn)\n* 译者 : [ZhaoKaiQiang](https://github.com/ZhaoKaiQiang) \n* 校对者: [zhengxiaopeng](https://github.com/zhengxiaopeng) \n* 状态 : 校对完\n\n这篇文章介绍了在Android Studio中进行单元测试的基础部分。\n\n#在Android Studio中可以进行单元测试\n\n\n很多教程都指导你应该在“build.gradlew”中添加几行代码来开启“instrument tests” 功能，而且还需要添加 Android 测试库的项目依赖。\n\n其实你并不需要按照这种错误的方式去做，因为这是完全没有必要的。\n\nAndroid Studio本身就支持Android单元测试，你只需要在你的项目中简单配置一下就可以了。\n\n注意：还有好几种流行的Android单元测试框架，比如[Robolectric](http://robolectric.org/)，这些框架涉及到的配置和设置比我在这里提到的更多，我希望在未来可以以这个主题写一些指导教程。\n\n#创建你的单元测试文件夹\n\n我喜欢把单元测试放在我的主项目里面，比如“com.mypath.tests.” ，你可以把测试目录放到你想放的任何地方。在开始之前，像下面这样，先创建你的\"test\"文件夹。(译者注：这一步不是必须的，你也可以把单元测试类创建在与Android Studio默认的ApplicationTest类相同的路径下面)\n\n![](http://i2.tietuku.com/8ea1f7ff89634a0f.png)\n\n接下来，创建一个叫做 “ExampleTest”的类，要继承自InstrumentationTestCase\n\n![](http://i2.tietuku.com/164d47e438f78f37.png)\n\n然后可以添加一段简单的测试代码，我们知道这段代码肯定会运行失败\n\n```\npublic class ExampleTest extends InstrumentationTestCase {\n public void test() throws Exception {\n final int expected = 1;\n final int reality = 5;\n assertEquals(expected, reality);\n }\n}\n```\n\n\n注意：所有的测试方法必须以\"test\"开头，否则Android Studio不能找到要进行单元测试的方法，你将会得到各种各样的错误，并且无法正常执行。\n\n#为你的项目配置单元测试\n\n现在我们已经有了一个必然会运行失败的测试用例，我们必须把它run起来。\n\n首先点击\"Run-> Edit Configurations\"\n\n![](http://i2.tietuku.com/e91b3515dff21267.png)\n\n然后点击“+”，从左上角选择添加一个 Android Tests，然后你可以将这个测试配置重新命名为\"test\"或与之相关的名字\n\n![](http://i2.tietuku.com/6f5c952065151e07.png)\n\n然后就会创建如下的测试项目配置\n\n![](http://i2.tietuku.com/2183cac60bbed220.png)\n\n从下拉菜单中选择你当前的module\n\n![](http://i2.tietuku.com/854bbdd0299ddb1c.png)\n\n\n接下来，选择\"All in Package\"选项，然后把你的刚才创建的测试文件夹选中。你也可以选择“All in Module”选项，这样Android Studio会自动的找到你整个Module中的所有测试单元，你也可以通过更具体的类或者是方法选项，进一步缩小测试范围。\n\n做完这一切之后，看起来应该像下面这样\n\n![](http://i2.tietuku.com/15039870f925e4e9.png)\n\n我也喜欢选中下面的“Show chooser dialog”,这样当每次运行的时候，我可以指定如何去运行\n\n![](http://i2.tietuku.com/66d3e1d4a120df74.png)\n\n现在点击\"Apply\"然后关闭，你现在应该可以看到你的测试案例已经作为一个可以运行的项目配置在Android Studio上面的工具栏上了\n\n![](http://i2.tietuku.com/6acd89afcb22309d.png)\n\n#运行我们的单元测试\n\n我使用Genymotion来完成所有的事情，所以开启你的Genymotion然后运行test\n\n在assertion这一行添加一个断点，然后点击 “run debug mode”，目的是为了证明Android Studio确实执行了我们的单元测试。\n\n![](http://i2.tietuku.com/e91aefd47fe27e05.png)\n\n当你开始你的测试工程之后，你会看到一个叫做“Running Tests…”的显示窗口\n\n![](http://i2.tietuku.com/2202b414f006234a.png)\n\n\n当你的测试没有通过，点击“Logcat”然后查看综合的输出结果，看下我们测试失败的原因\n\n![](http://i2.tietuku.com/82cf59170999b096.png)\n\n通过控制台，可以看到打印出的错误原因：\n\n```\n“junit.framework.AssertionFailedError: expected:<1> but was:<5>”\n```\n\n恭喜你，你已经成功测试出错误啦~\n\n下面的这些资料在完成本文时，给了很大的帮助\n\n- http://mobilengineering.blogspot.com/2012/05/tdd-testing-asynctasks-on-android.html\n- http://www.vogella.com/tutorials/AndroidTesting/article.html\n- http://nikolaj.hesselholtskov.dk/2013/10/how-to-add-unit-tests-to-android-studio.html" }, { "path": "issue-9/创建-RecyclerView-LayoutManager-Part-1.md", "content": "创建一个 RecyclerView LayoutManager – Part 1\n---\n\n> * 原文链接 : [Building a RecyclerView LayoutManager – Part 1][source]\n> * 原文作者 : [Dave Smith][author]\n* [译文出自 : 开发技术前线 www.devtf.cn](http://www.devtf.cn)\n* 译者 : [tiiime](https://github.com/tiiime) \n* 校对者: [chaossss](https://github.com/chaossss) \n* 状态 : 完成 \n\n\n# Building a RecyclerView LayoutManager – Part 1\n\n>本文是这个系列中的 Part 1，这里是 [Part 2][part2] 和 [Part 3][part3] 的链接。\n\n现如今，如果你是 Android 开发者，你肯定听说过 RecyclerView 这个控件；\n它是一个即将加入 support library 之中的新组件，\n通过方便的视图复用轻松实现自定义高效的视图集。\n已经有很多优秀的文章介绍了 RecyclerView 基础，讲解如何使用\nRecyclerView 提供的内建部分，包括 item animations。所以，\n我们就不再重复前人的工作了，下面是一些帮你入门的资料：\n\n- [A First Glance at Android’s RecyclerView][res-1]\n- [The new TwoWayView][res-2]\n- [RecyclerViewItemAnimators][res-3]\n\n我们的这个系列文章会关注 RecyclerView 底层细节，涉及到创建你自己的 \nLayoutManager，做些比单一的 垂直/水平 滚动列表稍稍复杂的东西。\n\n>在我们开始前，你需要知道 LayoutManager API 之所以能够让我们实现\n>强大复杂的布局是因为它只替你做了很少的工作；这就意味着\n>你不得不自己完成数量可观的代码。如果要在一个项目中使用自定义视图，\n>不要陷入过度优化或过度泛化代码之中。你只需要关心\n>在你的用例中需要实现的特性就可以了。\n\n# RecyclerView Playground\n\n这个系列中所有的代码段都取自 [RecyclerView Playground sample][demo] 这个项目，\n示例应用里包含了各个方面使用 RecyclerView 的实例，从创建简单的 list\n到自定义 LayoutManagers。\n\n本文的代码来自 `FixedGridLayoutManager` ，一个可以垂直和水平\n滚动的二维的网格布局。\n\n>support library 里也有一个自定义的 LayoutManager；本质上\n>是一个自定义 vertical linear list 的实现：\n>[SDK_PATH]/extras/android/compatibility/samples/Support7Demos/src/com/example/android/supportv7/widget/RecyclerViewActivity.java\n>\n>同时，Android L 和 新的 support libraries 可能还没加入 AOSP\n>之中，不过 RecyclerView 提供了 **JAR** 资源，可以在这里找到：\n>[SDK_PATH]/extras/android/m2repository/com/android/support/recyclerview-v7/21.0.0-rc1/recyclerview-v7-21.0.0-rc1-sources.jar\n\n# The Recycler\n\n首先，了解下 API 的结构。当你需要从一个可能再生的前子视图中\n回收旧的 view 或者 获取新的 view 时，\n你的 LayoutManager 可以访问一个 `Recycler` 实例。\n\nRecycler 也免掉了直接访问 view 当前适配器方法的麻烦。当你的\nLayoutManager 需要一个新的子视图时，只要调用 `getViewForPosition() `\n这个方法，Recycler 会决定到底是从头创建一个新的视图\n还是重用一个已存在的废弃视图。\n你的 LayoutManager 需要及时将不再显示的视图传递给 Recycler，\n避免 Recycler 创建不必要的 view 对象。\n\n## Detach vs. Remove\n\n布局更新时有两个方法处理已存在的子视图：detach 和\nremove (分离和移除)。Detach 是一个轻量的记录 view 操作。\n被 detach 的视图在你的代码返回前能够重新连接。可以通过 Recycler\n在不 重新绑定/重新构建 子视图的情况下修改已连接子视图的索引。\n\nRemove 意味着这个 view 已经不需要了。任何被永久移除的 view 都应该\n放到 Recycler 中，方便以后重用，不过 API 并没有强制要求。\n被 remove 的视图是否被回收取决于你。\n\n## Scrap vs. Recycle\n\nRecycler 有两级视图缓存系统： scrap heap 和 recycle pool (垃圾堆和回收池)，\nScrap heap 是一个轻量的集合，视图可以不经过适配器直接返回给\nLayoutManager 。通常被 detach \n但会在同一布局重新使用的视图会临时储存在这里。Recycle pool 存放的\n是那些假定并没有得到正确数据(相应位置的数据)的视图，\n因此它们都要经过适配器重新绑定后才能返回给 LayoutManager。\n\n当要给 LayoutManager 提供一个新 view 时，Recycler 首先会\n检查 scrap heap 有没有对应的 position/id；如果有对应的内容，\n就直接返回数据不需要通过适配器重新绑定。如果没有的话，\nRecycler 就会从 recycle pool 里弄一个合适的视图出来，\n然后用 adapter 给它绑定必要的数据\n(就是调用 `RecyclerView.Adapter.bindViewHolder()`) 再返回。\n如果 recycle pool 中也不存在有效 view ，就会在绑定数据前\n创建新的 view (就是 `RecyclerView.Adapter.createViewHolder()`)，\n最后返回数据。\n\n## 经验法则\n\n只要你原意，LayoutManager 的 API 允许你独立完成所有这些任务，\n所以可能的组合有点多。通常来说，\n如果你想要临时整理并且希望稍后在同一布局中重新使用某个 view 的话，\n 可以对它调用 `detachAndScrapView()` 。如果基于当前布局\n 你不再需要某个 view 的话，对其调用 `removeAndRecycleView()`。\n\n# Building The Core\n\nLayoutManager 需要实时添加，测量和布局所有它需要的子视图。\n当用户滚动屏幕时，布局管理器将来决定什么时候添加新的子视图，\n什么时候可以 detach/scrap (分离/废弃)视图。\n\n你需要实现下面这些方法创建一个可行的 LayoutManager 最小系统。\n\n#### generateDefaultLayoutParams()\n\n事实上你只要重写这个方法你的 LayoutManager 就能编译通过了。\n实现也很简单，返回一个你想要默认应用给所有从 \nRecycler 中获得的子视图做参数的 `RecyclerView.LayoutParams` 实例。\n这些参数会在对应的 `getViewForPosition()` 返回前赋值给相应的子视图。\n\n```java\n@Override\npublic RecyclerView.LayoutParams generateDefaultLayoutParams() {\n return new RecyclerView.LayoutParams(\n RecyclerView.LayoutParams.WRAP_CONTENT,\n RecyclerView.LayoutParams.WRAP_CONTENT);\n}\n```\n\n#### onLayoutChildren()\n\n`onLayoutChildren()` 是 LayoutManager 的主入口。\n它会在 view 需要初始化布局时调用，\n当适配器的数据改变时(或者整个适配器被换掉时)会再次调用。\n**注意！这个方法不是在每次你对布局作出改变时调用的。**\n它是 初始化布局 或者 在数据改变时重置子视图布局的好位置。\n\n在接下来的部分，我们会分析在适配器更新时\n是怎样使用它基于当前可见元素刷新布局的。\n现在，我们将简单地解决这个问题当做子视图布局第一关。\n下面是 `FixedGridLayoutManager` 示例的精简版：\n\n```java\n@Override\npublic void onLayoutChildren(RecyclerView.Recycler recycler, RecyclerView.State state) {\n //Scrap measure one child\n View scrap = recycler.getViewForPosition(0);\n addView(scrap);\n measureChildWithMargins(scrap, 0, 0);\n\n /*\n * We make some assumptions in this code based on every child\n * view being the same size (i.e. a uniform grid). This allows\n * us to compute the following values up front because they\n * won't change.\n */\n mDecoratedChildWidth = getDecoratedMeasuredWidth(scrap);\n mDecoratedChildHeight = getDecoratedMeasuredHeight(scrap);\n detachAndScrapView(scrap, recycler);\n \n updateWindowSizing();\n int childLeft;\n int childTop;\n\n /*\n * Reset the visible and scroll positions\n */\n mFirstVisiblePosition = 0;\n childLeft = childTop = 0;\n \n //Clear all attached views into the recycle bin\n detachAndScrapAttachedViews(recycler);\n //Fill the grid for the initial layout of views\n fillGrid(DIRECTION_NONE, childLeft, childTop, recycler);\n}\n```\n\n我们会对子视图做一些记录和安排\n(为了简便，假设来自适配器的所有子视图都是一样大的)，\n确保所有已存在的视图在 scrap heap 之中。我将\n大部分工作抽象到 `fillGrid()` 这个辅助方法中以便重用。\n我们很快就会看到这个方法在更新可见视图和滚动屏幕中被大量调用。\n\n\n\n\n>就像是自定义实现一个 ViewGroup，你负责触发测量和布局每一个\n>从 Recycler 获取到的子视图。API 没有直接完成这项工作 。\n\n通常来说，在这类方法之中你需要完成的主要步骤如下：\n\n1. 在滚动事件结束后检查所有附加视图当前的偏移位置。\n2. 判断是否需要添加新视图填充由滚动屏幕产生的空白部分。并从 \n\tRecycler 中获取视图。\n3. 判断当前视图是否不再显示。移除它们并放置到 Recycler 中。\n4. 判断剩余视图是否需要整理。发生上述变化后可能\n\t需要你修改视图的子索引来更好地和它们的适配器位置校准。\n\n\n\n注意我们放进 `FixedGridLayoutManager.fillGrid()` 里填充 RecyclerView 的主要步骤。\n当到达最大行数时，这个 manager 将位置从右到左排序，封装。\n\n1. 清点目前我们所有的视图。将他们 Detach 以便稍后重新连接。\n\t\n\t```java\n\tSparseArray viewCache = new SparseArray(getChildCount());\n\t//...\n\tif (getChildCount() != 0) {\n\t\t//...\n\t\t//Cache all views by their existing position, before updating counts\n\t\tfor (int i=0; i < getChildCount(); i++) {\n\t\t\tint position = positionOfIndex(i);\n\t\t\tfinal View child = getChildAt(i);\n\t\t\tviewCache.put(position, child);\n\t\t}\n\t\t//Temporarily detach all views.\n\t\t// Views we still need will be added back at the proper index.\n\t\tfor (int i=0; i < viewCache.size(); i++) {\n\t\t\tdetachView(viewCache.valueAt(i));\n\t\t}\n\t}\n\t```\n\t\n2. 测量/布局每一个当前可见的子视图。重新连接已有的视图很简单；\n\t新的视图是从 Recycler 之中获取的。\n\t\n\t```java\n\tfor (int i = 0; i < getVisibleChildCount(); i++) {\n\t //...\n\n\t //Layout this position\n\t View view = viewCache.get(nextPosition);\n\t if (view == null) {\n\t /*\n\t * The Recycler will give us either a newly constructed view,\n\t * or a recycled view it has on-hand. In either case, the\n\t * view will already be fully bound to the data by the\n\t * adapter for us.\n\t */\n\t view = recycler.getViewForPosition(nextPosition);\n\t addView(view);\n\n\t /*\n\t * It is prudent to measure/layout each new view we\n\t * receive from the Recycler. We don't have to do\n\t * this for views we are just re-arranging.\n\t */\n\t measureChildWithMargins(view, 0, 0);\n\t layoutDecorated(view, leftOffset, topOffset,\n\t leftOffset + mDecoratedChildWidth,\n\t topOffset + mDecoratedChildHeight);\n\t } else {\n\t //Re-attach the cached view at its new index\n\t attachView(view);\n\t viewCache.remove(nextPosition);\n\t }\n\n\t //...\n\t}\n\n\t```\n\t\n3. 最终，所有在第一步中 detach 并且没有被重新连接的视图都不可见。\n\t将它们移入 Recycler 中，以备后用。\n\t\n\t```java\n\tfor (int i=0; i < viewCache.size(); i++) {\n\t recycler.recycleView(viewCache.valueAt(i));\n\t}\n\t```\n\n说明一下，先将所有视图 detach 之后再将需要的视图重新连接是为了\n保持每一个视图子索引的顺序 (就是 `getChildAt()` 的索引)。我们希望\n可见视图从左上到右下的索引从 `0` 开始，到 `getChildCount()-1` 结束。\n当我们上下滑动视图，新的子视图被添加，它的索引顺序会变得不可靠。\n我们需要保留正确的索引来在任意点上定位每一个视图。在一个简单地\nLayoutManager (比如 LinearLayoutManager)中，子视图可以轻松地插入\nlist 的两端， 记录层就没有存在的必要了。\n\n\n# 添加用户交互\n\n目前，我们已经有一个非常好的初始布局，但是它并不能动起来。\nRecyclerView 的关键就在于当用户浏览一组数据时动态提供视图。\n覆盖一些方法就能实现我们的目的。\n\n#### canScrollHorizontally() & canScrollVertically()\n\n这些方法很简单，在你想要滚动方向对应的方法里返回 true ，\n不想要滚动方向对应的方法里返回 false。\n\n```java\n@Override\npublic boolean canScrollVertically() {\n //We do allow scrolling\n return true;\n}\n```\n\n#### scrollHorizontallyBy() & scrollVerticallyBy()\n\n在这里你应该实现 content 移动的逻辑。RecyclerView 已经处理了 scrolling\n和 [flinging][flinging] (注：Fling: Gross gesture, no on-screen target)\n触摸操作，不需要处理 MotionEvents 或者 GestureDetectors 这些麻烦事。\n你只需要完成下面这三个任务：\n\n1. 将所有的子视图移动适当的位置 (对的，你得自己做这个)。\n2. 决定移动视图后 添加/移除 视图。\n3. 返回滚动的实际距离。框架会根据它判断你是否触碰到边界。\n\n在 FixedGridLayoutManager 里，这两个方法很像。这里是精简后的垂直滚动实现：\n\n```java\n@Override\npublic int scrollVerticallyBy(int dy, RecyclerView.Recycler recycler,\n RecyclerView.State state) {\n\n if (getChildCount() == 0) {\n return 0;\n }\n\n //Take top measurements from the top-left child\n final View topView = getChildAt(0);\n //Take bottom measurements from the bottom-right child.\n final View bottomView = getChildAt(getChildCount()-1);\n\n //Optimize the case where the entire data set is too small to scroll\n int viewSpan = getDecoratedBottom(bottomView) - getDecoratedTop(topView);\n if (viewSpan <= getVerticalSpace()) {\n //We cannot scroll in either direction\n return 0;\n }\n\n int delta;\n int maxRowCount = getTotalRowCount();\n boolean topBoundReached = getFirstVisibleRow() == 0;\n boolean bottomBoundReached = getLastVisibleRow() >= maxRowCount;\n\n if (dy > 0) { // Contents are scrolling up\n //Check against bottom bound\n if (bottomBoundReached) {\n //If we've reached the last row, enforce limits\n int bottomOffset;\n if (rowOfIndex(getChildCount() - 1) >= (maxRowCount - 1)) {\n //We are truly at the bottom, determine how far\n bottomOffset = getVerticalSpace() - getDecoratedBottom(bottomView)\n + getPaddingBottom();\n } else {\n /*\n * Extra space added to account for allowing bottom space in the grid.\n * This occurs when the overlap in the last row is not large enough to\n * ensure that at least one element in that row isn't fully recycled.\n */\n bottomOffset = getVerticalSpace() - (getDecoratedBottom(bottomView)\n + mDecoratedChildHeight) + getPaddingBottom();\n }\n delta = Math.max(-dy, bottomOffset);\n } else {\n //No limits while the last row isn't visible\n delta = -dy;\n }\n } else { // Contents are scrolling down\n //Check against top bound\n if (topBoundReached) {\n int topOffset = -getDecoratedTop(topView) + getPaddingTop();\n delta = Math.min(-dy, topOffset);\n } else {\n delta = -dy;\n }\n }\n\n offsetChildrenVertical(delta);\n\n if (dy > 0) {\n if (getDecoratedBottom(topView) < 0 && !bottomBoundReached) {\n fillGrid(DIRECTION_DOWN, recycler);\n } else if (!bottomBoundReached) {\n fillGrid(DIRECTION_NONE, recycler);\n }\n } else {\n if (getDecoratedTop(topView) > 0 && !topBoundReached) {\n fillGrid(DIRECTION_UP, recycler);\n } else if (!topBoundReached) {\n fillGrid(DIRECTION_NONE, recycler);\n }\n }\n\n /*\n * Return value determines if a boundary has been reached\n * (for edge effects and flings). If returned value does not\n * match original delta (passed in), RecyclerView will draw\n * an edge effect.\n */\n return -delta;\n}\n```\n\n我们获得了滚动距离(dx/dy)的增量来验证。方法的第一部分判断\n按照所给的距离(标志给了滚动方向)滚动会不会超过边界。如果会，\n我们需要计算出视图实际滚动的距离。\n\n在这个方法里，我们需要自己手工移动这些视图。\n`offsetChildrenVertical() ` 和 `offsetChildrenHorizontal() ` \n这两个方法 可以帮助我们处理匀速移动。\n**如果你不实现它，你的视图就不会滚动**。\n移动视图操作完成后，我们触发另一个填充操作，\n根据滚动的距离替换视图。\n\n最后，将实际位移距离应用给子视图。RecyclerView 根据这个值判断是否\n绘制到达边界的效果。一般意义上，如果返回值不等于传入的值就意味着\n需要绘制边缘的发光效果了。\n**如果你返回了一个带有错误方向的值，框架的函数会把这个当做一个大的变化\n你将不能获得正确的边缘发光特效。**\n\n除了用来判断绘制边界特效外，返回值还被用来决定什么时候取消 flings。\n返回错误的值会让你失去对 content fling 的控制。框架会认为你已经提前\n触碰到边缘并取消了 fling。\n\n#热身结束~\n\n目前，我们已经实现了基本的功能。它少了很多的细节部分，\n不过滚动和适当的视图回收已经完成了。\n关于自定义 LayoutManager 还有很多要说的东西。\n[接下来][part2]，我们会细致的介绍 decorations, data set changes\n还有实现滚动到特定位置。\n\n---\n\n\n[source]:http://wiresareobsolete.com/2014/09/building-a-recyclerview-layoutmanager-part-1/\n[author]:http://wiresareobsolete.com/\n[part2]:../issue-13/创建-RecyclerView-LayoutManager-Part-2.md\n[part3]:../issue-13/创建-RecyclerView-LayoutManager-Part-3.md\n[res-1]:http://www.grokkingandroid.com/first-glance-androids-recyclerview/\n[res-2]:http://lucasr.org/2014/07/31/the-new-twowayview/\n[res-3]:https://github.com/gabrielemariotti/RecyclerViewItemAnimators\n[demo]:https://github.com/devunwired/recyclerview-playground\n[flinging]:http://www.google.com/design/spec/patterns/gestures.html#gestures-touch-mechanics\n" }, { "path": "issue-9/通过Jenkins并行完成UI的自动化测试.md", "content": "通过Jenkins并行完成UI的自动化测试\n---\n\n> * 原文链接 : [Concurrent Android UI automation with Jenkins](http://www.hidroh.com/2015/04/14/concurrent-android-ui-automation-jenkins/)\n* 原文作者 : [Ha Duy Trung](http://www.hidroh.com/)\n* [译文出自 : 开发技术前线 www.devtf.cn](http://www.devtf.cn)\n* 译者 : [chaossss](https://github.com/chaossss) \n* 校对者: [tiiime](https://github.com/tiiime)\n* 状态 : 完成\n\n\n\n\n![](http://www.hidroh.com/assets/img/parallel-cover.jpg)\n\n现在的 IT 公司会为了进入不同的市场开发相应的 App，来自同一家公司的 App 总会具有相似的 UI 逻辑，但 UI 的细节、风格又各有区分。随着产品的发展，抑或是在产品应用于新市场的过程中产生了旧 UI 逻辑的变种，用于测试所有 UI 逻辑的时间会与新 UI 的数量呈正比例关系增长。即使有 UI 的自动化框架可以用来减少测试所需的时间（例如 Calabash Android），使得每天只需要2个小时就能完成对 UI 的测试，但在这套 UI 衍生出四套“变种 UI”后，却要花费8个小时才能完成测试。\n\n这篇博文将利用 Continuous Integration (CI) 服务，同时在不同的设备中执行 UI 测试，并介绍一种从根源上减少这种实际场景下自动化测试所需时间的方法。此外，我们的测试都是在真机上运行，而不是虚拟机。\n\n更贴近现实的自动化测试：有很多东西只能通过真机来反映，像内存消耗，CPU 消耗：虚拟机通常都是消耗电脑的资源，而真机基本不会消耗电脑资源。\n\n而且用真机进行测试性价比较高！Android 设备都很便宜，所以你可以在需要设备进行测试的时候毫不犹豫地买买买，如果用虚拟机测试的话，由于虚拟机会消耗很多电脑资源而且拓展电脑硬件很烧钱，这无疑会限制测试设备的数量。\n\n虽说博文里同时使用了 Calabash Android 自动化框架 和 [Jenkins CI](https://jenkins-ci.org/)，但我提到的大部分方法可以通过运行在任意 CI 服务上的 [Android Debug Bridge (ADB)](https://wiki.jenkins-ci.org/display/JENKINS/Distributed+builds#Distributedbuilds-RunningMultipleSlavesontheSameMachine) 应用于其他的自动化测试框架里。\n\n## 创建 Jenkins slaves 和 slave group\n\n完成[分布式构建](https://wiki.jenkins-ci.org/display/JENKINS/Distributed+builds)的第一步就是创建 Jenkins slave，授权它管理多个“奴隶”。我们可以通过 Jenkins -> Manage Jenkins -> Manage Nodes 导航到 Jenkins slaves/nodes 的配置界面。\n\n根据定义，Jenkins slave 用于完成 Jenkins 主机分发下来的任务。在我们的使用场景中，需要完成的任务则是运行在 Android 设备上的自动化测试。为了完成这项任务，所有奴隶都可以[运行在相同的机器上](https://wiki.jenkins-ci.org/display/JENKINS/Distributed+builds#Distributedbuilds-RunningMultipleSlavesontheSameMachine)，也就是通过 USB 连接在电脑上的，具有执行 ADB 命令的 Android 设备。\n\n下面是一个与 Samsung S3 关联的奴隶的安装细节：\n\n![](http://www.hidroh.com/assets/img/parallel-slave-1.png)\n\n当所有奴隶都运行在同一台机器上时，我建议为不同的奴隶结点提供不同的系统 roots 文件，因为它们很可能会在测试结果处被存储，如果它们指向同一个 root 文件，可能会让测试结果被不同的结点重写。我们可以通过 Remote FS root 进行这样的设置。\n\n> **Remote FS root**\n\n> 每个奴隶都需要拥有 Jenkins 中的一个专用目录，我们在奴隶中为其指定绝对路径，如：'/var/jenkins' 或 'c:\\jenkins'，而且该路径应该是奴隶设备中的本地路径。但是该路径不需要对 Jenkins 可见，怎么正常怎么来就行。\n\n> 奴隶不会持有重要数据（不同于最后创建于其上的项目的活跃工作区），所以你可以将奴隶的工作区设置到一个临时目录。这样做的唯一缺点在于：你可能会在奴隶设备关机后失去最新的工作区。\n\n当 separate FS roots 和多处理器允许 Calabash 的并行操作时，ADB_DEVICE_ARG 环境变量需要用于通知 Calabash，因为 Calabash 运行的设备应该向其发送 ADB 命令，防止设备的多重连接。底层中，Calabash 通过 ADB 设备命令自动化 UI，当一个设备匹配于另一个奴隶结点，ADB_DEVICE_ARG 应该通过环境变量的配置应用到 node 结点层中，并在其后在任务层变为可用。\n\n> **环境变量**\n\n> 这些键值对将会应用于结点上的每一个构建，并重写任意全局值，所以他们能在 Jenkins 的配置中被使用（如 $key 或 ${key}），而且将会被添加到构建上启动的进程。\n \n在 Nexus 4 中设置奴隶的方式如上\n\n![](http://www.hidroh.com/assets/img/parallel-slave-2.png)\n\n如果你留心注意一些细节你会发现，所有奴隶结点都被配置了相同的 android-group 标签。这样做的目的主要是将奴隶分组，使得当我们需要使用奴隶时，方便我们调用特定分组里的所有奴隶。\n\n> 标签\n\n> 标签（AKA 标签）用于将多个奴隶分到一个逻辑组中，而每一个标签都会消耗空间。例如 'regression java6' 将为为结点分配 'regression' 和 'java6' 标签。\n\n> 举例来说吧，如果你有多个窗口奴隶，而且你要完成的任务需要窗口，那么你可以让你的所有窗口奴隶持有 'windows' 标签，然后将需要执行的任务与 'windows' 标签绑定。这使得你的任务在所有窗口奴隶中被执行，而不是被随意执行。\n\n![](http://www.hidroh.com/assets/img/parallel-slave-group.png)\n\n现在如果我们检查 android-group，我们会得到一个所有结点都带着 android-group 标签的列表，把其他设备添加到这个组里就像拷贝一个已存在的结点和更新 ADB_DEVICE_ARG 环境变量一样简单。\n\n## 使用奴隶群建立并行任务\n\n在进行了上面的配置以后，我们现在可以创建一个 Jenkins 任务使用连接到电脑的设备，通过各自的奴隶和具有 android-group 的奴隶群执行 Calabash Android。\n\n![](http://www.hidroh.com/assets/img/parallel-downstream-1.png)\n\n通过选中“如果必要的话，执行并行构建”和“限制项目运行位置”两个配置选项，使得任务可以被并行执行，主题对结点可用，仅使用标有“android-group”标签的结点。但其中的限制是：需要确保只有与已连接的设备关联的结点才能用于自动化测试，因为我们有用于完成其他任务的其他与未连接设备关联的结点。\n\n> **如果必要的话，执行并行构建**\n\n> 如果需要并行执行构建，Jenkins 会安排并并行执行多个构建（假设你有足够的执行器和传入的构建请求），这对于耗时长的构建和测试任务来说非常有用……此外，参数化构建也是非常实用的，因为每一个执行器的执行任务与其他执行器的执行任务相互独立。\n\n现在假设我们有4个自动化测试的请求和三个已连接的设备，处理完所有请求将需要两轮操作（第一轮三个设备将会被使用，剩下一个请求在队列中等待处理，当某个设备变为空闲状态则会处理该请求）。这就意味着我们可以使4个产品风格自动化测试的时间从8小时减少为4小时，如果我们再买一台或者多台设备的话，时间甚至会更少。\n\n##通过上游任务触发并行的下游任务\n\n写到这里，我们已经能够随心所欲地对我们想要的设备（连接在 USB 端口处可用的设备！）手动地触发并行的自动化测试。但是，我们为什么要手动地完成这些工作呢？我们可以用 Jenkins Parameterized Trigger Plugin 设置上游任务，通过相应的参数触发多个下游任务。\n\n例如，如果我们想要使用所有可用设备并行地测试多个应用 UI，那么我们可以设置一个这样的上游任务，并执行它：\n\n![](http://www.hidroh.com/assets/img/parallel-upstream-2.png)\n\n![](http://www.hidroh.com/assets/img/parallel-upstream-3.png)\n\n上面的配置完成后，我们可以触发三个并行的 MOBILE_TEST 下游任务（必须进行了“如果必要的话，执行并行构建”的配置），每一个下游任务将会测试一个指定的 App 风格“cherry”，“tomato”，“rasberry”，并通过一个叫作风格的参数发送到下游任务。上游任务将会被阻塞，等待所有下游任务完成任务并因此设置构建状态。\n\n我建议大家把上游任务运行在不同的奴隶结点/奴隶组中，而不是运行在和下游任务相同的奴隶结点/奴隶组中，否则它将占着设备不处理，浪费了资源\n\n![](http://www.hidroh.com/assets/img/parallel-upstream-1.png)\n\n所以从今天开始，让我们一起回收这些被淘汰的设备，让它为我们贡献最后一丝价值吧！\n" }, { "path": "markdown简单教程.md", "content": "# 标题1，文章的第一句就是标题1\n\n## 这是标题2，其他小标题按照层级划分\n### 标题3\n### 标题4\n\n## 文字加粗\n**hello**\n\n## 引用\n引用的格式为: >加上一个空格，然后加上文字内容。 \n在一些注意点时，我们可以使用引用来引起读着的注意。例如 : \n\n> 注意 : 不能在子线程中更新UI。\n\n\n## 换行\n\n句尾有四个以上的空格代表换行。示例 :\n\n**四个空格换行（注意句尾的空格）** \n这里是一行，重新换行。 \n新的一行。\n\n\n**回车换行** \n这里是一行，重新换行。\n\n新的一行。\n\n## 超链接\n**格式1 :** \n[链接名](地址)\n\n示例 : \n[www.baidu.com](www.baidu.com)\n\n**格式2** \n[链接名][唯一标识]\n[唯一标识]: url地址 \n\n这种格式一般用在某段话中链接比较多的情况，为了保持原文简洁，将链接单独提出来。 \n\n示例 : \n[开发技术前线][devtf]\n\n[devtf]: http://www.devtf.cn \n\n## 代码\n\n```java\npublic class Name {\n\t\n}\n```\n\n适用于Android代码。需要注意的是开始处的```上面必须要有一个空行。\n\n使用于iOS方面的代码 : \n\n```\nlet customPresentAnimationController = CustomPresentAnimationController()\n\noverride func prepareForSegue(segue: UIStoryboardSegue, sender: AnyObject?) {\n \n if segue.identifier == \"showAction\" {\n let toViewController = segue.destinationViewController as UIViewController\n toViewController.transitioningDelegate = self\n }\n}\n```\n\n## 显示图片\n格式 : \n![图片名字](图片链接)\n\n示例 : \n![p1](http://img.blog.csdn.net/20150416165133627)\n\n\n## 列表 \n列表前面也是需要一个空行，并且在标识符后面需要一个空格,比如: 1. 和* 。 \n\n这是有序列表 : \n\n1. 第一\n2. 第二\n3. 第三\n\n无序列表 : \n\n* 翻译正确\n* 中文流畅\n* 高质量\n\n另一种列表 : \n\n- 翻译项目\n- 认真校对撒\n- 发布文章\n\n## 表格 \n格式为 : \n\n| \t 这是表头1\t\t| \t\t表头2 \t\t|\n|:-------------|:-------------:|\n| 第一行第一列，左对齐| 第一行第二列居中 |\n| 第二行第一列，左对齐| 第二行第二列，居中 |\n\n\nMarkdown更详细的教程请查看[Markdown简明教程](http://wowubuntu.com/markdown/)。" }, { "path": "markdown转换教程.md", "content": "# markdown转换教程 #\n\nAuthor：[tmc9031](https://github.com/tmc9031)\n\n\n## HTML转markdown ##\n\n\n### WHY ###\n\n为提高翻译效率，推荐把原文的html格式先转换为markdown格式，可以简化手工整理原文的过程\n\n### INSTALL ###\n\n这里介绍一款格式转换神器 [pandoc.org](http://pandoc.org)\n\nLinux系统下的的安装\n\n $ sudo apt-get install pandoc\n\n其它系统的详见官方 [installing](http://pandoc.org/installing.html)\n\n### HOWTO ###\n\n以下以该文章为例 [Automating Android development](https://medium.com/google-developer-experts/automating-android-development-6daca3a98396)\n\n1. 用浏览器打开另保存为aad.html，注意保存类型选择 `网页，仅 HTML`\n2. 使用pandoc工具，Linux系统下使用shell终端命令\n\n $ pandoc aad.html -o aad.md --from=html --to=markdown\n\n3. 接下来打开aad.md去除一些头尾的多余部分即可开始翻译\n\n> 注意：\n> 建议在翻译过程中善用git保存转换出来的原文markdown\n> 另外保留中英双语方便校对，完成后再删除英文原文\n" }, { "path": "others/Android-M中Intent的解析/readme.md", "content": "Android 6.0中Intent的解析\n---\n\n> * 原文链接 : [Intent Resolving in Android M](https://medium.com/google-developer-experts/intent-resolving-in-android-m-c17d39d27048#.n23z2g14e)\n* 原文作者 : [Said Tahsin Dane](https://medium.com/@tasomaniac)\n* 译文出自 : [开发技术前线 www.devtf.cn。未经允许，不得转载!](http://www.devtf.cn)\n* 译者 : [liuling07](https://github.com/liuling07) \n* 校对者: [这里校对者的github用户名](github链接)\n* 状态 : 未完成 \n\n注意了！在Android 6.0中，“隐式Intent”的解析不能像之前版本那样正常工作了。这很有可能导致你的app不能正常使用。\n\n现在让我解释一下这个意料之中的问题以及为什么它不能正常使用：\n最近，我正在开发一个小的开源项目，叫做“Open Link With”。希望不久后它能够在应用市场上架。\n\n我的这个app能够让你在其他app之间随意切换。当你给我分享一个链接的时候，我基本上可以根据这个链接查询出所有可以处理这个链接的Activity。然后我会模拟一个系统对话框让你切换app。\n\n![从已经打开的youtube的web页面切换到youtube应用](https://cdn-images-1.medium.com/max/1600/1*rW8I8aCpJ2q8fnfKH_51_g.gif)\n\n我一直都是使用下面的方法：\n\n```\nList infos = packageManager\n .queryIntentActivities(intent, MATCH_DEFAULT_ONLY);\n```\n\n这段代码几乎所有Android开发者都比较熟悉，并且我也相信大部分app都有用到这段代码。\n\n我的手机里有两个浏览器。“一个URL是Google+ 的Intent”期望得到一个具有3个ResolveInfo对象的列表（Google+应用以及两个浏览器）。\n\n好吧，并不是这样！\n\n欢迎来到Android 6.0！\n\nAndroid 6.0引进了应用关联。系统主要通过你的web页面来认证，并且自动使用你的app来打开这些URL，而不会向你做任何请求。或者你可以到系统设置，选择“应用程序”，然后点击一个应用，再点击“默认打开方式”，然后设置“用这个应用打开”，就可以每次都使用这个应用打开。\n\n![Android 6.0的应用默认设置页面](https://cdn-images-1.medium.com/max/800/1*MVZbYKhwu-7qnyGAFWuNsw.png)\n\n在这种情况下，queryIntentActivities方法只会给开发者返回一个只有一个Activity的列表（此例子返回的是Google+）。\n\n虽然这是在意料之中的，但是应该在文档中注明，因为它与公共API相矛盾了。\n\n我研究了一下，发现了一个MATCH_ALL标志，文档表示，它将禁用所有的系统级过滤器。\n\n```\n/**\n * Querying flag: if set and if the platform is doing any filtering of the results, then\n * the filtering will not happen. This is a synonym for saying that all results should\n * be returned.\n */\npublic static final int MATCH_ALL = 0x00020000;\n```\n\n这对我来说没什么用。我打开源码（至少我有源码）并开始研究这个方法。\n\n它似乎优先考虑验证应用程序的域，不仅在它的内部系统，在公共API中也是如此。\n\n如果有一个验证应用程序的域，它不会返回任何其他东西。MATCH_ALL标志会移除一些系统过滤器，但是仅仅是在没有验证程序的情况下。\n\n对于这个问题，我找不到任何可变通的措施。它只是排除浏览器应用，即使他们的IntentFilters匹配。\n\n之所以没有可变通的措施，是因为他是一个内部组件（我们无法访问），Android SDK通过IPC使用AIDL与它进行通信。\n\n大部分开发者使用这个方法来判断是否至少有一个Activity来处理隐式的Intent。在大多数情况下，列表中第一项就是你想要的。\n\n在花了几个小时搞明白到底发生了什么之后，我尝试寻找一个我认为每个人都应该知道的解决方案。\n\n在Android 6.0中，改动的地方很多。实际上谷歌提供了一些改变清单，在清单中你能看到到底有哪些改变。我认为还有很多类似上面的一些没有在清单中列出的改变，而这些改动很有可能导致你的应用无法正常运行。\n\n所以如果你使用PackageManager的方法，你一定得小心，并且认真检查。\n\n感谢此文的校对者：[Yağmur Dalman](https://twitter.com/yagmurdalman)、[ Sebastiano Poggi](https://medium.com/u/9706138c9bfb)、[Salim KAYABAŞI](https://medium.com/u/73761c65c602)、[Hasan Keklik](https://medium.com/u/24a0490cd588)\n\n\n" }, { "path": "others/FaceBook推出的Android图片加载库-Fresco/readme.md", "content": "FaceBook推出的Android图片加载库-Fresco\n---\n\n>\n* 原文链接:[Introducing Fresco: A new image library for Android](https://code.facebook.com/posts/366199913563917/introducing-fresco-a-new-image-library-for-android/)\n* 作者 : [tyrone Nicholas ](https://www.facebook.com/tyrone.nicholas)\n* 译者 : [ZhaoKaiQiang](https://github.com/ZhaoKaiQiang) \n* 校对者: [Chaossss](https://github.com/chaossss)\n* 校对者: [bboyfeiyu](https://github.com/bboyfeiyu)\n* 校对者: [BillionWang](https://github.com/BillionWang)\n* 状态 : 完成\n\n在Android设备上面，快速高效的显示图片是极为重要的。过去的几年里，我们在如何高效的存储图像这方面遇到了很多问题。图片太大，但是手机的内存却很小。每一个像素的R、G、B和alpha通道总共要占用4byte的空间。如果手机的屏幕是480*800,那么一张屏幕大小的图片就要占用1.5M的内存。手机的内存通常很小，特别是Android设备还要给各个应用分配内存。在某些设备上，分给Facebook App的内存仅仅有16MB。一张图片就要占据其内存的十分之一。\n\n当你的App内存溢出会发生什么呢？它当然会崩溃！我们开发了一个库来解决这个问题，我们叫它Fresco。它可以管理使用到的图片和内存，从此App不再崩溃。\n\n##内存区\n为了理解Facebook到底做了什么工作，在此之前我们需要了解在Android可以使用的堆内存之间的区别。Android中每个App的Java堆内存大小都是被严格的限制的。每个对象都是使用Java的new在堆内存实例化，这是内存中相对安全的一块区域。内存有垃圾回收机制，所以当App不在使用内存的时候，系统就会自动把这块内存回收。\n\n不幸的是，内存进行垃圾回收的过程正是问题所在。当内存进行垃圾回收时，内存不仅仅进行了垃圾回收，还把 Android 应用完全终止了。这也是用户在使用 App 时最常见的卡顿或短暂假死的原因之一。这会让正在使用 App 的用户非常郁闷，然后他们可能会焦躁地滑动屏幕或者点击按钮，但 App 唯一的响应就是：在 App 恢复正常之前，请求用户耐心等待\n\n相比之下，Native堆是由C++程序的new进行分配的。在Native堆里面有更多可用内存，App只被设备的物理可用内存限制，而且没有垃圾回收机制或其他东西拖后腿。但是c++程序员必须自己回收所分配的每一块内存，否则就会造成内存泄露，最终导致程序崩溃。\n\nAndroid有另外一种内存区域，叫做Ashmem。它操作起来更像Native堆，但是也有额外的系统调用。Android 在操作 Ashmem 堆时，会把该堆中存有数据的内存区域从 Ashmem 堆中抽取出来，而不是把它释放掉，这是一种弱内存释放模式；被抽取出来的这部分内存只有当系统真正需要更多的内存时（系统内存不够用）才会被释放。当 Android 把被抽取出来的这部分内存放回 Ashmem 堆，只要被抽取的内存空间没有被释放，之前的数据就会恢复到相应的位置。\n\n##可消除的Bitmap\nAshmem不能被Java应用直接处理，但是也有一些例外，图片就是其中之一。当你创建一张没有经过压缩的Bitmap的时候，Android的API允许你指定是否是可清除的。\n\n```\nBitmapFactory.Options = new BitmapFactory.Options();\noptions.inPurgeable = true;\nBitmap bitmap = BitmapFactory.decodeByteArray(jpeg, 0, jpeg.length, options);\n```\n经过上面的代码处理后，可清除的Bitmap会驻留在 Ashmem 堆中。不管发生什么，垃圾回收器都不会自动回收这些 Bitmap。当 Android 绘制系统在渲染这些图片，Android 的系统库就会把这些 Bitmap 从 Ashmem 堆中抽取出来，而当渲染结束后，这些 Bitmap 又会被放回到原来的位置。如果一个被抽取的图片需要再绘制一次，系统仅仅需要把它再解码一次，这个操作非常迅速。\n\n这听起来像一个完美的解决方案，但是问题是Bitmap解码的操作是运行在UI线程的。Bitmap解码是非常消耗CPU资源的，当消耗过大时会引起UI阻塞。因为这个原因，所以Google不推荐使用这个[特性](http://developer.android.com/intl/zh-cn/reference/android/graphics/BitmapFactory.Options.html#inPurgeable)。现在它们推荐使用另外一个特性——inBitmap。但是这个特性直到Android3.0之后才被支持。即使是这样，这个特性也不是非常有用，除非 App 里的所有图片大小都相同，这对Fackbook来说显然是不适用的。一直到4.4版本，这个限制才被移除了。但我们需要的是能够运行在 Android 2.3 - 最新版本中的通用解决方案。\n\n##自力更生\n对于上面提到的“解码操作致使 UI 假死”的问题，我们找到了一种同时使 UI 显示和内存管理都表现良好的解决方法。如果我们在 UI 线程进行渲染之前把被抽取的内存区域放回到原来的位置，并确保它再也不会被抽取，那我们就可以把这些图片放在 Ashmem 里，同时不会出现 UI 假死的问题。幸运的是，Android 的 NDK 中有一个函数可以完美地实现这个需求，名字叫做 AndroidBitmap_lockPixels。这个函数最初的目的就是：在调用 unlockPixels 再次抽取内存区域后被执行。\n\n当我们意识到我们没有必要这样做的时候，我们取得了突破。如果我们只调用lockPixels而不调用对应的unlockPixels，那么我们就可以在Java的堆内存里面创建一个内存安全的图像，并且不会导致UI线程加载缓慢。只需要几行c++代码，我们就完美的解决了这个问题。\n\n##用C++的思想写Java代码\n就像《蜘蛛侠》里面说的：“能力越强，责任越大。”可清除的 Bitmap 既不会被垃圾回收器回收，也不会被 Ashmem 内置的清除机制处理，这使得使用它们可能会造成内存泄露。所以我们只能靠自己啦。\n\n在c++中,通常的解决方案是建立智能指针类,实现引用计数。这些需要利用到c++的语言特性——拷贝构造函数、赋值操作符和确定的析构函数。这种语法在Java之中不存在，因为垃圾回收器能够处理这一切。所以我们必须以某种方式在Java中实现C++的这些保证机制。\n\n我们创建了两个类去完成这件事。其中一个叫做“SharedReference”，它有addReference和deleteReference两个方法，调用者调用时必须采取基类对象或让它在范围之外。一旦引用计数器归零，资源处理(Bitmap.recycle)就会发生。\n\n然而，很显然，让Java开发者去调用这些方法是很容易出错的。Java语言就是为了避免做这样的事情的！所以SharedReference之上,我们构建了CloseableReference类。它不仅实现了Java的Closeable接口,而且也实现了Cloneable接口。它的构造器和clone()方法会调用addReference()，而close()方法会调用deleteReference()。所以Java开发者需要遵守下面两条简单的的规则：\n\n1. 在分配CloseableReference新对象的时候,调用.clone()。\n2. 在超出作用域范围的时候，调用.close()，这通常是在finally代码块中。\n\n这些规则可以有效地防止内存泄漏,并让我们在像Fackbook的Android客户端这种大型的Java程序中享受Native内存管理和通信。\n\n##不仅仅是加载程序，它是一个管道\n在移动设备上显示图片需要很多的步骤：\n![](http://i2.tietuku.com/4480c88a0d8004bf.png)\n几个优秀的开源库都是按照这个顺序执行的，比如 Picasso,Universal Image Loader,Glide和 Volley等等。上面这些开源库为Android的发展做出了非常重要的贡献。我们相信Fresco在几个重要方面会表现的更好。\n\n我们的不同之处在于把上面的这些步骤看作是管道，而不仅仅是加载器。每一个步骤和其他方面应该是尽可能独立的，把数据和参数传递进去，然后产生一个输出，就这么简单。它应该可以做一些操作，不管是并行还是串行。一些操作只能在特性条件下才能执行。一些有特殊要求的在线程上执行。除此之外，当我们考虑改进图像的时候，所有的图片就会变得非常复杂。很多人在低网速情况下使用Facebook，我们想要这些人能够尽快的看到图片，甚至经常是在图片没有完全下载完之前。\n\n##不要烦恼，拥抱stream\n在Java中，异步代码历来都是通过Future机制来执行的。在另外的线程里面代码被提交执行，然后一个类似Future的对象可以检查执行的结果是不是已经完成了。但是，这只在假设只有一种结果的情况下行得通。在处理渐进的图像的时候，我们希望可以完整而且连续的显示结果。\n\n我们的解决方式是定义一个更广义的Future版本，叫做DataSource。它提供了一个订阅方法，调用者必须传入一个DataSubscriber和Executor。DataSubscriber可以从DataSource获取到处理中和处理完毕的结果，并且提供了很简单的方法来区分。因为我们需要非常频繁的处理这些对象，所以必须有一个明确的close调用，幸运的是，DataSource本身就是Closeable。\n\n在后台，每一个箱子上面都实现了一个叫做“生产者/消费者”的新框架。在这个问题是，我们是从[ReactiveX](http://reactivex.io/)获取的灵感。我们的系统拥有和[RxJava](https://github.com/ReactiveX/RxJava)相似的接口，但是更加适合移动设备，并且有内置的对Closeables的支持。\n\n保持简单的接口。Producer只有一个叫做produceResults的方法，这个方法需要一个Consumer对象。反过来，Consumer有一个onNewResult方法。\n\n我们使用像这样的系统把Producer联系起来。假设我们有一个producer的工作是把类型I转化为类型O，那么它看起来应该是这个样子：\n\n```\npublic class OutputProducer implements Producer {\n\n private final Producer mInputProducer;\n\n public OutputProducer(Producer inputProducer) {\n this.mInputProducer = inputProducer;\n }\n\n public void produceResults(Consumer outputConsumer, ProducerContext context) {\n Consumer inputConsumer = new InputConsumer(outputConsumer);\n mInputProducer.produceResults(inputConsumer, context);\n }\n\n private static class InputConsumer implements Consumer {\n private final Consumer mOutputConsumer;\n\n public InputConsumer(Consumer outputConsumer) {\n mOutputConsumer = outputConsumer;\n }\n\n public void onNewResult(I newResult, boolean isLast) {\n O output = doActualWork(newResult);\n mOutputConsumer.onNewResult(output, isLast); \n }\n }\n}\n```\n\n这可以使我们把非常复杂的步骤串起来，同时也可以保持他们逻辑的独立性。\n\n##动画全覆盖\n使用Facebook的人都非常喜欢Stickers，因为它可以以动画形式存储GIF和Web格式。如果支持这些格式，就需要面临新的挑战。因为每一个动画都是由不止一张图片组成的，你需要解码每一张图片，存储在内存里，然后显示出来。对于大一点的动画，把每一帧图片放在内存是不可行的。\n\n我们建立了AnimatedDrawable,一个强大的可以呈现动画的Drawable,同时支持GIF和WebP格式。AnimatedDrawable实现标准的Android Animatable接口,所以调用者可以随意的启动或者停止动画。为了优化内存使用，如果图片足够小的时候，我们就在内存里面缓存这些图片，但是如果太大，我们可以迅速的解码这些图片。这些行为调用者是完全可控的。\n\n所有的后台都用c++代码实现。我们保持一份解码数据和元数据解析,如宽度和高度。我们引用技术数据，它允许多个Java端的Drawables同时访问一个WebP图像。\n\n##如何去爱你？我来告诉你...\n当一张图片从网络上下载下来之后，我们想显示一张占位图。如果下载失败了，我们就会显示一个错误标志。当图片加载完之后，我们有一个渐变动画。通过使用硬件加速，我们可以按比例放缩，或者是矩阵变换成我们想要的大小然后渲染。我们不总是按照图片的中心进行放缩，那么我们可以自己定义放缩的聚焦点。有些时候，我们想显示圆角甚至是圆形的图片。所有的这些操作都应该是迅速而平滑的。\n\n我们之前的实现是使用Android的View对象——时机到了，可以使用ImageView替换出占位的View。这个操作是非常慢的。改变View会让Android强制刷新整个布局，当用户滑动的时候，这绝对不是你想看到的效果。比较明智的做法是使用Android的Drawables,它可以迅速的被替换。\n\n所以我们创建了Drawee。这是一个像MVC架构的图片显示框架。该模型被称为DraweeHierarchy。它被实现为Drawables的一个层，对于底层的图像而言，每一个曾都有特定的功能——成像、层叠、渐变或者是放缩。\n\nDraweeControllers通过管道的方式连接到图像上——或者是其他的图片加载库——并且处理后台的图片操作。他们从管道接收事件并决定如何处理他们。他们控制DraweeHierarchy实际上的操作——无论是占位图片,错误条件或是完成的图片。\n\nDraweeViews 的功能不多,但都是至关重要的。他们监听Android的View不再显示在屏幕上的系统事件。当图片离开屏幕的时候,DraweeView可以告诉DraweeController关闭使用的图像资源。这可以避免内存泄露。此外,如果它已经不在屏幕范围内的话，控制器会告诉图片管道取消网络请求。因此，像Fackbook那样滚动一长串的图片的时候，不会频繁的网络请求。\n\n通过这些努力，显示图片的辛苦操作一去不复返了。调用代码只需要实例化一个DraweeView,然后指定一个URI和其他可选的参数就可以了。剩下的一切都会自动完成。开发人员不需要担心管理图像内存，或更新图像流。Fresco为他们把一切都做了。\n\n##Fresco\n完成这个图像显示和操作复杂的工具库之后,我们想要把它分享到Android开发者社区。我们很高兴的宣布，从今天起，这个项目已经作为[开源代码](http://github.com/facebook/fresco)了！\n\n壁画是绘画技术,几个世纪以来一直受到世界各地人们的欢迎。我们许多伟大的艺术家使用这种名字,从意大利文艺复兴时期的大师拉斐尔到壁画艺术家斯里兰卡。我们并不是假装达到这个伟大的水平，我们真的希望Android开发者能像我们当初享受创建这个开源库的过程一样，非常享受的使用它。\n\n##更多\n[Fresco中文文档](http://fresco-cn.org/)\n" }, { "path": "others/Google推荐的图片加载库Glide介绍/readme.md", "content": "Google推荐的图片加载库Glide介绍\n---\n\n>\n* 原文链接:[Google推荐的图片加载库Glide介绍](http://inthecheesefactory.com/blog/get-to-know-glide-recommended-by-google/en)\n* 作者 : [nuuneoi](http://inthecheesefactory.com/)\n* 译者 : [jianghejie](https://github.com/jianghejie) \n* 校对者 : [chaossss](https://github.com/chaossss)\n* 状态 : 完成\n \n\n在泰国举行的谷歌开发者论坛上，谷歌为我们介绍了一个名叫 [Glide](https://github.com/bumptech/glide) 的图片加载库，作者是bumptech。这个库被广泛的运用在google的开源项目中，包括2014年google I/O大会上发布的官方app。\n\n毫无疑问，这个库引起了我的兴趣。于是我花了一个晚上研究和把玩它，将它的实现原理分析清楚以后，我决定写一篇博文分享一些自己的经验。在开始之前我想说，Glide和Picasso有90%的相似度，准确的说，我觉得它就像 Picasso 的克隆体。\n\n不管怎样，Glide 和 Picasso在细节上还是有不少区别的，接下来我会让你们了解到其中的差异。\n\n##导入库\n\nPicasso和Glide都在jcenter上。在项目中添加依赖非常简单：\nPicasso\n```gradle\ndependencies {\n compile 'com.squareup.picasso:picasso:2.5.1'\n}\n```\nGlide\n```gradle\ndependencies {\n compile 'com.github.bumptech.glide:glide:3.5.2'\n compile 'com.android.support:support-v4:22.0.0'\n}\n```\n不管怎样，Glide 需要 Android Support Library v4 包，千万不要忘了像上面的代码做的那样添加 Android Support Library v4 包的依赖。不过这都不是什么大问题，因为现在 Android Support Library v4 基本是每一个新 Android 项目的标配了。\n\n##基础\n\n就如我所说的Glide和Picasso非常相似，Glide加载图片的方法和Picasso如出一辙。\n\nPicasso\n```java\nPicasso.with(context)\n .load(\"http://inthecheesefactory.com/uploads/source/glidepicasso/cover.jpg\")\n .into(ivImg);\n```\nGlide\n\n```java\nGlide.with(context)\n .load(\"http://inthecheesefactory.com/uploads/source/glidepicasso/cover.jpg\")\n .into(ivImg);\n```\n虽然两者看起来非常相似，但是 Glide 的代码无疑设计得更好，因为 Glide 的 with() 方法不光接受 Context，还接受 Activity 和 Fragment。此外，with() 方法还能自动地从你放入的各种东西里面提取出 Context，供它自己使用。\n\n![](http://jcodecraeer.com/uploads/20150327/1427445293711143.png)\n\n同 时将Activity/Fragment作为with()参数的好处是：图片加载会和Activity/Fragment的生命周期保持一致，比如 Paused状态在暂停加载，在Resumed的时候又自动重新加载。所以我建议传参的时候传递Activity 和 Fragment给Glide，而不是Context。\n\n##默认Bitmap格式是RGB_565\n\n下面是加载图片时和Picasso的比较（1920x1080 像素的图片加载到768x432的ImageView中）\n\n![](http://jcodecraeer.com/uploads/20150327/1427445293137409.jpg)\n\n可以看到Glide加载的图片质量要差于Picasso（ps：我看不出来哈），为什么？这是因为Glide默认的Bitmap格式是RGB_565 ，比ARGB_8888格式的内存开销要小一半。下面是Picasso在ARGB8888下与Glide在RGB565下的内存开销图（应用自身占用了8m，因此以8为基准线比较）：\n\n![](http://jcodecraeer.com/uploads/20150327/1427445293965030.png)\n\n如果你觉得 Glide 在默认的 RGB_565 格式下加载的图片质量可以接受的话，可以什么都不做。但如果你觉得难以接受，或者是你的实际需求对图片的质量有更高的要求的话，你可以像下面的代码那样创建一个 GlideModule 子类，把 Bitmap 的格式转换到 ARGB_8888：\n\n```java\n public class GlideConfiguration implements GlideModule {\n \n @Override\n public void applyOptions(Context context, GlideBuilder builder) {\n // Apply options to the builder here.\n builder.setDecodeFormat(DecodeFormat.PREFER_ARGB_8888);\n }\n \n @Override\n public void registerComponents(Context context, Glide glide) {\n // register ModelLoaders here.\n }\n}\n```\n然后在AndroidManifest.xml中将GlideModule定义为meta-data\n\n```java\n\n```\n![](http://jcodecraeer.com/uploads/20150327/1427445294447874.jpg)\n\n这样看起来就会好很多。\n\n我们再来看看内存开销图，虽然看起来这次 Glide 的内存开销接近于上次的两倍，但是Picasso的内存开销仍然远大于Glide。\n\n![](http://jcodecraeer.com/uploads/20150327/1427445294918728.png)\n\n但是上面那样做的问题在于你需要手动计算 ImageView 的尺寸，又或者是你对 ImageView 设置了具体的尺寸大小，为了解决这样的麻烦，你可以在 Picasso 中通过这样做简化你的代码：\n\n```java\nPicasso.with(this)\n .load(\"http://nuuneoi.com/uploads/source/playstore/cover.jpg\")\n .resize(768, 432)\n .into(ivImgPicasso);\n```\n但是问题在于你需要主动计算ImageView的大小，或者说你的ImageView大小是具体的值（而不是wrap_content），你也可以这样：\n\n```java\nPicasso.with(this)\n .load(\"http://nuuneoi.com/uploads/source/playstore/cover.jpg\")\n .fit()\n .centerCrop()\n .into(ivImgPicasso);\n```\n现在Picasso的内存开销就和Glide差不多了。\n\n![](http://jcodecraeer.com/uploads/20150327/1427445294433243.png)\n\n虽然内存开销差距不大，但是在这个问题上Glide完胜Picasso。因为Glide可以自动计算出任意情况下的ImageView大小。\n##Image质量的细节\n\n这是将ImageView还原到真实大小时的比较。\n![](http://jcodecraeer.com/uploads/20150327/1427445294704430.png)\n\n很显然，Glide 加载的图片有些像素点变得很模糊，看起来也没有 Picasso 那么平滑。而且直到现在，我也没有找到一个可以直观改变图片大小调整算法的方法。\n\n但是这并不算什么坏事，因为很难察觉。\n\n\n##磁盘缓存\n\nPicasso和Glide在磁盘缓存策略上有很大的不同。我们刚刚做了一个使用 Glide 和 Picasso 加载同一张高清图片的实验，我在实验后检查缓存目录时发现： Glide 缓存的图片和 ImageView 的尺寸相同，而 Picasso 缓存的图片和原始图片的尺寸相同。\n\n![](http://jcodecraeer.com/uploads/20150327/1427445294110987.jpg)\n\n上面提到的平滑度的问题依然存在，而且如果加载的是RGB565图片，那么缓存中的图片也是RGB565。\n\n我 尝试将ImageView调整成不同大小，但不管大小如何Picasso只缓存一个全尺寸的。Glide则不同，它会为每种大小的ImageView缓存 一次。尽管一张图片已经缓存了一次，但是假如你要在另外一个地方再次以不同尺寸显示，需要重新下载，调整成新尺寸的大小，然后将这个尺寸的也缓存起来。\n\n具体说来就是：假如在第一个页面有一个200x200的ImageView，在第二个页面有一个100x100的ImageView，这两个ImageView本来是要显示同一张图片，却需要下载两次。\n\n不过，你可以改变这种行为，让Glide既缓存全尺寸又缓存其他尺寸：\n\n```java\nGlide.with(this)\n .load(\"http://nuuneoi.com/uploads/source/playstore/cover.jpg\")\n .diskCacheStrategy(DiskCacheStrategy.ALL)\n .into(ivImgGlide);\n```\n下次在任何ImageView中加载图片的时候，全尺寸的图片将从缓存中取出，重新调整大小，然后缓存。\n\nGlide的这种方式优点是加载显示非常快。而Picasso的方式则因为需要在显示之前重新调整大小而导致一些延迟，即便你添加了这段代码来让其立即显示：\n```java\n//Picasso\n.noFade();\n```\n![](http://jcodecraeer.com/uploads/allimg/150327/163Aa632-0.gif)\n\nPicasso 和 Glide 在磁盘缓存策略上各有所长，你应该根据自己的需求选择最合适的。\n\n对我而言，我更喜欢Glide，因为它远比Picasso快，虽然需要更大的空间来缓存。\n##特性\n\n你可以做到几乎和Picasso一样多的事情，代码也几乎一样。\n\nImage Resizing\n```java\n// Picasso\n.resize(300, 200);\n \n// Glide\n.override(300, 200);\n```\n\nCenter Cropping\n```java\n// Picasso\n.centerCrop();\n \n// Glide\n.centerCrop();\n```\n\nTransforming\n```java\n// Picasso\n.transform(new CircleTransform())\n \n// Glide\n.transform(new CircleTransform(context))\n```\n设置占位图或者加载错误图：\n```java\n// Picasso\n.placeholder(R.drawable.placeholder)\n.error(R.drawable.imagenotfound)\n \n// Glide\n.placeholder(R.drawable.placeholder)\n.error(R.drawable.imagenotfound)\n```\n\n正如我在博文开头所说，如果你已经熟悉如何使用 Picasso，那从Picasso转换到Glide对你来说就是小菜一碟。\n\n \n##有什么Glide可以做而Picasso 做不到\n\nGlide可以加载GIF动态图，而Picasso不能。\n\n![](http://jcodecraeer.com/uploads/20150327/1427445366503084.gif)\n\n\n同时因为Glide和Activity/Fragment的生命周期是一致的，因此gif的动画也会自动的随着Activity/Fragment的状态暂停、重放。Glide 的缓存在gif这里也是一样，调整大小然后缓存。\n\n但是从我的一次测试结果来看，用 Glide 显示动画会消耗很多内存，因此谨慎使用。\n\n除了gif动画之外，Glide还可以将任意本地视频解码成一张静态图片。\n\n还有一个特性是你可以配置图片显示的动画，而Picasso只有一种动画：fading in。\n\n最后一个是可以使用thumbnail()产生一个你所加载图片的thumbnail。\n\n其实还有一些特性，不过不是非常重要，比如将图像转换成字节数组等。\n配置\n\n有许多可以配置的选项，比如大小，缓存的磁盘位置，最大缓存空间，位图格式等等。可以在这个页面查看这些配置 Configuration 。\n\n##库的大小\n\nPicasso (v2.5.1)的大小约118kb，而Glide (v3.5.2)的大小约430kb。\n\n![](http://jcodecraeer.com/uploads/20150327/1427453389115686.png)\n\n不过312kb的差距并不是很重要。\n\nPicasso和Glide的方法个数分别是840和2678个。\n\n![](http://jcodecraeer.com/uploads/20150327/1427453390188737.png)\n\n必须指出，对于DEX文件65535个方法的限制来说，2678是一个相当大的数字了。建议在使用Glide的时候开启ProGuard。\n\n\n##总结\n\nGlide和Picasso都是非常完美的库。Glide加载图像以及磁盘缓存的方式都要优于Picasso，速度更快，并且Glide更有利于减少OutOfMemoryError的发生，GIF动画是Glide的杀手锏。不过Picasso的图片质量更高。你更喜欢哪个呢？\n\n虽然我使用了很长时间的Picasso，但是我得承认现在我更喜欢Glide。我的建议是使用Glide，但是将Bitmap格式换成 ARGB_8888、让Glide缓存同时缓存全尺寸和改变尺寸两种。\n\n \n##相关资源\n\n- [Glide 3.0: a media management library for Android](http://google-opensource.blogspot.com/2014/09/glide-30-media-management-library-for.html) \n- [Glide Wiki](https://github.com/bumptech/glide/wiki) \n- [Android Picasso vs Glide](http://pluu.github.io/android%20study/2015/01/15/android-glide-picasso/) \n- [Android: Image loading libraries Picasso vs Glide](http://vardhan-justlikethat.blogspot.com/2014/09/android-image-loading-libraries-picasso.html) \n\n" }, { "path": "others/InstaMaterial概念设计系列/实现Instagram的Material Design概念设计/readme.md", "content": "实现Instagram的Material Design概念设计\n---\n\n>\n* 原文链接:[Instagram with Material Design concept is getting real ](http://frogermcs.github.io/Instagram-with-Material-Design-concept-is-getting-real/)\n* 译者 : [jianghejie](https://github.com/jianghejie) \n* 译者博文链接 : [jcodecraeer.com](http://jcodecraeer.com/a/anzhuokaifa/androidkaifa/2015/0204/2415.html)\n \n几个月前（这篇文章的日期是2014 年11月10日），google发布了app和web应用的Material Design设计准则之后，设计师Emmanuel Pacamalan在youtube上发布了一则概念视频，演示了Instagram如果做成Material风格会是什么样子：\n\n视频地址在这里 [http://v.youku.com/v_show/id_XODg2NDQ1NDQ4.html](http://v.youku.com/v_show/id_XODg2NDQ1NDQ4.html) ps:markdown不支持播放优酷视频\n\n这 仅仅是停留在图像上的设计，是美好的愿景，估计很多人都会问，能否使用相对简单的办法将它实现出来呢？答案是：yes，不仅仅能实现，而且无须要求在 Lillipop版本，实际上几年前4.0发布之后我们就可以实现这些效果了。ps 读到这里我们应该反思这几年开发者是不是都吃屎去了。\n\n鉴于这个原因，我决定开始撰写一个新的课题-如何将[INSTAGRAM with Material Design](https://www.youtube.com/watch?v=ojwdmgmdR_Q) 视频中的效果转变成现实。当然，我们并不是真的要做一个Instagram应用，只是将界面做出来而已，并且尽量减少一些不必要的细节。\n##开始\n\n本文将要实现的是视频中前7秒钟的效果。我觉得对于第一次尝试来说已经足够了。我想要提醒诸位的是，里面的实现方法不仅仅是能实现，也是我个人最喜欢的实现方式。还有，我不是一个美工，因此项目中的所有图片是直接从网上公开的渠道获取的。（主要是从 [resources page](http://www.google.com/design/spec/resources/sticker-sheets-icons.html) ）。\n\n好了，下面是最终效果的两组截图和视频（很短的视频，就是那7秒钟的效果，可以在上面的视频中看到，这里因为没法直接引用youtube的视频就略了）（分别从Android 4 和5上获得的）：\n\n![](http://jcodecraeer.com/uploads/20150204/1423058817102389.png)\n\n![](http://jcodecraeer.com/uploads/20150204/1423059082492283.png)\n\n\n##准备\n在我们的项目中，将使用一些热门的android开发工具和库。并不是所有这些东西本篇文章都会用到，我只是将它们准备好以备不时之需。\n初始化项目\n\n首先我们需要创建一个新的android项目。我使用的是Android Studio和gradle的build方式。最低版本的sdk是15（即Android 4.0.4）。然后我们将添加一些依赖。没什么好讲的，下面是build.gradle以及app/build.gradle文件的代码：\n\nbuild.gradle\n```gradle\nbuildscript {\n repositories {\n jcenter()\n }\n dependencies {\n classpath 'com.android.tools.build:gradle:0.14.0'\n classpath 'com.jakewharton.hugo:hugo-plugin:1.1.+'\n }\n}\n \nallprojects {\n repositories {\n jcenter()\n }\n}\n```\napp/build.gradle\n```gradle\napply plugin: 'com.android.application'\napply plugin: 'hugo'\n \nandroid {\n compileSdkVersion 21\n buildToolsVersion \"21.1\"\n \n defaultConfig {\n applicationId \"io.github.froger.instamaterial\"\n minSdkVersion 15\n targetSdkVersion 21\n versionCode 1\n versionName \"1.0\"\n }\n}\n \ndependencies {\n compile fileTree(dir: 'libs', include: ['*.jar'])\n \n compile \"com.android.support:appcompat-v7:21.0.0\"\n compile 'com.android.support:support-v13:21.+'\n compile 'com.android.support:support-v4:21.+'\n compile 'com.android.support:palette-v7:+'\n compile 'com.android.support:recyclerview-v7:+'\n compile 'com.android.support:cardview-v7:21.0.+'\n compile 'com.jakewharton:butterknife:5.1.2'\n compile 'com.jakewharton.timber:timber:2.5.0'\n compile 'com.facebook.rebound:rebound:0.3.6'\n}\n```\n\n简而言之，我们有如下工具：\n\n一些兼容包（CardView, RecyclerView, Palette, AppCompat）-我喜欢使用最新的控件。当然你完全可以使用ListView Actionbar甚至View/FrameView来替代，但是为什么要这么折腾？😉\n\n[ButterKnife](http://jakewharton.github.io/butterknife/) - view注入工具简化我们的代码。（比方说不再需要写findViewById()来引用view，以及一些更强大的功能）。\n\n[Rebound](http://facebook.github.io/rebound/) - 我们目前还没有用到，但是我以后肯定会用它。这个facebook开发的动画库可以让你的动画效果看起来更自然。\n\n[Timber](https://github.com/JakeWharton/timber) 和 [Hugo](https://github.com/JakeWharton/hugo) - 对这个项目而言并不是必须，我仅仅是用他们打印log。\n\n##图片资源\n\n本项目中将使用到一些Material Design的图标资源。App 图标来自于 [NSTAGRAM with Material Design](https://www.youtube.com/watch?v=ojwdmgmdR_Q) 视频，[这里](https://github.com/frogermcs/frogermcs.github.io/raw/master/files/2/resources.zip) 是项目的全套资源。\n##样式\n\n我们从定义app的默认样式开始。同时为Android 4和5定义Material Desing样式的最简单的方式是直接继承Theme.AppCompat.NoActionBar 或者 Theme.AppCompat.Light.NoActionBar主题。为什么是NoActionBar？因为新的sdk中为我们提供了实现Actionbar功能的新模式。本例中我们将使用Toolbar控件，基于这个原因-Toolbar是ActionBar更好更灵活的解决方案。我们不会深入讲解这个问题，但你可以去阅读android开发者博客[AppCompat v21](http://android-developers.blogspot.com/2014/10/appcompat-v21-material-design-for-pre.html) 。\n\n\n根据概念视频中的效果，我们在AppTheme中定义了三个基本颜色（基色调）：\n\nstyles.xml\n```xml\n\n\n\n \n\n```\ncolors1.xml\n```xml\n\n\n\n #2d5d82\n #21425d\n #01bcd5\n\n```\n关于这三个颜色的意义，你可以在这里找到Material [Theme Color Palette documentation](http://developer.android.com/training/material/theme.html#ColorPalette) 。 \n##布局\n项目目前主要使用了3个主要的布局元素\n\n *Toolbar* - 包含导航图标和applogo的顶部bar\n\n *TRecyclerView*T - 用于显示feed\n\n *TFloating Action Button* - 一个实现了Material Design中[action button pattern](http://www.google.com/design/spec/components/buttons.html#buttons-flat-raised-buttons)的ImageButton。\n\n在开始实现布局之前，我们先在res/values/dimens.xml文件中定义一些默认值：\n```xml\n\n\n\n 56dp\n 16dp\n 8dp\n\n```\n这些值的大小是基于Material Design设计准则中的介绍。\n\n现在我们来实现MainActivity中的layout：\n\nactivity_main.xml\n```xml\n\n \n \n \n \n \n \n \n \n \n \n\n```\n以上代码的解释:\n\n 关于Toolbar最重要的特征是他现在是activity layout的一部分，而且继承自ViewGroup，因此我们可以在里面放一些UI元素（它们将利用剩余空间）。本例中，它被用来放置logo图片。同时，因为Toolbar是比Actionbar更灵活的控件，我们可以自定义更多的东西，比如设置背景颜色为colorPrimary（否则Toolbar将是透明的）。\n\n RecyclerView虽然在xml中用起来非常简单，但是如果java代码中没有设置正确，app是不能启动的，会报java.lang.NullPointerException。\n\n\n Elevation（ImageButton中）属性不兼容api21以前的版本。所以如果我们想做到Floating Action Button的效果需要在Lollipop和Lollipop之前的设备上使用不同的background。\n\n*Floating Action Button*\n\n为了简化FAB的使用，我们将用对Lollipop以及Lollipop之前的设备使用不同的样式：\n\n*FAB for Android v21:*\n\n![](http://jcodecraeer.com/uploads/20150204/1423059083822681.png)\n\n*FAB for Android pre-21:*\n\n![](http://jcodecraeer.com/uploads/20150204/1423059084110006.png)\n\n我们需要创建两个不同的xml文件来设置button的background：/res/drawable-v21/btn_fab_default.xml（Lollipop设备） ，/res/drawable/btn_fab_default.xml（Lollipop之前的设备）：\n\nbtn_fab_default2.xml\n```xml\n\n\n\n \n \n \n \n \n\n```\nbtn_fab_default1.xml\n```xml\n\n\n\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n\n```\n上面的代码涉及到两个颜色的定义,在res/values/colors.xml中添加：\n```xml\n#00000000\n#40ffffff\n```\n可以看到在 21之前的设备商制造阴影比较复杂。不幸的是在xml中达到真实的阴影效果没有渐变方法。其他的办法是使用图片的方式，或者通过java代码实现（参见[creating fab shadow](http://stackoverflow.com/questions/24480425/android-l-fab-button-shadow)）。\n##Toolbar\n\n现在我们来完成Toolbar。我们已经有了background和应用的logo，现在还剩下navigation以及menu菜单图标了。关于navigation，非常不幸的是，在xml中app:navigationIcon=\"\"是不起作用的，而android:navigationIcon=\"\"又只能在Lollipop上有用，所以只能使用代码的方式了：\n```xml\ntoolbar.setNavigationIcon(R.drawable.ic_menu_white);\n```\n注：app:navigationIcon=\"\"的意思是使用兼容包appcompat的属性，而android:navigationIcon=\"\"是标准的sdk属性。\n\n至于menu图标我们使用标准的定义方式就好了：\n\n在res/menu/menu_main.xml中\n```xml\n\n\n \n\n```\n在activity中inflated这个menu：\n```java\n@Override\npublic boolean onCreateOptionsMenu(Menu menu) {\n getMenuInflater().inflate(R.menu.menu_main, menu);\n return true;\n}\n```\n本应运行的很好，但是正如我在twitter上提到的，Toolbar onClick selectors有不协调的情况：\n\n\n为了解决这个问题，需要做更多的工作，首先为menu item创建一个自定义的view\n\nres/layout/menu_item_view.xml：\n```xml\n\n\n\n```\n然后为Lollipop和Lollipop之前的设备分别创建onClick的selector，在Lollipop上有ripple效果：\nbtn_default_light2.xml\n```xml\n\n\n\n```\nbtn_default_light1.xml\n```xml\n\n\n\n \n \n \n\n```\n现在，工程中的所有的color应该是这样子了：\n\ncolors.xml \n```xml\n\n\n\n#2d5d82\n#21425d\n#01bcd5\n \n#007787\n#44000000\n \n#00000000\n#40ffffff\n\n```\n 最后我们应该将custom view放到menu item中，在onCreateOptionsMenu()中：\n```java\n @Override\npublic boolean onCreateOptionsMenu(Menu menu) {\n getMenuInflater().inflate(R.menu.menu_main, menu);\n inboxMenuItem = menu.findItem(R.id.action_inbox);\n inboxMenuItem.setActionView(R.layout.menu_item_view);\n return true;\n}\n```\n以上就是toolbar的所有东西。并且onClick的按下效果也达到了预期的效果：\n\n![](http://jcodecraeer.com/uploads/20150204/1423059085109860.png)\n\n#Feed\n最后需要实现的是feed，基于RecyclerView实现。我们需要设置两个东西：layout manager和adapter，因为这里其实就是想实现ListView的效果，所以直接用LinearLayoutManager就行了，而adapter我们首先从item的布局开始(res/layout/item_feed.xml)：\n\nitem_feed.xml\n\n```xml\n\n\n \n \n \n \n \n \n \n \n \n \n\n```\nFeedAdapter也非常简单：\n\nFeedAdapter.java\n```java\npublic class FeedAdapter extends RecyclerView.Adapter {\n private static final int ANIMATED_ITEMS_COUNT = 2;\n \n private Context context;\n private int lastAnimatedPosition = -1;\n private int itemsCount = 0;\n \n public FeedAdapter(Context context) {\n this.context = context;\n }\n \n @Override\n public RecyclerView.ViewHolder onCreateViewHolder(ViewGroup parent, int viewType) {\n final View view = LayoutInflater.from(context).inflate(R.layout.item_feed, parent, false);\n return new CellFeedViewHolder(view);\n }\n \n private void runEnterAnimation(View view, int position) {\n if (position >= ANIMATED_ITEMS_COUNT - 1) {\n return;\n }\n \n if (position > lastAnimatedPosition) {\n lastAnimatedPosition = position;\n view.setTranslationY(Utils.getScreenHeight(context));\n view.animate()\n .translationY(0)\n .setInterpolator(new DecelerateInterpolator(3.f))\n .setDuration(700)\n .start();\n }\n }\n \n @Override\n public void onBindViewHolder(RecyclerView.ViewHolder viewHolder, int position) {\n runEnterAnimation(viewHolder.itemView, position);\n CellFeedViewHolder holder = (CellFeedViewHolder) viewHolder;\n if (position % 2 == 0) {\n holder.ivFeedCenter.setImageResource(R.drawable.img_feed_center_1);\n holder.ivFeedBottom.setImageResource(R.drawable.img_feed_bottom_1);\n } else {\n holder.ivFeedCenter.setImageResource(R.drawable.img_feed_center_2);\n holder.ivFeedBottom.setImageResource(R.drawable.img_feed_bottom_2);\n }\n }\n \n @Override\n public int getItemCount() {\n return itemsCount;\n }\n \n public static class CellFeedViewHolder extends RecyclerView.ViewHolder {\n @InjectView(R.id.ivFeedCenter)\n SquaredImageView ivFeedCenter;\n @InjectView(R.id.ivFeedBottom)\n ImageView ivFeedBottom;\n \n public CellFeedViewHolder(View view) {\n super(view);\n ButterKnife.inject(this, view);\n }\n }\n \n public void updateItems() {\n itemsCount = 10;\n notifyDataSetChanged();\n }\n}\n```\n没什么特别之处需要说明。\n\n通过以下方法将他们放在一起：\n```java\nprivate void setupFeed() {\n LinearLayoutManager linearLayoutManager = new LinearLayoutManager(this);\n rvFeed.setLayoutManager(linearLayoutManager);\n feedAdapter = new FeedAdapter(this);\n rvFeed.setAdapter(feedAdapter);\n}\n```\n下面是整个MainActivity class的源码：\n//MainActivity.java\n```java\npublic class MainActivity extends ActionBarActivity {\n @InjectView(R.id.toolbar)\n Toolbar toolbar;\n @InjectView(R.id.rvFeed)\n RecyclerView rvFeed;\n \n private MenuItem inboxMenuItem;\n private FeedAdapter feedAdapter;\n \n @Override\n protected void onCreate(Bundle savedInstanceState) {\n super.onCreate(savedInstanceState);\n setContentView(R.layout.activity_main);\n ButterKnife.inject(this);\n \n setupToolbar();\n setupFeed();\n }\n \n private void setupToolbar() {\n setSupportActionBar(toolbar);\n toolbar.setNavigationIcon(R.drawable.ic_menu_white);\n }\n \n private void setupFeed() {\n LinearLayoutManager linearLayoutManager = new LinearLayoutManager(this);\n rvFeed.setLayoutManager(linearLayoutManager);\n feedAdapter = new FeedAdapter(this);\n rvFeed.setAdapter(feedAdapter);\n }\n \n @Override\n public boolean onCreateOptionsMenu(Menu menu) {\n getMenuInflater().inflate(R.menu.menu_main, menu);\n inboxMenuItem = menu.findItem(R.id.action_inbox);\n inboxMenuItem.setActionView(R.layout.menu_item_view);\n return true;\n }\n}\n\n```\n运行结果：\n\nAndroid Lollipop\n\n![](http://jcodecraeer.com/uploads/20150204/1423059086107717.png)\n\n\nAndroid pre-21\n\n![](http://jcodecraeer.com/uploads/20150204/1423059082492283.png)\n\n##动画\n\n最后一件也是最重要的事情就是进入时的动画效果，再浏览一遍概念视频，可以发现在main Activity启动的时候有如下动画，分成两步：\n\n\n显示Toolbar以及其里面的元素\n\n在Toolbar动画完成之后显示feed和floating action button。\n\nToolbar中元素的动画表现为在较短的时间内一个接一个的进入。实现这个效果的主要问题在于navigation icon的动画，navigation icon是唯一一个不能使用动画的，其他的都好办。\n*Toolbar animation*\n\n首先我们只是需要在activity启动的时候才播放动画（在旋转屏幕的时候不播放），还要知道menu的动画过程是不能在onCreate()中去实现的（我们在onCreateOptionsMenu()中实现），创建一个布尔类型的变量pendingIntroAnimation ，在onCreate()方法中初始化：\n```java\n//...\nif (savedInstanceState == null) {\n pendingIntroAnimation = true;\n}\n```\nonCreateOptionsMenu():\n```java\n@Override\npublic boolean onCreateOptionsMenu(Menu menu) {\n getMenuInflater().inflate(R.menu.menu_main, menu);\n inboxMenuItem = menu.findItem(R.id.action_inbox);\n inboxMenuItem.setActionView(R.layout.menu_item_view);\n if (pendingIntroAnimation) {\n pendingIntroAnimation = false;\n startIntroAnimation();\n }\n return true;\n}\n```\n这样startIntroAnimation()将只被调用一次。\n\n现在该来准备Toolbar中元素的动画了，也非常简单\n\nToolbarAnimation\n```java\n//...\nprivate static final int ANIM_DURATION_TOOLBAR = 300;\n \nprivate void startIntroAnimation() {\n btnCreate.setTranslationY(2 * getResources().getDimensionPixelOffset(R.dimen.btn_fab_size));\n int actionbarSize = Utils.dpToPx(56);\n toolbar.setTranslationY(-actionbarSize);\n ivLogo.setTranslationY(-actionbarSize);\n inboxMenuItem.getActionView().setTranslationY(-actionbarSize);\n \n toolbar.animate()\n .translationY(0)\n .setDuration(ANIM_DURATION_TOOLBAR)\n .setStartDelay(300);\n ivLogo.animate()\n .translationY(0)\n .setDuration(ANIM_DURATION_TOOLBAR)\n .setStartDelay(400);\n inboxMenuItem.getActionView().animate()\n .translationY(0)\n .setDuration(ANIM_DURATION_TOOLBAR)\n .setStartDelay(500)\n .setListener(new AnimatorListenerAdapter() {\n @Override\n public void onAnimationEnd(Animator animation) {\n startContentAnimation();\n }\n })\n .start();\n}\n//...\n```\n在上面的代码中：\n\n 首先我们将所有的元素都通过移动到屏幕之外隐藏起来（这一步我们将FAB也隐藏了）。\n\n 让Toolbar元素一个接一个的开始动画\n\n 当动画完成，调用了startContentAnimation()开始content的动画（FAB和feed卡片的动画）\n\n 简单，是吧？\n*Content 动画*\n\n在这一步中我们将让FAB和feed卡片动起来。FAB的动画很简单，跟上面的方法类似，但是feed卡片稍微复杂些。\n\nstartContentAnimation方法\n```java\n//...\n//FAB animation\nprivate static final int ANIM_DURATION_FAB = 400;\n \nprivate void startContentAnimation() {\n btnCreate.animate()\n .translationY(0)\n .setInterpolator(new OvershootInterpolator(1.f))\n .setStartDelay(300)\n .setDuration(ANIM_DURATION_FAB)\n .start();\n feedAdapter.updateItems();\n}\n//...\n```\nFeedAdapter的代码在上面已经贴出来了。结合着就知道动画是如何实现的了。\n\n\n本篇文章就结束了，避免遗漏，这里是这篇文章是提交的代码 [commit for our project with implemented animations](https://github.com/frogermcs/InstaMaterial/commit/4e838861c5f858711b1072777cae2325ce12ee21) .\n\n \n##源代码\n\n完整的代码在[Github repository](https://github.com/frogermcs/InstaMaterial).\n\n作者: Miroslaw Stanek\n" }, { "path": "others/VectorDrawable系列/VectorDrawable – 第一章/readme.md", "content": "VectorDrawable-第一章\n---\n\n>\n* 原文链接:[VectorDrawables – Part 1](https://blog.stylingandroid.com/vectordrawables-part-1/)\n* 译者 : [jianghejie](https://github.com/jianghejie) \n* 译者博文链接 : [jcodecraeer.com](http://jcodecraeer.com/a/anzhuokaifa/androidkaifa/2015/0201/2396.html)\n \n\nLollipop中有一个非常好的新特性是VectorDrawable以及相关的一些类，他们为我们提供了添加复杂矢量图形的强大功能，同时也提供了动画显示这些图形的方法。矢量图形的好处是放大不会失真，可以适应不同分辨率的屏幕。这个文章系列我们将了解这些类以及它们的优点，以及如何用相对较少的代码实现吸引人的效果。\n\n \n\n 简单的来说，矢量图形就是使用几何形状的方式来描述一个图像元素。矢量图形非常适合于与设备无关的简单或者合成的制图或者不需要实现真实感的场合。Adobe Illustrator和Inkscape 常用来制作矢量图形。而位图（Bitmap ），则完全相反，位图是定义每一个像素点的颜色来显示一张图片，它适合显示一张真实的照片。矢量图形的一大好处是它的渲染是在运行时开始的，因此它可以自适应不同的屏幕。由于矢量图其实保存的只是描述几何图形的文本，因此它只占用非常少的空间。当然因为需要在运行时将这些字符串转换成图像，花费多一点点的cpu是肯定的。\n\n \n\n矢量图形在安卓的Lollipop中已经实现了，相关的类就是VectorDrawable 。（虽然第三方的MrVector 已经实现了VectorDrawable 兼容Lollipop 之前的设备，但是它并没有实现后面会讲到的AnimatedVectorDrawable ）。VectorDrawable 的出现意味着以前我们放在mdpi, hdpi, xhdpi, xxhdpi中的部分图片资源（适合用矢量图描述的，比如图标）只用一个VectorDrawable 替代就可以了。\n\n为了说明，我找了下面这张svg文件（这个文件可以从library for displaying SVG graphics in Android 中获取到），图片是一个机器人 ：\n\n![](https://blog.stylingandroid.com/wp-content/uploads/2014/12/android.svg)\n这个文件的svg格式只有2265字节，但是如果我们将它转换成500 x 500的bitmap文件，保存成png格式，则有13272 字节。并且它可以自动伸缩为任意大小的图片，而位图就需要使用多张才能达到不同分辨率的效果。不过，这里以svg作为例子还是有点问题，因为svg并非VectorDrawable，所以我们不能直接使用svg图片。但是VectorDrawable 支持svg的一部分规则，我们可以将svg中的某些数据用在VectorDrawable中。主要其实就是svg中定义path的那部分数据。Svg的path类似于android.graphics.Path api，只不过是用字符串定义的，我们看看svg的源码就知道了：\n```xml\n\n\n\n\n\n \n\n\n \n \n \n \n \n \n\n\n```\n看起来很乱，我们不需要知道其内部的细节，只把我们用得着的东西筛选出来就行了。 标签中定义了一些属性：画布以及视图区域大小为500 x 500 px，然后有一个标签，里面定义了一个描边，忽略掉就是了。再后又是一个标签，这个标签的id为“android”，这部分里面的东西才是机器人logo自身的数据，也是我们需要的数据。它包含了6个 元素，分别定义head、左眼、右眼、左手、身体和脚、右手。每一个path中的fill 属性定义填充色（可以看到，除了眼睛为白色之外，所有的填充色都是绿色），fill属性之后是包含path数据的属性d。想了解d属性中数据定义的可以参考SVG Path Specification ，但是这个不重要，因为我们只需简单的把这里面的数据直接用在VectorDrawable中就可以了。\n\n好了，我们来创建一个VectorDrawable：\n```xml\n\n\n \n \n \n \n \n \n \n \n\n```\n我们创建一个 元素，指定了宽和高，然后创建包含了6个元素的元素。这6个元素的定义非常类似svg中的定义，只有非常小的差别，大部分内容都是直接从svg中copy的。我们还定义了name 属性来描述每个path的作用。这个文件保存下来仍然只有2412字节。\n\n下面我们可以就像一般drawable一样去使用上面定义的VectorDrawable了。\n```xml\n\n \n \n \n\n```\n运行结果如下：\n\n ![](http://jcodecraeer.com/uploads/20150201/1422796393485613.png)\n\n有一个小问题：这个VectorDrawable渲染的非常好，但是我遇到过从其他的svg文件中复制的VectorDrawable 在Android Studio中无法预览的情况（在真实设备中运行却是正常的），因此不管Android Studio是否能正常预览，还是以真实设备为准吧，Android Studio是有bug的。我用的是V1.0.2 版本，关于这个bug在这里有描述：[点击这里](https://code.google.com/p/android/issues/detail?id=91383) 。\n\n现在我们可以使用VectorDrawable大幅度的减小我们的apk了，而且这还让我们在维护app的时候容易的多，至少在使用VectorDrawable的资源上我们不需要因为要兼容新的设备而修改。这还只是VectorDrawable的一个用处，在后面的文章中我们将看到VectorDrawable是如何动画的。\n\n这篇文章的代码可以在这里得到：[这里](https://bitbucket.org/StylingAndroid/vectordrawables/src/b4767fe0e0a7b41323adbfd77845ed1ec24822c3/?at=Part1)。\n\n \n\n英文原文：https://blog.stylingandroid.com/vectordrawables-part-1/ " }, { "path": "others/VectorDrawable系列/VectorDrawable – 第二章/readme.md", "content": "VectorDrawable-第二章\n---\n\n>\n* 原文链接:[VectorDrawables – Part 2](https://blog.stylingandroid.com/vectordrawables-part-2/)\n* 译者 : [jianghejie](https://github.com/jianghejie) \n* 译者博文链接 : [jcodecraeer.com](http://jcodecraeer.com/a/anzhuokaifa/androidkaifa/2015/0301/2514.html)\n \n[上篇文章](http://jcodecraeer.com/a/anzhuokaifa/androidkaifa/2015/0201/2396.html) 中，我们探讨了如何将svg图片转换成VectorDrawable，以在适应不同分辨率的同时减少资源文件的个数，同时也更易于维护。但是这并不是VectorDrawable的唯一好处-还可以用来制作动画。这篇文章就是关于如何用VectorDrawable来实现android机器人耸肩的效果！\n\n我们将要实现的动画很简单，在保持身体不动的同时，让头部和手臂在Y方向上上下移动。表面上看实现起来很复杂，因为我们这里只有一个Drawable（要是一般的Drawable估计的通过绘制来实现了）。但是有一个控件却可以使事情变得非常简单，那就是在Lollipop中和VectorDrawable一起被引入的AnimatedVectorDrawable。在上篇文章中，我们讲到了path元素的name属性是为了描述path的用处，但它还可以用在为指定path指定一个动画。本例中我们需要动画的path元素是头部，左眼，右眼，左臂，右臂。问题是单个的是没有translateX和translateY属性的，因此无法使用属性动画来控制translateY，而元素是有的，所以我们需要先将相关的元素包裹在一个个的元素中：\n```xml\n\n\n \n \n \n \n \n \n \n \n \n \n \n \n \n```\n现在再我们定义一个包含的drawable文件，这个文件的作用是将动画应用在指定的group中，使得某些部分的path动起来：\n```xml\n\n\n \n \n \n \n\n```\n\n虽然我知道完全可以将头、眼、和手臂放在一个group中，但是为了演示一个是如何控制多个group的动画的，我有意把他们分成两部分，实际运用中，不同的group目标动画肯定是不一样的。\n\n的最外层元素指定了我们要动画的VectorDrawable资源-在本例中这个资源是android.xml，里面的元素根据group的name属性指定group的动画效果。\n\n, , , 和 元素都有各自可以播放动画的属性，查阅VectorDrawable JavaDocs你会找到每种元素到底有那些属性，以便针对这些属性播放特定的动画。比如：要使用tint效果需要作用于元素上，而修改填充颜色则需要作用于元素。\n\n耸肩的效果很简单，只是个重复移动Y轴的animator：\n```xml\n\n\n \n\n```\n为了运行这个动画我们需要做几件事情。首先，要将ImageView的src改为动画效果的drawable。\n```xml\n\n \n \n \n\n```\n如果运行现在的代码，我们只能看到静态的图片。这是因为我们需要手动调用播放动画。我们将在Activity中去调用，如果Drawable是Animatable（AnimatedVectorDrawable实现了Animatable）的实例，将开始动画。\n```xml\npublic class VectorDrawablesActivity extends Activity {\n \n @Override\n protected void onCreate(Bundle savedInstanceState) {\n super.onCreate(savedInstanceState);\n setContentView(R.layout.activity_vector_drawables);\n ImageView androidImageView = (ImageView) findViewById(R.id.android);\n Drawable drawable = androidImageView.getDrawable();\n if (drawable instanceof Animatable) {\n ((Animatable) drawable).start();\n }\n }\n}\n```\n运行代码就会发现指定了animation的path出现动画效果：\n\n![](http://jcodecraeer.com/uploads/20150306/1425623349523137.gif)\n\n在接下来的文章中，我们将更深入的去了解AnimatedVectorDrawable，实现更酷的效果。\n\n本篇文章的源代码在 [这里](http://code.stylingandroid.com/vectordrawables/src/f4c31878fdfa3b9205bb58016c20c789e4dc426a/?at=Part2).\n\n\n\n\n" }, { "path": "others/上传拍下的照片、视频到服务器/readme.md", "content": "上传拍下的照片、视频到服务器\n---\n\n>\n* 原文链接 : [Android Uploading Camera Image, Video to Server with Progress Bar](http://www.androidhive.info/2014/12/android-uploading-camera-image-video-to-server-with-progress-bar/)\n* 作者 : [Ravi Tamada](http://www.androidhive.info/)\n* 译者 : [chaossss](https://github.com/chaossss) \n* 校对者: [Mr.Simple](https://github.com/bboyfeiyu) \n* 状态 : 校对完成\n\n\n我在上一篇教程中给大家讲解了怎么通过进度条下载文件，今天，我将在这篇文章中给大家讲解如果在弹出进度条的同时上传一个文件到服务器。通过阅读这篇文章，并学习其中的知识，你能做出一个类似 Instagram 的App，在你做出的 App 里，你能够像在 Instagram 里那样用摄像头拍照/视频，然后把它们上传到服务器。在服务器端，我使用 PHP 读取上传的文件，并把文件移动到一个特殊的位置。\n\n这篇文章最精华的部分在于：即使是上传大文件，它也能很好地运行，而不是产生许多内存不足的错误。我能有这样的自信，是因为我进行了许多的测试。在测试过程中，即便我上传了一个 50MB 的文件，这个功能仍然运行得很完美，不会出现错误。\n\n[源码下载](http://download.androidhive.info/)\n\n## 准备工作 ##\n\n由于这篇文章需要上传摄像头拍下来的照片/视频，因此你需要先了解有关 Android 摄像头模块的知识。所以我建议你最好先去阅读我之前的一篇有关 Android 是如何操作摄像头的讲解文章，通过阅读这篇文章你能大概了解怎么在你的 Android App 中使用摄像头。\n\n## 创建 Android 工程 ##\n\n1、 在 Eclipse 中创建一个新的 Android 工程，具体流程如下：New ⇒ Android Application Project，然后在里面填好一些必要的信息。\n\n2、 打开 res 文件夹中的 strings.xml,然后把下面的内容添加进去：\n\n**strings.xml**\n\n```xml\n \n \n \n \t\t Camera File Upload\n \t Capture Image\n \t Record Video\n \t (or)\n \t Upload to Server\n \n \n```\n \n3、 向 res 文件夹添加 colors.xml，并把下面的内容添加进去：\n\n**colors.xml**\n\n```xml\n\t\n\t\n\t \n\t\t#e8ecfa\n\t\t#277bec\n\t\t#ffffff\n\t\t#4e5572\n\t\t#1f2649\n\t \n\t\n```\n\n4、 在 src 目录下创建一个叫做 Config 的类。这个类用于保存文件上传所送到的 URL 地址，还有在移动设备中存储图片/视频的目录名称。你可能需要在测试 App 时使用你自己的 URL 地址进行上传操作。\n\n5、 创建一个叫做 AndroidMultiPartEntity 的类，并把下面的代码复制进去。这个类是一个自定义的 MultipartEntity 类，主要用于提供这个工程中需要用到的关键功能，例如进度条的进度增量。\n\n**AndroidMultiPartEntity.java**\n\n```java\n package info.androidhive.camerafileupload;\n \n import java.io.FilterOutputStream;\n import java.io.IOException;\n import java.io.OutputStream;\n import java.nio.charset.Charset;\n \n import org.apache.http.entity.mime.HttpMultipartMode;\n import org.apache.http.entity.mime.MultipartEntity;\n \n @SuppressWarnings(\"deprecation\")\n public class AndroidMultiPartEntity extends MultipartEntity\n \n {\n \n \tprivate final ProgressListener listener;\n \n \tpublic AndroidMultiPartEntity(final ProgressListener listener) {\n \t\tsuper();\n \t\tthis.listener = listener;\n \t}\n \n \tpublic AndroidMultiPartEntity(final HttpMultipartMode mode,\n \t\tfinal ProgressListener listener) {\n \t\tsuper(mode);\n \t\tthis.listener = listener;\n \t}\n \n \tpublic AndroidMultiPartEntity(HttpMultipartMode mode, final String boundary,\n \t\tfinal Charset charset, final ProgressListener listener) {\n \t\tsuper(mode, boundary, charset);\n \t\tthis.listener = listener;\n \t}\n \n \t@Override\n \tpublic void writeTo(final OutputStream outstream) throws IOException {\n \t\tsuper.writeTo(new CountingOutputStream(outstream, this.listener));\n \t}\n \n \tpublic static interface ProgressListener {\n \t\tvoid transferred(long num);\n \t}\n \n \tpublic static class CountingOutputStream extends FilterOutputStream {\n \n \t\tprivate final ProgressListener listener;\n \t\tprivate long transferred;\n \n \t\tpublic CountingOutputStream(final OutputStream out,\n \t\t\tfinal ProgressListener listener) {\n \t\t\t\tsuper(out);\n \t\t\t\tthis.listener = listener;\n \t\t\t\tthis.transferred = 0;\n \t\t}\n \n\t public void write(byte[] b, int off, int len) throws IOException {\n\t \tout.write(b, off, len);\n\t \tthis.transferred += len;\n\t \tthis.listener.transferred(this.transferred);\n\t }\n \n\t public void write(int b) throws IOException {\n\t \tout.write(b);\n\t \tthis.transferred++;\n\t \tthis.listener.transferred(this.transferred);\n\t }\n \t }\n\t}\n```\n\n现在我们需要通过在 App 中添加一个简单的页面来添加摄像头功能，在这里我们将使用两个 Button 来调用我们的摄像头为我们的 App 拍照/视频。\n\n6、 在你的 AndroidManifest.xml 中添加相应的权限。你会注意到 UploadActivity 也需要被添加到 AndroidManifest.xml 文件中，我们会在后面提到这个。\n\n**INTERNET** – 联网权限\n\n**WRITE_EXTERNAL_STORAGE** – 存储照片/视频到本地的权限\n\n**RECORD_AUDIO** – 拍摄权限\n\n**AndroidManifest.xml**\n\n```xml\n \n \n\t \n\t \n\t \n\t \n\t \n\t \n\t \n\t \n\t \n\t \n\t \n\t \n\t \n\t \n\t \n\t \n\t \n\t \n\n \n```\n\n7、打开你 MainActivity 的布局文件（activity_main.xml)，并添加下面的代码，这样做能让你的布局拥有两个 Button。\n\n**activity_main.xml**\n\n```xml\n\t\n\t\t\n\t \n\t \n\t \n\t \n\t \n\t \n\t \n\t \n\t \n\t \n\t \n\t \n\t \n\n\t\n```\n\n8、在你的 MainActivity 中添加使用摄像头的相关代码，这些代码和这个系列的教程中使用的代码是一样的。简单来说，这个 Activity 主要会完成下面的工作：\n\n- 这个 App 在安装并打开后，能够通过点击 Button 拍照/视频。\n\n- 只要照片/视频被拍下来，就会保存在移动设备的 SD 卡上\n\n- 最后， 通过传递 SD 卡中储存媒体文件的对应路径，UploadActivity 会被打开，然后执行上传的流程。\n\n**MainActivity.java**\n\n```java\n\tpackage info.androidhive.camerafileupload;\n\t \n\timport java.io.File;\n\timport java.text.SimpleDateFormat;\n\timport java.util.Date;\n\timport java.util.Locale;\n\t \n\timport android.app.Activity;\n\timport android.content.Intent;\n\timport android.content.pm.PackageManager;\n\timport android.graphics.Color;\n\timport android.graphics.drawable.ColorDrawable;\n\timport android.net.Uri;\n\timport android.os.Bundle;\n\timport android.os.Environment;\n\timport android.provider.MediaStore;\n\timport android.util.Log;\n\timport android.view.View;\n\timport android.widget.Button;\n\timport android.widget.Toast;\n\t \n\tpublic class MainActivity extends Activity {\n\t \n\t // LogCat tag\n\t private static final String TAG = MainActivity.class.getSimpleName();\n\t \n\t \n\t // Camera activity request codes\n\t private static final int CAMERA_CAPTURE_IMAGE_REQUEST_CODE = 100;\n\t private static final int CAMERA_CAPTURE_VIDEO_REQUEST_CODE = 200;\n\t \n\t public static final int MEDIA_TYPE_IMAGE = 1;\n\t public static final int MEDIA_TYPE_VIDEO = 2;\n\t \n\t private Uri fileUri; // file url to store image/video\n\t \n\t private Button btnCapturePicture, btnRecordVideo;\n\t \n\t @Override\n\t protected void onCreate(Bundle savedInstanceState) {\n\t super.onCreate(savedInstanceState);\n\t setContentView(R.layout.activity_main);\n\t \n\t // Changing action bar background color\n\t // These two lines are not needed\n\t getActionBar().setBackgroundDrawable(new ColorDrawable(Color.parseColor(getResources().getString(R.color.action_bar))));\n\t \n\t btnCapturePicture = (Button) findViewById(R.id.btnCapturePicture);\n\t btnRecordVideo = (Button) findViewById(R.id.btnRecordVideo);\n\t \n\t /**\n\t * Capture image button click event\n\t */\n\t btnCapturePicture.setOnClickListener(new View.OnClickListener() {\n\t \n\t @Override\n\t public void onClick(View v) {\n\t // capture picture\n\t captureImage();\n\t }\n\t });\n\t \n\t /**\n\t * Record video button click event\n\t */\n\t btnRecordVideo.setOnClickListener(new View.OnClickListener() {\n\t \n\t @Override\n\t public void onClick(View v) {\n\t // record video\n\t recordVideo();\n\t }\n\t });\n\t \n\t // Checking camera availability\n\t if (!isDeviceSupportCamera()) {\n\t Toast.makeText(getApplicationContext(),\n\t \"Sorry! Your device doesn't support camera\",\n\t Toast.LENGTH_LONG).show();\n\t // will close the app if the device does't have camera\n\t finish();\n\t }\n\t }\n\t \n\t /**\n\t * Checking device has camera hardware or not\n\t * */\n\t private boolean isDeviceSupportCamera() {\n\t if (getApplicationContext().getPackageManager().hasSystemFeature(\n\t PackageManager.FEATURE_CAMERA)) {\n\t // this device has a camera\n\t return true;\n\t } else {\n\t // no camera on this device\n\t return false;\n\t }\n\t }\n\t \n\t /**\n\t * Launching camera app to capture image\n\t */\n\t private void captureImage() {\n\t Intent intent = new Intent(MediaStore.ACTION_IMAGE_CAPTURE);\n\t \n\t fileUri = getOutputMediaFileUri(MEDIA_TYPE_IMAGE);\n\t \n\t intent.putExtra(MediaStore.EXTRA_OUTPUT, fileUri);\n\t \n\t // start the image capture Intent\n\t startActivityForResult(intent, CAMERA_CAPTURE_IMAGE_REQUEST_CODE);\n\t }\n\t \n\t /**\n\t * Launching camera app to record video\n\t */\n\t private void recordVideo() {\n\t Intent intent = new Intent(MediaStore.ACTION_VIDEO_CAPTURE);\n\t \n\t fileUri = getOutputMediaFileUri(MEDIA_TYPE_VIDEO);\n\t \n\t // set video quality\n\t intent.putExtra(MediaStore.EXTRA_VIDEO_QUALITY, 1);\n\t \n\t intent.putExtra(MediaStore.EXTRA_OUTPUT, fileUri); // set the image file\n\t // name\n\t \n\t // start the video capture Intent\n\t startActivityForResult(intent, CAMERA_CAPTURE_VIDEO_REQUEST_CODE);\n\t }\n\t \n\t /**\n\t * Here we store the file url as it will be null after returning from camera\n\t * app\n\t */\n\t @Override\n\t protected void onSaveInstanceState(Bundle outState) {\n\t super.onSaveInstanceState(outState);\n\t \n\t // save file url in bundle as it will be null on screen orientation\n\t // changes\n\t outState.putParcelable(\"file_uri\", fileUri);\n\t }\n\t \n\t @Override\n\t protected void onRestoreInstanceState(Bundle savedInstanceState) {\n\t super.onRestoreInstanceState(savedInstanceState);\n\t \n\t // get the file url\n\t fileUri = savedInstanceState.getParcelable(\"file_uri\");\n\t }\n\t \n\t \n\t \n\t /**\n\t * Receiving activity result method will be called after closing the camera\n\t * */\n\t @Override\n\t protected void onActivityResult(int requestCode, int resultCode, Intent data) {\n\t // if the result is capturing Image\n\t if (requestCode == CAMERA_CAPTURE_IMAGE_REQUEST_CODE) {\n\t if (resultCode == RESULT_OK) {\n\t \n\t // successfully captured the image\n\t // launching upload activity\n\t launchUploadActivity(true);\n\t \n\t \n\t } else if (resultCode == RESULT_CANCELED) {\n\t \n\t // user cancelled Image capture\n\t Toast.makeText(getApplicationContext(),\n\t \"User cancelled image capture\", Toast.LENGTH_SHORT)\n\t .show();\n\t \n\t } else {\n\t // failed to capture image\n\t Toast.makeText(getApplicationContext(),\n\t \"Sorry! Failed to capture image\", Toast.LENGTH_SHORT)\n\t .show();\n\t }\n\t \n\t } else if (requestCode == CAMERA_CAPTURE_VIDEO_REQUEST_CODE) {\n\t if (resultCode == RESULT_OK) {\n\t \n\t // video successfully recorded\n\t // launching upload activity\n\t launchUploadActivity(false);\n\t \n\t } else if (resultCode == RESULT_CANCELED) {\n\t \n\t // user cancelled recording\n\t Toast.makeText(getApplicationContext(),\n\t \"User cancelled video recording\", Toast.LENGTH_SHORT)\n\t .show();\n\t \n\t } else {\n\t // failed to record video\n\t Toast.makeText(getApplicationContext(),\n\t \"Sorry! Failed to record video\", Toast.LENGTH_SHORT)\n\t .show();\n\t }\n\t }\n\t }\n\t \n\t private void launchUploadActivity(boolean isImage){\n\t Intent i = new Intent(MainActivity.this, UploadActivity.class);\n\t i.putExtra(\"filePath\", fileUri.getPath());\n\t i.putExtra(\"isImage\", isImage);\n\t startActivity(i);\n\t }\n\t \n\t /**\n\t * ------------ Helper Methods ---------------------- \n\t * */\n\t \n\t /**\n\t * Creating file uri to store image/video\n\t */\n\t public Uri getOutputMediaFileUri(int type) {\n\t return Uri.fromFile(getOutputMediaFile(type));\n\t }\n\t \n\t /**\n\t * returning image / video\n\t */\n\t private static File getOutputMediaFile(int type) {\n\t \n\t // External sdcard location\n\t File mediaStorageDir = new File(\n\t Environment\n\t .getExternalStoragePublicDirectory(Environment.DIRECTORY_PICTURES),\n\t Config.IMAGE_DIRECTORY_NAME);\n\t \n\t // Create the storage directory if it does not exist\n\t if (!mediaStorageDir.exists()) {\n\t if (!mediaStorageDir.mkdirs()) {\n\t Log.d(TAG, \"Oops! Failed create \"\n\t + Config.IMAGE_DIRECTORY_NAME + \" directory\");\n\t return null;\n\t }\n\t }\n\t \n\t // Create a media file name\n\t String timeStamp = new SimpleDateFormat(\"yyyyMMdd_HHmmss\",\n\t Locale.getDefault()).format(new Date());\n\t File mediaFile;\n\t if (type == MEDIA_TYPE_IMAGE) {\n\t mediaFile = new File(mediaStorageDir.getPath() + File.separator\n\t + \"IMG_\" + timeStamp + \".jpg\");\n\t } else if (type == MEDIA_TYPE_VIDEO) {\n\t mediaFile = new File(mediaStorageDir.getPath() + File.separator\n\t + \"VID_\" + timeStamp + \".mp4\");\n\t } else {\n\t return null;\n\t }\n\t \n\t return mediaFile;\n\t }\n\t}\n```\n\n如果你现在运行你的 App，你会看到类似下面这样的输出结果。\n\n![](http://cdn4.androidhive.info/wp-content/uploads/2014/12/android-file-upload-camera-screen.jpg?6141f6)\n\n![](http://cdn2.androidhive.info/wp-content/uploads/2014/12/android-file-upload-camera-taking-camera-picture.jpg?6141f6)\n\n只要你能够打开摄像头并拍着照片/视频，我们就能继续今天的学习，也就是接下来要讲的——创建实现上传功能的 Activity。\n\n9、在 res 文件夹中创建一个 activity_upload.xml 文件，这个布局提供了 ImageView、VideoView 用以预览拍下来的照片/视频，此外，还有一个 ProgressBar 被用于展现上传进度。\n\n**activity_upload.xml**\n\n```xml\n\t\n\t\n\t \n\t \n\t \n\t \n\t \n\t \n\t \n\t \n\t \n\t \n\t \n\t \n\t \n\t \n\t \n\t \n\t \n\t\n```\n\n10、创建一个叫做 UploadActivity 的类，并把下面的代码复制进去。在这个类里，我们主要完成下面两项工作：\n\n- 接收 MainActivity 传过来的媒体文件路径，并把媒体文件显示在我们的视图中供以预览。\n\n- 通过 UploadFileToServer()方法我们异步处理了上传文件到服务器和更新进度条进度两项工作。\n\n**UploadActivity.java**\n\n```java\n\tpackage info.androidhive.camerafileupload;\n\t \n\timport info.androidhive.camerafileupload.AndroidMultiPartEntity.ProgressListener;\n\t \n\timport java.io.File;\n\timport java.io.IOException;\n\t \n\timport org.apache.http.HttpEntity;\n\timport org.apache.http.HttpResponse;\n\timport org.apache.http.client.ClientProtocolException;\n\timport org.apache.http.client.HttpClient;\n\timport org.apache.http.client.methods.HttpPost;\n\timport org.apache.http.entity.mime.content.FileBody;\n\timport org.apache.http.entity.mime.content.StringBody;\n\timport org.apache.http.impl.client.DefaultHttpClient;\n\timport org.apache.http.util.EntityUtils;\n\t \n\timport android.app.Activity;\n\timport android.app.AlertDialog;\n\timport android.content.DialogInterface;\n\timport android.content.Intent;\n\timport android.graphics.Bitmap;\n\timport android.graphics.BitmapFactory;\n\timport android.graphics.Color;\n\timport android.graphics.drawable.ColorDrawable;\n\timport android.os.AsyncTask;\n\timport android.os.Bundle;\n\timport android.util.Log;\n\timport android.view.View;\n\timport android.widget.Button;\n\timport android.widget.ImageView;\n\timport android.widget.ProgressBar;\n\timport android.widget.TextView;\n\timport android.widget.Toast;\n\timport android.widget.VideoView;\n\t \n\tpublic class UploadActivity extends Activity {\n\t // LogCat tag\n\t private static final String TAG = MainActivity.class.getSimpleName();\n\t \n\t private ProgressBar progressBar;\n\t private String filePath = null;\n\t private TextView txtPercentage;\n\t private ImageView imgPreview;\n\t private VideoView vidPreview;\n\t private Button btnUpload;\n\t long totalSize = 0;\n\t \n\t @Override\n\t protected void onCreate(Bundle savedInstanceState) {\n\t super.onCreate(savedInstanceState);\n\t setContentView(R.layout.activity_upload);\n\t txtPercentage = (TextView) findViewById(R.id.txtPercentage);\n\t btnUpload = (Button) findViewById(R.id.btnUpload);\n\t progressBar = (ProgressBar) findViewById(R.id.progressBar);\n\t imgPreview = (ImageView) findViewById(R.id.imgPreview);\n\t vidPreview = (VideoView) findViewById(R.id.videoPreview);\n\t \n\t // Changing action bar background color\n\t getActionBar().setBackgroundDrawable(\n\t new ColorDrawable(Color.parseColor(getResources().getString(\n\t R.color.action_bar))));\n\t \n\t // Receiving the data from previous activity\n\t Intent i = getIntent();\n\t \n\t // image or video path that is captured in previous activity\n\t filePath = i.getStringExtra(\"filePath\");\n\t \n\t // boolean flag to identify the media type, image or video\n\t boolean isImage = i.getBooleanExtra(\"isImage\", true);\n\t \n\t if (filePath != null) {\n\t // Displaying the image or video on the screen\n\t previewMedia(isImage);\n\t } else {\n\t Toast.makeText(getApplicationContext(),\n\t \"Sorry, file path is missing!\", Toast.LENGTH_LONG).show();\n\t }\n\t \n\t btnUpload.setOnClickListener(new View.OnClickListener() {\n\t \n\t @Override\n\t public void onClick(View v) {\n\t // uploading the file to server\n\t new UploadFileToServer().execute();\n\t }\n\t });\n\t \n\t }\n\t \n\t /**\n\t * Displaying captured image/video on the screen\n\t * */\n\t private void previewMedia(boolean isImage) {\n\t // Checking whether captured media is image or video\n\t if (isImage) {\n\t imgPreview.setVisibility(View.VISIBLE);\n\t vidPreview.setVisibility(View.GONE);\n\t // bimatp factory\n\t BitmapFactory.Options options = new BitmapFactory.Options();\n\t \n\t // down sizing image as it throws OutOfMemory Exception for larger\n\t // images\n\t options.inSampleSize = 8;\n\t \n\t final Bitmap bitmap = BitmapFactory.decodeFile(filePath, options);\n\t \n\t imgPreview.setImageBitmap(bitmap);\n\t } else {\n\t imgPreview.setVisibility(View.GONE);\n\t vidPreview.setVisibility(View.VISIBLE);\n\t vidPreview.setVideoPath(filePath);\n\t // start playing\n\t vidPreview.start();\n\t }\n\t }\n\t \n\t /**\n\t * Uploading the file to server\n\t * */\n\t private class UploadFileToServer extends AsyncTask {\n\t @Override\n\t protected void onPreExecute() {\n\t // setting progress bar to zero\n\t progressBar.setProgress(0);\n\t super.onPreExecute();\n\t }\n\t \n\t @Override\n\t protected void onProgressUpdate(Integer... progress) {\n\t // Making progress bar visible\n\t progressBar.setVisibility(View.VISIBLE);\n\t \n\t // updating progress bar value\n\t progressBar.setProgress(progress[0]);\n\t \n\t // updating percentage value\n\t txtPercentage.setText(String.valueOf(progress[0]) + \"%\");\n\t }\n\t \n\t @Override\n\t protected String doInBackground(Void... params) {\n\t return uploadFile();\n\t }\n\t \n\t @SuppressWarnings(\"deprecation\")\n\t private String uploadFile() {\n\t String responseString = null;\n\t \n\t HttpClient httpclient = new DefaultHttpClient();\n\t HttpPost httppost = new HttpPost(Config.FILE_UPLOAD_URL);\n\t \n\t try {\n\t AndroidMultiPartEntity entity = new AndroidMultiPartEntity(\n\t new ProgressListener() {\n\t \n\t @Override\n\t public void transferred(long num) {\n\t publishProgress((int) ((num / (float) totalSize) * 100));\n\t }\n\t });\n\t \n\t File sourceFile = new File(filePath);\n\t \n\t // Adding file data to http body\n\t entity.addPart(\"image\", new FileBody(sourceFile));\n\t \n\t // Extra parameters if you want to pass to server\n\t entity.addPart(\"website\",\n\t new StringBody(\"www.androidhive.info\"));\n\t entity.addPart(\"email\", new StringBody(\"abc@gmail.com\"));\n\t \n\t totalSize = entity.getContentLength();\n\t httppost.setEntity(entity);\n\t \n\t // Making server call\n\t HttpResponse response = httpclient.execute(httppost);\n\t HttpEntity r_entity = response.getEntity();\n\t \n\t int statusCode = response.getStatusLine().getStatusCode();\n\t if (statusCode == 200) {\n\t // Server response\n\t responseString = EntityUtils.toString(r_entity);\n\t } else {\n\t responseString = \"Error occurred! Http Status Code: \"\n\t + statusCode;\n\t }\n\t \n\t } catch (ClientProtocolException e) {\n\t responseString = e.toString();\n\t } catch (IOException e) {\n\t responseString = e.toString();\n\t }\n\t \n\t return responseString;\n\t \n\t }\n\t \n\t @Override\n\t protected void onPostExecute(String result) {\n\t Log.e(TAG, \"Response from server: \" + result);\n\t \n\t // showing the server response in an alert dialog\n\t showAlert(result);\n\t \n\t super.onPostExecute(result);\n\t }\n\t \n\t }\n\t \n\t /**\n\t * Method to show alert dialog\n\t * */\n\t private void showAlert(String message) {\n\t AlertDialog.Builder builder = new AlertDialog.Builder(this);\n\t builder.setMessage(message).setTitle(\"Response from Servers\")\n\t .setCancelable(false)\n\t .setPositiveButton(\"OK\", new DialogInterface.OnClickListener() {\n\t public void onClick(DialogInterface dialog, int id) {\n\t // do nothing\n\t }\n\t });\n\t AlertDialog alert = builder.create();\n\t alert.show();\n\t }\n\t \n\t} \n```\n\n到这里，我们已经把 Android 项目构建好了，现在让我们来快速地创建一个 PHP工程以用于接收我们 App 发送过来的文件，就能看到这个项目的实际想过啦。但在那之前，我们可能需要为 WAMP Server做一点点简单的配置。\n\n## 2.安装与配置 WAMP Server ##\n\n1、下载并安装 WAMP，在 Windows 系统中，WAMP 将会被安装在 C:\\wamp location。\n\n2、打开 php,ini 文件，并修改下列值。在 WAMP Server 中，上传文件的最大值默认为 2MB，通过修改下列值，我们能够让上传文件的最大值达到 50MB。\n\n![](http://cdn3.androidhive.info/wp-content/uploads/2014/12/wamp-server-editing-php.ini-file1.png?6141f6)\n\n> upload_max_filesize = 50M\n> post_max_size = 50M\n> max_input_time = 300\n> max_execution_time = 300\n\n3、配置完成后重启 WAMP Server 即可。\n\n## 3.创建一个 PHP 项目 ##\n \n1、到 C:\\wamp\\www 目录中创建一个名为 AndroidFileUpload 的文件夹，这将会是我们 PHP 项目的根目录\n\n2、进入这个文件夹中创建一个叫作 uploads 的文件夹，用以储存所有上传到服务器的文件\n\n3、创建一个叫做 fileUpload.php 的文件，并把下面的内容复制进去。这些 PHP 代码的作用是：接收我们 Android App 上传的文件，并把它们储存在 uploads 文件夹中。一旦上传完成，服务器就会返回一个 JSON。\n\n**fileUpload.php**\n\n```php\n\tgetMessage();\n\t }\n\t} else {\n\t // File parameter is missing\n\t $response['error'] = true;\n\t $response['message'] = 'Not received any file!F';\n\t}\n\t \n\t// Echo final json response to client\n\techo json_encode($response);\n\t?>\n```\n\nBelow is the sample JSON response if the file is uploaded successfully. You can use error value to verify the upload on android side.\n\n如果文件成功被上传，就会得到类似下面这个简单的 JSON 返回值范例。你可以使用错误代码来确认 Android 端的上传结果。\n\n```php\n\t{\n\t \"file_name\": \"DSC_0021.JPG\",\n\t \"email\": \"admin@androidhive.info\",\n\t \"website\": \"www.androidhive.info\",\n\t \"message\": \"File uploaded successfully!\",\n\t \"error\": false,\n\t \"file_path\": \"http://192.168.0.104/AndroidFileUpload/uploads/DSC_0021.JPG\"\n\t}\n```\n\n## 4.测试上传文件功能（本地） ##\n\n你可以通过完成下面的步骤在本地测试 App 的功能\n\n1. 运行必要的设备（这里指的是运行 WAMP server 和 Android 手机），并将它们连在同一个 WIFI 网络中\n\n2. 开启 WAMP server\n\n3. 在电脑上运行 PHP 工程，并获取本机的 IP 地址。你可以通过在控制台中输入 ipconfig 命令获得你的 IP 地址。（在 Mac Os 系统中，你需要使用 ifconfig 获得 IP 地址）\n\n4. 把 Config 类中的 IP 地址换成你的 IP 地址（创建 Android 项目的第四步）\n\n5. 把我们的 Android App 安装到手机上，并运行它\n\n![](http://cdn2.androidhive.info/wp-content/uploads/2014/12/android-uploading-camera-picture-to-server.jpg?6141f6)\n\n![](http://cdn2.androidhive.info/wp-content/uploads/2014/12/android-uploading-camera-picture-to-server1.jpg?6141f6)\n\n![](http://cdn2.androidhive.info/wp-content/uploads/2014/12/android-uploading-camera-picture-to-server2.jpg?6141f6)\n\n## 引用 ##\n\n1. [Stackoverflow](http://stackoverflow.com/questions/22874735/upload-large-file-with-progress-bar-and-without-outofmemory-error-in-android) 上有一个相关的使用进度条上传文件的问题\n\n2. 我在 App 中使用的[图标](https://www.iconfinder.com/icons/66782/file_upload_icon#size=128)" }, { "path": "others/如何在本地搭建一个Android应用crashing跟踪系统－ACRA/readme.md", "content": "如何在本地搭建一个Android应用crashing跟踪系统－ACRA\n---\n>\n* 原文链接 : [How to setup ACRA, an Android Application Crash Tracking system, on your own host](http://inthecheesefactory.com/blog/how-to-install-and-use-acra-android/en)\n* 作者 : [nuunei](http://inthecheesefactory.com/blog)\n* 译者 : [sundroid](https://github.com/sundroid) \n* 校对者: [sundroid](https://github.com/sundroid) \n* 状态 : 校对完成\n\n\n在开发一款移动app时的一个事实是会有很多约束，比如硬件（CPU、RAM、Battery 等等）。如果你的代码设计不是很好，你会遇到一个非常让人头疼的问题：“Crash”,研究表明：\n\n>\n*应用崩溃时绝大多数应用使用者抱怨的问题。\n\n此外\n\n>\n* 如果应用程序联系崩溃三次，大约一半的用户将会卸载这款应用。\n\n\n崩溃跟踪系统，帮助开发者能够直接的葱用户的设备收集每一个崩溃原因，是不是发现这个功能很特殊。目前最受欢迎的崩溃跟踪系统是 [Crashlytics](http://fabric.io/)和[Parse Crash Reporting](http://blog.parse.com/2014/12/09/introducing-parse-crash-reporting-2/)，这两个系统都是完全免费的。开发者可以免费的集成他们在自己的应用中。不论什么时候app崩溃了，整个bug信息将会发送到后台，允许开发人员用最简单的方式去解决这些bug。通过这个方法，你可以在短时间内迭代一款不会影响正常使用的应用。\n\n\n然而，提供崩溃信息收集的厂商收集这些崩溃信息同时也收集了用户信息，这可能让引起大公司担心用户隐私。\n\n\n所以，这儿有没有崩溃信息跟踪系统可以让我们搭建在自己的服务器上？那么就不存在泄漏用户隐私的担忧了。当然有了，并且这个系统提供了非常简单的搭建方法。在这里我们来介绍下[Application Crash Reporting on Android (ACRA)](https://www.acra.gov.sg/home/),一个库允许Android应用自动地发送崩溃信息到自己的服务器。\n\n下面将会介绍如何去搭建。\n\n## 搭建一个服务器 ##\n\n服务器端是一个先决条件，让我们先从搭建服务器端开始。\n\n由于ACRA设计的很好并且很受欢迎。它允许开发者开发自己的服务器系统，并且现在我们可以看到很多这样的系统。即便如此我觉得最好的是Acralyzer，这个也是由ACRA团队研发。Acralyzer工作在Apache CouchDB，所以\n这里没有必要安装除了CouchDB以外的软件。\n\nAcralyzer是一个功能相当齐全的后端崩溃跟踪系统。来自不同原因的相同堆栈轨迹将会被分组成一个单一的问题。如果你解决了所有问题，你可以非常便捷的关闭Acralyzer服务，并且这种关闭服务的操作时实时的，我发现系统唯一的缺点是它的ui让人感到不舒服，但是谁会在乎这个？它是为开发者开发的。\n\n安装起来也很简单，下面将介绍如何在Ubuntu安装Acralyzer。\n\n打开命令窗口，开始安装couchdb\n>\n*apt-get install couchdb\n\nTest the installation with this command:\n\n测试是否安装成功。\n>\n*curl http://127.0.0.1:5984\n\n如果正确安装，会显示如下：\n>\n*{\"couchdb\":\"Welcome\",\"version\":\"1.2.0\"}\n\n编辑etc/couchdb/local.ini允许我们通过外部IP(默认的访问会通过127.0.0.1)去访问CouchDB。仅仅改变两行实现这个功能：\n>\n*;port = 5984\n*;bind_address = 127.0.0.1\n\n\n改变为\n>\n*port = 5984\n*bind_address = 0.0.0.0\n\n在同一个文件夹下，你需要添加username/password作为管理员账户。找到这一行（应该会在文件末尾）\n>\n*[admins]\n\n下一行添加username/password 形式为username = password，比如：\n>\n*[nuuneoi = 12345]\n\n\n请不要对在这里书写明文密码感到担心，一旦CouchDB重启后，你的密码将会自动地散列，并且将会是不可读的，\n\n保存你刚刚编辑的文件同时通过命令行重启hashed：\n>\n*curl -X POST http://localhost:5984/_restart -H\"Content-Type: application/json\"\n\n从现在起，你将可以通过浏览器访问CouchDB。这个web服务我们称之为Futon，一个CouchDB UI管理后台。在你的浏览器中打开这个地址。\n\n>\n*http://:5984/_utils\n\n让我们开始吧，Futon。\n![](http://inthecheesefactory.com/uploads/source/acra/futon.png)\n\n\n首先，通过你之前设置的管理员账号登陆这个系统。\n\n现在我们开始安装一个acro-storage (Acralyzer's Storage Endpoing).在左边的菜单，点击Replicator，然后填写远程存储改为本地存储的表单。\n>\n*from Remote Database: http://get.acralyzer.com/distrib-acra-storage to Local Database: acra-myapp\n\n点击Replicate然后等待，知道这个过程结束。\n\n下一步安装Acralyzer通过同样的方法，但是参数是不同的。\n>\n*from Remote Database: http://get.acralyzer.com/distrib-acralyzer to Local Database: acralyzer\n\n点击Replicate安装。\n\n如果你操作正确，系统将会有两个数据库，acra-myapp 和 acralyzer。\n\n![](http://inthecheesefactory.com/uploads/source/acra/acra3.png)\n\n我门就快大功告成了，下一步，我们需要为这个客户端创建一个用户，打开浏览器，然后打开这个网址：\n>\n*http://:5984/acralyzer/_design/acralyzer/index.html\n![](http://inthecheesefactory.com/uploads/source/acra/admincreateuser.png)\n\n填写你想要的Username/Password，然后点击Create User，这些信息将会出现。\n![](http://inthecheesefactory.com/uploads/source/acra/users2.png)\n\n复制这些信息，然后粘贴到你的文本编辑器，我们可能会用这个在客户端设置。\n\n最后一件事是限制访问权限来保护在acra-myapp里面的数据，进入acra-myapp然后点击Securities，填写用户角色分配；\n>\n*[\"reader\"]\n![](http://inthecheesefactory.com/uploads/source/acra/reader.png)\n\n完工！\n在这些结束后，你可以通过同一个网址访问这个控制台，去Admin选项卡，并选择Users。\n\n>\n*[http://:5984/acralyzer/_design/acralyzer/index.html\n\n请注意acro-myapp只能够为一款应用服务。以防你想为另外一款应用创建一个后台，请通过同样的过程复制另外一个acro-storage，但是改变本地数据库名为acra-。请注意，有必要去通过acra- 去开启服务，或者它不能够在仪表盘中罗列为选择项供我们去选择。\n\n如果在系统中有不止一款应用，在Acralyzer的仪表盘中将会有一个下拉列表，让我们去选择看哪一个的问题。你可以试一试。\n\n在客户端设置ACRA。\n\n在客户端中设置ACRA很简单，首先，在你的 build.gradle里添加ACRA的依赖配置信息。\n>\n*compile 'ch.acra:acra:4.6.1'\n\n同步你的gradle文件，然后创建一个自定义Application类，但是不要忘记在AndroidManifest.xml中定义这个Application类。（我假设每一个Android开发者不会忘记这么做）。\n\n在你创建的自定义的Application类中添加 @ReportCrashes注解。\n\n```java\nimport android.app.Application;\nimport org.acra.ACRA;\nimport org.acra.annotation.ReportsCrashes;\nimport org.acra.sender.HttpSender;\n \n/**\n * Created by nuuneoi on 2/19/2015.\n */\n \n@ReportsCrashes(\n)\npublic class MainApplication extends Application {\n \n @Override\n public void onCreate() {\n super.onCreate();\n \n ACRA.init(this);\n }\n \n}\n```\n\n现在我们复制服务器端生成的信息，并且像下面那样粘贴到@ReportsCrashes中。\n\n```java\n\t@ReportsCrashes(\n httpMethod = HttpSender.Method.PUT,\n reportType = HttpSender.Type.JSON,\n formUri = \"http://YOUR_SERVER_IP:5984/acra-myapp/_design/acra-storage/_update/report\",\n formUriBasicAuthLogin = \"tester\",\n formUriBasicAuthPassword = \"12345\"\n)\n```\n\n最后一步，不要忘记添加在AndroidManifest.xml网络访问权限，否则ACRA可能无法发送这些日志信息到你的服务器上。\n>\n*\n\n\n恭喜，现在所有的配置都已经完成，ACRA可以正常的工作，帮助你收集崩溃日志信息，从而你可以快速解决应用出现的问题。\n\n##测试##\n\n现在我们通过在Activity中强制一些崩溃来做一些测试，例子如下： \n\n```java\nextView tvHello;\n \n@Override\nprotected void onCreate(Bundle savedInstanceState) {\n super.onCreate(savedInstanceState);\n setContentView(R.layout.activity_main);\n \n tvHello.setText(\"Test Crash\");\n}\n```\n\n运行你的应用，然后改变崩溃的原因，再运行一次。查看你的仪表盘，你将会看到这些发送到后台的bug。\n\n![](http://inthecheesefactory.com/uploads/source/acra/acra.png)\n\n每一个bug来自不同用户不同时间，并且这些报告被分组了。\n![](http://inthecheesefactory.com/uploads/source/acra/reportslist.png)\n\n仔细看看这些报告信息，你将会发现他们都是完整的崩溃信息。\n![](http://inthecheesefactory.com/uploads/source/acra/stacktrace.png)\n\n并且非常多的信息，足足有7页。\n\n如果你修复这些bug后，你可以关闭这个问题，通过简单的点击在页面中高亮显示的\"bug\"图标，\n![](http://inthecheesefactory.com/uploads/source/acra/closeissue.png)\n\n希望这篇文章对你们有用，特别是对于一些需要应用崩溃信息收集但是却担心隐私信息的大公司可以来使用这个系统。\n\n事实上ACRA还有许多其他特性，比如：当一个月崩溃时显示Toast 或者 popup 来报告这些信息。你可以在ACRA网站上发现这些选项。\n\nAcralytics也一样，这里有许多其他特性可以使用，比如，你可以设置一个服务器来发送邮件给我们。\n\n下一篇博客再见。\n\n\n\t\n\n\n\n\n\n\n" }, { "path": "others/深入浅出Android 新特性-Transition-Part-1/readme.md", "content": "开始使用 Transitions（过渡动画） (part 1)\n---\n\n>\n* 原文链接 : [Getting Started with Activity & Fragment Transitions (part 1)][source-url]\n* 作者 : [Alex Lockwood](https://plus.google.com/+AlexLockwood)\n* 译者 : [tiiime](https://github.com/tiiime)\n* 校对者: [chaossss](https://github.com/chaossss) \n* 状态 : 校对完成\n\n\n\n\n##首先\n这篇文章主要介绍 Android 5.0 新加入的 Transition (过渡动画) API，这是这个系列的第一篇文章。主要介绍下面几个话题:\n\n\n- Part 1: [在 Activity 和 Fragment 中使用 Transition ][part-1]\n- Part 2: [深入理解 Transition][part-2]\n- Part 3a: [深入理解共享元素的 Transition][part3a]\n- Part 3b: [延迟共享元素的 Transition][part-3b]\n- Part 3c: 共享元素回调实践 (coming soon!)\n- Part 4: Activity & Fragment 过渡动画示例(coming soon!)\n\n今天这篇文章是 Transition 的概述，同时也象征着这个专栏的开始，希望大家喜欢啦。\n\n#先说下什么是 Transition(过渡动画).\nLollipop 中 Activity 和 Fragment 的过渡动画是基于 Android 一个叫作 Transition 的新特性实现的。\n初次引入这个特性是在 KitKat 中，Transition 框架提供了一个方便的 API 来构建应用中不同 UI 状态切换时的动画。\n这个框架始终围绕两个关键概念:场景和过渡。\n**场景** 描述应用中 UI 的状态，[**过渡**][transition] 确定两个场景转换之间的过渡动画。\n\n当场景转换，Transition 的主要职责是：\n\n1. 捕获每一个 View 的起始和结束状态\n2. 根据这些数据来创建从一个场景到另一个场景间的过渡动画。\n\n下面是一个简单示例，当用户点击，我们需要 Activity 的 View 视图产生消失和出现的效果。使用 Transition ，实现这个需求只要几行代码，代码如下：(1)\n\n```java\npublic class ExampleActivity extends Activity implements View.OnClickListener {\n private ViewGroup mRootView;\n private View mRedBox, mGreenBox, mBlueBox, mBlackBox;\n\n @Override\n protected void onCreate(Bundle savedInstanceState) {\n super.onCreate(savedInstanceState);\n setContentView(R.layout.activity_main);\n\n mRootView = (ViewGroup) findViewById(R.id.layout_root_view);\n mRootView.setOnClickListener(this);\n\n mRedBox = findViewById(R.id.red_box);\n mGreenBox = findViewById(R.id.green_box);\n mBlueBox = findViewById(R.id.blue_box);\n mBlackBox = findViewById(R.id.black_box);\n }\n\n @Override\n public void onClick(View v) {\n TransitionManager.beginDelayedTransition(mRootView, new Fade());\n toggleVisibility(mRedBox, mGreenBox, mBlueBox, mBlackBox);\n }\n\n private static void toggleVisibility(View... views) {\n for (View view : views) {\n boolean isVisible = view.getVisibility() == View.VISIBLE;\n view.setVisibility(isVisible ? View.INVISIBLE : View.VISIBLE);\n }\n }\n}\n```\n\n为了更好地理解底层中发生了什么，我们一步一步地分析下这段代码，首先假设屏幕上的所有的 View 都是**可见**的:\n\n1. 首先，点击按钮后调用了 [beginDelayedTransition()][beginDelayedTransition]，\n将根场景和[Fade][fade] Transition对象（淡入/淡出过渡效果）作为参数传递出去。框架立即对场景中所有 View 调用 Transitions 的 [captureStartValues()][captureStartValues] 方法，同时， Transitions 将记录每个 View 的可见性。\n\n2. 调用结束后，开发者将场景中所有 View 设置为**不可见**的。\n\n3. 在下一个画面，框架对场景中所有 View(近期更新的) 调用 Transitions 的[captureEndValues()][captureEndValues]\n方法， Transitions 记录可见性。\n\n4. 框架调用 Transitions 的 [createAnimator()][createAnimator] 方法。Transition 分析每一个 View 的起始/结束状态，注意到 View 的可见性发生了变化。之后 **Fade** 对象利用这些信息创建了一个**AnimatorSet** 对象，并将其返回到框架中，进而将每个 View 的 **alpha** 值渐变到 **0f**。\n\n5. 框架运行返回的**动画**,让所有 View 从屏幕中淡出。\n\n这个例子强调了 Transition 框架的两个优点：第一，**Transition** 将开发人员所需要的**动画**概念抽象，减少了 Activity 和 Fragment 内的代码复用，使得我们只要设置好 View 的 起始 和 结束 时的状态，就能通过 Transition 自动创建动画。第二，只要更换 **Transition** 对象就可以修改两个场景间的动画。\n\n[ 示例 **Video 1.1**](http://www.androiddesignpatterns.com/assets/videos/posts/2014/12/04/trivial-opt.mp4),只要少量代码就可以创建复杂的动画效果。\n后续文章会介绍如何做到。\n\n# Lollipop 中的 Activity & Fragment Transitions\n在 Android 5.0 中， 切换 **Activitys** 或者 **Fragments** 时可以使用 **Transitions** 来构建精致的过场动画。虽然在之前的版本中已经引入 Activity 和 Fragment 的切换动画(通过 [Activity#overridePendingTransition()][overridePendingTransition] 和 [FragmentTransaction#setCustomAnimation()][setCustomAnimations] 方法实现)，但是动画的对象只能是**Activity/Fragment**整体。而新的 API 将这个特性延伸，使我们可以为每个 View 单独设置动画，甚至可以在两个独立的 Activity/Fragment 容器内共享某些 View的动画。\n\n接下来介绍些术语。注意，虽然下面是以 Activity 为例，但是在 Fragment 中这些术语也同样有效:\n\n>假设 **A** 和 **B** 是两个 Activity，通过 **A** 来启动 **B**。\n>**A** 叫做 \"调用Activity\"(调用 `startActivity()` 的那个)\n>**B** 就是 \"被调用Activity\"\n\nActivity transition API 是围绕退出，进入，返回还有重入过渡动画效果构建的。根据之前的定义我们可以这样描述它们:\n\n>Activity **A** 的 退出 Transition 确定 **A** 启动 **B** 时 **A** 中 View 的动画\n\n>Activity **B** 的 进入 Transition 确定 **A** 启动 **B** 时 **B** 中 View 的动画\n\n>Activity **B** 的 返回 Transition 确定 **B** 返回 **A** 时 **B** 中 View 的动画\n\n>Activity **A** 的 重入 Transition 确定 **B** 返回 **A** 时 **A** 中 View 的动画\n\n最后，Transition 框架提供了 **Content(内容)**和**共享元素(Shared Element)** 两种类型的Activity过渡动画，每个都可以让我们以独特的方式自定义 Activity 切换间的动画\n\n>**Content(内容) Transition** 确定了非共享元素如何 进入/退出 Activity 场景\n\n>**共享元素(Shared Element) Transition** 确定了两个Activity 共享 View (也被叫做主角视图)的动画效果。\n\n[Video 1.2](http://www.androiddesignpatterns.com/assets/videos/posts/2014/12/04/news-opt.mp4)这段视频很好的解释了 Content Transition 和 共享元素 Transition，我猜想它使用了下面的过渡动画。\n\n- **A**(调用Activity) 的**退出**和**重新进入** Content Transition 都是 **null**。因为用户退出和重新进入时 Activity A中的非共享视图没有动画效果。(2)\n\n\n- **B**(被调用Activity) 的**进入** Content Transition 使用了一个自定义的 Slide Transition 将list item从底部移至屏幕中。\n\n- Activity **B** 的**返回** Content Transition是一个 **TransitionSet**，同时进行两个子 Transition:一个Slide (Gravity.TOP) Transition\n针对Activity上半部分的View，一个Slide (Gravity.BOTTOM) Transition 针对Activity 下半部分View。当用户点击按钮返回Activity A，Activity呈现一种断成两半的感觉。\n\n- 共享元素的进入和退出 Transition 都是 **ChangeImageTransform**，使ImageView过渡动画可以在两个Activity间无缝衔接。\n\n你可能也注意到了在共享元素 Transition 下还有一个圆形的过渡动画(circular reveal)，我们会在将来的章节中介绍它是如何实现的。现在，我们来继续了解 Activity 和 Fragment transition APIs\n\n#介绍Activity Transition API\n\n使用 Lollipop 的 APIs 创建一个 Activity 过渡动画 非常简单，下面的总结是实现一个过渡动画的必要步骤。在接下来的文章中我们还会介绍很多提升水平的用例，不过现在先让我们来入个门:\n\n- 在你的A(调用Activity)和B(被调用Activity)的 `.java` 文件或者\n`xml`(3)布局中请求启用\n[`Window.FEATURE_ACTIVITY_TRANSITIONS`][FEATURE_ACTIVITY_TRANSITIONS] 窗口特性，\n使用Material主题的应用默认已开启。\n\n- 为A和B单独设置 [**exit**][exit] 和 [**enter**][enter] Content Transition 。\nMaterial主题的 [**exit**][exit] 和 [**enter**][enter] Content Transition 默认分别是\n`null`和`Fade`。如果没有明确定义 [**reenter**][reenter] 或 [**return**][return]\nContent Transition 将会使用 Activity 的 [**exit**][exit] 和 [**enter**][enter]\n Transition 来代替。\n\n- 为 A 和 B 设置 [**exit**][exit] 和 [**enter**][enter] 共享元素 Transition。\nMaterial主题中共享元素默认设置 [`@android:transition/move`][move] 作为\n[**exit**][exit] 和 [**enter**][enter] 过渡动画。如果没有明确定义\n[**reenter**][reenter] 和 [**return**][return] 的过渡动画将会使用 Activity 的\n[**exit**][exit] 和 [**enter**][enter] 过渡动画作为替代。\n- 启动一个包含 Content Transition 和 共享元素 Transition 的 Activity 时要调用\n`startActivity(Context, Bundle) `方法，其中第二参数 Bundle 通过下面这段代码获得：\n \n\t```java\n\tActivityOptions.makeSceneTransitionAnimation(activity, pairs).toBundle();\n\t``` \n\n**pairs** 是一个 **Pair< View, String >** 数组，记录Activity间(4) 共享元素的View 和 相对应的特征字符串。别忘了在[程序][setTransitionName]中或 [xml][xml] 文件里给共享元素设置不重复的名称，否则过渡动画不会正常运行。\n\n- 通过启动程序返回一个 Transition，调用 **finishAfterTransition()** 代替 **finish()**。\n\n- Material主题应用默认会在他们的**退出/重入** Transition 完成前一点点启动**进入/返回** Content Transition，这样会在两个动画间产生一些重叠，让过渡动画更好看。如果你想关闭这个特性可以调用 [ setWindowAllowEnterTransitionOverlap()][setAllowEnterTransitionOverlap] 和 [setWindowAllowReturnTransitionOverlap()][setAllowReturnTransitionOverlap] 方法或者在xml文件里给定适当的属性\n\n##Fragment 的 Transition API\n\n如果你使用 Fragment 的 transition API，大部分 API 相似，但是会有一些小的不同:\n\n- Content 的[退出][exit]，[进入][enter]，[重入][reenter]和[返回][return] 过渡动画应该在 Fragment 的`.java`文件中调用对应的方法或者在 xml 属性声明里设置。\n\n- 共享元素 的[进入][enter]和 [返回][return] 过渡动画应该在 Fragment 的`.java`文件中调用对应的方法或者在 xml 属性声明里设置。\n\n- 鉴于Activity的 Transition 是通过调用 **startActivity()** 和 **finishAfterTransition()** 直接启动的,Fragment 的过渡是在 Fragment\n被add, remove, attach, detach, show,或 hidden 后由 FragmentTransaction 自动启动。\n\n- 共享元素应该在transaction(事务)提交前调用[`addSharedElement(View, String)`][addSharedElement]声明为 **FragmentTransaction** 的一部分。\n\n##结语\n\n这篇文章里我们只是简单的介绍了 Activitiy 和 Fragment transition API，但是在接下来的文章你会发现扎实的基础给你带来的好处，尤其是在讲到**自定义过渡动画**时。后面我们会非常深入的讲解 Content Transition 和 共享元素 Transition，让你更加了解 Activity 和 Fragment 背后的工作。\n\n希望你喜欢我的文章，感谢观看～\n\n1. 如果你想尝试这个例子，这里有[xml代码][xmlcode] ↩\n\n2. 第一眼看上去可能感觉是Activity A fade in/out 屏幕, 事实上是Activity B 在 Activity A 的上面渐变. A 中的 View 事实上是没有动画的. 你可以在被调用 Activity 的 Window 中使用 [setTransitionBackgroundFadeDuration()][setTransitionBackgroundFadeDuration] 方法调节背景渐变持续时间。 ↩\n\n3. 了解更多关于 **FEATURE_ACTIVITY_TRANSITIONS** 和 **FEATURE_CONTENT_TRANSITIONS** 窗口特性的不同可以看[这里StackOverflow Post][window-feature]↩\n\n4. 启动一个包含Content Transition 而不是共享元素 Transition 的Activity,可以这样创建**Bundle**\n\n\t```java\n\tActivityOptions.makeSceneTransitionAnimation(activity).toBundle()\n\t```\n如果想完全禁用Content Transition 和 共享元素 Transition 可以将 Bundle 设为 **null**. ↩\n\n\n[source-url]:http://www.androiddesignpatterns.com/2014/12/activity-fragment-transitions-in-android-lollipop-part1.html\n\n[part-1]:http://www.androiddesignpatterns.com/2014/12/activity-fragment-transitions-in-android-lollipop-part1.html\n[part-2]:http://www.androiddesignpatterns.com/2014/12/activity-fragment-content-transitions-in-depth-part2.html\n[part3a]:http://www.androiddesignpatterns.com/2015/01/activity-fragment-shared-element-transitions-in-depth-part3a.html\n[part-3b]:http://www.androiddesignpatterns.com/2015/03/activity-postponed-shared-element-transitions-part3b.html\n\n[beginDelayedTransition]:https://developer.android.com/reference/android/transition/TransitionManager.html#beginDelayedTransition(android.view.ViewGroup,%20android.transition.Transition)\n[captureStartValues]:https://developer.android.com/reference/android/transition/Transition.html#captureStartValues(android.transition.TransitionValues)\n[captureEndValues]:https://developer.android.com/reference/android/transition/Transition.html#captureEndValues(android.transition.TransitionValues)\n\n[createAnimator]:https://developer.android.com/reference/android/transition/Transition.html#createAnimator(android.view.ViewGroup,%20android.transition.TransitionValues,%20android.transition.TransitionValues)\n[video1.1]:http://www.androiddesignpatterns.com/assets/videos/posts/2014/12/04/trivial-opt.mp4\n[video1.2]:http://www.androiddesignpatterns.com/assets/videos/posts/2014/12/04/news-opt.mp4\n[FEATURE_ACTIVITY_TRANSITIONS]:http://developer.android.com/reference/android/view/Window.html#FEATURE_ACTIVITY_TRANSITIONS\n[move]:https://github.com/android/platform_frameworks_base/blob/lollipop-release/core/res/res/transition/move.xml\n[fade]:https://developer.android.com/reference/android/transition/Fade.html\n[transition]:https://developer.android.com/reference/android/transition/Transition.html\n\n[overridePendingTransition]:http://developer.android.com/reference/android/app/Activity.html#overridePendingTransition(int,%20int)\n[setCustomAnimations]:http://developer.android.com/reference/android/app/FragmentTransaction.html#setCustomAnimations(int,%20int,%20int,%20int)\n\n\n[exit]:https://developer.android.com/reference/android/view/Window.html#setExitTransition(android.transition.Transition)\n[enter]:https://developer.android.com/reference/android/view/Window.html#setEnterTransition(android.transition.Transition)\n[reenter]:https://developer.android.com/reference/android/view/Window.html#setSharedElementReenterTransition(android.transition.Transition)\n[return]:https://developer.android.com/reference/android/view/Window.html#setReturnTransition(android.transition.Transition)\n[addSharedElement]:https://developer.android.com/reference/android/app/FragmentTransaction.html#addSharedElement(android.view.View,%20java.lang.String)\n[setTransitionName]:https://developer.android.com/reference/android/view/View.html#setTransitionName(java.lang.String)\n[xml]:https://developer.android.com/reference/android/view/View.html#attr_android:transitionName\n[setAllowEnterTransitionOverlap]:http://developer.android.com/reference/android/view/Window.html#setAllowEnterTransitionOverlap(boolean)\n[setAllowReturnTransitionOverlap]:http://developer.android.com/reference/android/view/Window.html#setAllowReturnTransitionOverlap(boolean)\n[xmlcode]:https://gist.github.com/alexjlockwood/a96781b876138c37e88e\n[window-feature]:http://stackoverflow.com/questions/28975840/feature-activity-transitions-vs-feature-content-transitions\n[setTransitionBackgroundFadeDuration]:http://developer.android.com/reference/android/view/Window.html#setTransitionBackgroundFadeDuration(long)\n" }, { "path": "others/深入浅出Android 新特性-Transition-Part-2/readme.md", "content": "`深入理解Content Transition (part 2)`\n---\n\n>\n* 原文链接 : [Content Transitions In-Depth (part 2)][source-url]\n* 译者 : [tiiime](https://github.com/tiiime)\n* 校对者: [chaossss](https://github.com/chaossss)\n* 状态 : 完成\n\n\n\n#深入理解Content Transition\n\n这篇文章会深度分析 Content Transitions 和它在 Activity & Fragment Transitions API 中的作用。这篇文章是下面这个系列中的第二篇：\n\n- Part 1: [在 Activity 和 Fragment 中使用 Transition ][part-1]\n- Part 2: [深入理解 Content Transition][part-2]\n- Part 3a: [深入理解共享元素 Transition][part3a]\n- Part 3b: [延迟共享元素的 Transition][part-3b]\n- Part 3c: 共享元素回调实践 (coming soon!)\n- Part 4: Activity & Fragment 过渡动画示例(coming soon!)\n\n我们先来总结下在 [part 1][part-1] 中提到的关于 Content Transitions 的知识点，然后\n说一说在 Android Lollipop 中是怎样使用它来构建合适的过渡动画。\n\n---\n\n##Content Transition 是什么？\n\nContent transition 决定了非共享元素 View (也称为 transitioning view) 在\nActivity & Fragment 过渡期间是如何进入或退出场景的。出于 Google 新的设计语言\n[Material Design][md-design] , content transitions 允许我们协调 Activity/Fragment 中每一个\n view 的进入和退出 transition，轻松搞定流畅的屏幕切换动作。\n开始使用 Android Lollipop，调用下面这些[ Window ][window] 和\n[ Fragment ][fragment] 方法可以通过程序设置 content transitions :\n\n\n- **setExitTransition()** - 当 A **启动** B 时， **A** 中 views **离开**场景的退出过渡动画\n\n- **setEnterTransition()** - 当 A **启动** B 时， **B** 中 views **进入**场景的进入过渡动画\n\n- **setReturnTransition()** - 当 B **返回** A 时， **B** 中 views **离开**场景的返回过渡动画\n\n- **setReenterTransition()** - 当 B **返回** A 时， **A** 中 views **进入**场景的重入过渡动画\n\n(注:A 和 B 是Activity 见 [part 1][part-1])。\n\n[**Video 2.1**][video2.1] - Content transitions in the Google Play Games app (as of v2.2). Click to play.\n\n---\n\n\n[**Video 2.1**][video2.1]作为示例阐明了在 Google Play Games app 中是如何使\n用 content transitions 实现流畅的 activitiy 切换动画。当第二个 activity 启动，\n它的**进入** content transition 轻轻地从屏幕底部边缘将头像推入场景。按下返回按钮后，\n第二个 activity 的**返回** content transition 将图层分成上下两块，分别推出屏幕。\n\n\n---\n\n目前为止我们对 content transitions 的分析仅仅停留在表面，一些重要的问题仍然没有涉及。\n例如 Content Transition 在底层是如何实现的？都有哪些类型的 **Transition** 对象可以使用?框架是如何确定哪些 view\n是 transitioning view? 在 content transitions 中一个 **ViewGroup** 和它的子视图能不能当成一个整体\n执行动画?下面我们就来一个一个解答这些问题。\n\n---\n\n##Content Transitions 底层深入\n\n上篇文章我们说过 Transition 的两个主要职责分别是获取目标视图的开始结束状态和创建这两个状态间的过渡动画。同样，框架必须先改变每个 transitioning view 的可见性并将状态信息交给 content\ntransition ，它才能创建过渡动画。更准确的说，当 Activity **A** 启动 Activity **B** 将会出现以下事件：(1)\n\n1. Activity **A** 调用 **startActivity()**\n\n\t- 框架首先会遍历 **A** 的 view 层次结构，确定当 **A** 的退出 transition 运行后有哪些\n\ttransitioning views 会退出场景。\n\t- **A** 的退出 transition 捕获 A 中 transitioning views 的起始状态。\n\t- 框架将 **A** 中所有 transitioning views 设置为**不可见**。\n\t- 在下一个画面中，**A** 的退出 transition 捕获 **A** 中所有 transitioning views 的结束状态。\n\t- **A** 的退出 transition 比较每一个 transitioning view 开始和结束状态的不同，\n\t并基于这些信息创建一个 **Animator**，最后运行 **Animator** 将所有 transitioning views\n\t移出场景。\n\n2. Activity **B** 被启动\n\t- 框架遍历 **B** 的 view 层次结构， 确定当 B 的进入 transition 运行后有哪些\n\t transitioning views 会进入场景。\n\t- **B** 的进入 transition 捕获 B 中 transitioning views 的起始状态。\n\t- 框架将 **B** 中所有 transitioning views 设置为**可见**\n\t- 在下一个画面中，**B** 的进入 transition 捕获 **B** 中所有 transitioning views 的结束状态。\n\t- **B** 的进入 transition 比较每一个 transitioning view 开始和结束状态的不同，\n\t并基于这些信息创建一个 **Animator**，最后运行 **Animator** 将所有 transitioning views\n\t移入场景。\n\n---\n\n框架通过在**可见**和**不可见**之间切换每个 transitioning view 的可见性来保证\ncontent transition 能够获得用来构建目标动画所需要的状态信息。\n显然所有的 content **Transition** 对象至少要能够获取和记录每个 transitioning view\n起始和结束状态的可见性。还好 [Visibility][Visibility] 这个抽象类已经提供了这个功能 :\n需要创建并返回 (让 view 进入/退出场景的) **Animator** 的 **Visibility**\n子类只需要实现 [**onAppear()**][onAppear] 和 [**onDisappear()**][onDisappear] 这两个工厂方法。\n从 API 21 开始，有三个已经写好的 **Visibility** 实现( [**Fade**][Fade], [**Slide**][slide] 和 [**Explode**][explode])，可以使用它们来构建 Activity 和 Fragment 的 content transitions。\n有必要的话也可以自己实现 Visibility 类达到想实现的效果。后边的文章会有具体介绍。\n\n---\n\n##Transitioning Views 和 Transition Groups\n直到现在，我们已经假设 content transitions 操作一组叫做 transitioning views 的非共享 view 。\n在这节中，我们将探讨 Transition 框架如何确定哪些 View 是非共享 View，以及如何使用 transition group 深度定制框架\n\nTransition 开始前，框架会在 Activity 窗口(或 Fragment) 的视图层上执行一个递归的搜索，用来\n构建 transitioning views 的集合。这个搜索通过对图层的根视图递归调用重写的**ViewGroup#captureTransitioningViews** 方法启动，部分[源码][source-code]如下:\n\n```java\n/** @hide */\n@Override\npublic void captureTransitioningViews(List transitioningViews) {\n if (getVisibility() != View.VISIBLE) {\n return;\n }\n if (isTransitionGroup()) {\n transitioningViews.add(this);\n } else {\n int count = getChildCount();\n for (int i = 0; i < count; i++) {\n View child = getChildAt(i);\n child.captureTransitioningViews(transitioningViews);\n }\n }\n}\n```\n\n---\n\n\n[**Video 2.2**][video2.2] - A simple Radiohead app that illustrates a potential bug involving transition groups and WebViews. Click to play.\n\n---\n\n这个递归调用很简单: 框架遍历树的每一层，直到找到一个**可见的**[ leaf view ][leafview] (子视图)或者一个 transition group。Transition groups 本质上允许我们在 Activity/Fragment 的 transition\n期间将全部 **ViewGroups** 当作一个整体执行过渡动画。如果一个 **ViewGroup** 的\n[`isTransitionGroup ()`][isTransitionGroup] (2)方法返回值为 **true**，它和它的子视图会被当作一\n个整体来执行过渡动画。否则，这个递归搜索会继续执行下去， 这个 ViewGroup 的子视图在动画期间\n会执行自己的独立的过渡动画。搜索最终会返回一个全部由 content transition\n 执行动画的 transitioning views 集合 。(3)\n\n---\n\n上面的 [**Video 2.1**][video2.1] 展示了 transition groups 的效果。在 enter transition ，\n用户头像是作为一个单独的 View 进入屏幕，return transition 时却是和包含它的 parent\n**ViewGroup** 一起消失。在 Google Play Games 里可能用了一个 transition group\n来实现在返回前一个 activity 时，让当前场景拦腰斩断的效果。\n\n---\n\n有时 transition groups 还被用来修复 Activity/Fragment transitions 中诡异的 bugs。\n例如，Video 2.2中: **调用 Activity** 显示了一个电台司令专辑图的网格布局，\n**被调用 Activity** 展示了一个背景标题图，一个共享元素专辑封面图还有一个 **WebView**。\n这个 App 使用了一个和 Google Play Games app 类似的 return transition，将背景图和底部的\n**WebView** 分别推出屏幕。然而这里有个小故障导致 **WebView** 不能流畅的退出屏幕。\n\n好吧，错误在哪呢？原来 **WebView** 是一个 **ViewGroup**，因此在默认情况下 WebView 不会被当作 transitioning view\n的。当 return transition 被执行时，**WebView** 会被完全忽略，直到过渡动画结束才会被移除屏幕。\n找到问题就好解决了，只要在 return transition 开始前调用 `webView.setTransitionGroup(true)`\n就能修复这个bug。\n\n---\n\n##结语\n\n总之，这篇文章讲了三个重点:\n\n- Content transition 决定了 Activity/Fragment 中非共享元素视图(被称为 transitioning views)\n\t在 Activity/Fragment transition 期间如何进入或退出场景。\n- Content transitions 被触发是因为它的 transitioning views 可见性改变 ，并且应该总是继承\n\t**Visibility** 这个抽象类。\n- Transition groups 可以让我们在 content transition 期间将 **ViewGroups**\n\t当作一个整体执行过渡动画。\n\n希望这篇文章能够帮到你，欢迎留下评论～\n\n---\n\n1. Activities 和 Fragments 在 return/reenter transitions 期间出现的一系列事件相似。\n\t↩\n2. 如果 ViewGroup 有一个非空的 background drawable 或者非空的默认 transition name 那么\n\t`isTransitionGroup()` 将返回 **true** (所述方法[文档][isTransitionGroup])\n\t↩\n3. 当 transition 运行时，任何在 content **Transition** 对象中被明确地 [ added ][addTarget]或\n\t[ excluded ][excludeTarget] 的 view 也会被考虑。↩\n\n\n[source-url]:http://www.androiddesignpatterns.com/2014/12/activity-fragment-content-transitions-in-depth-part2.html\n\n[part-1]:http://www.androiddesignpatterns.com/2014/12/activity-fragment-transitions-in-android-lollipop-part1.html\n[part-2]:http://www.androiddesignpatterns.com/2014/12/activity-fragment-content-transitions-in-depth-part2.html\n[part3a]:http://www.androiddesignpatterns.com/2015/01/activity-fragment-shared-element-transitions-in-depth-part3a.html\n[part-3b]:http://www.androiddesignpatterns.com/2015/03/activity-postponed-shared-element-transitions-part3b.html\n[md-design]:http://www.google.com/design/spec/animation/meaningful-transitions.html\n[window]:http://developer.android.com/reference/android/view/Window.html\n[fragment]:http://developer.android.com/reference/android/app/Fragment.html\n[video2.1]:http://www.androiddesignpatterns.com/assets/videos/posts/2014/12/15/games-opt.mp4\n[jump1]:http://www.androiddesignpatterns.com/2014/12/activity-fragment-content-transitions-in-depth-part2.html#footnote1\n[Visibility]:https://developer.android.com/reference/android/transition/Visibility.html\n[onAppear]:https://developer.android.com/reference/android/transition/Visibility.html#onAppear(android.view.ViewGroup,%20android.transition.TransitionValues,%20int,%20android.transition.TransitionValues,%20int)\n[onDisappear]:https://developer.android.com/reference/android/transition/Visibility.html#onDisappear(android.view.ViewGroup,%20android.transition.TransitionValues,%20int,%20android.transition.TransitionValues,%20int)\n[Fade]:https://developer.android.com/reference/android/transition/Fade.html\n[slide]:https://developer.android.com/reference/android/transition/Slide.html\n[explode]:https://developer.android.com/reference/android/transition/Explode.html\n[source-code]:https://github.com/android/platform_frameworks_base/blob/lollipop-release/core/java/android/view/ViewGroup.java#L6243-L6258\n[leafview]:https://github.com/android/platform_frameworks_base/blob/lollipop-release/core/java/android/view/View.java#L19351-L19362\n[isTransitionGroup]:https://developer.android.com/reference/android/view/ViewGroup.html#isTransitionGroup()\n[video2.2]:http://www.androiddesignpatterns.com/assets/videos/posts/2014/12/15/webview-opt.mp4\n[addTarget]:https://developer.android.com/reference/android/transition/Transition.html#addTarget(android.view.View)\n[excludeTarget]:https://developer.android.com/reference/android/transition/Transition.html#excludeTarget(android.view.View,%20boolean)\n" }, { "path": "others/清晰的软件架构/readme.md", "content": "The Clean Architecture\n---\n\n\n>* 原文链接 : [The Clean Architecture](http://blog.8thlight.com/uncle-bob/2012/08/13/the-clean-architecture.html)\n> * [Robert Martin](http://blog.8thlight.com/) \n> * 译者:[zimoguo](https://github.com/zimoguo)\n> * 校对者:[Mr.Simple](https://github.com/bboyfeiyu)\n\n![](http://blog.8thlight.com/uncle-bob/images/2012-08-13-the-clean-architecture/CleanArchitecture.jpg) \n\n在过去的几年中,我们已经看到了关于系统框架的一些想法 : \n\n* [Hexagonal Architecture(六角架构)](http://alistair.cockburn.us/Hexagonal+architecture)(a.k.a. Ports and Adapters) 这种架构是由Alistair Cockburn提出的，并由Steve Freeman和Nat Pryce在他们的书[Growing Object Oriented Software](http://www.amazon.com/Growing-Object-Oriented-Software-Guided-Tests/dp/0321503627)中提出。 \n* [Onion Architecture(洋葱架构)](http://jeffreypalermo.com/blog/the-onion-architecture-part-1/) 提出者是Jeffrey Palermo。\n* [尖叫架构(Screaming Architecture)](http://blog.8thlight.com/uncle-bob/2011/09/30/Screaming-Architecture.html) 提出者是Uncle Bob（就是这篇文章的作者）。\n* [DCI架构](http://www.amazon.com/Lean-Architecture-Agile-Software-Development/dp/0470684208/) 提出者是James Coplien和Trygve Reenskaug。\n* [BCE架构](http://www.amazon.com/Object-Oriented-Software-Engineering-Approach/dp/0201544350) 提出者是Ivar Jacobson。在他的书《Object Oriented Software Engineering: A Use-Case Driven Approach》中有大量提及对这种架构的说明。\n\n虽然这些文章在细节上有所不同,总体来说是非常相似的.它们关注点分离,通过将软件划分成层达到分离效果.每层最少包含一个业务规划或者接口。 \n\n这些架构有以下特点:\n\n1. 独立框架 \n这些架构不依赖某些特定库的加载,允许你使用框架作为工具,不会限制你的系统；\n2. 可测试 \n业务规划在没有UI界面,数据库,网页服务器或者其他外部元素的情况下进行测试；\n3. 独立于UI \nUI很容易改变,而不用改变系统的其他部分,网页界面可以被控制台界面替换,同时还不用改变业务规划；\n4.独立于数据库 \n你可以切换到Oracle,SQL Server,Mongo,BigTable,CouchDB或者其他类型数据库,业务规则不与数据库绑定；\n5.独立于任何外部代理 \n事实上你的业务规划根本不需要知道外面的世界\n\n在这篇文章顶部的图表是将这些架构的理念集成在一起。\n\n\n## 依赖规则\n同心圆代表软件的不同区域,一般情况下,越接近中心位置软件的级别会变得越来越高,外圆圈是机制,内圆圈是策略。\n\n覆盖规则使得架构遵循依赖规则,这条规则表明,源代码只能向内依赖,内侧圆环不了解关于外侧圆环的一起,原则上,外圈圆环声明的名称不需要在内侧圆环中提到,其中包括函数,类,变量或者其他软件实体的名字\n\n出于同样的原因,在外圆圈中使用的数据格式不应该使用在内圆圈,特别是格式是由外圆圈的框架产生的情况,我们不希望外圆圈影响内圆圈的内容\n\n##实体\n实体封装项目范围内的业务规则,一个实体可以是一个对象的方法,或者是一组数据结构和功能.只要在项目中实体被不同的应用所使用即可。\n\n如果你没有项目,只是单纯的写一个应用程序,那么这些实体就是应用程序的业务对象.它们封装的最普通,最高级的规则.当外部变化时,它们最有可能改变,例如,你不希望这些对象被一个更改的页面导航或者安全影响,改变特定应用程序的操作不应该影响实体层。\n\n##用例\n在此层应用的业务规则包含应用特定的业务规则,他封装并实现了所有的系统用例,这些用例编排数据的流入和流出的实体,指示这些实体用在它们项目范围内的业务规则到达用力的目标。\n\n我们不希望改变层时影响实体,也不希望层被外部的改变所影响,例如数据库,用户界面或者任何的共同框架的改变,此层与这部分是隔离开的。\n\n我们这样做,不过是希望改变应用程序的操作时影响软件层的用例,用例详细信息改变时,这一层的代码也会受到影响。\n\n## 接口适配器\n这层软件是一个转化数字的适配器,从格式最方便的用例和实体转化为格式最方便的一些外部机构,如数据库或者网页,这一层完全包含GUI的MVC架构,代理者,视图,控制器都属于这一层,该模型可是只是从控制器传回到用例,然后从用例到代理和视图的数据结构。 \n\n同样的,在这一层数据被转换,从形式最方便的实体和用例转化成形式最方便的使用持久框架,即数据库.内圈里的任何代码不应该知道关于数据库的任何事情.如果这个数据库是SQL数据库,所有的SQL应该被限制在这一层,尤其是在这层对数据库的操作。\n\n另外,在这一层其他适配器需要将数据从外部形势(如外部服务)转化成内部形式的用例和实体。\n\n## 框架和驱动程序\n最外层一般由框架和工具组成,如数据库,web框架等.一般来说,你不会在这一层写太多代码,而是贴代码传达到内层圆圈内。\n\n这一层有很多细节,网页是一个细节,数据库是一个细节,我们保持外层的这些细节收到更少的破坏。 \n\n## 只有四个圆环?\n不,圆圈只是传达意思,你可能会发现你使用到的不仅仅是这四个,没有规定你必须使用这四个圆环,然后,依赖规则始终适用,源代码始终向内依赖.越往圆圈内侧抽象水平越高,最外面的圆圈为低一级的具体细节.越往圆圈内侧抽象和封装的层次更高,最内侧圆层次最高,最普通. \n\n## 跨越边界\n该图的右下方是一个我们如何穿越边界的例子,它展示了控制器和代理者与下一层用例进行通信.注意控制流,开始于控制器,通过用例移动,结束于代理者的执行.还要注意源代码的依赖关系,指向内侧用例。 \n\n我们通常使用[依赖倒置原则](http://zh.wikipedia.org/wiki/%E4%BE%9D%E8%B5%96%E5%8F%8D%E8%BD%AC%E5%8E%9F%E5%88%99)解释这个明显的矛盾,像java语言,例如,我们会编排接口和继承的关系，使源代码在跨越边界的右侧点依赖反对控制流.\n\n例如,考虑用例需要调用的代理.然而不需要直接调用,因为这将违反相关性规则:在外圈中的名称不需要在内圈中提及.因此,我们在内侧圆环中调用接口(这里显示的用例输出端口),在外侧圆环实现它.\n\n相同的技术应用在跨越边界的系统结构中,无论控制流会在什么方向,我们以动态多态性的优势创建源代码依赖性,反对控制流,使得我们能够符合依赖规则。 \n\n## 什么是数据跨越边界\n通常跨越边界的数据是一种单纯的数据结构,可以使用基本的结构或者简单的数据进行传输.或者数据可以单纯的在函数中调用,或者你可以打包成一个hashMap,或构造成一个对象,重要的是分离,操作简单,通过数据结构跨越边界.我们不想通过实体和数据作弊,不希望数据结构有任何一种依赖违反依赖规则.\n\n例如,很多数据库框架响应查询返回一个方便的数据格式,我们称之为行结构.我们不希望向内跨越行结构,这将违反依赖规则,因为这会迫使内侧圆环了解外侧圆环的一些东西。\n\n因此,当我们跨越边界传输数据时,它总是使用最方便内圆环的格式。\n\n## 结论\n符合这些简单的规则并不难,并会为你省掉很多前进过程中头疼的问题,通过软件分层,顺应依赖规则,创建一个系统在本质上是可以检测的,意味着拥有其本身的好处.当任何一个系统的外部部件过时时,如数据库或者web框架,你可以使用最少的忧虑替换掉那些过时的元素。\n" }, { "path": "others/简化Android的UI开发/readme.md", "content": "简化Android的UI开发\n---\n\n>\n* 原文链接 : [android ui development made easy](http://zserge.com/blog/android-mvx.html)\n* 作者 : [Zaitsev Serge](http://zserge.com/blog.html)\n* 译者 : [chaossss](https://github.com/chaossss) \n* 校对者: [ZhaoKaiQiang](https://github.com/ZhaoKaiQiang) \n* 状态 : 校对完成\n\n\n\n\n如果你觉得这篇文章太长，而且还没有往下阅读的话，我可以给你简要的介绍文章要讲的内容：我使用纯 Java 通过数据绑定的方式提供了一种\n\nAndroid UI 开发的代码往往是支离破碎的，写出来的代码通常都是大量的模板化代码，而且没有结构可言。下面是一些问题（纯属个人见解）：\n\n- Android UI 开发很少符合 MVC 模式（或者是 M-V-其他任何东西）\n\n- XML文件通常包含了很多重复的代码，在代码复用方面比较糟糕\n\n- XMLS 非常脆弱，这使得你在写 XML 文件时，即使输入了 TextVeiw ，在编译过程中编译器也不会警告你，但在 App 运行时又会抛出 InflateException 异常\n\n- 缺少对 styles 的支持，缺少对变量的支持，不支持宏和计算结果（例如 10dp + 2px)\n\n- 没有数据绑定，这使得你必须自己把所有的 findViewById 和 setOn...Listener 写好\n\n- 你可以通过 Java 实现你的布局，但是写出来的代码有如天书\n\n## 使用 mithril.js 建立用户接口 ##\n\n在 Web 开发中，开发者们很快就意识到在没有 MVx 的情况下开发复杂的应用会很吃力，这使得他们意识到 jQuery 中存在的问题，并开发了 Backbone，Knockout，Angular，Ember...等等，来提高他们的开发效率\n\n但在 Android 中，我们还在通过那一点点函数毫无章法可言地设置 View 的属性，就像在 jQuery 里一样：\n\n```java\n\t$('.myview').text('Hello');\n\t$('.myview').on('click', function() {\n\t\n\t});\n\t\n\tmyView.setText(\"Hello\");\n\tmyView.setOnClickListener(new View.OnClickListener() { ...});\n```\n\n我们在一个目录下定义了我们的 Layout ，又在另一个目录中使用它们，然后在 UI 开发的代码里改变\n，这样并不好。\n\nReact.js 对 Web 开发有一点点影响：他们以树状关系的自定义对象创建了一个虚拟的 DOM 概念，并以此展示实际的 HTML 布局。虚拟树创建和切换的时间都很短，所以当实际的 DOM 需要被渲染，两棵虚拟树（前一棵和新的那棵）将进行对比，只有不匹配的部分才会被渲染。\n\nMithril.js 是一个精悍、短小的框架，使用它能使 React.js 的实现更整洁。在 Mithril 中，除了纯 JavaScript，你几乎能摆脱一切，同时，它还能让你在写布局的时候感受到图灵完备的语言所具备的力量。\n\n```java\n\treturn m('div',\n\t m('p', someText),\n\t m('ul',\n\t items.map((item) => m('li', item))),\n\t m('button', {onclick: myClickHandler}));\n```\n\n因此，你能用循环生成许多 View，你能用判断语句改变布局中的某个部分，最后你能绑定数据和设置事件监听器。\n\n那这个方法能在 Android 中被使用吗？\n\n## 虚拟布局 ##\n\n虚拟布局（使用类似 Web 中虚拟 DOM 的概念）是树状的自定义Java对象集合，被用于展示实际的 Android 布局。虽然 App 的数据改变多少次，树就会被构建多少次，但布局改变的内容应该仅仅是前后不一致的部分（当前的布局和改变前布局）。\n\n我们的框架只导入一个静态类，所以所有类中的静态方法都不需要类名前缀就能被使用（例如我们只需要使用 v()，而不是 Render.v()），这是语言特性带来的好处。下面是我们如何创建布局的例子：\n\n```java\n\tv(LinearLayout.class,\n\t orientation(LinearLayout.VERTICAL),\n\t v(TextView.class,\n\t text(someText)),\n\t v(Button.class,\n\t text(\"Click me\"),\n\t onClick(someClickHandler)));\n```\n\n第一个 v() 方法返回了一个虚拟布局，每一次调用后它会返回当前应用状态的实际展示（不是实际的 View！）\n\n当一些文字变量被改变 - 虚拟树会获得一个被用于下次渲染的发生了改变的结点值，然后调用 setText()改变相应的 TextView 实例。但是其余的布局不会发生任何变化。\n\n一棵虚拟布局树在理想情况下应该只是一个类，我们就把它叫作结点吧。但是结点主要有两种类型：View 结点（TextView.class等等）和属性设置结点，例如text（someText)\n\n那这就意味着结点应该任意包含一个 View 类和一个方法去改变 View 的属性。\n\n```java\n\tinterface AttributeSetter {\n\t public void set(View v);\n\t}\n\n\tpublic static class Node {\n\t List attrs = new ArrayList();\n\t Class viewClass; // for view nodes\n\t AttributeSetter setter; // for attribute setter nodes\n\t\n\t public Node(Class c) {\n\t this.viewClass = c;\n\t }\n\t\n\t public Node(AttributeSetter setter) {\n\t this.setter = setter;\n\t }\n\t}\n```\n\n现在我们需要定义类在产生虚拟布局的时候实际能干的事情了，那就让我们来调用可渲染类吧。一个可渲染类可以是一个 Activity，或者一个自定义的 ViewGroup，或者 Fragment 也凑合。每一个可渲染类都应该有一个用于返回虚拟布局的方法，此外，如果这个方法指定了它将要作用于实际布局中的哪个 View 会更好。\n\n```java\n\tpublic interface Renderable {\n\t Node view();\n\t ViewGroup getRootView();\n\t}\n```\n\n由于 v() 方法的第一个参数是 View 子类的泛型，所以你不用担心类型安全问题。剩下的参数都是结点类型，所以我们只需要把它们添加到 list 中，无视掉空结点的话效果会更好一些。\n\n```java\n\tpublic static Node v(final Class cls, final Node ...nodes) {\n\t return new Node(cls) ;\n\t}\n```\n\nHere's an example of the text() attribute setter (the real code is a bit different, but it could have been implemented like this):\n\n下面是一个 text() 属性的设置方法（实际代码会有点不一样，但是也能像下面这样实现）：\n\n```java\n\tpublic static Node text(final String s) {\n\t return new Node(new AttributeSetter() {\n\t public void set(View v) {\n\t ((TextView) v).setText(s);\n\t }\n\t });\n\t}\n```\n\n其他类似的工具方法也能用于改变线性布局的方向，View 的大小、页边距、间距，总之所有 View 的参数都能被改变。\n\n## 那么，我们要怎么去渲染呢？ ##\n\n现在我们需要一个“渲染者”。这是一个能够根据类名创建 View ，使用 AttributeSetters修改对应的参数并且递归地添加子 View的方法。（同样的，下面的代码也是被简化的，实际的代码会有些不一样，主要差别在于当结点没有被改变的时候，我们应该如何避免视图的渲染）\n\t\n```java\n\tpublic static View inflateNode(Context c, Node node, ViewGroup parent) {\n\t if (node.viewClass == null) {\n\t throw new RuntimeException(\"Root is not a view!\");\n\t }\n\t // Exception handling skipped here to make the code look shorter\n\t View v = (View) node.viewClass.getConstructor(Context.class).newInstance(c);\n\t parent.addView(v);\n\t for (Node subnode: node.attrs) {\n\t if (subnode.setter != null) {\n\t subnode.setter.set(v);\n\t } else {\n\t View subview = inflateNode(c, subnode, (ViewGroup) v);\n\t }\n\t }\n\t return v;\n\t}\n```\n\n现在我们真的可以摆脱 XMLS，并以一种简洁的方式通过 Java 进行布局了。\n\n布局结点不应该直接地被使用，而应该是通过 render(Renderer r) 和 render()被使用。前者用于重渲染某一个 View，后者用于重渲染所有被展示的 View。Renderer 通过一个弱哈希表存储，使得在 View 被移除或者 Activity 被销毁的同时 - 他们的渲染者也不会再被使用。\n\n## 什么时候去渲染呢？ ##\n\n这个框架的核心在于 自动进行重渲染，使得 UI 总能展示当前的虚拟布局状态。这就意味着 render() 应该在某个特定的节点被调用。\n\n我参考 Mithril 的方法，把每一个 On...Listener 和 调用 render 的方法捆绑在每一次 UI 的交互中。\n\n```java\n\tpublic static Node onClick(final View.OnClickListener listener) {\n\t return new Node(new AttributeSetter() {\n\t public void set(View v) {\n\t v.setOnClickListener(new View.OnClickListener() {\n\t public void onClick(View v) {\n\t listener.onClick(v);\n\t // After the click was processed - some data may have been changed\n\t // so we try to re-render the UI\n\t render();\n\t }\n\t });\n\t }\n\t });\n\t}\n```\n\n我觉得这样做是有道理的，因为大多数 Android 应用的数据都是在发生用户交互的时候被改变的。如果你的数据是因为其他因素被改变的 - 那就只能手动通过 render()渲染了。\n\n## 总的来说 ##\n\n这个方法虽然简单，却非常有用：\n\n- 你能用类似 XML 的方式定义你的布局结构（通过嵌套调用 v() 方法）\n\n- 你能用一种清晰易懂的方式绑定数据和监听器\n\n- 布局都是类型安全的，并且你的编译器会自动完成相应的工作\n\n- 没有运行时产生的开销，没有使用反射机制，没有自动生成代码\n\n- 你能在任何地方使用 Java（变量，语句，宏）生成布局\n\n- 你能用自定义 View 和自定义的属性设置方法\n\n- 因为你的所有 UI 数据都被保存在属性中，因此你能轻易的保存它们\n\n- 使用纯 Java 实现这些逻辑需要的代码还不到 250 行！\n\n以上证明了这个方法是可行的。现在我在想，如果有人想要用这个方法开发一个功能齐全的库呢？\n\n设计一个好的“区分”算法会是其中的关键。基本地，它应该能判断一个结点是否被添加/移除/修改，而文件就在于属性节点。简单的数据类型我们只要调用 equals() 去比较两个值就可以了，但是监听器呢？\n\n```java\n\tv(SomeView.java,\n\t onClick(v => ...));\n```\n\n这样做的话每一次虚拟树被创建，都会创建一个对应的监听器对象。那怎么去比较它们？还是永远都不更新监听器，只更新发生了改变的监听器类？或者使用某种事件分发机制分发事件，而不是使用监听器？\n\n另一件需要被注意的是：我不想自己把所有属性设置方法写好。这里有一个更好的方法，也就是 Kotlin 他们在 koan 库中做的那样。\n\n我现在在研究怎么从 android.jar 的类中自动生成设置器，以使得这个项目更有用。\n\n不管怎样，现在的代码我都放在 [Github](https://github.com/zserge/anvil) 上了，有 MIT 的许可。欢迎大家来评论和 PR！" }, { "path": "others/自动化截图－应用分发时的自动截图方案/readme.md", "content": "自动化截图－应用分发时的自动截图方案\n---\n\n>\n* 原文链接 : [Screenshots Through Automation](http://flavienlaurent.com/blog/2014/12/05/screenshot_automation/)\n* 作者 : [Flavien Laurent](http://flavienlaurent.com/)\n* 译者 : [chaossss](https://github.com/chaossss) \n* 校对者: [sundroid](https://github.com/sundroid) \n* 状态 : 校对完成\n\n在发布 App 到应用商店时有一件的事情不得不做，就是上传最新的高清无码截图到应用商店上。可是如果你的 App 有许多页面，那你每次发布更新都可能是一场梦魇，因为你需要一页一页地去截图。为了解决众多 App 开发者的这个痛点，我将在这篇博文中介绍一个实现自动化截图的方法：\n\n刚到 [Capitaine Train](https://www.capitainetrain.com/) 公司里，就有人让我造个能自动截图的轮子，因为我们公司的 App 每次版本更新都让人很头疼：问题在于我们的 App 对应有3种设备，4种语言，也就是有 12 种版本。此外，我们有6个需要截图的页面，也就是说，我们每次版本更新都需要72张截图。我们无法忍受这种低效并浪费时间的工作，于是我们经过不懈的努力，找到了一个自动化截图的方案，在这个方案中，要实现自动化截图有三个关键点：uiautomator 自动化测试, accessibility 和 bash脚本。\n\n## 修改 uiautomator ##\n\nuiautomator 是一个用部分封装代码将 UI 处理成一个 JUnit 测试用例的框架。这里需要注意的是：被测试的 App 里没有包含这些测试用例，因为他们在一个独立的进程中运行。换句话说，你可以把 uiautomator 框架看作一个独立的机器人，它能帮你在设备上完成诸如：点击，滚动，截图等简单动作。\n\n\n**预备知识**\n\n在继续讲解之前，我建议你花些时间阅读官方文档，这能帮助你更好地理解接下来的内容。\n\nuiautomator 框架的 API 非常简单，里面有三个类分别代表了不同类型的 UI 界面元素：\n\n- UiObject: 基本界面元素，例如：TextView\n\n- UiCollection: 包含多个 UiObject 的界面元素，例如：LinearLayout\n\n- UiScrollable: 包含多个 UiObject ，并能滚动的界面元素，例如：ListView\n\n![](http://flavienlaurent.com/media/2014-12-05-screenshot_automation/uml.png)\n\n框架里这两个类你也需要了解：\n\n- UiDevice：用于执行设备常见的动作，例如：点击按钮，截图等等\n\n- UiSelector：通过 id, 类型等获得屏幕上的 UI 界面元素\n\n最后，UiAutomatorTestCase 是框架里你绝对不能忽略的类，因为我们必须通过继承它来获得一个 uiautomator 测试用例。\n\n当然了，我刚刚提到的这些类在官方文档里面都有详细的解释，此外，文档还提供了一些示例来帮助我们熟悉 uiautomator 。\n\n**安装，创建和运行**\n\n接下来我们要做的就是创建 uiautomator ，但很不幸，uiautomator 并没有一个官方的 Gradle 整合模块，所以我们必须自己去完成这项工作。把这些工作都完成后，才能在我们的 App 上使用 uiautomator。uiautomator 测试用例的最终输出应该是一个独立的 JAR 包。具体步骤如下：\n\n在你的项目里新建一个 Gradle 模块，并在其中添加与 local.properties 相同的 android.jar 依赖包：\n\n.build.gradle\n\n```java\n\tapply plugin: 'java'\n\t\n\tProperties props = new Properties()\n\tprops.load(new FileInputStream(file(\"../local.properties\")))\n\t\n\tdependencies {\n\t compile fileTree(dir: props['sdk.dir'] + '/platforms/' + androidSdkTarget, include: '*.jar')\n\t}\n```\n\n通过使用 local.properties 和 gradle.properties 新建一个 ant 文件，使其获得与项目相同的配置信息(target, sdk path)：\n\nbuild.xml\n\n```xml\n\t\n\t\n\t \n\t \n\t \n\t \n\t\n```\n\n使用ant 构建JAR（不要使用Gradle构建），并把它加到你的设备中，然后运行你的测试用例。\n\n```java\n$ ant build\n$ adb push uiautomator.jar data/local/tmp\n$ adb shell uiautomator runtest uiautomator.jar -c com.your.TestCase\n```\n\n**自动切换设置信息**\n\n现在我准备讲解怎么在设置中自动切换设置项和设置信息（特别是从一个语言切换到另一个语言）。首先，这是一个练习使用 uiautomator 的机会。同时，这也是自动化截图的关键步骤。但你要记住，我接下来介绍的只是一个能在 Android 5.0 系统上正常使用的办法，如果你有更好的建议或者想法，也可以通过留言和我交流，一起优化这个步骤。\n\n- 打开快捷设置\n\n```java\n\tmUiDevice.openQuickSettings();\n```\n\n- 点击设置按钮以打开设置界面\n\n```java\n\tnew UiObject(new UiSelector().resourceId(\"com.android.systemui:id/settings_button\")).click();\n```\n\n- 因为在设置界面里我们没有可用的 View 的 id 值，所以我们必须根据设置栏的文字改变相对应的语言设置。所以我们滚动到某一项（FrameLayout）并点击它\n\n![](http://flavienlaurent.com/media/2014-12-05-screenshot_automation/settings_app.png)\n\n```java\n\tUiScrollable scrollable = new UiScrollable(new UiSelector().resourceId(\"com.android.settings:id/dashboard\"));\n\t\n\tscrollable.getChildByText(new UiSelector().className(FrameLayout.class), \"Language & input\", true).click();\n```\n\n- 通过上面的代码处理，整个“寻找并点击”的自动化逻辑已经能在语言设置栏里被使用了。\n![](http://flavienlaurent.com/media/2014-12-05-screenshot_automation/settings_language.png)\n\n```java\n\tUiScrollable scrollable = new UiScrollable(new UiSelector().className(ListView.class));\n\tscrollable.getChildByText(new UiSelector().className(LinearLayout.class), \"Language\", true).click();\n```\n\n- 添加这样的代码后，就能使得目标语言被选中了。\n\n![](http://flavienlaurent.com/media/2014-12-05-screenshot_automation/settings_language_selection.png)\n\n```java\n\tUiScrollable scrollable = new UiScrollable(new UiSelector().className(ListView.class));\n\tscrollable.getChildByText(new UiSelector().className(LinearLayout.class), \"Français (France)\", true).click();\n\tLocale.setDefault(new Locale(\"fr\"));\n```\n\n完成了上面的操作后，你还需要强制设置新的语言环境以避免 uiautomator 操作过程中保存了翻译缓存。\n\n**小提示**\n\n- 为了保证 uiautomator 的稳定性，当你在使用 uiautomator 时，必须关掉设备上的所有动画效果（你可以通过下面的设置完成：Settings > Developer options > Window animation|Transition animation|Animator duration scale）\n\n- 如果你想打 Log 方便你的调试，你可以使用 android.util.Log。为了更好地区分 Log 信息，你可以使用特定的标记来筛选它们。\n\n- 每一次你需要在 View 的不同层级间切换都要使用 uiautomatorviewer。因为它能为你提供一个精确的选择器，使你能够获得目标 UI 界面元素（uiautomatorviewer 在 sdk/tools/uiautomatorviewer 里）。\n\n- 记住，uiautomator 测试用例不是 Android 的测试用例，所以你不需要使用任何形式的 Context。\n\n- 你不能通过 uiautomator 进入你的 App 类，你只能引用 Android 框架中的类。\n\n- 你可以在命令行中使用 -e 命令把 uiautomator 命令行的参数传递到测试用例类中，又或者是使用测试用例类中的 UiAutomatorTestCase.html#getParams()。\n\n这样处理下来，你会发现自动完成语言的切换很简单对吧？uiautomator 虽然是个很好的工具，但如果你的 App 不是可访问的，它就没什么用了。特别是你的 App 需要创建完全自定义的 View 时，就可能会出现各种问题，所以接下来我们要解决的问题就是让 App 可以被访问，特别是自定义 View。\n\n## 让自定义 View 可访问 ##\n\n可访问性对一个 App 来说非常重要，其作用主要体现在两个方面：有些用户/开发者需要它（但总有开发者会忽略这个需求），此外，uiautomator 都以可访问性为基础，也就是说，如果一个应用不能提供可访问的入口，我们将无法在其中使用 uiautomator 自动化测试工具。\n\n大部分情况下，你都没有必要让你的 App 可以被其他应用访问。但事实上，大部分 View 都是可访问的，例如 TextView，ListView 等等。不过在你使用自定义 View 时，获得访问性可能会麻烦点，因为这需要你花费一些功夫去改变其中的代码。\n\n在 Capitaine Train App 里，为了满足对日历视图的特殊需求，我们创建了一个自定义 View。这个 View 是基于 ListView 设计的，ListView 中的每一项都有好几个自定义 View，并且每一个自定义 View 都代表一个月（我们称为 MonthView）。MonthView 是一个纯粹的 View，它继承于 View，并没有子类。这样使得 MonthView 中的一切都需要通过 onDraw() 方法进行绘制。因此，MonthView 在默认情况下不能被访问。\n\n首先要做的事情很简单：使用 View#setContentDescription 方法为每一个 MonthView 设置内容描述，这样我们能够把 ListView 滚动到一个特殊的月份上。\n\n然后，一旦 ListView 停留在某一个给定的月份上，我们希望我们能够选择一个确定的日期。为了实现这个需求，我们需要使 MonthView 的内容是可访问的。幸运的是，Android 的支持库在类似的处理上提供了一个很有用的 Helper类：ExploreByTouchHelper。由于 MonthView 不是以树形结构结合展示其中的 View 集合，所以创建伪树状结构的 View 集合需要基于触摸反馈实现。\n\n\n**为自定义 View 实现 ExploreByTouchHelper**\n\n我们有四个方法可以实现：\n\n- getVirtualViewAt(float x, float y) \n返回参数 x,y处所对应的虚拟 View 的 id。如果对应位置上没有虚拟 View，则返回 ExploreByTouchHelper.INVALID_ID\n\n- getVisibleVirtualViews(List virtualViewIds) \n将自定义 View 中所有虚拟 View 的 id 添加到 virtualViewIds 数组中。\n\n- onPopulateEventForVirtualView(int virtualViewId, AccessibilityEvent event) \n让虚拟 View 的相关信息可以被访问，例如：文字，内容描述\n\n- onPopulateNodeForVirtualView(int virtualViewId, AccessibilityNodeInfo node) \n让给定结点能够访问虚拟 View 的相关信息，例如文字，内容描述，类名，与父类的关系。如果两者之间产生了交互，你必须在给定结点中说明。\n\n- onPerformActionForVirtualView(int virtualViewId, int action, Bundle arguments) \n在虚拟 View 中实现某种动作（在前面的方法中被指定）\n\n怎么让 ExploreByTouchHelper 的接口变得更简单：\n\n- 创建一个 VirtualView 类去持有虚拟 View 的各种信息，例如：id，文字，内容描述，与父类的关系。\n- 在你的自定义 View 中使用一系列的 VirtualView。尽快初始化它们，并在绘制后更新它们\n\nYourAccessibilityTouchHelper.java\n\n```java\n\tprivate class YourAccessibilityTouchHelper extends ExploreByTouchHelper {\n\t\n\t public YourAccessibilityTouchHelper(View forView) {\n\t super(forView);\n\t }\n\t\n\t @Override\n\t protected int getVirtualViewAt(float x, float y) {\n\t final VirtualView vw = findVirtualViewByPosition(x, y);\n\t if (vw == null) {\n\t return ExploreByTouchHelper.INVALID_ID;\n\t }\n\t return vw.id;\n\t }\n\t\n\t @Override\n\t protected void getVisibleVirtualViews(List virtualViewIds) {\n\t for (int i = 0; i < mVirtualViews.size(); i++) {\n\t mVirtualViews.add(mVirtualViews.get(i).id);\n\t }\n\t }\n\t\n\t @Override\n\t protected void onPopulateEventForVirtualView(int virtualViewId, AccessibilityEvent event) {\n\t final VirtualDayView vw = findVirtualViewById(virtualViewId);\n\t if (vw == null) {\n\t return;\n\t }\n\t event.getText().add(vw.description);\n\t }\n\t\n\t @Override\n\t protected void onPopulateNodeForVirtualView(int virtualViewId, AccessibilityNodeInfoCompat node) {\n\t final VirtualDayView vw = findVirtualViewById(virtualViewId);\n\t if (vw == null) {\n\t return;\n\t }\n\t\n\t node.setText(Integer.toString(vw.text));\n\t node.setContentDescription(vw.description);\n\t node.setClassName(vw.className);\n\t node.setBoundsInParent(vw.boundsInParent);\n\t }\n\t}\n```\n\n**在你的自定义 View 中使用 Helper 类**\n\n我们需要在 ListView.getView 方法被执行后通过 setAccessibilityDelegate() 方法重设代理，因为我们需要实现 dispatchHoverEvent() 方法来激活对触摸事件的探索。（如果你的自定义 View 没有在 ListView 中被使用的话，只需要在构造器中设置代理）。\n\nYourCustomView.java\n\n```java\n\tpublic class YourCustomView extends View {\n\t\n\t private final YourAccessibilityTouchHelper mTouchHelper;\n\t\n\t public YourCustomView(Context context, AttributeSet attrs, int defStyle) {\n\t super(context, attrs, defStyle);\n\t mTouchHelper = new YourAccessibilityTouchHelper(this);\n\t }\n\t \n\t private void setAccessibilityDelegate() {\n\t setAccessibilityDelegate(mTouchHelper);\n\t }\n\t\n\t [...]\n\t\n\t public boolean dispatchHoverEvent(MotionEvent event) {\n\t if (mTouchHelper.dispatchHoverEvent(event)) {\n\t return true;\n\t }\n\t return super.dispatchHoverEvent(event);\n\t }\n```\n\n**用 uiautmatorviewer 检查你的接口能否正常运行**\n\n如果一切都正常运行，在你用 uiautmatorviewer 截图后，你应该能在虚拟 View 图层看到在可访问结点中预设置的所有信息。\n\n![](http://flavienlaurent.com/media/2014-12-05-screenshot_automation/accessibility_calendar_uiautomator.png)\n\n另一方面，在我写这篇博文的时候我发现 Capitaine Train App里的一个问题：每一个虚拟 View 的类名都是 com.capitainetrain.x，因为我们忘了用 Proguard。\n\n现在 App 中的一切都是可访问的，我们总算可以在 App 中顺利使用 uiautomator 进行自动化截图了。打铁趁热，我们不妨对我们的代码稍作修改，让它能够“优雅地截图”。\n\n## 优雅地截取图片 ##\n\n这篇博文要讲解的最后一个问题就是怎么改进 uiautomator ，使得它能在多种语言中优雅地自动截图。实现这个功能需要两个步骤：第一，使用 bash 脚本运行 uiautomator 测试用例，并按照你需要的图片数量进行自动化截图，之后用 imagemagick 处理你获得的照片。\n\n首先要做的就是创建 uiautomator JAR包，然后运行测试用例。因为你已经在前面的讲解中学习了怎么在测试用例中转换语言，所以你只需要传递两个参数到测试用例中：当前设置中使用的语言和你将要切换的语言。\n\nscreenshot.sh\n\n```gradle\n\t# Build and push the uiautomator JAR\n\tant build\n\tadb push bin/uiautomator.jar data/local/tmp\n\t\n\tadb shell uiautomator runtest uiautomator.jar\n\t -e current_language ${currentLanguage}\n\t -e new_language ${newLanguage}\n\t -c com.your.TestCase\n```\n\n接下来我们只要再创建一个能够切换语言，打开 App并截图的简单测试用例就可以啦：\n\nTestCase.java\n\n```java\n\tpublic class TestCase extends UiAutomatorTestCase {\n\t [...]\n\t @Override\n\t protected void setUp() throws Exception {\n\t super.setUp();\n\t final Bundle params = getParams();\n\t mCurrentLanguage = params.getString(\"current_language\");\n\t mNewLanguage = params.getString(\"new_language\");\n\t }\n\t\n\t public void test() throws Exception {\n\t switchLanguage(mCurrentLanguage, mNewLanguage);\n\t openApp();\n\t takeScreenshot(\"data/local/tmp/screenshots\");\n\t }\n\t}\n```\n\n\n- switchLanguage(String,String)只需要使用我在\"修改 uiautomator\"中讲解的方法就能轻松地实现 \n- openApp() 在 [这里](https://developer.android.com/tools/testing/testing_ui.html#sample)有详细的解释\n- takeScreenshot() 使用了 UiDevice#takeScreenshot 方法。在这里只有一个小提示：如果一个 App 使用了可滚动的 View，在滚动条消失之前我们必须安静地等一会儿，不然的话我们会在最后的截图里看到它。\n\n现在截图都被储存在设备里了，我们只需要把它们取出来就大功告成了：\n\nscreenshot.sh\n\n```\n\tmkdir screenshots\n\tadb pull data/local/tmp/screenshots screenshots\n```\n\n在多语言环境中运行测试用例。它会从设备当前使用的语言开始运行，因为我找不到一个合适的方式去表示它，然后会在不同的语言环境下（我们需要截图的那些语言）运行测试用例。\n\nscreenshot.sh\n\n```\n\tscreenshot() {\n\t currentLanguage=$1\n\t newLanguage=$2\n\t adb shell uiautomator runtest uiautomator.jar\n\t -e current_language ${currentLanguage}\n\t -e new_language ${newLanguage}\n\t -c com.your.TestCase\n\t}\n\n\tscreenshot $deviceLanguage fr\n\tscreenshot fr en\n\tscreenshot en de\n```\n\nApp 每次卸载/安装后在相同的环境下运行测试用例都能正常地实现自动化截图的功能：\n\nscreenshot.sh\n\n```\n\tscreenshot() {\n\t currentLanguage=$1\n\t newLanguage=$2\n\t\n\t # Uninstall/Install the app\n\t adb uninstall com.your.app\n\t adb install ../app/build/outputs/apk/yourapp-release.apk\n\t \n\t adb shell uiautomator runtest uiautomator.jar\n\t -e current_language ${currentLanguage}\n\t -e new_language ${newLanguage}\n\t -c com.your.TestCase\n\t}\n```\n\n最后把所有模块糅合在一起：\n\nscreenshot.sh\n\n```\n\tscreenshot() {\n\t currentLanguage=$1\n\t newLanguage=$2\n\t\n\t # Uninstall/Install the app\n\t adb uninstall com.your.app\n\t adb install ../app/build/outputs/apk/yourapp-release.apk\n\t\n\t # Run the test case\n\t adb shell uiautomator runtest uiautomator.jar\n\t -e current_language ${currentLanguage}\n\t -e new_language ${newLanguage}\n\t -c com.your.TestCase\n\t \n\t mkdir screenshots\n\t adb pull data/local/tmp/screenshots screenshots\n\t}\n\n\t# Build and push the uiautomator JAR\n\tant build\n\tadb push bin/uiautomator.jar data/local/tmp\n\t\n\t# Build the APK\n\tcd .. && ./gradlew assembleRelease && cd uiautomator\n\t\n\t# Screenshot everything\n\tscreenshot $currentLanguage fr\n\tscreenshot fr en\n\tscreenshot en de\n```\n\n**美化截图**\n分享一篇好文：[Creating professional looking screenshots](http://cyrilmottier.com/2012/07/11/creating-professional-looking-screenshots/)。\n\n每一个 App 的运营者都应该尽其所能美化 App 的截图，因为这是用户在应用商店中对 App 的第一印象。大多数情况下，用户都不会阅读应用的描述，而是直接打开应用的截图，因为阅读文字比看图片更费劲。虽然不能说经过下面的处理能获得完美无瑕的图片，但也在水平线以上了。那么什么样的 App 截图是优雅的截图呢？\n\n- 始终保持状态栏的整洁\n\n- 移除导航栏\n\n- 适配多种屏幕的尺寸\n\n第二点可以用一个超神奇的工具—imagemagick 实现，虽然它的官方文档非常大，但我们用不到那么多的特性，所以我们只需要关注两个特性：组合和转换。\n\n**用组合图覆盖状态栏**\n\n组合图是用来把一个图片覆盖到另一个上面的，这是获得简洁状态栏的完美办法。\n\n```java\ncomposite -quality 100 -compose atop clean_status_bar.png screenshot.png clean_screenshot.png\n```\n\n**通过转换裁剪导航栏**\n\n转换特性被用于转换图片的格式，使其格式与裁剪后的图片相同，这是从截图中移除导航栏的完美办法。\n\n```java\nconvert -quality 100 screenshot.png -gravity South -chop 0x144 clean_screenshot.png\n```\n\n144是在Nexu5上导航栏的高度像素值。\n\n**结论**\n\n因为有了这篇博文，通常要花费半天，甚至一天的截图工作现在能通过 Capitaine Train 上用的这个自动化截图工具缩短到 20～30 分钟完成（我相信没有人想手动地做这些工作，或者因为嫌弃这样的工作，从不更新 App 的截图）。这个工具能高效地节省时间，如果能够更多的人和资源投入到这个工具的开发之中，我相信这个工具还能变得更好，也不会那么容易出错和崩溃。\n\n接下来可能做的：\n\n使用 Google Play 发布的 API 简化上传这些自动生成的截图的流程，并把这个工具整合到 Jenkins 里，让 App 每一次版本更新都能自动地获取最新的截图，并将其显示在应用商店中。\n\n" }, { "path": "rxjava/chap1.md", "content": "# RxJava开发精要1-从.NET到RxJava\n\n> \n> * 原文出自《RxJava Essentials》\n* 原文作者 : [Ivan Morgillo](https://www.packtpub.com/books/info/authors/ivan-morgillo)\n* 译文出自 : [开发技术前线 www.devtf.cn](http://www.devtf.cn)\n* 转载声明: 本译文已授权[开发者头条](http://toutiao.io/download)享有独家转载权，未经允许，不得转载!\n* 译者 : [yuxingxin](https://github.com/yuxingxin) \n* 项目地址 : [RxJava-Essentials-CN](https://github.com/yuxingxin/RxJava-Essentials-CN)\n\n## RX - 从.NET到RxJava\n\n响应式编程是一种基于异步数据流概念的编程模式。数据流就像一条河：它可以被观测，被过滤，被操作，或者为新的消费者与另外一条流合并为一条新的流。\n\n响应式编程的一个关键概念是事件。事件可以被等待，可以触发过程，也可以触发其它事件。事件是唯一的以合适的方式将我们的现实世界映射到我们的软件中：如果屋里太热了我们就打开一扇窗户。同样的，当我们更改电子表（变化的传播）中的一些数值时，我们需要更新整个表格或者我们的机器人碰到墙时会转弯（响应事件）。\n\n今天，响应式编程最通用的一个场景是UI：我们的移动App必须做出对网络调用、用户触摸输入和系统弹框的响应。在这个世界上，软件之所以是事件驱动并响应的是因为现实生活也是如此。\n\n## 微软响应式扩展\n\n函数响应式编程是一个来自90年代后期受微软的一名计算机科学家Erik Meijer启发的思想，用来设计和开发微软的Rx库。\n\nRx 是微软.NET的一个响应式扩展。Rx借助可观测的序列提供一种简单的方式来创建异步的，基于事件驱动的程序。开发者可以使用Observables模拟异步数据流，使用LINQ语法查询Observables，并且很容易管理调度器的并发。\n\nRx让众所周知的概念变得易于实现和消费，例如**push方法**。在响应式的世界里，我们不能假装作用户不关注或者是不抱怨它而一味的等待函数的返回结果，网络调用，或者数据库查询的返回结果。我们时刻都在等待某些东西，这就让我们失去了并行处理其他事情的机会，提供更好的用户体验，让我们的软件免受顺序链的影响，而阻塞编程。\n\n下表列出的与.NET 枚举相关的.NET Observable\n\n| .NET Observable| 一个返回值| 多个返回值 |\n| ------------- |:-------------:| -----:|\n| Pull/Synchronous/Interactive|`T`| `IEnumerable` |\n| Push/Asynchronous/Reactive| `Task`|`IObservable`|\n\npush方法把这个问题逆转了：取而代之的是不再等待结果，开发者只是简单的请求结果，而当它返回时得到一个通知即可。开发者对即将发生的事件提供一个清晰的响应链。对于每一个事件，开发者都作出相应的响应；例如，用户被要求登录的时候，提交一个携带他的用户名和密码的表单。应用程序执行登录的网络请求，接下来将要发生的情况有：\n\n* 显示一个成功的信息，并保存用户的个人信息。\n* 显示一个错误的信息\n\n正如你用push方法所看到的，开发者不需要等待结果。而是在结果返回时通知他。在这期间，他可以做他想做的任何事情：\n\n* 显示一个进度对话框\n* 为下次登录保存用户名和密码\n* 预加载一些他认为登录成功后需要耗时处理的事情\n\n## 来到Java世界 - Netflix RxJava\n\nNetflix在2012年开始意识到他们的架构要满足他们庞大的用户群体已经变得步履维艰。因此他们决定重新设计架构来减少REST调用的次数。取代几十次的REST调用，而是让客户端自己处理需要的数据，他们决定基于客户端需求创建一个专门优化过的REST调用。\n\n为了实现这一目标，他们决定尝试响应式，开始将.NET Rx迁移到JVM上面。他们不想只基于Java语言；而是整个JVM，从而有可能为市场上的每一种基于JVM的语言：如Java、Closure、Groovy、Scala等等提供一种新的工具。\n\n2013年二月份,Ben Christensen 和 Jafar Husain发在Netflix技术博客的一篇文章第一次向世界展示了RxJava。\n\n主要特点有：\n\n* 易于并发从而更好的利用服务器的能力。\n* 易于有条件的异步执行。\n* 一种更好的方式来避免回调地狱。\n* 一种响应式方法。\n\n\n正如.NET,RxJava Observable 是push 迭代的等价体，即pull。pull方法是阻塞并等待的方法：消费者从源头pull值，并阻塞线程直到生产者提供新的值。\n\npush方法作用于订阅和响应：消费者订阅新值的发射，当它们可用时生产者push这些新值并通知消费者。在这一点上，消费者消费了它们。push方法很明显更灵活，因为从逻辑和实践的观点来看，开发者只需忽略他需要的数据是来自同步还是异步；他的代码将仍然起作用。\n\n\n## RxJava的与众不同之处\n\n从纯Java的观点看，RxJava Observable类源自于经典的Gang Of Four的观察者模式。\n\n它添加了三个缺少的功能：\n\n* 生产者在没有更多数据可用时能够发出信号通知：onCompleted()事件。\n* 生产者在发生错误时能够发出信号通知：onError()事件。\n* RxJava Observables 能够组合而不是嵌套，从而避免开发者陷入回调地狱。\n\n\nObservables和Iterables共用一个相似的API：我们在Iterable可以执行的许多操作也都同样可以在Observables上执行。当然，由于Observables流的本质，没有如Iterable.remove()这样相应的方法。\n\n| Pattern| 一个返回值| 多个返回值 |\n| ------------- |:-------------:| -----:|\n| Synchronous|`T getData()`| `Iterable` |\n| Asynchronous| `Future getData()`|`Observable getData()`|\n\n从语义的角度来看，RxJava就是.NET Rx。从语法的角度来看，Netflix考虑到了对应每个Rx方法,保留了Java代码规范和基本的模式。\n\n## 总结\n\n本章中，我们初步探索了响应式的世界。从微软的.NET到Netflix的RxJava，我们了解了Rx是如何诞生的，我们也了解到传统的方法与响应式方法相比之间的相似和不同。\n\n下一章，我们将学习到Observables是什么，以及如何创建它并把响应式编程应用到我们的日常编码中去。\n" }, { "path": "rxjava/chap2.md", "content": "# RxJava开发精要2-为什么是Observables?\n\n> \n> * 原文出自《RxJava Essentials》\n* 原文作者 : [Ivan Morgillo](https://www.packtpub.com/books/info/authors/ivan-morgillo)\n* 译文出自 : [开发技术前线 www.devtf.cn](http://www.devtf.cn)\n* 转载声明: 本译文已授权[开发者头条](http://toutiao.io/download)享有独家转载权，未经允许，不得转载!\n* 译者 : [yuxingxin](https://github.com/yuxingxin) \n* 项目地址 : [RxJava-Essentials-CN](https://github.com/yuxingxin/RxJava-Essentials-CN)\n\n## 为什么是Observables?\n\n在面向对象的架构中，开发者致力于创建一组解耦的实体。这样的话，实体就可以在不用妨碍整个系统的情况下可以被测试、复用和维护。设计这种系统就带来一个棘手的负面影响：维护相关对象之间的统一。\n\n在Smalltalk MVC架构中，创建模式的第一个例子就是用来解决这个问题的。用户界面框架提供一种途径使UI元素与包含数据的实体对象相分离，并且同时，它提供一种灵活的方法来保持它们之间的同步。\n\n在这本畅销的四人组编写的《设计模式——可复用面向对象软件的基础》一书中，观察者模式是最有名的设计模式之一。它是一种行为模式并提供一种以一对多的依赖来绑定对象的方法：即当一个对象发生变化时，依赖它的所有对象都会被通知并且会自动更新。\n\n在本章中，我们将会对观察者模式有一个概述，它是如何实现的以及如何用RxJava来扩展，Observable是什么，以及Observables如何与Iterables相关联。\n\n\n## 观察者模式\n\n在今天，观察者模式是出现的最常用的软件设计模式之一。它基于subject这个概念。subject是一种特殊对象，当它改变时，那些由它保存的一系列对象将会得到通知。而这一系列对象被称作Observers,它们会对外暴漏了一个通知方法,当subject状态发生变化时会调用的这个方法。\n\n在上一章中，我们看到了电子表单的例子。现在我们可以展开这个例子讲，展示一个更复杂的场景。让我们考虑这样一个填着账户数据的电子表单。我们可以把这些数据比作一张表，或者是3D柱状图，或者是饼状图。它们中每一个代表的意义都取决于同一组要展示的数据。每一个都是一个观察者，都依赖于那一个subject，维护着全部信息。\n\n3D柱状图这个类、饼状图类、表这个类以及维护这些数据的类是完全解耦的：它们彼此相互独立复用，但也能协同工作。这些表示类彼此不清楚对方，但是正如它们所做的：它们知道在哪能找到它们需要展示的信息，它们也知道一旦数据发生变化就通知需要更新数据表示的那个类。\n\n这有一张图描述了Subject/Observer的关系是怎样的一对多的关系：\n\n![](https://github.com/yuxingxin/RxJava-Essentials-CN/raw/master/images/chapter2_1.png)\n\n上面这张图展示了一个Subject为3个Observers提供服务。很明显，没有理由去限制Observers的数量：如果有需要，一个Subject可以有无限多个Observers,当subject状态发生变化时，这些Observers中的每一个都会收到通知。\n\n## 你什么时候使用观察者模式？\n\n观察者模式很适合下面这些场景中的任何一个：\n\n* 当你的架构有两个实体类，一个依赖另一个，你想让它们互不影响或者是独立复用它们时。\n* 当一个变化的对象通知那些与它自身变化相关联的未知数量的对象时。\n* 当一个变化的对象通知那些无需推断具体类型的对象时。\n\n\n## RxJava观察者模式工具包\n\n在RxJava的世界里，我们有四种角色：\n* Observable\n* Observer\n* Subscriber\n* Subjects\n\nObservables和Subjects是两个“生产”实体，Observers和Subscribers是两个“消费”实体。\n\n## Observable\n\n当我们异步执行一些复杂的事情，Java提供了传统的类，例如Thread、Future、FutureTask、CompletableFuture来处理这些问题。当复杂度提升，这些方案就会变得麻烦和难以维护。最糟糕的是，它们都不支持链式调用。\n\nRxJava Observables被设计用来解决这些问题。它们灵活，且易于使用，也可以链式调用，并且可以作用于单个结果程序上，更有甚者，也可以作用于序列上。无论何时你想发射单个标量值，或者一连串值，甚至是无穷个数值流，你都可以使用Observable。\n\nObservable的生命周期包含了三种可能的易于与Iterable生命周期事件相比较的事件，下表展示了如何将Observable async/push 与 Iterable sync/pull相关联起来。\n\n| Event| Iterable(pull)|Observable(push)|\n| ------------- |:-------------:| -----:|\n| 检索数据|`T next()`| `onNext(T)` |\n| 发现错误| `throws Exception`|`onError(Throwable)`|\n| 完成 |`!hasNext()`|`onCompleted()`|\n\n使用Iterable时，消费者从生产者那里以同步的方式得到值，在这些值得到之前线程处于阻塞状态。相反，使用Observable时，生产者以异步的方式把值推给观察者，无论何时，这些值都是可用的。这种方法之所以更灵活是因为即便值是同步或异步方式到达，消费者在这两种场景都可以根据自己的需要来处理。\n\n为了更好地复用Iterable接口，RxJava Observable类扩展了GOF观察者模式的语义。引入了两个新的接口：\n* onCompleted() 即通知观察者Observable没有更多的数据。\n* onError() 即观察者有错误出现了。\n\n\n### 热Observables和冷Observables\n\n从发射物的角度来看，有两种不同的Observables:热的和冷的。一个\"热\"的Observable典型的只要一创建完就开始发射数据，因此所有后续订阅它的观察者可能从序列中间的某个位置开始接受数据（有一些数据错过了）。一个\"冷\"的Observable会一直等待，直到有观察者订阅它才开始发射数据，因此这个观察者可以确保会收到整个数据序列。\n\n### 创建一个Observable\n\n在接下来的小节中将讨论Observables提供的两种创建Observable的方法。\n\n#### Observable.create()\n\ncreate()方法使开发者有能力从头开始创建一个Observable。它需要一个OnSubscribe对象,这个对象继承Action1,当观察者订阅我们的Observable时，它作为一个参数传入并执行call()函数。\n```java\nObservable.create(new Observable.OnSubscribe(){\n @Override\n public void call(Subscriber subscriber) {\n \n }\n});\n```\nObservable通过使用subscriber变量并根据条件调用它的方法来和观察者通信。让我们看一个“现实世界”的例子：\n```java\nObservable observableString = Observable.create(new Observable.OnSubscribe() {\n @Override\n public void call(Subscriber observer) {\n for (int i = 0; i < 5; i++) {\n observer.onNext(i);\n }\n observer.onCompleted();\n }\n});\n\nSubscription subscriptionPrint = observableString.subscribe(new Observer() {\n @Override\n public void onCompleted() {\n System.out.println(\"Observable completed\");\n }\n\n @Override\n public void onError(Throwable e) {\n System.out.println(\"Oh,no! Something wrong happened！\");\n }\n\n @Override\n public void onNext(Integer item) {\n System.out.println(\"Item is \" + item);\n }\n});\n```\n例子故意写的简单，是因为即便是你第一次见到RxJava的操作，我想让你明白接下来要发生什么。\n\n我们创建一个新的`Observable`,它执行了5个元素的for循环，一个接一个的发射他们，最后完成。\n\n另一方面，我们订阅了Observable，返回一个Subscription\n。一旦我们订阅了，我们就开始接受整数，并一个接一个的打印出它们。我们并不知道要接受多少整数。事实上，我们也无需知道是因为我们为每种场景都提供对应的处理操作：\n* 如果我们接收到了整数，那么就打印它。\n* 如果序列结束，我们就打印一个关闭的序列信息。\n* 如果错误发生了，我们就打印一个错误信息。\n\n#### Observable.from()\n\n在上一个例子中，我们创建了一个整数序列并一个一个的发射它们。假如我们已经有一个列表呢？我们是不是可以不用for循环而也可以一个接一个的发射它们呢？\n\n在下面的例子代码中，我们从一个已有的列表中创建一个Observable序列：\n```java\nList items = new ArrayList();\nitems.add(1);\nitems.add(10);\nitems.add(100);\nitems.add(200);\n\nObservable observableString = Observable.from(items);\nSubscription subscriptionPrint = observableString.subscribe(new Observer() {\n @Override\n public void onCompleted() {\n System.out.println(\"Observable completed\");\n }\n\n @Override\n public void onError(Throwable e) {\n System.out.println(\"Oh,no! Something wrong happened！\");\n }\n\n @Override\n public void onNext(Integer item) {\n System.out.println(\"Item is \" + item);\n }\n});\n```\n\n输出的结果和上面的例子绝对是一样的。\n\n`from()`创建符可以从一个列表/数组来创建Observable,并一个接一个的从列表/数组中发射出来每一个对象，或者也可以从Java `Future`类来创建Observable，并发射Future对象的`.get()`方法返回的结果值。传入`Future`作为参数时，我们可以指定一个超时的值。Observable将等待来自`Future`的结果；如果在超时之前仍然没有结果返回，Observable将会触发`onError()`方法通知观察者有错误发生了。\n\n#### Observable.just()\n\n如果我们已经有了一个传统的Java函数，我们想把它转变为一个Observable又改怎么办呢？我们可以用`create()`方法，正如我们先前看到的，或者我们也可以像下面那样使用以此来省去许多模板代码：\n```java\nObservable observableString = Observable.just(helloWorld());\n\nSubscription subscriptionPrint = observableString.subscribe(new Observer() {\n @Override\n public void onCompleted() {\n System.out.println(\"Observable completed\");\n }\n\n @Override\n public void onError(Throwable e) {\n System.out.println(\"Oh,no! Something wrong happened!\");\n }\n\n @Override\n public void onNext(String message) {\n System.out.println(message);\n }\n});\n```\n\n`helloWorld()`方法比较简单，像这样：\n```java\nprivate String helloWorld(){\n return \"Hello World\";\n}\n```\n\n不管怎样，它可以是我们想要的任何函数。在刚才的例子中，我们一旦创建了Observable，`just()`执行函数，当我们订阅Observable时，它就会发射出返回的值。\n\n`just()`方法可以传入一到九个参数，它们会按照传入的参数的顺序来发射它们。`just()`方法也可以接受列表或数组，就像`from()`方法，但是它不会迭代列表发射每个值,它将会发射整个列表。通常，当我们想发射一组已经定义好的值时会用到它。但是如果我们的函数不是时变性的，我们可以用just来创建一个更有组织性和可测性的代码库。\n\n最后注意`just()`创建符，它发射出值后，Observable正常结束，在上面那个例子中，我们会在控制台打印出两条信息：“Hello World”和“Observable completed”。\n\n#### Observable.empty(),Observable.never(),和Observable.throw()\n\n当我们需要一个Observable毫无理由的不再发射数据正常结束时，我们可以使用`empty()`。我们可以使用`never()`创建一个不发射数据并且也永远不会结束的Observable。我们也可以使用`throw()`创建一个不发射数据并且以错误结束的Observable。\n\n\n## Subject = Observable + Observer\n\n`subject`是一个神奇的对象，它可以是一个Observable同时也可以是一个Observer：它作为连接这两个世界的一座桥梁。一个Subject可以订阅一个Observable，就像一个观察者，并且它可以发射新的数据，或者传递它接受到的数据，就像一个Observable。很明显，作为一个Observable，观察者们或者其它Subject都可以订阅它。\n\n一旦Subject订阅了Observable，它将会触发Observable开始发射。如果原始的Observable是“冷”的，这将会对订阅一个“热”的Observable变量产生影响。\n\nRxJava提供四种不同的Subject：\n* PublishSubject\n* BehaviorSubject\n* ReplaySubject.\n* AsyncSubject\n\n### PublishSubject\n\nPublish是Subject的一个基础子类。让我们看看用PublishSubject实现传统的Observable `Hello World`:\n```java\nPublishSubject stringPublishSubject = PublishSubject.create();\nSubscription subscriptionPrint = stringPublishSubject.subscribe(new Observer() {\n @Override\n public void onCompleted() {\n System.out.println(\"Observable completed\");\n }\n\n @Override\n public void onError(Throwable e) {\n System.out.println(\"Oh,no!Something wrong happened!\"); \n }\n\n @Override\n public void onNext(String message) {\n System.out.println(message);\n }\n});\nstringPublishSubject.onNext(\"Hello World\");\n```\n\n在刚才的例子中，我们创建了一个`PublishSubject`，用`create()`方法发射一个`String`值，然后我们订阅了PublishSubject。此时，没有数据要发送，因此我们的观察者只能等待，没有阻塞线程，也没有消耗资源。就在这随时准备从subject接收值，如果subject没有发射值那么我们的观察者就会一直在等待。再次声明的是，无需担心：观察者知道在每个场景中该做什么，我们不用担心什么时候是因为它是响应式的：系统会响应。我们并不关心它什么时候响应。我们只关心它响应时该做什么。\n\n最后一行代码展示了手动发射字符串“Hello World”,它触发了观察者的`onNext()`方法，让我们在控制台打印出“Hello World”信息。\n\n让我们看一个更复杂的例子。话说我们有一个`private`声明的Observable，外部不能访问。Observable在它生命周期内发射值，我们不用关心这些值，我们只关心他们的结束。\n\n首先，我们创建一个新的PublishSubject来响应它的`onNext()`方法，并且外部也可以访问它。\n\n```java\nfinal PublishSubject subject = PublishSubject.create();\n \nsubject.subscribe(new Observer() {\n @Override\n public void onCompleted() {\n \n }\n\n @Override\n public void onError(Throwable e) {\n\n }\n\n @Override\n public void onNext(Boolean aBoolean) {\n System.out.println(\"Observable Completed\");\n }\n});\n```\n然后，我们创建“私有”的Observable，只有subject才可以访问的到。\n```java\nObservable.create(new Observable.OnSubscribe() {\n @Override\n public void call(Subscriber subscriber) {\n for (int i = 0; i < 5; i++) {\n subscriber.onNext(i);\n }\n subscriber.onCompleted();\n }\n}).doOnCompleted(new Action0() {\n @Override\n public void call() {\n subject.onNext(true);\n }\n}).subscribe();\n```\n`Observable.create()`方法包含了我们熟悉的for循环，发射数字。`doOnCompleted()`方法指定当Observable结束时要做什么事情：在subject上发射true。最后，我们订阅了Observable。很明显，空的`subscribe()`调用仅仅是为了开启Observable，而不用管已发出的任何值，也不用管完成事件或者错误事件。为了这个例子我们需要它像这样。\n\n在这个例子中，我们创建了一个可以连接Observables并且同时可被观测的实体。当我们想为公共资源创建独立、抽象或更易观测的点时，这是极其有用的。\n\n### BehaviorSubject\n\n简单的说，BehaviorSubject会首先向他的订阅者发送截至订阅前最新的一个数据对象（或初始值）,然后正常发送订阅后的数据流。\n\n```java\nBehaviorSubject behaviorSubject = BehaviorSubject.create(1);\n```\n在这个短例子中，我们创建了一个能发射整形(Integer)的BehaviorSubject。由于每当Observes订阅它时就会发射最新的数据，所以它需要一个初始值。\n### ReplaySubject\n\nReplaySubject会缓存它所订阅的所有数据,向任意一个订阅它的观察者重发:\n```java\nReplaySubject replaySubject = ReplaySubject.create();\n```\n\n### AsyncSubject\n\n当Observable完成时AsyncSubject只会发布最后一个数据给已经订阅的每一个观察者。\n\n```java\nAsyncSubject asyncSubject = AsyncSubject.create();\n```\n\n## 总结\n\n本章中，我们了解到了什么是观察者模式，为什么Observables在今天的编程场景中如此重要，以及如何创建Observables和subjects。\n\n下一章中，我们将创建第一个基于RxJava的Android应用程序，学习如何检索数据来填充listview，以及探索如何创建一个基于RxJava的响应式UI。" }, { "path": "rxjava/chap3.md", "content": "\n# RxJava开发精要3-向响应式世界问好\n\n> \n> * 原文出自《RxJava Essentials》\n* 原文作者 : [Ivan Morgillo](https://www.packtpub.com/books/info/authors/ivan-morgillo)\n* 译文出自 : [开发技术前线 www.devtf.cn](http://www.devtf.cn)\n* 转载声明: 本译文已授权[开发者头条](http://toutiao.io/download)享有独家转载权，未经允许，不得转载!\n* 译者 : [yuxingxin](https://github.com/yuxingxin) \n* 项目地址 : [RxJava-Essentials-CN](https://github.com/yuxingxin/RxJava-Essentials-CN)\n\n## 向响应式世界问好\n\n在上一章中，我们对观察者模式有个理论上的快速概述。我们也看了从头开始、从列表、或者从已经存在的函数来创建Observables。在本章中，我们将用我们学到的来创建我们第一个响应式Android应用程序。首先，我们需要搭建环境，导入需要的库和有用的库。然后我们将创建一个简单的应用程序，在不同的flavors中包含几个用RxJava填充的RecycleView items。\n\n\n## 启动引擎\n\n我们将使用IntelliJ IDEA/Android Studio来创建这个工程，因此你会对截图看起来比较熟悉。\n\n让我们开始创建一个新的Android工程。你可以创建你自己的工程或者用本书中提供的导入。选择你自己喜欢的创建方式这取决于你。\n\n如果你想用Android Studio创建一个新的工程，通常你可以参考官方文档：http://developer.android.com/intl/zh-cn/training/basics/firstapp/creating-project.html\n\n![](https://github.com/yuxingxin/RxJava-Essentials-CN/raw/master/images/chapter3_1.png)\n\n### 依赖\n\n很明显，我们将使用**Gradle**来管理我们的依赖列表。我们的build.gradble文件看起来像这样：\n ![](https://github.com/yuxingxin/RxJava-Essentials-CN/raw/master/images/chapter3_2.png)\n ![](https://github.com/yuxingxin/RxJava-Essentials-CN/raw/master/images/chapter3_3.png)\n正如你看到的我们引入了RxAndroid。RxAndroid是RxJava的增强版，尤其是针对Android设计的。\n### RxAndroid\n\nRxAndroid是RxJava家族的一部分。它基于RxJava1.0.x,在普通的RxJava基础上添加了几个有用的类。大多数情况下，它为Android添加了特殊的调度器。我们将在第七章Schedulers-Defeating the Android MainThread Issue再讨论它。\n\n## 工具\n\n出于实用，我们引入了Lombok 和 Butter Knife。这两个可以帮助我们在Android应用程序中少写许多模板类代码。\n\n### Lombok\n\nLombok使用注解的方式为你生成许多代码。我们将使用它老生成`getter/setter`、`toString()`、`equals()`、`hashCode()`。它借助于Gradle依赖和一个Android Studio插件。\n\n### Butter Knife\n\nButter Knife使用注解的方式来帮助我们免去写`findViewById()`和设置点击监听的痛苦。至于Lombok,我们可以通过导入依赖和安装Android Studio插件来获得更好的体验。\n\n### Retrolambda\n\n最后，我们导入Retrolambda，是因为我们开发的Android是基于Java 1.6，然后我们可以借助它来实现Java 8 Lambda函数从而减少许多模板代码。\n\n\n## 我们的第一个Observable\n\n在我们的第一个列子里，我们将检索安装的应用列表并填充RecycleView的item来展示它们。我们也设想一个下拉刷新的功能和一个进度条来告知用户当前任务正在执行。\n\n首先，我们创建Observable。我们需要一个函数来检索安装的应用程序列表并把它提供给我们的观察者。我们一个接一个的发射这些应用程序数据，将它们分组到一个单独的列表中，以此来展示响应式方法的灵活性。\n\n```java\nprivate Observable getApps(){\n return Observable.create(subscriber -> {\n List apps = new ArrayList();\n\n final Intent mainIntent = new Intent(Intent.ACTION_MAIN,null);\n mainIntent.addCategory(Intent.CATEGORY_LAUNCHER);\n\n List infos = getActivity().getPackageManager().queryIntentActivities(mainIntent, 0);\n\n for(ResolveInfo info : infos){\n apps.add(new AppInfoRich(getActivity(),info));\n }\n\n for (AppInfoRich appInfo:apps) {\n Bitmap icon = Utils.drawableToBitmap(appInfo.getIcon());\n String name = appInfo.getName();\n String iconPath = mFilesDir + \"/\" + name;\n Utils.storeBitmap(App.instance, icon,name);\n \n if (subscriber.isUnsubscribed()){\n return;\n }\n subscriber.onNext(new AppInfo(name,iconPath,appInfo.getLastUpdateTime())); \n }\n if (!subscriber.isUnsubscribed()){\n subscriber.onCompleted();\n }\n });\n}\n```\nAppInfo对象如下：\n\n```java\n@Data\n@Accessors(prefix = \"m\")\npublic class AppInfo implements Comparable {\n\n long mLastUpdateTime;\n String mName;\n String mIcon;\n\n public AppInfo(String nName, long lastUpdateTime, String icon) {\n mName = nName;\n mIcon = icon;\n mLastUpdateTime = lastUpdateTime;\n }\n\n @Override\n public int compareTo(Object another) {\n AppInfo f = (AppInfo)another;\n return getName().compareTo(f.getName());\n }\n}\n```\n需要重点注意的是在发射新的数据或者完成序列之前要检测观察者的订阅情况。这样的话代码会更高效，因为如果没有观察者等待时我们就不生成没有必要的数据项。\n\n此时，我们可以订阅Observable并观察它。订阅一个Observable意味着当我们需要的数据进来时我们必须提供对应的操作来执行它。\n\n当前的场景是什么？我们展示一个进度条来等待数据。当数据到来时，我们需要隐藏掉进度条,填充list,最终展示列表。现在，我们知道当一切都准备好了该做什么。那么错误的场景呢？对于错误这种情况，我们仅仅是用Toast展示一个错误的信息。\n\n使用Butter Knife,我们得到list和下拉刷新组件的引用：\n\n```java\n@InjetcView(R.id.fragment_first_example_list)\nRecyclerView mRecycleView;\n \n@InjectView(R.id.fragment_first_example_swipe_container)\nSwipeRefreshLayout mSwipeRefreshLayout;\n```\n\n我们使用Android 5的标准组件：RecyclerView和SwipeRefreshLayout。截屏展示了我们这个简单App的list Fragment的layout文件：\n\n![](https://github.com/yuxingxin/RxJava-Essentials-CN/raw/master/images/chapter3_4.png)\n\n我们使用一个下拉刷新方法，因此列表数据可以来自初始化加载，或由用户触发的一个刷新动作。针对这两个场景，我们用同样的行为，因此我们把我们的观察者放在一个易被复用的函数里面。下面是我们的观察者，定义了成功、失败、完成要做的事情：\n\n```java\nprivate void refreshTheList() {\n getApps().toSortedList()\n .subscribe(new Observable>() {\n\n @Override\n public void onCompleted() {\n Toast.makeText(getActivity(), \"Here is the list!\", Toast.LENGTH_LONG).show();\n }\n\n @Override\n public void onError(Throwable e) {\n Toast.makeText(getActivity(), \"Something went wrong!\", Toast.LENGTH_SHORT).show();\n mSwipeRefreshLayout.setRefreshing(false);\n }\n\n @Override\n public void onNext(List appInfos) {\n mRecyclerView.setVisibility(View.VISIBLE);\n mAdapter.addApplications(appInfos);\n mSwipeRefreshLayout.setRefreshing(false);\n }\n });\n}\n```\n\n定义一个函数使我们能够用同样一个block来处理两种场景成为了可能。当fragment加载时我们只需调用`refreshTheList()`方法并设置`refreshTheList()`方法作为用户下拉这一行为所触发的方法。\n\n```java\nmSwipeRefreshLayout.setOnRefreshListener(this::refreshTheList);\n```\n\n我们第一个例子现在完成了，运行跑一下。\n\n![](https://github.com/yuxingxin/RxJava-Essentials-CN/raw/master/images/chapter3_5.png)\n\n\n## 从列表创建一个Observable\n\n在这个例子中，我们将引入`from()`函数。使用这个特殊的“创建”函数，我们可以从一个列表中创建一个Observable。Observable将发射出列表中的每一个元素，我们可以通过订阅它们来对这些发出的元素做出响应。\n\n为了实现和第一个例子同样的结果，我们在每一个`onNext()`函数更新我们的适配器，添加元素并通知插入。\n\n我们将复用和第一个例子同样的结构。主要的不同的是我们不再检索已安装的应用列表。列表由外部实体提供：\n\n```java\nmApps = ApplicationsList.getInstance().getList();\n```\n获得列表后，我们仅需将它响应化并填充RecyclerView的item:\n```java\nprivate void loadList(List apps) {\n mRecyclerView.setVisibility(View.VISIBLE);\n Observable.from(apps)\n .subscribe(new Observable() {\n\n @Override\n public void onCompleted() {\n mSwipeRefreshLayout.setRefreshing(false);\n Toast.makeText(getActivity(), \"Here is the list!\", Toast.LENGTH_LONG).show();\n }\n\n @Override\n public void onError(Throwable e) {\n Toast.makeText(getActivity(), \"Something went wrong!\", Toast.LENGTH_SHORT).show();\n mSwipeRefreshLayout.setRefreshing(false);\n }\n\n @Override\n public void onNext(AppInfo appInfo) {\n mAddedApps.add(appInfo); \n mAdapter.addApplication(mAddedApps.size() - 1,appInfo);\n }\n });\n}\n```\n正如你看到的，我们将已安装的应用程序列表作为参数传进`from()`函数，然后我们订阅生成的Observable。观察者和我们第一个例子中的观察者十分相像。一个主要的不同是我们在`onCompleted()`函数中停掉进度条是因为我们一个一个的发射元素；第一个例子中的Observable发射的是整个list,因此在`onNext()`函数中停掉进度条的做法是安全的。\n\n\n\n## 再多几个例子\n\n在这一节中，我们将基于RxJava的`just()`,`repeat()`,`defer()`,`range()`,`interval()`,和`timer()`方法展示一些例子。\n\n### just()\n\n假如我们只有3个独立的AppInfo对象并且我们想把他们转化为Observable并填充到RecyclerView的item中：\n```java\nList apps = ApplicationsList.getInstance().getList();\n\nAppInfo appOne = apps.get(0);\n\nAppInfo appTwo = apps.get(10);\n\nAppInfo appThree = apps.get(24);\n\nloadApps(appOne,appTwo,appThree);\n\n```\n\n我们可以像我们之前的例子那样检索列表并提取出这三个元素。然后我们将他们传到这个`loadApps()`函数里面：\n```java\nprivate void loadApps(AppInfo appOne,AppInfo appTwo,AppInfo appThree) {\n mRecyclerView.setVisibility(View.VISIBLE);\n Observable.just(appOne,appTwo,appThree)\n .subscribe(new Observable() {\n\n @Override\n public void onCompleted() {\n mSwipeRefreshLayout.setRefreshing(false);\n Toast.makeText(getActivity(), \"Here is the list!\", Toast.LENGTH_LONG).show();\n }\n\n @Override\n public void onError(Throwable e) {\n Toast.makeText(getActivity(), \"Something went wrong!\", Toast.LENGTH_SHORT).show();\n mSwipeRefreshLayout.setRefreshing(false);\n }\n\n @Override\n public void onNext(AppInfo appInfo) {\n mAddedApps.add(appInfo); \n mAdapter.addApplication(mAddedApps.size() - 1,appInfo);\n }\n });\n}\n```\n\n正如你看到的，代码和之前的例子很像。这种方法让我们有机会来考虑一下代码的复用。\n\n你可以将一个函数作为参数传给`just()`方法，你将会得到一个已存在代码的原始Observable版本。在一个新的响应式架构的基础上迁移已存在的代码，这个方法可能是一个有用的开始点。\n\n\n### repeat()\n\n假如你想对一个Observable重复发射三次数据。例如，我们用`just()`例子中的Observable：\n\n```java\nprivate void loadApps(AppInfo appOne,AppInfo appTwo,AppInfo appThree) {\n mRecyclerView.setVisibility(View.VISIBLE);\n Observable.just(appOne,appTwo,appThree)\n .repeat(3)\n .subscribe(new Observable() {\n\n @Override\n public void onCompleted() {\n mSwipeRefreshLayout.setRefreshing(false);\n Toast.makeText(getActivity(), \"Here is the list!\", Toast.LENGTH_LONG).show();\n }\n\n @Override\n public void onError(Throwable e) {\n Toast.makeText(getActivity(), \"Something went wrong!\", Toast.LENGTH_SHORT).show();\n mSwipeRefreshLayout.setRefreshing(false);\n }\n\n @Override\n public void onNext(AppInfo appInfo) {\n mAddedApps.add(appInfo); \n mAdapter.addApplication(mAddedApps.size() - 1,appInfo);\n }\n });\n}\n```\n正如你看到的，我们在`just()`创建Observable后追加了`repeat(3)`，它将会创建9个元素的序列，每一个都单独发射。\n\n### defer()\n\n有这样一个场景，你想在这声明一个Observable但是你又想推迟这个Observable的创建直到观察者订阅时。看下面的`getInt()`函数：\n```java\nprivate Observable getInt(){\n return Observable.create(subscriber -> {\n if(subscriber.isUnsubscribed()){\n return;\n }\n App.L.debug(\"GETINT\");\n subscriber.onNext(42);\n subscriber.onCompleted();\n });\n}\n```\n\n这比较简单，并且它没有做太多事情，但是它正好为我们服务。现在，我们可以创建一个新的Observable并且应用`defer()`:\n\n```java\nObservable deferred = Observable.defer(this::getInt);\n```\n这次，`deferred`存在，但是`getInt()` `create()`方法还没有调用:logcat日志也没有“GETINT”打印出来:\n\n```java\ndeferred.subscribe(number -> {\n App.L.debug(String.valueOf(number));\n});\n```\n但是一旦我们订阅了，`create()`方法就会被调用并且我们也可以在logcat日志中得到下卖弄两个：GETINT和42。\n\n### range()\n\n你需要从一个指定的数字X开始发射N个数字吗？你可以用`range`:\n```java\nObservable.range(10,3)\n .subscribe(new Observable() {\n\n @Override\n public void onCompleted() {\n Toast.makeText(getActivity(), \"Yeaaah!\", Toast.LENGTH_LONG).show();\n }\n\n @Override\n public void onError(Throwable e) {\n Toast.makeText(getActivity(), \"Something went wrong!\", Toast.LENGTH_SHORT).show();\n }\n\n @Override\n public void onNext(Integer number) {\n Toast.makeText(getActivity(), \"I say \" + number, Toast.LENGTH_SHORT).show();\n }\n });\n```\n\n`range()`函数用两个数字作为参数：第一个是起始点，第二个是我们想发射数字的个数。\n\n\n### interval()\n\n`interval()`函数在你需要创建一个轮询程序时非常好用。\n```java\nSubscription stopMePlease = Observable.interval(3,TimeUnit.SECONDS)\n .subscribe(new Observable() {\n\n @Override\n public void onCompleted() {\n Toast.makeText(getActivity(), \"Yeaaah!\", Toast.LENGTH_LONG).show();\n }\n\n @Override\n public void onError(Throwable e) {\n Toast.makeText(getActivity(), \"Something went wrong!\", Toast.LENGTH_SHORT).show();\n }\n\n @Override\n public void onNext(Integer number) {\n Toast.makeText(getActivity(), \"I say \" + number, Toast.LENGTH_SHORT).show();\n }\n });\n```\n`interval()`函数的两个参数：一个指定两次发射的时间间隔，另一个是用到的时间单位。\n\n\n### timer()\n\n如果你需要一个一段时间之后才发射的Observable，你可以像下面的例子使用`timer()`：\n\n```java\nObservable.timer(3,TimeUnit.SECONDS)\n .subscribe(new Observable() {\n\n @Override\n public void onCompleted() {\n \n }\n\n @Override\n public void onError(Throwable e) {\n \n }\n\n @Override\n public void onNext(Long number) {\n Log.d(\"RXJAVA\", \"I say \" + number);\n }\n });\n```\n它将3秒后发射0,然后就完成了。让我们使用`timer()`的第三个参数，就像下面的例子：\n```java\nObservable.timer(3,3,TimeUnit.SECONDS)\n .subscribe(new Observable() {\n\n @Override\n public void onCompleted() {\n \n }\n\n @Override\n public void onError(Throwable e) {\n \n }\n\n @Override\n public void onNext(Long number) {\n Log.d(\"RXJAVA\", \"I say \" + number);\n }\n });\n```\n用这个代码，你可以创建一个以初始值来延迟（上一个例子是3秒）执行的`interval()`版本，然后每隔N秒就发射一个新的数字（前面的例子是3秒）。\n\n\n## 总结\n\n在本章中，我们创建了第一个由RxJava强化的Android应用程序。我们从头、从已有的列表、从已有的函数来创建Observable。我们也学习了如何创建重复发射的Observables，间隔发射的Observables以及延迟发射的Observables。\n\n在下一章中，我们将掌握过滤操作，能够从我们接收到的序列中创建我们需要的序列。\n" }, { "path": "rxjava/chap4.md", "content": "# RxJava开发精要4 - Observables过滤\n\n> \n> * 原文出自《RxJava Essentials》\n* 原文作者 : [Ivan Morgillo](https://www.packtpub.com/books/info/authors/ivan-morgillo)\n* 译文出自 : [开发技术前线 www.devtf.cn](http://www.devtf.cn)\n* 转载声明: 本译文已授权[开发者头条](http://toutiao.io/download)享有独家转载权，未经允许，不得转载!\n* 译者 : [yuxingxin](https://github.com/yuxingxin) \n* 项目地址 : [RxJava-Essentials-CN](https://github.com/yuxingxin/RxJava-Essentials-CN)\n\n## 过滤Observables\n\n在上一章中，我们学习了使用RxJava创建一个Android工程以及如何创建一个可观测的列表来填充RecyclerView。我们现在知道了如何从头、从列表、从一个已存在的传统Java函数来创建Observable。\n\n这一章中，我们将研究可观测序列的本质：过滤。我们将学到如何从发射的Observable中选取我们想要的值，如何获取有限个数的值，如何处理溢出的场景，以及更多的有用的技巧。\n\n## 过滤序列\n\nRxJava让我们使用`filter()`方法来过滤我们观测序列中不想要的值，在上一章中，我们在几个例子中使用了已安装的应用列表，但是我们只想展示以字母`C`开头的已安装的应用该怎么办呢？在这个新的例子中，我们将使用同样的列表，但是我们会过滤它，通过把合适的谓词传给`filter()`函数来得到我们想要的值。\n\n上一章中`loadList()`函数可以改成这样：\n```java\nprivate void loadList(List apps) {\n mRecyclerView.setVisibility(View.VISIBLE);\n Observable.from(apps)\n .filter((appInfo) ->\n appInfo.getName().startsWith(\"C\"))\n .subscribe(new Observable() {\n\n @Override\n public void onCompleted() {\n mSwipeRefreshLayout.setRefreshing(false);\n }\n\n @Override\n public void onError(Throwable e) {\n Toast.makeText(getActivity(), \"Something went wrong!\", Toast.LENGTH_SHORT).show();\n mSwipeRefreshLayout.setRefreshing(false);\n }\n\n @Override\n public void onNext(AppInfo appInfo) {\n mAddedApps.add(appInfo); \n mAdapter.addApplication(mAddedApps.size() - 1,appInfo);\n }\n });\n}\n```\n我们从上一章中的`loadList()`函数中添加下面一行：\n```java\n.fliter((appInfo -> appInfo.getName().startsWith(\"C\"))\n```\n创建Observable完以后，我们从发出的每个元素中过滤掉开头字母不是C的。为了让这里更清楚一些，我们用Java 7的语法来实现：\n```java\n.filter(new Func1(){\n @Override\n public Boolean call(AppInfo appInfo){\n return appInfo.getName().startsWith(\"C\");\n }\n})\n```\n\n我们传一个新的`Func1`对象给`filter()`函数，即只有一个参数的函数。`Func1`有一个`AppInfo`对象来作为它的参数类型并且返回`Boolean`对象。只要条件符合`filter()`函数就会返回`true`。此时，值会发射出去并且所有的观察者都会接收到。\n\n正如你想的那样，从一个我们得到的可观测序列中创建一个我们需要的序列`filter()`是很好用的。我们不需要知道可观测序列的源或者为什么发射这么多不同的数据。我们只是想要这些元素的子集来创建一个可以在应用中使用的新序列。这种思想促进了我们编码中的分离性与抽象性。\n\n`filter()`函数最常用的用法之一时过滤`null`对象：\n```java\n.filter(new Func1(){\n @Override\n public Boolean call(AppInfo appInfo){\n return appInfo != null;\n }\n})\n```\n这看起来简单，对于简单的事情有许多模板代码，但是它帮我们免去了在`onNext()`函数调用中再去检测`null`值，让我们把注意力集中在应用业务逻辑上。\n\n下图展示了过滤出的C字母开头的已安装的应用列表。\n\n\n\n\n\n## 获取我们需要的数据\n\n当我们不需要整个序列时，而是只想取开头或结尾的几个元素，我们可以用`take()`或`takeLast()`。\n\n## Take\n\n如果我们只想要一个可观测序列中的前三个元素那将会怎么样，发射它们，然后让Observable完成吗？`take()`函数用整数N来作为一个参数，从原始的序列中发射前N个元素，然后完成：\n```java\nprivate void loadList(List apps) {\n mRecyclerView.setVisibility(View.VISIBLE);\n Observable.from(apps)\n .take(3)\n .subscribe(new Observable() {\n\n @Override\n public void onCompleted() {\n mSwipeRefreshLayout.setRefreshing(false);\n }\n\n @Override\n public void onError(Throwable e) {\n Toast.makeText(getActivity(), \"Something went wrong!\", Toast.LENGTH_SHORT).show();\n mSwipeRefreshLayout.setRefreshing(false);\n }\n\n @Override\n public void onNext(AppInfo appInfo) {\n mAddedApps.add(appInfo); \n mAdapter.addApplication(mAddedApps.size() - 1,appInfo);\n }\n });\n}\n```\n下图中展示了发射数字的一个可观测序列。我们对这个可观测序列应用`take(2)`函数，然后我们创建一个只发射可观测源的第一个和第二个数据的新序列。\n\n![](https://github.com/yuxingxin/RxJava-Essentials-CN/raw/master/images/chapter4_2.png)\n\n## TakeLast\n\n如果我们想要最后N个元素，我们只需使用`takeLast()`函数：\n```java\nObservable.from(apps)\n .takeLast(3)\n .subscribe(https://github.com/yuxingxin/RxJava-Essentials-CN/raw/master.);\n```\n正如听起来那样不值一提，重点注意`takeLast()`函数由于用一组有限的发射数的本质使得它仅可用于完成的序列。\n\n下图中展示了如何从可观测源中发射最后一个元素来创建一个新的序列：\n\n![](https://github.com/yuxingxin/RxJava-Essentials-CN/raw/master/images/chapter4_3.png)\n\n下图中展示了我们在已安装的应用列表使用`take()`和`takeLast()`函数后发生的结果：\n\n![](https://github.com/yuxingxin/RxJava-Essentials-CN/raw/master/images/chapter4_4.png)\n\n\n## 有且仅有一次\n\n一个可观测序列会在出错时重复发射或者被设计成重复发射。`distinct()`和`distinctUntilChanged()`函数可以方便的让我们处理这种重复问题。\n\n## Distinct\n\n如果我们想对一个指定的值仅处理一次该怎么办？我们可以对我们的序列使用`distinct()`函数去掉重复的。就像`takeLast()`一样，`distinct()`作用于一个完整的序列，然后得到重复的过滤项，它需要记录每一个发射的值。如果你在处理一大堆序列或者大的数据记得关注内存使用情况。\n\n下图展示了如何在一个发射1和2两次的可观测源上创建一个无重的序列：\n![](https://github.com/yuxingxin/RxJava-Essentials-CN/raw/master/images/chapter4_5.png)\n\n为了创建我们例子中序列，我们将使用我们至今已经学到的几个方法：\n* `take()`：它有一小组的可识别的数据项。\n* `repeat()`：创建一个有重复的大的序列。\n\n然后，我们将应用`distinct()`函数来去除重复。\n\n## 注意\n\n我们用程序实现一个重复的序列，然后过滤出它们。这听起来时不可思议的，但是为了实现这个例子来使用我们至今为止已学习到的东西则是个不错的练习。\n\n```java\nObservable fullOfDuplicates = Observable.from(apps)\n .take(3)\n .repeat(3);\n```\n`fullOfDuplicates`变量里把我们已安装应用的前三个重复了3次：有9个并且许多重复的。然后，我们使用`distinct()`:\n\n```java\nfullOfDuplicates.distinct()\n .subscribe(new Observable() {\n\n @Override\n public void onCompleted() {\n mSwipeRefreshLayout.setRefreshing(false);\n }\n\n @Override\n public void onError(Throwable e) {\n Toast.makeText(getActivity(), \"Something went wrong!\", Toast.LENGTH_SHORT).show();\n mSwipeRefreshLayout.setRefreshing(false);\n }\n\n @Override\n public void onNext(AppInfo appInfo) {\n mAddedApps.add(appInfo); \n mAdapter.addApplication(mAddedApps.size() - 1,appInfo);\n }\n });\n}\n```\n\n结果，很明显，我们得到：\n\n\n\n## DistinctUntilsChanged\n\n如果在一个可观测序列发射一个不同于之前的一个新值时让我们得到通知这时候该怎么做？我们猜想一下我们观测的温度传感器，每秒发射的室内温度：\n```\n21°https://github.com/yuxingxin/RxJava-Essentials-CN/raw/master.21°https://github.com/yuxingxin/RxJava-Essentials-CN/raw/master.21°https://github.com/yuxingxin/RxJava-Essentials-CN/raw/master.21°https://github.com/yuxingxin/RxJava-Essentials-CN/raw/master.22°https://github.com/yuxingxin/RxJava-Essentials-CN/raw/master.\n```\n每次我们获得一个新值，我们都会更新当前正在显示的温度。我们出于系统资源保护并不想在每次值一样时更新数据。我们想忽略掉重复的值并且在温度确实改变时才想得到通知。`ditinctUntilChanged()`过滤函数能做到这一点。它能轻易的忽略掉所有的重复并且只发射出新的值。\n\n下图用图形化的方式展示了我们如何将`distinctUntilChanged()`函数应用在一个存在的序列上来创建一个新的不重复发射元素的序列。\n\n![](https://github.com/yuxingxin/RxJava-Essentials-CN/raw/master/images/chapter4_7.png)\n\n## First and last\n\n下图展示了如何从一个从可观测源序列中创建只发射第一个元素的序列。\n\n![](https://github.com/yuxingxin/RxJava-Essentials-CN/raw/master/images/chapter4_8.png)\n\n`first()`方法和`last()`方法很容易弄明白。它们从Observable中只发射第一个元素或者最后一个元素。这两个都可以传`Func1`作为参数，：一个可以确定我们感兴趣的第一个或者最后一个的谓词：\n\n下图展示了`last()`应用在一个完成的序列上来创建一个仅仅发射最后一个元素的新的Observable。\n\n![](https://github.com/yuxingxin/RxJava-Essentials-CN/raw/master/images/chapter4_9.png)\n\n与`first()`和`last()`相似的变量有：`firstOrDefault()`和`lastOrDefault()`.这两个函数当可观测序列完成时不再发射任何值时用得上。在这种场景下，如果Observable不再发射任何值时我们可以指定发射一个默认的值\n\n## Skip and SkipLast\n\n下图中展示了如何使用`skip(2)`来创建一个不发射前两个元素而是发射它后面的那些数据的序列。\n\n![](https://github.com/yuxingxin/RxJava-Essentials-CN/raw/master/images/chapter4_10.png)\n\n`skip()`和`skipLast()`函数与`take()`和`takeLast()`相对应。它们用整数N作参数，从本质上来说，它们不让Observable发射前N个或者后N个值。如果我们知道一个序列以没有太多用的“可控”元素开头或结尾时我们可以使用它。\n\n下图与前一个场景相对应：我们创建一个新的序列，它会跳过后面两个元素从源序列中发射剩下的其他元素。\n\n![](https://github.com/yuxingxin/RxJava-Essentials-CN/raw/master/images/chapter4_11.png)\n\n\n## ElementAt\n\n如果我们只想要可观测序列发射的第五个元素该怎么办？`elementAt()`函数仅从一个序列中发射第n个元素然后就完成了。\n\n如果我们想查找第五个元素但是可观测序列只有三个元素可供发射时该怎么办？我们可以使用`elementAtOrDefault()`。下图展示了如何通过使用`elementAt(2)`从一个序列中选择第三个元素以及如何创建一个只发射指定元素的新的Observable。\n\n![](https://github.com/yuxingxin/RxJava-Essentials-CN/raw/master/images/chapter4_12.png)\n\n## Sampling\n\n让我们再回到那个温度传感器。它每秒都会发射当前室内的温度。说实话，我们并不认为温度会变化这么快，我们可以使用一个小的发射间隔。在Observable后面加一个`sample()`，我们将创建一个新的可观测序列，它将在一个指定的时间间隔里由Observable发射最近一次的数值：\n\n```java\nObservable sensor = [...]\n\nsensor.sample(30,TimeUnit.SECONDS)\n .subscribe(new Observable() {\n\n @Override\n public void onCompleted() {\n \n }\n\n @Override\n public void onError(Throwable e) {\n \n }\n\n @Override\n public void onNext(Integer currentTemperature) {\n updateDisplay(currentTemperature)\n }\n });\n```\n例子中Observable将会观测温度Observable然后每隔30秒就会发射最后一个温度值。很明显，`sample()`支持全部的时间单位：秒，毫秒，天，分等等。\n\n下图中展示了一个间隔发射字母的Observable如何采样一个发射数字的Observable。Observable的结果将会发射每个已发射字母的最后一组数据：1，4，5.\n\n![](https://github.com/yuxingxin/RxJava-Essentials-CN/raw/master/images/chapter4_13.png)\n\n如果我们想让它定时发射第一个元素而不是最近的一个元素，我们可以使用`throttleFirst()`。\n\n## Timeout\n\n假设我们工作的是一个时效性的环境，我们温度传感器每秒都在发射一个温度值。我们想让它每隔两秒至少发射一个，我们可以使用`timeout()`函数来监听源可观测序列,就是在我们设定的时间间隔内如果没有得到一个值则发射一个错误。我们可以认为`timeout()`为一个Observable的限时的副本。如果在指定的时间间隔内Observable不发射值的话，它监听的原始的Observable时就会触发`onError()`函数。\n\n```java\nSubscription subscription = getCurrentTemperature()\n .timeout(2,TimeUnit.SECONDS)\n .subscribe(new Observable() {\n\n @Override\n public void onCompleted() {\n \n }\n\n @Override\n public void onError(Throwable e) {\n Log.d(\"RXJAVA\",\"You should go check the sensor, dude\");\n }\n\n @Override\n public void onNext(Integer currentTemperature) {\n updateDisplay(currentTemperature)\n }\n });\n```\n\n和`sample()`一样，`timeout()`使用`TimeUnit`对象来指定时间间隔。\n\n下图中展示了一旦Observable超过了限时就会触发`onError()`函数：因为超时后它才到达，所以最后一个元素将不会发射出去。\n\n![](https://github.com/yuxingxin/RxJava-Essentials-CN/raw/master/images/chapter4_14.png)\n\n\n## Debounce\n\n`debounce()`函数过滤掉由Observable发射的速率过快的数据；如果在一个指定的时间间隔过去了仍旧没有发射一个，那么它将发射最后的那个。\n\n就像`sample()`和`timeout()`函数一样，`debounce()`使用`TimeUnit`对象指定时间间隔。\n\n下图展示了多久从Observable发射一次新的数据，`debounce()`函数开启一个内部定时器，如果在这个时间间隔内没有新的数据发射，则新的Observable发射出最后一个数据：\n\n![](https://github.com/yuxingxin/RxJava-Essentials-CN/raw/master/images/chapter4_15.png)\n\n## 总结\n\n这一章中，我们学习了如何过滤一个可观测序列。我们现在可以使用`filter()`，`skip()`，和`sample()`来创建我们想要的Observable。\n\n下一章中，我们将学习如何转换一个序列，将函数应用到每个元素，给它们分组和扫描来创建我们所需要的能完成目标的特定Observable。" }, { "path": "rxjava/chap5.md", "content": "\n\n# RxJava开发精要5 - Observables变换\n\n> \n> * 原文出自《RxJava Essentials》\n* 原文作者 : [Ivan Morgillo](https://www.packtpub.com/books/info/authors/ivan-morgillo)\n* 译文出自 : [开发技术前线 www.devtf.cn](http://www.devtf.cn)\n* 转载声明: 本译文已授权[开发者头条](http://toutiao.io/download)享有独家转载权，未经允许，不得转载!\n* 译者 : [yuxingxin](https://github.com/yuxingxin) \n* 项目地址 : [RxJava-Essentials-CN](https://github.com/yuxingxin/RxJava-Essentials-CN)\n\n在上一章中，我们探索了RxJava通用过滤方法。我们学习了如何使用`filter()`方法过滤我们不需要的值，如何使用`take()`得到发射元素的子集，如何使用`distinct()`函数来去除重复的。我们学习了如何使用`timeout()`，`sample()`，以及`debounce()`来利用时间。\n\n这一章中，我们将学习如何变换可观测序列来创建一个更好满足我们需求的序列。\n\n## *map家族\n\nRxJava提供了几个mapping函数：`map()`,`flatMap()`,`concatMap()`,`flatMapIterable()`以及`switchMap()`.所有这些函数都作用于一个可观测序列，然后变换它发射的值，最后用一种新的形式返回它们。让我们用“真实世界”合适的例子一个个的学习下。\n\n## Map\n\nRxJava的`map`函数接收一个指定的`Func`对象然后将它应用到每一个由Observable发射的值上。下图展示了如何将一个乘法函数应用到每个发出的值上以此创建一个新的Observable来发射转换的数据。\n\n![](https://github.com/yuxingxin/RxJava-Essentials-CN/raw/master/images/chapter5_1.png)\n\n考虑我们已安装的应用列表。我们怎么才能够显示同样的列表，但是所有的名字都是小写。\n\n我们的`loadList()`函数可以改成这样：\n```java\nprivate void loadList(List apps) {\n mRecyclerView.setVisibility(View.VISIBLE);\n Observable.from(apps)\n .map(new Func1(){\n @Override\n public Appinfo call(AppInfo appInfo){\n String currentName = appInfo.getName();\n String lowerCaseName = currentName.toLowerCase();\n appInfo.setName(lowerCaseName);\n return appInfo;\n }\n })\n .subscribe(new Observable() {\n\n @Override\n public void onCompleted() {\n mSwipeRefreshLayout.setRefreshing(false);\n }\n\n @Override\n public void onError(Throwable e) {\n Toast.makeText(getActivity(), \"Something went wrong!\", Toast.LENGTH_SHORT).show();\n mSwipeRefreshLayout.setRefreshing(false);\n }\n\n @Override\n public void onNext(AppInfo appInfo) {\n mAddedApps.add(appInfo); \n mAdapter.addApplication(mAddedApps.size() - 1,appInfo);\n }\n });\n}\n```\n\n正如你看到的，像往常一样创建我们发射的Observable，我们加一个`map`调用，我们可以创建一个简单的函数来更新`AppInfo`对象并提供一个名字小写的新版本给观察者。\n\n## FlatMap\n\n在复杂的场景中，我们有一个这样的Observable：它发射一个数据序列，这些数据本身也可以发射Observable。RxJava的`flatMap()`函数提供一种铺平序列的方式，然后合并这些Observables发射的数据，最后将合并后的结果作为最终的Observable。\n\n![](https://github.com/yuxingxin/RxJava-Essentials-CN/raw/master/images/chapter5_2.png)\n\n当我们在处理可能有大量的Observables时，重要是记住任何一个Observables发生错误的情况，`flatMap()`函数将会触发它自己的`onError()`函数并放弃整个链。\n\n重要的一点是关于合并部分：它允许交叉。正如上图所示，这意味着`flatMap()`函数在最后的Observable中不能够保证源Observables确切的发射顺序。\n\n## ConcatMap\n\nRxJava的`concatMap()`函数解决了`flatMap()`的交叉问题，提供了一种能够把发射的值连续在一起的铺平函数，而不是合并它们，如下图所示：\n\n![](https://github.com/yuxingxin/RxJava-Essentials-CN/raw/master/images/chapter5_3.png)\n\n## FlatMapIterable\n\n作为*map家族的一员，`flatMapInterable()`和`flatMap()`很像。仅有的本质不同是它将源数据两两结成对，然后生成Iterable而不是原始数据和生成的Observables。\n\n![](https://github.com/yuxingxin/RxJava-Essentials-CN/raw/master/images/chapter5_4.png)\n\n## SwitchMap\n\n如下图所示，`switchMap()`和`flatMap()`很像，除了一点：当原始Observable发射一个新的数据（Observable）时，它将取消订阅并停止监视之前那个数据的Observable产生的Observable，并开始监视当前这一个。\n\n![](https://github.com/yuxingxin/RxJava-Essentials-CN/raw/master/images/chapter5_5.png)\n\n## Scan\n\nRxJava的`scan()`函数可以看做是一个累加器函数。`scan()`函数对原始Observable发射的每一项数据都应用一个函数，它将函数的结果填充回可观测序列，等待和下一次发射的数据一起使用。\n\n作为一个通用的例子，给出一个累加器：\n```java\nObservable.just(1,2,3,4,5)\n .scan((sum,item) -> sum + item)\n .subscribe(new Subscriber() {\n @Override\n public void onCompleted() {\n Log.d(\"RXJAVA\", \"Sequence completed.\");\n }\n\n @Override\n public void onError(Throwable e) {\n Log.e(\"RXJAVA\", \"Something went south!\");\n }\n\n @Override\n public void onNext(Integer item) {\n Log.d(\"RXJAVA\", \"item is: \" + item);\n }\n });\n```\n我们得到的结果是：\n```java\nRXJAVA: item is: 1\nRXJAVA: item is: 3\nRXJAVA: item is: 6\nRXJAVA: item is: 10\nRXJAVA: item is: 15\nRXJAVA: Sequence completed.\n```\n我们也可以创建一个新版本的`loadList()`函数用来比较每个安装应用的名字从而创建一个名字长度递增的列表。\n\n```java\nprivate void loadList(List apps) {\n mRecyclerView.setVisibility(View.VISIBLE);\n Observable.from(apps)\n .scan((appInfo,appInfo2) -> {\n if(appInfo.getName().length > appInfo2.getName().length()){\n return appInfo;\n } else {\n return appInfo2;\n }\n })\n .distinct()\n .subscribe(new Observable() {\n\n @Override\n public void onCompleted() {\n mSwipeRefreshLayout.setRefreshing(false);\n }\n\n @Override\n public void onError(Throwable e) {\n Toast.makeText(getActivity(), \"Something went wrong!\", Toast.LENGTH_SHORT).show();\n mSwipeRefreshLayout.setRefreshing(false);\n }\n\n @Override\n public void onNext(AppInfo appInfo) {\n mAddedApps.add(appInfo); \n mAdapter.addApplication(mAddedApps.size() - 1,appInfo);\n }\n });\n}\n```\n\n结果如下：\n\n\n\n\n有一个`scan()`函数的变体，它用初始值作为第一个发射的值，方法特征就像：`scan(R,Func2)`，就像下图中的例子这样：\n\n\n\n\n## GroupBy\n\n拿第一个例子开始，我们安装的应用程序列表按照字母表的顺序排序。然而，如果现在我们想按照最近更新日期来排序我们的App时该怎么办？RxJava提供了一个有用的函数从列表中按照指定的规则：`groupBy()`来分组元素。下图中的例子展示了`groupBy()`如何将发射的值根据他们的形状来进行分组。\n\n![](https://github.com/yuxingxin/RxJava-Essentials-CN/raw/master/images/chapter5_8.png)\n\n这个函数将源Observable变换成一个发射Observables的新的Observable。它们中的每一个新的Observable都发射一组指定的数据。\n\n为了创建一个分组了的已安装应用列表，我们在`loadList()`函数中引入了一个新的元素：\n```java\nObservable> groupedItems = Observable.from(apps)\n .groupBy(new Func1(){\n @Override\n public String call(AppInfo appInfo){\n SimpleDateFormat formatter = new SimpleDateFormat(\"MM/yyyy\");\n return formatter.format(new Date(appInfo.getLastUpdateTime()));\n }\n });\n```\n现在我们创建了一个新的Observable，`groupedItems`，将会发射一个带有`GroupedObservable`的序列。`GroupedObservable`是一个特殊的Observable，它源自一个分组的key。在这个例子中，key就是`String`，代表的意思是`Month/Year`格式化的最近更新日期。\n\n这一点，我们已经创建了几个发射`AppInfo`数据的Observable，用来填充我们的列表。我们想保留字母排序和分组排序。我们将创建一个新的Observable将所有的联系起来，像通常一样然后订阅它：\n\n```java\nObservable.concat(groupedItems)\n .subscribe(new Observable() {\n\n @Override\n public void onCompleted() {\n mSwipeRefreshLayout.setRefreshing(false);\n }\n\n @Override\n public void onError(Throwable e) {\n Toast.makeText(getActivity(), \"Something went wrong!\", Toast.LENGTH_SHORT).show();\n mSwipeRefreshLayout.setRefreshing(false);\n }\n\n @Override\n public void onNext(AppInfo appInfo) {\n mAddedApps.add(appInfo); \n mAdapter.addApplication(mAddedApps.size() - 1,appInfo);\n }\n });\n```\n\n我们的`loadList()`函数完成了，结果是：\n\n\n\n\n\n## Buffer\n\nRxJava中的`buffer()`函数将源Observable变换一个新的Observable，这个新的Observable每次发射一组列表值而不是一个一个发射。\n\n![](https://github.com/yuxingxin/RxJava-Essentials-CN/raw/master/images/chapter5_10.png)\n\n上图中展示了`buffer()`如何将`count`作为一个参数来指定有多少数据项被包在发射的列表中。实际上，`buffer()`函数有几种变体。其中有一个时允许你指定一个`skip`值：此后每当收到skip项数据，用count项数据就填充缓存。如下图所示：\n\n![](https://github.com/yuxingxin/RxJava-Essentials-CN/raw/master/images/chapter5_11.png)\n\n`buffer()`带一个`timespan`的参数，会创建一个每隔timespan时间段就会发射一个列表的Observable。\n\n![](https://github.com/yuxingxin/RxJava-Essentials-CN/raw/master/images/chapter5_12.png)\n\n\n## Window\n\nRxJava的`window()`函数和`buffer()`很像，但是它发射的时Observable而不是列表。下图展示了`window()`如何缓存3个数据项并把它们作为一个新的Observable发射出去。\n\n![](https://github.com/yuxingxin/RxJava-Essentials-CN/raw/master/images/chapter5_13.png)\n\n这些Observables中的每一个都发射原始Observable数据的一个子集，数量由`count`指定,最后发射一个`onCompleted()`结束。正如`buffer()`一样,`window()`也有一个`skip`变体,如下图所示：\n\n![](https://github.com/yuxingxin/RxJava-Essentials-CN/raw/master/images/chapter5_14.png)\n\n## Cast\n\nRxJava的`cast()`函数是本章中最后一个操作符。它是`map()`操作符的特殊版本。它将源Observable中的每一项数据都转换为新的类型，把它变成了不同的`Class`。\n\n![](https://github.com/yuxingxin/RxJava-Essentials-CN/raw/master/images/chapter5_15.png)\n\n\n## 总结\n\n这一章中，我们学习了RxJava时如何控制和转换可观测序列。用我们现在所学的知识，我们可以创建、过滤、转换我们所想要的任何种类的可观测序列。\n\n下一章，我们将学习如何组合Observable，合并它们，连接它们，再或者打包它们。\n" }, { "path": "rxjava/chap6.md", "content": "\n# RxJava开发精要6 - 组合Observables\n\n> \n> * 原文出自《RxJava Essentials》\n* 原文作者 : [Ivan Morgillo](https://www.packtpub.com/books/info/authors/ivan-morgillo)\n* 译文出自 : [开发技术前线 www.devtf.cn](http://www.devtf.cn)\n* 转载声明: 本译文已授权[开发者头条](http://toutiao.io/download)享有独家转载权，未经允许，不得转载!\n* 译者 : [yuxingxin](https://github.com/yuxingxin) \n* 项目地址 : [RxJava-Essentials-CN](https://github.com/yuxingxin/RxJava-Essentials-CN)\n\n上一章中，我们学到如何转换可观测序列。我们也看到了`map()`,`scan()`,`groupBY()`,以及更多有用的函数的实际例子，它们帮助我们操作Observable来创建我们想要的Observable。\n\n本章中，我们将研究组合函数并学习如何同时处理多个Observables来创建我们想要的Observable。\n\n\n## Merge\n\n在异步的世界经常会创建这样的场景，我们有多个来源但是只想有一个结果：多输入，单输出。RxJava的`merge()`方法将帮助你把两个甚至更多的Observables合并到他们发射的数据里。下图给出了把两个序列合并在一个最终发射的Observable。\n\n![](https://github.com/yuxingxin/RxJava-Essentials-CN/raw/master/images/chapter6_1.png)\n\n正如你看到的那样，发射的数据被交叉合并到一个Observable里面。注意如果你同步的合并Observable，它们将连接在一起并且不会交叉。\n\n像通常一样，我们用我们的App和已安装的App列表来创建了一个“真实世界”的例子。我们还需要第二个Observable。我们可以创建一个单独的应用列表然后逆序。当然没有实际的意义，只是为了这个例子。第二个列表，我们的`loadList()`函数像下面这样：\n```java\nprivate void loadList(List apps) {\n mRecyclerView.setVisibility(View.VISIBLE);\n List reversedApps = Lists.reverse(apps);\n Observable observableApps =Observable.from(apps);\n Observable observableReversedApps =Observable.from(reversedApps);\n Observable mergedObserbable = Observable.merge(observableApps,observableReversedApps);\n \n mergedObserbable.subscribe(new Observer(){\n @Override\n public void onCompleted() {\n mSwipeRefreshLayout.setRefreshing(false);\n Toast.makeText(getActivity(), \"Here is the list!\", Toast.LENGTH_LONG).show();\n }\n \n @Override\n public void onError(Throwable e) {\n Toast.makeText(getActivity(), \"One of the two Observable threw an error!\", Toast.LENGTH_SHORT).show();\n mSwipeRefreshLayout.setRefreshing(false);\n }\n \n @Override\n public void onNext(AppInfoappInfo) {\n mAddedApps.add(appInfo);\n mAdapter.addApplication(mAddedApps.size() - 1, appInfo);\n } \n });\n}\n```\n\n我们创建了Observable和observableApps数据以及新的observableReversedApps逆序列表。使用`Observable.merge()`，我们可以创建新的`ObservableMergedObservable`在单个可观测序列中发射源Observables发出的所有数据。\n\n正如你能看到的,每个方法签名都是一样的，因此我们的观察者无需在意任何不同就可以复用代码。结果如下：\n\n\n\n注意错误时的toast消息，你可以认为每个Observable抛出的错误将会打断合并。如果你需要避免这种情况，RxJava提供了`mergeDelayError()`，它能从一个Observable中继续发射数据即便是其中有一个抛出了错误。当所有的Observables都完成时，`mergeDelayError()`将会发射`onError()`，如下图所示：\n\n![](https://github.com/yuxingxin/RxJava-Essentials-CN/raw/master/images/chapter6_3.png)\n\n\n## ZIP\n\n我们在处理多源时可能会带来这样一种场景：多从个Observables接收数据，处理它们，然后将它们合并成一个新的可观测序列来使用。RxJava有一个特殊的方法可以完成：`zip()`合并两个或者多个Observables发射出的数据项，根据指定的函数`Func*`变换它们，并发射一个新值。下图展示了`zip()`方法如何处理发射的“numbers”和“letters”然后将它们合并一个新的数据项：\n\n![](https://github.com/yuxingxin/RxJava-Essentials-CN/raw/master/images/chapter6_4.png)\n\n对于“真实世界”的例子来说，我们将使用已安装的应用列表和一个新的动态的Observable来让例子变得有点有趣味。\n\n```java\nObservable tictoc = Observable.interval(1, TimeUnit.SECONDS);\n```\n`tictoc`Observable变量使用`interval()`函数每秒生成一个Long类型的数据：简单且高效，正如之前所说的，我们需要一个`Func`对象。因为它需要传两个参数，所以是`Func2`:\n\n```java\nprivate AppInfo updateTitle(AppInfoappInfo, Long time) {\n appInfo.setName(time + \" \" + appInfo.getName());\n return appInfo;\n}\n```\n现在我们的`loadList()`函数变成这样：\n```java\nprivate void loadList(List apps) {\n mRecyclerView.setVisibility(View.VISIBLE);\n Observable observableApp = Observable.from(apps);\n \n Observable tictoc = Observable.interval(1, TimeUnit.SECONDS);\n \n Observable.zip(observableApp, tictoc,\n (AppInfo appInfo, Long time) -> updateTitle(appInfo, time))\n .observeOn(AndroidSchedulers.mainThread())\n .subscribe(new Observer() {\n @Override\n public void onCompleted() {\n Toast.makeText(getActivity(), \"Here is the list!\", Toast.LENGTH_LONG).show();\n }\n \n @Override\n public void onError(Throwable e) {\n mSwipeRefreshLayout.setRefreshing(false);\n Toast.makeText(getActivity(), \"Something went wrong!\", Toast.LENGTH_SHORT).show();\n }\n \n @Override\n public void onNext(AppInfoappInfo) {\n if (mSwipeRefreshLayout.isRefreshing()) {\n mSwipeRefreshLayout.setRefreshing(false);\n } \n mAddedApps.add(appInfo);\n int position = mAddedApps.size() - 1;\n mAdapter.addApplication(position, appInfo);\n mRecyclerView.smoothScrollToPosition(position);\n }\n });\n}\n```\n正如你看到的那样，`zip()`函数有三个参数：两个Observables和一个`Func2`。\n\n仔细一看会发现`observeOn()`函数。它将在下一章中讲解：现在我们可以小试一下。\n\n结果如下：\n\n\n\n\n## Join\n\n前面两个方法，`zip()`和`merge()`方法作用在发射数据的范畴内，在决定如何操作值之前有些场景我们需要考虑时间的。RxJava的`join()`函数基于时间窗口将两个Observables发射的数据结合在一起。\n\n![](https://github.com/yuxingxin/RxJava-Essentials-CN/raw/master/images/chapter6_6.png)\n\n为了正确的理解上一张图，我们解释下`join()`需要的参数：\n\n* 第二个Observable和源Observable结合。\n* `Func1`参数：在指定的由时间窗口定义时间间隔内，源Observable发射的数据和从第二个Observable发射的数据相互配合返回的Observable。\n* `Func1`参数：在指定的由时间窗口定义时间间隔内，第二个Observable发射的数据和从源Observable发射的数据相互配合返回的Observable。\n* `Func2`参数：定义已发射的数据如何与新发射的数据项相结合。\n* \n如下练习的例子，我们可以修改`loadList()`函数像下面这样：\n```java\nprivate void loadList(List apps) {\n mRecyclerView.setVisibility(View.VISIBLE);\n \n Observable appsSequence =\n Observable.interval(1000, TimeUnit.MILLISECONDS)\n .map(position -> {\n return apps.get(position.intValue());\n });\n \n Observable tictoc = Observable.interval(1000,TimeUnit.MILLISECONDS);\n \n appsSequence.join(\n tictoc, \n appInfo -> Observable.timer(2,TimeUnit.SECONDS),\n time -> Observable.timer(0, TimeUnit.SECONDS),\n this::updateTitle)\n .observeOn(AndroidSchedulers.mainThread())\n .take(10)\n .subscribe(new Observer() {\n @Override\n public void onCompleted() {\n Toast.makeText(getActivity(), \"Here is the list!\", Toast.LENGTH_LONG).show();\n }\n \n @Override\n public void onError(Throwable e) {\n mSwipeRefreshLayout.setRefreshing(false); \n Toast.makeText(getActivity(), \"Something went wrong!\", Toast.LENGTH_SHORT).show();\n }\n \n @Override\n public void onNext(AppInfoappInfo) {\n if (mSwipeRefreshLayout.isRefreshing()) {\n mSwipeRefreshLayout.setRefreshing(false);\n } \n mAddedApps.add(appInfo);\n int position = mAddedApps.size() - 1;\n mAdapter.addApplication(position, appInfo);\n mRecyclerView.smoothScrollToPosition(position);\n } \n });\n}\n```\n\n我们有一个新的对象`appsSequence`，它是一个每秒从我们已安装的app列表发射app数据的可观测序列。`tictoc`这个Observable数据每秒只发射一个新的`Long`型整数。为了合并它们，我们需要指定两个`Func1`变量：\n\n```java\nappInfo -> Observable.timer(2, TimeUnit.SECONDS)\n\ntime -> Observable.timer(0, TimeUnit.SECONDS)\n```\n上面描述了两个时间窗口。下面一行描述我们如何使用`Func2`将两个发射的数据结合在一起。\n```java\nthis::updateTitle\n```\n\n结果如下：\n\n\n\n它看起来有点乱，但是注意app的名字和我们指定的时间窗口，我们可以看到：一旦第二个数据发射了我们就会将它与源数据结合，但我们用同一个源数据有2秒钟。这就是为什么标题重复数字累加的原因。\n\n值得一提的是，为了简单起见，也有一个`join()`操作符作用于字符串然后简单的和发射的字符串连接成最终的字符串。\n\n![](https://github.com/yuxingxin/RxJava-Essentials-CN/raw/master/images/chapter6_8.png)\n\n## combineLatest\n\nRxJava的`combineLatest()`函数有点像`zip()`函数的特殊形式。正如我们已经学习的，`zip()`作用于最近未打包的两个Observables。相反，`combineLatest()`作用于最近发射的数据项：如果`Observable1`发射了A并且`Observable2`发射了B和C，`combineLatest()`将会分组处理AB和AC，如下图所示：\n\n![](https://github.com/yuxingxin/RxJava-Essentials-CN/raw/master/images/chapter6_9.png)\n\n`combineLatest()`函数接受二到九个Observable作为参数，如果有需要的话或者单个Observables列表作为参数。\n\n从之前的例子中把`loadList()`函数借用过来，我们可以修改一下来用于`combineLatest()`实现“真实世界”这个例子：\n```java\nprivate void loadList(List apps) {\n mRecyclerView.setVisibility(View.VISIBLE);\n Observable appsSequence = Observable.interval(1000, TimeUnit.MILLISECONDS)\n .map(position ->apps.get(position.intValue()));\n Observable tictoc = Observable.interval(1500, TimeUnit.MILLISECONDS);\n Observable.combineLatest(appsSequence, tictoc,\n this::updateTitle)\n .observeOn(AndroidSchedulers.mainThread())\n .subscribe(new Observer() {\n \n @Override\n public void onCompleted() {\n Toast.makeText(getActivity(), \"Here is the list!\", Toast.LENGTH_LONG).show();\n }\n \n @Override\n public void onError(Throwable e) {\n mSwipeRefreshLayout.setRefreshing(false);\n Toast.makeText(getActivity(), \"Something went wrong!\", Toast.LENGTH_SHORT).show();\n }\n \n @Override\n public void onNext(AppInfoappInfo) {\n if (mSwipeRefreshLayout.isRefreshing()) {\n mSwipeRefreshLayout.setRefreshing(false);\n } \n mAddedApps.add(appInfo);\n int position = mAddedApps.size() - 1;\n mAdapter.addApplication(position, appInfo);\n mRecyclerView.smoothScrollToPosition(position);\n } \n });\n}\n```\n这我们使用了两个Observables：一个是每秒钟从我们已安装的应用列表发射一个App数据，第二个是每隔1.5秒发射一个`Long`型整数。我们将他们结合起来并执行`updateTitle()`函数，结果如下：\n\n\n\n正如你看到的，由于不同的时间间隔，`AppInfo`对象如我们所预料的那样有时候会重复。\n\n## And,Then和When\n\n在将来还有一些`zip()`满足不了的场景。如复杂的架构，或者是仅仅为了个人爱好，你可以使用And/Then/When解决方案。它们在RxJava的joins包下，使用Pattern和Plan作为中介，将发射的数据集合并到一起。\n\n![](https://github.com/yuxingxin/RxJava-Essentials-CN/raw/master/images/chapter6_11.png)\n\n我们的`loadList()`函数将会被修改从这样：\n```java\nprivate void loadList(List apps) {\n\n mRecyclerView.setVisibility(View.VISIBLE);\n\n Observable observableApp = Observable.from(apps);\n \n Observable tictoc = Observable.interval(1, TimeUnit.SECONDS);\n \n Pattern2 pattern = JoinObservable.from(observableApp).and(tictoc); \n \n Plan0 plan = pattern.then(this::updateTitle);\n \n JoinObservable\n .when(plan)\n .toObservable()\n .observeOn(AndroidSchedulers.mainThread())\n .subscribe(new Observer() {\n \n @Override\n public void onCompleted() {\n Toast.makeText(getActivity(), \"Here is the list!\", Toast.LENGTH_LONG).show();\n }\n \n @Override\n public void onError(Throwable e) {\n mSwipeRefreshLayout.setRefreshing(false); \n Toast.makeText(getActivity(), \"Something went wrong!\", Toast.LENGTH_SHORT).show();\n }\n \n @Override\n public void onNext(AppInfoappInfo) {\n if (mSwipeRefreshLayout.isRefreshing()) { \n mSwipeRefreshLayout.setRefreshing(false);\n } \n mAddedApps.add(appInfo);\n int position = mAddedApps.size() - 1;\n mAdapter.addApplication(position, appInfo); mRecyclerView.smoothScrollToPosition(position);\n } \n });\n}\n```\n和通常一样，我们有两个发射的序列，`observableApp`，发射我们安装的应用列表数据，`tictoc`每秒发射一个`Long`型整数。现在我们用`and()`连接源Observable和第二个Observable。\n\n```java\nJoinObservable.from(observableApp).and(tictoc);\n```\n这里创建一个`pattern`对象，使用这个对象我们可以创建一个`Plan`对象:\"我们有两个发射数据的Observables,`then()`是做什么的？\"\n```java\npattern.then(this::updateTitle);\n```\n现在我们有了一个`Plan`对象并且当plan发生时我们可以决定接下来发生的事情。\n```java\n.when(plan).toObservable()\n```\n这时候，我们可以订阅新的Observable，正如我们总是做的那样。\n\n\n\n## Switch\n\n有这样一个复杂的场景就是在一个`subscribe-unsubscribe`的序列里我们能够从一个Observable自动取消订阅来订阅一个新的Observable。\n\nRxJava的`switch()`，正如定义的，将一个发射多个Observables的Observable转换成另一个单独的Observable，后者发射那些Observables最近发射的数据项。\n\n给出一个发射多个Observables序列的源Observable，`switch()`订阅到源Observable然后开始发射由第一个发射的Observable发射的一样的数据。当源Observable发射一个新的Observable时，`switch()`立即取消订阅前一个发射数据的Observable（因此打断了从它那里发射的数据流）然后订阅一个新的Observable，并开始发射它的数据。\n\n![](https://github.com/yuxingxin/RxJava-Essentials-CN/raw/master/images/chapter6_12.png)\n\n\n## StartWith\n\n我们已经学到如何连接多个Observables并追加指定的值到一个发射序列里。RxJava的`startWith()`是`concat()`的对应部分。正如`concat()`向发射数据的Observable追加数据那样，在Observable开始发射他们的数据之前， `startWith()`通过传递一个参数来先发射一个数据序列。 \n\n![](https://github.com/yuxingxin/RxJava-Essentials-CN/raw/master/images/chapter6_13.png)\n\n\n\n## 总结\n\n这章中，我们学习了如何将两个或者更多个Observable结合来创建一个新的可观测序列。我们将能够`merge` Observable，`join` Observables ，`zip` Observables 并在几种情况下把他们结合在一起。\n\n下一章，我们将介绍调度器，它将很容易的帮助我们创建主线程以及提高我们应用程序的性能。我们也将学习如何正确的执行长任务或者I/O任务来获得更好的性能。\n" }, { "path": "rxjava/chap7.md", "content": "# RxJava开发精要7 - Schedulers-解决Android主线程问题\n\n> \n> * 原文出自《RxJava Essentials》\n* 原文作者 : [Ivan Morgillo](https://www.packtpub.com/books/info/authors/ivan-morgillo)\n* 译文出自 : [开发技术前线 www.devtf.cn](http://www.devtf.cn)\n* 转载声明: 本译文已授权[开发者头条](http://toutiao.io/download)享有独家转载权，未经允许，不得转载!\n* 译者 : [yuxingxin](https://github.com/yuxingxin) \n* 项目地址 : [RxJava-Essentials-CN](https://github.com/yuxingxin/RxJava-Essentials-CN)\n\n前面一章是最后一章关于RxJava的Observable的创建和操作的章节。我们学习到了如何将两个或更多的Observables合并在一起，`join`它们，`zip`它们，`merge`它们以及如何创建一个新的Observable来满足我们特殊的需求。\n\n本章中，我们提升标准看看如何使用RxJava的调度器来处理多线程和并发编程的问题。我们将学习到如何以响应式的方式创建网络操作，内存访问，以及耗时任务。\n\n\n## StrictMode\n\n为了获得更多出现在代码中的关于公共问题的信息，我们激活了`StrictMode`模式。\n\n`StrictMode`帮助我们侦测敏感的活动，如我们无意的在主线程执行磁盘访问或者网络调用。正如你所知道的，在主线程执行繁重的或者长时的任务是不可取的。因为Android应用的主线程时UI线程，它被用来处理和UI相关的操作：这也是获得更平滑的动画体验和响应式App的唯一方法。\n\n为了在我们的App中激活`StrictMode`，我们只需要在`MainActivity`中添加几行代码，即`onCreate()`方法中这样：\n```java\n@Override\npublic void onCreate() { \n super.onCreate();\n if (BuildConfig.DEBUG) {\n StrictMode.setThreadPolicy(new StrictMode.ThreadPolicy.Builder().detectAll().penaltyLog().build()); \n StrictMode.setVmPolicy(new StrictMode.VmPolicy.Builder().detectAll().penaltyLog().build());\n } \n}\n```\n我们并不想它总是激活着，因此我们只在debug构建时使用。这种配置将报告每一种关于主线程用法的违规做法，并且这些做法都可能与内存泄露有关：`Activities`、`BroadcastReceivers`、`Sqlite`等对象。\n\n选择了`penaltyLog()`，当违规做法发生时，`StrictMode`将会在logcat打印一条信息。\n\n\n## 避免阻塞I/O的操作\n\n阻塞I/O的操作将使App能够进行下一步操作前会强制使其等待结果的返回。在UI线程上执行一个阻塞操作将强制使UI卡住，这将直接产生不好的用户体验。\n\n我们激活`StrictMode`后，我们开始收到了关于我们的App错误操作磁盘I/O的不友好信息。\n\n```java\nD/StrictMode StrictMode policy violation; ~duration=998 ms: android.os.StrictMode$StrictModeDiskReadViolation: policy=31 violation=2\nat android.os.StrictMode$AndroidBlockGuardPolicy.onReadFromDisk (StrictMode.java:1135)\nat libcore.io.BlockGuardOs.open(BlockGuardOs.java:106) at libcore.io.IoBridge.open(IoBridge.java:393)\nat java.io.FileOutputStream.(FileOutputStream.java:88) \nat android.app.ContextImpl.openFileOutput(ContextImpl.java:918) \nat android.content.ContextWrapper.openFileOutput(ContextWrapper. java:185)\nat com.packtpub.apps.rxjava_essentials.Utils.storeBitmap (Utils.java:30)\n```\n上一条信息告诉我们`Utils.storeBitmap()`函数执行完耗时998ms：在UI线程上近1秒的不必要的工作和App上近1秒不必要的迟钝。这是因为我们以阻塞的方式访问磁盘。我们的`storeBitmap()`函数包含了：\n```java\nFileOutputStream fOut = context.openFileOutput(filename, Context.MODE_PRIVATE);\n```\n它直接访问智能手机的固态存储然后就慢了。我们该如何提高访问速度呢？`storeBitmap()`函数保存了已安装App的图标。他返回了`void`，因此在执行下一个操作前我们毫无理由去等待直到它完成。我们可以启动它并让它执行在不同的线程。Android中这些年线程管理的变化产生了App诡异的行为。我们可以使用`AsyncTask`，但是我们要避免掉入前几章里的`onPrehttps://github.com/yuxingxin/RxJava-Essentials-CN/raw/master. onPosthttps://github.com/yuxingxin/RxJava-Essentials-CN/raw/master.doInBackGround`地狱。我们将使用RxJava的方式;万岁的调度器！\n\n\n## Schedulers\n\n调度器以一种最简单的方式将多线程用在你的Apps的中。它们时RxJava重要的一部分并能很好地与Observables协同工作。它们无需处理实现、同步、线程、平台限制、平台变化而可以提供一种灵活的方式来创建并发程序。\n\nRxJava提供了5种调度器：\n\n* `.io()`\n* `.computation()`\n* `.immediate()`\n* `.newThread()`\n* `.trampoline()`\n\n让我们一个一个的来看下它们：\n\n## Schedulers.io()\n\n这个调度器时用于I/O操作。它基于根据需要，增长或缩减来自适应的线程池。我们将使用它来修复我们之前看到的`StrictMode`违规做法。由于它专用于I/O操作，所以并不是RxJava的默认方法；正确的使用它是由开发者决定的。\n\n重点需要注意的是线程池是无限制的，大量的I/O调度操作将创建许多个线程并占用内存。一如既往的是，我们需要在性能和简捷两者之间找到一个有效的平衡点。\n\n## Schedulers.computation()\n\n这个是计算工作默认的调度器，它与I/O操作无关。它也是许多RxJava方法的默认调度器：`buffer()`,`debounce()`,`delay()`,`interval()`,`sample()`,`skip()`。\n\n## Schedulers.immediate()\n\n这个调度器允许你立即在当前线程执行你指定的工作。它是`timeout()`,`timeInterval()`,以及`timestamp()`方法默认的调度器。\n\n## Schedulers.newThread()\n\n这个调度器正如它所看起来的那样：它为指定任务启动一个新的线程。\n\n## Schedulers.trampoline()\n\n当我们想在当前线程执行一个任务时，并不是立即，我们可以用`.trampoline()`将它入队。这个调度器将会处理它的队列并且按序运行队列中每一个任务。它是`repeat()`和`retry()`方法默认的调度器。\n\n\n## 非阻塞I/O操作\n\n现在我们知道如何在一个指定I/O调度器上来调度一个任务，我们可以修改`storeBitmap()`函数并再次检查`StrictMode`的不合规做法。为了这个例子，我们可以在新的`blockingStoreBitmap()`函数中重排代码。\n\n```java\nprivate static void blockingStoreBitmap(Context context, Bitmap bitmap, String filename) {\n FileOutputStream fOut = null; \n try {\n fOut = context.openFileOutput(filename, Context.MODE_PRIVATE);\n bitmap.compress(Bitmap.CompressFormat.PNG, 100, fOut); \n fOut.flush();\n fOut.close();\n } catch (Exception e) {\n throw new RuntimeException(e);\n } finally { \n try {\n if (fOut != null) {\n fOut.close();\n }\n } catch (IOException e) {\n throw new RuntimeException(e); \n }\n } \n}\n```\n现在我们可以使用`Schedulers.io()`创建非阻塞的版本：\n\n```java\npublic static void storeBitmap(Context context, Bitmap bitmap, String filename) {\n Schedulers.io().createWorker().schedule(() -> {\n blockingStoreBitmap(context, bitmap, filename);\n }); \n}\n```\n\n每次我们调用`storeBitmap()`，RxJava处理创建所有它需要从I / O线程池一个特定的I/ O线程执行我们的任务。所有要执行的操作都避免在UI线程执行并且我们的App比之前要快上1秒：logcat上也不再有`StrictMode`的不合规做法。\n\n下图展示了我们在`storeBitmap()`场景看到的两种方法的不同：\n\n![](https://github.com/yuxingxin/RxJava-Essentials-CN/raw/master/images/chapter7_1.png)\n\n\n## SubscribeOn and ObserveOn\n\n我们学到了如何在一个调度器上运行一个任务。但是我们如何利用它来和Observables一起工作呢？RxJava提供了`subscribeOn()`方法来用于每个Observable对象。`subscribeOn()`方法用`Scheduler`来作为参数并在这个Scheduler上执行Observable调用。\n\n在“真实世界”这个例子中，我们调整`loadList()`函数。首先，我们需要一个新的`getApps()`方法来检索已安装的应用列表：\n\n```java\nprivate Observable getApps() { \n return Observable.create(subscriber -> {\n List apps = new ArrayList<>();\n SharedPreferences sharedPref = getActivity().getPreferences(Context.MODE_PRIVATE);\n Type appInfoType = new TypeToken>(){}.getType();\n String serializedApps = sharedPref.getString(\"APPS\", \"\");\n if (!\"\".equals(serializedApps)) {\n apps = new Gson().fromJson(serializedApps,appInfoType); \n }\n for (AppInfo app : apps) {\n subscriber.onNext(app);\n }\n subscriber.onCompleted(); \n });\n}\n```\n`getApps()`方法返回一个`AppInfo`的Observable。它先从Android的SharePreferences读取到已安装的应用程序列表。反序列化，并一个接一个的发射AppInfo数据。使用新的方法来检索列表，`loadList()`函数改成下面这样：\n\n```java\nprivate void loadList() {\n mRecyclerView.setVisibility(View.VISIBLE);\n getApps().subscribe(new Observer() {\n @Override\n public void onCompleted() {\n mSwipeRefreshLayout.setRefreshing(false);\n Toast.makeText(getActivity(), \"Here is the list!\", Toast.LENGTH_LONG).show();\n }\n \n @Override\n public void onError(Throwable e) {\n Toast.makeText(getActivity(), \"Something went wrong!\", Toast.LENGTH_SHORT).show();\n mSwipeRefreshLayout.setRefreshing(false);\n }\n \n @Override\n public void onNext(AppInfo appInfo) {\n mAddedApps.add(appInfo);\n mAdapter.addApplication(mAddedApps.size() - 1, appInfo);\n } \n });\n}\n```\n如果我们运行代码，`StrictMode`将会报告一个不合规操作，这是因为`SharePreferences`会减慢I/O操作。我们所需要做的是指定`getApps()`需要在调度器上执行：\n\n```java\n\ngetApps().subscribeOn(Schedulers.io())\n .subscribe(new Observer() { [https://github.com/yuxingxin/RxJava-Essentials-CN/raw/master.]\n```\n`Schedulers.io()`将会去掉`StrictMode`的不合规操作，但是我们的App现在崩溃了是因为：\n```java\nat rx.internal.schedulers.ScheduledAction.run(ScheduledAction.jav a:58)\nat java.util.concurrent.Executors$RunnableAdapter.call(Executors. java:422)\nat java.util.concurrent.FutureTask.run(FutureTask.java:237) \nat java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutu reTask.access$201(ScheduledThreadPoolExecutor.java:152)\nat java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutu reTask.run(ScheduledThreadPoolExecutor.java:265)\nat java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolEx ecutor.java:1112)\nat java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolE xecutor.java:587)\nat java.lang.Thread.run(Thread.java:841) Caused by:\n android.view.ViewRootImpl$CalledFromWrongThreadException: Only the original thread that created a view hierarchy can touch its views.\n\n```\nOnly the original thread that created a view hierarchy can touch its views.\n\n我们再次回到Android的世界。这条信息简单的告诉我们我们试图在一个非UI线程来修改UI操作。意思是我们需要在I/O调度器上执行我们的代码。因此我们需要和I/O调度器一起执行代码，但是当结果返回时我们需要在UI线程上操作。RxJava让你能够订阅一个指定的调度器并观察它。我们只需在`loadList()`函数添加几行代码，那么每一项就都准备好了：\n\n```java\ngetApps()\n.onBackpressureBuffer()\n.subscribeOn(Schedulers.io())\n.observeOn(AndroidSchedulers.mainThread())\n.subscribe(new Observer() { [https://github.com/yuxingxin/RxJava-Essentials-CN/raw/master.]\n```\n`observeOn()`方法将会在指定的调度器上返回结果：如例子中的UI线程。`onBackpressureBuffer()`方法将告诉Observable发射的数据如果比观察者消费的数据要更快的话，它必须把它们存储在缓存中并提供一个合适的时间给它们。做完这些工作之后，如果我们运行App，就会出现已安装的程序列表：\n\n\n\n## 处理耗时的任务\n\n我们已经知道如何处理缓慢的I/O操作。让我们看一个与I/O无关的耗时的任务。例如，我们修改`loadList()`函数并创建一个新的`slow`函数发射我们已安装的app数据。\n\n```java\nprivate Observable getObservableApps(List apps) {\n return Observable .create(subscriber -> {\n for (double i = 0; i < 1000000000; i++) {\n double y = i * i;\n }\n for (AppInfo app : apps) {\n subscriber.onNext(app);\n }\n subscriber.onCompleted(); \n });\n}\n```\n\n正如你看到的，这个函数执行了一些毫无意义的计算，只是针对这个例子消耗时间，然后从`List`对象中发射我们的`AppInfo`数据，现在，我们重排`loadList()`函数如下：\n\n```java\nprivate void loadList(List apps) {\n mRecyclerView.setVisibility(View.VISIBLE);\n getObservableApps(apps)\n .subscribe(new Observer() {\n @Override\n public void onCompleted() {\n mSwipeRefreshLayout.setRefreshing(false);\n Toast.makeText(getActivity(), \"Here is the list!\", Toast.LENGTH_LONG).show();\n }\n \n @Override\n public void onError(Throwable e) {\n Toast.makeText(getActivity(), \"Something went wrong!\", Toast.LENGTH_SHORT).show();\n mSwipeRefreshLayout.setRefreshing(false);\n }\n \n @Override\n public void onNext(AppInfo appInfo) { \n mAddedApps.add(appInfo); \n mAdapter.addApplication(mAddedApps.size() - 1, appInfo);\n } \n });\n}\n```\n\n如果我们运行这段代码，当我们点击`Navigation Drawer`菜单项时App将会卡住一会，然后你能看到下图中半关闭的菜单:\n\n\n\n\n如果我们不够走运的话，我们可以看到下图中经典的ANR信息框：\n\n\n\n可以确定的是，我们将会看到下面在logcat中不愉快的信息：\n\n```java\nI/Choreographer Skipped 598 frames! The application may be doing too much work on its main thread.\n```\n\n这条信息比较清楚，Android在告诉我们用户体验非常差的原因是我们用不必要的工作量阻塞了UI线程。但是我们已经知道了如何处理它：我们有调度器！我们只须添加几行代码到我们的Observable链中就能去掉加载慢和`Choreographer`信息：\n\n```java\ngetObservableApps(apps)\n .onBackpressureBuffer()\n .subscribeOn(Schedulers.computation())\n .observeOn(AndroidSchedulers.mainThread())\n .subscribe(new Observer() { [https://github.com/yuxingxin/RxJava-Essentials-CN/raw/master.]\n```\n用这几行代码，我们将可以快速关掉`Navigation Drawer`,一个漂亮的进度条，一个工作在独立的线程缓慢执行的计算任务，并在主线程返回结果让我们更新已安装的应用列表。\n\n## 执行网络任务\n\n网络在今天是99%的移动应用的一部分：我们总是连接远端服务器来检索我们App需要的信息。\n\n作为网络访问的第一个方法，我们将创建下面这样一个场景:\n\n* 加载一个进度条。\n* 用一个按钮开始文件下载。\n* 下载过程中更新进度条。\n* 下载完后开始视频播放。\n\n我们的用户界面非常简单，我们只需要一个有趣的进度条和一个下载按钮。\n\n\n\n\n首先，我们创建`mDownloadProgress`\n\n```java\nprivate PublishSubjectmDownloadProgress = PublishSubject.create();\n```\n这个主题我们用来管理进度的更新，它和`download`函数协同工作。\n```java\nprivate boolean downloadFile(String source, String destination) {\n boolean result = false;\n InputStream input = null; \n OutputStream output = null; \n HttpURLConnection connection = null;\n try {\n URL url = new URL(source);\n connection = (HttpURLConnection) url.openConnection(); \n connection.connect();\n if (connection.getResponseCode() != HttpURLConnection.HTTP_OK) {\n return false;\n }\n int fileLength = connection.getContentLength();\n input = connection.getInputStream();\n output = new FileOutputStream(destination);\n byte data[] = new byte[4096];\n long total = 0;\n int count;\n while ((count = input.read(data)) != -1) {\n total += count;\n if (fileLength >0) {\n int percentage = (int) (total * 100 / fileLength);\n mDownloadProgress.onNext(percentage);\n }\n output.write(data, 0, count); \n }\n mDownloadProgress.onCompleted(); \n result = true;\n } catch (Exception e) { \n mDownloadProgress.onError(e);\n } finally { \n try {\n if (output != null) { \n output.close();\n }\n if (input != null) {\n input.close(); \n }\n } catch (IOException e) { \n mDownloadProgress.onError(e);\n }\n if (connection != null) {\n connection.disconnect();\n mDownloadProgress.onCompleted();\n }\n }\n return result;\n}\n```\n上面的这段代码将会触发`NetworkOnMainThreadException`异常。我们可以创建RxJava版本的函数进入我们挚爱的响应式世界来解决这个问题：\n\n```java\nprivate Observable obserbableDownload(String source, String destination) {\n return Observable.create(subscriber -> {\n try {\n boolean result = downloadFile(source, destination); \n if (result) {\n subscriber.onNext(true);\n subscriber.onCompleted(); \n } else {\n subscriber.onError(new Throwable(\"Download failed.\"));\n }\n } catch (Exception e) { \n subscriber.onError(e);\n } \n });\n}\n```\n现在我们需要触发下载操作，点击下载按钮:\n\n```java\n@OnClick(R.id.button_download)\nvoid download() {\n mButton.setText(getString(R.string.downloading));\n mButton.setClickable(false);\n mDownloadProgress.distinct()\n .observeOn(AndroidSchedulers.mainThread())\n .subscribe(new Observer() {\n \n @Override\n public void onCompleted() { \n App.L.debug(\"Completed\");\n }\n \n @Override\n public void onError(Throwable e) {\n App.L.error(e.toString()); \n }\n \n @Override\n public void onNext(Integer progress) {\n mArcProgress.setProgress(progress);\n } \n });\n \n String destination = \"sdcardsoftboy.avi\";\n obserbableDownload(\"http://archive.blender.org/fileadmin/movies/softboy.avi\", destination)\n .subscribeOn(Schedulers.io())\n .observeOn(AndroidSchedulers.mainThread())\n .subscribe(success -> {\n resetDownloadButton();\n Intent intent = new Intent(android.content.Intent.ACTION_VIEW);\n File file = new File(destination);\n intent.setDataAndType(Uri.fromFile(file),\"video/avi\");\n intent.addFlags(Intent.FLAG_ACTIVITY_NEW_TASK); \n startActivity(intent);\n }, error -> {\n Toast.makeText(getActivity(), \"Something went south\", Toast.LENGTH_SHORT).show();\n resetDownloadButton();\n });\n}\n```\n我们使用Butter Knife的注解`@OnClick`来绑定按钮的方法并更新按钮信息和点击状态：我们不想让用户点击多次从而触发多次下载事件。\n\n然后，我们创建一个subscription来观察下载进度并相应的更新进度条。很明显，我们我们观测主线程是因为进度条是UI元素。\n\n```java\nobserbableDownload(\"http://archive.blender.org/fileadmin/movies/softboy.avi\", \"sdcardsoftboy.avi\";)\n```\n这是一个下载Observable。网络调用是一个I/O任务和我们预料的那样使用I/O调度器。当下载完成时，我们在`onNext()`启动视频播放器，并且播放器将会在目的URL找到下载的文件.。\n\n下图展示了下载进度和视频播放器对话框：\n\n\n\n\n## 总结\n\n这一章中，我们学习了如何简单的将多线程应用在我们的App中。RxJava为此提供了极其有用的工具：调度器。调度器来自不同的指定优化场景并且我们也不避免了`StrictMode`不合法操作以及阻塞I/O函数。我们现在可以用简单的，响应式的并在整个App中保持一致的方式来访问内存和网络。\n\n下一章中，我们将会提高风险并创建一个`真实世界`App，并使用Square公司开源的REST API库Retrofit从不同的远程资源获取数据来创建一个复杂的material design UI。\n\n" }, { "path": "rxjava/chap8.md", "content": "# RxJava开发精要8 - 与REST无缝结合-RxJava和Retrofit\n\n> \n> * 原文出自《RxJava Essentials》\n* 原文作者 : [Ivan Morgillo](https://www.packtpub.com/books/info/authors/ivan-morgillo)\n* 译文出自 : [开发技术前线 www.devtf.cn](http://www.devtf.cn)\n* 转载声明: 本译文已授权[开发者头条](http://toutiao.io/download)享有独家转载权，未经允许，不得转载!\n* 译者 : [yuxingxin](https://github.com/yuxingxin) \n* 项目地址 : [RxJava-Essentials-CN](https://github.com/yuxingxin/RxJava-Essentials-CN)\n\n在上一章中，我们学习了如何使用调度器在不同于UI线程的线程上操作。我们学习了如何高效的运行I/O任务而不用阻塞UI以及如何运行耗时的计算任务而不耗损应用性能。在最后一章中，我们将创建一个最终版的`真实世界`的例子，用Retrofit映射到远程的API,异步的查询数据，从而不费力的创造一个丰富的UI。\n\n\n## 项目目标\n\n我们将在已存在的例子中创建一个新的`Activity`。这个`Activity`将会使用StackExchange API从stackoverflow检索最活跃的10位用户。使用这个信息，App将会展示一个用户的头像，姓名，名望数以及住址列表。对于每一位用户，app将会使用其居住城市和OpenWeatherMap API 来检索当地的天气预报，并展示一个小的天气图标。基于从StackOverflow检索的信息，app对列表的每一位用户将会提供一个`onClick`事件，它将会打开他们在个人信息中指定的个人网站或者打开Stack Overflow的个人主页。\n\n## Retrofit\n\nRetrofit是Square公司专为Android和Java设计的一个类型安全的REST客户端。它帮助你很容易的和任何REST API交互，它完美的集成R小Java：所有的JSON响应对象都被映射成原始的Java对象，并且所有的网络调用都基于Rxjava Observable这些对象。\n\n使用API文档，我们可以定义我们从服务器接收的JSON响应数据。为了很容易的将JSON响应数据映射为我们的Java代码，我们将使用jsonschema2pojo(http://www.jsonschema2pojo.org)，这个灵活的服务将会生成我们所需要映射JSON响应数据的所有Java类。\n\n当我们把所有的Java model准备好后，我们就可以开始建立Retrofit。Retrofi使用标准的Java接口来映射API路由。例如例子中，我们将使用来自API的一个路由，下面是我们Retrofit的接口：\n```java\npublic interface StackExchangeService {\n @GET(\"2.2users?order=desc&sort=reputation&site=stackoverflow\")\n Observable getMostPopularSOusers(@Query(\"pagesize\") int howmany);\n}\n```\n`interface`接口只包含一个方法，即`getMostPopularSOusers`。这个方法用整型`howmany`作为一个参数并返回`UserResponse`的Observable。\n\n当我们有了`interface`，我们可以创建`RestAdapter`类，为了更清楚的组织我们的代码，我们创建一个`SeApiManager`函数提供一种更适当的方式来和StackExchange API交互。\n```java\npublic class SeApiManager {\n private final StackExchangeService mStackExchangeService;\n \n public SeApiManager() {\n RestAdapter restAdapter = new RestAdapter.Builder()\n .setEndpoint(\"https://api.stackexchange.com\")\n .setLogLevel(RestAdapter.LogLevel.BASIC)\n .build();\n mStackExchangeService = restAdapter.create(StackExchangeService.class);\n}\n\npublic Observable> getMostPopularSOusers(int howmany) {\n return mStackExchangeService\n .getMostPopularSOusers(howmany)\n .map(UsersResponse::getUsers)\n .subscribeOn(Schedulers.io())\n .observeOn(AndroidSchedulers.mainThread());\n}\n```\n为了简化例子，我们不再将这个类设计为它本应该设计为的单例。使用依赖注入解决方案，如Dagger2将会使代码质量更高。\n\n创建`RestAdapter`类，我们为API客户端建立了几个重要的点。这个例子中，我们设置`endpoint`和`log level`。由于这个例子URL只是硬编码，使用外部资源来像这样存储数据很重要。避免在代码中硬编码字符串是一个好的实践。\n\nRetrofit把`RestAdapter`类和我们的API接口绑定在一起后就创建结束。它返回给我们一个对象用来查询API。我们可以选择直接暴露这个对象，或者以某种方式封装依次来限制访问它。在这个例子中，我们封装它并只暴露`getMostPopularSOusers`方法。这个方法执行查询，让Retrofit解析JSON响应数据。获得用户列表，并返回给订阅者。正如你看到的，使用Retrofit、RxJava和Retrolambda，我们几乎没有模板代码：它非常紧凑并且可读性也高。\n\n现在，我们已经有一个API管理者来暴露一个响应式的方法，它从远程API获取到数据并给I/O调度器，解析映射最后提供给我们的消费者一个简洁的用户列表。\n\n\n## App架构\n\n我们不使用任何MVC，MVP，或者MVVM模式。因为那不是这本书的目的，因此我们的`Activity`类将包含我们需要创建和展示用户列表的所有逻辑。\n\n\n## 创建Activity类\n\n我们将在`onCreate()`方法里创建`SwipeRefreshLayout`和`RecyclerView`；我们有一个`refreshList()`方法来处理用户列表的获取和展示，`showRefreshing()`方法来管理进度条和`RecyclerView`的显示。\n\n我们的`refreshList()`函数看起来如下：\n```java\nprivate void refreshList() { \n showRefresh(true);\n mSeApiManager.getMostPopularSOusers(10)\n .subscribe(users -> { \n showRefresh(false);\n mAdapter.updateUsers(users);\n }, error -> { \n App.L.error(error.toString());\n showRefresh(false);\n });\n}\n```\n我们显示了进度条，从StackExchange API 管理器观测用户列表。一旦获取到列表数据，我们开始展示它并更新`Adapter`的内容并让`RecyclerView`显示为可见。\n\n## 创建RecyclerView Adapter\n\n我们从REST API获取到数据后，我们需要把它绑定View上，并用一个适配器填充列表。我们的RecyclerView适配器是标准的。它继承于`RecyclerView.Adapter`并指定它自己的`ViewHolder`：\n```java\npublic static class ViewHolder extends RecyclerView.ViewHolder {\n @InjectView(R.id.name) TextView name;\n @InjectView(R.id.city) TextView city;\n @InjectView(R.id.reputation) TextView reputation;\n @InjectView(R.id.user_image) ImageView user_image;\n public ViewHolder(View view) { \n super(view);\n ButterKnife.inject(this, view); \n }\n}\n```\n我们一旦收到来自API管理器的数据，我们可以设置界面上所有的标签：`name`,`city`和`reputation`。\n\n为了展示用户的头像，我们将使用Sergey Tarasevich (https://github.com/nostra13/Android-Universal- ImageLoader)写的`Universal Image Loader`。UIL是非常有名的并且被测试出很好用的图片管理库。我们也可以使用Square公司的Picasso，Glide或者Facebook公司的Fresco。这只是根据你自己的爱好。重要的是无须重复造轮子：库能够方便开发者的生活并让他们更快速实现目标。\n\n在我们的适配器中，我们可以这样：\n```java\n@Override\npublic void onBindViewHolder(SoAdapter.ViewHolder holder, int position) {\n User user = mUsers.get(position);\n holder.setUser(user); \n}\n```\n在`ViewHolder`，我们可以这样：\n```java\npublic void setUser(User user) { \n name.setText(user.getDisplayName());\n city.setText(user.getLocation());\n reputation.setText(String.valueOf(user.getReputation()));\n \n ImageLoader.getInstance().displayImage(user.getProfileImage(), user_image);\n}\n```\n\n此时，我们可以允许代码获得一个用户列表，正如下图所示：\n\n\n\n### 检索天气预报\n\n我们加大难度，将当地城市的天气加入列表中。**OpenWeatherMap**是一个灵活的web service公共API，我们可以查询检索许多有用的预报信息。\n\n和往常一样，我们将使用Retrofit映射到API然后通过RxJava来访问它。至于StackExchange API，我们将创建`interface`，`RestAdapter`和一个灵活的管理器：\n\n```java\npublic interface OpenWeatherMapService {\n @GET(\"data2.5/weather\")\n Observable getForecastByCity(@Query(\"q\") String city);\n}\n```\n\n这个方法用城市名字作为参数提供当地的预报信息。我们像下面这样将接口和`RestAdapter`类绑定在一起：\n\n```java\nRestAdapter restAdapter = new RestAdapter.Builder()\n .setEndpoint(\"http://api.openweathermap.org\")\n .setLogLevel(RestAdapter.LogLevel.BASIC)\n .build();\nmOpenWeatherMapService = restAdapter.create(OpenWeatherMapService.class);\n```\n像以前一样，我们只需设置API端口和log级别：我们只需要立马做的两件事情。\n\n`OpenWeatherMapApiManager`类将提供下面的方法：\n```java\npublic Observable getForecastByCity(String city) {\n return mOpenWeatherMapService.getForecastByCity(city)\n .subscribeOn(Schedulers.io())\n .observeOn(AndroidSchedulers.mainThread());\n}\n```\n现在，我们有了用户列表，我们可以根据城市名来查询OpenWeatherMap来接收天气预报信息。下一步是修改我们的`ViewHolder`类来为每位用户检索和使用天气预报信息从而根据状态来展示天气图标。\n\n我们使用这些工具方法先验证用户主页信息并获得一个合法的城市名字：\n```java\nprivate boolean isCityValid(String location) {\n int separatorPosition = getSeparatorPosition(location);\n return !\"\".equals(location) && separatorPosition > -1; \n}\n\nprivate int getSeparatorPosition(String location) { \n int separatorPosition = -1;\n if (location != null) {\n separatorPosition = location.indexOf(\",\"); \n }\n return separatorPosition; \n}\n\nprivate String getCity(String location, int position) {\n if (location != null) {\n return location.substring(0, position); \n } else {\n return \"\"; \n }\n}\n```\n借助一个有效的城市名，我们可以用下面命令来获得我们所需要天气的所有数据：\n\n```java\nOpenWeatherMapApiManager.getInstance().getForecastByCity(city)\n```\n用天气响应的结果，我们可以获得天气图标的URL：\n\n```java\ngetWeatherIconUrl(weatherResponse);\n```\n用图标URL，我们可以检索到图标本身：\n\n```java\nprivate Observable loadBitmap(String url) {\n return Observable.create(subscriber -> {\n ImageLoader.getInstance().displayImage(url,city_image, new ImageLoadingListener() { \n @Override\n public void onLoadingStarted(String imageUri, View view) {\n }\n \n @Override\n public void onLoadingFailed(String imageUri, View view, FailReason failReason) {\n subscriber.onError(failReason.getCause()); \n }\n \n @Override\n public void onLoadingComplete(String imageUri, View view, Bitmap loadedImage) {\n subscriber.onNext(loadedImage);\n subscriber.onCompleted(); \n }\n \n @Override\n public void onLoadingCancelled(String imageUri, View view) {\n subscriber.onError(new Throwable(\"Image loading cancelled\"));\n }\n });\n });\n}\n```\n这个`loadBitmap()`返回的Observable可以链接前面一个，并且最后我们可以为这个任务返回一个单独的Observable：\n\n```java\nif (isCityValid(location)) {\n String city = getCity(location, separatorPosition);\n OpenWeatherMapApiManager.getInstance().getForecastByCity(city)\n .filter(response -> response != null)\n .filter(response -> response.getWeather().size() > 0)\n .flatMap(response -> {\n String url = getWeatherIconUrl(response);\n return loadBitmap(url);\n })\n .subscribeOn(Schedulers.io())\n .observeOn(AndroidSchedulers.mainThread())\n .subscribe(new Observer() {\n \n @Override\n public void onCompleted() {\n }\n \n @Override\n public void onError(Throwable e) {\n App.L.error(e.toString()); \n }\n \n @Override\n public void onNext(Bitmap icon) {\n city_image.setImageBitmap(icon); \n }\n });\n}\n```\n运行代码，我们可以在下面列表中为每个用户获得新的天气图标：\n\n\n\n\n### 打开网站\n\n使用用户主页包含的信息，我们将会创建一个`onClick`监听器来导航到用户web页面，如果有，或者是Stack Overflow个人主页。\n\n为了实现它，我们简单实现`Activity`类的接口，用来在适配器触发Android的`onClick`事件。\n\n我们的`Adapter ViewHolder`指定这个接口：\n\n```java\npublic interface OpenProfileListener {\n public void open(String url); \n}\n```\n\n`Activity`实现它：\n\n```java\n[https://github.com/yuxingxin/RxJava-Essentials-CN/raw/master.] implements SoAdapter.ViewHolder.OpenProfileListener { [https://github.com/yuxingxin/RxJava-Essentials-CN/raw/master.]\n mAdapter.setOpenProfileListener(this); \n[https://github.com/yuxingxin/RxJava-Essentials-CN/raw/master.]\n\n@Override\npublic void open(String url) {\n Intent i = new Intent(Intent.ACTION_VIEW);\n i.setData(Uri.parse(url)); \n startActivity(i);\n}\n```\n\n`Activity`收到URL并用外部Android浏览器打开它。我们的`ViewHolder`负责在用户列表的每个卡片上创建`OnClickListener`并检查我们是打开Stack Overflow用户主页还是外部个人站：\n\n```java\nmView.setOnClickListener(view -> { \n if (mProfileListener != null) {\n String url = user.getWebsiteUrl();\n if (url != null && !url.equals(\"\") && !url.contains(\"search\")) {\n mProfileListener.open(url); \n } else {\n mProfileListener.open(user.getLink()); \n }\n }\n)}；\n```\n一旦我们点击了，我们将直接重定向到预期的网站。在Android上，我们可以用RxAndroid的一种特殊形式（ViewObservable）以更加响应式的方式实现同样的结果。\n```java\nViewObservable.clicks(mView)\n .subscribe(onClickEvent -> {\n if (mProfileListener != null) {\n String url = user.getWebsiteUrl();\n if (url != null && !url.equals(\"\") && !url.contains(\"search\")) { \n mProfileListener.open(url);\n } else {\n mProfileListener.open(user.getLink());\n } \n }\n});\n```\n上面两块代码片段是等价的，你可以选择你最喜欢的那一种方式。\n\n\n## 总结\n\n我们的旅程结束了。你已经准备好将你的Java应用带到一个新的代码质量水平。你可以享受一个新的编码模式并用更流畅的思维方式接触你的日常编码生活。RxJava提供这样一种机会来以面向时间的方式考虑数据：所有事情都是持续可变的，数据在更新，事件在触发，然后你可以创建基于这些事件响应的，灵活的，运行流畅的App。\n\n刚开始切换到RxJava看起来难并且耗时，但是我们经历了如何用响应式的方式有效地处理日常问题。现在你可以把你的旧代码迁移到RxJava上:给这些同步`getters`一种新的响应式生活。\n\nRxJava是一个正在不断发展和扩大的世界。还有许多方法我们还没有去探索。有些方法甚至还没有，因为RxJava，你可以创建你自己的操作符并把他们推得更远。\n\nAndroid是一个好玩的地方，但是它也有局限性。作为一个Android开发者，你可以用RxJava和RxAndroid克服它们中许多部分。我们用AndroidScheduler只简单提了下RxAndroid,除了在最后一章，你了解了`ViewObservable`。RxAndroid给了你许多：例如，`WidgetObservable`，`LifecycleObservable`。现在要更多的推动它取决于你了。\n\n记得可观测序列就像一条河：它们是流动的。你可以“过滤”一条河，你可以“转换”一条河，你可以将两条河合并成一个，然后它仍旧时流动的。最后，它将成为你想要的那条河。\n\n" }, { "path": "software-architecture-patterns/chap-5.md", "content": "# 第五章 基于空间的架构\n\n大多数基于网站的商务应用都遵循相同的请求流程：一个请求从浏览器发到web服务器，然后到应用服务器，然后到数据库服务器。虽然这个模式在用户数不大的时候工作良好，但随着用户负载的增加,瓶颈开始出现，首先出现在web服务器层，然后应用服务器层，最后数据库服务器层。通常的解决办法就是**向外扩展**，也就是增加服务器数量。这个方法相对来说简单和廉价，并能够解决问题。然而，对于大多数高访问量的情况，它只不过是把web服务器的问题移到了应用服务器。而扩展应用服务器会更复杂，而且成本更高，并且又只是把问题移动到了数据库服务器，那会更复杂，更贵。就算你能扩展数据库服务器，你最终会陷入一个金字塔式的情形，在金字塔最下面是web服务器，它会出现最多的问题，但也最好伸缩。金字塔顶部是数据库服务器，问题不多，但最难伸缩。\n\n在一个高并发大容量的应用中，数据库通常是决定应用能够支持多少用户同时在线的关键因素。虽然各种缓存技术和数据库伸缩产品都在帮助解决这个问题，但数据库难以伸缩的现实并没有改变。\n\n基于空间的架构模型是专门为了**解决伸缩性和并发问题**而设计的。它对于用户数量不可预测且数量级经常变化的情况同样适用。在架构级别来解决这个伸缩性问题通常是比增加服务器数量或者提高缓存技术更好的解决办法。\n\n## 模型介绍\n\n基于空间的模型（有时也称为云架构模型）旨在减少限制应用伸缩的因素。模型的名字来源于分布式共享内存中的 tuple space（数组空间）概念。高伸缩性是通过去除中心数据库的限制，并使用从内存中复制的数据框架来获得的。保存在内存的应用数据被复制给所有运行的进程。进程可以动态的随着用户数量增减而启动或结束，以此来解决伸缩性问题。这样因为没有了中心数据库，数据库瓶颈就此解决，此后可以近乎无限制的扩展了。\n\n大多数使用这个模型的应用都是标准的网站，它们接受来自浏览器的请求并进行相关操作。竞价拍卖网站是一个很好的例子 ( 12306更是一个典型的示例 )。网站不停的接受来自浏览器的报价。应用收到对某一商品的报价，记录下报价和时间，并且更新对该商品的报价，将信息返回给浏览器。\n\n这个架构中有两个主要的模块：**处理单元** 和 **虚拟化中间件**。下图展示了这个架构和里面的主要模块。\n\n![](images/5-1.png)\n\n处理单元包含了应用模块（或者部分的应用模块）。具体来说就是包含了web组件以及后台业务逻辑。处理单元的内容根据应用的类型而异——小型的web应用可能会部署到单一的处理单元，而大型一些的应用会将应用的不同功能模块部署到不同的处理单元中。典型的处理单元包括应用模块，以及保存在内存的数据框架和为应用失败时准备的异步数据持久化模块。它还包括复制引擎，使得虚拟化中间件可以将处理单元修改的数据复制到其他活动的处理单元。\n\n虚拟化中间件负责保护自身以及通信。它包含用于数据同步和处理请求的模块，以及通信框架，数据框架，处理框架和部署管理器。这些在下文中即将介绍的部分，可以自定义编写或者购买第三方产品来实现。\n\n## 模型间合作\n\n基于空间的架构的魔力就在虚拟化中间件，以及各个处理单元中的内存中数据框架。下图展示了包含着应用模块、内存中数据框架、处理异步数据恢复的组件和复制引擎的处理单元架构。\n\n虚拟化中间件本质上是架构的控制器，它管理请求，会话，数据复制，分布式的请求处理和处理单元的部署。虚拟化中间件有四个架构组件：通信框架，数据框架，处理框架和部署管理器。\n\n![](images/5-2.png)\n\n### 通信框架\n\n通信框架管理输入请求和会话信息。当有请求进入虚拟化中间件，通信框架就决定有哪个处理单元可用，并将请求传递给这个处理单元。通信框架的复杂程度可以从简单的round robin算法到更复杂的用于监控哪个请求正在被哪个处理单元处理的next-available算法。\n\n![](images/5-3.png)\n\n### 数据框架\n\n数据框架可能是这个架构中最重要和关键的组件。它与各个处理单元的数据复制引擎交互，在数据更新时来管理数据复制功能。由于通信框架可以将请求传递给任何可用的处理单元，所以每个处理单元包含完全一样的内存中数据就很关键。下图展示处理单元间如何同步数据复制，实际中是通过非常迅速的并行的异步复制来完成的，通常在微秒级。\n\n![](images/5-4.png)\n\n### 处理框架\n\n处理框架，就像下图所示，是虚拟化中间件中一个可选组件，负责管理在有多个处理单元时的分布式请求处理，每个处理单元可能只负责应用中的某个特定功能。如果请求需要处理单元间合作（比如，一个订单处理单元和顾客处理单元），此时处理框架就充当处理单元见数据传递的媒介。\n\n![](images/5-5.png)\n\n### 部署管理器\n\n部署管理器根据负载情况管理处理单元的动态启动和关闭。它持续监控响应时间和用户负载，在负载增加时启动新的处理单元，在负载下降时关闭处理单元。它是实现可变伸缩性需求的关键。\n\n## 其他考虑\n\n基于空间的架构是一个复杂和实现起来相对昂贵的框架。对于拥有可变负载的小型web应用是很好的选择，然而，对于拥有大量草错的传统大规模关系型数据库应用，并不那么适用。\n\n虽然基于空间的架构模型不需要集中式的数据储存，但通常还是需要这样一个，来进行初始化内存中数据框架，和异步的更新各处理单元的数据。通常也会创建一个单独的分区，来从隔离常用的断电就消失的数据和不常用的数据，这样减少处理单元之间对对方内存数据的依赖。\n\n值得注意的是，虽然这个架构的另一个名字是云架构，处理单元（以及虚拟化中间件）都没有放在云端服务或者PaaS上。他们同样可以简单的放在本地服务器，这也是为什么我更倾向叫它“基于空间的架构”。\n\n从产品实现的角度讲，这个架构中的很多组件都可以从第三方获得，比如GemFire, JavaSpaces, GigaSpaces，IBM Object Grid，nCache，和 Oracle Coherence。由于架构的实现根据工程的预算和需求而异，所以作为架构师，你应该在实现或选购第三方产品前首先明确你的目标和需求。\n\n## 架构分析\n\n下面的表格是这个架构的特征分析和评分。每个特征的评分是基于一个典型的架构实现来给出的。要知道这个模式相对别的模式的对比，请参见最后的附录A。\n\n#### 综合能力\n\n评分：高\n\n分析：综合能力是对环境变化做出快速反应的能力。因为处理单元（应用的部署实例）可以快速的启动和关闭，整个应用可以根据用户量和负载做出反应。使用这个架构通常在应对代码变化上，由于较小的应用规模和组件间相互依赖，也会反映良好。\n\n#### 部署难易程度\n\n评分：高\n\n分析：虽然基于空间的架构通常没有解耦合并且功能分布，但他们是动态的，也是成熟的基于云的工具，允许应用轻松的部署到服务器。\n\n#### 可测试性\n\n评分：低\n\n分析：测试高用户负载既昂贵又耗时，所以在测试架构的可伸缩性方面很困难\n\n#### 性能\n\n评分：高\n\n分析：通过内存中数据存取和架构中的缓存机制可获得高性能\n\n#### 伸缩性\n\n评分：高\n\n分析：高伸缩性是源于几乎不依赖集中式的数据库，从而去除了这个限制伸缩性的瓶颈。\n\n#### 开发难度\n\n评分：低\n\n分析：成熟的缓存机制和内存中数据框架使这个架构开发起来相对复杂，主要是因为难以熟悉这个架构开发所需要的工具和第三方产品。而且，开发过程中还需要特别注意源码不要对性能和可伸缩性造成不良影响。\n" }, { "path": "software-architecture-patterns/chapter01-BillonWang.md", "content": "# 第一章 分层架构 \n\nThe most common architecture pattern is the layered architecture pattern, otherwise known as the n-tier architecture pattern. This pattern is the de facto standard for most Java EE applications and therefore is widely known by most architects, designers, and devel‐ opers. The layered architecture pattern closely matches the tradi‐ tional IT communication and organizational structures found in most companies, making it a natural choice for most business appli‐ cation development efforts.\n\n分层架构是一种很常见的架构模式，它也叫N层架构。这种架构是大多数Jave EE应用的实际标准，因此很多的架构师，设计师，还有程序员都知道它。许多传统IT公司的组织架构和分层模式十分的相似。所以它很自然的成为大多数应用的架构模式。\n\n## Pattern Description\nComponents within the layered architecture pattern are organized into horizontal layers, each layer performing a specific role within the application (e.g., presentation logic or business logic). Although the layered architecture pattern does not specify the number and types of layers that must exist in the pattern, most layered architec‐ tures consist of four standard layers: presentation, business, persis‐ tence, and database (Figure 1-1). In some cases, the business layer and persistence layer are combined into a single business layer, par‐ ticularly when the persistence logic (e.g., SQL or HSQL) is embed‐ ded within the business layer components. Thus, smaller applications may have only three layers, whereas larger and more complex business applications may contain five or more layers.\n\n分层架构模式里的组件被分成几个平行的层次，每一层都代表了应用的一个功能(展示逻辑或者业务逻辑)。尽管分层架构没有规定自身要分成几层几种，大多数的结构都分成四个层次:展示层，业务层，持久层，和数据库层。如表1-1，有时候，业务层和持久层会合并成单独的一个业务层，尤其是持久层的逻辑绑定在业务层的组件当中。因此，有一些小的应用可能只有3层，一些有着更复杂的业务的大应用可能有5层或者更多的分层。\n\nEach layer of the layered architecture pattern has a specific role and responsibility within the application. For example, a presentation layer would be responsible for handling all user interface and browser communication logic, whereas a business layer would be responsible for executing specific business rules associated with the request. Each layer in the architecture forms an abstraction around the work that needs to be done to satisfy a particular business request. For example, the presentation layer doesn’t need to know or worry about how to get customer data; it only needs to display that information on a screen in particular format. Similarly, the business layer doesn’t need to be concerned about how to format customer data for display on a screen or even where the customer data is coming from; it only needs to get the data from the persis‐ tence layer, perform business logic against the data (e.g., calculate values or aggregate data), and pass that information up to the pre‐ sentation layer.\n\n分层架构中的每一层都着特定的角色和职能。举个例子，展示层负责处理所有的界面展示以及交互逻辑，业务层负责处理请求对应的业务。架构里的层次是具体工作的高度抽象，它们都是为了实现某种特定的业务请求。比如说展示层并不需要关心怎样得到用户数据，它只需在屏幕上以特定的格式展示信息。业务层并不关心要展示在屏幕上的用户数据格式，也不关心这些用户数据从哪里来。它只需要从持久层得到数据，执行与数据有关的相应业务逻辑，然后把这些信息传递给展示层。\n\n![1-1](images/1-1.png) \nFigure 1-1. Layered architecture pattern\n\nOne of the powerful features of the layered architecture pattern is the separation of concerns among components. Components within a specific layer deal only with logic that pertains to that layer. For example, components in the presentation layer deal only with pre‐ sentation logic, whereas components residing in the business layer deal only with business logic. This type of component classification makes it easy to build effective roles and responsibility models into your architecture, and also makes it easy to develop, test, govern, and maintain applications using this architecture pattern due to well-defined component interfaces and limited component scope.\n\n分层架构的一个突出特性是组件间关注点分离 (separation of concerns)。一个层中的组件只会处理本层的逻辑。比如说，展示层的组件只会处理展示逻辑，业务层中的组件只会去处理业务逻辑。多亏了组件分离，让我们更容易构造有效的角色和强力的模型。这样应用变的更好开发，测试，管理和维护。\n\n## Key Concepts\nNotice in Figure 1-2 that each of the layers in the architecture is marked as being closed. This is a very important concept in the lay‐ ered architecture pattern. A closed layer means that as a request moves from layer to layer, it must go through the layer right below it to get to the next layer below that one. For example, a request origi‐ nating from the presentation layer must first go through the busi‐ ness layer and then to the persistence layer before finally hitting the database layer.\n\n注意表1-2中每一层都是封闭的。这是分层架构中非常重要的特点。这意味request必须一层一层的传递。举个例子，从展示层传递来的请求首先会传递到业务层，然后传递到持久层，最后才传递到数据层。\n\n![1-2](images/1-2.png) \nFigure 1-2. Closed layers and request access\n\nSo why not allow the presentation layer direct access to either the persistence layer or database layer? After all, direct database access from the presentation layer is much faster than going through a bunch of unnecessary layers just to retrieve or save database infor‐ mation. The answer to this question lies in a key concept known as layers of isolation.\n\n那么为什么不允许展示层直接访问数据层呢。如果只是获得以及读取数据，展示层直接访问数据层，比穿过一层一层来得到数据来的快多了。这涉及到一个概念:层隔离。\n\nThe layers of isolation concept means that changes made in one layer of the architecture generally don’t impact or affect components in other layers: the change is isolated to the components within that layer, and possibly another associated layer (such as a persistence layer containing SQL). If you allow the presentation layer direct access to the persistence layer, then changes made to SQL within the persistence layer would impact both the business layer and the pre‐ sentation layer, thereby producing a very tightly coupled application with lots of interdependencies between components. This type of architecture then becomes very hard and expensive to change.\n\n层隔离就是说架构中的某一层的改变不会影响到其他层:这些变化的影响范围限于当前层次。如果展示层能够直接访问持久层了，假如持久层中的SQL变化了，这对业务层和展示层都有一定的影响。这只会让应用变得紧耦合，组件之间互相依赖。这种架构会非常的难以维护。\n\n\nThe layers of isolation concept also means that each layer is inde‐ pendent of the other layers, thereby having little or no knowledge of the inner workings of other layers in the architecture. To understand the power and importance of this concept, consider a large refactor‐ ing effort to convert the presentation framework from JSP (Java Server Pages) to JSF (Java Server Faces). Assuming that the contracts (e.g., model) used between the presentation layer and the business layer remain the same, the business layer is not affected by the refac‐ toring and remains completely independent of the type of user- interface framework used by the presentation layer.\n\n从另外一个方面来说，分层隔离使得层与层之间都是相互独立的，架构中的每一层的互相了解都很少。为了说明这个概念的牛逼之处，想象一个超级重构，把展示层从JSP换成JSF。假设展示层和业务层的之间的联系保持一致，业务层不会受到重构的影响，它和展示层所使用的界面架构完全独立。\n\nWhile closed layers facilitate layers of isolation and therefore help isolate change within the architecture, there are times when it makes sense for certain layers to be open. For example, suppose you want to add a shared-services layer to an architecture containing com‐ mon service components accessed by components within the busi‐ ness layer (e.g., data and string utility classes or auditing and logging classes). Creating a services layer is usually a good idea in this case because architecturally it restricts access to the shared services to the business layer (and not the presentation layer). Without a separate layer, there is nothing architecturally that restricts the presentation layer from accessing these common services, making it difficult to govern this access restriction.\n\n然而封闭的架构层次也有不便之处，有时候也应该开放某一层。如果想往包含了一些由业务层的组件调用的普通服务组件的架构中添加一个分享服务层。在这个例子里，新建一个服务层通常是一个好主意，因为从架构上来说，它限制了分享服务访问业务层(也不允许访问展示层)。如果没有隔离层，就没有任何架构来限制展示层访问普通服务，难以进行权限管理。\n\nIn this example, the new services layer would likely reside below the business layer to indicate that components in this services layer are not accessible from the presentation layer. However, this presents a problem in that the business layer is now required to go through the services layer to get to the persistence layer, which makes no sense at all. This is an age-old problem with the layered architecture, and is solved by creating open layers within the architecture.\nAs illustrated in Figure 1-3, the services layer in this case is marked as open, meaning requests are allowed to bypass this open layer and go directly to the layer below it. In the following example, since the services layer is open, the business layer is now allowed to bypass it and go directly to the persistence layer, which makes perfect sense.\n\n在这个例子中，新的服务层是处于业务层之下的，展示层不能直接访问这个服务层中的组件。但是现在业务层还要通过服务层才能访问到持久层，这一点也不合理。这是分层架构中的老问题了，解决的办法是开放某些层。如表1-3所示，服务层现在是开放的了。请求可以绕过这一层，直接访问这一层下面的层。既然服务层是开放的，业务层可以绕过服务层，直接访问数据持久层。这样就非常合理。\n\n![1-3](images/1-3.png) \nFigure 1-3. Open layers and request flow\n\nLeveraging the concept of open and closed layers helps define the relationship between architecture layers and request flows and also provides designers and developers with the necessary information to understand the various layer access restrictions within the architec‐ ture. Failure to document or properly communicate which layers in the architecture are open and closed (and why) usually results in tightly coupled and brittle architectures that are very difficult to test, maintain, and deploy.\n\n开放和封闭层的概念确定了架构层和请求流之间的关系，并且给设计师和开发人员提供了必要的信息理解架构里各种层之间的访问限制。如果随意的开放或者封闭架构里的层，整个项目可能都是紧耦合，一团糟的。以后也难以测试，维护和部署。\n\n\n## Pattern Example\n\nTo illustrate how the layered architecture works, consider a request from a business user to retrieve customer information for a particu‐ lar individual as illustrated in Figure 1-4. The black arrows show the request flowing down to the database to retrieve the customer data, and the red arrows show the response flowing back up to the screen to display the data. In this example, the customer informa‐ tion consists of both customer data and order data (orders placed by the customer).\n\n为了演示分层架构是如何工作的，想象一个场景，如表1-4，用户发出了一个请求要获得客户的信息。黑色的箭头是从数据库中获得用户数据的请求流，红色箭头显示用户数据的返回流的方向。在这个例子中，用户信息由客户数据和订单数组组成(客户下的订单)。\n\nThe customer screen is responsible for accepting the request and dis‐ playing the customer information. It does not know where the data is, how it is retrieved, or how many database tables must be queries to get the data. Once the customer screen receives a request to get customer information for a particular individual, it then forwards that request onto the customer delegate module. This module is responsible for knowing which modules in the business layer can process that request and also how to get to that module and what data it needs (the contract). The customer object in the business layer is responsible for aggregating all of the information needed by the business request (in this case to get customer information). This module calls out to the customer dao (data access object) module in the persistence layer to get customer data, and also the order dao module to get order information. These modules in turn execute SQL statements to retrieve the corresponding data and pass it back up to the customer object in the business layer. Once the customer object receives the data, it aggregates the data and passes that infor‐ mation back up to the customer delegate, which then passes that data to the customer screen to be presented to the user.\n\n用户界面只管接受请求以及显示客户信息。它不管怎么得到数据的，或者说得到这些数据要用到哪些数据表。如果用户界面接到了一个查询客户信息的请求，它就会转发这个请求给用户委托(Customer Delegate)模块。这个模块能找到业务层里对应的模块处理对应数据(约束关系)。业务层里的customer object聚合了业务请求需要的所有信息(在这个例子里获取客户信息)。这个模块调用持久层中的 customer dao 来得到客户信息，调用order dao来得到订单信息。这些模块会执行SQL语句，然后返回相应的数据给业务层。当 customer object收到数据以后，它就会聚合这些数据然后传递给 customer delegate,然后传递这些数据到customer screen 展示在用户面前。\n![1-4](images/1-4.png) \nFigure 1-4. Layered architecture example\n\nFrom a technology perspective, there are literally dozens of ways these modules can be implemented. For example, in the Java plat‐ form, the customer screen can be a (JSF) Java Server Faces screen coupled with the customer delegate as the managed bean compo‐ nent. The customer object in the business layer can be a local Spring bean or a remote EJB3 bean. The data access objects illustrated in the previous example can be implemented as simple POJO’s (Plain Old Java Objects), MyBatis XML Mapper files, or even objects encapsulating raw JDBC calls or Hibernate queries. From a Micro‐ soft platform perspective, the customer screen can be an ASP (active server pages) module using the .NET framework to access C# mod‐ ules in the business layer, with the customer and order data access modules implemented as ADO (ActiveX Data Objects).\n\n从技术的角度来说，有很多的方式能够实现这些模块。比如说在Java平台中，customer screen 对应的是 (JSF) Java Server Faces ,用 bean 组件来实现 customer delegate。用本地的Spring bean或者远程的EJB3 bean 来实现业务层中的customer object。上例中的数据访问可以用简单的POJP's(Plain Old Java Objects)，或者可以用MyBatis，还可以用JDBC或者Hibernate 查询。Microsoft平台上，customer screen能用 .NET 库的ASP模块来访问业务层中的C#模块，用ADO来实现用户和订单数据的访问模块。\n\n## Considerations\nThe layered architecture pattern is a solid general-purpose pattern, making it a good starting point for most applications, particularly when you are not sure what architecture pattern is best suited for your application. However, there are a couple of things to consider from an architecture standpoint when choosing this pattern.\n\n分层架构是一个很可靠的架构模式。它适合大多数的应用。如果你不确定在项目中使用什么架构，分层架构是再好不过的了。然后，从架构的角度上来说，选择这个模式还要考虑很多的东西。\n\nThe first thing to watch out for is what is known as the architecture sinkhole anti-pattern. This anti-pattern describes the situation where requests flow through multiple layers of the architecture as simple pass-through processing with little or no logic performed within each layer. For example, assume the presentation layer responds to a request from the user to retrieve customer data. The presentation layer passes the request to the business layer, which simply passes the request to the persistence layer, which then makes a simple SQL call to the database layer to retrieve the customer data. The data is then passed all the way back up the stack with no additional pro‐ cessing or logic to aggregate, calculate, or transform the data.\n\n第一个要注意的就是 污水池反模式(architecture sinkhole anti-pattern)。\n在这个模式中，请求流只是简单的穿过层次，不留一点云彩，或者说只留下一阵青烟。比如说界面层响应了一个获得数据的请求。响应层把这个请求传递给了业务层，业务层也只是传递了这个请求到持久层，持久层对数据库做简单的SQL查询获得用户的数据。这个数据按照原理返回，不会有任何的二次处理，返回到界面上。\n\nEvery layered architecture will have at least some scenarios that fall into the architecture sinkhole anti-pattern. The key, however, is to analyze the percentage of requests that fall into this category. The 80-20 rule is usually a good practice to follow to determine whether or not you are experiencing the architecture sinkhole anti-pattern. It is typical to have around 20 percent of the requests as simple pass- through processing and 80 percent of the requests having some business logic associated with the request. However, if you find that this ratio is reversed and a majority of your requests are simple pass- through processing, you might want to consider making some of the architecture layers open, keeping in mind that it will be more diffi‐ cult to control change due to the lack of layer isolation.\n\n每个分层架构或多或少都可能遇到这种场景。关键在于这样的请求有多少。80-20原则可以帮助你确定架构是否处于反污水模式。大概有百分之二十的请求仅仅是做简单的穿越，百分之八十的请求会做一些业务逻辑操作。然而，如果这个比例反过来，大部分的请求都是仅仅穿过层，不做逻辑操作。那么开放一些架构层会比较好。不过由于缺少了层次隔离，项目会变得难以控制。\n\nAnother consideration with the layered architecture pattern is that it tends to lend itself toward monolithic applications, even if you split the presentation layer and business layers into separate deployable units. While this may not be a concern for some applications, it does pose some potential issues in terms of deployment, general robust‐ ness and reliability, performance, and scalability.\n另外一个要考虑的是分层模式会导致项目变得巨大无比，即使你的展示层和业务层可以单独发布。某些小应用可能会无视这个问题，不过他的确会导致一些潜在的问题，比如说分布模式复杂，总体的健壮性和可靠性，性能和规模等。\n\n## Pattern Analysis\nThe following table contains a rating and analysis of the common architecture characteristics for the layered architecture pattern. The rating for each characteristic is based on the natural tendency for that characteristic as a capability based on a typical implementa‐ tion of the pattern, as well as what the pattern is generally known for. For a side-by-side comparison of how this pattern relates to other patterns in this report, please refer to Appendix A at the end of this report.\n\n下面的的表里分析了分层架构的各个方面。\n\n### Overall agility 整体灵活性\nRating: Low \nAnalysis: Overall agility is the ability to respond quickly to a constantly changing environment. While change can be isolated through the layers of isolation feature of this pattern, it is still cumbersome and time-consuming to make changes in this architecture pattern because of the monolithic nature of most implementations as well as the tight coupling of components usually found with this pattern.\n评级:低\n分析:总体灵活性是响应环境变化的能力。尽管分层模式中的变化可以隔绝起来，想在这种架构中做一些也改变也是并且费时费力的。分层模式的笨重以及经常出现的组件之间的紧耦合是导致灵活性降低的原因。\n\n### Ease of deployment 部署难易度\nRating: Low \nAnalysis: Depending on how you implement this pattern, deployment can become an issue, particularly for larger applica‐ tions. One small change to a component can require a redeployment of the entire application (or a large portion of the application), resulting in deployments that need to be planned, scheduled, and executed during off-hours or on weekends. As such, this pattern does not easily lend itself toward a contin‐ uous delivery pipeline, further reducing the overall rating for deployment.\n评级:低\n分析:这取决于你怎么发布这种模式，发布程序可能比较麻烦，尤其是很大的项目。一个组件的小小改动可能会影响到整个程序的发布(或者程序的大部分)。发布必须是按照计划，在非工作时间或者周末进行发布。因此。分层模式导致应用发布一点也不流畅，在发布上降低了灵活性。\n\n### Testability 可测试性\nRating: High \nAnalysis: Because components belong to specific layers in the architecture, other layers can be mocked or stubbed, making this pattern is relatively easy to test. A developer can mock a presentation component or screen to isolate testing within a business component, as well as mock the business layer to test certain screen functionality.\n评级:高\n分析:因为组件都处于各自的层次中，可以模拟其他的层，或者说直接去掉层，所以分层模式很容易测试。开发者可以单独模拟一个展示组件，对业务组件进行隔绝测试。还可以年模拟业务层来测试某个展示功能。\n\n### Performance 性能\nRating: Low \nAnalysis: While it is true some layered architectures can per‐ form well, the pattern does not lend itself to high-performance applications due to the inefficiencies of having to go through multiple layers of the architecture to fulfill a business request.\n评级:低\n分析:尽管某些分层架构的性能表现的确不错，但是这个模式的特点导致它无法带来高性能。因为一次业务请求要穿越所有的架构层，做了很多不必要的工作。\n\n### Scalability 伸缩性\nRating: Low \nAnalysis: Because of the trend toward tightly coupled and mon‐ olithic implementations of this pattern, applications build using this architecture pattern are generally difficult to scale. You can scale a layered architecture by splitting the layers into separate physical deployments or replicating the entire application into multiple nodes, but overall the granularity is too broad, making it expensive to scale.\n评级:低\n分析:由于这种模式以紧密耦合的趋势在发展，规模也比较大，用分层架构构建的程序都比较难以扩展。你可以把各个层分成单独的物理模块或者干脆把整个程序分成多个节点来扩展分层架构，但是总体的关系过于紧密，这样很难扩展。\n\n### Ease of development 易开发性\nRating: High \nAnalysis: Ease of development gets a relatively high score, mostly because this pattern is so well known and is not overly complex to implement. Because most companies develop appli‐ cations by separating skill sets by layers (presentation, business, database), this pattern becomes a natural choice for most business-application development. The connection between a company’s communication and organization structure and the way it develops software is outlined is what is called Conway’s law. You can Google “Conway’s law\" to get more information about this fascinating correlation.\n评级:容易\n分析:在开发难度上面，分层架构得到了比较高的分数。因为这种架构对大家来说很熟悉，不难实现。大部分公司在开发项目的都是通过层来区分技术的，这种模式对于大多数的商业项目开发来说都很合适。公司的组织架构和他们软件架构之间的联系被戏称为\"Conway's law\"。你可以Google一下查查这个有趣的联系。\n" }, { "path": "software-architecture-patterns/chapter02-chaossss.md", "content": "# 第二章 事件驱动架构\n\n> 译者注：文章中 mediator 及 broker 的概念很容易混淆，在文章的结尾处译者对两者的区别（还有 proxy）进行了一定的阐述\n\nThe event-driven architecture pattern is a popular distributed asynchronous architecture pattern used to produce highly scalable applications. It is also highly adaptable and can be used for small applications and as well as large, complex ones. The event-driven architecture is made up of highly decoupled, single-purpose event processing components that asynchronously receive and process events. \n\n事件驱动架构模式是一种主流的异步分发事件架构模式，常用于设计高度可拓展的应用。当然了，它有很高的适应性，使得它在小型应用、大型应用、复杂应用中都能表现得很好。事件驱动架构模式由高度解耦、单一目的的事件处理组件构成，这些组件负责异步接收和处理事件。\n\nThe event-driven architecture pattern consists of two main topolo‐ gies, the mediator and the broker. The mediator topology is com‐ monly used when you need to orchestrate multiple steps within an event through a central mediator, whereas the broker topology is used when you want to chain events together without the use of a central mediator. Because the architecture characteristics and imple‐ mentation strategies differ between these two topologies, it is impor‐ tant to understand each one to know which is best suited for your particular situation.\n\n事件驱动架构模式包含了两种主要的拓扑结构：**中介(mediator)**拓扑结构和**代理(broker)**拓扑结构。 mediator 拓扑结构通常在你需要在一个事件内使用一个核心中介分配、协调多个步骤间的关系、执行顺序时被使用；而代理拓扑结构则在你想要不通过一个核心中介将多个事件串联在一起时被使用。由于这两种结构在结构特征和实现策略上有很大的差别，所以如果你想要在你的应用中使用它们的话，一定要深入理解两者的技术实现细节，从而为你的实际使用场景选择最合理的结构。\n\n## Mediator Topology\n## 中介拓扑结构\n\nThe mediator topology is useful for events that have multiple steps and require some level of orchestration to process the event. For example, a single event to place a stock trade might require you to first validate the trade, then check the compliance of that stock trade against various compliance rules, assign the trade to a broker, calcu‐ late the commission, and finally place the trade with that broker. All of these steps would require some level of orchestration to deter‐\nmine the order of the steps and which ones can be done serially and in parallel.\n\n中介拓扑结构适合用于拥有多个步骤，并需要在处理事件时能通过某种程度的协调将事件分层的场景，举例来说吧：假设你现在需要进行股票交易，那你首先需要证券所批准你进行交易，然后检查进行这次交易是否违反了股票交易的某种规定，检查完成后将它交给一个经纪人，计算佣金，最后与经纪人确认交易。以上所有步骤都需要通过中介进行某种程度的分配和协调，以决定各个步骤的执行顺序，判断哪些步骤可以并行，哪些步骤可以串行。\n\nThere are four main types of architecture components within the mediator topology: event queues, an event mediator, event channels, and event processors. The event flow starts with a client sending an event to an event queue, which is used to transport the event to the event mediator. The event mediator receives the initial event and orchestrates that event by sending additional asynchronous events to event channels to execute each step of the process. Event process‐ ors, which listen on the event channels, receive the event from the event mediator and execute specific business logic to process the event. Figure 2-1 illustrates the general mediator topology of the event-driven architecture pattern.\n\n在中介拓扑结构中主要有四种组件：事件队列（event queue）, 事件中介, 事件通道（event channel）, 和 事件处理器（event processor）。当事件流需要被处理，客户端将一个事件发送到某个事件队列中，由消息队列将其运输给事件中介进行处理和分发。事件中介接收到该消息后，并通过将额外的异步事件发送给事件通道，让事件通道执行该异步事件中的每一个步骤，使得事件中介能够对事件进行分配、协调。同时，又因为事件处理器是事件通道的监听器，所以事件通道对异步事件的处理会触发事件处理器的监听事件，使事件处理器能够接收来自事件中介的事件，执行事件中具体的业务逻辑，从而完成对传入事件的处理。事件驱动架构模式中的中介拓扑模式结构大体如下图：\n\n![2-1](images/2-1.png)\n\nIt is common to have anywhere from a dozen to several hundred event queues in an event-driven architecture. The pattern does not specify the implementation of the event queue component; it can be a message queue, a web service endpoint, or any combination thereof.\n\n在事件驱动架构中拥有十几个，甚至几百个事件队列是很常见的情况，该模式并没有对事件队列的实现有明确的要求，这就意味着事件队列可以是消息队列，Web 服务端，或者其它类似的东西。\n\nThere are two types of events within this pattern: an initial event and a processing event. The initial event is the original event received by the mediator, whereas the processing events are ones that are generated by the mediator and received by the event-processing components.\n\n在事件驱动架构模式中主要有两种事件：初始事件和待处理事件。初始事件是中介所接收到的最原始的事件，没有经过其他组件的处理；而待处理事件是由事件中介生成，由事件处理器接收的组件，不能把待处理事件看作初始事件经过处理后得到的事件，两者是完全不同的概念。\n\nThe event-mediator component is responsible for orchestrating the steps contained within the initial event. For each step in the ini‐ tial event, the event mediator sends out a specific processing event to an event channel, which is then received and processed by the event processor. It is important to note that the event mediator doesn’t actually perform the business logic necessary to process the initial event; rather, it knows of the steps required to process the ini‐ tial event.\n\n事件中介负责分配、协调初始事件中的各个待执行步骤，事件中介需要为每一个初始事件中的步骤发送一个特定的待处理事件到事件通道中，触发事件处理器接收和处理该待处理事件。这里需要注意的是：事件 中介没有真正参与到对初始事件必须处理的业务逻辑的实现之中；相反，事件中介只是知道初始事件中有哪些步骤需要被处理。\n\nEvent channels are used by the event mediator to asynchronously pass specific processing events related to each step in the initial event to the event processors. The event channels can be either mes‐ sage queues or message topics, although message topics are most widely used with the mediator topology so that processing events can be processed by multiple event processors (each performing a different task based on the processing event received).\n\n事件中介通过事件通道将与初始事件每一个执行步骤相关联的特定待处理事件传递给事件处理器。尽管我们通常在待处理事件能被多个事件处理器处理时才会在中介拓扑结构中使用 message topics，但事件通道仍可以是消息队列或 message topics（不知道译作啥……）。（但需要注意的是，尽管在使用 message topics 时待处理事件能被多个事件处理器处理，但由于接收到的待处理事件各异，所以对其处理的操作也各不相同）\n\nThe event processor components contain the application business logic necessary to process the processing event. Event processors are self-contained, independent, highly decoupled architecture compo‐ nents that perform a specific task in the application or system. While the granularity of the event-processor component can vary from fine-grained (e.g., calculate sales tax on an order) to coarse- grained (e.g., process an insurance claim), it is important to keep in mind that in general, each event-processor component should per‐ form a single business task and not rely on other event processors to complete its specific task.\n\n为了能顺利处理待处理事件，事件处理器组件中包含了应用的业务逻辑。此外，事件处理器作为事件驱动架构中的组件，不依赖于其他组件，独立运作，高度解耦，在应用或系统中完成特定的任务。当事件处理器需要处理的事件从细粒度（例如：计算订单的营业税）变为粗粒度（例如：处理一项保险索赔事务），必须要注意的是：一般来说，每一个事件处理器组件都只完成一项唯一的业务工作，并且事件处理器在完成其特定的业务工作时不能依赖其他事件处理器。\n\nThe event mediator can be implemented in a variety of ways. As an architect, you should understand each of these implementation options to ensure that the solution you choose for the event media‐ tor matches your needs and requirements.\n\n虽然事件中介有许多方法可以实现，但作为一名架构工程师，你应该了解所有实现方式，以确保你能为你的实际需求选择了最合适的事件中介。\n\nThe simplest and most common implementation of the event medi‐ ator is through open source integration hubs such as Spring Integra‐ tion, Apache Camel, or Mule ESB. Event flows in these open source integration hubs are typically implemented through Java code or a DSL (domain-specific language). For more sophisticated mediation and orchestration, you can use BPEL (business process execution language) coupled with a BPEL engine such as the open source Apache ODE. BPEL is a standard XML-like language that describes the data and steps required for processing an initial event. For very large applications requiring much more sophisticated orchestration (including steps involving human interactions), you can implement the event mediator using a business process manager (BPM) such as jBPM.\n\n事件中介最简单、常见的实现就是使用开源框架，例如：Spring Integration，Apache Camel，或 Mule ESB。事件流在这些开源框架中通常用 Java 或 域特定语言（domain-specific language）。在调节过程和业务流程都很复杂的使用场景下，你可以使用业务流程执行语言（BPEL - business process execution language）结合类似开源框架 Apache ODE 的 BPEL 引擎进行开发。BPEL 是一种基于 XML 的服务编制编程语言，它为处理初始事件时需要描述的数据和步骤提供了描述。对每一个拥有复杂业务流程（包括与用户交互的执行步骤）的大型应用来说，你可以使用类似 jBPM 的业务处理管理系统（business process manager）实现事件中介。\n\nUnderstanding your needs and matching them to the correct event mediator implementation is critical to the success of any event- driven architecture using this topology. Using an open source inte‐ gration hub to do very complex business process management orchestration is a recipe for failure, just as is implementing a BPM solution to perform simple routing logic.\n\n如果你需要使用中介拓扑结构，那么理解你的需求，并为其匹配恰当的事件中介实现是构建事件驱动架构过程中至关重要的一环。使用开源框架去解决非常复杂的业务处理、管理、调节事件，注定会失败，因为开源框架只是用 BPM 的方式解决了一些简单的事件分发逻辑，比起你的业务逻辑，其中的事件分发逻辑简直是九牛一毛。\n\nTo illustrate how the mediator topology works, suppose you are insured through an insurance company and you decide to move. In this case, the initial event might be called something like relocation event. The steps involved in processing a relocation event are con‐ tained within the event mediator as shown in Figure 2-2. For each initial event step, the event mediator creates a processing event (e.g., change address, recalc quote, etc.), sends that processing event to the event channel and waits for the processing event to be processed by the corresponding event processor (e.g., customer process, quote process, etc.). This process continues until all of the steps in the ini‐ tial event have been processed. The single bar over the recalc quote and update claims steps in the event mediator indicates that these steps can be run at the same time.\n\n为了解释清楚中介拓扑结构是怎么运作的，我假设你在某家保险公司买了保险，成为了受保人，然后你打算搬家。在这种情况下，初始事件就是重定位事件，或者其他类似的事件。与重定位事件相关的处理步骤就像下图展示的那样，处于事件中介之中。对每一个初始事件的传入，事件中介都会创建一个待处理事件（例如：改变地址，重新计算保险报价，等等……），并将它发送给事件通道，等到待处理事件被发出响应的事件处理器处理（例如：客户改变地址的操作流程、报价计算流程，等等……）。直到初始事件中的每一个需要处理的步骤完成了，这项处理才会继续（例如：把所有手续都完成之后，保险公司才会帮你改变地址）。事件中介中，位于重新计算保险报价和更新请求前的小竖杠表示表示这些步骤可以并行处理。\n\n![2-1](images/2-2.png)\n\n## Broker Topology\n## 代理拓扑结构\n\nThe broker topology differs from the mediator topology in that there is no central event mediator; rather, the message flow is dis‐ tributed across the event processor components in a chain-like fashion through a lightweight message broker (e.g., ActiveMQ, HornetQ, etc.). This topology is useful when you have a relatively simple event processing flow and you do not want (or need) central event orchestration.\n\n代理拓扑结构与中介拓扑结构不同之处在于：代理拓扑结构中没有核心的事件中介；相反，事件流在代理拓扑结构中通过一个轻量的消息代理（例如：ActiveMQ, HornetQ，等等……）将消息串联成链状，分发至事件处理器组件中进行处理。代理扑结构适用的使用场景大致上具有以下特征：你的事件处理流相对来说比较简单，而且你不想（不需要）使用核心的事件分配、调节机制以提高你处理事件的效率。\n\nThere are two main types of architecture components within the broker topology: a broker component and an event processor compo‐ nent. The broker component can be centralized or federated and contains all of the event channels that are used within the event flow.\n\n在代理拓扑结构中主要包括两种组件：代理和事件处理器。代理可被集中或相互关联在一起使用，此外，代理中还可以包含所有事件流中使用的事件通道。\n\nThe event channels contained within the broker component can be message queues, message topics, or a combination of both.\n\n存在于代理组件中的事件通道可以是消息队列，消息主题,或者是两者的组合。\n\nThis topology is illustrated in Figure 2-3. As you can see from the diagram, there is no central event-mediator component controlling and orchestrating the initial event; rather, each event-processor component is responsible for processing an event and publishing a new event indicating the action it just performed. For example, an event processor that balances a portfolio of stocks may receive an initial event called stock split. Based on that initial event, the event processor may do some portfolio rebalancing, and then publish a new event to the broker called rebalance portfolio, which would then be picked up by a different event processor. Note that there may be times when an event is published by an event processor but not picked up by any another event processor. This is common when you are evolving an application or providing for future functionality and extensions.\n\n代理拓扑结构大致如下图，如你所见，在这其中没有一个核心的事件中介组件控制和分发初始事件；相反，每一个事件处理器只负责处理一个事件，并向外发送一个事件，以标明其刚刚执行的动作。例如，假设存在一个事件处理器用于平衡证券交易，那么事件处理器可能会接受一个拆分股票的初始事件，为了处理这项初始事件，事件处理器则需要重新平衡股票的投资金额，而这个重新平衡的事件将由另一个事件处理器接收、处理。在这其中有一个细节需要注意：处理初始事件后，由事件处理器发出的事件不被其他事件处理器接收、处理的情况时常会发生，尤其是你在为应用添加功能和进行功能拓展时，这种情况更为常见。\n\n![2-3](images/2-3.png)\n\nTo illustrate how the broker topology works, we’ll use the same example as in the mediator topology (an insured person moves). Since there is no central event mediator to receive the initial event in the broker topology, the customer-process component receives the event directly, changes the customer address, and sends out an event saying it changed a customer’s address (e.g., change address event). In this example, there are two event processors that are interested in the change address event: the quote process and the claims process. The quote processor component recalculates the new auto- insurance rates based on the address change and publishes an event to the rest of the system indicating what it did (e.g., recalc quote event). The claims processing component, on the other hand, receives the same change address event, but in this case, it updates an outstanding insurance claim and publishes an event to the system as an update claim event. These new events are then picked up by other event processor components, and the event chain continues through the system until there are no more events are published for that par‐ ticular initiating event.\n\n为了阐明代理拓扑结构的运行机制，我会用一个与讲解中介拓扑结构时类似的例子（受保人旅行的例子）进行解释。因为在代理拓扑结构中没有核心事件中介接收初始事件，那么事件将由客户自处理组件直接接收，改变客户的地址，并发出一个事件告知系统客户的地址被其进行了改变（例如：改变地址的事件）。在这个例子中：有两个事件处理器会与改变地址的事件产生关联：报价处理和索赔处理。报价事件处理器将根据受保人的心地址重新计算保险的金额，并发出事件告知系统该受保人的保险金额被其改变。而索赔事件处理器将接受到相同的改变地址事件，不同的是，它将更新保险的赔偿金额，并发出一个更新索赔金额事件告知系统该受保人的赔偿金额被其改变。当这些新的事件被其他事件处理器接收、处理，使事件链一环扣一环地交由系统处理，直到事件链上的所有事件都被处理完，初始事件的处理才算完成。\n\n![2-4](images/2-4.png) \n\nAs you can see from Figure 2-4, the broker topology is all about the chaining of events to perform a business function. The best way to understand the broker topology is to think about it as a relay race. In a relay race, runners hold a baton and run for a certain distance, then hand off the baton to the next runner, and so on down the chain until the last runner crosses the finish line. In relay races, once a runner hands off the baton, she is done with the race. This is also true with the broker topology: once an event processor hands off the event, it is no longer involved with the processing of that spe‐ cific event.\n\n如上图所示，代理拓扑结构的设计思想就是将对事件流的处理转换为对事件链的业务功能处理，把代理拓扑结构看作是接力比赛是最好的理解方式：在一场4*100的接力比赛中，每一位运动员都需要拿着一根接力棒跑100米，运动员跑完自己的100米后需要将接力棒传递给下一位运动员，直到最后一位运动员拿着接力棒跑过终点线，整场接力比赛才算结束。根据这样的逻辑我们还可以知道：在代理拓扑结构中，一旦某个事件处理器将事件传递给另一个事件处理器，那么这个事件处理器不会与该事件的后续处理产生任何联系。\n\n## Considerations\n## 使用事件驱动架构模式的顾虑\n\nThe event-driven architecture pattern is a relatively complex pattern to implement, primarily due to its asynchronous distributed nature. When implementing this pattern, you must address various dis‐ tributed architecture issues, such as remote process availability, lack of responsiveness, and broker reconnection logic in the event of a broker or mediator failure.\n\n实现事件驱动架构模式相对于实现其他架构模式会更困难一些，因为它通过异步处理进行事件分发。当你需要在你的应用中使用这种架构模式，你必须处理各种由事件分发处理带来的问题，例如：远程操作功能的可用性，缺少权限，以及在代理或中介中处理事件失败时，用于处理这种情况的重连逻辑。如果你不能很好地解决这些问题，那你的应用一定会出现各种 Bug，让开发团队痛苦不已。\n\nOne consideration to take into account when choosing this architec‐ ture pattern is the lack of atomic transactions for a single business process. Because event processor components are highly decoupled and distributed, it is very difficult to maintain a transactional unit of work across them. For this reason, when designing your application using this pattern, you must continuously think about which events can and can’t run independently and plan the granu‐ larity of your event processors accordingly. If you find that you need to split a single unit of work across event processors—that is, if you are using separate processors for something that should be an undivided transaction—this is probably not the right pattern for your application.\n\n在选择事件驱动架构时还有一点需要注意：在处理单个业务逻辑时，这种架构模式不能处理细粒度的事务。因为事件处理器都高度解耦、并且广泛分布，这使得在这些事件处理器中维持一个业务单元变得非常困难。因此，当你使用这种架构模式架构你的应用时，你必须不断地考虑哪些事件能单独被处理，哪些不能，并为此设计相应事件处理器的处理粒度。如果你发现你需要将一个业务单元切割成许多子单元，并一一匹配相应的事件处理器，那你就要为此进行代码设计；如果你发现你用多个不同的事件处理器处理的哪些业务其实是可以合并到一个业务事件之中的，那么这种模式可能并不适合你的应用，又或者是你的设计出了问题。\n\nPerhaps one of the most difficult aspects of the event-driven archi‐ tecture pattern is the creation, maintenance, and governance of the event-processor component contracts. Each event usually has a spe‐ cific contract associated with it (e.g., the data values and data format being passed to the event processor). It is vitally important when using this pattern to settle on a standard data format (e.g., XML, JSON, Java Object, etc.) and establish a contract versioning policy right from the start.\n\n使用事件驱动架构模式最困难的地方就在于架构的创建、维护、以及对事件处理器的管理。通常每一个事件都拥有其指定的事件处理协议（例如：传递给事件处理器的数据类型、数据格式），这就使得设下标准的数据格式成为使用事件驱动架构模式中至关重要的一环（例如：XML，JSON，Java 对象，等等……），并在架构创建之初就为这些数据格式授权，以便处理。\n\n## Pattern Analysis\n## 事件驱动架构模式分析\n\nThe following table contains a rating and analysis of the common architecture characteristics for the event-driven architecture pattern. The rating for each characteristic is based on the natural tendency for that characteristic as a capability based on a typical implementa‐ tion of the pattern, as well as what the pattern is generally known for. For a side-by-side comparison of how this pattern relates to other patterns in this report, please refer to Appendix A at the end of this report.\n\n下面是基于对常见的架构模式特征进行评价的标准，对事件驱动架构模式所作的实际分析，评价是以常见的架构模式的相似实现作为标准进行的，如果你想知道进行对比的其他架构模式对应的特征，可以结尾处查看 Appendix A 的汇总表。\n\n### Overall agility\nRating: High \n\n### 整体灵活性\n评价：高\n\nAnalysis: Overall agility is the ability to respond quickly to a constantly changing environment. Since event-processor com‐ ponents are single-purpose and completely decoupled from other event processor components, changes are generally iso‐ lated to one or a few event processors and can be made quickly without impacting other components.\n\n分析：整体灵活性用于评价架构能否在不断改变的使用场景下快速响应，因为事件处理器组件使用目的单一、高度解耦、与其他事件处理器组件相互独立，不相关联，那么发生的改变对一个或多个事件处理器来说普遍都是独立的，使得对改变的反馈非常迅速，不需要依赖其他事件处理器的响应作出处理。\n\n### Ease of deployment\nRating: High \n\n## 部署灵活性\n评价：高\n\nAnalysis: Overall this pattern is relatively easy to deploy due to the decoupled nature of the event-processor components. The broker topology tends to be easier to deploy than the mediator topology, primarily because the event mediator com‐ ponent is somewhat tightly coupled to the event processors: a change in an event processor component might also require a change in the event mediator, requiring both to be deployed for any given change.\n\n分析：总的来看，事件驱动架构模式由于其高度解耦的事件处理器组件的存在，对事件的部署相对来说比较容易，而使用代理拓扑结构比使用中介拓扑结构进行事件调度会更容易一些，主要是因为在 中介拓扑结构中事件处理器与事件中介紧密地耦合在一起：事件处理器中产生的告别会引起事件中介的改变，如果我们需要让某个被处理的事件被改变，那么我们需要同时调度事件处理器和事件中介。\n\n### Testability\nRating: Low \n\n### 可测试性\n评价：低\n\nAnalysis: While individual unit testing is not overly difficult, it does require some sort of specialized testing client or testing tool to generate events. Testing is also complicated by the asyn‐ chronous nature of this pattern.\n\n分析：虽然在事件驱动架构模式中进行单元测试并不困难，但如果我们要进行单元测试，我们就需要某种特定的测试客户端或者是测试工具产生事件，为单元测试提供初始值。此外，由于事件驱动架构模式是异步进行事件分发的，其异步处理的特性也为单元测试带来了一定的困难。\n\n### Performance\nRating: High \n\n### 性能表现\n评价：高\n\nAnalysis: While it is certainly possible to implement an event- driven architecture that does not perform well due to all the messaging infrastructure involved, in general, the pattern ach‐ ieves high performance through its asynchronous capabili‐ ties; in other words, the ability to perform decoupled, parallel asynchronous operations outweighs the cost of queuing and dequeuing messages.\n\n分析：对消息传递的架构可能会让设计出来的事件驱动架构的表现不如我们的期望，但通常来说，该模式都能通过其异步处理的特性展示优秀的性能表现；换句话来说，高度解耦，异步并行操作大大减少了传递消息过程中带来的时间开销。\n\n### Scalability\nRating: High \n\n### 可拓展性\n评价：高\n\nAnalysis: Scalability is naturally achieved in this pattern through highly independent and decoupled event processors. Each event processor can be scaled separately, allowing for fine-grained scalability.\n\n分析：事件驱动架构中的高度解耦、相互独立的事件处理器组件的存在，使得可拓展性成为该架构与生俱来的优点。架构的这些特定使得事件处理器能够进行细粒度的拓展，使得每一个事件处理器都能单独被拓展，而不影响其他事件处理器。\n\n### Ease of development\nRating: Low \n\n### 开发的简易性\n评价：低\n\nAnalysis: Development can be somewhat complicated due to the asynchronous nature of the pattern as well as contract cre‐ ation and the need for more advanced error handling condi‐ tions within the code for unresponsive event processors and failed brokers.\n\n分析：由于使用事件驱动架构进行开发需要考虑其异步处理机制、协议创建流程，并且开发者需要用代码为事件处理器和操作失败的代理提供优秀的错误控制环境，无疑使得用事件驱动架构进行开发会比使用其他架构进行开发要困难一些。\n\n## 译者注\n\n读完整篇文章，我相信大家对 mediator 与 broker 这两个概念有一个大致的印象，但就两者的译文来看，中介和代理似乎没什么区别，特别是了解 proxy 的读者会更加困惑，这三者之间到底是什么关系？它们的概念是互通的吗？为了解决这种混淆，译者将在此阐述三者间的区别：\n\n假如现在我有一个事件/事件流需要被处理，那么使用 mediator、broker、proxy 处理事件的区别在哪里呢？\n\n- 如果我们使用 mediator，那就意味着我将把事件流交给 mediator，mediator 会帮我把事件分解为多个步骤，并分析其中的执行逻辑，调整和分发事件（例如判断哪些事件可以并行，哪些事件可以串行），然后根据 mediator 分解、调节的结果去执行事件中的每一个步骤，把所有步骤完成后，就能把需要处理的事件处理好。\n\n- 如果我们使用 broker，那就意味着我将把事件交给 broker，broker 获得事件后会把事件发出去（在本文中为：通知架构中所有可用的事件处理器），事件处理器们接收到事件以后，判断处理这个事件是否为自己的职责之一，如果不是则无视，与自己有关则把需要完成的工作完成，完成后如果事件还有后续需要处理的事件，则通过 broker 再次发布，再由相关的事件处理器接收、处理。以这样的方式将事件不断分解，沿着事件链一级一级地向下处理子事件，直到事件链中的所有事件被完成，我的事件也就处理好了。\n\n- 如果我们使用 proxy，那就意味着我自己对需要处理的事件进行了分解，然后把不同的子事件一一委托给不同的 proxy，由被委托的 proxy 帮我完成子事件，从而完成我要做的事件。" }, { "path": "software-architecture-patterns/chapter03-Mr.Simple.md", "content": "# 第三章 微内核架构\n\rThe microkernel architecture pattern (sometimes referred to as the plug-in architecture pattern) is a natural pattern for implementing product-based applications. A product-based application is one that is packaged and made available for download in versions as a typical third-party product. However, many companies also develop and release their internal business applications like software products, complete with versions, release notes, and pluggable features. These are also a natural fit for this pattern. The microkernel architecture pattern allows you to add additional application features as plug-ins to the core application, providing extensibility as well as feature separation and isolation.\r\r微内核架构模式(也称为插件化应用架构)对于基于产品的应用程序来说是一个很自然的选择。基于产品的应用是指一个经过打包的、可以通过版本下载的一个典型的第三方产品。然而，很多公司也会开发和发布他们的内部商业软件，完整的版本号、发布日志和可插拔的新特性，这些就非常符合微内核架构的思想。微内核架构模式可以通过插件的形式添加额外的特性到核心系统中，这提供了很好的扩展性，也使得新特性与核心系统隔离开来。( 译者注: 比如，著名的Eclipse IDE就是基于插件化开发的，eclipse核心更像是一个微内核，或者我们可把它叫做开放平台，其他的功能通过安装插件的形式添加到eclipse中。 )\r\r## Pattern Description 模式描述\rThe microkernel architecture pattern consists of two types of archi‐ tecture components: a core system and plug-in modules. Application logic is divided between independent plug-in modules and the basic core system, providing extensibility, flexibility, and isolation of application features and custom processing logic. Figure 3-1 illustrates the basic microkernel architecture pattern. \n\n微内核架构主要包含两种架构组件: 核心系统和插件模块。应用逻辑被划分为独立的插件模块和核心系统，这样就提供良好的可扩展性、灵活性，应用的新特性和自定义处理逻辑也会被隔离。图3-1演示了基本的微内核架构。\n\rThe core system of the microkernel architecture pattern tradition‐ ally contains only the minimal functionality required to make the system operational. Many operating systems implement the micro‐ kernel architecture pattern, hence the origin of this pattern’s name. From a business-application perspective, the core system is often defined as the general business logic sans custom code for special cases, special rules, or complex conditional processing.\n\n微内核架构的核心系统一般情况下只包含一个能够使系统运作起来的最小化模块。很多操作系统的实现就是使用微内核架构，因此这也是该架构名字的由来。从商业应用的角度看，核心系统通常是为特定的使用场景、规则、或者复杂条件处理定义了通用的业务逻辑，而插件模块根据这些规则实现了具体的业务逻辑。\n\n![3-1](images/3-1.png)\r图 3-1. 微内核架构\r\rThe plug-in modules are stand-alone, independent components that contain specialized processing, additional features, and custom code that is meant to enhance or extend the core system to produce additional business capabilities. Generally, plug-in modules should be independent of other plug-in modules, but you can certainly design plug-ins that require other plug-ins to be present. Either way, it is important to keep the communication between plug-ins to a minimum to avoid dependency issues. \n\n插件模块是一个包含专业处理、额外特性的独立组件，自定义代码意味着增加或者扩展核心系统以达到产生附加的业务逻辑的能力。通常，插件模块之间应该是没有任何依赖性的，但是你也可以设计一个需要依赖另一个插件的插件。但无论如何，重要的是，插件之间的通信要保持在最低限度，以避免因依赖导致的问题出现。\n\rThe core system needs to know about which plug-in modules are available and how to get to them. One common way of implementing this is through some sort of plug-in registry. This registry contains information about each plug-in module, including things like its name, data contract, and remote access protocol details (depending on how the plug-in is connected to the core system). For example, a plug-in for tax software that flags high-risk tax audit items might have a registry entry that contains the name of the service (AuditChecker), the data contract (input data and output data), and the contract format (XML). It might also contain a WSDL (Web Services Definition Language) if the plug-in is accessed through SOAP. \n\n核心系统需要了解插件模块的可用性以及如何获取到它们。一个通用的实现方法是通过一组插件注册表。这个插件注册表含有每个插件模块的信息，包括它的名字、数据规约和远程访问协议(取决于插件如何与核心系统建立连接)。例如，一个税务软件的用于标识高风险的税务审计插件可能会有一个含有插件名(比如AuditChecker)的注册入口，数据规约(输入数据、输出数据)和规约格式( 比如xml )。如果这个插件是通过SOAP协议访问，那么它可能还要包含一个WSDL(Web Services Definition Language).\n\rPlug-in modules can be connected to the core system through a variety of ways, including OSGi (open service gateway initiative), messaging, web services, or even direct point-to-point binding (i.e., object instantiation). The type of connection you use depends on the type of application you are building (small product or large business application) and your specific needs (e.g., single deploy or distributed deployment). The architecture pattern itself does not specify any of these implementation details, only that the plug-in modules must remain independent from one another. \n\n插件模块可以通过多种方式连接到核心系统，包括OSGi ( open service gateway initiative )、消息机制、web服务或者直接点对点的绑定 ( 比如对象实例化，即依赖注入 )。你使用的连接类型取决于你构建的应用类型和你的特殊需求（比如单机部署还是分布式部署）。微内核架构本身没有指定任何的实现方式，唯一的规定就是插件模块之间不要产生依赖。\n\rThe contracts between the plug-in modules and the core system can range anywhere from standard contracts to custom ones. Custom contracts are typically found in situations where plug-in components are developed by a third party where you have no control over the contract used by the plug-in. In such cases, it is common to create an adapter between the plug-in contact and your standard con‐ tract so that the core system doesn’t need specialized code for each plug-in. When creating standard contracts (usually implemented through XML or a Java Map), it is important to remember to create a versioning strategy right from the start.\n\n插件和核心系统的通信规范包含标准规范和自定义规范。自定义规范典型的使用场景是插件组件是被第三方构建的，并且你无法控制插件使用的规范。在这种情况下，通常做法是在第三方插件规约和你的标准规范之间创建一个Adapter（适配器），这样，核心系统就无需为每个插件提供专门的代码。当创建标准规范 ( 通常是通过XML或者Java Map )时，从一开始就创建一个版本策略是非常重要的。 \r\r## Pattern Examples 架构示例\rPerhaps the best example of the microkernel architecture is the Eclipse IDE. Downloading the basic Eclipse product provides you little more than a fancy editor. However, once you start adding plug-ins, it becomes a highly customizable and useful product. Internet browsers are another common product example using the microkernel architecture: viewers and other plug-ins add additional capabilities that are not otherwise found in the basic browser (i.e., core system). \n\n也许微内核架构的最好示例就是大家熟知的Eclipse IDE了。下载最基本的Eclipse后，它只能提供一个编辑器。然后，一旦你开始添加插件，它就变成一个高度可定制化和非常有用的产品（译者注 : 更多内容大家可以参考 [开源软件架构 卷1：第6章 Eclipse之一](http://www.ituring.com.cn/article/6817) ）。浏览器是另一个使用微内核架构的产品示例，它由一个查看器和其他扩展的插件组成。\n\n\rThe examples are endless for product-based software, but what about large business applications? The microkernel architecture applies to these situations as well. To illustrate this point, let’s use another insurance company example, but this time one involving insurance claims processing. \n\n基于微内核架构的示例数不胜数，但是大型的商业应用呢？微内核应用架构也适用于这些情形。为了阐述这个观点，让我们来看看另一个保险公司的示例，但是这次的示例会涉及保险理赔处理。 \n\rClaims processing is a very complicated process. Each state has different rules and regulations for what is and isn’t allowed in an insurance claim. For example, some states allow free windshield replacement if your windshield is damaged by a rock, whereas other states do not. This creates an almost infinite set of conditions for a standard claims process. \n\n理赔处理是一个非常复杂的过程。每个州都有不同的关于保险理赔的规则和条文。例如，你的挡风玻璃被石头砸碎了，在有些州可以免费更换，但在其他州则不可以。因为大家的标准都不一样，因此理赔标准几乎可以是无限的。\n\rNot surprisingly, most insurance claims applications leverage large and complex rules engines to handle much of this complexity. How‐ ever, these rules engines can grow into a complex big ball of mud where changing one rule impacts other rules, or making a simple rule change requires an army of analysts, developers, and testers. Using the microkernel architecture pattern can solve many of these issues. \n\n有很多保险理赔应用运用大型和复杂的规则处理引擎来处理不同规则带来的复杂性。然而，可能会因为某条规则的改变而引起其他规则的改变而使得这些规则处理引擎变成一个大泥球，或者一个简单的规则变更也会需要很多的需求分析师、开发工程师、测试工程师来参与进行处理。使用微内核架构能够很好的解决这个问题，核心系统只知道根据理赔规则处理，但这个理赔规则是抽象的，系统将理赔规则作为一个插件规范，具体的规则有对应的实现，然后注入到系统中即可。\n\rThe stack of folders you see in Figure 3-2 represents the core system for claims processing. It contains the basic business logic required by the insurance company to process a claim, except without any custom processing. Each plug-in module contains the specific rules for that state. In this example, the plug-in modules can be implemented using custom source code or separate rules engine instances. Regardless of the implementation, the key point is that state-specific rules and processing is separate from the core claims system and can be added, removed, and changed with little or no effect on the rest of the core system or other plug-in modules. \n\n图3-2中的一堆文件夹代表了理赔处理核心系统。它包含一些处理保险理赔的基本业务逻辑。每一个插件模块包含每个州的具体理赔规则。在这个例子中，插件模块可以通过自定义源代码或分离规则引擎实例来实现。不管具体实现如何，关键就在于理赔规则和处理都从核心系统中分离，而这些规则和处理过程都可以被动态地添加、移除，而这些改变对于核心系统和其他插件只有很小的影响或者根本不产生影响。\n\n![3-2](images/3-2.png)\r图 3-2. 微内核架构案例\r\r## Considerations 注意事项\rOne great thing about the microkernel architecture pattern is that it can be embedded or used as part of another architecture pattern. For example, if this pattern solves a particular problem you have with a specific volatile area of the application, you might find that you can’t implement the entire architecture using this pattern. In this case, you can embed the microservices architecture pattern in another pattern you are using (e.g., layered architecture). Similarly, the event-processor components described in the previous section on event-driven architecture could be implemented using the microservices architecture pattern. \n\n微内核架构模式的妙处之一是，它可以嵌入或用作另一种架构模式的一部分。例如，如果这个架构解决的是一个你应用中易变领域的特定的问题 ( 译者注 : 即插件化能够解决你应用中的某个特定模块的架构问题 )，你可能会发现你不能在整个应用中使用这种架构。在这种情况下，你可以将微内核架构嵌入到另一个架构模式中 ( 比如分层架构 )。同样的，在上一章节中描述的事件驱动架构中的事件处理器组件也可以使用微内核架构。\n\rThe microservices architecture pattern provides great support for evolutionary design and incremental development. You can first produce a solid core system, and as the application evolves incrementally, add features and functionality without having to make significant changes to the core system. \n\n微内核架构对渐进式设计和增量开发提供了非常好的支持。你可以先构建一个单纯的核心系统，随着应用的演进，系统会逐渐添加越来越多的特性和功能，而这并不会引起核心系统的重大变化。\n\rFor product-based applications, the microkernel architecture pattern should always be your first choice as a starting architecture, particularly for those products where you will be releasing additional features over time and want control over which users get which features. If you find over time that the pattern doesn’t satisfy all of your requirements, you can always refactor your application to another architecture pattern better suited for your specific requirements. \n\n对基于产品的应用来说，微内核架构应该是你的第一选择。特别是那些你会在后续开发中发布附加特性和控制哪些用户能够获取哪些特性的应用。如果你在后续开发中发现这个架构不能满足你的需求了，你能够根据你的特殊需求将你的应用重构为另一个更好的架构。\n\n\r## Pattern Analysis 模式分析\rThe following table contains a rating and analysis of the common architecture characteristics for the microkernel architecture pattern. \n\nThe rating for each characteristic is based on the natural tendency for that characteristic as a capability based on a typical implementation of the pattern, as well as what the pattern is generally known for.\n\n For a side-by-side comparison of how this pattern relates to other patterns in this report, please refer to Appendix A at the end of this report. \n\n下面的表格中包含了微内核架构每个特性的评级和分析。以微内核架构的最经典的实现方式的自然趋势为依据对每个特性进行评级。关于微内核架构与其他模式的相关性比较请参考附录A。\n\r### Overall agility 整体灵活性\rRating: High \rAnalysis: Overall agility is the ability to respond quickly to a constantly changing environment. Changes can largely be isolated and implemented quickly through loosely coupled plug-in modules. In general, the core system of most microkernel archi‐ tectures tends to become stable quickly, and as such is fairly robust and requires few changes over time. \n\n评级 : 高 \n分析 : 整体灵活性是指能够快速适应不断变化的环境的能力。通过插件模块的松耦合实现，可以将变化隔离起来，并且快速满足需求。通常，微内核架构的核心系统很快趋于稳定，这样系统就变得很健壮，随着时间的推移它也不会发生多大改变。\n\r### Ease of deployment 易于部署\rRating: High \rAnalysis: Depending on how the pattern is implemented, the plug-in modules can be dynamically added to the core system at runtime (e.g., hot-deployed), minimizing downtime dur‐ ing deployment.\n\n评级 : 高 \n分析 : 根据实现方式，插件模块能够在运行时被动态地添加到核心系统中 （ 比如，热部署 ）,把停机时间减到最小。\r\n\r\n### Testability 可测试性\rRating: High\rAnalysis: Plug-in modules can be tested in isolation and can be easily mocked by the core system to demonstrate or prototype a particular feature with little or no change to the core system.\n\n评级 : 高 \n分析 : 插件模块能够被独立的测试，能够非常简单地被核心系统模拟出来进行演示，或者在对核心系统很小影响甚至没有影响的情况下对一个特定的特性进行原型展示。\r\r### Performance 性能\rRating: High \rAnalysis: While the microkernel pattern does not naturally lend itself to high-performance applications, in general, most appli‐ cations built using the microkernel architecture pattern perform well because you can customize and streamline applications to only include those features you need. The JBoss Application Server is a good example of this: with its plug-in architecture, you can trim down the application server to only those features you need, removing expensive non-used features such as remote access, messaging, and caching that consume memory, CPU, and threads and slow down the app server.\n\n评级 : 高 \n分析 : 使用微内核架构不会自然而然地使你的应用变得高性能。通常，很多使用微内核架构的应用运行得很好，因为你能定制和简化应用程序，使它只包含那些你需要的功能模块。JBoss应用服务器就是这方面的优秀示例: 依赖于它的插件化架构，你可以只加载你需要的功能模块，移除那些消耗资源但没有使用的功能特性，比如远程访问，消息传递，消耗内存、CPU的缓存，以及线程，从而减小应用服务器的资源消耗。\r\r### Scalability 伸缩性\rRating: Low \rAnalysis: Because most microkernel architecture implementa‐ tions are product based and are generally smaller in size, they are implemented as single units and hence not highly scalable. Depending on how you implement the plug-in modules, you can sometimes provide scalability at the plug-in feature level, but overall this pattern is not known for producing highly scala‐ ble applications. \n\n评级 : 低 \n分析 : 因为微内核架构的实现是基于产品的，它通常都比较小。它们以独立单元的形式实现，因此没有太高的伸缩性。此时，伸缩性就取决于你的插件模块，有时你可以在插件级别上提供可伸缩性，但是总的来说这个架构并不是以构建高度伸缩性的应用而著称的。\n\r### Ease of development 易于开发\rRating: Low \rAnalysis: The microkernel architecture requires thoughtful design and contract governance, making it rather complex to implement. Contract versioning, internal plug-in registries, plug-in granularity, and the wide choices available for plug-in connectivity all contribute to the complexity involved with implementing this pattern.\n\n评级 : 低\n\n分析 : 微内核架构需要详尽周全的设计和规约管理，这使得它实现起来相当复杂。规约版本控制，内部插件注册，插件粒度，广泛的插件连接选择，所有这些都是导致该架构的实现变得复杂的重要因素。" }, { "path": "software-architecture-patterns/chapter04-dupengwei.md", "content": "# 第四章 微服务架构 \nThe microservices architecture pattern is quickly gaining ground in the industry as a viable alternative to monolithic applications and service-oriented architectures. Because this architecture pattern is still evolving, there’s a lot of confusion in the industry about what this pattern is all about and how it is implemented. This section of the report will provide you with the key concepts and foundational knowledge necessary to understand the benefits (and trade-offs) of this important architecture pattern and whether it is the right pat‐ tern for your application.\n\n微服务架构模式作为替代monolithic应用和面向服务架构的一个可行的选择，在业内迅速取得进展。由于这个架构模式仍然在不断的发展中，在业界存在很多困惑——这种模式是关于什么的？它是如何实现的？本报告的这部分将为你提供关键概念和必要的基础知识来理解这一重要架构模式的好处(和取舍)，以此来判断这种架构是否适合你的应用。\n\n## Pattern Description 模式描述\nRegardless of the topology or implementation style you chose, there are several common core concepts that apply to the general architecture pattern. The first of these concepts is the notion of separately deployed units. As illustrated in Figure 4-1, each component of the microservices architecture is deployed as a separate unit, allowing for easier deployment through an effective and streamlined delivery pipeline, increased scalability, and a high degree of application and component decoupling within your application.\n\n不管你选择哪种拓扑或实现风格,有几种常见的核心概念适用于一般架构模式。第一个概念是*单独部署单元*。如图4-1所示，微服务架构的每个组件都作为一个独立单元进行部署，让每个单元可以通过有效、简化的传输管道进行通信，同时它还有很强的扩展性，应用和组件之间高度解耦，使得部署更为简单。\n\nPerhaps the most important concept to understand with this pattern is the notion of a service component. Rather than think about services within a microservices architecture, it is better to think about service components, which can vary in granularity from a single module to a large portion of the application. Service components contain one or more modules (e.g., Java classes) that represent either a single-purpose function (e.g., providing the weather for a specific city or town) or an independent portion of a large business application (e.g., stock trade placement or determining auto-insurance rates). Designing the right level of service component granularity is one of the biggest challenges within a microservices architecture. This challenge is discussed in more detail in the following service component orchestration subsection.\n\n也许要理解这种模式，最重要的概念就是服务组件（service component）。不要考虑微服务架构内部的服务，而最好是考虑服务组件，从粒度上讲它可以小到单一的模块，或者大至一个应用程序。服务组件包含一个或多个模块（如Java类），这些模块可以提供一个单一功能（如，为特定的城市或城镇提供天气情况），或也可以作为一个大型商业应用的一个独立部分（如，股票交易布局或测定汽车保险的费率）。在微服务架构中，正确设计服务组件的粒度是一个很大的挑战。在接下来的服务组件部分对这一挑战进行了详细的讨论。\n\n![4-1](images/4-1.png) \nFigure 4-1. Basic Microservices architecture pattern 图 4-1. 基本微服务架构模式\n\nAnother key concept within the microservices architecture pattern is that it is a distributed architecture, meaning that all the components within the architecture are fully decoupled from one other and accessed through some sort of remote access protocol (e.g., JMS, AMQP, REST, SOAP, RMI, etc.). The distributed nature of this architecture pattern is how it achieves some of its superior scalability and deployment characteristics.\n\n微服务架构模式的另一个关键概念是它是一个*分布式*的架构，这意味着架构内部的所有组件之间是完全解耦的，并通过某种远程访问协议（如， JMS, AMQP, REST, SOAP, RMI等）进行访问。这种架构的分布式特性是它实现一些优越的可扩展性和部署特性的关键所在。\n\nOne of the exciting things about the microservices architecture is that it evolved from issues associated with other common architecture patterns, rather than being created as a solution waiting for a problem to occur. The microservices architecture style naturally evolved from two main sources: monolithic applications developed using the layered architecture pattern and distributed applications developed through the service-oriented architecture pattern.\n\n微服务架构另一个令人兴奋的特性是它是由其他常见架构模式存在的问题演化来的，而不是作为一个解决方案被创造出来等待问题出现。微服务架构的演化有两个主要来源：使用分层架构模式的monolithic应用和使用面向服务架构的分布式应用。\n\nThe evolutionary path from monolithic applications to a microservices architecture style was prompted primarily through the development of continuous delivery, the notion of a continuous deployment pipeline from development to production which streamlines the deployment of applications. Monolithic applications typically consist of tightly coupled components that are part of a single deployable unit, making it cumbersome and difficult to change, test, and deploy the application (hence the rise of the common “monthly deployment” cycles typically found in most large IT shops). These factors commonly lead to brittle applications that break every time something new is deployed. The microservices architecture pattern addresses these issues by separating the application into multiple deployable units (service components) that can be individually developed, tested, and deployed independent of other service components.\n\n由单体应用( 一个应用就是一个整体 )到微服务的发展过程主要是由持续交付开发促成的。从开发到生产的持续部署管道概念,简化了应用程序的部署。单体应用通常是由紧耦合的组件组成，这些组件同时又是另一个单一可部署单元的一部分，这使得它繁琐，难以改变、测试和部署应用（因此常见的“月度部署”周期出现并通常发生在大型IT商店项目）。这些因素通常会导致应用变得脆弱以至于每次有一点新功能部署后应用就不能运行。微服务架构模式通过将应用分隔成多个可部署的单元（服务组件）的方法来解决这一问题，这些服务组件可以独立于其他服务组件进行单独开发、测试和部署。\n\nThe other evolutionary path that lead to the microservices architecture pattern is from issues found with applications implementing the service-oriented architecture pattern (SOA). While the SOA pattern is very powerful and offers unparalleled levels of abstraction, heterogeneous connectivity, service orchestration, and the promise of aligning business goals with IT capabilities, it is nevertheless complex, expensive, ubiquitous, difficult to understand and implement, and is usually overkill for most applications. The microservices architecture style addresses this complexity by simplifying the notion of a service, eliminating orchestration needs, and simplifying connectivity and access to service components.\n\n另一个导致微服务架构模式产生的演化过程是由面向服务架构模式（SOA）应用程序存在的问题引起的。虽然SOA模式非常强大，提供了无与伦比的抽象级别、异构连接、服务编排，并保证通过IT能力调整业务目标，但它仍然是复杂的,昂贵的,普遍存在，它很难理解和实现，对大多数应用程序来说过犹不及。微服务架构通过简化服务概念，消除编排需求、简化服务组件连接和访问来解决复杂度问题。\n\n## Pattern Topologies 模式拓扑\nWhile there are literally dozens of ways to implement a microservices architecture pattern, three main topologies stand out as the most common and popular: the API REST-based topology, 基于REST的应用 topology, and the centralized messaging topology.\n\n虽然有很多方法来实现微服务架构模式,但三个主要的拓扑结构脱颖而出，最常见和流行的有:API REST-based 拓扑结构,基于REST的应用拓扑结构和集中式消息拓扑结构。\n\nThe API REST-based topology is useful for websites that expose small, self-contained individual services through some sort of API (application programming interface). This topology, which is illustrated in Figure 4-2, consists of very fine-grained service components (hence the name microservices) that contain one or two modules that perform specific business functions independent from the rest of the services. In this topology, these fine-grained service components are typically accessed using a REST-based interface implemented through a separately deployed web-based API layer. Examples of this topology include some of the common single-purpose cloud-based RESTful web services found by Yahoo, Google, and Amazon.\n\n基于REST的API拓扑适用于网站，通过某些API（application programming interface）对外提供小型的、自包含的服务。这种拓扑结构,如图4 - 2所示,由粒度非常细的服务组件（因此得名微服务）组成，这些服务组件包含一个或两个模块并独立于其他服务来执行特定业务功能。在这种拓结构扑中,这些细粒度的服务组件通常被REST-based的接口访问，而这个接口是通过一个单独部署的web API层实现的。此种拓扑的例子包含一些常见的专用的、基于云的RESTful web service，大型网站像Yahoo, Google, and Amazon都在使用。\n\n![4-2](images/4-2.png) \nFigure 4-2. API REST-based topology 图 4-2. API REST-based拓扑结构\n\nThe application REST-based topology differs from the API REST- based approach in that client requests are received through traditional web-based or fat-client business application screens rather than through a simple API layer. As illustrated in Figure 4-3, the user-interface layer of the application is deployed as a separate web application that remotely accesses separately deployed service components (business functionality) through simple REST-based interfaces. The service components in this topology differ from those in the API-REST-based topology in that these service components tend to be larger, more coarse-grained, and represent a small portion of the overall business application rather than fine-grained, single-action services. This topology is common for small to medium-sized business applications that have a relatively low degree of complexity.\n\n基于REST的应用拓扑结构与API REST- based不同，它通过传统的基于web的或胖客户端业务应用来接收客户端请求，而不是通过一个简单的API层。如图4-3所示，应用的用户接口层（user interface layer）是一个web应用，可以通过简单的REST-based接口访问单独部署的服务组件（业务功能）。该拓扑结构中的服务组件与API-REST-based拓扑结构中的不同，这些服务组件往往会更大、粒度更粗、代表整个业务应用程序的一小部分，而不是细粒度的、单一操作的服务。这种拓扑结构常见于中小型企业等复程度相对较低的应用程序。\n\n![4-3](images/4-3.png) \nFigure 4-3. 基于REST的应用 topology 图 4-3. 基于REST的应用 拓扑结构\n\nAnother common approach within the microservices architecture pattern is the centralized messaging topology. This topology (illustrated in Figure 4-4) is similar to the previous application REST- based topology except that instead of using REST for remote access, this topology uses a lightweight centralized message broker (e.g., ActiveMQ, HornetQ, etc.). It is vitally important when looking at this topology not to confuse it with the service-oriented architecture pattern or consider it “SOA-Lite.\" The lightweight message broker found in this topology does not perform any orchestration, transformation, or complex routing; rather, it is just a lightweight transport to access remote service components.\n\n微服务架构模式中另一个常见的方法是集中式消息拓扑。该拓扑（如图4-4所示）与前面提到的基于REST的应用拓扑类似，不同的是，application REST- based拓扑结构使用REST进行远程访问，而该拓扑结构则使用一个轻量级的集中式消息代理（如，ActiveMQ, HornetQ等等）。不要将该拓扑与面向服务架构模式混淆或将其当做SOA简化版（“SOA-Lite”），这点是极其重要的。该拓扑中的轻量级消息代理（Lightweight Message Broker）不执行任何编排,转换,或复杂的路由;相反,它只是一个轻量级访问远程服务组件的传输工具。\n\nThe centralized messaging topology is typically found in larger business applications or applications requiring more sophisticated control over the transport layer between the user interface and the service components. The benefits of this topology over the simple REST-based topology discussed previously are advanced queuing mechanisms, asynchronous messaging, monitoring, error handling, and better overall load balancing and scalability. The single point of failure and architectural bottleneck issues usually associated with a centralized broker are addressed through broker clustering and broker federation (splitting a single broker instance into multiple broker instances to divide the message throughput load based on functional areas of the system).\n\n集中式消息拓扑结构通常应用在较大的业务应用程序中，或对于某些对传输层到用户接口层或者到服务组件层有较复杂的控制逻辑的应用程序中。该拓扑较之先前讨论的简单基于REST的拓扑结构，其好处是有先进的排队机制、异步消息传递、监控、错误处理和更好的负载均衡和可扩展性。与集中式代理相关的单点故障和架构瓶颈问题已通过代理集群和代理联盟（将一个代理实例为分多个代理实例，把基于系统功能区域的吞吐量负载划分开处理）解决。\n\n![4-4](images/4-4.png) \n\nFigure 4-4. Centralized messaging topology 图 4-4. 集中式消息拓扑结构\n\n## Avoid Dependencies and Orchestration 避免依赖和编排\nOne of the main challenges of the microservices architecture pattern is determining the correct level of granularity for the service components. If service components are too coarse-grained you may not realize the benefits that come with this architecture pattern (deployment, scalability, testability, and loose coupling). However, service components that are too fine-grained will lead to service orchestration requirements, which will quickly turn your lean microservices architecture into a heavyweight service-oriented architecture, complete with all the complexity, confusion, expense, and fluff typically found with SOA-based applications.\n\n微服务架构模式的主要挑战之一就是决定服务组件的粒度级别。如果服务组件粒度过粗，那你可能不会意识到这个架构模式带来的好处（部署、可扩展性、可测试性和松耦合），然而,服务组件粒度过细将导致服务编制要求,这会很快导致将微服务架构模式变成一个复杂、容易混淆、代价昂贵并易于出错的重量级面向服务架构。\n\nIf you find you need to orchestrate your service components from within the user interface or API layer of the application, then chances are your service components are too fine-grained. Similarly, if you find you need to perform inter-service communication between service components to process a single request, chances are your service components are either too fine-grained or they are not partitioned correctly from a business functionality standpoint.\n\n如果你发现需要从应用内部的用户接口或API层编排服务组件，那么很有可能你服务组件的粒度太细了。如果你发现你需要在服务组件之间执行服务间通信来处理单个请求,那么很有可能要么是你服务组件的粒度太细了，要么是没有从业务功能角度正确划分服务组件。\n\nInter-service communication, which could force undesired couplings between components, can be handled instead through a shared database. For example, if a service component handing Internet orders needs customer information, it can go to the database to retrieve the necessary data as opposed to invoking functionality within the customer-service component.\n\n服务间通信，可能导致组件之间产生耦合，但可以通过共享数据库进行处理。例如，若一个服务组件处理网络订单而需要用户信息时，它可以去数据库检索必要的数据，而不是调用客户服务组件的功能。\n\nThe shared database can handle information needs, but what about shared functionality? If a service component needs functionality contained within another service component or common to all service components, you can sometimes copy the shared functionality across service components (thereby violating the DRY principle: don’t repeat yourself). This is a fairly common practice in most business applications implementing the microservices architecture pattern, trading off the redundancy of repeating small portions of business logic for the sake of keeping service components independent and separating their deployment. Small utility classes might fall into this category of repeated code.\n\n共享数据库可以处理信息需求，但是共享功能呢？如果一个服务组件需要的功能包含在另一个服务组件内，或是一个公共的功能,那么有时你可以将服务组件的共享功能复制一份（因此违反了DRY规则：don’t repeat yourself）。为了保持服务组件独立和部署分离，微服务架构模式实现中会存在一小部分由重复的业务逻辑而造成的冗余，这在大多数业务应用程序中是一个相当常见的问题。小工具类可能属于这一类重复的代码。\n\nIf you find that regardless of the level of service component granularity you still cannot avoid service-component orchestration, then it’s a good sign that this might not be the right architecture pattern for your application. Because of the distributed nature of this pattern, it is very difficult to maintain a single transactional unit of work across (and between) service components. Such a practice would require some sort of transaction compensation framework for rolling back transactions, which adds significant complexity to this relatively simple and elegant architecture pattern.\n\n如果你发现就算不考虑服务组件粒度的级别，你仍不能避免服务组件编排,这是一个好迹象,可能此架构模式不适用于你的应用。由于这种模式的分布式特性，很难维护服务组件之间的单一工作事务单元。这种做法需要某种事务补偿框架回滚事务,这对此相对简单而优雅的架构模式来说，显著增加了复杂性。\n\n## Considerations 架构考量\nThe microservices architecture pattern solves many of the common issues found in both monolithic applications as well as service-oriented architectures. Since major application components are split up into smaller, separately deployed units, applications built using the microservices architecture pattern are generally more robust, provide better scalability, and can more easily support continuous delivery.\n\n\n微服务架构模式解决了很多单体应用和面向服务架构应用存在的问题。由于主要应用组件被分成更小的,单独部署单元,使用微服务架构模式构建的应用程序通常更健壮,并提供更好的可扩展性,支持持续交付也更容易。\n\nAnother advantage of this pattern is that it provides the capability to do real-time production deployments, thereby significantly reducing the need for the traditional monthly or weekend “big bang” production deployments. Since change is generally isolated to specific service components, only the service components that change need to be deployed. If you only have a single instance of a service component, you can write specialized code in the user interface application to detect an active hot-deployment and redirect users to an error page or waiting page. Alternatively, you can swap multiple instances of a service component in and out during a real-time deployment, allowing for continuous availability during deployment cycles (something that is very difficult to do with the layered architecture pattern).\n\n该模式的另一个优点是,它提供了实时生产部署能力，从而大大减少了传统的月度或周末“大爆炸”生产部署的需求。因为变化通常被隔离成特定的服务组件，只有变化的服务组件才需要部署。如果你的服务组件只有一个实例，你可以在用户界面程序编写专门的代码用于检测一个活跃的热部署,一旦检测到就将用户重定向到一个错误页面或等待页面。你也可以在实时部署期间，将服务组件的多个实例进行交换，允许应用程序在部署期间保持持续可用性（分层架构模式很难做到这点）。\n\nOne final consideration to take into account is that since the microservices architecture pattern is a distributed architecture, it shares some of the same complex issues found in the event-driven architecture pattern, including contract creation, maintenance, and government, remote system availability, and remote access authentication and authorization.\n\n最后一个要重视的考虑是，由于微服务架构模式是分布式的架构，他与事件驱动架构模式具有一些共同的复杂的问题，包括约定的创建、维护，和管理，远程系统的可用性，远程访问身份验证和授权。\n\n## Pattern Analysis 模式分析\nThe following table contains a rating and analysis of the common architecture characteristics for the microservices architecture pattern. The rating for each characteristic is based on the natural tendency for that characteristic as a capability based on a typical implementation of the pattern, as well as what the pattern is generally known for. For a side-by-side comparison of how this pattern relates to other patterns in this report, please refer to Appendix A at the end of this report.\n\n下面这个表中包含了微服务架构模式的特点分析和评级，每个特性的评级是基于自然趋势，基于典型模式实现的能力特性,以及该模式是以什么闻名的。本报告中该模式与其他模式的并排比较，请参考报告最后的附件A。\n\n### Overall agility 整体灵活性\nRating: High \nAnalysis: Overall agility is the ability to respond quickly to a constantly changing environment. Due to the notion of separately deployed units, change is generally isolated to individual service components, which allows for fast and easy deployment. Also, applications build using this pattern tend to be very loosely coupled, which also helps facilitate change.\n\n评级：高\n\n分析：整体的灵活性是能够快速响应不断变化的环境。由于单独部署单元的概念,变化通常被隔离成单独的服务组件,使得部署变得快而简单。同时，使用这种模式构建的应用往往是松耦合的，也有助于促进改变。\n\n### Ease of deployment 易部署性\nRating: High \nAnalysis: Overall this pattern is relatively easy to deploy due to the decoupled nature of the event-processor components. The broker topology tends to be easier to deploy than the mediator topology, primarily because the event-mediator component is somewhat tightly coupled to the event processors: a change in an event processor component might also require a change in the event mediator, requiring both to be deployed for any given change.\n\n评级：高\n\n分析：整体来讲，由于该模式的解耦特性和事件处理组件使得部署变得相对简单。broker拓扑往往比mediator拓扑更易于部署，主要是因为event-mediator组件与事件处理器是紧耦合的，事件处理器组件有一个变化可能导致event mediator跟着变化，有任何变化两者都需要部署。\n\n### Testability 可测试性\nRating: High \nAnalysis: Due to the separation and isolation of business functionality into independent applications, testing can be scoped, allowing for more targeted testing efforts. Regression testing for a particular service component is much easier and more feasible than regression testing for an entire monolithic application. Also, since the service components in this pattern are loosely coupled, there is much less of a chance from a development perspective of making a change that breaks another part of the application, easing the testing burden of having to test the entire application for one small change.\n\n评级：高\n\n分析：由于业务功能被分离成独立的应用模块,可以在局部范围内进行测试，这样测试工作就更有针对性。对一个特定的服务组件进行回归测试比对整个monolithic应用程序进行回归测试更简单、更可行。而且,由于这种模式的服务组件是松散耦合的，从开发角度来看，由一个变化导致应用其他部分也跟着变化的几率很小，并能减小由于一个微小的变化而不得不对整个应用程序进行测试的负担。\n\n### Performance 性能\nRating: Low \nAnalysis: While you can create applications implemented from this pattern that perform very well, overall this pattern does not naturally lend itself to high-performance applications due to the distributed nature of the microservices architecture pattern.\n\n评级：低\n\n分析：虽然你可以从实现该模式来创建应用程序并可以很好的运行，整体来说，由于微服务架构模式的分布式特性，并不适用于高性能的应用程序。\n\n### Scalability 可扩展性\nRating: High \nAnalysis: Because the application is split into separately deployed units, each service component can be individually scaled, allowing for fine-tuned scaling of the application. For example, the admin area of a stock-trading application may not need to scale due to the low user volumes for that functionality, but the trade-placement service component may need to scale due to the high throughput needed by most trading applications for this functionality.\n\n评级：高\n\n分析：由于应用程序被分为单独的部署单元,每个服务组件可以单独扩展，并允许对应用程序进行扩展调整。例如，股票交易的管理员功能区域可能不需要扩展，因为使用该功能的用户很少，但是交易布局服务组件可能需要扩展，因为大多数交易应用程序需要具备处理高吞吐量的功能。\n\n### Ease of development 开发容易度\nRating: High \nAnalysis: Because functionality is isolated into separate and distinct service components, development becomes easier due to the smaller and isolated scope. There is much less chance a developer will make a change in one service component that would affect other service components, thereby reducing the coordination needed among developers or development teams.\n\n评级：高\n\n分析：由于功能被分隔成不同的服务组件，由于开发范围更小且被隔离，开发变得更简单。程序员在一个服务组件做出一个变化影响其他服务组件的几率是很小的，从而减少开发人员或开发团队之间的协调。\n" }, { "path": "software-architecture-patterns/readme.md", "content": "软件架构模式\n-------\n\n原书名[《Software Architecture Patterns》](http://www.oreilly.com/programming/free/software-architecture-patterns.csp) .\n\n* [中文版百度云盘下载](http://pan.baidu.com/s/1sjAz23r)\n* [中文版github下载地址](https://raw.githubusercontent.com/hehonghui/android-tech-frontier/master/software-architecture-patterns/%E8%BD%AF%E4%BB%B6%E6%9E%B6%E6%9E%84%E6%A8%A1%E5%BC%8F.pdf)\n\n## 打赏 - JUST FOR FUN\n\n> * 一杯咖啡钱, 打赏金额随意，感谢大家~ :)\n\n| 支付宝 | 微信 |\n|------------|-----------|\n|| |\n\n\n## 译员列表\n该书总共五章，译员可以领其中一章或者多个章节，截止日期 2015/4/19，感谢大家的参与。可参考资料 : [软件架构模式读书笔记](http://blog.csdn.net/bboyfeiyu/article/details/44977219) 。\n\n| \t\t\t翻译章节\t\t\t | \t\t译员信息 \t |\n|--------------------------|-------------------|\n| [第一章 分层架构](chapter01-BillonWang.md) | [BillionWang](https://github.com/BillionWang) |\n| [第二章 事件驱动架构](chapter02-chaossss.md) | [chaossss](https://github.com/chaossss) |\n| [第三章 微内核架构](chapter03-Mr.Simple.md) | [Mr.Simple](https://github.com/bboyfeiyu) |\n| [第四章 微服务架构](chapter04-dupengwei.md) | [dupengwei](https://github.com/dupengwei) |\n| [第五章 基于空间的架构](chap-5.md) | [allenlsy](https://allenlsy.com) |\n\n\n" }, { "path": "software-architecture-patterns/软件架构模式.md", "content": "![cover](images/cover.png)\n\n\n软件架构模式 Mark Richards 著 \n版权归 © 2015 O’Reilly Media, Inc. 所有. \n\n原书发布链接为[Software Architecture Patterns](http://www.oreilly.com/programming/free/software-architecture-patterns.csp).\n\n**译员信息**\n\n本书的译员均来自 开发技术前线 [www.devtf.cn](http://www.devtf.cn)。 \n\n| 译者 | 个人简介 | \n|--------|----------|\n| [Mr.Simple](https://github.com/bboyfeiyu) | 乐于分享，热爱开源的工程师，[个人博客](http://blog.csdn.net/bboyfeiyu) | \n| [chaossss](https://github.com/chaossss) | 追风筝的吃货，汪～。[个人博客](http://blog.csdn.net/u012403246/) | \n| [Allenlsy](https://github.com/allenlsy) | 计算机科学爱好者，Rails程序员。[个人博客](allenlsy.com) | \n| [BillonWang](https://github.com/BillonWang) | 做好玩的事情，交好玩的朋友。[个人博客](www.woaichirou.com) | \n| [dupengwei](https://github.com/dupengwei) | 乐于分享的移动互联网开发工程师 | \n| [Charli Hu](https://github.com/ht1348092) | 喜欢英语，不放弃编程的菇凉。| \n\n\n# 目录\n* [简介](#introdution) \n* [第一章 分层架构](#chapter1)\n* [第二章 事件驱动架构](#chapter2)\n* [第三章 微内核架构](#chapter3)\n* [第四章 微服务架构](#chapter4)\n* [第五章 基于空间的架构](#chapter5)\n* [附录A](#appendix)\n* [关于作者](#author)\n\n\n\n## 简介\n对程序员来说很常见一种情况是在没有合理的程序架构时就开始编程，没有一个清晰的和定义好的架构的时候，大多数开发者和架构师通常会使用标准式的传统分层架构模式（也被称为多层架构）——通过将源码模块分割为几个不同的层到不同的包中。不幸的是，这种编码方式会导致一系列没有组织性的代码模块，这些模块缺乏明确的规则、职责和同其他模块之间的关联。这通常被称为架构大泥球。 \n\n应用程序缺乏合理的架构一般会导致程序过度耦合、容易被破坏、难以应对变化，同时很难有一个清晰的版本或者方向性。这样的结果是，如果你没有充分理解程序系统里每个组件和模块，就很难定义这个程序的结构特征。有关于程序的部署和维护的基本问题都难以回答，比如：程序架构是什么规模?应用程序有什么性能特点?应用程序有多容易应对变化?应用程序的部署特点是什么?架构是如何反应的?\n\n架构模式帮助你定义应用程序的基本特征和行为。例如，一些架构模式会让程序自己自然而然地朝着具有良好伸缩性的方向发展，而其他架构模式会让程序朝着高度灵活的方向发展。知道了这些特点，了解架构模式的优点和缺点是非常必要的，它帮助我们选择一个适合自己特定的业务需求和目标的的程序。\n \n作为一个架构师,你必须证明你的架构模式的决策是正确的,特别是当需要选择一个特定的体系结构模式或方法的时候。这本迷你书的目的就是给你足够的信息让你去做出正确的架构决策。\n\n\n## 第一章 分层架构\n\n分层架构是一种很常见的架构模式，它也叫N层架构。这种架构是大多数Jave EE应用的实际标准，因此很多的架构师，设计师，还有程序员都知道它。许多传统IT公司的组织架构和分层模式十分的相似。所以它很自然的成为大多数应用的架构模式。\n\n### 模式分析\n\n分层架构模式里的组件被分成几个平行的层次，每一层都代表了应用的一个功能(展示逻辑或者业务逻辑)。尽管分层架构没有规定自身要分成几层几种，大多数的结构都分成四个层次:展示层，业务层，持久层，和数据库层。如表1-1，有时候，业务层和持久层会合并成单独的一个业务层，尤其是持久层的逻辑绑定在业务层的组件当中。因此，有一些小的应用可能只有3层，一些有着更复杂的业务的大应用可能有5层或者更多的分层。\n\n分层架构中的每一层都着特定的角色和职能。举个例子，展示层负责处理所有的界面展示以及交互逻辑，业务层负责处理请求对应的业务。架构里的层次是具体工作的高度抽象，它们都是为了实现某种特定的业务请求。比如说展示层并不需要关心怎样得到用户数据，它只需在屏幕上以特定的格式展示信息。业务层并不关心要展示在屏幕上的用户数据格式，也不关心这些用户数据从哪里来。它只需要从持久层得到数据，执行与数据有关的相应业务逻辑，然后把这些信息传递给展示层。\n\n![1-1](images/1-1.png) \n\n分层架构的一个突出特性是组件间关注点分离 (separation of concerns)。一个层中的组件只会处理本层的逻辑。比如说，展示层的组件只会处理展示逻辑，业务层中的组件只会去处理业务逻辑。多亏了组件分离，让我们更容易构造有效的角色和强力的模型。这样应用变的更好开发，测试，管理和维护。\n\n### 关键概念\n\n注意表1-2中每一层都是封闭的。这是分层架构中非常重要的特点。这意味request必须一层一层的传递。举个例子，从展示层传递来的请求首先会传递到业务层，然后传递到持久层，最后才传递到数据层。\n\n![1-2](images/1-2.png) \n\n那么为什么不允许展示层直接访问数据层呢。如果只是获得以及读取数据，展示层直接访问数据层，比穿过一层一层来得到数据来的快多了。这涉及到一个概念:层隔离。\n\n层隔离就是说架构中的某一层的改变不会影响到其他层:这些变化的影响范围限于当前层次。如果展示层能够直接访问持久层了，假如持久层中的SQL变化了，这对业务层和展示层都有一定的影响。这只会让应用变得紧耦合，组件之间互相依赖。这种架构会非常的难以维护。\n\n从另外一个方面来说，分层隔离使得层与层之间都是相互独立的，架构中的每一层的互相了解都很少。为了说明这个概念的牛逼之处，想象一个超级重构，把展示层从JSP换成JSF。假设展示层和业务层的之间的联系保持一致，业务层不会受到重构的影响，它和展示层所使用的界面架构完全独立。\n\n然而封闭的架构层次也有不便之处，有时候也应该开放某一层。如果想往包含了一些由业务层的组件调用的普通服务组件的架构中添加一个分享服务层。在这个例子里，新建一个服务层通常是一个好主意，因为从架构上来说，它限制了分享服务访问业务层(也不允许访问展示层)。如果没有隔离层，就没有任何架构来限制展示层访问普通服务，难以进行权限管理。\n\n在这个例子中，新的服务层是处于业务层之下的，展示层不能直接访问这个服务层中的组件。但是现在业务层还要通过服务层才能访问到持久层，这一点也不合理。这是分层架构中的老问题了，解决的办法是开放某些层。如表1-3所示，服务层现在是开放的了。请求可以绕过这一层，直接访问这一层下面的层。既然服务层是开放的，业务层可以绕过服务层，直接访问数据持久层。这样就非常合理。\n\n![1-3](images/1-3.png) \n\n开放和封闭层的概念确定了架构层和请求流之间的关系，并且给设计师和开发人员提供了必要的信息理解架构里各种层之间的访问限制。如果随意的开放或者封闭架构里的层，整个项目可能都是紧耦合，一团糟的。以后也难以测试，维护和部署。\n\n### 示例\n\n为了演示分层架构是如何工作的，想象一个场景，如表1-4，用户发出了一个请求要获得客户的信息。黑色的箭头是从数据库中获得用户数据的请求流，红色箭头显示用户数据的返回流的方向。在这个例子中，用户信息由客户数据和订单数组组成(客户下的订单)。\n\n用户界面只管接受请求以及显示客户信息。它不管怎么得到数据的，或者说得到这些数据要用到哪些数据表。如果用户界面接到了一个查询客户信息的请求，它就会转发这个请求给用户委托(Customer Delegate)模块。这个模块能找到业务层里对应的模块处理对应数据(约束关系)。业务层里的customer object聚合了业务请求需要的所有信息(在这个例子里获取客户信息)。这个模块调用持久层中的 customer dao 来得到客户信息，调用order dao来得到订单信息。这些模块会执行SQL语句，然后返回相应的数据给业务层。当 customer object收到数据以后，它就会聚合这些数据然后传递给 customer delegate,然后传递这些数据到customer screen 展示在用户面前。\n\n![1-4](images/1-4.png) \n\n从技术的角度来说，有很多的方式能够实现这些模块。比如说在Java平台中，customer screen 对应的是 (JSF) Java Server Faces ,用 bean 组件来实现 customer delegate。用本地的Spring bean或者远程的EJB3 bean 来实现业务层中的customer object。上例中的数据访问可以用简单的POJP's(Plain Old Java Objects)，或者可以用MyBatis，还可以用JDBC或者Hibernate 查询。Microsoft平台上，customer screen能用 .NET 库的ASP模块来访问业务层中的C#模块，用ADO来实现用户和订单数据的访问模块。\n\n### 注意事项\n\n分层架构是一个很可靠的架构模式。它适合大多数的应用。如果你不确定在项目中使用什么架构，分层架构是再好不过的了。然后，从架构的角度上来说，选择这个模式还要考虑很多的东西。\n\n第一个要注意的就是 污水池反模式(architecture sinkhole anti-pattern)。\n在这个模式中，请求流只是简单的穿过层次，不留一点云彩，或者说只留下一阵青烟。比如说界面层响应了一个获得数据的请求。响应层把这个请求传递给了业务层，业务层也只是传递了这个请求到持久层，持久层对数据库做简单的SQL查询获得用户的数据。这个数据按照原理返回，不会有任何的二次处理，返回到界面上。\n\n每个分层架构或多或少都可能遇到这种场景。关键在于这样的请求有多少。80-20原则可以帮助你确定架构是否处于反污水模式。大概有百分之二十的请求仅仅是做简单的穿越，百分之八十的请求会做一些业务逻辑操作。然而，如果这个比例反过来，大部分的请求都是仅仅穿过层，不做逻辑操作。那么开放一些架构层会比较好。不过由于缺少了层次隔离，项目会变得难以控制。\n\n### 模式分析\n\n下面的的表里分析了分层架构的各个方面。\n\n##### 整体灵活性\n评级:低 \n分析:总体灵活性是响应环境变化的能力。尽管分层模式中的变化可以隔绝起来，想在这种架构中做一些也改变也是并且费时费力的。分层模式的笨重以及经常出现的组件之间的紧耦合是导致灵活性降低的原因。\n\n#### 易于部署\n评级:低 \n分析:这取决于你怎么发布这种模式，发布程序可能比较麻烦，尤其是很大的项目。一个组件的小小改动可能会影响到整个程序的发布(或者程序的大部分)。发布必须是按照计划，在非工作时间或者周末进行发布。因此。分层模式导致应用发布一点也不流畅，在发布上降低了灵活性。\n\n#### 可测试性\n评级:高 \n分析:因为组件都处于各自的层次中，可以模拟其他的层，或者说直接去掉层，所以分层模式很容易测试。开发者可以单独模拟一个展示组件，对业务组件进行隔绝测试。还可以模拟业务层来测试某个展示功能。\n\n#### 性能\n评级:低 \n分析:尽管某些分层架构的性能表现的确不错，但是这个模式的特点导致它无法带来高性能。因为一次业务请求要穿越所有的架构层，做了很多不必要的工作。\n\n#### 伸缩性\n评级:低 \n分析:由于这种模式以紧密耦合的趋势在发展，规模也比较大，用分层架构构建的程序都比较难以扩展。你可以把各个层分成单独的物理模块或者干脆把整个程序分成多个节点来扩展分层架构，但是总体的关系过于紧密，这样很难扩展。\n\n#### 易开发性\n评级:容易 \n分析:在开发难度上面，分层架构得到了比较高的分数。因为这种架构对大家来说很熟悉，不难实现。大部分公司在开发项目的都是通过层来区分技术的，这种模式对于大多数的商业项目开发来说都很合适。公司的组织架构和他们软件架构之间的联系被戏称为\"Conway's law\"。你可以Google一下查查这个有趣的联系。\n\n\n\n\n## 第二章 事件驱动架构\n\n> 译者注：文章中 mediator 及 broker 的概念很容易混淆，在文章的结尾处译者对两者的区别（还有 proxy）进行了一定的阐述\n\n事件驱动架构模式是一种主流的异步分发事件架构模式，常用于设计高度可拓展的应用。当然了，它有很高的适应性，使得它在小型应用、大型应用、复杂应用中都能表现得很好。事件驱动架构模式由高度解耦、单一目的的事件处理组件构成，这些组件负责异步接收和处理事件。\n\n事件驱动架构模式包含了两种主要的拓扑结构：**中介(mediator)**拓扑结构和**代理(broker)**拓扑结构。 mediator 拓扑结构通常在你需要在事件内使用一个核心中介分配、协调多个步骤间的关系、执行顺序时使用；而代理拓扑结构则在你想要不通过一个核心中介将多个事件串联在一起时使用。由于这两种结构在结构特征和实现策略上有很大的差别，所以如果你想要在你的应用中使用它们的话，一定要深入理解两者的技术实现细节，从而为你的实际使用场景选择最合理的结构。\n\n### 中介 ( Mediator )拓扑结构\n\n中介拓扑结构适合用于拥有多个步骤，并需要在处理事件时能通过某种程度的协调将事件分层的场景，举例来说吧：假设你现在需要进行股票交易，那你首先需要证券所批准你进行交易，然后检查进行这次交易是否违反了股票交易的某种规定，检查完成后将它交给一个经纪人，计算佣金，最后与经纪人确认交易。以上所有步骤都需要通过中介进行某种程度的分配和协调，以决定各个步骤的执行顺序，判断哪些步骤可以并行，哪些步骤可以串行。\n\n在中介拓扑结构中主要有四种组件：事件队列（event queue）, 事件中介, 事件通道（event channel）, 和 事件处理器（event processor）。当事件流需要被处理，客户端将一个事件发送到某个事件队列中，由消息队列将其运输给事件中介进行处理和分发。事件中介接收到该消息后，并通过将额外的异步事件发送给事件通道，让事件通道执行该异步事件中的每一个步骤，使得事件中介能够对事件进行分配、协调。同时，又因为事件处理器是事件通道的监听器，所以事件通道对异步事件的处理会触发事件处理器的监听事件，使事件处理器能够接收来自事件中介的事件，执行事件中具体的业务逻辑，从而完成对传入事件的处理。事件驱动架构模式中的中介拓扑模式结构大体如下图：\n\n![2-1](images/2-1.png)\n\n在事件驱动架构中拥有十几个，甚至几百个事件队列是很常见的情况，该模式并没有对事件队列的实现有明确的要求，这就意味着事件队列可以是消息队列，Web 服务端，或者其它类似的东西。\n\n在事件驱动架构模式中主要有两种事件：初始事件和待处理事件。初始事件是中介所接收到的最原始的事件，没有经过其他组件的处理；而待处理事件是由事件中介生成，由事件处理器接收的组件，不能把待处理事件看作初始事件经过处理后得到的事件，两者是完全不同的概念。\n\n事件中介负责分配、协调初始事件中的各个待执行步骤，事件中介需要为每一个初始事件中的步骤发送一个特定的待处理事件到事件通道中，触发事件处理器接收和处理该待处理事件。这里需要注意的是：事件 中介没有真正参与到对初始事件必须处理的业务逻辑的实现之中；相反，事件中介只是知道初始事件中有哪些步骤需要被处理。\n\n事件中介通过事件通道将与初始事件每一个执行步骤相关联的特定待处理事件传递给事件处理器。尽管我们通常在待处理事件能被多个事件处理器处理时才会在中介拓扑结构中使用 消息主题，但事件通道仍可以是消息队列或 消息主题。（但需要注意的是，尽管在使用 消息主题 时待处理事件能被多个事件处理器处理，但由于接收到的待处理事件各异，所以对其处理的操作也各不相同）\n\n为了能顺利处理待处理事件，事件处理器组件中包含了应用的业务逻辑。此外，事件处理器作为事件驱动架构中的组件，不依赖于其他组件，独立运作，高度解耦，在应用或系统中完成特定的任务。当事件处理器需要处理的事件从细粒度（例如：计算订单的营业税）变为粗粒度（例如：处理一项保险索赔事务），必须要注意的是：一般来说，每一个事件处理器组件都只完成一项唯一的业务工作，并且事件处理器在完成其特定的业务工作时不能依赖其他事件处理器。\n\n虽然事件中介有许多方法可以实现，但作为一名架构工程师，你应该了解所有实现方式，以确保你能为你的实际需求选择了最合适的事件中介。\n\n事件中介最简单、常见的实现就是使用开源框架，例如：Spring Integration，Apache Camel，或 Mule ESB。事件流在这些开源框架中通常用 Java 或 域特定语言（domain-specific language）。在调节过程和业务流程都很复杂的使用场景下，你可以使用业务流程执行语言（BPEL - business process execution language）结合类似开源框架 Apache ODE 的 BPEL 引擎进行开发。BPEL 是一种基于 XML 的服务编制编程语言，它为处理初始事件时需要描述的数据和步骤提供了描述。对每一个拥有复杂业务流程（包括与用户交互的执行步骤）的大型应用来说，你可以使用类似 jBPM 的业务处理管理系统（business process manager）实现事件中介。\n\n如果你需要使用中介拓扑结构，那么理解你的需求，并为其匹配恰当的事件中介实现是构建事件驱动架构过程中至关重要的一环。使用开源框架去解决非常复杂的业务处理、管理、调节事件，注定会失败，因为开源框架只是用 BPM 的方式解决了一些简单的事件分发逻辑，比起你的业务逻辑，其中的事件分发逻辑简直是九牛一毛。\n\n为了解释清楚中介拓扑结构是怎么运作的，我假设你在某家保险公司买了保险，成为了受保人，然后你打算搬家。在这种情况下，初始事件就是重定位事件，或者其他类似的事件。与重定位事件相关的处理步骤就像下图展示的那样，处于事件中介之中。对每一个初始事件的传入，事件中介都会创建一个待处理事件（例如：改变地址，重新计算保险报价，等等……），并将它发送给事件通道，等待发出响应的事件处理器处理待处理事件（例如：客户改变地址的操作流程、报价计算流程，等等……）。直到初始事件中的每一个需要处理的步骤完成了，这项处理才会继续（例如：把所有手续都完成之后，保险公司才会帮你改变地址）。事件中介中，重新报价和更新理赔步骤上面的直线表示这些步骤可以并行处理。\n\n![2-1](images/2-2.png)\n\n### 代理 (Broker) 拓扑结构\n\n代理拓扑结构与中介拓扑结构不同之处在于：代理拓扑结构中没有核心的事件中介；相反，事件流在代理拓扑结构中通过一个轻量的消息代理（例如：ActiveMQ, HornetQ，等等……）将消息串联成链状，分发至事件处理器组件中进行处理。代理扑结构适用的使用场景大致上具有以下特征：你的事件处理流相对来说比较简单，而且你不想（不需要）使用核心的事件分配、调节机制以提高你处理事件的效率。\n\n在代理拓扑结构中主要包括两种组件：代理和事件处理器。代理可被集中或相互关联在一起使用，此外，代理中还可以包含所有事件流中使用的事件通道。\n\n存在于代理组件中的事件通道可以是消息队列，消息主题,或者是两者的组合。\n\n代理拓扑结构大致如下图，如你所见，在这其中没有一个核心的事件中介组件控制和分发初始事件；相反，每一个事件处理器只负责处理一个事件，并向外发送一个事件，以标明其刚刚执行的动作。例如，假设存在一个事件处理器用于平衡证券交易，那么事件处理器可能会接受一个拆分股票的初始事件，为了处理这项初始事件，事件处理器则需要重新平衡股票的投资金额，而这个重新平衡的事件将由另一个事件处理器接收、处理。在这其中有一个细节需要注意：处理初始事件后，由事件处理器发出的事件不被其他事件处理器接收、处理的情况时常会发生，尤其是你在为应用添加功能和进行功能拓展时，这种情况更为常见。\n\n![2-3](images/2-3.png)\n\n为了阐明代理拓扑结构的运行机制，我会用一个与讲解中介拓扑结构时类似的例子（受保人旅行的例子）进行解释。因为在代理拓扑结构中没有核心事件中介接收初始事件，那么事件将由客户处理组件直接接收，改变客户的地址，并发出一个事件告知系统客户的地址被其进行了改变（例如：改变地址的事件）。在这个例子中：有两个事件处理器会与改变地址的事件产生关联：报价处理和索赔处理。报价事件处理器将根据受保人的新地址重新计算保险的金额，并发出事件告知系统该受保人的保险金额被其改变。而索赔事件处理器将接受到相同的改变地址事件，不同的是，它将更新保险的赔偿金额，并发出一个更新索赔金额事件告知系统该受保人的赔偿金额被其改变。当这些新的事件被其他事件处理器接收、处理，使事件链一环扣一环地交由系统处理，直到事件链上的所有事件都被处理完，初始事件的处理才算完成。\n\n![2-4](images/2-4.png) \n\n如上图所示，代理拓扑结构的设计思想就是将对事件流的处理转换为对事件链的业务功能处理，把代理拓扑结构看作是接力比赛是最好的理解方式：在一场4*100的接力比赛中，每一位运动员都需要拿着一根接力棒跑100米，运动员跑完自己的100米后需要将接力棒传递给下一位运动员，直到最后一位运动员拿着接力棒跑过终点线，整场接力比赛才算结束。根据这样的逻辑我们还可以知道：在代理拓扑结构中，一旦某个事件处理器将事件传递给另一个事件处理器，那么这个事件处理器不会与该事件的后续处理产生任何联系。\n\n### 顾虑\n\n实现事件驱动架构模式相对于实现其他架构模式会更困难一些，因为它通过异步处理进行事件分发。当你需要在你的应用中使用这种架构模式，你必须处理各种由事件分发处理带来的问题，例如：远程操作功能的可用性，缺少权限，以及在代理或中介中处理事件失败时，用于处理这种情况的重连逻辑。如果你不能很好地解决这些问题，那你的应用一定会出现各种 Bug，让开发团队痛苦不已。\n\n在选择事件驱动架构时还有一点需要注意：在处理单个业务逻辑时，这种架构模式不能处理细粒度的事务。因为事件处理器都高度解耦、并且广泛分布，这使得在这些事件处理器中维持一个业务单元变得非常困难。因此，当你使用这种架构模式架构你的应用时，你必须不断地考虑哪些事件能单独被处理，哪些不能，并为此设计相应事件处理器的处理粒度。如果你发现你需要将一个业务单元切割成许多子单元，并一一匹配相应的事件处理器，那你就要为此进行代码设计；如果你发现你用多个不同的事件处理器处理的哪些业务其实是可以合并到一个业务事件之中的，那么这种模式可能并不适合你的应用，又或者是你的设计出了问题。\n\n使用事件驱动架构模式最困难的地方就在于架构的创建、维护、以及对事件处理器的管理。通常每一个事件都拥有其指定的事件处理协议（例如：传递给事件处理器的数据类型、数据格式），这就使得设下标准的数据格式成为使用事件驱动架构模式中至关重要的一环（例如：XML，JSON，Java 对象，等等……），并在架构创建之初就为这些数据格式授权，以便处理。\n\n### 模式分析\n\n下面是基于对常见的架构模式特征进行评价的标准，对事件驱动架构模式所作的实际分析，评价是以常见的架构模式的相似实现作为标准进行的，如果你想知道进行对比的其他架构模式对应的特征，可以结尾处查看 [附录A](#appendix) 的汇总表。 \n\n#### 整体灵活性\n评价：高 \n分析：整体灵活性用于评价架构能否在不断改变的使用场景下快速响应，因为事件处理器组件使用目的单一、高度解耦、与其他事件处理器组件相互独立，不相关联，那么发生的改变对一个或多个事件处理器来说普遍都是独立的，使得对改变的反馈非常迅速，不需要依赖其他事件处理器的响应作出处理。\n\n#### 易于部署\n评价：高 \n分析：总的来看，事件驱动架构模式由于其高度解耦的事件处理器组件的存在，对事件的部署相对来说比较容易，而使用代理拓扑结构比使用中介拓扑结构进行事件调度会更容易一些，主要是因为在 中介拓扑结构中事件处理器与事件中介紧密地耦合在一起：事件处理器中发生改变后，事件中介也随之改变，如果我们需要改变某个被处理的事件，那么我们需要同时调度事件处理器和事件中介。\n\n#### 可测试性\n评价：低 \n分析：虽然在事件驱动架构模式中进行单元测试并不困难，但如果我们要进行单元测试，我们就需要某种特定的测试客户端或者是测试工具产生事件，为单元测试提供初始值。此外，由于事件驱动架构模式是异步进行事件分发的，其异步处理的特性也为单元测试带来了一定的困难。\n\n#### Performance 性能\n评价：高 \n分析：对消息传递的架构可能会让设计出来的事件驱动架构的表现不如我们的期望，但通常来说，该模式都能通过其异步处理的特性展示优秀的性能表现；换句话来说，高度解耦，异步并行操作大大减少了传递消息过程中带来的时间开销。\n\n#### 伸缩性\n评价：高 \n分析：事件驱动架构中的高度解耦、相互独立的事件处理器组件的存在，使得可拓展性成为该架构与生俱来的优点。架构的这些特定使得事件处理器能够进行细粒度的拓展，使得每一个事件处理器都能单独被拓展，而不影响其他事件处理器。\n\n#### 易于开发\n评价：低 \n分析：由于使用事件驱动架构进行开发需要考虑其异步处理机制、协议创建流程，并且开发者需要用代码为事件处理器和操作失败的代理提供优秀的错误控制环境，无疑使得用事件驱动架构进行开发会比使用其他架构进行开发要困难一些。\n\n### 译者注\n\n读完整篇文章，我相信大家对 mediator 与 broker 这两个概念有一个大致的印象，但就两者的译文来看，中介和代理似乎没什么区别，尤其是了解 proxy 的读者会更加困惑，这三者之间到底是什么关系？它们的概念是互通的吗？为了解决这种混淆，译者将在此阐述三者间的区别：\n\n假如现在我有一个事件/事件流需要被处理，那么使用 mediator、broker、proxy 处理事件的区别在哪里呢？\n\n- 如果我们使用 mediator，那就意味着我将把事件流交给 mediator，mediator 会帮我把事件分解为多个步骤，并分析其中的执行逻辑，调整和分发事件（例如判断哪些事件可以并行，哪些事件可以串行），然后根据 mediator 分解、调节的结果去执行事件中的每一个步骤，把所有步骤完成后，就能把需要处理的事件处理好。\n\n- 如果我们使用 broker，那就意味着我将把事件交给 broker，broker 获得事件后会把事件发出去（在本文中为：通知架构中所有可用的事件处理器），事件处理器们接收到事件以后，判断处理这个事件是否为自己的职责之一，如果不是则无视，与自己有关则把需要完成的工作完成，完成后如果事件还有后续需要处理的事件，则通过 broker 再次发布，再由相关的事件处理器接收、处理。以这样的方式将事件不断分解，沿着事件链一级一级地向下处理子事件，直到事件链中的所有事件被完成，我的事件也就处理好了。\n\n- 如果我们使用 proxy，那就意味着我自己对需要处理的事件进行了分解，然后把不同的子事件一一委托给不同的 proxy，由被委托的 proxy 帮我完成子事件，从而完成我要做的事件。\n\n\n\n## 第三章 微内核架构\n\n微内核架构模式(也称为插件化应用架构)对于基于产品的应用程序来说是一个很自然的选择。基于产品的应用是指一个经过打包的、可以通过版本下载的一个典型的第三方产品。然而，很多公司也会开发和发布他们的内部商业软件，完整的版本号、发布日志和可插拔的新特性，这些就非常符合微内核架构的思想。微内核架构模式可以通过插件的形式添加额外的特性到核心系统中，这提供了很好的扩展性，也使得新特性与核心系统隔离开来。( 译者注: 比如，著名的Eclipse IDE就是基于插件化开发的，eclipse核心更像是一个微内核，或者我们可把它叫做开放平台，其他的功能通过安装插件的形式添加到eclipse中。 )\n\n### 模式描述\n\n微内核架构主要需要考虑两个方面: 核心系统和插件模块。应用逻辑被划分为独立的插件模块和核心系统，这样就提供良好的可扩展性、灵活性，应用的新特性和自定义处理逻辑也会被隔离。图3-1演示了基本的微内核架构。\n\n微内核架构的核心系统一般情况下只包含一个能够使系统运作起来的最小化模块。很多操作系统的实现就是使用微内核架构，因此这也是该架构名字的由来。从商业应用的角度看，核心系统通常是为特定的使用场景、规则、或者复杂条件处理定义了通用的业务逻辑，而插件模块根据这些规则实现了具体的业务逻辑。\n\n![3-1](images/3-1.png)\n\n插件模块是一个包含专业处理、额外特性的独立组件，自定义代码意味着增加或者扩展核心系统以达到产生附加的业务逻辑的能力。通常，插件模块之间应该是没有任何依赖性的，但是你也可以设计一个需要依赖另一个插件的插件。但无论如何，使得插件之间可以通信的同时避免插件之间产生依赖又是一个特别重要的问题。\n\n核心系统需要了解插件模块的可用性以及如何获取到它们。一个通用的实现方法是通过一组插件注册表。这个插件注册表含有每个插件模块的信息，包括它的名字、数据规约和远程访问协议(取决于插件如何与核心系统建立连接)。例如，一个税务软件的用于标识高风险的税务审计插件可能会有一个含有插件名(比如AuditChecker)的注册入口，数据规约(输入数据、输出数据)和规约格式( 比如xml )。如果这个插件是通过SOAP服务访问，那么它可能会包含一个WSDL (Web Services Definition Language).\n\n插件模块可以通过多种方式连接到核心系统，包括OSGi ( open service gateway initiative )、消息机制、web服务或者直接点对点的绑定 ( 比如对象实例化，即依赖注入 )。你使用的连接类型取决于你构建的应用类型和你的特殊需求（比如单机部署还是分布式部署）。微内核架构本身没有指定任何的实现方式，唯一的规定就是插件模块之间不要产生依赖。\n\n插件和核心系统的通信规范包含标准规范和自定义规范。自定义规范典型的使用场景是插件组件是被第三方构建的。在这种情况下，通常是在第三方插件规约和你的标准规范创建一个Adapter来使核心系统根本不需要知道每个插件的具体细节。当创建标准规范 ( 通常是通过XML或者Java Map )时，从一开始就创建一个版本策略是非常重要的。 \n\n### 架构示例\n\n也许微内核架构的最好示例就是大家熟知的Eclipse IDE了。下载最基本的Eclipse后，它只能提供一个编辑器。然后，一旦你开始添加插件，它就变成一个高度可定制化和非常有用的产品（译者注 : 更多内容大家可以参考 [开源软件架构 卷1：第6章 Eclipse之一](http://www.ituring.com.cn/article/6817) ）。浏览器是另一个使用微内核架构的产品示例，它由一个查看器和其他扩展的插件组成。\n\n基于微内核架构的示例数不胜数，但是大型的商业应用呢？微内核应用架构也适用于这些情形。为了阐述这个观点，让我们来看看另一个保险公司的示例，但是这次的示例会涉及保险赔偿处理。 \n\n赔偿处理是一个非常复杂的过程。每个州都有不同的关于保险赔偿的规则和条文。例如一些州允许在你的挡风玻璃被石头砸碎时免费进行替换，但是一些州则不是这样。因为大家的标准都不一样，因此赔偿标准几乎可以是无限的。\n\n有很多保险赔偿应用运用大型和复杂的规则处理引擎来处理不同规则带来的复杂性。然而，可能会因为某条规则的改变而引起其他规则的改变而使得这些规则处理引擎变成一个大泥球，或者使简单需求变更会需要一个很大的分析师、工程师、测试工程师来进行处理。使用微内核架构能够很好的解决这个问题，核心系统只知道根据赔偿规则处理，但这个赔偿规则是抽象的，系统将赔偿规则作为一个插件规范，具体的规则有对应的实现，然后注入到系统中即可。\n\n图3-2中的一堆文件夹代表了赔偿处理核心系统。它包含一些处理保险赔偿的基本业务逻辑。每一个插件模块包含每个州的具体赔偿规则。在这个例子中，插件模块通过自定义源代码实现或者分离规则引起实例。不管具体实现如何，关键就在于赔偿规则和处理都从核心系统中分离，而这些规则和处理过程都可以被动态地添加、移除，而这些改变对于核心系统和其他插件只有很小的影响或者根本不产生影响。\n\n![3-2](images/3-2.png)\n\n### 注意事项\n\n对于微内核架构来说一个很重要的一点就是它能够被嵌入或者说作为另一种架构的一部分。例如，如果这个架构解决的是一个你应用中易变领域的特定的问题 ( 译者注 : 即插件化能够解决你应用中的某个特定模块的架构问题 )，你可能会发现你不能在整个应用中使用这种架构。在这种情况下，你可以将微内核架构嵌入到另一个架构模式中 ( 比如分层架构 )。同样的，在上一章节中描述的事件驱动架构中的事件处理器组件也可以使用微内核架构。\n\n微内核架构对渐进式设计和增量开发提供了非常好的支持。你可以先构建一个单纯的核心系统，随着应用的演进，系统会逐渐添加越来越多的特性和功能，而这并不会引起核心系统的重大变化。\n\n对基于产品的应用来说，微内核架构应该是你的第一选择。特别是那些你会在后续开发中发布附加特性和控制哪些用户能够获取哪些特性的应用。如果你在后续开发中发现这个架构不能满足你的需求了，你能够根据你的特殊需求将你的应用重构为另一个更好的架构。\n\n### 模式分析\n\n下面的表格中包含了微内核架构每个特性的评级和分析。以微内核架构的最经典的实现方式的自然趋势为依据对每个特性进行评级。关于微内核架构与其他模式的相关性比较请参考附录A。\n\n#### 整体灵活性\n评级 : 高 \n分析 : 整体灵活性是指能够快速适应不断变化的环境的能力。通过插件模块的松耦合实现，可以将变化隔离起来，并且快速满足需求。通常，微内核架构的核心系统很快趋于稳定，这样系统就变得很健壮，随着时间的推移它也不会发生多大改变。\n\n#### 易于部署\n评级 : 高 \n分析 : 根据实现方式，插件模块能够在运行时被动态地添加到核心系统中 （ 比如，热部署 ）,把停机时间减到最小。\n\n#### 可测试性\n评级 : 高 \n分析 : 插件模块能够被独立的测试，能够非常简单地被核心系统模拟出来进行演示，或者在对核心系统很小影响甚至没有影响的情况下对一个特定的特性进行原型展示。\n\n#### 性能\n评级 : 高 \n分析 : 使用微内核架构不会自然而然地使你的应用变得高性能。通常，很多使用微内核架构的应用运行得很好，因为你能定制和简化应用程序，使它只包含那些你需要的功能模块。JBoss应用服务器就是这方面的优秀示例: 依赖于它的插件化架构，你可以只加载你需要的功能模块，移除那些消耗资源但没有使用的功能特性，比如远程访问，消息传递，消耗内存、CPU的缓存，以及线程，从而减小应用服务器的资源消耗。\n\n#### 伸缩性\n评级 : 低 \n分析 : 因为微内核架构的实现是基于产品的，它通常都比较小。它们以独立单元的形式实现，因此没有太高的伸缩性。此时，伸缩性就取决于你的插件模块，有时你可以在插件级别上提供可伸缩性，但是总的来说这个架构并不是以构建高度伸缩性的应用而著称的。\n\n#### 易于开发\n评级 : 低 \n分析 : 微内核架构需要考虑设计和规约管理，使它不会很难实现。规约的版本控制，内部的插件注册，插件粒度，丰富的插件连接的方式等是涉及到这个架构模式实现复杂度的重要因素。\n\n\n\n\n\n## 第四章 微服务架构\n\n微服务架构模式作为替代单体应用和面向服务架构的一个可行的选择，在业内迅速取得进展。由于这个架构模式仍然在不断的发展中，在业界存在很多困惑——这种模式是关于什么的？它是如何实现的？本报告的这部分将为你提供关键概念和必要的基础知识来理解这一重要架构模式的好处(和取舍)，以此来判断这种架构是否适合你的应用。\n\n### 模式描述\n\n不管你选择哪种拓扑或实现风格,有几种常见的核心概念适用于一般架构模式。第一个概念是*单独部署单元*。如图4-1所示，微服务架构的每个组件都作为一个独立单元进行部署，让每个单元可以通过有效、简化的传输管道进行通信，同时它还有很强的扩展性，应用和组件之间高度解耦，使得部署更为简单。\n\n也许要理解这种模式，最重要的概念就是服务组件（service component）。不要考虑微服务架构内部的服务，而最好是考虑服务组件，从粒度上讲它可以小到单一的模块，或者大至一个应用程序。服务组件包含一个或多个模块（如Java类），这些模块可以提供一个单一功能（如，为特定的城市或城镇提供天气情况），或也可以作为一个大型商业应用的一个独立部分（如，股票交易布局或测定汽车保险的费率）。在微服务架构中，正确设计服务组件的粒度是一个很大的挑战。在接下来的服务组件部分对这一挑战进行了详细的讨论。\n\n![4-1](images/4-1.png) \n\n微服务架构模式的另一个关键概念是它是一个*分布式*的架构，这意味着架构内部的所有组件之间是完全解耦的，并通过某种远程访问协议（如， JMS, AMQP, REST, SOAP, RMI等）进行访问。这种架构的分布式特性是它实现一些优越的可扩展性和部署特性的关键所在。\n\n微服务架构另一个令人兴奋的特性是它是由其他常见架构模式存在的问题演化来的，而不是作为一个解决方案被创造出来等待问题出现。微服务架构的演化有两个主要来源：使用分层架构模式的单体应用和使用面向服务架构的分布式应用。\n\n由单体应用( 一个应用就是一个整体 )到微服务的发展过程主要是由持续交付开发促成的。从开发到生产的持续部署管道概念,简化了应用程序的部署。单体应用通常是由紧耦合的组件组成，这些组件同时又是另一个单一可部署单元的一部分，这使得它繁琐，难以改变、测试和部署应用（因此常见的“月度部署”周期出现并通常发生在大型IT商店项目）。这些因素通常会导致应用变得脆弱以至于每次有一点新功能部署后应用就不能运行。微服务架构模式通过将应用分隔成多个可部署的单元（服务组件）的方法来解决这一问题，这些服务组件可以独立于其他服务组件进行单独开发、测试和部署。\n\n另一个导致微服务架构模式产生的演化过程是由面向服务架构模式（SOA）应用程序存在的问题引起的。虽然SOA模式非常强大，提供了无与伦比的抽象级别、异构连接、服务编排，并保证通过IT能力调整业务目标，但它仍然是复杂的,昂贵的,普遍存在，它很难理解和实现，对大多数应用程序来说过犹不及。微服务架构通过简化服务概念，消除编排需求、简化服务组件连接和访问来解决复杂度问题。\n\n### 模式拓扑\n\n虽然有很多方法来实现微服务架构模式,但三个主要的拓扑结构脱颖而出，最常见和流行的有:基于REST API的拓扑结构,基于REST的应用拓扑结构和集中式消息拓扑结构。\n\n基于REST的API拓扑适用于网站，通过某些API对外提供小型的、自包含的服务。这种拓扑结构,如图4 - 2所示,由粒度非常细的服务组件（因此得名微服务）组成，这些服务组件包含一个或两个模块并独立于其他服务来执行特定业务功能。在这种拓结构扑中,这些细粒度的服务组件通常被REST-based的接口访问，而这个接口是通过一个单独部署的web API层实现的。此种拓扑的例子包含一些常见的专用的、基于云的RESTful web service，大型网站像Yahoo, Google, and Amazon都在使用。\n\n![4-2](images/4-2.png) \n\n基于REST的应用拓扑结构与基于REST API的不同，它通过传统的基于web的或胖客户端业务应用来接收客户端请求，而不是通过一个简单的API层。如图4-3所示，应用的用户接口层（user interface layer）是一个web应用，可以通过简单的REST-based接口访问单独部署的服务组件（业务功能）。该拓扑结构中的服务组件与API-REST-based拓扑结构中的不同，这些服务组件往往会更大、粒度更粗、代表整个业务应用程序的一小部分，而不是细粒度的、单一操作的服务。这种拓扑结构常见于中小型企业等复程度相对较低的应用程序。\n\n![4-3](images/4-3.png) \n\n微服务架构模式中另一个常见的方法是集中式消息拓扑。该拓扑（如图4-4所示）与前面提到的基于REST的应用拓扑类似，不同的是，application REST- based拓扑结构使用REST进行远程访问，而该拓扑结构则使用一个轻量级的集中式消息代理（如，ActiveMQ, HornetQ等等）。不要将该拓扑与面向服务架构模式混淆或将其当做SOA简化版（“SOA-Lite”），这点是极其重要的。该拓扑中的轻量级消息代理（Lightweight Message Broker）不执行任何编排,转换,或复杂的路由;相反,它只是一个轻量级访问远程服务组件的传输工具。\n\n集中式消息拓扑结构通常应用在较大的业务应用程序中，或对于某些对传输层到用户接口层或者到服务组件层有较复杂的控制逻辑的应用程序中。该拓扑较之先前讨论的简单基于REST的拓扑结构，其好处是有先进的排队机制、异步消息传递、监控、错误处理和更好的负载均衡和可扩展性。与集中式代理相关的单点故障和架构瓶颈问题已通过代理集群和代理联盟（将一个代理实例为分多个代理实例，把基于系统功能区域的吞吐量负载划分开处理）解决。\n\n![4-4](images/4-4.png) \n\n### 避免依赖和编排\n\n微服务架构模式的主要挑战之一就是决定服务组件的粒度级别。如果服务组件粒度过粗，那你可能不会意识到这个架构模式带来的好处（部署、可扩展性、可测试性和松耦合），然而,服务组件粒度过细将导致服务编制要求,这会很快导致将微服务架构模式变成一个复杂、容易混淆、代价昂贵并易于出错的重量级面向服务架构。\n\n如果你发现需要从应用内部的用户接口或API层编排服务组件，那么很有可能你服务组件的粒度太细了。如果你发现你需要在服务组件之间执行服务间通信来处理单个请求,那么很有可能要么是你服务组件的粒度太细了，要么是没有从业务功能角度正确划分服务组件。\n\n服务间通信，可能导致组件之间产生耦合，但可以通过共享数据库进行处理。例如，若一个服务组件处理网络订单而需要用户信息时，它可以去数据库检索必要的数据，而不是调用客户服务组件的功能。\n\n共享数据库可以处理信息需求，但是共享功能呢？如果一个服务组件需要的功能包含在另一个服务组件内，或是一个公共的功能,那么有时你可以将服务组件的共享功能复制一份（因此违反了DRY规则：don’t repeat yourself）。为了保持服务组件独立和部署分离，微服务架构模式实现中会存在一小部分由重复的业务逻辑而造成的冗余，这在大多数业务应用程序中是一个相当常见的问题。小工具类可能属于这一类重复的代码。\n\n如果你发现就算不考虑服务组件粒度的级别，你仍不能避免服务组件编排,这是一个好迹象,可能此架构模式不适用于你的应用。由于这种模式的分布式特性，很难维护服务组件之间的单一工作事务单元。这种做法需要某种事务补偿框架回滚事务,这对此相对简单而优雅的架构模式来说，显著增加了复杂性。\n\n### 注意事项\n\n微服务架构模式解决了很多单体应用和面向服务架构应用存在的问题。由于主要应用组件被分成更小的,单独部署单元,使用微服务架构模式构建的应用程序通常更健壮,并提供更好的可扩展性,支持持续交付也更容易。\n\n该模式的另一个优点是,它提供了实时生产部署能力，从而大大减少了传统的月度或周末“大爆炸”生产部署的需求。因为变化通常被隔离成特定的服务组件，只有变化的服务组件才需要部署。如果你的服务组件只有一个实例，你可以在用户界面程序编写专门的代码用于检测一个活跃的热部署,一旦检测到就将用户重定向到一个错误页面或等待页面。你也可以在实时部署期间，将服务组件的多个实例进行交换，允许应用程序在部署期间保持持续可用性（分层架构模式很难做到这点）。\n\n最后一个要重视的考虑是，由于微服务架构模式是分布式的架构，他与事件驱动架构模式具有一些共同的复杂的问题，包括约定的创建、维护，和管理，远程系统的可用性，远程访问身份验证和授权。\n\n### 模式分析\n\n下面这个表中包含了微服务架构模式的特点分析和评级，每个特性的评级是基于自然趋势，基于典型模式实现的能力特性,以及该模式是以什么闻名的。本报告中该模式与其他模式的并排比较，请参考报告最后的附件A。\n\n#### 整体灵活性\n评级：高 \n分析：整体的灵活性是能够快速响应不断变化的环境。由于单独部署单元的概念,变化通常被隔离成单独的服务组件,使得部署变得快而简单。同时，使用这种模式构建的应用往往是松耦合的，也有助于促进改变。\n\n#### 易于部署\n评级：高 \n分析：整体来讲，由于该模式的解耦特性和事件处理组件使得部署变得相对简单。broker拓扑往往比mediator拓扑更易于部署，主要是因为event-mediator组件与事件处理器是紧耦合的，事件处理器组件有一个变化可能导致event mediator跟着变化，有任何变化两者都需要部署。\n\n#### 可测试性\n评级：高 \n分析：由于业务功能被分离成独立的应用模块,可以在局部范围内进行测试，这样测试工作就更有针对性。对一个特定的服务组件进行回归测试比对整个单体应用程序进行回归测试更简单、更可行。而且,由于这种模式的服务组件是松散耦合的，从开发角度来看，由一个变化导致应用其他部分也跟着变化的几率很小，并能减小由于一个微小的变化而不得不对整个应用程序进行测试的负担。\n\n#### 性能\n评级：低 \n分析：虽然你可以从实现该模式来创建应用程序并可以很好的运行，整体来说，由于微服务架构模式的分布式特性，并不适用于高性能的应用程序。\n\n#### 伸缩性\n评级：高 \n分析：由于应用程序被分为单独的部署单元,每个服务组件可以单独扩展，并允许对应用程序进行扩展调整。例如，股票交易的管理员功能区域可能不需要扩展，因为使用该功能的用户很少，但是交易布局服务组件可能需要扩展，因为大多数交易应用程序需要具备处理高吞吐量的功能。\n\n#### 易于开发\n评级：高 \n分析：由于功能被分隔成不同的服务组件，由于开发范围更小且被隔离，开发变得更简单。程序员在一个服务组件做出一个变化影响其他服务组件的几率是很小的，从而减少开发人员或开发团队之间的协调。\n\n\n\n\n## 第五章 基于空间的架构\n\n大多数基于网站的商务应用都遵循相同的请求流程：一个请求从浏览器发到web服务器，然后到应用服务器，然后到数据库服务器。虽然这个模式在用户数不大的时候工作良好，但随着用户负载的增加,瓶颈会开始出现，首先出现在web服务器层，然后应用服务器层，最后数据库服务器层。通常的解决办法就是**向外扩展**，也就是增加服务器数量。这个方法相对来说简单和廉价，并能够解决问题。然而，对于大多数高访问量的情况，它只不过是把web服务器的问题移到了应用服务器。而扩展应用服务器会更复杂，而且成本更高，并且又只是把问题移动到了数据库服务器，那会更复杂，更贵。就算你能扩展数据库服务器，你最终会陷入一个金字塔式的情形，在金字塔最下面是web服务器，它会出现最多的问题，但也最好伸缩。金字塔顶部是数据库服务器，问题不多，但最难伸缩。\n\n在一个高并发大容量的应用中，数据库通常是决定应用能够支持多少用户同时在线的关键因素。虽然各种缓存技术和数据库伸缩产品都在帮助解决这个问题，但数据库难以伸缩的现实并没有改变。\n\n基于空间的架构模型是专门为了**解决伸缩性和并发问题**而设计的。它对于用户数量不可预测且数量级经常变化的情况同样适用。在架构级别来解决这个伸缩性问题通常是比增加服务器数量或者提高缓存技术更好的解决办法。\n\n### 模型介绍\n\n基于空间的模型（有时也称为云架构模型）旨在减少限制应用伸缩的因素。模型的名字来源于分布式共享内存中的 tuple space（数组空间）概念。高伸缩性是通过去除中心数据库的限制，并使用从内存中复制的数据框架来获得的。保存在内存的应用数据被复制给所有运行的进程。进程可以动态的随着用户数量增减而启动或结束，以此来解决伸缩性问题。这样因为没有了中心数据库，数据库瓶颈就此解决，此后可以近乎无限制的扩展了。\n\n大多数使用这个模型的应用都是标准的网站，它们接受来自浏览器的请求并进行相关操作。竞价拍卖网站是一个很好的例子 ( 12306更是一个典型的示例 )。网站不停的接受来自浏览器的报价。应用收到对某一商品的报价，记录下报价和时间，并且更新对该商品的报价，将信息返回给浏览器。\n\n这个架构中有两个主要的模块：**处理单元** 和 **虚拟化中间件**。下图展示了这个架构和里面的主要模块。\n\n![](images/5-1.png)\n\n处理单元包含了应用模块（或者部分的应用模块）。具体来说就是包含了web组件以及后台业务逻辑。处理单元的内容根据应用的类型而异——小型的web应用可能会部署到单一的处理单元，而大型一些的应用会将应用的不同功能模块部署到不同的处理单元中。典型的处理单元包括应用模块，以及保存在内存的数据框架和为应用失败时准备的异步数据持久化模块。它还包括复制引擎，使得虚拟化中间件可以将处理单元修改的数据复制到其他活动的处理单元。\n\n虚拟化中间件负责保护自身以及通信。它包含用于数据同步和处理请求的模块，以及通信框架，数据框架，处理框架和部署管理器。这些在下文中即将介绍的部分，可以自定义编写或者购买第三方产品来实现。\n\n### 组件间合作\n\n基于空间的架构的魔力就在虚拟化中间件，以及各个处理单元中的内存中数据框架。下图展示了包含着应用模块、内存中数据框架、处理异步数据恢复的组件和复制引擎的处理单元架构。\n\n虚拟化中间件本质上是架构的控制器，它管理请求，会话，数据复制，分布式的请求处理和处理单元的部署。虚拟化中间件有四个架构组件：通信框架，数据框架，处理框架和部署管理器。\n\n![](images/5-2.png)\n\n#### 通信框架\n\n通信框架管理输入请求和会话信息。当有请求进入虚拟化中间件，通信框架就决定有哪个处理单元可用，并将请求传递给这个处理单元。通信框架的复杂程度可以从简单的round robin算法到更复杂的用于监控哪个请求正在被哪个处理单元处理的next-available算法。\n\n![](images/5-3.png)\n\n#### 数据框架\n\n数据框架可能是这个架构中最重要和关键的组件。它与各个处理单元的数据复制引擎交互，在数据更新时来管理数据复制功能。由于通信框架可以将请求传递给任何可用的处理单元，所以每个处理单元包含完全一样的内存中数据就很关键。下图展示处理单元间如何同步数据复制，实际中是通过非常迅速的并行的异步复制来完成的，通常在微秒级。\n\n![](images/5-4.png)\n\n#### 处理框架\n\n处理框架，就像下图所示，是虚拟化中间件中一个可选组件，负责管理在有多个处理单元时的分布式请求处理，每个处理单元可能只负责应用中的某个特定功能。如果请求需要处理单元间合作（比如，一个订单处理单元和顾客处理单元），此时处理框架就充当处理单元见数据传递的媒介。\n\n![](images/5-5.png)\n\n#### 部署管理器\n\n部署管理器根据负载情况管理处理单元的动态启动和关闭。它持续检测请求所需时间和在线用户量，在负载增加时启动新的处理单元，在负载下降时关闭处理单元。它是实现可变伸缩性需求的关键。\n\n### 其他考虑\n\n基于空间的架构是一个复杂和实现起来相对昂贵的框架。对于有可变伸缩性需求的小型web应用是很好的选择，然而，对于拥有大量数据操作的传统大规模关系型数据库应用，并不那么适用。\n\n虽然基于空间的架构模型不需要集中式的数据储存，但通常还是需要这样一个，来进行初始化内存中数据框架，和异步的更新各处理单元的数据。通常也会创建一个单独的分区，来从隔离常用的断电就消失的数据和不常用的数据，这样减少处理单元之间对对方内存数据的依赖。\n\n值得注意的是，虽然这个架构的另一个名字是云架构，处理单元（以及虚拟化中间件）都没有放在云端服务或者PaaS上。他们同样可以简单的放在本地服务器，这也是为什么我更倾向叫它“基于空间的架构”。\n\n从产品实现的角度讲，这个架构中的很多组件都可以从第三方获得，比如GemFire, JavaSpaces, GigaSpaces，IBM Object Grid，nCache，和 Oracle Coherence。由于架构的实现根据工程的预算和需求而异，所以作为架构师，你应该在实现或选购第三方产品前首先明确你的目标和需求。\n\n### 架构分析\n\n下面的表格是这个架构的特征分析和评分。每个特征的评分是基于一个典型的架构实现来给出的。要知道这个模式相对别的模式的对比，请参见最后的附录A。\n\n#### 综合能力\n评分：高 \n分析：综合能力是对环境变化做出快速反应的能力。因为处理单元（应用的部署实例）可以快速的启动和关闭，整个应用可以根据用户量和负载做出反应。使用这个架构通常在应对代码变化上，由于较小的应用规模和组件间相互依赖，也会反映良好。\n\n#### 易于部署\n评分：高 \n分析：虽然基于空间的架构通常没有解耦合并且功能分布，但他们是动态的，也是成熟的基于云的工具，允许应用轻松的部署到服务器。\n\n#### 可测试性\n评分：低 \n分析：测试高用户负载既昂贵又耗时，所以在测试架构的可伸缩性方面很困难\n\n#### 性能\n评分：高 \n分析：通过内存中数据存取和架构中的缓存机制可获得高性能\n\n#### 伸缩性\n评分：高 \n分析：高伸缩性是源于几乎不依赖集中式的数据库，从而去除了这个限制伸缩性的瓶颈。\n\n#### 易于开发\n评分：低 \n分析：主要是因为难以熟悉这个架构开发所需得工具和第三方产品，因此使用该架构需要较大的学习成本。而且，开发过程中还需要特别注意不要影响到性能和可伸缩性。\n\n\n### 附录A \n#### 模式分析总结\n图A-1 总结了在这个报告中，对于架构模式的每部分进行的模式分析所产生的影响。这个总结帮助你确定哪些模式可能是最适合你的情况。例如,如果你的架构模式重点是可伸缩性，你可以在这个图表看看事件驱动模式,microservices模式,和基于空间模式，这些对于你来说可能是很好的架构模式的选择。同样的,如果你的程序注重的是分层架构模式,你可以参考图看到部署、性能和可伸缩性的在你的架构中所存在的风险。\n\n![a-1](images/a-1.png) \n\n同时这个图表将指导你选择正确的模式,因为在选择一种架构模式的时候，有更多的因素需要考虑。你必须分析你的环境的各个方面,包括基础设施的支持,开发人员技能,项目预算,项目最后期限,和应用程序大小等等。选择正确的架构模式是至关重要的,因为一旦一个架构被确定就很难改变。\n\n\n### 关于作者 \nMark•Richards是一位有丰富经验的软件架构师，他参与架构、设计和实施microservices体系结构、面向服务的体系结构和在J2EE中的分布式系统和其他技术。自1983年以来，他一直从事软件行业,在应用、继承和企业架构方面有大量的经验和专业知识。\n\nMark在1999到2003年间担任新英格兰Java用户组的主席。他是许多技术书籍和视频的作者,包括软件架构基础(O‘Reilly视频)、企业消息传递(O'Reilly视频),《Java消息服务，第二版》(O'Reilly)和《软件架构师应该知道的97件事》(O'Reilly)的特约作者。Mark拥有一个计算机科学硕士学位并且多次获得IBM、Sun、开放集团和BEA等颁发的架构师和开发人员认证。 \n\n他是Fluff Just Stuff(NFJS)研讨会系列（一个不定期会议）议长,并且有过上百次的在世界各地公益会议和用户组上围绕技术主题的演讲经验)。Mark不工作的时候经常会到白色山脉或阿帕拉契山径徒步旅行。\n\n\n" }, { "path": "software-architecture-patterns/附录2015-4-11-charli.md", "content": "# APPENDIX A #\n## Pattern Analysis Summary ##\nFigure A-1 summarizes the pattern-analysis scoring for each of the\narchitecture patterns described in this report. This summary will\nhelp you determine which pattern might be best for your situation.\nFor example, if your primary architectural concern is scalability, you\ncan look across this chart and see that the event-driven pattern,\nmicroservices pattern, and space-based pattern are probably good\narchitecture pattern choices. Similarly, if you choose the layered\narchitecture pattern for your application, you can refer to the chart\nto see that deployment, performance, and scalability might be risk\nareas in your architecture.\n45\n\n# 附录A #\n## 模式分析总结 ##\n图A-1 总结了在这个报告中，对于架构模式的每部分进行的模式分析所产生的影响。这个总结帮助你确定哪些模式可能是最适合你的情况。例如,如果你的架构模式重点是可伸缩性，你可以在这个图表看看事件驱动模式,microservices模式,和基于空间模式，这些对于你来说可能是很好的架构模式的选择。同样的,如果你的程序注重的是分层架构模式,你可以参考图看到部署、性能和可伸缩性的在你的架构中所存在的风险。\n\nWhile this chart will help guide you in choosing the right pattern,\nthere is much more to consider when choosing an architecture pattern.\nYou must analyze all aspects of your environment, including\ninfrastructure support, developer skill set, project budget, project\ndeadlines, and application size (to name a few). Choosing the right\narchitecture pattern is critical, because once an architecture is in\nplace, it is very hard (and expensive) to change\n\n同时这个图表将指导你选择正确的模式,\n因为在选择一种架构模式的时候，有更多的需要考虑。\n你必须分析你的环境的各个方面,包括\n基础设施的支持,开发人员技能,项目预算,项目\n最后期限,和应用程序大小(等等)。选择正确的\n架构模式是至关重要的,因为一旦一个架构\n被确定了就很难改变。\n\n\n# About the Author #\nMark Richards is an experienced, hands-on software architect\ninvolved in the architecture, design, and implementation of microservices\narchitectures, service-oriented architectures, and distributed\nsystems in J2EE and other technologies.\n He has been in the\nsoftware industry since 1983 and has significant experience and\nexpertise in application, integration, and enterprise architecture.\nMark served as the president of the New England Java Users Group\nfrom 1999 through 2003.\n He is the author of numerous technical books and videos, including Software Architecture Fundamentals\n(O’Reilly video), Enterprise Messaging (O’Reilly video), Java\nMessage Service, 2nd Edition (O’Reilly), and a contributing author\nto 97 Things Every Software Architect Should Know (O’Reilly).\nMark has a master’s degree in computer science and numerous\narchitect and developer certifications from IBM, Sun, The Open\nGroup, and BEA. \nHe is a regular conference speaker at the No\nFluff Just Stuff (NFJS) Symposium Series and has spoken at more\nthan 100 conferences and user groups around the world on a variety\nof enterprise-related technical topics. \nWhen he is not working,\nMark can usually be found hiking in the White Mountains or\nalong the Appalachian Trail.\n# 有关作者 #\nMark•Richards是一位有实际经验的软件架构师，他参与架构、设计和实施microservices\n体系结构、面向服务的体系结构和在J2EE中的分布式\n系统和其他技术。自1983年以来，他一直从事软件行业,有大量的经验和专业知识在应用、集成和企业架构方面。\nMark从1999年到2003担任新英格兰Java用户组的主席。\n他是许多技术书籍和视频的作者,包括软件架构基础(O‘Reilly视频)、企业消息传递(O'Reilly视频),《Java\n消息服务，第二版》(O'Reilly)和《软件架构师应该知道的97件事》(O'Reilly)的特约作者。\nMark有一个计算机科学硕士学位和很多从IBM、Sun、开放\n集团和BEA获得的架构师和开发人员认证。\n他是Fluff Just Stuff(NFJS)研讨会系列的一个不定期会议议长\n,并且超过100多次在世界各地的公益的会议和用户组上围绕技术主题\n发言。当他不工作时,Mark通常会在白色山脉或阿帕拉契山径徒步旅行。\n\n\n" }, { "path": "template.md", "content": "这里写中文标题\n---\n\n> * 原文链接 : [原文标题](原文url)\n* 原文作者 : [作者](作者的博客或者其他社交页面)\n* 译文出自 : [开发技术前线 www.devtf.cn](http://www.devtf.cn)\n* 转载声明: 本译文已授权[开发者头条](http://toutiao.io/download)享有独家转载权，未经允许，不得转载!\n* 译者 : [这里写你的github用户名](github链接) \n* 校对者: [这里校对者的github用户名](github链接) \n* 状态 : 未完成 / 校对中 / 完成 \n\n**注意 : 翻译完之后请认真的审核一遍有没有错字、语句通不通顺，谢谢~**\n\n\n`这里是翻译原文，注意翻译时英文和译文都要留在该文档中，并且是一段英文原文下面直接跟着写译文，便于校对。如下示例 : `\n\nOver the last months and after having friendly discussions at Tuenti with colleagues like @pedro_g_s and @flipper83 (by the way 2 badass of android development), I have decided that was a good time to write an article about architecting android applications.\nThe purpose of it is to show you a little approach I had in mind in the last few months plus all the stuff I have learnt from investigating and implementing it.\n\n过去几个月以来，通过在Tuenti网站上与@pedro_g_s和@flipper83（安卓开发两位大牛）进行友好讨论之后，我决定写这篇关于架构安卓应用的文章。 \n\n我写这篇文章的目的是想把我在过去几个月体悟到的小方法以及在调查和应用中学到的有用的东西分享给大家。\n\nGetting Started\nWe know that writing quality software is hard and complex: It is not only about satisfying requirements, also should be robust, maintainable, testable, and flexible enough to adapt to growth and change. This is where “the clean architecture” comes up and could be a good approach for using when developing any software application.\nThe idea is simple: clean architecture stands for a group of practices that produce systems that are:\n\n## 入门指南\n大家都知道要写一款精品软件是有难度且很复杂的：不仅要满足特定要求，而且软件还必须具有稳健性，可维护、可测试性强，并且能够灵活适应各种发展与变化。这时候，“清晰架构”就应运而生了，这一架构在开发任何软件应用的时候用起来非常顺手。\n\n这个思路很简单：简洁架构 意味着产品系统中遵循一系列的习惯原则：\n\n\n\n" }, { "path": "the-bad-guys/readme.md", "content": "# 国内优秀Android学习资源\n\n## 技术博客\n\n### 应用开发\n\n| 博主 | 博客 | 备注 |\n|-------- |------------------|----------|\n| 任玉刚 | [CSDN博客](http://blog.csdn.net/singwhatiwanna/) | 深入Android应用开发，深度与广度兼顾 |\n| 郭霖 | [CSDN博客](http://blog.csdn.net/guolin_blog/) | 内容实用，行文流畅，高人气博主 |\n| 夏安明 | [CSDN博客](http://blog.csdn.net/xiaanming/) | \n| 张鸿洋 | [CSDN博客](http://blog.csdn.net/lmj623565791/) | 自定义View系列非常有价值，质量与产量都很高 | \n| 爱哥 | [CSDN博客](http://blog.csdn.net/aigestudio/) | 自定义View系列非常有价值，内容详细逼格高 | \n| 傲慢的上校 | [CSDN博客](http://blog.csdn.net/lilu_leo/) | 自定义View系列非常有价值，内容详细逼格高 | \n| Trinea | [个人博客](http://www.trinea.cn/) | 性能优化,开源项目等 | \n| 胡凯 | [个人博客](http://hukai.me/) | 性能优化等 |\n| 谦虚的天下 | [博客园](http://www.cnblogs.com/qianxudetianxia/) | 性能优化等 |\n| 兰亭风雨 | [CSDN博客](http://blog.csdn.net/ns_code) | Java源码分析等 | \n| Mr.Simple | [CSDN博客](http://blog.csdn.net/bboyfeiyu) | 开源框架系列、OOP等 | \n\n\n### 源码分析\n| 博主 | 博客 | 备注 |\n|-------- |------------------|----------|\n| 罗升阳 | [CSDN博客](http://blog.csdn.net/luoshengyang/) | 源码分析 |\n| 邓凡平 | [博客园](http://www.cnblogs.com/innost/) | 源码分析 |\n\n\n## 开源达人\n| 作者 | 备注 |\n|-------- |----------|\n| [square项目组](https://github.com/square) | OkHttp, Retrofit, Otto等很多优秀的开源项目，业界良心！ |\n| [facebook项目组](https://github.com/facebook) | fresco,react native等很多优秀的开源项目，业界良心之二！ |\n| [Jake Wharton](https://github.com/jakewharton) | NineOldAnimatoins, ButterKnife,ViewIndicator等优秀作品，Square员工 |\n| [Trinea](https://github.com/trinea) | 优秀开源项目集锦,优秀开源库架构分析等 |\n| [singwhatiwanna](https://github.com/singwhatiwanna) | DL (插件化),PinnedHeaderExpandableListView等 |\n| [daimajia](https://github.com/daimajia) | 自定义View |\n| [greenrobot](https://github.com/greenrobot) | EventBus, greenDAO |\n| [wyouflf](https://github.com/wyouflf) | xUtils作者 |\n| [litesuits](https://github.com/litesuits) | http,orm等库 |\n| [Mr.Simple](https://github.com/bboyfeiyu) | AndroidEventBus,开发技术前线,Android源码设计模式分析等项目 |\n\n## 优秀学习网站\n| 地址 | 备注 |\n|-------- |----------|\n| [开发技术前线](http://devtf.cn) | 国内外各个开发领域优质技术文章的聚合网站 |\n| [Android Dev Blog](http://android-developers.blogspot.com/) | Android官方博客 |\n| [Android Weekly](http://androidweekly.net) | 国外优秀技术文章的收集网站，每周发布 |\n| [Android开发技术周报](http://androidweekly.cn) | AndroidWeekly中国版 |\n| [码农周刊](http://weekly.manong.io/) | 文章、咨询周报 |\n| [好东西传送门](http://memect.com/) | 各领域技术文章的日报 |\n\n" }, { "path": "翻译项目协作流程.md", "content": "Github协作流程\n---\n\n\n## fork一份到你的账户下\n在[android-tech-frontier](https://github.com/bboyfeiyu/android-tech-frontier)项目中选择右边的\"fork\"，然后选择你的头像，将该项目fork一份到你的账户下。\n\n![fork](http://img.blog.csdn.net/20150323230517092)\n\n点击“fork”后能在个人主页中看到项目就表示fork成功了：\n\n![](http://img.my.csdn.net/uploads/201504/25/1429948243_6050.png)\n\n## clone你fork的仓库到本地\n输入如下命令clone一份你fork的仓库 (相当于拷贝了一份到你的账户下)，例如 : \n![clone](http://img.blog.csdn.net/20150323230449588)\n\n> git clone git@github.com:bboyfeiyu/android-tech-frontier.git\n\n等待clone完毕。此时，在你的当前目录下会有android-tech-frontier目录。进入该android-tech-frontier，在相应的目录下按照[readme.md](readme.md)中的命名规则创建你的翻译项目，然后完成翻译。 \n\n操作完成后就能在相应的目录中看到项目文件了\n\n## 发送 pull request\n\n打开项目首页，点击图中的小绿框\n\n![](http://img.my.csdn.net/uploads/201504/25/1429948415_2193.png)\n\n再点击红框内的文字\n\n![](http://img.my.csdn.net/uploads/201504/25/1429948487_1166.jpg)\n\n就会出现这个页面\n\n![](http://img.my.csdn.net/uploads/201504/25/1429948573_7445.jpg)\n\n将左边选成你的项目，右边选成项目作者的项目，就表示你要将你的项目更新为作者的状态，与作者保持一致\n\n例如项目更新了10篇文章，你翻译好了一篇文章，那么在你提交你的文章之前，你就需要先将项目更新为作者最新的状态，再提交，否则会出现冲突\n\n![](http://img.my.csdn.net/uploads/201504/25/1429948699_7368.jpg)\n\n将左边选成作者的项目，右边选成你的项目，则表示要将你对作者项目作出的改变提交给作者，请求作者同步\n\n![](http://img.my.csdn.net/uploads/201504/25/1429948882_7915.jpg)\n\n选择 Create Pull Request 就可以完成啦\n\n## 进行校对\n\n打开项目作者处的 pull request，当有其他人的 pull request 时页面会如下：\n\n![](http://img.my.csdn.net/uploads/201504/25/1429948986_4450.jpg)\n\n选择某一个 pull request ，将进入相应的页面\n\n![](http://img.my.csdn.net/uploads/201504/25/1429949102_5644.jpg)\n\n点击 commit 能看见提交者的所有 commit，点击相应的 commit 能看到提交者进行了什么操作，修改了什么东西。\n\n点击 FileChange 则能看见提交者提交上来的内容（最终版本）\n\n![](http://img.my.csdn.net/uploads/201504/25/1429949236_2350.jpg)\n\n在每一行的左侧，会出现一个蓝色的 + 号，点击它，就能进行 comment，通过 comment 可以对提交者存在问题的译文作出评论，和译者交流\n\n![](http://img.my.csdn.net/uploads/201504/25/1429949329_3391.jpg)\n\n## 认领翻译任务\n你可以在主仓库下看到一些翻译任务的状态: \n\n* 待认领 : 表示还没有人接这个翻译任务;\n* 翻译中 : 表明已经有人翻译了；\n* 翻译完成 : 表明已经翻译完成；\n* 寻找校对中 : 表明此时文章翻译完成，正在等待校对；\n* 校对中 : 表明正在校对；\n* 校对完成 : 表明校对完成，等待发布。\n \n当你看到某个状态为\"待认领\"的issue时，你可以撸起袖子在该issue下面添加评论，将你的github账户评论到下面，然后管理员会将该issue设置为\"翻译中\"。当你看到“寻找校对中”的任务，则说明该任务已经翻译完，但是需要校对，你也可以在该issue中将你的github账户添加到评论中，然后将该任务设置为“校对中”。 \n校对完毕，管理员确认没啥问题之后会发布该文章，发布后会将该issue关闭。 \n\n![is](http://img.blog.csdn.net/20150323231540412)\n\n\n## 推荐文章\n如果你看到好的文章，也可以在仓库的issue中添加一个，将推荐理由、原文链接填上。如图 : \n\n![submit](http://img.blog.csdn.net/20150323231923706) \n\n## 提交翻译内容到你的仓库中\n在android-tech-frontier下依次输入如下三条命令提交你修改的内容到你的仓库。 \n\n```\ngit add .\ngit commit -m \"我翻译了xxx项目\"\ngit push origin master\n```\n\n## 将你的更新提交到主仓库\n经过上面push命令之后，你的内容已经更新到你自己fork的仓库，此时你需要把你的更新提交到主仓库。因此你需要发一个pull request。在你fork的项目的右边点击\"pull request\",然后选择\"new pull request\"。注意是从你的仓库master分支(左边)到我的仓库的master分支(右边)。然后选择\"create new pull request\"，最后填写相关的内容后确认即可。\n\n![pr](http://img.blog.csdn.net/20150323230526312)\n \n提交了pull request之后，管理员会找相关人员进行校对。校对完成之后管理员会将你的文章发布。 \n\n" } ]