适用于iOS开发者的Android开发技巧

     我曾从事过5年的iOS利用开发工作，那段时间我1直在尽可能避免同Android打交道――不过现在情况不同了。不管大家是不是相信，Android开发其实乐趣满满、而且与iOS开发相比也不像大家想象的那样差异巨大。

     我在Android平台上开发出这款“7分钟锻炼”利用，并借此学到了很多宝贵的知识。我希望这篇文章分享的1些小技能也能帮助大家解决实际问题。请注意，我接下来进行比较的内容其实不1定完全匹配，而且本文的重点也不在于完全地叙述Android开发;固然，我1定会提到自己在开发这款简单利用的进程中所积累到的全部经验。

      IDE

      我选择使用Android Studio，而且我愿意打赌：只要测试完成，它将成为未来的业界标准。虽然很多报导称它的运行状态其实不稳定，但在我的实际使用中、它仅仅崩溃过1次。或许我只是习惯了Xcode。

      Java

      不管大家对Java如何评价，说到底它也只是不过是1种编程语言而已。它能够解决问题，而且对经验丰富的开发者来讲、大家肯定是把主要精力放在框架而非Java身上。很高兴我用不着跟J2EE扯上关系。

      iOS加密

      移动利用安全保护平台――爱加密，在Android利用加密保护方面有dex加壳、独有的so库加密保护、资源文件保护等。而且推出了iOS利用加密保护，实属全球首创。分别从本地数据、方法体/方法名、URL编码、程序结构、网络传输数据等几个方面对iOS利用进行全方位的保护，并可以根据iOS利用用户的需求提供定制解决方案，从而实现iOS防破解保护。下图是iOS利用使用前后

      摹拟器

      我1直认为iOS摹拟器让人头痛不已，但相比之下我才发现当初的自己还是太年轻。在稍作尝试以后，我决定放弃Android摹拟器、直接将利用部署在实际装备上――除非大家愿意拿出大量时间盯着屏幕枯等。

      Storyboard / NIB

      我在自己的iOS开发博客上谈了很多关于Storyboard的话题，很多与我意见相左的读者发来的1些措辞强硬的邮件让我完全放弃了这1交换平台。

      Android使用的布局格式为xml。它们彼此之间完全独立。Android Studio还提供1套出色的“所见即所得”编辑器：

       但大家依然可以深入到原始xml当中――如果愿意的话（反正我1般是不愿意这么麻烦）。

     相对自动布局，大家也能够选择其它布局容器，例如RelativeLayout和FrameLayout之类。在这里，我们能够以像素数量（即装备的像素容纳能力）或matchparent、wrapcontant等来设定理想的宽度、高度、填充效果、边框和色调。

     Wrap非常合适文本内容，它会自动将调剂正确的高度并设定与之相适应的尺寸，并把其余工作交给LinearLayout等特定布局方案。

     虽然我还没有用过，但Fragment看起来一样是1种对自定义UI元素加以重新利用的好途径。

     UIViewController

     Android利用1个Activity来实现UIViewConroller的功能。每个屏幕/窗口都相当于1个Activity。我们就在这里处理大部份工作，包括将数据绑定到UI当中或处理事件等等。

     Controller/View转换

     在iOS当中我们利用segue、pushViewController、presentController等在不同屏幕之间进行迁移。但在Android环境下，我们需要使用Intent。

     大家可以轻松迁移至新的activity当中，乃至能够将1部份数据传递过去。

     在新的Activity（也就是以上代码中的MyActivity）中，我们可以提取出传递来的数据：

     大家也能够利用Intent来触发各类事件，例照实现表格同享：

     IBOutlet

     或许大家跟我1样，在超过半数的情况下会忘记连接IBOutlet。

     在Android当中，每个场景/组件都具有独立的ID，内容以下所示：

      它随后会自动生成1个名为R的类，接下来我们可以以下所示访问代码中的按钮：

      标签

      iOS开发者们常常使用的1项技能就是利用处景标签来保存查找信息，例如整体布局的位移。在Android环境下，大家也能够将全部对象加入到标签当中，这类作法非常实用。

     UITableViewController / UITableViewDataSource / UITableViewCell

     Android当中的ListView就相当于iOS上的UITableView。

     而UITableViewDataSource在Android中所对应的则是ArrayAdapter：

     其中listviewitemrow属于某1行的布局，相当于iOS中的UITableViewCell。

     其中的adapter随后会在getView当中创建/重新使用各行。

     大家也能够像这样设置标题：

      图片/资源

      由于有了Asset Catalogue的辅助，iOS环境下的图片处理变得非常轻松，通常情况下开发者只需斟酌视网膜屏与非视网膜屏这两种情况（除非大家想要在iPhone上使用专门针对iPad的图片）。

      由于Android阵营下各款装备的分辨率千差万别，因此大家必须要提供以下4种图片格式。

      它们分别是：mdpi（普通分辨率）、hdpi（高分辨率）、xhdpi（超高分辨率）和xxhdpi（超超高分辨率）。我个人认为xxxhdpi版本的诞生将只是时间问题。

      在利用Android Studio创建项目时，大家只需要提供1份图标、它就可以自动创建出这4种格式。这类作法相信已给从事过Android利用开发的朋友们留下了严重的心理阴影：别怕，大家可以随后手动将其替换为完善的像素版本。

      因此，最基本的解决思路就是为每幅图片针对每种像素密度创建1个单独的版本，为其设定一样的名称并放在正确的文件夹之下;这样Android就会视装备平台的具体情况挑选理想的版本。

     自定义字体

     自定义字体在Android上实现起来一样非常简单：将字体复制到main/assets当中，而后就可以利用以下代码加以调用：

     问题在于这类方式其实不是在所有装备上都行得通，因此大家需要准备1套后备字体――不过我自己手头的两台Android装备都没有提供这样的字体。

      NSLog

     日志看起来没甚么可讲的，大家可以利用它来进行利用程序调试甚么甚么的（此处省去1千字）。System.out.println(..)似乎也一样能够完成这项任务。

      向下兼容能力

     我们都听说过Android装备的碎片化问题。不过从本质上讲，处理旧版本Android的难度其实不比在旧版本iOS上使用新型iOS功能更高。不过大家可能需要对这类兼容能力加以高度重视，毕竟Android环境下这类问题的出现频率要远高于iOS。

      我们可以通过以下代码来检查当前Android版本：

      以下代码则用于避免函数调用引发的正告信息：

      千奇百怪的漫长Android之旅

      CountDownTimer

      CountDownTimer――这项内置功能的存在实在让我兴奋不已，由于这正是我的7分钟锻炼利用所必须的要素。但是经过实际测试，它不会在onFinish之前发送最后1次onTick，这是个非常诡异的bug而且到现在也没能得到修复。诡异，真是太诡异了。

      方位

      当用户转动手中的装备时，我们的activity也会完全重置，这意味着大家必须在activity重新载入以后为其保存全部状态与恢复机制。Android环境下的处理方式使人头痛，但iOS则处理得很好。

     Kindle Fire / Amazon Store

     要让自己的利用程序顺利入驻Amazon Store，我只需要对现有成果作出两项调剂：

     ・YouTube SDK没法起效，由于Kindle Fire上不提供YouTube利用。不过对Flash的支持能力仍然被保存下来。

     ・大家需要针对Amazon Store替换利用购买代码。

     大家可以利用android.os.Build.MANUFACTURER和android.os.Build.MODEL对装备的制造商和产品型号信息进行检测。